À propos des réseaux auto-reporting (SRN)

En bref : découvrez les réseaux auto-reporting (SRN), également appelés réseaux auto-attribués, qui communiquent les événements attribuables via des API, et non via des liens d'attribution comme les non-SRN. 

blobid0.jpg verizonmedia.png
Google Marketing Platform  Apple Search Ads Google Ads Snapchat Facebook Tencent Social Ads Yahoo! Search Ads Yahoo Twitter

Réseaux auto-reporting

  • SRN :
  • Les non-SRN (réseaux publicitaires) signalent les événements via les liens d'attribution AppsFlyer.
  • Ce qu'implique iOS 14.5 pour les SRN : utilisation du tableau de bord SKAN pour examiner les performances SRN. Attendez-vous à une réduction des installations attribuées aux SRN dans le tableau de bord traditionnel ; utilisez le tableau de bord SKAN. 

Comment fonctionnent les SRN ?

Les utilisateurs consultent et explorent souvent plusieurs publicités avant de finir par installer une application. En général, les fournisseurs d'attribution indiquent aux annonceurs l'attribution qui reflète le dernier touch, ce qui attribue l'installation au tout dernier clic réalisé avant que l'installation n'ait lieu.

Lorsqu'une app est lancée pour la première fois :

  • AppsFlyer vérifie les points suivants :
    • L’app est configurée pour recevoir le trafic des SRN.
    • L'utilisateur a un ID publicitaire.
  • Si les deux conditions sont remplies, AppsFlyer interroge les SRN à l’aide de l’ID publicitaire. 
  • AppsFlyer procède à l'attribution après avoir pris en compte les réclamations SRN. 

Exemple A

SRN_1.png

Lundi : le réseau A rapporte un clic d'utilisateur.

Mardi : le réseau B rapporte un engagement vidéo.

Mercredi : le réseau C rapporte un clic sur une publicité vidéo et, 30 minutes plus tard, une installation a lieu.

AppsFlyer attribue l'installation au réseau C et considère que les réseaux A et B ont assisté l'installation.

AppsFlyer fournit aux annonceurs les données d'assistance (c'est à dire les engagements non attribués qui ont lieu avant installation). Ces données permettent aux annonceurs de personnaliser leurs modèles d'attribution multi-touch ou fractionnée. Pour en savoir plus, veuillez consulter cette courte explication.

Notez que dans le cas d'Apple Search Ads (ASA), AppsFlyer obtient les informations d'attribution à partir du SDK. Si disponible, AppsFlyer renvoie à ASA l'heure et la date du lancement de l'app uniquement.

Les fournisseurs d'attribution tiers et les SRN

Les SRN appliquent une méthode d'attribution différente. Leur procédure est la suivante :

  • Utilisez une API pour communiquer avec les fournisseurs d'attribution et d'analyses (plutôt que le reporting via liens d'attribution).
  • Lorsque les fournisseurs d’attribution détectent une installation, ils interrogent le réseau à l’aide de l’ID publicitaire.
  • Le SRN rapporte les infos détaillées pour tous les clics ou impressions publicitaires concernés.
  • AppsFlyer applique sa logique d'attribution habituelle pour séquencer les données d'impression et de clic importantes.
  • L'attribution AppsFlyer se base sur les deux méthodes last-touch et multi-touch.

Exemple B

Cet exemple est la suite de l'exemple A ci-dessus.

SRN_2.png

Le réseau D (SRN) rapporte un clic quelques minutes avant le réseau C.

Le réseau C utilise une intégration d'attribution standard.

AppsFlyer attribue l'installation au réseau C, associé au dernier clic.

Les SRN et les fenêtres d'attribution

Les fenêtres d'attribution comprennent les fenêtres rétrospectives et post-vue.Certains SRN facturent les annonceurs en fonction des installations basées sur le coût par impression (CPM) ou le coût par action (CPA) (c'est à dire basées sur les clics ou impressions qui se produisent sur une période allant de 1 à 28 jours).

AppsFlyer attribue l'installation, l'activité, le coût effectif par installation (eCPI) et le coût effectif par action (eCPA) en fonction de la méthode d'attribution préférée de l'annonceur et des fenêtres rétrospectives.

Les annonceurs peuvent avoir à payer les installations en fonction de la fenêtre rétrospective d'attribution SRN ou d'un modèle post-vues.

  • Les annonceurs attendent d'AppsFlyer et de sa méthodologie d'attribution universelle tierce qu'il optimise et alloue leurs dépenses publicitaires.
  • Pourquoi ? Parce que AppsFlyer rapporte les eCPI et eCPA en fonction des termes qui ont été définis par l'annonceur.
  • Les SRN peuvent en bénéficier à court terme car ils imposent souvent leurs propres conditions de paiement. Mais les annonceurs font en sorte que cela ne se produise pas en passant par des fournisseurs d'attribution tiers.

Deep Linking avec des SRN

Pour ouvrir l'app lorsqu'un utilisateur clique sur le lien, il vous suffit de configurer les liens d'app/liens universels/schéma d'URI. 

Cependant, le deep linking ou le deep linking différé vers une page/activité spécifique de l'app ne fonctionne pas de la même manière. Les SRN disposent de leurs propres méthodes de deep linking, qui n'incluent pas les liens d'attribution des services d'attribution externes.

Comment pouvez-vous rediriger vos utilisateurs via le Deep Linking et obtenir les données pertinentes de la part des SRN ?

Deep Linking direct avec des SRN

Les SRN utilisent leurs propres méthodes pour le deep linking.
Cela signifie que la méthode de deep linking AppsFlyer n'est pas appelée lorsqu'un appareil utilisateur effectue un deep linking à partir d'un SRN. Si les données de deep linking direct sont nécessaires dans l'app, il convient d'utiliser les méthodes des SRN pour les obtenir au lancement de l'app. 

Remarque : veuillez consulter les instructions relatives à Facebook qui stipulent quand OneLink peut être utilisé.

Deferred Deep Linking avec des SRN

Il est possible de réaliser du deferred deep linking avec des SRN en passant par l'API GCD AppsFlyer. 
AppsFlyer reçoit les données de conversion puis les met à la disposition de l'application lors du premier lancement.
Les nouveaux utilisateurs qui installent l'application après avoir cliqué sur une campagne de deep linking / retargeting sur un SRN peuvent être redirigés dans l'application au moment de son lancement, et ce grâce aux données de conversion.

Toutefois, les SRN ne disposent pas des paramètres de Deep Linking standard d'AppsFlyer sous forme de données de Deep Linking.
Pour utiliser ces données dans l'app, le développeur doit utiliser une logique supplémentaire basée sur les paramètres disponibles tels que les campagnes, les ad sets ou les noms de publicité uniques.

Remarque : avec Facebook, le deferred deep linking via GCD est disponible pour les apps Android qui utilisent le procédé Google Install Referrer. Il n’est pas disponible pour les apps iOS.

 Exemple

Jill, la marketeuse d'apps mobile Greatapp décide de lancer sur Facebook une campagne de Deep Linking destinée au grand public.
Tous les utilisateurs qui cliquent sur la campagne sont redirigés vers une activité « bonus ».
Jack, le développeur mobile, ajoute la logique suivante après avoir obtenu les données de conversion :
1. Le trafic provient-il de Facebook ("is_fb=true") ?
2. Si oui, obtenir la valeur du paramètre adgroup.
3. Si la valeur contient le mot « bonus », rediriger l'utilisateur vers l'activité « bonus ».
En utilisant les méthodes de Facebook, les utilisateurs habituels qui cliquent sur la publicité sont directement redirigés vers l'activité, tandis que les nouveaux utilisateurs obtiennent la même expérience en utilisant les données de conversion d'AppsFlyer.

FAQ

Pourquoi le champ URL d'origine est-il vide dans les rapports de données brutes ?

Le clic est effectué dans l'environnement SRN mais sans lien d'attribution AppsFlyer. Les données d'URL d'origine associées au clic ne sont donc pas disponibles pour AppsFlyer. 

Le tableau de bord n'affiche pas les clics et les impressions SRN

Le clic est effectué dans l'environnement SRN mais sans lien d'attribution AppsFlyer. Par conséquent, certains SRN ne fournissent pas de données de clics et d'impressions à AppsFlyer.

Facebook et Google transmettent à AppsFlyer des données agrégées.

Configurer une campagne avec une agence et un SRN

Comment fonctionne le retargeting avec les SRN ?

Les clics de retargeting de sources non-SRN sont facilement identifiables grâce au paramètre is_retargeting=true dans le lien d'attribution de retargeting.
Avec les SRN, il n'y a aucune indication similaire. Pour permettre d'attribuer les réengagements des sources SRN, AppsFlyer utilise une autre logique :

  • Prérequis :
    • Sur la page des paramètres d'app , sélectionnez Activer le retargeting.
    • Sur la page des partenaires intégrés, sélectionnez le SRN et activez Retargeting.
  • À chaque lancement d'app, AppsFlyer interroge le SRN sur les engagements récents de l'ID d'appareil avec des publicités de campagne pour l'app.
    • Si le SRN répond avec les éléments détaillés de l'engagement, AppsFlyer valide que l'engagement se situe dans la fenêtre rétrospective et dépasse le délai minimum autorisé entre les réengagements.
    • Les engagements validés sont enregistrés comme des réengagements et attribués au SRN.

Qu'est-ce qu'un mauvais ciblage SRN ?

Les campagnes SRN sont censées cibler un public précis, mais ce n'est pas toujours le cas : des non-utilisateurs peuvent être touchés dans des campagnes d'acquisition d'utilisateurs, et des utilisateurs existants peuvent l'être dans des campagnes de retargeting.

Si un SRN est utilisé pour lancer à la fois des campagnes d'acquisition d'utilisateurs et de retargeting, il y a des choses d'obtenir un mauvais ciblage des utilisateurs. Le résultat, c'est que vous payez pour un trafic dont vous ne vouliez pas.

Scénario : un SRN de la plate-forme AppsFlyer est activé pour une campagne d'acquisition utilisateur.

  • Après chaque lancement d'app, AppsFlyer interroge le SRN pour vérifier si l'ID publicitaire (utilisateur) a eu un engagement récent.
  • Si tel est le cas,
    • le SRN répond en donnant le nom de la campagne.
    • AppsFlyer détermine s'il s'agit du premier lancement (ou non) et gère les attributions :
      Premier lancement : une nouvelle installation est attribuée à la campagne.
      Deuxième lancement ou lancement ultérieur : un événement de retargeting est attribué à la campagne.

Conclusion : il est contre-productif de vouloir obtenir les événements de retargeting à partir d'une campagne d'acquisition d'utilisateurs.

Le mauvais ciblage pose-t-il des problèmes ?

Les analystes de données AppsFlyer ont surveillé les campagnes d'acquisition d'utilisateurs de Facebook pendant un certain mois.

  • Le retargeting était activé.
  • Dans 30 % des campagnes, au moins 15 % des utilisateurs ciblés étaient des utilisateurs de l'app déjà existants.
  • Dans 5 % des campagnes, au moins 40 % d'entre eux étaient des utilisateurs déjà existants de l'app.
  • Conclusion : dans les campagnes d'acquisition d'utilisateurs SRN, 1 utilisateur ciblé sur 10 est déjà un utilisateur existant. 

mistargeted_users.png

Comment résoudre le problème du mauvais ciblage

Solution imparable  : ne pas inclure les utilisateurs existants dans une campagne d'acquisition d'utilisateurs.

  • Le SRN ciblera uniquement les nouveaux utilisateurs.
  • Maximise les résultats d'acquisition des nouveaux utilisateurs avec le même budget.
  • Mettez périodiquement (et manuellement) la campagne à jour, par exemple une fois par mois.
  • Toutefois, en raison de certains délais, les utilisateurs existants pourront être ciblés par une campagne d'acquisition d'utilisateurs durant le premier mois qui suivra l'installation de leur app.

Audiences, qui est une fonctionnalité premium AppsFlyer, vous permet d'envoyer automatiquement et chaque jour à des dizaines de réseaux publicitaires, un segment choisi de votre base d'utilisateurs.

Des études AppsFlyer indiquent qu'en corrigeant un mauvais ciblage, l'impact sur le marketing et sur les actions d'acquisition d'utilisateurs peut être significatif.

Impact de l'attribution SRN iOS 14.5

À partir d'iOS 14.5 :

  • La plupart des SRN prennent en charge SKAdNetwork et ont l'intégration nécessaire avec AppsFlyer. 
  • Installations SRN :
    • Affichage possible dans les tableaux de bord SKAdNetwork et traditionnels si les utilisateurs donnent leur consentement ATT à la fois dans les apps de l'annonceur et de l'éditeur (double consentement).
    • Sont enregistrés dans le tableau de bord SKAdNetwork. Important ! Le tableau de bord se met à jour avec un décalage de 48 à 72 heures après l'installation.
  • Les installations effectuées par Apple Search Ads (ASA) ne sont pas attribuées dans le tableau de bord SKAdNetwork.

Globalement, il faut s'attendre à une diminution des installations attribuées aux SRN et à une augmentation correspondante des installations organiques.

iOS 14 a-t-il un impact sur l'envoi de postbacks d'événements aux SRN ?

  • Actuellement, les SRN qui reçoivent des postbacks d'événements comptent sur l'inclusion de l'ID de l'appareil dans le retour. Cela permet aux SRN d'auto-attribuer les actions d'un utilisateur défini.
  • Beaucoup d'utilisateurs d'iOS 14 ne donnent pas leur accord (pour l'accès à leur identifiant d'appareil (IDFA)).

iOS 14 affecte les SRN de la façon suivante :

  • Une diminution du nombre de postbacks d'événements vers les SRN
  • Divergences dans le nombre de postbacks d'événements entre les SRN et AppsFlyer, qui enregistrent tous les événements.
  • Les réseaux publicitaires par clic ne sont pas affectés, car ils utilisent leurs propres identifiants de transaction, et non les identifiants d'appareil, pour auto-attribuer des informations de postback d'événement.

Est-ce que AppsFlyer envoie des postbacks pour les ID de publicité manquants (IDFA / GAID) ?

Lorsque les ID publicitaires contiennent une chaîne vide ("") ou affichent la valeur 00000000-0000-0000-0000-000000000000 (IDFA en zéro), AppsFlyer n'envoie pas de postback pour les installations, ouvertures d'app ou événements in-app, sauf dans les cas suivants :
  • Dans le cas d'une intégration pour les mesures avec Google Ads, lorsqu'un utilisateur iOS n'ayant pas donné son accord ouvre l'app ou génère un événement in-app, AppsFlyer envoie le gbraid ainsi que les informations de l'événement à Google Ads (pour l'événement additional_data_json ).
  • Sous Android, lorsqu'il n'y a pas d'ID d'appareil mais que la valeur du référent contient un gclid (pour les installations), ou qu'un événement de réengagement contient un deep link avec le paramètre gclid, AppsFlyer envoie le gclid ainsi que les informations d'événement à Google Ads.
Paramètre gbraid Google Ads : un ID agrégé généré par Google qui permet d'identifier un groupe d’appareils et qui est référencé par le deep link. 
ID de clic Google (paramètre gclid) : un paramètre que transmet l'URL lors d'un clic sur une publicité, et qui permet d'identifier la campagne et autres attributs de clics associés à la publicité. Il permet le suivi des publicités et l’attribution des campagnes.
Cet article vous a-t-il été utile ?