en quoi consistent les clés d'agrégation, comment elles sont utilisées dans l'API Attribution Reporting et comment convertir des objectifs en clés ;
En tant qu'entreprise ad tech diffusant des campagnes dans plusieurs emplacements pour différentes catégories de produits, vous souhaitez aider les annonceurs à répondre aux questions suivantes:
- Combien d'achats ont été générés pour chaque catégorie de produits dans chaque zone géographique par chacune de mes campagnes ?
- Quels revenus ont été générés chacune de mes campagnes dans chaque zone géographique pour chaque catégorie de produits ?
Bien que 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 voulez répondre avant de collecter des 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 effectuer le suivi des dimensions suivantes:
- ID de campagne publicitaire: identifiant de la campagne spécifique.
- Identifiant géographique: la zone 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 géographique" sont connues lorsque l'annonce est diffusée (durée 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 (heure de la conversion).
Les dimensions dont vous souhaitez effectuer le suivi 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 de navigateur utilisées pour configurer les rapports. Le terme bucket est utilisé dans les rapports agrégables et de synthèse, 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 suivies. Les données sont ensuite agrégées avec chaque clé d'agrégation.
Supposons par exemple que vous effectuiez le suivi des dimensions "Catégorie de produits", "ID géographique" et "ID de campagne".
Lorsqu'un utilisateur situé dans la zone géographique 7 voit une annonce associée à l'ID de campagne 12, puis effectue une conversion en achetant un produit de 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 ressemble pas exactement à ceci 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 mis à disposition dans un rapport récapitulatif, il s'agira 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 de vos objectifs de mesure.
| Question | Valeur agrégable = objectif de mesure |
|---|---|
| Combien d'achats... | Nombre d'achats |
| Quels sont les revenus... | Valeur des achats |
Lorsqu'un utilisateur situé dans la zone géographique 7 voit une annonce associée à l'ID de campagne 12, puis effectue une conversion en achetant un produit de la catégorie de produits 25 pour 120 $ (en supposant que votre devise est le dollar américain), vous pouvez définir une clé d'agrégation et des valeurs pouvant être agrégées 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 la forme de valeurs récapitulatives dans les rapports récapitulatifs.
Les valeurs agrégables sont additionnées afin de générer des insights cumulé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 décrire cet exemple avec du bruit.
Des clés et valeurs aux rapports
Voyons maintenant le lien entre les clés et valeurs agrégables et les rapports.
Rapports agrégables
Lorsqu'un utilisateur voit une annonce ou clique dessus, puis réalise une conversion par la suite, vous demandez au navigateur de stocker une paire {Aggregation key, aggregatable value}.
Dans notre exemple, lorsqu'un utilisateur voit une annonce ou clique dessus, puis réalise une conversion par la suite, 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 se présente pas exactement comme ceci. Mais pour l'instant, concentrons-nous sur les informations contenues dans le rapport.
Lorsque vous demandez au navigateur de générer deux contributions, il génère un rapport agrégable (s'il peut établir une correspondance entre la conversion et 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.). Consultez tous les champs d'un rapport agrégable.
Les rapports agrégables sont au format JSON et comprennent, 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 correspondant à une paire {aggregate key, aggregatable value} :
- bucket: la 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 telle sorte que les buckets et les valeurs se présentent différemment de l'exemple précédent (un bucket peut ressembler à \u0000\u0000\x80\u0000). Bucket et value sont tous deux des chaînes d'octets.
Rapports de synthèse
Les rapports agrégables sont regroupé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 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 {aggregate key, summary value}.
Un rapport récapitulatif contient un ensemble de paires clé/valeur de style dictionnaire JSON. Chaque paire contient:
- bucket: la clé d'agrégation, encodée en tant que chaîne d'octets.
- value: valeur récapitulative au format décimal pour un objectif de mesure donné, calculé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 telle sorte que les buckets et les valeurs soient différents de ce qu'indique l'exemple (un bucket peut donc ressembler à \u0000\u0000\x80\u0000). Bucket et value sont tous deux des chaînes d'octets.
Clés d'agrégation en pratique
Les clés d'agrégation (buckets) sont définies par une entreprise ad tech, généralement en deux étapes: lorsqu'un utilisateur clique ou consulte une annonce, et lorsqu'un utilisateur effectue une conversion.
Structure de la clé
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 x Identifiant géographique x Catégorie de produit constitue une structure clé.
Types de clés
Les valeurs agrégables sont additionnées pour une clé donnée pour plusieurs utilisateurs/navigateurs. Toutefois, nous avons constaté que les valeurs agrégables permettent de suivre différents objectifs de mesure, tels que la valeur d'un achat 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 un élément de 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 pour votre clé une dimension supplémentaire qui représente le type d'objectif de mesure.
Dans 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 des achats est le deuxième type d'objectif de mesure.
Si vous avez défini 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 produit donné par campagne et par zone géographique".
Taille de la clé, taille de la dimension
La taille maximale de la clé est définie en bits, soit le 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'utiliser des clés très précises, mais les clés plus précises sont plus susceptibles d'entraîner plus de bruit. 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 possède une cardinalité spécifique, c'est-à-dire le nombre de valeurs distinctes qu'elle peut prendre. Selon sa cardinalité, chaque dimension doit être représentée par un certain nombre de bits. Avec n bits, il est possible d'exprimer 2n options distinctes.
Par exemple, une 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 stockeraient que 27 =128 options distinctes, ce qui est inférieur aux 200 options nécessaires.
8 bits stockeraient 28 =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 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 désignées sous le nom de buckets).
Définir deux éléments clés pour une clé complète
Supposons que vous utilisiez une clé pour effectuer le suivi des dimensions suivantes:
- ID de campagne
- Identifiant géographique
- Catégorie de produits
Bien que les dimensions "ID de campagne" et "ID géographique" soient connues lorsque l'annonce est diffusée (durée de diffusion de l'annonce), la catégorie de produit sera connue à partir d'un événement déclencheur, lorsque l'utilisateur effectue une conversion (heure de la conversion).
En pratique, cela signifie que vous allez définir une clé en deux étapes:
- Vous devez définir une partie de la clé (ID de campagne x ID géographique) au moment du clic ou de l'affichage.
- Vous devez définir la deuxième partie de la clé ("Catégorie de produit") 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 XOR (^) de ses éléments clés.
Exemple :
- Clé côté source =
0x159 - Clé côté déclencheur =
0x400 - Clé =
0x159 ^ 0x400 = 0x559
Aligner les pièces clés
Avec deux éléments de clé de 64 bits étendus à 128 bits à l'aide de remplissages/décalages de 64 bits soigneusement placés (les seize zéros), les éléments de clé XOR équivaut à les concaténer, ce qui est plus facile à raisonner et à vérifier:
- Clé côté source =
0xa7e297e7c8c8d0540000000000000000 - Clé côté déclencheur =
0x0000000000000000674fbe308a597271 - Clé =
- 0xa7e297e7c8c8d0540000000000000000 ^ 0x0000000000000000674fbe308a597271 =
- 0xa7e297e7c8c8d054674fbe308a597271
Plusieurs clés par vue ou clic sur une annonce
En pratique, vous pouvez définir plusieurs clés par événement de source d'attribution (clic sur une annonce ou vue d'une annonce). Par exemple, vous pouvez définir:
- Une clé permettant d'effectuer le suivi de l'ID géographique et de l'ID de campagne.
- Une autre clé assure le suivi du type de création et de l'ID de campagne.
Examinez la stratégie B pour voir un autre exemple.
Encodage des dimensions dans des clés
Lorsque vous demandez des rapports de synthèse, vous devez indiquer au service d'agrégation à quelles métriques vous souhaitez accéder, en demandant des rapports de synthèse 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é. Qu'est-ce que cela signifie ?
- Lorsque vous définissez des clés lorsque l'utilisateur voit une annonce ou clique dessus, puis effectue une conversion par la suite, 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 les mêmes clés ou y accéder instantanément que celles définies lorsque l'utilisateur a vu une annonce ou cliqué dessus et a effectué une conversion, en fonction des valeurs des dimensions pour lesquelles vous souhaitez afficher des données globales.
Encoder des dimensions à l'aide de mappages de structure de clés
Pour encoder des dimensions en clés, vous pouvez créer et gérer un mappage de structure de clés à l'avance, lorsque vous définissez vos clés (avant la diffusion de l'annonce).
Un mappage de structure clé représente chacune de vos dimensions et leur position dans la clé.
En pratique, pour créer et gérer des mappages de structure de clés, vous devez implémenter et gérer la logique du décodeur. Si vous recherchez une méthode qui ne nécessite pas cette opération, envisagez plutôt d'utiliser une approche basée sur le hachage.
Exemple :
Supposons que vous envisagez d'effectuer le suivi des achats et de leur valeur 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 effectuer le suivi de deux objectifs de mesure différents (nombre d'achats et valeur des achats), vous devez ajouter une dimension dans votre clé pour suivre le type de clé. Cela vous permettra de définir ce que la valeur agrégable représente réellement à 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 de produits
- Type d'objectif de mesure
- Identifiant géographique
- ID de campagne
Pour chaque dimension, supposons que vous deviez effectuer le suivi des éléments suivants pour votre cas d'utilisation:
- 29 catégories de produits différentes.
- Huit 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 de votre clé:
- Catégorie de produits: 5 bits (25 = 32 > 29).
- Type d'objectif de mesure: 1 bit. L'objectif de la mesure est le nombre d'achats ou la valeur des achats, ce qui signifie deux possibilités distinctes. Par conséquent, un bit suffit pour stocker cela.
ID géographique: 3 bits (23 = 8). Vous devez également définir une carte de dimensions pour l'identifiant géographique afin de savoir quelle région géographique chaque valeur binaire représente. La carte de vos dimensions "Identifiant 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 la campagne: 4 bits (24 = 16)
Les clés suivant cette structure ont une longueur de 13 bits (5 + 1 + 3 + 4).
Dans cet exemple, le mappage de la structure de ces clés se présente comme suit:
L'ordre des dimensions au sein de 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) est le premier et la catégorie de produit (derniers bits) le plus à gauche.
Dans chaque dimension, le bit le plus significatif (celui qui contient la valeur numérique la plus élevée) 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és pour décoder une clé.
Prenons 0b1100100111100 comme exemple de clé arbitraire et supposons que vous savez que cette clé suit le mappage de structure de clé de l'illustration précédente.
Selon le mappage de structure des clés, cette clé serait décodée en:
11001 0 011 1100
Ainsi, la clé 0b1100100111100 représente le nombre d'achats de la catégorie de produits 25, pour l'ID de campagne 12 lancée en Europe.
Encoder des dimensions à l'aide d'une fonction de hachage
Plutôt que d'utiliser un mappage de structure de clés, vous pouvez utiliser une fonction de hachage pour générer dynamiquement des clés de manière cohérente et fiable.
Cela fonctionne comme suit:
- Sélectionnez un algorithme de hachage.
- Au moment de la diffusion de l'annonce, générez une chaîne incluant toutes les dimensions dont vous souhaitez effectuer le suivi et 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 64 bits de zéros pour l'aligner avec l'élément de clé côté déclencheur et faciliter le raisonnement XOR.
- Pièce de clé côté source
= <hachage hexadécimal 64 bits("COUNT, campaignID=12, geoID=7"))><00000000 64 bits...> - Notez que COUNT encode le même élément que measurementGoalType=0 dans l'approche de la carte de structure clé. COUNT est un peu plus simple et plus explicite.
- Pièce de clé côté source
- Au moment de la conversion, générez une chaîne incluant toutes les dimensions dont vous souhaitez effectuer le suivi, ainsi que leurs valeurs. Pour générer un élément de clé côté déclencheur, hachez cette chaîne et ajoutez un préfixe 64 bits de zéros :
- Pièce de clé côté déclencheur = <00000000 64 bits...><hachage hexadécimal 64 bits("productCategory=25")>
- Le navigateur effectue une opération XOR pour ces éléments de clé afin de générer une clé.
- Clé d'agrégation de 128 bits
=< hachage d'élément de clé hexadécimale de 64 bits côté source>
- Clé d'agrégation de 128 bits
- 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 de clé côté source et côté déclencheur, comme vous l'avez fait précédemment.
- Pièce de clé côté source
= <hachage hexadécimal 64 bits("COUNT, campaignID=12, geoID=7"))><00000000 64 bits...> - Pièce de clé côté déclencheur
= <00000000 64 bits...><hachage hexadécimal 64 bits("productCategory=25")> - pièce de clé côté déclencheur = toHex(hash("productCategory=25"))
- Pièce de clé côté source
- Tout comme pour le navigateur, utilisez l'opérateur XOU pour générer la clé générée précédemment par le navigateur.
- Clé d'agrégation 128 bits
= <64 bits de hachage de l'élément de clé côté source> < hachage de l'élément de clé côté source de 64 bits>
- Clé d'agrégation 128 bits
- En fonction des dimensions qui vous intéressent, générez un élément de clé côté source et côté déclencheur, comme vous l'avez fait précédemment.
Voici quelques conseils pratiques si vous utilisez cette approche basée sur le hachage:
- Respectez toujours l'ordre des dimensions. Cela garantit que vos hachages peuvent être générés de nouveau 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, une méthode simple consiste à trier les dimensions au moyen de caractères alphanumériques. C'est ce que nous allons faire dans l'exemple, à la différence que COUNT ou VALUE seront toujours le premier élément de la dimension. Il s'agit d'un choix pour la lisibilité, car COUNT ou VALUE encode des informations qui sont légèrement différentes du point de vue conceptuel.
- Effectuez le suivi de l'ensemble des dimensions que vous utilisez dans les clés. Vous voulez éviter de générer des clés sur la base d'un ensemble de dimensions que vous n'avez jamais utilisé.
- Les conflits de hachage sont rares si une fonction de hachage appropriée est utilisée. Toutefois, en vérifiant les hachages précédemment utilisés (qui doivent être stockés pour interpréter les résultats du service d'agrégation), vous pouvez éviter d'introduire de nouvelles clés qui entrent en conflit avec d'anciennes clés.
Pour découvrir comment utiliser des clés basées sur le hachage, consultez l'exemple de conversion par clic ou de 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, un plafond est défini pour leurs contributions. Pour l'ensemble des valeurs agrégables associées à une source unique (clic ou vue d'annonce), aucune valeur ne peut être supérieure à une certaine limite de contribution.
Nous appelons cette limite le CONTRIBUTION_BUDGET. Dans l'explication, cette limite est appelée budget L1, mais elle est identique au 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 souhaitiez répondre aux questions suivantes:
- Quelles catégories de produits sont les plus utiles 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 effectuer le suivi des éléments suivants:
- 16 campagnes différentes.
- Huit 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, se concentrer sur les conversions les plus importantes (les achats, par exemple) est un bon moyen de s'assurer que les résultats cumulé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 risque d'être bruyante. Vous devez donc choisir soigneusement les éléments à mesurer.
Dans cet exemple, nous allons nous concentrer sur les configurations de campagnes qui ne mesurent qu'une seule conversion par clic ou par vue: les achats.
Vous mesurerez à la fois le nombre et la valeur des achats, et vous accéderez à diverses statistiques globales importantes, telles que la valeur totale des achats et la répartition géographique. Le bruit reste raisonnable et garantit une approche de mise à l'échelle simple pour votre budget de contribution.
Qu'en est-il des devises ?
La diffusion de campagnes dans différentes régions implique que 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 d'un ID de campagne, puis 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. Cela vous permet de convertir n'importe quelle valeur d'achat dans la devise locale de l'utilisateur vers la devise de référence de votre choix. Vous pouvez également effectuer cette conversion à la volée, lorsque l'utilisateur achète un article.
Avec cette technique, toutes les valeurs agrégables sont dans la même devise de référence et peuvent donc être additionnées pour générer une valeur totale d'achat agrégée (une valeur d'achat récapitulative).
Convertir les objectifs en clés
Avec 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: utiliser une structure de clés précise
- Stratégie B: deux structures clés grossières.
Stratégie A: une arborescence profonde (une structure de clés précise)
Dans la stratégie A, vous utilisez une structure de clés 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 en tant que nombre d'achats.
- Type de clé 1: type d'objectif de mesure = 1, que vous décidez de définir en tant que 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 "d'une arborescence profonde" :
- Chaque valeur récapitulative des rapports récapitulatifs est associée à toutes les dimensions dont vous effectuez le suivi.
- Vous pouvez cumuler ces valeurs récapitulatives avec chacune de ces dimensions. Ces valeurs peuvent ainsi être aussi détaillées que le nombre de dimensions dont vous disposez.
Avec la stratégie A, vous répondriez à vos questions comme suit:
| Question | Réponse |
|---|---|
| Quelles catégories de produits sont les plus utiles dans chaque région ? | Additionnez le nombre et les valeurs d'achats récapitulatifs figurant dans les rapports récapitulatifs, pour toutes les campagnes. Vous obtenez ainsi le nombre d'achats et la valeur par identifiant géographique et par catégorie de produits. Pour chaque région, comparez la valeur des achats et le nombre de produits de différentes catégories. |
| Quelles sont les stratégies de campagne les plus efficaces dans chaque région ? | Additionnez le nombre et les valeurs d'achats récapitulatifs figurant dans les rapports récapitulatifs, pour toutes les catégories de produits. Vous obtenez ainsi le nombre d'achats et la valeur par ID de campagne et par ID géographique. Pour chaque région, comparez la valeur des achats et leur nombre pour différentes campagnes. |
Avec la stratégie A, vous pouvez aussi répondre directement à cette troisième question:
"Quel est le chiffre d'affaires généré par chaque produit par mes campagnes dans chaque zone géographique ?"
Même si les valeurs récapitulatives comportent du bruit, vous pouvez déterminer quand les différences de valeur mesurée entre chaque campagne ne sont pas dues uniquement au bruit. Pour savoir comment procéder, consultez Comprendre le bruit.
Stratégie B: deux arbres peu profonds (deux structures clés grossières)
Dans la stratégie B, vous utilisez deux structures de clés grossières, chacune comprenant 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 atteindre deux objectifs de mesure.
- Type d'objectif de mesure = 0, que vous décidez de définir en tant que nombre d'achats.
- Type d'objectif de mesure = 1, que vous décidez de définir en tant que valeur d'achat.
Vous vous retrouvez avec 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 de synthèse se présentent comme suit:
Vous pouvez considérer la stratégie B comme une stratégie composée de "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 avec chacune des dimensions de ces ensembles. Cela signifie que ces cumuls ne sont pas aussi profonds 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:
| Question | Réponse |
|---|---|
| Quelles catégories de produits sont les plus utiles dans chaque région ? | Accédez directement au nombre et aux valeurs d'achats récapitulatifs figurant dans les rapports récapitulatifs. |
| Quelles sont les stratégies de campagne les plus efficaces dans chaque région ? | Accédez directement au nombre et aux valeurs d'achats récapitulatifs figurant dans les rapports récapitulatifs. |
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 que vous n'avez qu'une seule structure de clé à gérer.
Cependant, 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 comporte du bruit. 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 affichées dans les rapports récapitulatifs vous fournissent déjà les informations dont vous avez besoin. Cela signifie que la stratégie B entraînera probablement un impact moindre du bruit que la stratégie A.
Comment devez-vous déterminer la stratégie à adopter ? 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 décider:
- Collectez l'équivalent d'un mois de données grâce aux clés précises (stratégie A). Comme 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 hebdomadaires et la valeur des achats.
Dans cet exemple, supposons que le nombre d'achats hebdomadaires et la valeur des achats soient suffisamment élevés pour que la stratégie A génère un pourcentage de bruit que vous jugez acceptable pour votre cas d'utilisation.
Étant donné que la stratégie A est plus simple et engendre un impact négatif 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 ayez sélectionné SHA-256. Vous pouvez également utiliser un algorithme plus simple et moins sécurisé, comme MD5.
Dans le navigateur: définir les clés et les valeurs
Maintenant que vous avez choisi une structure de clés et un algorithme de hachage, vous êtes prêt à enregistrer des clés et des valeurs lorsque les utilisateurs cliquent sur des annonces ou voient des annonces, puis effectuent une conversion.
Voici une présentation des en-têtes que vous allez définir pour enregistrer des clés et des valeurs dans le navigateur:
Définir les é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 élément de clé) connue au moment de la diffusion de l'annonce.
Générons les éléments clés:
| Pièce de clé côté source pour l'ID de clé... | Chaîne contenant les valeurs de dimension que vous souhaitez définir | Hachage de cette chaîne au format hexadécimal, réduit aux 64 premiers bits (64/4 = 16 caractères1) | Hachage hexadécimal avec des zéros ajoutés pour simplifier l'opération XOR. Il s'agit de la clé côté source. |
|---|---|---|---|
| key_purchaseCount | NB, IDCampagne=12, ID géographique=7 | 0x3cf867903fbb73ec | 0x3cf867903fbb73ec0000000000000000 |
| key_purchaseValue | VALEUR, IDCampagne=12, ID géographique=7 | 0x245265f432f16e73 | 0x245265f432f16e730000000000000000 |
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 de clés dans le navigateur, de sorte que les éléments de clé côté source et côté déclencheur puissent être mappés entre eux 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 des événements (ID de l'événement source et données du déclencheur) et la clé d'agrégation peuvent correspondre.
Vous pouvez utiliser les deux rapports si, par exemple, vous prévoyez d'utiliser les rapports au niveau des événements pour exécuter des modèles et identifier les types d'annonces qui ont tendance à générer le plus grand nombre 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 demande:
- Définissez les éléments de clé côté conversion (côté déclencheur) pour compléter la clé.
Vous allez définir 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 terminer la clé
Générons les éléments clés:
| Pièce de clé côté déclencheur pour l'ID de clé... | Chaîne contenant les valeurs de dimension que vous souhaitez définir | Hachage de cette chaîne au format hexadécimal, réduit aux 64 premiers bits (64/4 = 16 caractères1) | Hachage hexadécimal avec des zéros ajoutés pour simplify l'opération XOR. Il s'agit de la clé côté source. |
|---|---|---|---|
| key_purchaseCount | CatégorieProduit=25 | 0x1c7ce88c4904bbe2 | 0x0000000000000000f9e491fe37e55a0c |
| key_purchaseValue | (identique) | (identique) | (identique) |
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 répertoriant 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 augmenter afin de réduire le bruit.
Supposons qu'un achat de 52 € ait été effectué pour le type de produit 25.
Vous ne les définissez pas directement en tant que valeurs agrégables:
key_purchaseCount: 1 conversionkey_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, un montant maximal de CONTRIBUTION_BUDGET/2 est alloué à chaque objectif (=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 anomalies. Par exemple, très peu d'utilisateurs ont dépensé plus que cette somme, mais vous pouvez décider de les ignorer.
Votre facteur de scaling pour la valeur des achats 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 sur une annonce ou par vue (événement source).
Vous pouvez maintenant définir les valeurs suivantes:
key_purchaseCount: 1*32 768 = 32 768key_purchaseValue: 52 x 22 = 1 144
En pratique, vous devez les définir comme suit, à l'aide de 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 à 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 elles étaient lisibles en texte clair:
[ {
key: 0x3cf867903fbb73ecf9e491fe37e55a0c, // = source-side key piece XOR 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 XOR 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 même rapport agrégable.
Demander un rapport récapitulatif
- Rapports agrégables par lot Suivez les conseils fournis dans la section Traitement par lot.
- Générez les clés dont vous souhaitez afficher les 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 x ID géographique 7 x catégorie de produits 25, procédez comme suit :
- Générez l'élément de clé côté source, comme vous l'avez fait pour le définir dans le navigateur.
- Générez l'élément de clé côté déclencheur, comme vous l'avez fait pour le définir dans le navigateur.
| Métrique souhaitée1 | Clé côté source | Clé côté déclencheur | Clé de la requête envoyée au service d'agrégation2 |
|---|---|---|---|
| Nombre total d'achats (COUNT) | 0x3cf867903fbb73ec 0000000000000000 |
0x00000000000000 00f9e491fe37e55a0c |
0x3cf867903fbb73 ecf9e491fe37e55a0c |
| Valeur totale des achats (VALUE) | 0x245265f432f16e73 0000000000000000 |
0x0000000000000000 f9e491fe37e55a0c |
0x245265f432f16e73 f9e491fe37e55a0c |
- Demandez des données récapitulatives au service d'agrégation pour ces clés.
Gérer le rapport récapitulatif
En fin de compte, 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 deuxième bucket correspond à la clé VALUE en binaire. Notez que si les clés sont hétérogènes (COUNT vs VALUE), elles figurent dans le même rapport.
Réduire les valeurs
- 2 558 500 fait référence au nombre d'achats pour cette clé, augmenté en fonction du facteur de scaling précédemment calculé. 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 = valeur totale des achats de 31 230 €.
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.
Within the reporting time period, campaign #12
run in Europe drove $31,230 of purchases (± noise)
for the product category #25.