Le service d'agrégation génère des rapports récapitulatifs sur les données de conversion détaillées et les mesures de la couverture à partir de rapports bruts agrégables. Pour préserver la confidentialité et la sécurité des données utilisateur, le service d'agrégation utilise un framework compatible avec la confidentialité différentielle afin de quantifier et de limiter la quantité d'informations révélées par ces rapports sur les utilisateurs individuels.
Ce guide présente les outils et les stratégies permettant de créer des rapports agrégables qui aident à protéger les données des utilisateurs individuels:
- Créer des rapports récapitulatifs avec du bruit ajouté
- Définir un budget de contribution
- Stratégies de traitement par lot des rapports
- Gérer les rapports en double par lot
- Gérer les rapports avec un ID partagé commun
- Utiliser des clés d'agrégation prédéclarées
Rapports de synthèse avec bruit ajouté
Lorsque vous regroupez des rapports agrégables, le service d'agrégation crée un rapport récapitulatif. Ce rapport récapitulatif est un agrégat de toutes les contributions de toutes les clés de domaine prédéfinies, avec un bruit statistique supplémentaire.
Le bruit ajouté aux rapports ne dépend pas du nombre de rapports agrégés, des valeurs de rapports individuelles ni des valeurs de rapports agrégées. Le bruit est extrait d'une version discrète de la distribution de Laplace et est mis à l'échelle du budget de contribution (sensibilité L1) appliqué par le client en fonction de l'API de mesure correspondante et du paramètre de confidentialité epsilon.
Pour en savoir plus sur le bruit et ses conséquences sur les données des rapports, consultez Comprendre le bruit dans les rapports récapitulatifs.
Budget de contribution
Pour contrôler la sensibilité d'un rapport récapitulatif, le nombre de contributions transmises dans un appel est associé à une limite de délimitation des contributions spécifique, également appelée budget de contribution. Le budget de contribution varie selon que vous utilisez l'API Attribution Reporting ou l'API Private Aggregation.
Pour savoir comment définir des budgets de contribution pour chaque API, consultez les sections de documentation des API suivantes:
- Contrôle des contributions et budgétisation avec l'API Attribution Reporting
- Limites de contribution de l'API Private Aggregation
- Contrôle et budgét des contributions de l'API Private Aggregation
Stratégies de traitement par lot des rapports
Lorsque vous regroupez des rapports agrégables, il est important d'optimiser les stratégies de traitement par lot afin de ne pas dépasser les limites de confidentialité. Pour effectuer un traitement par lot correct, deux concepts importants sont la règle d'absence de doublons et l'idée de lots disjoints.
Règle "Pas de doublons"
Le service d'agrégation applique une règle d'interdiction des doublons. Cette règle indique qu'un rapport agrégable, qui est identifié de manière unique par report_id, ne peut apparaître qu'une seule fois dans un même lot. Si un rapport agrégable apparaît plusieurs fois par lot, le premier rapport est inclus dans l'agrégation, les rapports suivants avec le même report_id sont supprimés, et le lot se termine correctement.
La règle stipule également que le même identifiant partagé ne peut pas apparaître dans plusieurs lots. Si un ID partagé a déjà été inclus dans un lot précédent ayant abouti, un lot ultérieur incluant également le même ID partagé échouera.
Sans la règle "Pas de doublons", un pirate informatique pourrait obtenir des informations sur le contenu d'un lot spécifique en manipulant le contenu des lots en incluant des copies en double d'un rapport dans un seul lot ou plusieurs.
Pour en savoir plus sur l'application de la règle "Pas de doublons" dans un lot de rapports ou plusieurs lots, consultez Rapports en double dans les lots.
Lots disjoints
Pour éviter les chevauchements entre les lots, le service d'agrégation applique des lots disjoints. Cela signifie que deux lots ou plus ne peuvent pas contenir de rapports qui partagent un ID partagé commun. Un ID partagé est une combinaison de données collectées à partir du champ shared_info d'un rapport agrégable, ainsi que de l'ID de filtrage de la requête d'exécution. Si aucun ID de filtrage n'est spécifié, la valeur par défaut est 0.
Dans l'exemple de champ shared_info suivant, vous pouvez voir l'API, attribution_destination (pour Attribution Reporting), reporting_origin, scheduled_report_time, source_registration_time (pour Attribution Reporting) et version. Ces champs, à l'exception de report_id, ainsi que l'ID de filtrage de la requête d'emploi, contribuent à l'ID partagé.
"shared_info": {
"API": "attribution-reporting",
"attribution_destination": "https://privacy-sandbox-demos-shop.dev",
"report_id": "5b052748-f5fb-4f14-b291-de03484ed59e",
"reporting_origin": "https://privacy-sandbox-demos-dsp.dev",
"scheduled_report_time": "1707786751",
"source_registration_time": "0",
"version": "0.1"
}
Étant donné que source_registration_time est tronqué par jour et scheduled_report_time par heure, certains rapports ont le même ID partagé. Dans cet exemple, Report1 et Report2 partagent des champs d'informations. Les deux rapports ont la même API, la même version, les mêmes attribution_destination, reporting_origin et source_registration_time. Étant donné que report_id ne fait pas partie de l'ID partagé, vous pouvez ignorer cette différence.
Dans les exemples suivants pour Report1 et Report2, la valeur scheduled_report_time est la même.
Report1 a partagé les informations suivantes:
"shared_info": {
"API": "attribution-reporting",
"attribution_destination": "https://shop.dev",
"report_id": "5b052748-...",
"reporting_origin": "https://dsp.dev",
"scheduled_report_time": "1708376890",
"source_registration_time": "0",
"version": "0.1"
}
Informations partagées par Report2:
"shared_info": {
"API": "attribution-reporting",
"attribution_destination": "https://shop.dev",
"report_id": "5b052748-...",
"reporting_origin": "https://dsp.dev",
"scheduled_report_time": "1708376890",
"source_registration_time": "0",
"version": "0.1"
}
Les heures de planification des rapports sont "19 février 2024 21h08:10" pour Report1 et "19 février 2024 22h55:10" pour Report2. Étant donné que la valeur du champ scheduled_report_time est tronquée à l'heure, les deux rapports contiennent 1708376890 (valeur encodée pour "19 février 2024 21h") comme valeur du champ scheduled_report_time.
Étant donné que tous les autres champs et l'ID de filtrage sont identiques, les deux rapports ont le même ID partagé. Étant donné que les deux rapports ont le même ID partagé, ils doivent tous deux être inclus dans le même lot.
Si Report1 a été traité dans un lot précédent et que Report2 est traité dans un lot ultérieur, le lot avec Report2 échoue avec une erreur PRIVACY_BUDGET_EXHAUSTED. Dans ce cas, supprimez les rapports avec l'ID partagé qui ont déjà été groupés dans des lots précédents, puis réessayez. Pour en savoir plus sur cette erreur, consultez Codes d'erreur et mesures d'atténuation pour le service d'agrégation.
Clés d'agrégation prédéclarées
Lorsque vous envoyez un lot au service d'agrégation, il doit inclure à la fois les rapports agrégables reçus de l'origine des rapports et le fichier de domaine de sortie. Le domaine de sortie contient les clés, ou buckets, qui sont récupérées à partir des rapports agrégables.
Du point de vue de la confidentialité, du bruit est ajouté à toutes les clés prédéclarées dans le domaine de sortie, même lorsqu'aucun rapport réel ne correspond à une clé particulière. Spécifier le domaine de sortie permet de se protéger contre une attaque où la présence d'une clé dans la sortie révèle quelque chose sur un seul utilisateur ou événement. Par exemple, si vous n'avez présenté une campagne qu'à un seul utilisateur, la réception d'une clé dans la sortie indique que l'utilisateur a effectué une conversion ultérieurement, même en présence de bruit. En spécifiant ce domaine en premier, vous pouvez être sûr qu'il ne révèle rien sur les contributions des utilisateurs.
Vous pouvez déclarer ces clés 128 bits dans l'API Attribution Reporting ou l'API Private Aggregation, et les utiliser pour encoder les dimensions que vous souhaitez suivre.
Seules les clés prédéclarées sont prises en compte pour l'agrégation et incluses dans le rapport récapitulatif. Un bruit statistique est ajouté aux valeurs agrégées des buckets du rapport récapitulatif, ce qui se reflète dans le rapport récapitulatif créé.
Si une clé d'agrégation est incluse dans le fichier de domaine de sortie, mais qu'elle ne se trouve pas dans un rapport par lot, même si la valeur agrégée est nulle, le rapport récapitulatif final sera probablement différent de zéro en raison du bruit ajouté pour préserver la confidentialité.