En bref : les rapports de données brutes détaillent les installations et événements in-app bloqués par le moteur Protect360, ainsi que par les règles de validation ajoutées manuellement.
À propos des rapports de données brutes Protect360
Rapports de données brutes :
- Afficher les données sur :
- Clics, installations et événements in-app identifiés comme frauduleux par le moteur Protect360.
- Installations et événements in-app identifiés par les règles de validation.
- Indiquez la raison du blocage pour chaque clic, installation ou événement in-app.
- Utilisé par les annonceurs pour rapprocher les comptes des réseaux publicitaires, à des fins d'optimisation, et pour ajuster les tableaux de bord d'attribution pour la fraude post-attribution.
- Certains champs peuvent être restreints ou non disponibles si la Confidentialité avancée agrégée (CAA) AppsFlyer est appliquée.
- Les types de rapports et leur disponibilité pour les téléchargements, API et Data Locker (compartiment S3) sont décrits ci-dessous.
- Les rapports sur les données historiques brutes sont conservés jusqu'à 90 jours, en fonction de l'outil de reporting et de l'origine des données brutes.
Types de rapport
Types de rapports de données brutes Protect 360
| Rapport | Description |
|---|---|
| d'installations |
Les rapports comprennent :
|
| Installations post-attribution |
Les rapports incluent les installations attribuées à une source média, mais qui se sont révélées frauduleuses par la suite.Protect360 corrige l'attribution. |
| Événements in-app bloqués |
Les rapports incluent les événements in-app de :
|
| Évènements in-app post-attribution |
Les rapports incluent les événements in-app de :
|
| Clics | Les rapports incluent les clics bloqués avec les raisons du blocage. |
| Postbacks d'installations bloquées | Les rapports incluent des copies des postbacks de rejet envoyés aux sources média apportant des installations bloquées. |
Rapports post-attribution
- Les rapports de fraude de données brutes post-attribution possèdent la même structure que les rapports sur les fraudes bloquées.
- Le rapport post-attribution du mois en cours (par date d'installation) continue d'être mis à jour jusqu'au septième jour du mois suivant (date de détection).
- Les rapports de données brutes post-attribution sont réservés aux annonceurs. Les agences ont besoin que les autorisations soient activées pour y accéder.
- Les rapports contiennent les événements de fraude post-attribution identifiés par Protect360 et rassemblent toutes les sources média dans un rapport unique. Remarque : Si aucun événement de fraude post-attribution n'a été identifié pour la période sélectionnée, le rapport est vide.
-
Les rapports de fraude sur les données brutes post-attribution sont disponibles comme suit :
- Interface utilisateur du tableau de bord : limitée à une source média pendant un mois civil.
- API Pull : contient toutes les sources média. (Restriction : disponible uniquement pour les propriétaires d'app)
Utilisation des rapports post-attribution
- Sélectionnez n'importe quelle combinaison d'installation/IAE et détectez les plages de dates selon vos besoins.
- Tenez compte du fait que Protect360 procède à la détection post-attribution pendant le mois civil de l'installation et jusqu'au septième jour du mois suivant. Cela signifie, par exemple, que pour les installations de novembre, Protect360 vérifie la fraude jusqu'au 7 décembre.
- La meilleure pratique pour utiliser cette API Pull est la suivante :
- Supposons que vous génériez un rapport quotidiennement.
- Définissez la plage de dates d'installation sur 60 jours à partir de la journée en cours.
- Définissez la plage de détection detect-from/detect-to jusqu'à la veille du jour en cours.
Cela signifie que vous obtiendrez la liste des fraudes post-attribution détectées la veille. Si vous n'avez pas généré de rapport pendant quelques jours, ajustez la plage de dates de détection et extrayez le rapport.
Exemple
Exemple A : en décembre (date d'installation), 15 installations sont attribuées à example_media . Le 3 janvier (date de détection), Protect360 identifie example_media comme un fraudeur. Les 15 installations attribuées à example_media sont donc répertoriées comme frauduleuses dans le rapport de fraude post-attribution, pour que le propriétaire de l'application prenne les mesures nécessaires.
Exemple B : en décembre, 15 installations sont attribuées à example_media. Le 9 janvier, Protect360 identifie example_media comme un fraudeur. Dans ce cas, aucune action n'est entreprise par Protect360, car le fraudeur a été identifié après la clôture du mois, le 7 janvier.
Disponibilité des données brutes par type d'outil
Disponibilité des données brutes Protect 360 par type d'outil
| Rapport | Actualisation des données | API pull | Page Données d'exportation | Data Locker |
|---|---|---|---|---|
| d'installations | temps réel | ✓ | ✓ | ✓* |
| Événements in-app bloqués | temps réel | ✓ | ✓ | ✓ |
| Clics | temps réel | ✓ | ✓ | ✓ |
| Postbacks d'installations bloquées | temps réel | - | ✓ | - |
| Installations post-attribution |
Tous les jours à 10:00 UTC |
✓ |
✓ | ✓* |
| Évènements in-app post-attribution |
Tous les jours à 10:00 UTC |
✓ | ✓ | - |
|
* Limitations du rapport via Data Locker :
|
||||
Obtenir des rapports de données brutes
Les rapports de données brutes sont disponibles via téléchargement, API Pull et Data Locker (compartiment S3). Vous pouvez également donner à vos partenaires l'accès aux rapports.
Télécharger
À télécharger :
- Dans le tableau de bord Protect360, allez dans Rapports de données brutes > Blocages ou Post-attribution.
- Pour les rapports post-attribution, choisissez une source média et un mois.
- Sélectionnez le rapport Protect360 et des règles de validation à télécharger.
OU
- Dans le tableau de bord AppsFlyer, allez dans données d'exportation.
- Sélectionnez le rapport Protect360 et des règles de validation à télécharger.
Remarque : les rapports téléchargés depuis la page des données d'exportation contiennent l'ensemble des sources média.
API pull
Pour télécharger les rapports de données brutes disponibles via API Pull :
Avant de commencer :
Vous devez avoir un jeton d'API Pull. Le jeton s'obtient auprès d'un utilisateur admin.
- Rendez-vous dans Intégration > Accès API.
La pageAPI Pull s'ouvre. - Dans la section des rapports de fraude Protect360, sélectionnez l'appel API Pull requis.
- Remplissez les paramètres selon vos besoins. Le tableau qui suit répertorie les paramètres.
- Extrayez le rapport.
Paramètres de rapport des données brutes de l'API Pull
| Paramètre | Description | Format | Obligatoire |
|---|---|---|---|
| app_id | L'ID app tel qu'il apparaît dans AppsFlyer | Chaîne | Oui |
| api_token | Récupérez la clé depuis le tableau de bord. Rendez-vous dans Intégration > Accès API. Seul un utilisateur admin peut récupérer le jeton d'API. | Chaîne | Oui |
| from |
Début de la plage de dates :
|
AAAA-MM-JJ | Oui |
| to |
Fin de la plage de dates :
|
AAAA-MM-JJ | Oui |
| event_name |
[Facultatif pour les fraudes d'événements in-app post-attribution] Filtrez les événements par événement in-app. Limitez le rapport à des événements spécifiques. Un ou plusieurs événements peuvent être inclus. Exemple d'utilisation : |
Chaîne |
Non
|
| additional_fields=rejected_reason_value |
[Facultatif pour les fraudes d'événements in-app post-attribution] rejected_reason_value affiche le contributeur valide (source média) pour les installations/événements in-app détournés. Renseigné par contributeur[1-3] ou bien organique. |
Chaîne |
Non |
| detect-from |
[Facultatif pour les installations post-attribution] Début de la plage de dates de détection de fraude. (La valeur par défaut est from.) (Utilisée pour la fraude d'installation post-attribution). (Utilisée pour la fraude d'installation post-attribution). |
AAAA-MM-JJ | Non |
| detect-to |
[Facultatif pour les installations post-attribution] Fin de la plage de dates de détection de fraude (La valeur par défaut est to.) |
AAAA-MM-JJ | Non |
Data Locker
Data Locker inscrit les données brutes dans un compartiment AWS S3.
Voir la liste des rapports Protect360 disponibles.
Reportez-vous aux instructions de configuration de Data Locker.
Structure de rapports Protect360
Les rapports Protect360 ont la même structure globale de champs que les rapports d'acquisition utilisateur.
En plus des champs de rapports des données brutes habituels, les rapports Protect360 incluent les champs de retargeting et de motifs de blocage suivants :
Motifs de blocage
Raisons du blocage au niveau des clics
Au niveau des clics, seuls les clics sont bloqués. Le processus d'attribution se contente de les ignorer.
| Motif bloqué | Description |
|---|---|
| ip_blacklist | Basé sur une liste créée dynamiquement (détails) |
| invalid_fingerprint | Clics S2S uniquement : les paramètres non valides sont envoyés par la source (pour la correspondance probabiliste) |
| click_capping | Des taux extrêmement élevés de clics frauduleux sont détectés sur ce réseau publicitaire. En savoir plus |
| click_signing | La signature du clic n'est pas validée. En savoir plus |
| input_validation | Nom de source média invalide |
Raisons de blocage au niveau de l'installation
Au niveau de l'installation, nous identifions suffisamment d'informations au moment de l'installation pour déterminer si :
- L'installation est frauduleuse, c'est à dire si l'utilisateur qui installe l'app n'est pas une vraie personne. Dans ce cas, l'attribution est complètement bloquée.
- L'attribution est détournée, car l'utilisateur est une vraie personne mais l'engagement est falsifié. Dans ce cas, l'engagement frauduleux est bloqué et l'attribution est réattribuée au premier ad network contributeur valide.
Les tableaux suivants répertorient les différentes raisons qui peuvent bloquer une installation :
Niveau installation : causes de blocage des installations frauduleuses
| Motif bloqué | Sous-motif bloqué | Description |
|---|---|---|
| Robots | fake_device_parameters | Comportement non humain détecté dans les paramètres de l'appareil durant le processus d'installation de l'app |
| Robots | fake_install_parameters | Comportement non humain détecté dans les paramètres de l'installation durant le processus d'installation de l'app |
| Robots | bayesian_network | Identification de schémas frauduleux selon le réseau bayésien |
| install_store_validation | - |
Échec de validation du reçu d'installation de l'App Store Apple |
| validation_bots | invalid_device_parameters | Anomalie au niveau du contenu de certains champs de l'appareil - défini par le client |
| validation_bots | validation_rules |
Règles avec lesquelles les installations sont bloquées en fonction d'une règle de validation définie manuellement |
Niveau installation : causes de blocage des installations piratées
| Motif bloqué | Sous-motif bloqué | Description |
|---|---|---|
|
ctit_anomalies |
short_ctit |
Installations bloquées à cause d'un CTIT trop court : défini par Protect360 |
|
install_hijacking |
referrer_hijack |
Tentative de piratage bloquée selon les paramètres de l'API GooglePlay et du SDK AppsFlyer |
|
install_hijacking |
integration_temporarily_blocked |
Installation bloquée car le partenaire (pid) présente un niveau de fraude extrêmement élevé ainsi que d'importantes anomalies sur l'ensemble de son trafic |
|
validation_hijacking |
short_ctit |
Installations bloquées à cause d'un CTIT trop court : défini par le client |
|
validation_hijacking |
empty_site_id |
Installations bloquées en raison d'un identifiant de site non renseigné. La mise en place des règles se fait progressivement |
|
validation_hijacking |
validation_rules |
Règles avec lesquelles les attributions sont bloquées en fonction d'une règle de validation définie manuellement |
Motifs de blocage au niveau du regroupement
Lorsqu'un modèle de fraude est détecté, la source frauduleuse est classée dans la liste bloquée. Les installations provenant des sources figurant sur cette liste sont bloquées pour les raisons suivantes :
- L'installation est frauduleuse, c'est à dire si l'utilisateur qui installe l'app n'est pas une vraie personne. Dans ce cas, l'attribution est complètement bloquée.
- L'attribution est détournée, car l'utilisateur est une vraie personne mais l'engagement est falsifié. Dans ce cas, l'engagement frauduleux est bloqué et l'attribution est réattribuée au premier ad network contributeur valide.
Les tableaux suivants répertorient les différentes raisons qui peuvent entraîner le blocage au niveau regroupement :
Niveau regroupement : causes de blocage des installations frauduleuses
| Motif bloqué | Sous-motif bloqué | Description |
|---|---|---|
| Robots | timestamp_anomalies | Anomalies liées au temps de clics du flux d'attribution et autres marqueurs temporels collectés sur l'appareil |
| bots, site_blacklist | device_emulators | Installations générées à grande échelle par des scripts automatiques s'exécutant dans un environnement virtuel. |
| site_blacklist | device_farms | Taux élevés de (nouveaux) appareils inconnus |
| behavioral_anomalies | behavioral_anomalies | Comportement in-app suspect par rapport au modèle de comportement utilisateur habituel de l'app |
Niveau regroupement : causes de blocage des attributions piratées
| Motif bloqué | Sous-motif bloqué | Description |
|---|---|---|
| ctit_anomalies, install_hijacking | ctit_anomalies | Modèle CTIT anormal selon les critères habituels de l'app |
| click_flood | click_flood | Volume de clics anormalement élevé sur une distribution CTIT longue |
| install_hijacking | click_clusters | Clics générés par un malware au niveau de l'appareil |
Raisons de blocage au niveau in-app
Les événements in-app peuvent être bloqués pour les raisons suivantes :
- L'installation initiale a été identifiée comme frauduleuse.
- À cause d'une règle de validation définie.
- Notre algorithme a détecté la fraude.
Le tableaux suivant répertorient les différentes causes qui peuvent créer un blocage au niveau in-app :
Causes de blocage au niveau in-app
| Motif bloqué | Sous-motif bloqué | Description |
|---|---|---|
| Hérite de l'installation | Hérite de l'installation | Installation initiale identifiée comme frauduleuse au niveau installation ou liste bloquée. |
| inapps_bots | fake_device_parameters | L'algorithme AppsFlyer détecte la fraude |
| in_app_store_validation | - | Échec de la validation de réception pour les achats intégrés. |
| validation_inapps | validation_rules |
Basé sur une règle de validation définie manuellement |
Retargeting
Les données brutes Protect360 incluent les installations et sessions frauduleuses issues de campagnes de retargeting (nommées respectivement : réattributions et réengagements). Les données affichent les champs nom de l'événement et type de conversion de retargeting. Elles sont signalées comme étant soit :
- Installation (concerne le nom de l'événement, mais pas le type de conversion de retargeting)
- Réattribution
- RÉENGAGEMENT
- Réinstallation
Les données brutes de retargeting Protect360 sont proposées pour les blocages en temps réel et la fraude identifiée en post attribution comme suit :
| Rapport | Données d'exportation | API pull | Data Locker |
|---|---|---|---|
| d'installations | ✓* | ✓* | - |
| Installations post-attribution | ✓ | ✓ | ✓ |
|
* Données de réengagement non disponibles |
|||
Correction de l'attribution des installations détournées
En ce qui concerne les installations détournées, AppsFlyer bloque l'attribution au réseau frauduleux et attribue l'installation à la dernière source contributrice légitime.
Pour les installations détournées, utilisez le champ rejected_reason_value pour identifier le contributeur valide (source média), c'est-à-dire le contributeur qui aurait dû recevoir l'attribution à l'origine.
- La valeur rejected_reason_value est renseignée avec contributeur[1-3] ou organique. Consultez les champs contributeur[1-3] source média/partenaire pour accéder aux informations du contributeur et faire le rapprochement.
- Si les champs du contributeur ne s'affichent pas dans votre rapport, vous pouvez les ajouter depuis la page Données d'exportation.
Remarque : lorsque les installations détournées sont bloquées en temps réel, les attributions correctes s'affichent dans les tableaux de bord et les rapports AppsFlyer (pas seulement dans Protect360). Lorsque des installations détournées sont identifiées post-attribution, les attributions correctes s'affichent uniquement dans les données brutes de Protect360.