Aggregationsschlüssel für Attributionsberichte

Was sind Aggregationsschlüssel, wie werden sie in der Attribution Reporting API verwendet und wie können Sie Ziele in Schlüssel umwandeln?

Als Anbieter von Anzeigentechnologien, der Kampagnen an mehreren Standorten für verschiedene Produktkategorien durchführt, möchten Sie Werbetreibenden helfen, die folgenden Fragen zu beantworten:

1. Wie viele Käufe wurden mit jeder meiner Kampagnen in jeder geografischen Region für jede Produktkategorie erzielt?
2. Wie viel Umsatz wurde mit jeder meiner Kampagnen in jeder geografischen Region für jede Produktkategorie erzielt?

Viele Ad-Tech-Unternehmen empfehlen Werbetreibenden, verschiedene Conversion-Typen zu konfigurieren. Es ist jedoch sinnvoll, sich auf die wichtigsten Conversions wie Käufe zu konzentrieren, um zu prüfen, ob die zusammengefassten Ergebnisse für diese wichtigen Ereignisse detailliert und genau sind.

Dazu müssen Sie sich überlegen, welche Fragen Sie beantworten möchten, bevor Daten erhoben werden.

Dimensionen, Schlüssel und Werte

Um diese Fragen zu beantworten, sehen wir uns Dimensionen, Schlüssel und Werte an.

Dimensionen

Um nachzuvollziehen, wie Ihre Kampagnen Umsatz generieren, sollten Sie die folgenden Dimensionen erfassen:

• Kampagnen-ID: Die Kennung für die jeweilige Kampagne.
• Geografie-ID: Die geografische Region, in der die Anzeige ausgeliefert wurde.
• Produktkategorie: Der von Ihnen definierte Produkttyp.

Die Kampagnen-ID und die geografische ID sind bekannt, wenn die Anzeige ausgeliefert wird (Anzeigenauslieferungszeit). Die Produktkategorie ist erst nach einem Trigger-Ereignis bekannt, wenn der Nutzer eine Conversion ausführt (Conversion-Zeit).

Die Dimensionen, die Sie in diesem Beispiel erfassen möchten, sind im folgenden Bild dargestellt:

Was sind Aggregationsschlüssel (Buckets)?

Die Begriffe „Aggregationsschlüssel“ und „Bucket“ beziehen sich auf dasselbe. Der Aggregationsschlüssel wird in den Browser-APIs verwendet, mit denen Berichte konfiguriert werden. Der Begriff Bucket wird in den aggregierbaren Berichten und Zusammenfassungsberichten sowie in den APIs des Aggregationsdienstes verwendet.

Ein Aggregationsschlüssel (kurz: Schlüssel) ist ein Datenelement, das die Werte der erfassten Dimensionen darstellt. Die Daten werden später anhand jedes Aggregationsschlüssels zusammengefasst.

Angenommen, Sie erfassen die Dimensionen „Produktkategorie“, „Geografie-ID“ und „Kampagnen-ID“.

Wenn ein Nutzer mit der geografischen ID 7 eine Anzeige für die Kampagnen-ID 12 sieht und später eine Conversion erzielt, indem er ein Produkt in der Produktkategorie 25 kauft, können Sie einen Aggregationsschlüssel festlegen, der wie im folgenden Bild aussieht:

Sie werden später sehen, dass ein Aggregationsschlüssel in der Praxis nicht genau so aussieht. Konzentrieren wir uns aber erst einmal auf die Informationen, die er enthält.

Was sind aggregierbare Werte?

Um Ihre Fragen zu den von uns beschriebenen Dimensionen zu beantworten, müssen Sie Folgendes wissen:

• Die Anzahl der Käufe. Nachdem die Daten zusammengefasst und in einem Übersichtsbericht verfügbar gemacht wurden, ist dies die Gesamtzahl der Käufe (Zusammenfassungswert).
• Der Umsatz für jeden Kauf (der Kaufwert). Sobald die Daten zusammengefasst und in einem Übersichtsbericht verfügbar gemacht wurden, ist dies der Gesamtumsatz (Zusammenfassungswert).

Sowohl die Anzahl der Käufe für eine Conversion als auch der Kaufwert für eine Conversion sind aggregierbare Werte. Aggregierbare Werte sind die Werte Ihrer Analyseziele.

Wenn ein Nutzer mit der geografischen ID 7 eine Anzeige für die Kampagnen-ID 12 sieht und später eine Conversion ausführt, indem er ein Produkt der Produktkategorie 25 für 120 $kauft (vorausgesetzt, Ihre Währung ist USD), können Sie einen Aggregationsschlüssel und aggregierbare Werte festlegen, die so aussehen:

Zusammenfassbare Werte werden für jeden Schlüssel über viele Nutzer hinweg summiert, um aggregierte Statistiken in Form von Zusammenfassungswerten in Zusammenfassungsberichten zu generieren.

Zusammenfassbare Werte werden addiert, um aggregierte Statistiken für Ihre Analyseziele zu generieren.

In diesem Diagramm wird die Entschlüsselung ausgelassen. Es handelt sich um ein vereinfachtes Beispiel ohne Rauschen. Im nächsten Abschnitt wird dieses Beispiel mit Rauschen beschrieben.

Von Schlüsseln und Werten zu Berichten

Sehen wir uns nun an, wie sich aggregierbare Schlüssel und Werte auf Berichte beziehen.

Zusammenfassbare Berichte

Wenn ein Nutzer auf eine Anzeige klickt oder sie sieht und später eine Conversion ausführt, weisen Sie den Browser an, ein Paar aus {Aggregationsschlüssel, aggregierbarer Wert} zu speichern.

In unserem Beispiel weisen Sie den Browser an, zwei Beiträge zu generieren (einen pro Zielvorhaben), wenn ein Nutzer auf eine Anzeige klickt oder sie aufruft und später eine Conversion durchführt.

Wie Sie später sehen werden, sieht ein aggregierbarer Bericht mit {aggregation key, aggregatable value} nicht genau so aus. Konzentrieren wir uns aber erst einmal auf die Informationen, die er enthält.

Wenn Sie den Browser anweisen, zwei Beiträge zu generieren, wird ein aggregierbarer Bericht erstellt, sofern die Conversion mit einem früheren Aufruf oder Klick abgeglichen werden kann.

Ein aggregierbarer Bericht enthält:

• Die von Ihnen konfigurierten Beiträge.
• Metadaten zum Klick- oder Aufrufereignis und zum Conversion-Ereignis, z. B. die Website, auf der die Conversion erfolgt ist. Alle Felder in einem aggregierbaren Bericht ansehen

Zusammenfassbare Berichte sind im JSON-Format und enthalten unter anderem ein Nutzlastfeld, das als Dateneingabe für den endgültigen Zusammenfassungsbericht verwendet wird.

Die Nutzlast enthält eine Liste von Beiträgen, die jeweils ein Paar aus {Aggregationsschlüssel, aggregierbarer Wert} sind:

• bucket: Der Aggregationsschlüssel, codiert als Bytestring.
• value: Der aggregierbare Wert für dieses Zielvorhaben, als Bytestring codiert.

Beispiel:

{
  "data": [
    {
      "bucket": "111001001",
      "value": "11111010000",
    }
  ],
  "operation": "histogram"
}

In der Praxis werden aggregierbare Berichte so codiert, dass die Bucket- und Wertdarstellung sich vom vorherigen Beispiel unterscheidet (ein Bucket kann z. B. so aussehen: \u0000\u0000\x80\u0000). Bucket und Wert sind beide Bytestrings.

Zusammenfassende Berichte

Aggregierbare Berichte werden browser- und geräteübergreifend (nutzerübergreifend) zusammengefasst:

• Ein Anbieter von Anzeigentechnologien fordert Zusammenfassungsberichte für eine bestimmte Gruppe von Schlüsseln und eine bestimmte Gruppe von aggregierbaren Berichten an, die von vielen verschiedenen Browsern (Nutzern) stammen.
• Aggregierbare Berichte werden vom Aggregationsdienst entschlüsselt.
• Für jeden Schlüssel werden die aggregierbaren Werte aus den aggregierbaren Berichten summiert.
• Dem Zusammenfassungswert wird Rauschen hinzugefügt.

Das Ergebnis ist ein zusammenfassender Bericht, der eine Reihe von Paaren aus {Aggregationsschlüssel, Zusammenfassungswert} enthält.

Ein Übersichtsbericht enthält eine Reihe von Schlüssel/Wert-Paaren im JSON-Wörterbuchstil. Jedes Paar enthält:

• bucket: Der Aggregationsschlüssel, codiert als Bytestring.
• value: Der zusammengefasste Dezimalwert für ein bestimmtes Zielvorhaben, der aus allen verfügbaren aggregierbaren Berichten summiert wird. Es wird ein zusätzliches Rauschen hinzugefügt.

Beispiel:

[
  {"bucket": "111001001", "value": "2558500"},
  {"bucket": "111101001", "value": "3256211"},
  {...}
]

In der Praxis werden Zusammenfassungsberichte so codiert, dass Buckets und Werte anders aussehen als im Beispiel (ein Bucket kann z. B. so aussehen: \u0000\u0000\x80\u0000). Bucket und Wert sind beide Bytestrings.

Aggregationsschlüssel in der Praxis

Aggregationsschlüssel (Buckets) werden von einem Ad-Tech-Unternehmen definiert, in der Regel in zwei Schritten: wenn auf eine Anzeige geklickt oder sie angesehen wird und wenn ein Nutzer eine Conversion ausführt.

Schlüsselstruktur

Der Begriff Schlüsselstruktur bezeichnet die Menge der Dimensionen, die in einem Schlüssel codiert sind.

Ein Beispiel für eine wichtige Struktur ist „Kampagnen-ID × GeoID × Produktkategorie“.

:

Schlüsseltypen

Zusammenfassbare Werte werden für einen bestimmten Schlüssel über mehrere Nutzer/Browser hinweg summiert. Wir haben jedoch festgestellt, dass mit aggregierbaren Werten verschiedene Analyseziele verfolgt werden können, z. B. ein Kaufwert oder eine Anzahl von Käufen. Sie möchten prüfen, ob der Aggregationsdienst aggregierbare Werte desselben Typs summiert.

Codieren Sie dazu in jedem Schlüssel einen Teil der Daten, der angibt, wofür der zusammenfassende Wert steht – das Messziel, auf das sich dieser Schlüssel bezieht. Eine Möglichkeit dazu ist, eine zusätzliche Dimension für Ihren Schlüssel zu erstellen, die den Typ des Messzielvorhabens darstellt.

In unserem Beispiel hätte dieser Messzieltyp zwei verschiedene mögliche Werte:

• Anzahl der Käufe ist der erste Typ von Messziel.
• Der Kaufwert ist der zweite Typ von Messzielvorhaben.

:

Wenn Sie n Messziele hatten, hätte der Messzieltyp n verschiedene Wertetypen.

Die Dimensionen eines Schlüssels können als Messwert betrachtet werden. Beispiel: „Die Anzahl der Käufe eines bestimmten Produkts pro Kampagne und geografischer Einheit“.

Schlüsselgröße, Dimensionsgröße

Die maximale Schlüsselgröße wird in Bit definiert – die Anzahl der Nullen und Einsen im Binärformat, aus denen der vollständige Schlüssel besteht. Die API ermöglicht eine Schlüssellänge von 128 Bit.

Diese Größe ermöglicht sehr detaillierte Schlüssel, die jedoch eher zu ungenauen Werten führen. Weitere Informationen zu Rauschen

Wie bereits erwähnt, werden Dimensionen im Aggregationsschlüssel codiert. Jede Dimension hat eine bestimmte Kardinalität, d. h. die Anzahl der unterschiedlichen Werte, die die Dimension annehmen kann. Je nach Kardinalität muss jede Dimension durch eine bestimmte Anzahl von Bits dargestellt werden. Mit n Bits lassen sich 2ⁿ verschiedene Optionen darstellen.

Die Dimension „Land“ kann beispielsweise eine Kardinalität von 200 haben, da es etwa 200 Länder auf der Welt gibt. Wie viele Bits sind erforderlich, um diese Dimension zu codieren?

Mit 7 Bits könnten nur 2⁷ = 128 unterschiedliche Optionen gespeichert werden, was weniger als die erforderlichen 200 ist.

Mit 8 Bits können 2⁸ = 256 unterschiedliche Optionen gespeichert werden. Das ist mehr als die erforderlichen 200. Sie können also n=8 Bits verwenden, um diese Dimension zu codieren.

Schlüsselcodierung

Wenn Sie Schlüssel im Browser festlegen, sollten sie hexadezimal codiert sein. In Zusammenfassungsberichten werden Schlüssel binär dargestellt und als „Buckets“ bezeichnet.

Zwei Schlüsselteile für einen vollständigen Schlüssel festlegen

Angenommen, Sie verwenden einen Schlüssel, um die folgenden Dimensionen zu erfassen:

• Kampagnen-ID
• Geography-ID
• Produktkategorie

Die Dimensionen „Kampagnen-ID“ und „Geografie-ID“ sind bekannt, wenn die Anzeige ausgeliefert wird (Auslieferungszeitpunkt). Die Produktkategorie ist jedoch erst nach einem Trigger-Ereignis bekannt, wenn der Nutzer eine Conversion ausführt (Conversion-Zeitpunkt).

In der Praxis bedeutet das, dass Sie einen Schlüssel in zwei Schritten festlegen:

1. Ein Teil des Schlüssels (Kampagnen-ID × Geografie-ID) wird zum Zeitpunkt des Klicks oder der Impression festgelegt.
2. Den zweiten Teil des Schlüssels, die Produktkategorie, legen Sie zum Zeitpunkt der Conversion fest.

Diese verschiedenen Teile der Schlüssel werden als Schlüsselkomponenten bezeichnet.

Ein Schlüssel wird berechnet, indem die ODER-Verknüpfung (v) seiner Schlüsselkomponenten verwendet wird.

Beispiel:

• Schlüsselkomponente auf der Quellseite = 0x159
• Schlüsselkomponente auf Triggerseite = 0x400
• Schlüssel = 0x159 v 0x400 = 0x559

Wichtige Elemente abstimmen

Bei zwei 64-Bit-Schlüsselteilen, die mit sorgfältig platzierten 64-Bit-Füllern oder ‑Offsets (den sechzehn Nullen) auf 128 Bit erweitert werden, entspricht die OR-Verknüpfung der Schlüsselteile der Verkettung, die einfacher nachzuvollziehen und zu überprüfen ist:

• Schlüsselkomponente auf der Quellseite = 0xa7e297e7c8c8d0540000000000000000
• Schlüsselkomponente auf Triggerseite = 0x0000000000000000674fbe308a597271
• Schlüssel = 0xa7e297e7c8c8d0540000000000000000 v 0x0000000000000000674fbe308a597271 = 0xa7e297e7c8c8d054674fbe308a597271

Mehrere Schlüssel pro Anzeigenklick oder ‑aufruf

In der Praxis können Sie mehrere Schlüssel pro Attributionsquellenereignis (Anzeigenklick oder ‑aufruf) festlegen. Sie können beispielsweise Folgendes festlegen:

• Ein Schlüssel, mit dem die geografische ID × Kampagnen-ID erfasst wird.
• Ein weiterer Schlüssel, mit dem der Creative-Typ × die Kampagnen-ID erfasst wird.

Ein weiteres Beispiel finden Sie unter Strategie B.

Dimensionen in Schlüssel codieren

Wenn Sie Zusammenfassungsberichte anfordern, müssen Sie dem Aggregationsdienst mitteilen, auf welche Messwerte Sie zugreifen möchten. Dazu fordern Sie Zusammenfassungsberichte für eine bestimmte Gruppe von Aggregationsschlüsseln an.

Zusammenfassungsberichte enthalten Rohdaten in Form von {Schlüssel, Zusammenfassungswert}-Paaren und keine zusätzlichen Informationen zum Schlüssel. Das bedeutet Folgendes:

• Wenn Sie Schlüssel festlegen, während ein Nutzer eine Anzeige sieht oder darauf klickt und später eine Conversion ausführt, müssen Sie die Schlüssel zuverlässig auf Grundlage der Werte der Dimensionen festlegen, die sie repräsentieren.
• Wenn Sie die Schlüssel definieren, für die Sie Zusammenfassungsberichte anfordern möchten, müssen Sie dieselben Schlüssel zuverlässig generieren oder spontan darauf zugreifen können, die festgelegt wurden, als der Nutzer eine Anzeige gesehen oder darauf geklickt und eine Conversion ausgeführt hat. Dies muss auf Grundlage der Werte der Dimensionen erfolgen, für die Sie aggregierte Daten sehen möchten.

Dimensionen mit Schlüsselstrukturzuordnungen codieren

Um Dimensionen in Schlüssel zu codieren, können Sie vorab eine Schlüsselstrukturkarte erstellen und verwalten, wenn Sie Ihre Schlüssel definieren (vor der Anzeigenauslieferung).

Eine Schlüsselstrukturkarte stellt jede Ihrer Dimensionen und ihre Position im Schlüssel dar.

In der Praxis bedeutet das Erstellen und Verwalten von Schlüsselstrukturzuordnungen, dass Sie die Decoderlogik implementieren und verwalten müssen. Wenn Sie eine Methode suchen, bei der das nicht erforderlich ist, sollten Sie stattdessen einen hashbasierten Ansatz verwenden.

Beispiel:

Angenommen, Sie möchten sowohl Käufe als auch Kaufwerte für bestimmte Kampagnen, geografische Regionen und Produkte erfassen.

Die Produktkategorie, die geografische ID und die Kampagnen-ID müssen Dimensionen in Ihren Schlüsseln sein. Da Sie außerdem zwei verschiedene Messziele erfassen möchten (Anzahl der Käufe und Kaufwert), müssen Sie Ihrem Schlüssel eine Dimension hinzufügen, mit der der Schlüsseltyp erfasst wird. So können Sie definieren, was der aggregierbare Wert tatsächlich darstellt, wenn Sie {Schlüssel, aggregierbarer Wert}-Paare in Zusammenfassungsberichten erhalten.

Mit diesen Analyseziele hat Ihr Schlüssel die folgenden Dimensionen:

• Produktkategorie
• Typ des Zielvorhabens der Analyse
• Geography-ID
• Kampagnen-ID

Sehen wir uns nun die einzelnen Dimensionen an. Angenommen, Sie müssen für Ihren Anwendungsfall Folgendes erfassen:

• 29 verschiedene Produktkategorien.
• 8 verschiedene geografische Regionen: Nordamerika, Mittelamerika, Südamerika, Europa, Afrika, Asien, Karibik und Ozeanien.
• 16 verschiedene Kampagnen.

Hier sehen Sie die Anzahl der Bits, die Sie zum Codieren jeder Dimension in Ihrem Schlüssel benötigen:

• Produktkategorie: 5 Bit (2⁵ = 32 > 29).
• Typ des Zielvorhabens der Messung: 1 Bit. Das Analysevorhaben ist entweder die Anzahl der Käufe oder der Kaufwert. Da es nur zwei Möglichkeiten gibt, reicht ein Bit zum Speichern dieser Information aus.

• Regions-ID: 3 Bit (2³ = 8). Sie würden auch eine Dimensionszuordnung für die geografische ID definieren, um zu wissen, welche geografische Region jeder binäre Wert darstellt. Die Dimensionszuordnung für die Dimension „Geografie-ID“ könnte so aussehen:

  Binärwert im Schlüssel	Geografie
  000	Nordamerika
  001	Mittelamerika
  010	Südamerika
  011	Europa
  100	Afrika
  101	Asien
  110	Karibik
  111	Ozeanien

• Kampagnen-ID: 4 Bit (2⁴ = 16)

Schlüssel mit dieser Struktur wären 13 Bit lang (5 + 1 + 3 + 4).

In diesem Beispiel sieht die Schlüsselstrukturzuordnung für diese Schlüssel so aus:

Die Reihenfolge der Dimensionen im Schlüssel liegt bei Ihnen.

Um zu veranschaulichen, wie Dimensionen eine Schlüsselstruktur bilden, verwenden wir eine binäre Darstellung. Daher befindet sich die Kampagnen-ID (erste Bits) ganz rechts und die Produktkategorie (letzte Bits) ganz links.

Innerhalb jeder Dimension ist das höchstwertige Bit (das mit dem größten numerischen Wert) das Bit ganz links. Das am weitesten rechts stehende Bit ist das Bit mit der geringsten Signifikanz.

Sehen wir uns an, wie Sie eine Schlüsselstrukturzuordnung verwenden, um einen Schlüssel zu decodieren.

Nehmen wir 0b1100100111100 als Beispielschlüssel an und gehen wir davon aus, dass Sie wissen, dass dieser Schlüssel der Schlüsselstrukturkarte in der vorherigen Abbildung entspricht.

Gemäß der Schlüsselstruktur würde dieser Schlüssel so decodiert:

`11001 0 011 1100`

Der Schlüssel 0b1100100111100 steht also für die Anzahl der Käufe der Produktkategorie 25 für die Kampagnen-ID 12, die in Europa gestartet wurde.

Dimensionen mit einer Hash-Funktion codieren

Anstatt eine Schlüsselstrukturzuordnung zu verwenden, können Sie eine Hash-Funktion verwenden, um Schlüssel dynamisch, konsistent und zuverlässig zu generieren.

Das funktioniert so:

1. Wählen Sie einen Hashing-Algorithmus aus.
2. Generieren Sie zum Zeitpunkt der Anzeigenauslieferung einen String, der alle Dimensionen enthält, die Sie erfassen möchten, sowie deren Werte. Um den Quellschlüsselteil zu generieren, hashen Sie diesen String und fügen Sie ein 64-Bit-Suffix mit Nullen hinzu, um ihn mit dem Schlüsselteil auf der Triggerseite abzugleichen und die OR-Logik zu vereinfachen.
   • Schlüsselkomponente auf Quellseite
     = <64-bit hex hash("COUNT, campaignID=12, geoID=7"))><64-bit 00000000…>
   • COUNT codiert dasselbe wie measurementGoalType=0 im Ansatz mit der Schlüsselstrukturzuordnung. COUNT ist etwas schlanker und expliziter.
3. Generieren Sie zum Zeitpunkt der Conversion einen String, der alle Dimensionen enthält, die Sie erfassen möchten, sowie deren Werte. Um ein Schlüssel-Fragment für den Trigger zu generieren, hashen Sie diesen String und fügen Sie ein 64-Bit-Präfix mit Nullen hinzu:
   • Schlüsselteil auf Triggerseite = <64-bit 00000000…><64-bit hex hash("productCategory=25")>
4. Der Browser führt eine OR-Verknüpfung dieser Schlüsselteile aus, um einen Schlüssel zu generieren.
   • 128-Bit-Aggregationsschlüssel 
     = <64-bit hex source-side key piece hash><64-bit hex source-side key piece hash>
5. Wenn Sie später einen zusammenfassenden Bericht für diesen Schlüssel anfordern möchten, generieren Sie ihn spontan:
   • Generieren Sie basierend auf den Dimensionen, die Sie interessieren, wie zuvor ein Quell- und ein Trigger-seitiges Schlüsselstück.
     • Schlüsselkomponente auf Quellseite
       = <64-bit hex hash("COUNT, campaignID=12, geoID=7"))><64-bit 00000000…>
     • Schlüsselteil auf Triggerseite
       = <64-bit 00000000…><64-bit hex hash("productCategory=25")>
     • Schlüsselkomponente auf Triggerseite = toHex(hash("productCategory=25"))
   • Wie beim Browser können Sie diese Schlüsselteile mit OR verknüpfen, um denselben Schlüssel zu generieren, den der Browser zuvor generiert hat.
     • 128-Bit-Aggregationsschlüssel 
       = <64-bit source-side key piece hash><64-bit source-side key piece hash>

Hier sind einige praktische Tipps, wenn Sie diesen hashbasierten Ansatz verwenden:

• Verwenden Sie immer dieselbe Reihenfolge der Dimensionen. So wird sichergestellt, dass Ihre Hashes zuverlässig neu generiert werden können. ("COUNT, CampaignID=12, GeoID=7" generiert nicht denselben Hash wie "COUNT, GeoID=7, CampaignID=12".) Eine einfache Möglichkeit, dies zu erreichen, besteht darin, Dimensionen alphanumerisch zu sortieren. Genau das machen wir im Beispiel. Allerdings ist COUNT oder VALUE immer das erste Element in der Dimension. Das ist eine Entscheidung, die wir aus Gründen der Lesbarkeit getroffen haben, da COUNT oder VALUE Informationen enthält, die sich konzeptionell leicht von allen anderen Dimensionen unterscheiden.
• Behalten Sie die Dimensionen im Blick, die Sie in Schlüsseln verwenden. Sie möchten vermeiden, dass Schlüssel auf Grundlage von Dimensionen generiert werden, die Sie noch nie verwendet haben.
• Hash-Kollisionen sind selten, wenn eine geeignete Hash-Funktion verwendet wird. Durch den Abgleich mit zuvor verwendeten Hashes (die gespeichert werden sollten, um die Ergebnisse des Aggregationsdienstes zu interpretieren) kann vermieden werden, dass neue Schlüssel eingeführt werden, die mit älteren Schlüsseln kollidieren.

Hier finden Sie ein praktisches Beispiel für die Verwendung hashbasierter Schlüssel.

Aggregierbare Werte in der Praxis

Das Ad-Tech-Unternehmen legt aggregierbare Werte fest, wenn ein Nutzer eine Conversion ausführt.

Um die Privatsphäre der Nutzer zu schützen, gibt es ein Limit für die Beiträge jedes Nutzers. Für alle aggregierbaren Werte, die einer einzelnen Quelle (Anzeigenklick oder ‑aufruf) zugeordnet sind, darf kein Wert ein bestimmtes Beitragslimit überschreiten.

Dieses Limit wird als CONTRIBUTION_BUDGET bezeichnet. In der Erklärung wird dieses Limit als L1-Budget bezeichnet, es ist aber dasselbe wie CONTRIBUTION_BUDGET.

Eine ausführliche Erläuterung des Beitragsbudgets finden Sie unter Beitragsbudget für Zusammenfassungsberichte.

Beispiel: eine Conversion pro Klick oder Aufruf

In diesem Beispiel gehen wir davon aus, dass Sie Antworten auf die folgenden Fragen suchen:

• Welche Produktkategorien sind in den einzelnen Regionen am wertvollsten?
• Welche Kampagnenstrategien sind in den einzelnen Regionen am effektivsten?

Nehmen wir außerdem an, dass Sie für Ihren Anwendungsfall wöchentliche Statistiken benötigen.

Außerdem müssen Sie Folgendes erfassen:

• 16 verschiedene Kampagnen.
• 8 verschiedene geografische Regionen: Nordamerika, Mittelamerika, Südamerika, Europa, Afrika, Asien, Karibik und Ozeanien.
• 29 verschiedene Produktkategorien.

Geeignete Messwerte

Viele Ad-Tech-Unternehmen empfehlen Werbetreibenden, verschiedene Conversion-Typen zu konfigurieren. Es ist jedoch sinnvoll, sich auf die wichtigsten Conversions wie Käufe zu konzentrieren, um zu prüfen, ob die aggregierten Ergebnisse für diese wichtigen Conversion-Ereignisse detailliert und genau sind. Je mehr Messwerte Sie analysieren, desto kleiner ist das Budget für die Beiträge pro Messwert und desto ungenauer sind die einzelnen Werte. Sie müssen daher sorgfältig auswählen, was Sie messen möchten.

In diesem Beispiel konzentrieren wir uns auf Kampagneneinrichtungen, bei denen nur eine Conversion pro Klick oder Aufruf erfasst wird: ein Kauf.

Sie können weiterhin sowohl die Anzahl als auch den Wert der Käufe erfassen und auf eine Vielzahl wichtiger aggregierter Statistiken wie den Gesamtwert der Käufe und geografische Aufschlüsselungen zugreifen. So wird Rauschen effektiv unterdrückt und gleichzeitig eine einfache Skalierungsmethode für Ihr Beitragsbudget bestätigt.

Was ist mit Währungen?

Wenn Sie Kampagnen in verschiedenen Regionen schalten, müssen Sie die Währungen berücksichtigen. Sie haben folgende Möglichkeiten:

• Machen Sie die Währung zu einer eigenen Dimension in den Aggregationsschlüsseln.
• Alternativ können Sie die Währung aus einer Kampagnen-ID ableiten und alle Währungen in eine Referenzwährung umrechnen.

In diesem Beispiel gehen wir davon aus, dass Sie die Währung aus einer Kampagnen-ID ableiten können. So können Sie jeden Kaufwert von der lokalen Währung des Nutzers in eine Referenzwährung Ihrer Wahl umrechnen. Sie können die Umrechnung auch spontan durchführen, wenn der Nutzer einen Artikel kauft.

Bei dieser Methode sind alle aggregierbaren Werte in derselben Referenzwährung und können daher addiert werden, um einen aggregierten Gesamtkaufwert zu erhalten.

Ziele in Schlüssel umwandeln

Mit Ihren Messzielen und ‑messwerten haben Sie eine Reihe von Optionen für Ihre Schlüsselstrategie. Konzentrieren wir uns auf zwei dieser Strategien:

• Strategie A: Eine detaillierte Schlüsselstruktur.
• Strategie B: zwei grobe Schlüsselstrukturen.

Strategie A: ein umfassender Baum (eine detaillierte Schlüsselstruktur)

Bei Strategie A verwenden Sie eine detaillierte Schlüsselstruktur, die alle erforderlichen Dimensionen enthält:

Alle Ihre Schlüssel verwenden diese Struktur.

Sie teilen diese Schlüsselstruktur in zwei Schlüsseltypen auf, um zwei Analyseziele zu unterstützen.

• Schlüsseltyp 0: Messzieltyp = 0. Sie entscheiden sich, ihn als Anzahl der Käufe zu definieren.
• Schlüsseltyp 1: Messzieltyp = 1. Sie entscheiden sich, diesen als Kaufwert zu definieren.

Zusammenfassungsberichte sehen so aus:

Sie können sich Strategie A als „Baum mit einer Ebene“ vorstellen:

• Jeder zusammenfassende Wert in Übersichtsberichten ist allen Dimensionen zugeordnet, die Sie erfassen.
• Sie können diese zusammengefassten Werte zusammen mit jeder dieser Dimensionen zusammenfassen. Die Zusammenfassungen können also so detailliert sein, wie die Anzahl der Dimensionen, die Sie haben.

Mit Strategie A würden Sie Ihre Fragen so beantworten:

Mit Strategie A können Sie auch die dritte Frage direkt beantworten:

„Wie viel Umsatz wurde mit jeder meiner Kampagnen in jeder geografischen Region für jedes Produkt generiert?“

Auch wenn die zusammengefassten Werte mit Unsicherheiten behaftet sind, können Sie feststellen, wann Unterschiede im gemessenen Wert zwischen den einzelnen Kampagnen nicht nur auf Unsicherheiten zurückzuführen sind. Weitere Informationen

Strategie B: zwei flache Bäume (zwei grobe Schlüsselstrukturen)

Bei Strategie B verwenden Sie zwei grobe Schlüsselstrukturen, die jeweils eine Teilmenge der benötigten Dimensionen enthalten:

Sie unterteilen jede dieser Schlüsselstrukturen in zwei Haupttypen, um zwei Messziele zu unterstützen.

• Der Typ des Analysevorhabens ist 0. Sie definieren ihn als Anzahl der Käufe.
• Der Typ des Analysevorhabens ist 1. Sie legen ihn als Kaufwert fest.

Daraus ergeben sich vier wichtige Typen:

• Schlüsseltyp I-0: Schlüsselstruktur I, Anzahl der Käufe.
• Schlüsseltyp I-1: Schlüsselstruktur I, Kaufwert.
• Schlüsseltyp II-0: Schlüsselstruktur II, Anzahl der Käufe.
• Schlüsseltyp II-1: Schlüsselstruktur II, Kaufwert.

Zusammenfassungsberichte sehen so aus:

Sie können sich Strategie B als Strategie mit zwei flachen Bäumen vorstellen:

• Die zusammengefassten Werte in Zusammenfassungsberichten werden einer von zwei kleinen Gruppen von Dimensionen zugeordnet.
• Sie können diese zusammengefassten Werte zusammen mit jeder der Dimensionen in diesen Sets zusammenfassen. Das bedeutet, dass diese Zusammenfassungen nicht so detailliert sind wie in Option A, da es weniger Dimensionen gibt, für die zusammengefasst werden kann.

Bei Strategie B würden Sie Ihre Fragen so beantworten:

Entscheidung: Strategie A

Strategie A ist einfacher, da alle Daten derselben Schlüsselstruktur folgen. Das bedeutet auch, dass Sie nur eine Schlüsselstruktur verwalten müssen.

Bei Strategie A müssen Sie jedoch die zusammengefassten Werte in den Zusammenfassungsberichten addieren, um einige Ihrer Fragen zu beantworten. Jeder dieser zusammenfassenden Werte ist verrauscht. Wenn Sie diese Daten zusammenfassen, fassen Sie auch das Rauschen zusammen.

Bei Strategie B ist das nicht der Fall, da die in den Zusammenfassungsberichten enthaltenen Zusammenfassungswerte bereits die benötigten Informationen liefern. Das bedeutet, dass Strategie B wahrscheinlich weniger von Rauschen beeinflusst wird als Strategie A.

Wie entscheiden Sie, welche Strategie Sie verwenden? Bei bestehenden Werbetreibenden oder Kampagnen können Sie anhand von Verlaufsdaten ermitteln, ob das Conversion-Volumen besser für Strategie A oder Strategie B geeignet ist. Bei neuen Werbetreibenden oder Kampagnen haben Sie jedoch folgende Möglichkeiten:

• Erfassen Sie einen Monat lang Daten mit den detaillierten Schlüsseln (Strategie A). Da Sie den Zeitraum für die Datenerhebung verlängern, sind die zusammengefassten Werte höher und das Rauschen relativ geringer.
• Die wöchentliche Anzahl von Conversions und den Kaufwert mit angemessener Genauigkeit einschätzen.

Nehmen wir in diesem Beispiel an, dass die wöchentliche Anzahl der Käufe und der Kaufwert so hoch sind, dass Strategie A zu einem Rauschprozentsatz führen würde, der für Ihren Anwendungsfall akzeptabel ist.

Da Strategie A einfacher ist und zu einer Rauschwirkung führt, die Ihre Entscheidungsfindung nicht beeinträchtigt, entscheiden Sie sich für Strategie A.

Hashing-Algorithmus auswählen

Sie entscheiden sich für einen hashbasierten Ansatz zum Generieren Ihrer Schlüssel. Dazu müssen Sie einen Hashing-Algorithmus auswählen, der diesen Ansatz unterstützt.

Angenommen, Sie haben SHA-256 ausgewählt. Sie können auch einen einfacheren, weniger sicheren Algorithmus wie MD5 verwenden.

Schlüssel und Werte im Browser festlegen

Nachdem Sie sich für eine Schlüsselstruktur und einen Hashing-Algorithmus entschieden haben, können Sie Schlüssel und Werte registrieren, wenn Nutzer auf Anzeigen klicken oder sie aufrufen und anschließend eine Conversion ausführen.

Im Folgenden finden Sie eine Übersicht der Header, die Sie festlegen müssen, um Schlüssel und Werte im Browser zu registrieren:

Schlüsselkomponenten auf der Quellseite festlegen

Wenn ein Nutzer auf eine Anzeige klickt oder sie sich ansieht, legen Sie die Aggregationsschlüssel im Attribution-Reporting-Register-Aggregatable-Source-Header fest. In dieser Phase können Sie für jeden Schlüssel nur den Teil des Schlüssels oder Schlüsselbestandteil festlegen, der zum Zeitpunkt der Anzeigenauslieferung bekannt ist.

Generieren wir die wichtigsten Elemente:

Legen wir nun die wichtigsten Elemente fest:

// Upon receiving the request from the publisher site
res.set(
  "Attribution-Reporting-Register-Aggregatable-Source",
  JSON.stringify([
    {
      "id": "key_purchaseCount",
      "key_piece": "0x3cf867903fbb73ec0000000000000000"
    },
    {
      "id": "key_purchaseValue",
      "key_piece": "0x245265f432f16e730000000000000000"
    }
  ])
);

Schlüssel-IDs werden nicht in den endgültigen Berichten angezeigt. Sie werden nur verwendet, wenn Schlüssel im Browser festgelegt werden, damit Quell- und Triggerseitenschlüsselkomponenten einander zugeordnet und zu einem vollständigen Schlüssel kombiniert werden können.

Optional: Berichte auf Ereignisebene

Wenn Sie Berichte auf Ereignisebene zusammen mit aggregierbaren Berichten verwenden müssen, prüfen Sie, ob die Daten auf Ereignisebene (Quellereignis-ID und Triggerdaten) und der Aggregationsschlüssel für eine bestimmte Quelle abgeglichen werden können.

Sie können beide Berichte verwenden, wenn Sie beispielsweise Modelle erstellen möchten, um herauszufinden, welche Arten von Anzeigen am häufigsten zu Käufen führen.

Nutzer führt Conversion aus

Wenn ein Nutzer eine Conversion ausführt, wird in der Regel eine Pixelanfrage an den Ad-Tech-Server gesendet. Nach Erhalt dieser Anfrage:

• Legen Sie die Schlüsselkomponenten auf der Conversion-Seite (Trigger-Seite) fest, um den Schlüssel zu vervollständigen. Diese Schlüsselkomponenten werden mit dem Header Attribution-Reporting-Register-Aggregatable-Trigger-Data festgelegt.
• Legen Sie den aggregierbaren Wert für diese Conversion mit dem Header Attribution-Reporting-Register-Aggregatable-Values fest.

Schlüsselkomponenten auf Triggerseite festlegen, um den Schlüssel zu vervollständigen

Generieren wir die wichtigsten Elemente:

Legen wir nun die wichtigsten Elemente fest:

// Upon receiving the pixel request from the advertiser site
res.set(
  "Attribution-Reporting-Register-Aggregatable-Trigger-Data",
  JSON.stringify([
    // Each dictionary independently adds pieces to multiple source keys
    {
      "key_piece": "0x0000000000000000f9e491fe37e55a0c",
      "source_keys": ["key_purchaseCount", "key_purchaseValue"]
    },
  ])
);

Beachten Sie, dass Sie mehreren Schlüsseln denselben Schlüsselbestandteil hinzufügen, indem Sie mehrere Schlüssel-IDs in source_keys auflisten. Der Schlüsselbestandteil wird beiden Schlüsseln hinzugefügt.

Aggregierbare Werte festlegen

Bevor Sie die aggregierbaren Werte festlegen, müssen Sie sie hochskalieren, um das Rauschen zu reduzieren.

Angenommen, es wurde ein Kauf für den Produkttyp 25 im Wert von 52 € getätigt.

Sie legen diese nicht direkt als aggregierbare Werte fest:

• key_purchaseCount: 1 Conversion
• key_purchaseValue: 52 $

Stattdessen müssen Sie diese aggregierbaren Werte skalieren, bevor Sie sie registrieren, um Rauschen zu minimieren.

Sie haben zwei Ziele, für die Sie Ihr Budget für Beiträge ausgeben können. Daher können Sie das Budget für Beiträge in zwei Teile aufteilen.

In diesem Fall wird jedem Ziel ein Maximum von CONTRIBUTION_BUDGET/2 (=65.536/2=32.768) zugewiesen.

Angenommen, der maximale Kaufwert für einen einzelnen Nutzer beträgt 1.500 $. Diese Annahme basiert auf dem Kaufverlauf aller Nutzer der Website. Es kann Ausreißer geben, z. B. sehr wenige Nutzer, die mehr als diesen Betrag ausgegeben haben. Sie können diese Ausreißer jedoch ignorieren.

Der Skalierungsfaktor für den Kaufwert sollte so aussehen:

((CONTRIBUTION_BUDGET/2) / 1.500) = 32.768/1.500 = 21,8 ≈ 22

Der Skalierungsfaktor für die Anzahl der Käufe ist 32.768/1 = 32.768, da Sie beschlossen haben, maximal einen Kauf pro Anzeigenklick oder ‑aufruf (Quellereignis) zu erfassen.

Sie können jetzt die folgenden Werte festlegen:

• key_purchaseCount: 1 × 32.768 = 32.768
• key_purchaseValue: 52 × 22 = 1.144

In der Praxis würden Sie sie so festlegen und dabei den dedizierten Header Attribution-Reporting-Register-Aggregatable-Values verwenden:

// Instruct the browser to schedule-send a report
res.set(
  "Attribution-Reporting-Register-Aggregatable-Values",
  JSON.stringify({
    "key_purchaseCount": 32768,
    "key_purchaseValue": 1144,
  })
);

Der aggregierbare Bericht wird generiert.

Der Browser ordnet die Conversion einem vorherigen Aufruf oder Klick zu und generiert einen aggregierbaren Bericht, der neben den Bericht-Metadaten auch die verschlüsselte Nutzlast enthält.

Im Folgenden finden Sie ein Beispiel für die Daten, die in der Nutzlast des aggregierbaren Berichts enthalten sein könnten, wenn sie im Klartext lesbar wären:

[
  {
    key: 0x3cf867903fbb73ecf9e491fe37e55a0c, // = source-side key piece OR conversion-side key piece for the key key_purchaseCount
    value: 32768 // the scaled value for 1 conversion, in the context of [CONTRIBUTION_BUDGET/2]
  },
  {
    key: 0x245265f432f16e73f9e491fe37e55a0c, // source-side key piece OR conversion-side key piece for the key key_purchaseValue
    value: 1144 // the scaled value for $52, in the context of [CONTRIBUTION_BUDGET/2]
  },
]

Hier sehen Sie zwei separate Beiträge in einem einzigen aggregierbaren Bericht.

Zusammenfassungsbericht anfordern

• Batch-aggregierbare Berichte. Folgen Sie der Anleitung unter Batching.
• Generieren Sie die Schlüssel, für die Sie Daten sehen möchten. Wenn Sie beispielsweise zusammenfassende Daten für COUNT (Gesamtzahl der Käufe) und VALUE (Gesamtkaufwert) für die Kampagnen-ID 12 × Geografie-ID 7 × Produktkategorie 25 sehen möchten, gehen Sie so vor:
  • Generieren Sie den Quellschlüsselteil, wie Sie es beim Festlegen im Browser getan haben.
  • Generieren Sie das schlüsselbezogene Segment auf der Triggerseite, wie Sie es beim Festlegen im Browser getan haben.

• Zusammenfassungsdaten für diese Schlüssel beim Aggregationsdienst anfordern.

Zusammenfassungsbericht verarbeiten

Letztendlich erhalten Sie einen zusammenfassenden Bericht, der so aussehen kann:

[
  {"bucket": "00111100111110000110011110010000001111111011101101110011111011001111100111100100100100011111111000110111111001010101101000001100",
    "value": "2558500"},
  {"bucket": "00100100010100100110010111110100001100101111000101101110011100111111100111100100100100011111111000110111111001010101101000001100",
    "value": "687060"},
  …
]

Der erste Bucket ist der COUNT-Schlüssel im Binärformat. Der zweite Bucket ist der VALUE-Schlüssel in Binärform. Die Schlüssel sind heterogen (COUNT im Vergleich zu VALUE), aber im selben Bericht enthalten.

Werte herunterskalieren

• Die Zahl 2.558.500 bezieht sich auf die Anzahl der Käufe für diesen Schlüssel, die mit dem zuvor berechneten Skalierungsfaktor hochgerechnet wurde. Der Skalierungsfaktor für die Anzahl der Käufe war 32.768. Dividieren Sie 2.558.500 durch das Budget für den Beitrag des Zielvorhabens: 2.558.500/32.768 = 156,15 Käufe.
• 687.060 → 687.060/22 = 31.230 $Gesamtkaufwert.

Zusammenfassungsberichte liefern Ihnen daher die folgenden Informationen:

- Within the reporting time period, campaign #12
  run in Europe drove about 156 purchases (± noise)
  for the product category #25
  ```

  ```text
- Within the reporting time period, campaign #12
  run in Europe drove $31,230 of purchases (± noise)
  for the product category #25.