Qu’est-ce que l’API Protected Audience et modifie-t-elle le remarketing ?

L’abandon imminent de GAID par Google en 2024 est une nouvelle à enjeux pour les entreprises et les spécialistes du marketing d’applications. Pour ceux qui utilisent le remarketing comme stratégie principale de fidélisation et d’engagement – et ils sont nombreux comme le montre le graphique A ci-dessous – la situation est encore plus préoccupante.  

Toutefois, avant de tirer la sonnette d’alarme, il est important de souligner que Privacy Sandbox n’est pas aussi effrayant qu’il n’y paraît. Les spécialistes du marketing ne sont pas laissés pour compte. Cette mise à jour s’accompagne d’une innovation technologique qui garantit la mise en place de solutions pour aider les spécialistes du marketing à atteindre leurs objectifs. 

Parallèlement à la réduction de la dépendance à l’égard des identifiants des appareils, de nouvelles technologies de préservation de la vie privée sont mises en place. Chez AppsFlyer, nous travaillons en étroite collaboration avec Google et des partenaires de l’industrie pour concevoir une solution respectueuse de la vie privée, tout en permettant aux entreprises de développer et de fidéliser leurs utilisateurs grâce au remarketing. 

L’API Protected Audience (précédemment appelée FLEDGE) est le cadre proposé par Google pour un remarketing respectueux de la vie privée, effectué directement sur l’appareil et sans recours aux identifiants, spécifiquement pour Android.

Mais l’API Protected Audience modifie-t-elle le remarketing tel que nous le connaissons ? 

Au-delà des équipes de marketing, comment ce nouveau cadre affectera-t-il les développeurs d’applications et les partenaires publicitaires ? 

Réponses ci-dessous.

L’API Protected Audience, simplifiée

Comment le remarketing fonctionnera-t-il à l’ère de l’API Protected Audience ? Voici une explication simplifiée comparant le remarketing actuel, basé sur l’ID publicitaire, au remarketing utilisant l’API Protected Audiences. 

Remarketing avec GAID

Aujourd’hui, le remarketing est rendu possible par Google Advertising ID (GAID) – un identifiant d’appareil mobile interapplicatif généré par le système d’exploitation Android et communiqué aux réseaux publicitaires pour aider les spécialistes du marketing à personnaliser leurs campagnes de la façon suivante :

• Segmentation personnalisée de l’audience : Les utilisateurs d’applications sont regroupés en audiences personnalisées en fonction de caractéristiques communes ou de l’utilisation de l’application, chaque utilisateur d’application étant représenté par son numéro d’identification personnel (GAID). 

• Communication personnalisée avec l’audience : Le GAID est utilisé pour partager l’appartenance d’un utilisateur d’application à une audience personnalisée avec des partenaires publicitaires, tels que les réseaux publicitaires et leurs applications éditeurs.

• Améliorer le ciblage de l’audience : Les plateformes publicitaires peuvent alors adapter des publicités et des offres personnalisées à des GAID spécifiques en fonction de leur appartenance à une audience personnalisée, et diffuser la publicité dès que le GAID devient disponible dans l’application de l’éditeur.  

• Attribution et mesure de l’audience personnalisée : L’engagement de l’utilisateur vis-à-vis des publicités de remarketing est communiqué à l’aide du GAID, qui est l’outil que les MMP utilisent pour leurs modèles d’attribution. Ces informations sont également transmises aux réseaux publicitaires et aux applications des éditeurs pour les aider à optimiser leur logique publicitaire en temps réel.

Maintenant que nous connaissons tous les tenants et les aboutissants du remarketing, voyons comment il fonctionne sans l’utilisation de GAID. 

Remarketing avec l’API Protected Audience

Grâce à l’API Protected Audience, le système d’exploitation Android facilitera l’échange d’informations entre les applications des annonceurs et des éditeurs, et les plateformes adtech buy side et sell side correspondantes. 

Au lieu de s’appuyer sur un identifiant partagé, comme c’est le cas aujourd’hui, les audiences seront créées sur l’appareil pour un ciblage personnalisé. De cette manière, toutes les données sont isolées sur l’appareil, sans qu’aucun tiers ne puisse y accéder.  

La séquence de remarketing dans le cadre de l’API Protected Audience sera la suivante :

• Segmentation personnalisée de l’audience : Les utilisateurs sont regroupés en audiences personnalisées en fonction de caractéristiques communes ou de l’utilisation de l’application. Chaque utilisateur est ajouté à l’audience sur l’appareil par l’application de l’annonceur elle-même via l’API Protected Audience d’Android. 

• Communication personnalisée avec l’audience : Lors de la création de l’audience, une plateforme publicitaire spécifique (telle qu’un réseau publicitaire DSP ou un SRN, comme Meta par exemple) est définie pour afficher des publicités à cette audience. Étant donné que l’appartenance à l’audience de l’appareil ne peut être communiquée en dehors de l’appareil, les processus de diffusion des publicités qui se déroulaient traditionnellement sur le serveur de la plateforme publicitaire seront désormais exécutés sur l’appareil lui-même.

Pour ce faire, l’application publicitaire doit prédéfinir les éléments suivants comme faisant partie de l’audience :

• Créations publicitaires : les publicités qu’ils ont l’intention de diffuser à l’audience sur d’autres applications. 
• Signaux d’enchère : facteurs importants pour déterminer une future enchère, tels que la localisation de l’utilisateur, son activité, son score LTV, etc. 
• Logique d’enchère : logique d’utilisation des différentes variables reçues de l’audience personnalisée et de l’application de l’éditeur pour déterminer une enchère en temps réel. Comme la logique elle-même ne se situe pas au niveau de l’utilisateur et qu’elle est soumise à des mises à jour en temps réel, elle est extraite d’un serveur de confiance situé du côté de la plateforme publicitaire.  
• Heure d’activation/d’expiration : l’heure à laquelle l’audience personnalisée doit être activée et l’heure à laquelle elle doit expirer.
• Par exemple, une application de shopping souhaite faire du remarketing auprès des utilisateurs qui ont acheté récemment afin de les inciter à effectuer leur prochain achat. 

Une fois que l’«utilisateur A» de l’application a effectué un achat, l’application appelle l’API Protected Audience d’Android pour joindre l’utilisateur A de l’application à l’audience personnalisée “Acheté au cours des 7 derniers jours”. 

L’audience personnalisée sur l’appareil comprendra le nom du réseau publicitaire où l’application d’achat a défini sa campagne publicitaire, les publicités de cette campagne, un score d’activité pour adapter une offre compétitive, un pointeur pour récupérer la logique d’enchère du réseau publicitaire en temps réel, et un délai d’expiration fixé à 7 jours à partir du moment de l’achat. 

• Améliorer le ciblage de l’audience : Lorsqu’une application d’éditeur demande à afficher une publicité, elle appelle l’API Protected Audience pour recevoir une publicité sélectionnée et une offre dérivée des audiences personnalisées définies sur l’appareil. Ici aussi, les éléments requis seront communiqués par l’application de l’éditeur et son partenaire du côté de la vente pour déterminer la publicité sélectionnée :
  • Signaux des vendeurs et des enchères publicitaires : facteurs importants pour déterminer l’annonce et l’enchère gagnantes, tels que le type d’application ou l’emplacement de l’annonce, ainsi que des informations contextuelles complètes. 
  • Logique de décision : logique d’évaluation d’une publicité basée sur les variables partagées par les acheteurs et les vendeurs.
  • Par exemple, une application d’actualités souhaite afficher une publicité dans sa section mode. Lorsque l’«utilisateur A» de l’application ouvre un article dans la section mode, l’application d’actualités appelle l’API Protected Audience pour vérifier s’il existe une publicité basée sur une audience personnalisée ciblée pour cet utilisateur de l’application. 

Cette demande de “sélection publicitaire” comprendra le réseau publicitaire vendeur/SSP par l’intermédiaire duquel l’action est effectuée, l’application requérante et l’application verticale, le format et les dimensions de l’annonce, la catégorie de contenu, ainsi qu’un pointeur permettant de récupérer la logique d’évaluation de l’annonce du vendeur en temps réel. Cette information est utilisée pour enchérir face à d’autres annonces ciblées ainsi que pour d’autres inventaires publicitaires.

Recevez les dernières infos marketing et les avis d’experts directement par mail

L’API Protected Audience répondra avec une publicité et une offre sélectionnée qui seront diffusées par l’application de l’éditeur.

• Attribution et mesure de l’audience personnalisée : Les impressions gagnantes seront communiquées aux acheteurs et aux vendeurs à des fins de mesure et d’optimisation. Cet élément est encore en cours de conception et nous communiquerons plus de détails au fur et à mesure de l’évolution de cette fonctionnalité.

Quel sera l’impact de l’API sur l’audience protégée ? 

Commençons par les défis déjà identifiés :

• Les utilisateurs ne peuvent être ajoutés aux audiences personnalisées que lorsqu’ils sont actifs : Contrairement au GAID, où les audiences peuvent être créées rétroactivement, l’API d’audience protégée exige que l’application soit active (c’est-à-dire ouverte, au premier plan de l’appareil) afin d’ajouter l’utilisateur à une audience. Pour ce faire, les développeurs d’applications devront :

• Définir une solide stratégie de ciblage personnalisé de l’audience tout au long du cycle de vie de l’utilisateur, étant donné que de nombreuses stratégies d’audience ne pouvaient être définies qu’à l’avance.

Par exemple, si un annonceur a l’intention de montrer à l’utilisateur une publicité de remarketing après 7 jours d’inactivité, il doit définir cette audience à l’avance chaque fois que l’utilisateur lance l’application (avec une heure d’activation fixée dans le futur), et supprimer l’utilisateur de l’audience au cas où il utiliserait l’application avant la période de 7 jours d’inactivité.

• Calculer rapidement le nombre de membres de l’audience : Le fait de disposer d’un délai limité pour ajouter l’utilisateur à une audience signifie que la segmentation de l’audience exige de la souplesse et de la rapidité. 
• Les détails du contrôle par l’utilisateur restent à définir : Les utilisateurs d’Android pourront contrôler les applications autorisées à les ajouter à des audiences personnalisées. Android n’a pas encore dévoilé tous les détails de cette approche. Cependant, au vu de son engagement pour la pérennité de l’écosystème, comme en témoignent les diverses initiatives du “Privacy Sandbox”, nous n’anticipons pas de taux de désabonnement qui pourraient perturber le marché.
• Les audiences personnalisées créées par les annonceurs doivent utiliser un SDK : Les équipes BI et CRM des annonceurs sont traditionnellement en mesure d’effectuer une segmentation personnalisée de l’audience de leur côté, puis de télécharger les audiences personnalisées vers les plateformes publicitaires manuellement à l’aide de fichiers CSV ou à l’aide d’intégrations API directes. 

Avec le passage à la gestion de l’audience sur l’appareil, les annonceurs devront soit mettre en place ces outils directement dans les SDK de leur application, soit utiliser des plates-formes ad tech désignées. En utilisant le SDK AppsFlyer, les annonceurs peuvent utiliser la plateforme AppsFlyer Audiences pour la gestion d’audiences personnalisées de la même manière qu’elle est utilisée aujourd’hui.

Pour examiner le flux généré par l’annonceur, veuillez consulter le diagramme ci-dessus.

• Les audiences personnalisées issues des plateformes publicitaires : Le GAID a permis aux annonceurs de déléguer la segmentation de l’audience aux plateformes publicitaires (par exemple, les DSP ou les réseaux publicitaires) sans être obligés de mettre en œuvre des SDK mobiles spécifiques dans leurs applications. En revanche, l’API Protected Audience nécessite un kit de développement logiciel (SDK) pour ajouter des utilisateurs à des audiences personnalisées, ce qui peut entraîner des frais techniques et opérationnels supplémentaires pour les annonceurs et les plateformes publicitaires. Pour combler cette lacune, AppsFlyer met en place des intégrations de partenaires qui permettront également de définir des audiences personnalisées – voir le graphique C pour plus d’informations. 

Découvrons ensemble quels sont les avantages uniques de ce système

• Protège la vie privée des utilisateurs : L’API Protected Audience constitue une avancée majeure en matière de protection de la vie privée des utilisateurs. Cette solution permet aux marques de personnaliser la communication avec leur public cible sans communiquer d’informations sur les utilisateurs à des tiers, dans le respect de la vie privée. L’API Protected Audience peut rendre accessible le remarketing pour de nombreuses entreprises qui hésitaient à le faire en raison de leur crainte de partager des informations sur les utilisateurs. Au-delà du remarketing, l’API Protected Audience constitue une avancée significative pour l’écosystème des applications et montre comment tirer parti de la technologie pour préserver la vie privée, sans compromettre l’expérience de l’utilisateur ou l’optimisation des campagnes publicitaires.
• Filtre des publicités lors de l’installation des applications: L’API Protected Audience comprend une fonction dédiée qui permet aux développeurs d’applications d’intégrer les appareils au filtre des publicités installées dans les applications. Grâce à cette logique de filtre, les plateformes publicitaires pourraient définir des campagnes d’UA pour exclure les utilisateurs d’applications existantes dans le cadre de leur sélection publicitaire, optimisant ainsi les coûts d’acquisition. 
• Signaux d’enchères des utilisateurs : L’API Protected Audience permet aux plateformes publicitaires d’effectuer une optimisation granulaire des enchères au niveau de l’appareil grâce à l’utilisation de signaux d’enchères de l’utilisateur qui sont ajoutés à chaque audience personnalisée. Cette fonctionnalité permet aux plateformes publicitaires d’optimiser leur logique d’enchères en l’enrichissant de détails supplémentaires dans le respect de la vie privée. Par exemple, les applications peuvent désormais prédéfinir une offre plus compétitive pour un utilisateur qui génère des revenus plus élevés. 

Que dois-je faire ensuite ?

Les implications de l’API “Protected Audience” et la réduction de notre dépendance aux identifiants d’appareils varient selon votre position dans l’écosystème publicitaire. Nous avons établi que le remarketing restera efficace grâce à l’API Protected Audience. Cependant, les stratégies à adopter diffèreront selon que vous soyez annonceur ou partenaire publicitaire.

L’approche d’un spécialiste du marketing

L’API Protected Audience introduit des changements technologiques massifs sur Android et, à ce titre, la formation est un élément essentiel d’une préparation réussie. Cela est nécessaire pour de nombreuses parties prenantes internes, notamment les équipes de marketing, de BI et de développement. Les annonceurs devront cartographier leur infrastructure et leurs stratégies de reciblage actuelles et s’assurer qu’elles s’adaptent au nouveau flux. En tant que partenaire de votre croissance, AppsFlyer est là pour vous aider à comprendre et à actualiser le potentiel des changements offerts par l’API de l’audience protégée.

Au-delà des équipes internes, les spécialistes du marketing devront s’assurer que leurs plateformes publicitaires et technologiques sont prêtes pour le changement. AppsFlyer développe des actifs technologiques et des partenariats à travers l’écosystème des applications pour aider à décupler votre croissance dans ce nouveau cadre. 

Se mettre à la place d’une plateforme publicitaire

Les plateformes publicitaires font face à de multiples changements qui vont nécessiter une adaptation. On assiste à un véritable bouleversement, avec un transfert massif des mécanismes du côté serveur vers l’appareil. Alors que les entités du côté de la vente, telles que les SSP et les SDK de monétisation, exigent déjà une présence sur l’appareil, les plateformes du côté de l’achat, telles que les réseaux publicitaires et les DSP, n’ont traditionnellement pas exigé de leurs annonceurs qu’ils mettent en œuvre un SDK mobile pour mener à bien leurs campagnes publicitaires. 

AppsFlyer coopère avec les plateformes publicitaires pour permettre un ciblage personnalisé de l’audience dans le cadre de l’API Protected Audience en utilisant le SDK AppsFlyer. Cela permettra de rationaliser la connectivité entre les annonceurs et les partenaires publicitaires, nécessaire à l’exécution de ces flux marketing critiques.

Connecter l’écosystème pour repenser le remarketing

En résumé, si le remarketing est en train de changer, il n’est en aucun cas en voie de disparition. Et c’est par la collaboration que nous pouvons favoriser le succès de cette stratégie, tout en veillant à ce qu’elle préserve la vie privée de l’utilisateur final. 

C’est cette vision qui a conduit AppsFlyer à coopérer étroitement avec Google, nos clients et nos partenaires publicitaires pour définir le cadre d’utilisation de l’API Audience protégée. J’espère qu’en tant que communauté, nous pourrons continuer à collaborer afin de faire progresser nos pratiques en matière de protection de la vie privée tout en augmentant la réussite et la fidélisation des entreprises.