Nouveautés dans AdAttributionKit

Bonjour à tous, je m’appelle Mike, ingénieur dans l’équipe d’ingénierie de l’App Store. Je vais vous présenter les nouveautés d’AdAttributionKit conçues pour les développeurs d’apps promues. Bonjour, je m’appelle Yuchi, ingénieure de l’équipe Commerce Engineering. Je vais vous présenter les options de configuration d’attribution et de réception de données pour les utilisateurs de postbacks.

Nous considérons chez Apple que la confidentialité est un droit humain essentiel. C’est pourquoi nous avons développé AdAttributionKit, qui permet aux annonceurs d’évaluer l’efficacité de leurs campagnes tout en respectant la confidentialité des utilisateurs. Je vais commencer par expliquer le fonctionnement d’AdAttributionKit. Un flux AdAttributionKit comporte trois parties différentes. Un réseau publicitaire se charge de créer et de diffuser du contenu publicitaire vers l’app d’un éditeur.

Celle-ci affiche ensuite une publicité pour promouvoir l’app. Enfin, l’app promue analyse l’engagement en mesurant les actions que les utilisateurs effectuent dans l’app. Chaque acteur intervient à un moment précis dans le processus complet d’AdAttributionKit.

Le processus complet débute lorsque le réseau publicitaire crée une charge utile pour une app. Le réseau publicitaire transmet la charge utile publicitaire à l’app éditrice, qui affiche alors une publicité à l’utilisateur.

L’utilisateur peut interagir avec la publicité en la regardant ou en la touchant, ce qui peut mener à une installation ou à un réengagement.

Une conversion d’installation a lieu quand une personne télécharge votre app depuis l’App Store ou une autre marketplace après avoir interagi avec une publicité.

Les conversions par réengagement se produisent lorsque quelqu’un s’intéresse à une publicité pour une app qu’il a déjà installée, ce qui lui permet d’accéder directement à l’app annoncée.

Une fois la conversion effectuée, l’annonceur mesure les interactions et l’engagement des utilisateurs au sein de son app. Une fois la période de conversion écoulée, les données de mesure des conversions et de l’engagement sont renvoyées au réseau publicitaire sous forme de postback. Voilà comment se déroule le processus d’AdAttributionKit. Pour rappel, AdAttributionKit a été lancé avec iOS 17.4 et prenait en charge les conversions d’installation. Nous avons ajouté la prise en charge du réengagement avec iOS 18. Pour découvrir AdAttributionKit, regardez notre séance WWDC24 « Meet AdAttributionKit ». Nous sommes heureux de vous présenter les nouveautés conçues pour améliorer les différentes étapes du processus.

Si vous êtes développeur, je vais vous présenter de nouvelles fonctions avancées de mesure et de test à implémenter dans votre app. Si vous êtes un réseau publicitaire ou utilisez des postbacks, Yuchi vous présentera les optimisations développées pour vos flux d’attribution et les nouvelles données intégrées aux postbacks.

Nous avons divisé cette présentation en quatre parties. Je vais d’abord parler des balises de conversion, qui vous permettent de mesurer les conversions de réengagement qui se chevauchent dans votre app.

Yuchi vous expliquera ensuite comment personnaliser les règles d’attribution pour votre app et présentera les nouvelles données géographiques intégrées aux postbacks.

Je terminerai en expliquant comment tester votre implémentation d’AdAttributionKit grâce aux nouvelles fonctions de test de l’app Réglages iOS.

Voyons comment mesurer les fenêtres de conversion qui se chevauchent.

Examinons le flux de réengagement dans notre schéma.

Jusqu’à iOS 18.3, une seule conversion de réengagement peut être active simultanément par app.

À partir d’iOS 18.4, votre app peut gérer plusieurs fenêtres de conversion de réengagement simultanément. Votre app peut obtenir des balises de conversion, qui fonctionnent comme un signet pour une conversion. Vous pouvez utiliser des balises de conversion pour définir la conversion de réengagement à modifier. Examinons un scénario dans lequel vous utilisez des balises de conversion dans votre app. En tant que développeur, vous pouvez lancer plusieurs campagnes de réengagement pour promouvoir les différentes ventes que vous proposez aux clients dans votre app.

Un client peut voir une publicité promouvant un produit à prix réduit dans votre app et décider de la toucher. Cette interaction le reliera profondément à votre app et créera une conversion de réengagement dans le système. Au bout de quelques minutes, il quitte votre app acheter l’article. Quelques heures plus tard, le même client voit une autre publicité présentant un deuxième article en promotion dans votre app et la touche. Cette opération crée une autre conversion de réengagement dans le système. Au bout du compte, il change d’avis et achète le premier article en promotion. Grâce aux balises de conversion, vous pouvez mettre à jour la valeur de conversion pour la conversion originale correspondant à la remise 1. Cette fonction est très utile si vous lancez simultanément des campagnes de réengagement pour différents produits de votre app. Pour mesurer les fenêtres de conversion qui se chevauchent, définissez la clé EligibleForAdAttributionKitOverlappingConversions sur YES dans le fichier Info.plist de votre app. Sinon, les conversions précédentes continueront à se bloquer mutuellement quand elles se chevauchent, comme auparavant. Ensuite, je vais vous montrer comment votre app peut obtenir des balises de conversion.

Une fois que votre app a activé cette option, les balises de conversion seront intégrées à l’URL de réengagement qu’AdAttributionKit transmet à votre app lors d’un réengagement. Les URL de réengagement sont des liens universels qui sont transmis aux API lorsqu’une publicité avec rendu personnalisé ou rendu StoreKit s’affiche à l’écran. La balise est fournie comme valeur du paramètre de réengagement ouvert d’AdAttributionKit. Dans cet exemple d’URL, la balise est égale à 1.

Quand votre app reçoit une URL de réengagement, vous pouvez extraire la balise de conversion en utilisant une fonction comme celle-ci. Je vais décomposer ce qui se passe ici. D’abord, la fonction récupère les composants de l’URL transmise en utilisant URLComponents. Ensuite, elle obtient la liste des éléments de la requête. AdAttributionKit ajoute systématiquement un paramètre de réengagement ouvert lorsque l’app s’ouvre après un réengagement.

Il examine alors la liste des paramètres de requête associés à l’URL. S’il trouve le paramètre ouvert de réengagement dans l’URL, il renvoie immédiatement la valeur de ce paramètre. S’il ne parvient pas à trouver le paramètre de requête, la fonction retournera nil.

Vous avez donc une balise de conversion dans votre app que vous pouvez utiliser pour mettre à jour cette conversion directement.

Nous recommandons d’associer les balises de conversion à la conversion de réengagement qui les a générées, afin de pouvoir relier les événements significatifs qui découlent de cette conversion.

Vous devez également conserver la balise de conversion soit localement dans votre app, soit dans une base de données côté serveur.

Lorsqu’un client effectue une action dans votre app et que vous voulez mesurer cette conversion, récupérez la balise qui correspond à cette conversion.

Voyons comment utiliser une balise de conversion pour mettre à jour directement une conversion dans le code.

Cette fonction utilise une valeur de conversion dans la balise de conversion pour mettre à jour un postback spécifique. Lors de l’initialisation d’une structure PostbackUpdate, transmettez la balise de la conversion que vous souhaitez mettre à jour. Vous pouvez ensuite appeler l’API Postback pour mettre à jour la valeur de conversion.

Vous pouvez également appeler l’API updateConversionValue sans balise de conversion, et le système mettra à jour les postbacks des conversions les plus récentes. Voilà comment utiliser les balises de conversion pour mettre à jour les postbacks lorsque les fenêtres de conversion se chevauchent. La mesure des valeurs de conversion pour les postbacks n’est qu’un élément du puzzle quand vous utilisez AdAttributionKit. L’interprétation des données postback reçues en aval est un aspect clé du système et peut guider les décisions marketing pour l’activité de votre app. Yuchi, as-tu des nouveautés à partager dans ce domaine ? Bien sûr. Voici de nouvelles fonctionnalités pour mieux utiliser et interpréter les données postback que vous recevez. Pour capturer les signaux les plus pertinents dans vos données postback, nous avons ajouté la possibilité de personnaliser les règles d’attribution de votre app, ce qui vous permet d’ajuster votre flux d’attribution

Vous pouvez ajuster votre flux d’attribution de deux manières. La première est la fenêtre d’attribution configurable.

En reprenant le flux d’attribution publicitaire complet, AdAttributionKit effectue une attribution basée sur l’ancienneté et le type de publicité.

AdAttributionKit prend en charge les annonces par clic et par vue.

Les différents types d’annonces ciblent généralement un horizon temporel différent. Par exemple, une annonce par clic peut viser à obtenir des conversions dans les 10 jours. Lorsqu’une conversion se produit après la période ciblée, comme 20 jours après l’heure d’affichage de l’impression, cette conversion ne doit plus être considérée comme étant due à cette annonce. Cette période de ciblage publicitaire est ce que nous appelons la fenêtre d’attribution. Elle est définie comme la période commençant à l’heure d’affichage de l’annonce jusqu’à la dernière heure à laquelle cette annonce peut encore être prise en compte pour l’attribution. Si la conversion se produit pendant la période d’attribution, l’annonce pourra prétendre à l’attribution de cette conversion. Sinon, elle ne pourra pas y prétendre. Avant, seules les annonces cliquées datant de moins de 30 jours et celles consultées depuis moins d’un jour étaient considérées pour l’attribution. Nous avons souhaité vous offrir plus de flexibilité pour cette période, c’est pourquoi nous mettons en place une fenêtre d’attribution ajustable. En tant qu’annonceur, vous pouvez spécifier la longueur de la fenêtre d’attribution souhaitée dans le fichier Info.plist. Cet exemple utilise un fichier JSON pour illustrer les configurations, mais les mêmes clés et la même structure peuvent être utilisées lors de l’édition du fichier Info.plist de votre app. La fenêtre d’attribution peut être définie sur la base d’un réseau publicitaire et d’un type d’interaction publicitaire, c’est-à-dire les annonces par vue et par clic. Voici un exemple. Pour le réseau publicitaire com.example.adNetwork, l’annonceur a spécifié une fenêtre d’attribution de deux jours pour les annonces par clic et d’un jour pour les annonces par vue. Si un partenaire d’un réseau publicitaire se concentre principalement sur un type d’annonce, vous pouvez choisir d’ignorer complètement les autres types d’annonces de ce réseau. Pour ce faire, spécifiez la clé ignoreInteractionType. Cette clé peut être définie sur « view » ou « click », mais pas les deux simultanément. Si vous utilisez plusieurs réseaux publicitaires, spécifier la longueur de la fenêtre d’attribution pour chacun d’entre eux peut représenter un travail considérable. Vous pouvez alors spécifier une longueur de fenêtre pour tous les réseaux publicitaires que vous utilisez en ajoutant la clé globale, qui s’applique par défaut à tous les réseaux publicitaires. Outre la longueur de la fenêtre globale, vous pouvez également configurer la longueur de la fenêtre d’attribution pour des réseaux publicitaires spécifiques, ce qui aura la priorité sur la configuration globale. Si aucun réseau publicitaire ou aucune configuration globale n’est trouvé, nous reviendrons à la longueur de la fenêtre d’attribution par défaut utilisée aujourd’hui. Dans cet exemple, la fenêtre d’attribution pour les annonces au clic provenant du réseau publicitaire com.example.adNetwork sera de cinq jours, et les annonces par vue provenant de ce réseau seront ignorées. Pour tous les autres réseaux, la fenêtre d’attribution pour les annonces par vue sera de trois jours. Notez que le concept de fenêtre d’attribution s’applique uniquement aux annonces d’installation, et non aux annonces de réengagement. En effet, les interactions publicitaires de réengagement et les conversions se produisent immédiatement, sans intervalle entre elles. La deuxième méthode pour ajuster votre flux d’attribution consiste à configurer le délai d’attente. Et à réexaminer le flux d’attribution des annonces. Concentrons-nous sur la mesure de l’engagement des utilisateurs après une conversion générée par une annonce. Après la diffusion d’une annonce par le réseau et la conversion, la fenêtre permettant de mesurer l’engagement s’ouvre. Nous appelons cette fenêtre la fenêtre de conversion. Les annonceurs peuvent mesurer la valeur de la conversion en fonction des activités effectuées par les utilisateurs dans leur app, comme un abonnement et un achat intégré, en invoquant l’API updateConversionValue. En réalité, un grand nombre de ces attributions publicitaires peuvent se produire simultanément pour la même app promue sur le même appareil. Les fenêtres de conversion peuvent aussi se chevaucher, ce qui peut entraîner l’enregistrement d’une mesure dans une conversion moins appropriée.

Prenons un exemple plus concret. Un utilisateur a cliqué sur une annonce et téléchargé l’app promue, puis a effectué un achat intégré peu après, ce qui a entraîné une mesure de valeur utilisateur élevée pour l’annonce d’installation. Mais imaginez qu’immédiatement après avoir installé l’app, cette même personne clique sur une annonce de réengagement et ouvre l’app. L’achat intégré qui aurait dû être attribué à l’annonce d’installation sera attribué à l’annonce de réengagement. Il se peut que cet objectif de mesure ne soit pas le vôtre.

Le même scénario peut se produire pour une annonce de réengagement qui suit de près une autre conversion de réengagement. Ce qui aurait été attribué à la première annonce de réengagement sera désormais attribué à la deuxième annonce de réengagement. Pour éviter cela, vous pouvez définir une période après chaque conversion afin de bloquer les autres signaux et utiliser cette période uniquement pour mesurer la valeur des annonces qui ont généré la conversion en question. C’est ce que nous appelons le délai d’attribution configurable. Ce délai peut être spécifié pour chaque type de conversion. Ce délai commencera à partir de chaque conversion de ce type spécifique, et toutes les autres conversions qui se sont produites avant que le délai ne soit complètement écoulé ne seront pas attribuées à une conversion. En tant qu’annonceur, vous pouvez spécifier le délai d’attribution souhaité dans le fichier Info.plist. Dans cet exemple, un annonceur a spécifié un délai de 6 heures pour l’installation et d’une heure pour le réengagement. Avec cette configuration, supposons qu’un utilisateur ait cliqué sur l’annonce d’installation, puis ait installé une app à l’instant T. Et le délai configuré pour l’installation est de 6 heures. Si la même personne clique sur l’annonce et ouvre l’app 4 heures après l’installation, cette conversion de réengagement ne sera pas attribuée à l’annonce. Si, par exemple, le clic publicitaire de réengagement et l’ouverture de l’app ont eu lieu 7 heures après l’installation, le réengagement recevra une attribution publicitaire. Pour la fenêtre d’attribution configurable et le délai d’attribution, le format JWS restera inchangé pour les impressions et les postbacks. Outre ces fonctionnalités configurables, nous avons ajouté de nouvelles données géographiques dans les postbacks pour vous aider à évaluer le succès de vos campagnes publicitaires par pays.

Revenons au flux d’attribution publicitaire. Concentrons-nous à présent sur les postbacks.

Les postbacks sont les sorties d’AdAttributionKit qui transmettent des informations sur la conversion, telles que l’attribution et la mesure de l’engagement des utilisateurs. Ils sont transmis aux réseaux publicitaires et aux développeurs des apps promues par publicité. Les annonceurs et les réseaux publicitaires souhaitent accéder aux données géographiques des conversions afin d’optimiser la diffusion des annonces. Aujourd’hui, certaines implémentations s’appuient sur l’identifiant de la source pour obtenir cette information. Avec la dernière version d’AdAttributionKit, le code pays est fourni dans un nouveau champ du postback. Voici ce que représente le code pays dans différents contextes.

Pour les apps de l’App Store, le code pays du postback vient de la vitrine où l’app a été téléchargée, conformément à la localisation des paramètres du compte utilisateur. Pour la conversion de réengagement, les postbacks utilisent le même emplacement que lors de l’installation initiale de l’app. Avec iOS 17.4, les marketplaces d’apps alternatives peuvent fournir un jeton de vérification d’installation pour communiquer un signal d’installation d’app à un appareil Apple. Le jeton de vérification de l’installation est un jeton JWS dont la charge utile contient des informations sur l’installation de l’app, telles que l’horodatage du téléchargement et l’ID de l’app téléchargée. Désormais, les marketplaces d’apps alternatives fournissent un nouveau champ pour le code pays dans la charge utile du jeton de vérification d’installation. Signez-le et envoyez-le à Apple. Apple validera ensuite la valeur et renseignera le champ du code du pays de postback avec le code. Le code pays est un champ facultatif dans le jeton de vérification de l’installation. Si le système ne trouve pas de code du pays dans le jeton de vérification de l’installation, le postback n’aura aucun code pays.

La valeur du code pays pour la conversion via d’autres marketplaces d’apps est limitée aux emplacements où ces marketplaces sont prises en charge.

C’est ainsi que le code pays sera ajouté au postback. Le code pays sera un champ non signé, parallèle au type d’interaction publicitaire, au jeton JWS signé et à la valeur de conversion grossière. Le champ du code pays est soumis à l’algorithme d’anonymat qu’AdAttributionKit applique à tous les postbacks. L’algorithme d’anonymisation est au cœur de notre système d’attribution publicitaire respectueux de la vie privée, qui garantit que chaque individu reste unique au sein d’une grande foule avant que des informations identifiables ne soient transmises à l’annonceur et au réseau publicitaire.

Les postbacks ne contiendront le code pays que si le volume de conversions similaires dans le même pays est suffisant. Le niveau d’anonymat qui permet d’indiquer le code pays dans le postback sera un niveau supplémentaire qui s’ajoutera aux quatre niveaux que nous appliquons déjà. Cela signifie que les annonceurs et les réseaux publicitaires ne perdront jamais les données qu’ils reçoivent actuellement. Voilà pour les nouveautés sur les données postback. Mike va maintenant aborder la testabilité d’AdAttributionKit. Merci Yuchi pour toutes ces informations. Maintenant que nous avons couvert toutes les nouveautés d’AdAttributionKit, je vais vous montrer comment tester votre implémentation.

Revenons à notre schéma et concentrons-nous sur la diffusion des annonces et le flux de conversion.

C’est un flux type pour tester l’implémentation d’AdAttributionKit pour votre app.

Tout d’abord, vous devez créer et diffuser une charge utile publicitaire pour votre app. Vous affichez une annonce et interagissez avec celle-ci dans une autre app, puis vous effectuez une conversion d’installation ou de réengagement pour créer des postbacks de développement pour votre app.

Dans iOS 18.4, vous pouvez créer des postbacks de développement pour votre app directement dans les Réglages iOS.

Les postbacks créés à partir des paramètres du développeur permettent de tester de nouvelles méthodes. Vous pouvez tester la mise à jour des valeurs de conversion si votre app a été exécutée à partir de Xcode ou d’autres mécanismes de distribution, comme une distribution ad hoc. Vous avez aussi un contrôle direct sur les données que vos postbacks contiendront. Cela peut être utile pour tester l’implémentation de votre serveur pour le traitement de différents niveaux de données postbacks.

Voici comment utiliser les paramètres du développeur pour créer des postbacks pour votre app.

Vous devez d’abord vérifier que le mode développeur est activé sur votre appareil. Ensuite, accédez aux paramètres du développeur dans Réglages.

Dans les paramètres du développeur, faites défiler vers le bas jusqu’à la section Ad Attribution Testing. Nous avons ajouté une nouvelle page nommée Development Postbacks au-dessus d’AdAttributionKit Developer Mode.

La page Development Postbacks permet de configurer les postbacks pour votre app, transmettre tous les postbacks éligibles ou effacer tous les postbacks de développement de votre appareil. Pour configurer les postbacks de développement, saisissez l’identifiant du bundle de votre app et touchez le bouton Configurer.

L’app doit être installée sur votre appareil au préalable pour pouvoir créer des postbacks.

La première étape consiste à spécifier une destination pour votre postback. Il s’agit de l’URL de votre serveur. Mieux vaut utiliser une URL de développement lors des tests, différente de l’URL où vous recevez les postbacks de production. Vous pouvez également récupérer automatiquement l’URL de copie de postback de votre app. Vous pouvez l’utiliser pour confirmer que l’URL générée par le système correspond à l’URL exposée par votre serveur.

Ensuite, renseignez les propriétés de votre postback. Configurez le postback pour qu’il représente n’importe quel type de conversion en modifiant les propriétés.

iOS permet maintenant de configurer le code pays en tant que nouvelle propriété. Vous pourrez ainsi tester le code pays dans les postbacks, comme l’a évoqué Yuchi.

Après avoir configuré les propriétés, vous pouvez ajuster la granularité des données de chaque postback individuel. Cela permet de contrôler la quantité d’informations envoyées à votre serveur. Vous pouvez ainsi vérifier que l’implémentation de votre serveur traite correctement les différents niveaux de données postback.

Une fois la configuration terminée, touchez le bouton pour les créer pour votre app.

Maintenant que votre app a des postbacks de développement, mettez à jour les valeurs de conversion.

Lors des tests, appelez l’API updateConversionValue(_:) pour mettre à jour les postbacks de développement. Vous pouvez attendre que les postbacks soient envoyés automatiquement ou toucher le bouton Transmettre les postbacks quand votre fenêtre de conversion des postbacks se ferme.

Les postbacks créés dans les paramètres du développeur sont différents de ceux créés dans les flux de bout en bout. Je vais vous montrer les changements figurant dans la signature web JSON de votre postback.

Voici un extrait de l’en-tête reçu dans votre postback.

Les postbacks créés à partir des paramètres du développeur sont signés avec une nouvelle clé, indiquée par la valeur kid. Consultez la documentation sur la vérification des postbacks pour obtenir la nouvelle clé publique permettant de valider la signature de ces postbacks. La charge utile du postback présente elle aussi quelques différences notables. Ad-network-identifier sera toujours défini sur development.adattributionkit. Cela permet de mieux distinguer les postbacks créés dans les paramètres du développeur des postbacks de production.

L’Advertised-item-identifier dans le postback peut également être à zéro, par exemple, si vous avez exécuté votre app à partir de Xcode pour un test.

C’est tout pour les nouvelles fonctionnalités de testabilité que nous avons ajoutées à AdAttributionKit. Nous pensons que cette nouvelle testabilité vous aidera à rationaliser votre flux de travail de développement et de test pour l’implémentation d’AdAttributionKit. Nous avons abordé de nombreux aspects des nouvelles fonctionnalités d’AdAttributionKit aujourd’hui. De la mesure des fenêtres de conversion qui se chevauchent dans votre app à la réception des codes pays et des postbacks, ces mises à jour ont un impact sur divers éléments de l’attribution des annonces.

Prochaines étapes : si vous êtes prêt à configurer des règles d’attribution pour votre app, ajoutez les nouvelles clés de configuration au fichier Info.plist de votre app. Commencez à utiliser la nouvelle fonctionnalité de testabilité pour tester votre implémentation d’AdAttributionKit plus tôt dans votre cycle de développement, avant la mise en production. Si vous utilisez SKAdNetwork, c’est le moment idéal pour migrer vers AdAttributionKit et commencer à utiliser toutes ces nouveautés. Nous tenons à remercier la communauté des développeurs qui nous font part de leur feedback sur leur expérience avec nos frameworks publicitaires axés sur la confidentialité. Votre feedback nous aide à améliorer nos produits et à offrir une expérience publicitaire exceptionnelle pour votre app, tout en préservant la confidentialité des utilisateurs. Merci !