Comprendre les clés d'agrégation pour Attribution Reporting

Découvrez ce que sont les clés d'agrégation, comment elles sont utilisées dans l'Attribution Reporting API et comment vous pouvez traduire des objectifs en clés.

En tant qu'entreprise de technologie publicitaire diffusant des campagnes dans plusieurs zones géographiques pour différentes catégories de produits, vous souhaitez aider les annonceurs à répondre aux questions suivantes :

1. Combien d'achats de chaque catégorie de produits ont été générés par chacune de mes campagnes dans chaque région géographique ?
2. Combien de revenus chaque catégorie de produits a-t-elle générés pour chacune de mes campagnes dans chaque région géographique ?

De nombreuses entreprises de technologie publicitaire encouragent les annonceurs à configurer différents types de conversions. Toutefois, il est préférable de se concentrer sur les conversions les plus importantes, comme les achats, pour vérifier que les résultats récapitulatifs sont détaillés et précis pour ces événements importants.

Pour ce faire, vous devez réfléchir aux questions auxquelles vous souhaitez répondre avant de collecter les données.

Dimensions, clés et valeurs

Pour répondre à ces questions, examinons les dimensions, les clés et les valeurs.

Dimensions

Pour comprendre comment vos campagnes génèrent des revenus, comme décrit ici, vous devez suivre les dimensions suivantes :

• ID de la campagne publicitaire : identifiant de la campagne spécifique.
• ID de zone géographique : région géographique où l'annonce a été diffusée.
• Catégorie de produit : type de produit tel que vous l'avez défini.

Alors que les dimensions "ID de campagne" et "ID de zone géographique" sont connues au moment de la diffusion de l'annonce (temps de diffusion), la catégorie de produit sera connue à partir d'un événement déclencheur, lorsque l'utilisateur effectue une conversion (temps de conversion).

Les dimensions que vous souhaitez suivre pour cet exemple sont celles indiquées dans l'image suivante :

Que sont les clés d'agrégation (buckets) ?

Les termes "clé d'agrégation" et "bucket" font référence à la même chose. La clé d'agrégation est utilisée dans les API du navigateur pour configurer les rapports. Le terme bucket est utilisé dans les rapports agrégables et récapitulatifs, ainsi que dans les API du service d'agrégation.

Une clé d'agrégation (ou clé) est un élément de données qui représente les valeurs des dimensions suivies. Les données sont ensuite agrégées selon chaque clé d'agrégation.

Par exemple, supposons que vous suiviez les dimensions "Catégorie de produit", "ID de zone géographique" et "ID de campagne".

Lorsqu'un utilisateur situé dans la zone géographique 7 voit une annonce pour la campagne 12, puis effectue une conversion en achetant un produit de la catégorie 25, vous pouvez définir une clé d'agrégation semblable à celle de l'image suivante :

Vous verrez plus tard qu'une clé d'agrégation ne ressemble pas exactement à cela en pratique, mais pour l'instant, concentrons-nous sur les informations qu'elle contient.

Que sont les valeurs agrégables ?

Pour répondre à vos questions sur les dimensions que nous avons décrites, vous devez savoir :

• Nombre d'achats. Une fois agrégées et disponibles dans un rapport récapitulatif, il s'agit du nombre total d'achats (valeur récapitulative).
• Revenu généré par chaque achat (valeur de l'achat). Une fois agrégées et disponibles dans un rapport récapitulatif, il s'agit des revenus totaux (valeur récapitulative).

Chacune de ces valeurs (le nombre d'achats pour une conversion et la valeur d'achat pour une conversion) est une valeur agrégable. Vous pouvez considérer les valeurs agrégables comme les valeurs de vos objectifs de mesure.

Lorsqu'un utilisateur situé dans la zone géographique 7 voit une annonce pour la campagne 12, puis effectue une conversion en achetant un produit de la catégorie 25 pour 120 $ (en supposant que votre devise soit l'USD), vous pouvez définir une clé d'agrégation et des valeurs agrégables comme celles-ci :

Les valeurs agrégables sont additionnées par clé pour de nombreux utilisateurs afin de générer des insights agrégés, sous la forme de valeurs récapitulatives dans les rapports récapitulatifs.

Les valeurs agrégables sont additionnées pour générer des insights agrégés pour vos objectifs de mesure.

Notez que ce diagramme omet le déchiffrement et représente un exemple simplifié sans bruit appliqué. Dans la section suivante, nous allons présenter cet exemple avec du bruit.

Des clés et valeurs aux rapports

Voyons maintenant comment les clés et les valeurs agrégables sont liées aux rapports.

Rapports agrégables

Lorsqu'un utilisateur clique sur une annonce ou la voit, puis effectue une conversion, vous demandez au navigateur de stocker une paire {clé d'agrégation, valeur agrégable}.

Dans notre exemple, lorsqu'un utilisateur clique sur une annonce ou la voit, puis effectue une conversion, vous demandez au navigateur de générer deux contributions (une par objectif de mesure).

Vous verrez plus tard qu'un rapport agrégable {clé d'agrégation, valeur agrégable} ne ressemble pas exactement à cela, mais pour l'instant, concentrons-nous sur les informations qu'il contient.

Lorsque vous demandez au navigateur de générer deux contributions, il génère un rapport agrégable (s'il peut associer la conversion à une vue ou un clic précédents).

Un rapport agrégable contient les éléments suivants :

• La ou les contributions que vous avez configurées.
• Métadonnées sur l'événement de clic ou de vue et l'événement de conversion : site sur lequel la conversion a eu lieu, etc. Afficher tous les champs d'un rapport agrégable

Les rapports agrégables sont au format JSON et incluent, entre autres, un champ de charge utile qui sera utilisé comme entrée de données pour le rapport récapitulatif final.

La charge utile contient une liste de contributions, chacune étant une paire {clé d'agrégation, valeur agrégable} :

• bucket : clé d'agrégation, encodée sous forme de bytestring.
• value : valeur agrégable pour cet objectif de mesure, encodée sous forme de bytestring.

Exemple :

{
  "data": [
    {
      "bucket": "111001001",
      "value": "11111010000",
    }
  ],
  "operation": "histogram"
}

En pratique, les rapports agrégables sont encodés de manière à ce que les buckets et les valeurs soient différents de ceux de l'exemple précédent (c'est-à-dire qu'un bucket peut ressembler à \u0000\u0000\x80\u0000). Bucket et value sont tous deux des bytestrings.

Rapports récapitulatifs

Les rapports agrégables sont agrégés sur plusieurs navigateurs et appareils (utilisateurs) comme suit :

• Une technologie publicitaire demande des rapports récapitulatifs pour un ensemble de clés et un ensemble de rapports agrégables donnés provenant de nombreux navigateurs (utilisateurs) différents.
• Les rapports agrégables sont déchiffrés par le service d'agrégation.
• Pour chaque clé, les valeurs agrégables des rapports agrégables sont additionnées.
• Du bruit est ajouté à la valeur récapitulative.

Le résultat est un rapport récapitulatif contenant un ensemble de paires {clé d'agrégation, valeur récapitulative}.

Un rapport récapitulatif contient un ensemble de paires clé/valeur de type dictionnaire JSON. Chaque paire contient :

• bucket : clé d'agrégation, encodée sous forme de bytestring.
• value : valeur récapitulative décimale pour un objectif de mesure donné, cumulée à partir de tous les rapports agrégables disponibles, avec un niveau de bruit supplémentaire.

Exemple :

[
  {"bucket": "111001001", "value": "2558500"},
  {"bucket": "111101001", "value": "3256211"},
  {...}
]

En pratique, les rapports récapitulatifs sont encodés de manière à ce que les buckets et les valeurs soient différents de ceux indiqués dans l'exemple (par exemple, un bucket peut ressembler à \u0000\u0000\x80\u0000). Bucket et valeur sont tous deux des bytestrings.

Clés d'agrégation en pratique

Les clés d'agrégation (buckets) sont définies par une entreprise de technologie publicitaire, généralement en deux étapes : lorsqu'un utilisateur clique sur une annonce ou la voit, et lorsqu'il effectue une conversion.

Structure des clés

Nous utiliserons le terme structure de clé pour désigner l'ensemble des dimensions encodées dans une clé.

Par exemple, "ID de campagne" × "ID géographique" × "Catégorie de produit" est une structure clé.

Types de clés

Les valeurs agrégables sont additionnées pour une clé donnée sur plusieurs utilisateurs/navigateurs. Toutefois, nous avons constaté que les valeurs agrégables peuvent suivre différents objectifs de mesure, comme la valeur ou le nombre d'achats. Vous souhaitez vérifier que le service d'agrégation additionne les valeurs agrégables du même type.

Pour ce faire, dans chaque clé, encodez une partie des données qui vous indique ce que représente la valeur récapitulative (l'objectif de mesure auquel cette clé fait référence). Pour ce faire, vous pouvez créer une dimension supplémentaire pour votre clé, qui représente le type d'objectif de mesure.

En reprenant notre exemple précédent, ce type d'objectif de mesure aurait deux valeurs possibles :

• Le nombre d'achats est le premier type d'objectif de mesure.
• La valeur d'achat est le deuxième type d'objectif de mesure.

Si vous aviez n objectifs de mesure, le type d'objectif de mesure aurait n types de valeurs différents.

Vous pouvez considérer les dimensions d'une clé comme une métrique. Par exemple, "le nombre d'achats d'un certain produit par campagne et par zone géographique".

Taille de clé, taille de la dimension

La taille maximale de la clé est définie en bits (nombre de zéros et de uns en binaire pour créer la clé complète). L'API autorise une longueur de clé de 128 bits.

Cette taille permet d'obtenir des clés très précises, mais plus les clés sont précises, plus les valeurs risquent d'être bruyantes. Pour en savoir plus sur le bruit, consultez Comprendre le bruit.

Comme indiqué précédemment, les dimensions sont encodées dans la clé d'agrégation. Chaque dimension a une certaine cardinalité, c'est-à-dire le nombre de valeurs distinctes que la dimension peut prendre. En fonction de sa cardinalité, chaque dimension doit être représentée par un certain nombre de bits. Avec n bits, il est possible d'exprimer 2ⁿ options distinctes.

Par exemple, la dimension "Pays" peut avoir une cardinalité de 200, car il existe environ 200 pays dans le monde. Combien de bits sont nécessaires pour encoder cette dimension ?

7 bits ne permettraient de stocker que 2⁷ = 128 options distinctes, ce qui est inférieur aux 200 options nécessaires.

8 bits permettent de stocker 2⁸ = 256 options distinctes, ce qui est supérieur aux 200 options nécessaires. Vous pouvez donc utiliser n=8 bits pour encoder cette dimension.

Encodage des clés

Lorsque vous définissez des clés dans le navigateur, elles doivent être encodées au format hexadécimal. Dans les rapports récapitulatifs, les clés apparaissent au format binaire (et sont appelées "buckets").

Définir deux éléments clés pour une clé complète

Supposons que vous utilisiez une clé pour suivre les dimensions suivantes :

• ID de la campagne
• ID de la zone géographique
• Catégorie de produits

Alors que les dimensions "ID de campagne" et "ID de zone géographique" sont connues au moment de la diffusion de l'annonce (temps de diffusion), la catégorie de produit sera connue à partir d'un événement déclencheur, lorsque l'utilisateur effectue une conversion (temps de conversion).

En pratique, cela signifie que vous définirez une clé en deux étapes :

1. Vous définissez une partie de la clé (ID de campagne × ID de zone géographique) au moment du clic ou de la vue.
2. Vous définirez la deuxième partie de la clé (catégorie de produits) au moment de la conversion.

Ces différentes parties des clés sont appelées "pièces clés".

Une clé est calculée en effectuant un OR (v) de ses éléments de clé.

Exemple :

• Élément clé côté source : 0x159
• Clé de déclencheur = 0x400
• Clé = 0x159 v 0x400 = 0x559

Aligner les éléments clés

Avec deux clés de 64 bits étendues à 128 bits à l'aide de remplissages ou de décalages de 64 bits soigneusement placés (les seize zéros), l'opération OR sur les clés équivaut à les concaténer, ce qui est plus facile à comprendre et à vérifier :

• Élément clé côté source : 0xa7e297e7c8c8d0540000000000000000
• Clé de déclencheur = 0x0000000000000000674fbe308a597271
• Clé = 0xa7e297e7c8c8d0540000000000000000 v 0x0000000000000000674fbe308a597271 = 0xa7e297e7c8c8d054674fbe308a597271

Plusieurs clés par clic ou vue d'annonce

En pratique, vous pouvez définir plusieurs clés par événement de source d'attribution (clic ou vue d'annonce). Par exemple, vous pouvez définir :

• Clé permettant de suivre l'ID de zone géographique × l'ID de campagne.
• Autre clé permettant de suivre le type de création × l'ID de campagne.

Consultez la stratégie B pour en voir un autre exemple.

Encoder des dimensions dans des clés

Lorsque vous demandez des rapports récapitulatifs, vous devez indiquer au service d'agrégation les métriques auxquelles vous souhaitez accéder en demandant des rapports récapitulatifs pour un certain ensemble de clés d'agrégation.

Les rapports récapitulatifs contiennent des paires {clé, valeur récapitulative} brutes, sans aucune information supplémentaire sur la clé. Par conséquent :

• Lorsque vous définissez des clés au moment où l'utilisateur voit ou clique sur une annonce, puis effectue une conversion, vous devez définir ces clés de manière fiable en fonction des valeurs des dimensions qu'elles représentent.
• Lorsque vous définissez les clés pour lesquelles vous souhaitez demander des rapports récapitulatifs, vous devez générer ou accéder de manière fiable et à la volée aux mêmes clés que celles définies lorsque l'utilisateur a vu ou cliqué sur une annonce et effectué une conversion. Pour cela, vous devez vous baser sur les valeurs des dimensions pour lesquelles vous souhaitez afficher des données agrégées.

Encodage des dimensions à l'aide de mappages de structure de clés

Pour encoder des dimensions dans des clés, vous pouvez créer et gérer une carte de structure de clé à l'avance, lorsque vous définissez vos clés (avant la diffusion des annonces).

Une carte de la structure des clés représente chacune de vos dimensions et leur position dans la clé.

En pratique, la création et la gestion de cartes de structure clés impliquent l'implémentation et la gestion de la logique du décodeur. Si vous recherchez une méthode qui ne nécessite pas cette étape, envisagez d'utiliser une approche basée sur le hachage.

Exemple :

Imaginons que vous prévoyez de suivre les achats et les valeurs d'achat pour des campagnes, des régions géographiques et des produits spécifiques.

La catégorie de produit, l'ID de zone géographique et l'ID de campagne doivent être des dimensions dans vos clés. De plus, comme vous souhaitez suivre deux objectifs de mesure différents (le nombre d'achats et la valeur des achats), vous devez ajouter une dimension à votre clé qui suit le type de clé. Cela vous permettra de définir ce que représente réellement la valeur agrégable lorsque vous recevez des paires {clé, valeur agrégable} dans les rapports récapitulatifs.

Avec ces objectifs de mesure, votre clé présente les dimensions suivantes :

• Catégorie de produits
• Type d'objectif de mesure
• ID de la zone géographique
• ID de la campagne

Maintenant, examinons chaque dimension. Supposons que, pour votre cas d'utilisation, vous deviez suivre les éléments suivants :

• 29 catégories de produits différentes.
• 8 régions géographiques différentes : Amérique du Nord, Amérique centrale, Amérique du Sud, Europe, Afrique, Asie, Caraïbes et Océanie.
• 16 campagnes différentes.

Voici le nombre de bits dont vous auriez besoin pour encoder chaque dimension de votre clé :

• Catégorie de produit : 5 bits (2⁵ = 32 > 29).
• Type d'objectif de mesure : 1 bit. L'objectif de mesure est soit le nombre d'achats, soit la valeur des achats. Il existe donc deux possibilités distinctes. Un bit suffit donc pour stocker cette information.

• ID de zone géographique : 3 bits (2³ = 8). Vous devez également définir une carte des dimensions pour l'ID géographique afin de savoir quelle région géographique représente chaque valeur binaire. Votre mappage de dimension pour la dimension "ID géographique" peut se présenter comme suit :

  Valeur binaire dans la clé	Zone géographique
  000	Amérique du Nord
  001	Amérique centrale
  010	Amérique du Sud
  011	Europe
  100	Afrique
  101	Asie
  110	Caraïbes
  111	Océanie

• ID de campagne : 4 bits (2⁴ = 16)

Les clés suivant cette structure auront une longueur de 13 bits (5 + 1 + 3 + 4).

Dans cet exemple, le mappage de la structure de clé pour ces clés se présente comme suit :

L'ordre des dimensions dans la clé dépend de vous.

Pour illustrer la façon dont les dimensions constituent une structure clé, nous allons utiliser une représentation binaire. C'est pourquoi l'ID de campagne (premiers bits) se trouve à l'extrême droite et la catégorie de produit (derniers bits) à l'extrême gauche.

Dans chaque dimension, le bit le plus significatif (celui qui porte la plus grande valeur numérique) est le bit le plus à gauche. Le bit le moins significatif (celui qui porte la plus petite valeur numérique) est le bit le plus à droite.

Voyons comment utiliser un mappage de structure de clé pour décoder une clé.

Prenons 0b1100100111100 comme exemple de clé arbitraire et supposons que vous savez que cette clé suit la carte de structure de clé de l'illustration précédente.

Selon le mappage de la structure des clés, cette clé se décode comme suit :

`11001 0 011 1100`

La clé 0b1100100111100 représente le nombre d'achats de la catégorie de produits 25, pour la campagne 12 lancée en Europe.

Encoder des dimensions à l'aide d'une fonction de hachage

Plutôt que d'utiliser une carte de structure de clé, vous pouvez utiliser une fonction de hachage pour générer des clés de manière dynamique, cohérente et fiable.

Voici comment cela fonctionne :

1. Sélectionnez un algorithme de hachage.
2. Au moment de la diffusion des annonces, générez une chaîne incluant toutes les dimensions que vous souhaitez suivre et leurs valeurs. Pour générer la partie clé côté source, hachez cette chaîne et envisagez d'ajouter un suffixe de 64 bits de zéros pour l'aligner sur la partie clé côté déclencheur et faciliter le raisonnement sur le OU.
   • Élément clé côté source
     = <64-bit hex hash("COUNT, campaignID=12, geoID=7"))><64-bit 00000000…>
   • Notez que COUNT encode la même chose que measurementGoalType=0 dans l'approche de la carte de structure des clés. COUNT est un peu plus simple et explicite.
3. Au moment de la conversion, générez une chaîne incluant toutes les dimensions que vous souhaitez suivre et leurs valeurs. Pour générer un élément de clé côté déclencheur, hachez cette chaîne et ajoutez un préfixe de 64 bits de zéros :
   • Clé de déclencheur : = <64-bit 00000000…><64-bit hex hash("productCategory=25")>
4. Le navigateur combine ces éléments de clé à l'aide d'un OR pour générer une clé.
   • Clé d'agrégation de 128 bits
     = <64-bit hex source-side key piece hash><64-bit hex source-side key piece hash>
5. Plus tard, lorsque vous serez prêt à demander un rapport récapitulatif pour cette clé, générez-le à la volée :
   • En fonction des dimensions qui vous intéressent, générez un élément clé côté source et côté déclencheur, comme vous l'avez fait précédemment.
     • Élément clé côté source
       = <64-bit hex hash("COUNT, campaignID=12, geoID=7"))><64-bit 00000000…>
     • Élément clé côté déclencheur
       = <64-bit 00000000…><64-bit hex hash("productCategory=25")>
     • Élément clé côté déclencheur = toHex(hash("productCategory=25"))
   • Tout comme le navigateur, OR ces éléments clés pour générer la même clé que le navigateur a générée précédemment.
     • Clé d'agrégation de 128 bits
       = <64-bit source-side key piece hash><64-bit source-side key piece hash>

Voici quelques conseils pratiques si vous utilisez cette approche basée sur le hachage :

• Utilisez toujours le même ordre pour les dimensions. Cela permet de s'assurer que vos hachages peuvent être régénérés de manière fiable. ("COUNT, CampaignID=12, GeoID=7" ne générera pas le même hachage que "COUNT, GeoID=7, CampaignID=12"). Pour ce faire, une méthode simple consiste à trier les dimensions de manière alphanumérique. C'est ce que nous allons faire dans l'exemple, sauf que nous allons toujours faire de COUNT ou VALUE le premier élément de la dimension. C'est un choix de lisibilité, car COUNT ou VALUE encode des informations dont le concept est légèrement différent de celui de toutes les autres dimensions.
• Gardez une trace de l'ensemble des dimensions que vous utilisez dans les clés. Vous souhaitez éviter de générer des clés basées sur un ensemble de dimensions que vous n'avez jamais utilisées.
• Les collisions de hachage sont rares si une fonction de hachage appropriée est utilisée. Toutefois, la vérification par rapport aux hachages précédemment utilisés (qui doivent être stockés pour interpréter les résultats du service d'agrégation) peut éviter d'introduire de nouvelles clés qui entrent en conflit avec des clés plus anciennes.

Pour savoir comment utiliser les clés basées sur le hachage en pratique, consultez l'exemple d'une conversion par clic ou par vue.

Valeurs agrégables en pratique

L'entreprise de technologie publicitaire définit des valeurs agrégables lorsqu'un utilisateur effectue une conversion.

Pour protéger la confidentialité des utilisateurs, les contributions de chacun sont limitées. Pour toutes les valeurs agrégables associées à une même source (clic ou vue d'annonce), aucune valeur ne peut dépasser une certaine limite de contribution.

Nous désignerons cette limite sous le nom de CONTRIBUTION_BUDGET. Dans l'explication, cette limite est appelée budget L1, mais elle est identique à CONTRIBUTION_BUDGET.

Pour en savoir plus sur le budget de contribution, consultez Budget de contribution pour les rapports récapitulatifs.

Exemple : une conversion par clic ou par vue

Pour cet exemple, supposons que vous cherchez à répondre aux questions suivantes :

• Quelles sont les catégories de produits les plus intéressantes dans chaque région ?
• Quelles sont les stratégies de campagne les plus efficaces dans chaque région ?

Supposons également que, pour votre cas d'utilisation, vous ayez besoin d'insights hebdomadaires.

Vous devez également suivre les éléments suivants :

• 16 campagnes différentes.
• 8 régions géographiques différentes : Amérique du Nord, Amérique centrale, Amérique du Sud, Europe, Afrique, Asie, Caraïbes et Océanie.
• 29 catégories de produits différentes.

Données à évaluer

De nombreuses entreprises de technologie publicitaire encouragent les annonceurs à configurer différents types de conversions. Toutefois, il est préférable de se concentrer sur les conversions les plus importantes, comme les achats, pour vérifier que les résultats agrégés sont détaillés et précis pour ces événements de conversion importants. En effet, plus vous mesurez de métriques, plus votre budget de contribution par métrique est faible, et plus chaque valeur est susceptible d'être bruyante. Vous devez donc choisir avec soin ce que vous allez mesurer.

Dans cet exemple, nous allons nous concentrer sur les configurations de campagne qui ne mesurent qu'une seule conversion par clic ou vue : un achat.

Vous continuerez à mesurer le nombre et la valeur des achats, et à accéder à diverses statistiques globales importantes, comme la valeur totale des achats et les répartitions géographiques. Cela permet de gérer efficacement le bruit tout en confirmant une méthode de mise à l'échelle simple pour votre budget de contribution.

Qu'en est-il des devises ?

Si vous diffusez des campagnes dans différentes régions, vous devez tenir compte des devises. Vous pouvez :

• Faites de la devise une dimension dédiée dans les clés d'agrégation.
• Vous pouvez également déduire la devise à partir d'un ID de campagne et convertir toutes les devises en devises de référence.

Dans cet exemple, nous partons du principe que vous pouvez déduire la devise à partir d'un ID de campagne. Cela vous permet de convertir n'importe quelle valeur d'achat de la devise locale de l'utilisateur dans une devise de référence de votre choix. Vous pouvez également effectuer cette conversion à la volée, lorsque l'utilisateur achète un article.

Grâce à cette technique, toutes les valeurs agrégables sont exprimées dans la même devise de référence et peuvent donc être additionnées pour générer une valeur d'achat agrégée totale, c'est-à-dire une valeur d'achat récapitulative.

Traduire les objectifs en clés

En fonction de vos objectifs et métriques de mesure, vous disposez de plusieurs options pour votre stratégie clé. Concentrons-nous sur deux de ces stratégies :

• Stratégie A : une structure de clés granulaires.
• Stratégie B : deux structures de clés grossières.

Stratégie A : un arbre profond (une structure de clés granulaires)

Dans la stratégie A, vous utilisez une structure de clés précises qui inclut toutes les dimensions dont vous avez besoin :

Toutes vos clés utilisent cette structure.

Vous divisez cette structure de clés en deux types de clés pour répondre à deux objectifs de mesure.

• Type de clé 0 : type d'objectif de mesure = 0, que vous décidez de définir comme nombre d'achats.
• Type de clé 1 : type d'objectif de mesure = 1, que vous décidez de définir comme valeur d'achat.

Les rapports récapitulatifs se présentent comme suit :

Vous pouvez considérer la stratégie A comme une stratégie "d'arbre à un niveau" :

• Chaque valeur récapitulative des rapports récapitulatifs est associée à toutes les dimensions que vous suivez.
• Vous pouvez cumuler ces valeurs récapitulatives à côté de chacune de ces dimensions. Ces cumuls peuvent donc être aussi détaillés que le nombre de dimensions dont vous disposez.

Avec la stratégie A, vous répondriez à vos questions comme suit :

Avec la stratégie A, vous pouvez également répondre directement à cette troisième question :

"Combien de revenus chaque produit a-t-il générés pour chacune de mes campagnes dans chaque région géographique ?"

Même si les valeurs récapitulatives seront bruyantes, vous pourrez déterminer quand les différences de valeur mesurées entre chaque campagne ne sont pas dues au bruit seul. Pour savoir comment procéder, consultez Comprendre le bruit.

Stratégie B : deux arbres peu profonds (deux structures de clés grossières)

Dans la stratégie B, vous utilisez deux structures de clés approximatives, chacune incluant un sous-ensemble des dimensions dont vous avez besoin :

Vous devez diviser chacune de ces structures clés en deux types clés pour répondre à deux objectifs de mesure.

• Type d'objectif de mesure = 0, que vous décidez de définir comme nombre d'achats.
• Type d'objectif de mesure = 1, que vous décidez de définir comme valeur d'achat.

Vous obtenez quatre types de clés :

• Type de clé I-0 : structure de clé I, nombre d'achats.
• Type de clé I-1 : structure de clé I, valeur d'achat.
• Type de clé II-0 : structure de clé II, nombre d'achats.
• Type de clé II-1 : structure de clé II, valeur d'achat.

Les rapports récapitulatifs se présentent comme suit :

Vous pouvez considérer la stratégie B comme une stratégie à "deux arbres peu profonds" :

• Les valeurs récapitulatives des rapports récapitulatifs correspondent à l'un des deux petits ensembles de dimensions.
• Vous pouvez cumuler ces valeurs récapitulatives à côté de chacune des dimensions de ces ensembles. Cela signifie que ces cumuls ne sont pas aussi détaillés que dans l'option A, car il y a moins de dimensions à cumuler.

Avec la stratégie B, vous répondriez à vos questions comme suit :

Décision : Stratégie A

La stratégie A est plus simple : toutes les données suivent la même structure de clé, ce qui signifie également que vous n'avez qu'une seule structure de clé à gérer.

Toutefois, avec la stratégie A, vous devez additionner les valeurs récapitulatives que vous recevez dans les rapports récapitulatifs pour répondre à certaines de vos questions. Chacune de ces valeurs récapitulatives est bruyante. En additionnant ces données, vous additionnez également le bruit.

Ce n'est pas le cas avec la stratégie B, où les valeurs récapitulatives exposées dans les rapports récapitulatifs vous fournissent déjà les informations dont vous avez besoin. Cela signifie que la stratégie B aura probablement un impact moins important du bruit que la stratégie A.

Comment déterminer quelle stratégie utiliser ? Pour les annonceurs ou les campagnes existants, vous pouvez vous appuyer sur les données historiques pour déterminer si le volume de conversions est plus adapté à la stratégie A ou à la stratégie B. Toutefois, pour les nouveaux annonceurs ou les nouvelles campagnes, vous pouvez choisir de :

• Collectez un mois de données avec les clés précises (stratégie A). Étant donné que vous prolongez la durée de collecte des données, les valeurs récapitulatives seront plus élevées et le bruit sera relativement plus faible.
• Évaluez avec une précision raisonnable le nombre de conversions et la valeur des achats hebdomadaires.

Dans cet exemple, supposons que le nombre et la valeur des achats hebdomadaires sont suffisamment élevés pour que la stratégie A entraîne un pourcentage de bruit que vous jugez acceptable pour votre cas d'utilisation.

Comme la stratégie A est plus simple et entraîne un impact de bruit qui n'affecte pas votre capacité à prendre des décisions, vous décidez de l'adopter.

Sélectionner un algorithme de hachage

Vous décidez d'adopter une approche basée sur le hachage pour générer vos clés. Pour ce faire, vous devez sélectionner un algorithme de hachage compatible avec cette approche.

Supposons que vous ayez sélectionné SHA-256. Vous pouvez également utiliser un algorithme plus simple et moins sécurisé, tel que MD5.

Dans le navigateur : définir des clés et des valeurs

Maintenant que vous avez choisi une structure de clés et un algorithme de hachage, vous êtes prêt à enregistrer les clés et les valeurs lorsque les utilisateurs cliquent sur des annonces ou les voient, puis effectuent une conversion.

Vous trouverez ci-dessous un aperçu des en-têtes que vous définirez pour enregistrer les clés et les valeurs dans le navigateur :

Définir les éléments clés côté source

Lorsqu'un utilisateur clique sur une annonce ou la voit, définissez les clés d'agrégation dans l'en-tête Attribution-Reporting-Register-Aggregatable-Source. À ce stade, pour chaque clé, vous ne pouvez définir que la partie de la clé, ou élément clé, qui est connue au moment de la diffusion des annonces.

Générons les éléments clés :

Définissons maintenant les éléments clés :

// Upon receiving the request from the publisher site
res.set(
  "Attribution-Reporting-Register-Aggregatable-Source",
  JSON.stringify([
    {
      "id": "key_purchaseCount",
      "key_piece": "0x3cf867903fbb73ec0000000000000000"
    },
    {
      "id": "key_purchaseValue",
      "key_piece": "0x245265f432f16e730000000000000000"
    }
  ])
);

Notez que les ID de clé n'apparaîtront pas dans les rapports finaux. Elles ne sont utilisées que lors de la définition des clés dans le navigateur, afin que les éléments de clé côté source et côté déclencheur puissent être mis en correspondance et combinés en une clé complète.

Facultatif : rapports au niveau des événements

Si vous devez utiliser des rapports au niveau des événements en plus des rapports agrégables, vérifiez que les données au niveau des événements (ID de l'événement source et données du déclencheur) et la clé d'agrégation peuvent être mises en correspondance pour une source donnée.

Vous pouvez utiliser les deux types de rapports si, par exemple, vous prévoyez d'utiliser des rapports au niveau des événements pour exécuter des modèles sur les types d'annonces qui ont tendance à générer le plus d'achats.

Un utilisateur réalise une conversion

Lorsqu'un utilisateur effectue une conversion, une demande de pixel est généralement envoyée au serveur de technologie publicitaire. Une fois cette demande reçue :

• Définissez les éléments de clé côté conversion (côté déclencheur) pour compléter la clé. Vous définirez ces éléments clés à l'aide de l'en-tête Attribution-Reporting-Register-Aggregatable-Trigger-Data.
• Définissez la valeur agrégable pour cette conversion à l'aide de l'en-tête Attribution-Reporting-Register-Aggregatable-Values.

Définissez les éléments de clé côté déclencheur pour compléter la clé.

Générons les éléments clés :

Définissons maintenant les éléments clés :

// Upon receiving the pixel request from the advertiser site
res.set(
  "Attribution-Reporting-Register-Aggregatable-Trigger-Data",
  JSON.stringify([
    // Each dictionary independently adds pieces to multiple source keys
    {
      "key_piece": "0x0000000000000000f9e491fe37e55a0c",
      "source_keys": ["key_purchaseCount", "key_purchaseValue"]
    },
  ])
);

Notez que vous ajoutez le même élément de clé à plusieurs clés en listant plusieurs ID de clé dans source_keys. L'élément de clé sera ajouté aux deux clés.

Définir des valeurs agrégables

Avant de définir les valeurs agrégables, vous devez les mettre à l'échelle pour réduire le bruit.

Supposons qu'un achat ait été effectué pour le type de produit 25 pour un montant de 52 $.

Vous ne définirez pas directement ces valeurs comme des valeurs agrégables :

• key_purchaseCount : 1 conversion
• key_purchaseValue : 52 $

Au lieu de cela, avant d'enregistrer ces valeurs agrégables, vous devez les mettre à l'échelle afin de minimiser le bruit.

Vous avez deux objectifs pour dépenser votre budget de contribution. Vous pouvez donc décider de le diviser en deux.

Dans ce cas, chaque objectif se voit attribuer un maximum de CONTRIBUTION_BUDGET/2 (=65 536/2=32 768).

Supposons que la valeur d'achat maximale pour un seul utilisateur, basée sur l'historique des achats de tous les utilisateurs du site, soit de 1 500 $. Il peut y avoir des valeurs aberrantes (par exemple, très peu d'utilisateurs ont dépensé plus que cette somme), mais vous pouvez choisir de les ignorer.

Votre facteur de scaling pour la valeur d'achat doit être le suivant :

((CONTRIBUTION_BUDGET/2) / 1 500) = 32 768/1 500 = 21,8 ≈ 22

Votre facteur de scaling pour le nombre d'achats est de 32 768/1 = 32 768, car vous avez décidé de suivre au maximum un achat par clic ou vue d'annonce (événement source).

Vous pouvez désormais définir les valeurs suivantes :

• key_purchaseCount : 1 × 32 768 = 32 768
• key_purchaseValue : 52 x 22 = 1 144

En pratique, vous les définissez comme suit, en utilisant l'en-tête dédié Attribution-Reporting-Register-Aggregatable-Values :

// Instruct the browser to schedule-send a report
res.set(
  "Attribution-Reporting-Register-Aggregatable-Values",
  JSON.stringify({
    "key_purchaseCount": 32768,
    "key_purchaseValue": 1144,
  })
);

Le rapport agrégable est généré.

Le navigateur associe la conversion à un clic ou à une vue précédents, puis génère un rapport agrégable, qui inclut la charge utile chiffrée à côté des métadonnées du rapport.

Voici un exemple des données qui pourraient figurer dans la charge utile du rapport agrégable, si elles étaient lisibles en texte brut :

[
  {
    key: 0x3cf867903fbb73ecf9e491fe37e55a0c, // = source-side key piece OR conversion-side key piece for the key key_purchaseCount
    value: 32768 // the scaled value for 1 conversion, in the context of [CONTRIBUTION_BUDGET/2]
  },
  {
    key: 0x245265f432f16e73f9e491fe37e55a0c, // source-side key piece OR conversion-side key piece for the key key_purchaseValue
    value: 1144 // the scaled value for $52, in the context of [CONTRIBUTION_BUDGET/2]
  },
]

Ici, vous pouvez voir deux contributions distinctes dans un seul rapport agrégable.

Demander un rapport récapitulatif

• Rapports agrégables par lot. Suivez les conseils fournis dans Regroupement par lots.
• Générez les clés pour lesquelles vous souhaitez afficher des données. Par exemple, pour afficher les données récapitulatives de COUNT (nombre total d'achats) et VALUE (valeur totale des achats) pour l'ID de campagne 12 × l'ID de zone géographique 7 × la catégorie de produit 25 :
  • Générez la partie clé côté source, comme vous l'avez fait lorsque vous l'avez définie dans le navigateur.
  • Générez la partie clé du déclencheur, comme vous l'avez fait lors de sa définition dans le navigateur.

• Demandez des données récapitulatives au service d'agrégation pour ces clés.

Gérer le rapport récapitulatif

Vous recevrez un rapport récapitulatif qui peut se présenter comme suit :

[
  {"bucket": "00111100111110000110011110010000001111111011101101110011111011001111100111100100100100011111111000110111111001010101101000001100",
    "value": "2558500"},
  {"bucket": "00100100010100100110010111110100001100101111000101101110011100111111100111100100100100011111111000110111111001010101101000001100",
    "value": "687060"},
  …
]

Le premier bucket correspond à la clé COUNT en binaire. Le deuxième bucket correspond à la clé VALUE en binaire. Notez que, bien que les clés soient hétérogènes (COUNT par rapport à VALUE), elles sont contenues dans le même rapport.

Réduire les valeurs

• 2 558 500 correspond au nombre d'achats pour cette clé, mis à l'échelle par votre facteur de scaling calculé précédemment. Le facteur de scaling pour le nombre d'achats était de 32 768. Divisez 2 558 500 par le budget de contribution de l'objectif : 2 558 500/32 768 = 156,15 achats.
• 687 060 → 687 060/22 = 31 230 $, soit la valeur totale des achats.

Par conséquent, les rapports récapitulatifs vous fournissent les insights suivants :

- Within the reporting time period, campaign #12
  run in Europe drove about 156 purchases (± noise)
  for the product category #25
  ```

  ```text
- Within the reporting time period, campaign #12
  run in Europe drove $31,230 of purchases (± noise)
  for the product category #25.