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é. 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:
Réessayer d'importer le rapport
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 est hors connexion, la nouvelle tentative aura lieu une minute après sa remise en ligne. 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 n'est pas connecté, il réessayera d'envoyer le rapport avec la prochaine tâche de création de rapports qui s'exécutera une fois que l'appareil se sera de nouveau 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 en retard 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 être utilisées pour déterminer le délai d'attente des rapports en retard.
Les rapports cumulés instantanés peuvent être utilisés pour réduire le risque de rapports retardés.
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 applique une règle "pas 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 entraîner 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 ayant le même ID partagé ne contribuent qu'à un seul rapport récapitulatif. Cela signifie que les rapports qui correspondent à un ID partagé doivent tous être inclus dans un même lot. Par exemple, si le rapport X et le rapport Y ont le même ID partagé, ils doivent être inclus dans le même lot pour éviter que les rapports ne soient supprimés en raison de doublons.
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.
Rapports en double dans les 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. Si un lot contient plusieurs rapports avec le même report_id, seul le premier rapport sera agrégé. Les autres seront considérés comme des doublons et supprimés sans notification. L'agrégation se poursuivra normalement et aucune erreur ne sera envoyée.
Bien que cela ne soit pas obligatoire, la technologie publicitaire peut s'attendre à une amélioration des 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 ayant le même ID partagé doivent être inclus 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 avec le même ID partagé e679aa sont regroupés dans des lots 1 et 2 différents. Étant donné que le budget de tous les rapports avec l'ID partagé e679aa est consommé lors de la génération du rapport récapitulatif du lot 1, le lot 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 des rapports sur l'attribution.
L'agrégation privée ne comporte pas de champ attribution_destination, qui correspond à l'annonceur. Nous vous recommandons de créer des lots 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 du compte 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.
Regrouper 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.