Lorsque vous regroupez des rapports agrégables par lot, il est important d'optimiser les stratégies de traitement par lot afin de ne pas dépasser les limites de confidentialité. Vous trouverez ci-dessous quelques stratégies recommandées pour envoyer des lots de rapports au service d'agrégation.
Collecter des rapports
Lorsque vous collectez des rapports à inclure dans un lot, tenez compte des points suivants:
Nouvelles tentatives d'importation de rapports
Remarque:Les critères de nouvelle tentative sont susceptibles d'être modifiés. Les informations de cette section seront mises à jour dans ce cas.
Sur les plates-formes Web et d'OS, une plate-forme tente d'envoyer le rapport trois fois, mais si l'envoi échoue après le troisième essai, il n'est pas envoyé. La valeur scheduled_report_time d'origine est conservée, quel que soit le moment où le rapport peut être envoyé. Le calendrier des nouvelles tentatives varie selon la plate-forme:
- Un navigateur Web envoie des rapports lorsqu'il est en ligne. Si l'envoi du rapport échoue, cinq minutes d'attente sont nécessaires pour la deuxième tentative, puis 15 minutes pour la troisième. Si le navigateur se déconnecte, la prochaine tentative aura lieu une minute après sa prochaine connexion. Il n'existe pas de délai maximal d'envoi des rapports sur le Web. Cela signifie que si le navigateur passe hors connexion, quel que soit le temps écoulé depuis la génération du rapport, il tentera de l'envoyer conformément à la stratégie de nouvelle tentative.
- Un téléphone Android dispose d'une connexion réseau cohérente. Par conséquent, la tâche sera exécutée pour envoyer des rapports une fois par heure. Cela signifie que si l'envoi d'un rapport échoue, il sera réessayé l'heure suivante, puis une nouvelle fois l'heure suivante. Si l'appareil ne dispose d'aucune connexion, il tentera d'envoyer le rapport avec la tâche de création de rapports suivante qui s'exécutera une fois l'appareil connecté au réseau. Le délai maximal est de 28 jours, ce qui signifie que l'appareil n'envoie pas de rapport généré il y a plus de 28 jours.
Attendre les rapports
Nous vous recommandons d'attendre les rapports en retard lorsque vous collectez des rapports pour les regrouper. Vous pouvez déterminer les rapports tardifs en comparant la valeur scheduled_report_time à la date de réception du rapport. La différence de temps entre ces rapports vous aidera à déterminer combien de temps vous pouvez attendre les rapports en retard. Par exemple, lorsque les rapports différés sont collectés, vérifiez le champ scheduled_report_time et notez le délai en heures, car 90%, 95 % et 99% des rapports sont reçus. Ces données peuvent servir à déterminer le temps d'attente pour les rapports en retard.
Les rapports cumulés instantanés peuvent être utilisés pour réduire le risque de retard dans la diffusion des rapports.
L'image suivante montre comment les rapports arrivés en retard sont stockés dans les lots appropriés en fonction de l'heure de planification du rapport. Le lot T représente scheduled_report_time, et T+X représente le temps d'attente pour les rapports retardés. Vous obtenez ainsi un rapport récapitulatif qui inclut la majorité des rapports inclus dans le lot, qui correspondent à l'heure de planification du rapport.
Comptabilisation des rapports agrégables
Le service d'agrégation gère une règle d'absence de doublons. Cette règle exige que tous les rapports agrégables ayant le même ID partagé doivent être inclus dans le même lot.
Une fois les rapports collectés, ils doivent être regroupés de sorte que tous les rapports ayant le même ID partagé fassent partie d'un même lot.
Si un rapport a déjà été traité dans un autre lot, le traitement peut générer une erreur liée à l'épuisement du budget de confidentialité. Le traitement par lot des rapports permet d'éviter que les lots ne soient rejetés en raison de la règle "Pas de doublons".
Un ID partagé est une clé générée pour chaque rapport afin de suivre la comptabilité des rapports agrégables. L'ID partagé garantit que les rapports avec le même ID partagé ne contribuent qu'à un seul rapport récapitulatif. Cela signifie que les rapports associés à un ID partagé doivent tous être inclus dans un seul lot. Par exemple, si les rapports X et Y ont le même ID partagé, ils doivent être inclus dans le même lot pour éviter que des rapports ne soient supprimés à des fins de duplication.
L'image suivante montre les composants shared_info hachés ensemble pour générer un ID partagé.
L'image suivante montre comment deux rapports différents peuvent avoir le même ID partagé:
Remarque:scheduled_report_time est tronqué par heure et source_registration_time par jour. De plus, report_id n'est pas utilisé pour créer des ID partagés. La granularité temporelle pourra être modifiée à l'avenir.
Dupliquer des rapports dans des lots
Le champ shared_info d'un rapport agrégable contient un UUID dans le champ report_id, qui permet d'identifier les rapports en double dans un lot. S'il existe plusieurs rapports avec le même report_id dans un lot, seul le premier sera agrégé, et les autres seront considérés comme des doublons et supprimés sans notification. L'agrégation se déroulera normalement et aucune erreur n'est envoyée.
Bien que cela ne soit pas obligatoire, la technologie publicitaire peut s'attendre à obtenir des gains de performances en filtrant les rapports en double avec les mêmes ID de rapport avant l'agrégation.
L'report_id est unique pour chaque rapport.
Rapports en double entre les lots
Chaque rapport est associé à un ID partagé, qui est généré à partir de points de données combinés provenant du champ shared_info du rapport. Plusieurs rapports peuvent avoir le même ID partagé, et chaque lot peut contenir plusieurs ID partagés. Tous les rapports associés au même ID partagé doivent figurer dans le même lot. Si des rapports avec le même ID partagé se retrouvent dans plusieurs lots, seul le premier lot sera accepté, et les autres seront refusés en tant que doublons. Pour éviter cela, les lots doivent être créés de manière appropriée.
L'image suivante montre un exemple où les rapports avec le même ID partagé entre les lots peuvent entraîner l'échec du lot ultérieur. Dans l'image, vous pouvez voir que deux rapports ou plus ayant le même ID partagé e679aa sont regroupés dans différents lots n° 1 et n° 2. Étant donné que le budget de tous les rapports avec l'ID partagé e679aa est utilisé lors de la génération du rapport récapitulatif du lot 1, le lot n° 2 n'est pas autorisé et échoue avec une erreur.
Rapports par lot
Vous trouverez ci-dessous des méthodes recommandées pour créer des rapports par lot afin d'éviter les doublons et d'optimiser la comptabilité des rapports agrégés.
Par lot par annonceur
Remarque:Cette stratégie n'est recommandée que pour l'agrégation Attribution Reporting.
Private Aggregation ne comporte pas de champ attribution_destination, qui correspond à l'annonceur. Nous vous recommandons de les regrouper par annonceur, c'est-à-dire d'inclure les rapports appartenant à un seul annonceur dans le même lot, afin d'éviter d'atteindre la limite de comptes de rapports agrégables pour chaque lot. Le champ "Annonceur" est pris en compte lors de la génération d'ID partagés. Par conséquent, les rapports concernant le même annonceur peuvent également avoir le même ID partagé, ce qui nécessite qu'ils se trouvent dans le même lot pour éviter les erreurs.
Traitement par lot par heure
Nous vous recommandons de tenir compte de l'heure de planification du rapport (shared_info.scheduled_report_time) lors de l'exécution par lot. L'heure de planification des rapports est tronquée à l'heure lors de la génération de l'ID partagé. Par conséquent, les rapports doivent être regroupés par lot à des intervalles d'une heure minimum. Autrement dit, tous les rapports dont l'heure de planification se situe dans la même heure doivent être regroupés dans le même lot pour éviter d'avoir des rapports avec le même ID partagé dans plusieurs lots, ce qui entraînerait des erreurs de tâche.
Fréquence de traitement par lots et bruit
Nous vous recommandons de tenir compte de l'impact du bruit sur la fréquence de traitement des rapports agrégables. Si les rapports agrégables sont groupés plus fréquemment (par exemple, les rapports sont traités une fois par heure), moins d'événements de conversion seront inclus et le bruit aura un impact relatif plus important. Si la fréquence est réduite et que les rapports sont traités une fois par semaine, le bruit aura un impact relatif plus faible. Pour mieux comprendre l'impact du bruit sur les lots, testez le laboratoire de bruit.