Rapports de données brutes Protect360

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.

Lectures complémentaires : Présentation | Tableaux de bord | Règles de validation

À 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.
  • Les types de rapports et leur disponibilité par téléchargement, API et Data Locker (seau S3) sont décrits dans les sections suivantes.

Types de rapport

Types de rapports de données brutes Protect 360
Rapport Description
d'installations

Les rapports comprennent : 

  • Fausses installations : installations identifiées comme frauduleuses par le moteur Protect360. Ces éléments n'apparaissent dans aucun tableau de bord ou données brutes d'AppsFlyer, à l'exception du tableau de bord et des données brutes de Protect360.
  • Installations détournées : l'utilisateur réel installe là où l'attribution est volée, mais Protect360 corrige l'attribution.
    • Dans les rapports d'installation de Protect360, la source média frauduleuse est affichée.
    • Dans les rapports d'installations régulières de données brutes (non organiques et organiques), la source média correcte s'affiche.
  • Règles de validation : qui ont soit bloqué l'installation, soit bloqué l'attribution. 
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.

Événements in-app bloqués 

Les rapports incluent les événements in-app de :

  • Fausses installations : les IAE sont bloqués.
  • Installations détournées : 
    • Dans les rapports d'installation de Protect360, la source média frauduleuse est affichée.
    • Dans les rapports réguliers sur les données brutes des événements in-app, la source média correcte est affichée.
  • Événement in-app : identifié comme frauduleux indépendamment des installations initiales.
  • Règles de validation :
    • Les IAE provenant d'une règle qui bloquait l'installation ou l'attribution bloquée.
    • Les IAE provenant d'une règle qui bloquait l'événement in-app.
Évènements in-app post-attribution

Les rapports incluent les événements in-app de :

  • Identifié après l'attribution.
  • Des installations attribuées à une source média, mais qui se sont révélées frauduleuses par la suite.
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 incluent toutes les sources média dans un rapport unique. 
  • 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.
  • Pour les installations/IAE détournés, uutilisez 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 peuplée avec contributor[1-3] ou organic. Vérifiez les champs contributor [1-3] pour voir les détails du contributeur et faire le rapprochement.
    • Si les champs des contributeurs ne s'affichent pas dans votre rapport, ils peuvent être ajoutés à partir de la page Exporter les données.
  • 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 :

  • Transparence de l'agence non prise en charge. Ce qui signifie que le trafic généré par une agence ne contient pas le nom de la source média qui envoie l'installation. 
  • Le rapport contient un ensemble de champs unique comparé aux autres rapports Data Locker. Cette liste n'est pas modifiable. 

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.

OU

  • Rendez-vous sur la page Données d'exportation.


    Remarque : les rapports téléchargés depuis la page 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. Ce jeton s'obtient auprès de l'administrateur.

  1. Rendez-vous dans Intégration > Accès API.
    La pageAPI Pull s'ouvre.
  2. Dans la section des rapports de fraude Protect360, sélectionnez l'appel API Pull requis.
  3. Remplissez les paramètres selon vos besoins. Le tableau qui suit répertorie les paramètres.
  4. 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 l'administrateur du compte peut récupérer le jeton d'API. Chaîne Oui
from

Début de la plage de dates :

  • Pour les installations, il s'agit de la date d'installation.
  • Pour les événements in-app, il s'agit de la date de l'événement.
AAAA-MM-JJ Oui
to

Fin de la plage de dates :

  • Pour les installations, il s'agit de la date d'installation.
  • Pour les événements in-app, il s'agit de la date de l'événement.
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 : &event_name=af_purchase,af_login

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 générale que leurs champs de rapports d'acquisition d'utilisateurs parallèles.

En plus des champs de rapports des données brutes habituels, les rapports Protect360 comportent les champs suivants :

  • Motif bloqué
  • Sous-raisons du blocage
  • Valeur du motif bloqué
  • Règle du motif de blocage

Motifs du blocage Protect360

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)
install_store_validation Les différents écarts entre les valeurs Google Referrer de l'installation
invalid_fingerprint Clics S2S uniquement : paramètres non valides envoyés par la source (pour la correspondance probabiliste)

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 relatifs à l'appareil lors du processus d'installation de l'app
Robots fake_install_parameters Comportement non humain détecté dans les paramètres relatifs à l'installation lors du processus d'installation de l'app
Robots bayesian_network Identification de schémas frauduleux selon le réseau bayésien
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

Cet article vous a-t-il été utile ?