Beim Batching aggregierbarer Berichte ist es wichtig, die Batching-Strategien so zu optimieren, dass die Datenschutzlimits nicht überschritten werden. Im Folgenden finden Sie einige empfohlene Strategien zum Senden von Berichts-Batches an den Aggregationsdienst.
Berichte erfassen
Beachten Sie beim Erstellen von Berichten, die in einen Batch aufgenommen werden sollen, Folgendes:
Wiederholungsversuche für das Hochladen von Berichten
Hinweis:Die Kriterien für Wiederholungsversuche können sich ändern. Die Informationen in diesem Abschnitt werden in diesem Fall aktualisiert.
Sowohl auf Web- als auch auf Betriebssystemplattformen wird versucht, den Bericht dreimal zu senden. Wenn das Senden des Berichts nach dem dritten Versuch fehlschlägt, wird er nicht gesendet. Der ursprüngliche scheduled_report_time-Wert wird unabhängig davon beibehalten, wann der Bericht gesendet werden kann. Die Zeitachse für Wiederholungsversuche ist je nach Plattform unterschiedlich:
- Ein Webbrowser sendet Berichte, wenn er online ist. Wenn der Bericht nicht gesendet werden kann, wird fünf Minuten auf den zweiten und dann 15 Minuten auf den dritten Versuch gewartet. Wenn der Browser offline geht, erfolgt der nächste Versuch eine Minute nach dem erneuten Onlinegehen. Im Web gibt es keine maximale Verzögerung beim Senden von Berichten. Wenn der Browser also offline geht, wird der Bericht, sobald der Browser wieder online ist, gemäß der Richtlinie für Wiederholungsversuche gesendet, unabhängig davon, wie lange der Bericht schon generiert wurde.
- Ein Android-Smartphone hat eine stabile Netzwerkverbindung. Der Job wird also einmal pro Stunde ausgeführt, um Berichte zu senden. Wenn ein Bericht nicht gesendet werden kann, wird der Vorgang in der nächsten Stunde und dann noch einmal in der Stunde danach wiederholt. Wenn das Gerät keine Verbindung hat, wird der Bericht beim nächsten Reporting-Job, der ausgeführt wird, nachdem das Gerät wieder mit dem Netzwerk verbunden ist, noch einmal gesendet. Die maximale Verzögerung beträgt 28 Tage. Das Gerät sendet also keinen Bericht, der vor mehr als 28 Tagen generiert wurde.
Auf Berichte warten
Es wird empfohlen, mit dem Erstellen von Batches zu warten, bis alle Berichte eingegangen sind. Sie können ermittelt werden, indem der scheduled_report_time-Wert mit dem Zeitpunkt verglichen wird, zu dem der Bericht eingegangen ist. Anhand des Zeitunterschieds zwischen den Berichten können Sie festlegen, wie lange Sie auf verspätete Berichte warten möchten. Sehen Sie sich das Feld scheduled_report_time an, während verzögerte Berichte eingehen, und notieren Sie sich die Zeitverzögerung in Stunden, wenn 90%, 95 % und 99% der Berichte eingegangen sind. Anhand dieser Daten lässt sich ermitteln, wie lange gewartet werden soll, bis verspätet eingehende Berichte berücksichtigt werden.
Mit sofortigen aggregierten Berichten lässt sich die Wahrscheinlichkeit verzögerter Berichte verringern.
Im folgenden Bild sehen Sie, wie Berichte, die erst später eintreffen, entsprechend der geplanten Berichtszeit in den entsprechenden Batches gespeichert werden. „Batch T“ steht für scheduled_report_time und „T+X“ für die Wartezeit für verzögerte Berichte. So wird ein zusammenfassender Bericht erstellt, der die meisten Berichte enthält, die im Batch enthalten sind und deren geplante Berichtszeit entspricht.
Zusammenfassbare Berichte
Der Aggregationsdienst hält sich an die Regel „Keine Duplikate“. Diese Regel erzwingt, dass alle aggregierbaren Berichte mit derselben freigegebenen ID im selben Batch enthalten sein müssen.
Nachdem die Berichte erfasst wurden, sollten sie so gebündelt werden, dass alle Berichte mit derselben freigegebenen ID Teil eines Batches sind.
Wenn ein Bericht bereits in einem anderen Batch verarbeitet wurde, kann die Verarbeitung zu einem Fehler aufgrund eines ausgeschöpften Datenschutzbudgets führen. Wenn Sie Berichte richtig zusammenfassen, wird verhindert, dass Batches aufgrund der Regel „Keine Duplikate“ abgelehnt werden.
Eine gemeinsame ID ist ein Schlüssel, der für jeden Bericht generiert wird, um die Abrechnung aggregierbarer Berichte nachzuverfolgen. Die freigegebene ID sorgt dafür, dass Berichte mit derselben freigegebenen ID nur zu einem zusammenfassenden Bericht beitragen. Das bedeutet, dass alle Berichte, die einer gemeinsamen ID zugeordnet sind, in einem einzigen Batch enthalten sein müssen. Wenn beispielsweise Bericht X und Bericht Y dieselbe freigegebene ID haben, müssen sie im selben Batch enthalten sein, damit keine Berichte aufgrund von Duplikaten verworfen werden.
Das folgende Bild zeigt die shared_info-Komponenten, die gehasht werden, um eine gemeinsame ID zu generieren.
Das folgende Bild zeigt, wie zwei verschiedene Berichte dieselbe freigegebene ID haben können:
Hinweis:scheduled_report_time wird nach Stunde und source_registration_time nach Tag gekürzt. Außerdem wird report_id nicht beim Erstellen einer gemeinsamen ID verwendet. Die Zeitgranularität kann in Zukunft aktualisiert werden.
Berichte in Batches duplizieren
Das Feld shared_info in einem aggregierbaren Bericht enthält eine UUID im Feld report_id, mit der doppelte Berichte in einem Batch identifiziert werden. Wenn in einem Batch mehrere Berichte mit demselben report_id vorhanden sind, wird nur der erste Bericht zusammengefasst. Die anderen werden als Duplikate betrachtet und ohne Benachrichtigung verworfen. Die Zusammenfassung wird wie gewohnt fortgesetzt und es werden keine Fehler gesendet.
Obwohl dies nicht erforderlich ist, können Ad-Tech-Unternehmen mit einer Leistungssteigerung rechnen, wenn sie die doppelten Berichte mit denselben Berichts-IDs vor der Aggregation herausfiltern.
Die report_id ist für jeden Bericht eindeutig.
Doppelte Berichte in Batches
Jedem Bericht wird eine gemeinsame ID zugewiesen. Diese ID wird aus kombinierten Datenpunkten generiert, die aus dem Feld shared_info des Berichts stammen. Mehrere Berichte können dieselbe freigegebene ID haben und jeder Batch kann mehrere freigegebene IDs enthalten. Alle Berichte mit derselben freigegebenen ID müssen in denselben Batch aufgenommen werden. Wenn Berichte mit derselben freigegebenen ID in mehreren Batches landen, wird nur der erste Batch akzeptiert und die anderen werden als Duplikate abgelehnt. Um dies zu verhindern, müssen Batches entsprechend erstellt werden.
Das folgende Bild zeigt ein Beispiel, in dem Berichte mit derselben freigegebenen ID in verschiedenen Batches dazu führen können, dass der spätere Batch fehlschlägt. Auf dem Bild sehen Sie, dass zwei oder mehr Berichte mit derselben freigegebenen ID e679aa in verschiedenen Batches 1 und 2 zusammengefasst werden. Da das Budget für alle Berichte mit der gemeinsamen ID e679aa bei der Erstellung des Übersichtsberichts für Batch 1 aufgebraucht wird, ist Batch 2 nicht zulässig und schlägt mit einem Fehler fehl.
Batch-Berichte
Im Folgenden finden Sie empfohlene Methoden zum Erstellen von Batchberichten, um Duplikate zu vermeiden und die Abrechnung von aggregierten Berichten zu optimieren.
Batch nach Werbetreibendem
Hinweis:Diese Strategie wird nur für die Aggregation von Attribution Reporting empfohlen.
Bei Private Aggregation gibt es kein attribution_destination-Feld, das den Werbetreibenden angibt. Es wird empfohlen, die Batch-Verarbeitung nach Werbetreibenden vorzunehmen. Das bedeutet, dass Berichte, die zu einem einzelnen Werbetreibenden gehören, im selben Batch enthalten sein sollten, um das Limit für aggregierbare Berichte pro Batch nicht zu überschreiten. Der Werbetreibende ist ein Feld, das bei der Generierung der freigegebenen ID berücksichtigt wird. Berichte mit demselben Werbetreibenden können also auch dieselbe freigegebene ID haben. In diesem Fall müssen sie sich im selben Batch befinden, um Fehler zu vermeiden.
Batch nach Zeit
Es wird empfohlen, beim Batching die geplante Berichtszeit des Berichts (shared_info.scheduled_report_time) zu berücksichtigen. Die Zeit für geplante Berichte wird bei der gemeinsamen ID-Generierung auf die Stunde gekürzt. Daher sollten Berichte mindestens stündlich gebündelt werden. Das bedeutet, dass alle Berichte mit geplanter Berichtszeit innerhalb derselben Stunde in denselben Batch aufgenommen werden sollten, um zu vermeiden, dass Berichte mit derselben gemeinsamen ID in mehreren Batches vorhanden sind, was zu Jobfehlern führt.
Batch-Häufigkeit und Rauschen
Es wird empfohlen, die Auswirkungen von Rauschen auf die Häufigkeit der Verarbeitung aggregierbarer Berichte zu berücksichtigen. Wenn aggregierbare Berichte häufiger in Batches verarbeitet werden, z. B. einmal pro Stunde, sind weniger Conversion-Ereignisse enthalten und Rauschen hat einen größeren relativen Einfluss. Wenn die Häufigkeit verringert wird und Berichte einmal pro Woche verarbeitet werden, hat Rauschen eine geringere relative Auswirkung. Um die Auswirkungen von Rauschen auf Batches besser zu verstehen, können Sie mit dem Noise Lab experimentieren.