Der Aggregationsdienst erstellt Zusammenfassungsberichte mit detaillierten Conversion-Daten und Reichweitenmessungen aus Rohdaten aggregierbarer Berichte. Um die Daten der Nutzer zu schützen und zu sichern, verwendet der Aggregationsdienst ein Framework, das Differential Privacy (DP) unterstützt. Damit wird die Menge der Informationen, die in diesen Berichten über einzelne Nutzer offengelegt werden, quantifiziert und begrenzt.
In diesem Leitfaden werden Tools und Strategien zum Erstellen von aggregierten Berichten beschrieben, mit denen Daten zu einzelnen Nutzern geschützt werden können:
- Zusammenfassungsberichte mit hinzugefügtem Rauschen erstellen
- Beitragsbudget festlegen
- Strategien für die Berichterstellung im Batch
- Vordefinierte Aggregationsschlüssel verwenden
Zusammenfassungsberichte mit hinzugefügtem Rauschen
Wenn Sie aggregierbare Berichte im Batch erstellen, erstellt der Aggregationsdienst einen Zusammenfassungsbericht. Dieser Zusammenfassungsbericht ist eine Zusammenfassung aller Beiträge aller vordefinierten Domainschlüssel mit hinzugefügtem statistischem Rauschen.
Die den Berichten hinzugefügten Schwankungen hängen nicht von der Anzahl der zusammengefassten Berichte, den einzelnen Berichtswerten oder den zusammengefassten Berichtswerten ab. Der Rauschanteil wird aus einer diskreten Version der Laplace-Verteilung gezogen und auf das Beitragsbudget (L1-Empfindlichkeit) skaliert, das vom Kunden abhängig von der entsprechenden Mess-API und dem Datenschutzparameter epsilon erzwungen wird.
Weitere Informationen zu Abweichungen und ihren Auswirkungen auf Berichtsdaten finden Sie unter Abweichungen in Zusammenfassungsberichten.
Beitragsbudget
Um die Sensitivität eines Zusammenfassungsberichts zu steuern, ist die Anzahl der in einem Aufruf übergebenen Beiträge an ein bestimmtes Grenzlimit für Beiträge gebunden, auch als Beitragsbudget bezeichnet. Das Beitragsbudget variiert je nachdem, ob Sie die Attribution Reporting API oder die Private Aggregation API verwenden.
Weitere Informationen zum Festlegen von Beitragsbudgets für die einzelnen APIs finden Sie in den folgenden Abschnitten der API-Dokumentation:
- Beitragsbegrenzung und Budgetierung mit der Attribution Reporting API
- Beitragslimits für die Private Aggregation API
- Bei der Private Aggregation API Beiträge begrenzen und Budgets festlegen
Strategien für die Berichterstellung im Batchverfahren
Wenn Sie aggregierbare Berichte im Batch erstellen, sollten Sie die Batch-Strategien so optimieren, dass die Datenschutzlimits nicht überschritten werden. Zwei wichtige Konzepte für die korrekte Zusammenstellung von Berichten sind die Regel „Keine Duplikate“ und die Idee von nicht überlappenden Batches.
Regel „Keine Duplikate“
Der Aggregationsdienst erzwingt die Regel „Keine Duplikate“. Diese Regel besagt, dass ein aggregierbarer Bericht, der durch report_id eindeutig identifiziert wird, nur einmal in einem einzelnen Batch vorkommen darf. Wenn ein aggregierbarer Bericht mehrmals pro Batch auftritt, wird der erste Bericht in die Aggregation einbezogen, nachfolgende Berichte mit derselben report_id werden verworfen und der Batch wird erfolgreich abgeschlossen.
Außerdem darf dieselbe gemeinsame ID nicht in mehr als einem Batch vorkommen. Wenn eine gemeinsame ID bereits in einem vorherigen erfolgreichen Batch enthalten war, schlägt ein späterer Batch fehl, der dieselbe gemeinsame ID enthält.
Ohne die Regel „Keine Duplikate“ könnte ein Angreifer Einblick in den Inhalt eines bestimmten Batches erhalten, indem er den Inhalt der Batches manipuliert, indem er in einem oder mehreren Batches doppelte Kopien eines Berichts einfügt.
Weitere Informationen zum Erzwingen der Regel „Keine Duplikate“ innerhalb eines Berichts-Batches oder mehrerer Berichts-Batches finden Sie unter Duplizierte Berichte innerhalb von Batches.
Disjunkte Batches
Um Überschneidungen zwischen Batches zu vermeiden, erzwingt der Aggregationsdienst nicht überlappende Batches. Das bedeutet, dass zwei oder mehr Batches keine Berichte enthalten dürfen, die dieselbe gemeinsame ID haben. Eine freigegebene ID ist eine Kombination aus Daten, die aus dem Feld shared_info eines aggregierbaren Berichts erfasst wurden, und der Filter-ID aus der Jobanfrage. Wenn keine Filter-ID angegeben ist, wird standardmäßig „0“ verwendet.
Im folgenden Beispiel für das Feld shared_info sehen Sie die API, attribution_destination (für Attribution Reporting), reporting_origin, scheduled_report_time, source_registration_time (für Attribution Reporting) und version. Diese Felder, mit Ausnahme von report_id, sowie die Filter-ID aus der Jobanfrage tragen zur gemeinsamen ID bei.
"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"
}
Da source_registration_time auf den Tag und scheduled_report_time auf die Stunde gekürzt wird, gibt es Berichte mit derselben gemeinsamen ID. In diesem Beispiel haben Bericht 1 und Bericht 2 gemeinsame Infofelder. Beide Berichte haben dieselbe API, Version, attribution_destination, reporting_origin und source_registration_time. Da report_id nicht Teil der freigegebenen ID ist, können Sie diesen Unterschied ignorieren.
In den folgenden Beispielen für Bericht 1 und Bericht 2 ist der Wert für scheduled_report_time identisch.
Freigegebene Informationen zu Report1:
"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"
}
Freigegebene Informationen zu 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"
}
Die geplanten Berichtszeiten sind „19. Februar 2024, 21:08:10 Uhr“ für Bericht1 und „19. Februar 2024, 21:55:10 Uhr“ für Bericht2. Da der Wert für das Feld scheduled_report_time auf die Stunde gekürzt wird, haben beide Berichte 1708376890 (der codierte Wert für „19. Februar 2024, 21:00 Uhr“) als Wert für das Feld scheduled_report_time.
Da alle anderen Felder und die Filter-ID identisch sind, haben beide Berichte dieselbe gemeinsame ID. Da beide Berichte dieselbe gemeinsame ID haben, müssen sie in derselben Batchdatei enthalten sein.
Wenn Bericht1 in einem zuvor erfolgreichen Batch gruppiert wurde und Bericht2 in einem nachfolgenden Batch verarbeitet wird, schlägt der Batch mit Bericht2 mit einem PRIVACY_BUDGET_EXHAUSTED-Fehler fehl. Entfernen Sie in diesem Fall die Berichte mit der gemeinsamen ID, die bereits in früheren Batches zusammengefasst wurden, und versuchen Sie es noch einmal. Weitere Informationen zu diesem Fehler finden Sie unter Fehlercodes und Abhilfemaßnahmen für den Aggregationsdienst.
Vordefinierte Aggregationsschlüssel
Wenn Sie einen Batch an den Aggregationsdienst senden, muss er sowohl die aggregierbaren Berichte enthalten, die vom Berichtsoriginator empfangen werden, als auch die Ausgabedomaindatei. Die Ausgabedomain enthält die Schlüssel oder Buckets, die aus den aggregierbaren Berichten abgerufen werden.
Aus Datenschutzgründen werden allen in der Ausgabedomain vorab deklarierten Schlüsseln Rauschen hinzugefügt, auch wenn kein echter Bericht mit einem bestimmten Schlüssel übereinstimmt. Durch die Angabe der Ausgabedomain wird ein Angriff verhindert, bei dem das Vorhandensein eines Schlüssels in der Ausgabe etwas über einen einzelnen Nutzer oder ein einzelnes Ereignis verrät. Wenn Sie beispielsweise eine Kampagne nur einem Nutzer präsentiert haben und in der Ausgabe ein Schlüssel angezeigt wird, bedeutet das, dass der Nutzer später eine Conversion ausgeführt hat, auch wenn Rauschen hinzugefügt wurde. Wenn Sie diese Domain zuerst angeben, können Sie sicher sein, dass sie nichts über die Nutzerbeiträge preisgibt.
Sie können diese 128-Bit-Schlüssel entweder in der Attribution Reporting API oder in der Private Aggregation API deklarieren und damit Dimensionen codieren, die Sie erfassen möchten.
Nur vorab deklarierte Schlüssel werden für die Aggregation berücksichtigt und in den Zusammenfassungsbericht aufgenommen. Den zusammengefassten Werten der Bucket im Zusammenfassungsbericht wird statistischer Rauschen hinzugefügt, was sich im erstellten Zusammenfassungsbericht widerspiegelt.
Wenn ein Aggregationsschlüssel in der Ausgabedomaindatei, aber nicht in einem Batchbericht enthalten ist, ist der Wert im endgültigen Zusammenfassungsbericht wahrscheinlich nicht null, auch wenn der aggregierte Wert null ist. Das liegt an den hinzugefügten Zufallswerten, die dem Datenschutz dienen.