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

ce que sont les clés d'agrégation, comment elles sont utilisées dans l'API Attribution Reporting et comment convertir les objectifs en clés ;

En tant qu'entreprise ad tech qui diffuse 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. Quels sont les revenus générés par chaque catégorie de produits pour chacune de mes campagnes dans chaque région géographique ?

Même si de nombreuses entreprises de technologie publicitaire encouragent les annonceurs à configurer différents types de conversions, se concentrer sur les conversions les plus importantes (les achats, par exemple) est un bon moyen de s'assurer que les résultats récapitulatifs sont détaillés et précis pour ces événements importants.

Pour ce faire, vous devrez réfléchir aux questions auxquelles vous souhaitez répondre avant que les données ne soient collecté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 produits : type de produit tel que vous l'avez défini.

Les dimensions "ID de la campagne" et "ID de la zone géographique" sont connues au moment de la diffusion de l'annonce (date et heure de diffusion de l'annonce), tandis que la catégorie de produits est connue à partir d'un événement déclencheur, lorsque l'utilisateur effectue une conversion (date et heure de la conversion).

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

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

Les termes "clé d'agrégation" et "bucket" désignent 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 de service d'agrégation.

Une clé d'agrégation est une donnée qui représente les valeurs des dimensions faisant l'objet d'un suivi. Les données sont ensuite agrégées en fonction de chaque clé d'agrégation.

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

Lorsqu'un internaute situé dans la zone géographique ID 7 voit une annonce pour la campagne 12, puis effectue une conversion ultérieurement en achetant un produit appartenant à la catégorie de produits 25, vous pouvez définir une clé d'agrégation semblable à celle illustrée dans l'image ci-dessous:

Vous verrez plus tard qu'une clé d'agrégation ne se présente pas exactement comme cela dans la pratique, mais pour l'instant, concentrons-nous sur les informations qu'elle contient.

Que sont les valeurs agrégables ?

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

• Nombre d'achats (nombre d'achats). Une fois agrégé et disponible dans un rapport récapitulatif, il s'agit du nombre total d'achats (valeur récapitulative).
• Revenus générés par chaque achat (valeur de l'achat). Une fois agrégé et mis à disposition dans un rapport récapitulatif, il s'agit du revenu total (valeur récapitulative).

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

Lorsqu'un internaute situé dans la zone géographique ID 7 voit une annonce pour l'ID de campagne 12, puis effectue une conversion par la suite en achetant un produit de la catégorie de produits 25 à 120 $ (en supposant que votre devise est le dollar américain), vous pouvez définir une clé d'agrégation et des valeurs agrégables qui se présentent comme suit:

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

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

Notez que ce schéma omet le déchiffrement et représente un exemple simplifié sans bruit. Dans la section suivante, nous allons illustrer cet exemple avec du bruit.

Des clés et des valeurs aux rapports

Voyons maintenant le lien entre les clés et valeurs agrégables et les rapports.

Rapports agrégables

Lorsqu'un utilisateur clique ou regarde une annonce, 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 voit une annonce ou clique dessus, 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 {aggregate key, aggregatable value} ne ressemble pas exactement à ceci. 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 faire correspondre la conversion à une vue ou à un clic antérieur).

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 sur l'événement de conversion : site où la conversion s'est produite, etc. Affichez tous les champs dans un rapport agrégable.

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

La charge utile contient une liste de contributions, chacune étant une paire {aggregate key, aggregatable value} :

• bucket: clé d'agrégation, encodée en tant que chaîne d'octets.
• value: valeur agrégable pour cet objectif de mesure, encodée sous forme de chaîne d'octets.

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 des chaînes d'octets.

Rapports de synthèse

Les rapports agrégables sont compilés pour de nombreux navigateurs et appareils (utilisateurs) comme suit:

• Une technologie publicitaire demande des rapports récapitulatifs pour un ensemble donné de clés et un ensemble donné de rapports agrégables 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 issues des rapports agrégables sont additionnées.
• Du bruit est ajouté à la valeur récapitulative.

Vous obtenez un rapport récapitulatif contenant un ensemble de paires {aggregate key, summary value}.

Un rapport récapitulatif contient un ensemble de paires clé-valeur de type dictionnaire JSON. Chaque paire contient les éléments suivants :

• bucket: clé d'agrégation, encodée en tant que chaîne d'octets.
• value: valeur récapitulative en décimales pour un objectif de mesure donné, additionné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 sorte que les buckets et les valeurs soient différents de ceux indiqués dans l'exemple (c'est-à-dire qu'un bucket peut ressembler à \u0000\u0000\x80\u0000). Bucket et value sont des chaînes d'octets.

Les 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 : lorsque l'utilisateur clique ou visionne une annonce, 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, la structure ID de la campagne × ID géographique × Catégorie de produits est une structure clé.

Types de clés

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

Pour ce faire, dans chaque clé, encodez une donnée qui vous indique ce que la valeur récapitulative représente, c'est-à-dire 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.

Dans notre exemple précédent, ce type d'objectif de mesure aurait deux valeurs différentes possibles :

• 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 comporte n types de valeurs différents.

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

Taille de la clé et de la dimension

La taille maximale de la clé est définie en bits, c'est-à-dire en nombre de zéros et d'uns au format binaire pour créer la clé complète. L'API autorise une longueur de clé de 128 bits.

Bien que cette taille permette d'utiliser des clés très précises, les clés plus précises sont plus susceptibles de générer plus de bruit dans les valeurs. 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 qu'elle 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 y a environ 200 pays dans le monde. Combien de bits sont nécessaires pour encoder cette dimension ?

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

8 bits stockeraient 2⁸ = 256 options distinctes, soit plus que les 200 bits nécessaires. Vous pouvez donc utiliser n=8 bits pour encoder cette dimension.

Encodage de clé

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

Définir deux parties de clé pour une clé complète

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

• ID de la campagne
• ID de zone géographique
• Catégorie du produit

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

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

1. Vous définirez une partie de la clé (ID de campagne × ID de zone géographique) au moment du clic ou de la vue.
2. Vous devez définir 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 prenant l'opérateur OR (v) de ses éléments clés.

Exemple :

• Pièce de clé côté source = 0x159
• Clé côté déclencheur = 0x400
• Clé = 0x159 v 0x400 = 0x559

Aligner les éléments clés

Avec deux éléments de clé de 64 bits étendus à 128 bits à l'aide de remplisseurs/décalages de 64 bits soigneusement placés (les seize zéros), l'opération OR sur les éléments de clé équivaut à les concatenar, ce qui est plus facile à raisonner et à vérifier :

• Pièce de la clé côté source = 0xa7e297e7c8c8d0540000000000000000
• Clé côté déclencheur = 0x0000000000000000674fbe308a597271
• Clé = 0xa7e297e7c8c8d0540000000000000000 v 0x0000000000000000674fbe308a597271 = 0xa7e297e7c8c8d054674fbe308a597271

Plusieurs clés par clic ou vue sur une 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 les éléments suivants :

• Clé qui suit l'ID de zone géographique × ID de campagne.
• Autre clé qui suit le type de création × ID de la campagne.

Pour en voir un autre, consultez la stratégie B.

Encodage 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 de synthèse contiennent des paires {key, summary value} brutes et aucune information supplémentaire sur la clé. Par conséquent :

• Lorsque vous définissez des clés lorsque l'utilisateur voit une annonce ou clique dessus, puis effectue une conversion, vous devez définir des 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 de manière fiable ou accéder instantanément aux mêmes clés que celles définies lorsque l'utilisateur a vu ou cliqué sur une annonce et a généré une conversion, en fonction des 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é

Pour encoder des dimensions en clés, vous pouvez créer et gérer un mappage de structure de clés à l'avance, lors de la définition de vos clés (avant l'heure de diffusion de l'annonce).

Un mappage de la structure de clés représente chacune de vos dimensions et leur position dans la clé.

En pratique, vous devez implémenter et gérer la logique du décodeur pour créer et gérer des mappages de structure de clés. Si vous recherchez une méthode qui ne vous oblige pas à le faire, envisagez plutôt d'utiliser une approche basée sur le hachage.

Exemple :

Supposons que vous souhaitiez suivre à la fois les achats et la valeur des achats pour des campagnes, des zones géographiques et des produits spécifiques.

La catégorie de produits, l'ID géographique et l'ID de campagne doivent être des dimensions dans vos clés. En outre, comme vous souhaitez suivre deux objectifs de mesure différents, à savoir le nombre d'achats et la valeur des achats, vous devez ajouter une dimension dans votre clé qui permet de suivre le type de clé. Cela vous permettra de définir ce que la valeur agrégable représente réellement lors de la réception de paires {key, aggregatable value} dans les rapports de synthèse.

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

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

Examinons maintenant chaque dimension. Pour votre cas d'utilisation, supposons que 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 avez besoin pour encoder chaque dimension dans votre clé :

• Catégorie de produit: 5 bits (2⁵ = 32 > 29).
• Type d'objectif de mesure : 1 bit. L'objectif de mesure concerne soit le nombre d'achats, soit la valeur des achats, ce qui signifie que deux possibilités distinctes sont possibles. Un bit est donc suffisant pour les stocker.

• ID de zone géographique : 3 bits (2³ = 8). Vous pouvez également définir une carte de dimensions pour l'identifiant géographique afin de savoir quelle région géographique représente chaque valeur binaire. Votre mappage de dimension pour votre dimension d'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 qui suivent cette structure auront une longueur de 13 bits (5 + 1 + 3 + 4).

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

L'ordre des dimensions dans la clé vous appartient.

Pour illustrer la façon dont les dimensions constituent une structure de clé, nous allons utiliser une représentation binaire. C'est pourquoi l'ID de la campagne (premiers bits) est le plus à droite, et la catégorie de produits (derniers bits) est la plus à 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 contient 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 ayez un moyen de savoir que cette clé suit le plan de structure de clé dans l'illustration précédente.

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

`11001 0 011 1100`

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

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

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

Voici comment cela fonctionne :

1. Sélectionnez un algorithme de hachage.
2. Au moment de la diffusion de l'annonce, générez une chaîne incluant toutes les dimensions dont vous souhaitez effectuer le suivi, ainsi que leurs valeurs. Pour générer l'élément de clé côté source, hachez cette chaîne et envisagez d'ajouter un suffixe de zéros de 64 bits pour l'aligner avec l'élément de clé côté déclencheur et faciliter le raisonnement de l'opérateur OR.
   • Pièce de 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 mappage de la structure des clés. COUNT est un peu plus mince et plus 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 une clé côté déclencheur, hachez cette chaîne et ajoutez un préfixe de 64 bits composé de zéros :
   • Pièce de clé côté déclencheur = <64-bit 00000000…><64-bit hex hash("productCategory=25")>
4. Le navigateur effectue une opération OR sur ces éléments de clé pour générer une clé.
   • Clé d'agrégation 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 :
   • Générez un élément clé côté source et côté déclencheur en fonction des dimensions qui vous intéressent, comme vous l'avez fait précédemment.
     • Pièce de clé côté source
       = <64-bit hex hash("COUNT, campaignID=12, geoID=7"))><64-bit 00000000…>
     • Clé côté déclencheur
       = <64-bit 00000000…><64-bit hex hash("productCategory=25")>
     • Clé côté déclencheur = toHex(hash("productCategory=25"))
   • Tout comme le navigateur, OU 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:

• Veillez à toujours respecter le même ordre pour les dimensions. Cela garantit que vos hachages peuvent être régénérés de manière fiable. ("COUNT, CampaignID=12, GeoID=7" ne génère pas le même hachage que "COUNT, GeoID=7, CampaignID=12"). Pour ce faire, il suffit de trier les dimensions alphanumériquement. C'est ce que nous ferons dans l'exemple, à l'exception du fait que nous définirons toujours COUNT ou VALUE comme premier élément de la dimension. Il s'agit d'un choix de lisibilité, car COUNT ou VALUE encode des informations légèrement différentes conceptuellement de toutes les autres dimensions.
• Gardez une trace de l'ensemble de 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 des 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 d'anciennes clés.

Découvrez comment utiliser des clés basées sur un hachage dans la pratique dans l'exemple d'une conversion par clic ou affichage.

Les 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 chaque utilisateur sont limitées. Sur l'ensemble des valeurs agrégables associées à une même source (clic ou visionnage d'annonce), aucune valeur ne peut dépasser un certain seuil de contribution.

Cette limite est appelée 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 catégories de produits sont 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 vous ayez besoin d'insights hebdomadaires pour votre cas d'utilisation.

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

Même si de nombreuses entreprises de technologie publicitaire encouragent les annonceurs à configurer différents types de conversions, se concentrer sur les conversions les plus importantes (les achats, par exemple) est un bon moyen de s'assurer 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 soigneusement les éléments à 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 pourrez toujours mesurer le nombre d'achats et la valeur des achats, et accéder à diverses statistiques globales importantes, comme la valeur totale des achats et la répartition géographique. Le bruit est ainsi raisonnable et une approche de mise à l'échelle simple pour votre budget de contribution.

Qu'en est-il des devises ?

Pour diffuser des campagnes dans différentes régions, les devises doivent être prises en compte. 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 de l'ID d'une campagne et convertir toutes les devises dans une devise de référence.

Dans cet exemple, nous supposons que vous pouvez déduire la devise à partir d'un ID de campagne. Vous pouvez ainsi convertir la valeur d'un achat donné de la devise locale de l'utilisateur dans une devise de référence de votre choix. Vous pouvez également effectuer cette conversion instantanément lorsque l'utilisateur achète un article.

Avec 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 totale agrégée (valeur d'achat récapitulative).

Traduire les objectifs en clés

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

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

Stratégie A : une arborescence profonde (une structure de clé détaillée)

Dans la stratégie A, vous utilisez une structure de clé précise 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 atteindre deux objectifs de mesure.

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

Les rapports de synthèse se présentent comme suit:

Vous pouvez considérer la stratégie A comme une stratégie "un arbre profond" :

• Chaque valeur récapitulative dans les rapports de synthèse est associée à toutes les dimensions dont vous effectuez le suivi.
• Vous pouvez regrouper ces valeurs récapitulatives avec chacune de ces dimensions, de sorte que ces valeurs de synthèse puissent aller aussi loin que le nombre de dimensions dont vous disposez.

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

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

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

Même si les valeurs récapitulatives comportent du bruit, vous pouvez déterminer à quel moment 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 principales grosses)

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

Vous divisez chacune de ces structures de clés en deux types de clés pour prendre en charge 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 de l'achat

Les rapports de synthèse se présentent comme suit:

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

• Les valeurs récapitulatives des rapports récapitulatifs correspondent à l'un des deux petits ensembles de dimensions.
• Vous pouvez regrouper ces valeurs récapitulatives avec chacune des dimensions de ces ensembles. Cela signifie que ces agrégations ne sont pas aussi détaillées que dans l'option A, car il y a moins de dimensions à regrouper.

Avec la stratégie B, vous répondriez à vos questions de la manière suivante:

Décision : Stratégie A

La stratégie A est plus simple. Toutes les données suivent la même structure de clés, ce qui signifie également que vous n'avez qu'une seule structure de clés à 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 en raison du bruit que la stratégie A.

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

• Collectez un mois de données avec les clés détaillées (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 relativement faible.
• Évaluez avec une précision raisonnable le nombre de conversions hebdomadaires et la valeur des achats.

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

Étant donné que la stratégie A est plus simple et qu'elle entraîne un impact du bruit qui n'affecte pas votre capacité à prendre des décisions, vous décidez d'opter pour la stratégie A.

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 avez 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é et un algorithme de hachage, vous êtes prêt à enregistrer des clés et des valeurs lorsque des utilisateurs cliquent sur les annonces ou les voient, puis effectuent une conversion.

Vous trouverez ci-dessous une présentation des en-têtes que vous définirez pour enregistrer des clés et des valeurs dans le navigateur :

Définir des éléments de clé côté source

Lorsqu'un utilisateur voit une annonce ou clique dessus, 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 la partie de clé, qui est connue au moment de la diffusion de l'annonce.

Générez 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. Ils ne sont utilisés que lors de la configuration des clés dans le navigateur, afin que les éléments de clé côté source et côté déclencheur puissent être mappés les uns aux autres 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 avec des rapports agrégables, assurez-vous que pour une source donnée, les données au niveau de l'événement (ID d'événement source et données du déclencheur) et la clé d'agrégation peuvent être mises en correspondance.

Vous pouvez utiliser les deux 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 génèrent le plus d'achats.

Un utilisateur effectue une conversion.

Lorsqu'un utilisateur effectue une conversion, une demande de pixel est généralement envoyée au serveur de technologie publicitaire. À la réception de cette requête :

• 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 de clé via l'en-tête Attribution-Reporting-Register-Aggregatable-Trigger-Data.
• Définissez la valeur agrégable pour cette conversion via l'en-tête Attribution-Reporting-Register-Aggregatable-Values.

Définir 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 la même partie de clé à plusieurs clés en listant plusieurs ID de clé dans source_keys. La partie de clé sera ajoutée aux deux clés.

Définir des valeurs agrégables

Avant de définir les valeurs agrégables, vous devez les augmenter afin de réduire le bruit.

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

Vous ne les définirez pas directement 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 est alloué un maximum de CONTRIBUTION_BUDGET/2 (= 65 536 / 2 = 32 768).

Supposons que la valeur d'achat maximale d'un seul utilisateur, sur la base de 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 ayant dépensé plus que cette somme, mais vous pouvez décider de les ignorer.

Le facteur de mise à l'échelle de la valeur des achats doit être le suivant:

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

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

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

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

En pratique, vous devez les définir 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 met en correspondance la conversion avec une vue ou un clic précédents, et 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 de données pouvant être trouvées dans la charge utile du rapport agrégable, si elle était lisible en texte clair :

[
  {
    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]
  },
]

Vous pouvez voir deux contributions distinctes dans un même rapport agrégable.

Demander un rapport récapitulatif

• Rapports agrégables par lot Suivez les conseils fournis dans la section Grouper les requêtes.
• Générez les clés pour lesquelles vous souhaitez consulter les données. Par exemple, pour afficher les données récapitulatives pour COUNT (nombre total d'achats) et VALUE (valeur totale des achats) pour l'identifiant de campagne 12 × l'identifiant géographique 7 × la catégorie de produits 25 :
  • Générez l'élément de clé côté source, comme vous l'avez fait lorsque vous l'avez défini dans le navigateur.
  • Générez la clé côté déclencheur comme vous l'avez fait pour la configurer dans le navigateur.

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

Gérer le rapport récapitulatif

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

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

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

Réduire les valeurs

• 2 558 500 fait référence au nombre d'achats pour cette clé, multiplié par le facteur de mise à l'échelle que vous avez calculé précédemment. Le facteur de scaling du 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 $ de valeur d'achat totale.

Par conséquent, les rapports récapitulatifs vous fournissent les informations suivantes:

- 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.