Aggregationsschlüssel für Attributionsberichte

Was Aggregationsschlüssel sind, wie sie in der Attribution Reporting API verwendet werden und wie sich Zielvorhaben in Schlüssel umwandeln lassen

Sie sind AdTech-Unternehmen, das an mehreren Standorten Kampagnen für verschiedene Produktkategorien durchführt, und möchten Werbetreibenden dabei helfen, die folgenden Fragen zu beantworten:

1. Wie viele Käufe jeder Produktkategorie haben meine Kampagnen in jeder geografischen Region generiert?
2. Wie viel Umsatz pro Produktkategorie hat mit den einzelnen Kampagnen in den einzelnen Regionen jeweils erzielt?

Viele Unternehmen im Bereich Anzeigentechnologie empfehlen Werbetreibenden, eine Vielzahl von Conversion-Typen zu konfigurieren. Wenn Sie sich jedoch auf die wichtigsten Conversions (z. B. Käufe) konzentrieren, können Sie dafür sorgen, dass die zusammenfassenden Ergebnisse für diese wichtigen Ereignisse detailliert und präzise sind.

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

Dimensionen, Schlüssel und Werte

Sehen wir uns Dimensionen, Schlüssel und Werte an, um diese Fragen zu beantworten.

Abmessungen

Um zu verstehen, wie Ihre Kampagnen Umsatz generieren, wie hier beschrieben, sollten Sie die folgenden Dimensionen erfassen:

• Werbekampagnen-ID: Die Kennung der jeweiligen Kampagne.
• Geografie-ID: Die geografische Region, in der die Anzeige ausgeliefert wurde.
• Produktkategorie: der von Ihnen definierte Produkttyp.

Während die Dimensionen „Kampagnen-ID“ und „Geografische ID“ bekannt sind, wenn die Anzeige ausgeliefert wird (Zeit der Anzeigenbereitstellung), ist die Produktkategorie aus einem Triggerereignis bekannt, wenn der Nutzer eine Conversion ausführt (Conversion-Zeit).

Die Dimensionen, die Sie für dieses Beispiel erfassen möchten, sind in der folgenden Abbildung 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 aggregierten Berichten und den Zusammenfassungsberichten sowie in den Aggregationsdienst-APIs verwendet.

Ein Aggregationsschlüssel (kurz: Schlüssel) ist ein Datenelement, das die Werte der erfassten Dimensionen darstellt. Die Daten werden später zusammen mit jedem Aggregationsschlüssel aggregiert.

Angenommen, Sie erfassen die Dimensionen "Produktkategorie", "Regions-ID" und "Kampagnen-ID".

Wenn ein Nutzer in Geografie-ID 7 eine Anzeige für Kampagnen-ID 12 sieht und später eine Conversion durch den Kauf eines Produkts aus der Produktkategorie 25 abschließt, können Sie einen Aggregationsschlüssel festlegen, der wie in der folgenden Abbildung aussieht:

Sie werden später sehen, dass ein Aggregationsschlüssel in der Praxis nicht genau so aussieht. Konzentrieren wir uns vorerst auf die im Schlüssel enthaltenen Informationen.

Was sind aggregierbare Werte?

Zur Beantwortung Ihrer Fragen zu den beschriebenen Dimensionen benötigen Sie Folgendes:

• Die Anzahl der Käufe (die Anzahl der Käufe). Nach der Zusammenfassung und Bereitstellung in einem zusammenfassenden Bericht ist dies die Gesamtzahl der Käufe (Zusammenfassungswert).
• Der Umsatz für jeden Kauf (der Kaufwert). Nach der Zusammenfassung und Bereitstellung in einem zusammenfassenden Bericht ist dies der Gesamtumsatz (Zusammenfassungswert).

Jedes dieser Werte – die Anzahl der Käufe für eine Conversion und der Kaufwert für eine Conversion – ist ein aggregierter Wert. Aggregierbare Werte sind die Werte Ihrer Analyseziele.

Frage	Aggregierbarer Wert = Messziel
		Wie viele Käufe...	Anzahl der Käufe
Wie viel Umsatz...	Kaufwert

Wenn ein Nutzer in Geografie-ID 7 eine Anzeige für Kampagnen-ID 12 sieht und später eine Conversion durch den Kauf eines Produkts der Produktkategorie 25 für 120 € (vorausgesetzt Ihre Währung ist USD) ausführt, können Sie einen Aggregationsschlüssel und aggregierte Werte festlegen, die wie folgt aussehen:

Aggregierte Werte werden pro Schlüssel für viele Nutzer summiert, um zusammengefasste Statistiken in Form von Übersichtswerten in Zusammenfassungsberichten zu generieren.

Die aggregierten Werte werden addiert, um zusammengefasste Informationen für Ihre Analyseziele zu erhalten.

Beachten Sie, dass in diesem Diagramm die Entschlüsselung weggelassen wird und ein vereinfachtes Beispiel ohne Rauschen dargestellt ist. Im nächsten Abschnitt beschreiben wir dieses Beispiel mit Rauschen.

Von Schlüsseln und Werten zu Berichten

Sehen wir uns nun an, wie aggregierbare Schlüssel und Werte mit Berichten zusammenhängen.

Aggregierbare Berichte

Wenn ein Nutzer auf eine Anzeige klickt oder sie ansieht und später eine Conversion ausführt, weisen Sie den Browser an, ein {aggregation key, aggregatable value}-Paar zu speichern.

Wenn ein Nutzer auf eine Anzeige klickt oder sie ansieht und später eine Conversion ausführt, weisen Sie den Browser in unserem Beispiel an, zwei Beiträge zu generieren (einen pro Messziel).

Sie werden später sehen, dass ein aggregierter {aggregationsschlüssel, aggregierter Wert} nicht genau so aussieht. Konzentrieren wir uns vorerst auf die im Bericht enthaltenen Informationen.

Wenn Sie den Browser anweisen, zwei Beiträge zu generieren, wird ein aggregierter Bericht erstellt, sofern die Conversion mit einer vorherigen Ansicht oder einem vorherigen Klick abgeglichen werden kann.

Ein aggregierter Bericht enthält Folgendes:

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

Aggregierte Berichte sind im JSON-Format erstellt 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, wobei jeder Beitrag ein {aggregation key, aggregatable value}-Paar ist:

• bucket: der als Bytestring codierte Zusammenfassungsschlüssel
• value: der aggregierte Wert für dieses Messziel, codiert als Bytestring.

Beispiel:

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

In der Praxis sind aggregierbare Berichte so codiert, dass Buckets und Werte sich von dem im vorherigen Beispiel unterscheiden. Ein Bucket kann also wie \u0000\u0000\x80\u0000 aussehen. Bucket und value sind beides Bytestrings.

Zusammenfassende Berichte

Aggregierte Berichte werden für viele Browser und Geräte (Nutzer) wie folgt zusammengefasst:

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

Das Ergebnis ist ein Zusammenfassungsbericht, der eine Reihe von {aggregation key, summary value}-Paaren enthält.

Ein Zusammenfassungsbericht enthält Schlüssel/Wert-Paare im Stil eines JSON-Wörterbuchs. Jedes Paar enthält Folgendes:

• bucket: der als Bytestring codierte Zusammenfassungsschlüssel
• value: der Dezimalwert für ein bestimmtes Messziel, summiert aus allen verfügbaren aggregierten Berichten, mit einem zusätzlichen Rauschen.

Beispiel:

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

In der Praxis sind zusammenfassende Berichte so codiert, dass Buckets und Werte anders aussehen als im Beispiel angegeben (ein Bucket kann also wie \u0000\u0000\x80\u0000 aussehen). Bucket und value sind beides Bytestrings.

Aggregationsschlüssel in der Praxis

Aggregationsschlüssel (Buckets) werden von einem Anzeigentechnologie-Unternehmen in der Regel in zwei Schritten definiert: wenn eine Anzeige angeklickt oder angesehen wird und wenn ein Nutzer eine Conversion ausführt.

Schlüsselstruktur

Mit dem Begriff Schlüsselstruktur kennzeichnen wir die in einem Schlüssel codierten Dimensionen.

Beispiel: Kampagnen-ID × GeoID × Produktkategorie ist eine Schlüsselstruktur.

Schlüsseltypen

Die aggregierten Werte werden für einen bestimmten Schlüssel über mehrere Nutzer/Browser hinweg summiert. Wir haben jedoch festgestellt, dass mit aggregierten Werten verschiedene Messziele erfasst werden können, z. B. der Kaufwert oder die Anzahl der Käufe. Sie möchten sicherstellen, dass der Aggregationsdienst aggregierte Werte desselben Typs summiert.

Codieren Sie dazu in jedem Schlüssel ein Datenelement, aus dem hervorgeht, was der Zusammenfassungswert darstellt – das Messziel, auf das sich dieser Schlüssel bezieht. Eine Möglichkeit dafür besteht darin, eine zusätzliche Dimension für Ihren Schlüssel zu erstellen, die den Typ des Analyseziels darstellt.

In unserem Beispiel hätte dieser Typ von Messungsziel zwei verschiedene mögliche Werte:

• Die erste Art von Analyseziel ist die Anzahl der Käufe.
• Kaufwert ist die zweite Art von Analyseziel.

Wenn Sie n Messzielvorhaben hätten, hätte der Typ des Zielvorhabens n verschiedene Arten von Werten.

Die Dimensionen eines Schlüssels können Sie sich als Messwerte vorstellen. Beispiel: „Die Anzahl der Käufe eines bestimmten Produkts pro Kampagne und Region.

Schlüsselgröße, Dimensionsgröße

Die maximale Schlüsselgröße wird in Bits definiert, also der Anzahl der Nullen und Einsen im Binärformat, um den vollständigen Schlüssel zu erstellen. Die API unterstützt eine Schlüssellänge von 128 Bit.

Diese Größe ermöglicht sehr detaillierte Schlüssel, aber detailliertere Schlüssel führen mit größerer Wahrscheinlichkeit zu verrauschten Werten. Weitere Informationen zu Geräuschen

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. Abhängig von ihrer Kardinalität muss jede Dimension durch eine bestimmte Anzahl von Bits dargestellt werden. Mit n Bits ist es möglich, 2ⁿ verschiedene Optionen auszudrücken.

Beispielsweise kann die Dimension „Land“ eine Kardinalität von 200 haben, weil es weltweit etwa 200 Länder gibt. Wie viele Bit sind erforderlich, um diese Dimension zu codieren?

7 Bit speichern nur 2⁷ = 128 verschiedene Optionen, also weniger als die erforderlichen 200.

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

Schlüsselcodierung

Wenn Sie Schlüssel im Browser festlegen, sollten diese hexadezimal codiert sein. In zusammenfassenden Berichten werden Schlüssel in Binärprogrammen angezeigt (und als Buckets benannt).

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

Angenommen, Sie verwenden einen Schlüssel zum Erfassen der folgenden Dimensionen:

• Kampagnen-ID
• Geografische ID
• Produktkategorie

Während die Dimensionen „Kampagnen-ID“ und „Geografische ID“ bekannt sind, wenn die Anzeige ausgeliefert wird (Zeit der Anzeigenbereitstellung), ist die Produktkategorie aus einem Triggerereignis bekannt, wenn der Nutzer eine Conversion ausführt (Conversion-Zeit).

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

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

Diese verschiedenen Teile der Tasten werden als Schlüsselelemente bezeichnet.

Ein Schlüssel wird anhand des XOR (^) seiner Schlüsselelemente berechnet.

Beispiel:

• Quellseitiger Schlüsselteil = 0x159
• Schlüsselelement auf Triggerseite = 0x400
• Schlüssel = 0x159 ^ 0x400 = 0x559

Die wichtigsten Elemente aufeinander abstimmen

Da zwei 64-Bit-Schlüsselelemente mithilfe sorgfältig platzierter 64-Bit-Füller/Offsets (die sechzehn Nullen) auf 128 Bit erweitert wurden, entspricht die XOR-Verkettung der Schlüsselteile, was einfacher zu verstehen und zu überprüfen ist:

• Quellseitiger Schlüsselteil = 0xa7e297e7c8c8d0540000000000000000
• Schlüsselelement auf Triggerseite = 0x0000000000000000674fbe308a597271
• Schlüssel = 0xa7e297e7c8c8d0540000000000000000 ^ 0x0000000000000000674fbe308a597271 = 0xa7e297e7c8c8d054674fbe308a597271

Mehrere Schlüssel pro Anzeigenklick oder Ansicht

In der Praxis können Sie mehrere Schlüssel pro Ereignis der Attributionsquelle (Anzeigenklick oder Aufruf) festlegen. Sie können beispielsweise Folgendes festlegen:

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

Strategie B ist ein weiteres Beispiel.

Dimensionen in Schlüssel codieren

Wenn Sie zusammenfassende Berichte anfordern, müssen Sie dem Aggregationsdienst mitteilen, auf welche Messwerte Sie zugreifen möchten, indem Sie zusammenfassende Berichte für einen bestimmten Satz von Aggregationsschlüsseln anfordern.

Zusammenfassungsberichte enthalten unformatierte {key, summary value}-Paare und keine zusätzlichen Informationen über den Schlüssel. Das bedeutet Folgendes:

• Wenn Sie Schlüssel festlegen, wenn ein Nutzer eine Anzeige sieht oder klickt und später eine Conversion ausführt, müssen Sie Schlüssel zuverlässig auf Grundlage der Werte der Dimensionen festlegen, die sie darstellen.
• Wenn Sie die Schlüssel definieren, für die Sie zusammenfassende Berichte anfordern möchten, müssen Sie zuverlässig dieselben Schlüssel generieren oder direkt aufrufen wie die Schlüssel, die festgelegt wurden, als der Nutzer eine Anzeige angesehen oder darauf geklickt hat und zu einer Conversion geführt hat. Diese Schlüssel basieren auf den Werten der Dimensionen, für die Sie aggregierte Daten sehen möchten.

Dimensionen mithilfe von Schlüsselstrukturzuordnungen codieren

Wenn Sie Dimensionen als Schlüssel codieren möchten, können Sie nach der Definition Ihrer Schlüssel (vor der Anzeigenbereitstellung) eine Schlüsselstrukturkarte erstellen und verwalten.

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 Decoderlogik implementieren und pflegen. Falls Sie nach einer Methode suchen, bei der dies nicht erforderlich ist, sollten Sie stattdessen einen Hash-basierten Ansatz in Betracht ziehen.

Beispiel:

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

Die Produktkategorie, die Geografie-ID und die Kampagnen-ID müssen Dimensionen in Ihren Schlüsseln sein. Da Sie zwei verschiedene Messziele – Kaufzahl und Kaufwert – erfassen möchten, müssen Sie Ihrem Schlüssel außerdem eine Dimension hinzufügen, die den Schlüsseltyp erfasst. Auf diese Weise können Sie definieren, was der aggregierte Wert tatsächlich darstellt, wenn er {key, aggregatable value}-Paare in Zusammenfassungsberichten empfangen.

Bei diesen Messzielen hat Ihr Schlüssel die folgenden Dimensionen:

• Produktkategorie
• Zielvorhabentyp für Messung
• Geografische ID
• Kampagnen-ID

Wenn wir uns nun jede Dimension ansehen, gehen wir für Ihren Anwendungsfall davon aus, dass Sie Folgendes erfassen müssen:

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

Hier sehen Sie die Anzahl der Bits, die Sie benötigen, um jede Dimension in Ihrem Schlüssel zu codieren:

• Produktkategorie: 5 Bit (2⁵ = 32 > 29).
• Zielvorhabentyp für Messung: 1 Bit. Das Messziel ist entweder die Anzahl der Käufe oder der Kaufwert. Das bedeutet, dass zwei verschiedene Möglichkeiten vorhanden sind. Daher reicht ein Bit aus, um diese zu speichern.

• Geografische ID: 3 Bit (2³ = 8) Außerdem müssen Sie eine Dimensionszuordnung für die geografische ID definieren, um die geografische Region zu ermitteln, die jeder Binärwert darstellt. Die Dimensionszuordnung für die Dimension „Geografische ID“ könnte so aussehen:

  Binärwert im Schlüssel	Region
  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 würde die Schlüsselstrukturzuordnung für diese Schlüssel so aussehen:

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

Um zu veranschaulichen, wie Dimensionen eine Schlüsselstruktur ausmachen, verwenden wir eine binäre Darstellung. Deshalb ist 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 niedrigstwertige Bit – das Bit mit dem kleinsten numerischen Wert – ist das Bit ganz rechts.

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

Nehmen wir 0b1100100111100 als willkürlichen Beispielschlüssel und wir gehen davon aus, dass Sie wissen, dass dieser Schlüssel der Schlüsselstrukturzuordnung aus der vorherigen Abbildung folgt.

Laut Schlüsselstrukturzuordnung würde dieser Schlüssel in 11001 0 011 1100 decodiert werden.

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

Dimensionen mit einer Hash-Funktion codieren

Anstatt eine Schlüsselstrukturzuordnung zu verwenden, können Sie auch eine Hash-Funktion verwenden, um Schlüssel auf einheitliche und zuverlässige Weise dynamisch zu generieren.

Das funktioniert so:

1. Wählen Sie einen Hash-Algorithmus aus.
2. Generieren Sie zum Zeitpunkt der Anzeigenschaltung einen String, der alle Dimensionen, die Sie verfolgen möchten, und deren Werte enthält. Hashen Sie diesen String, um das quellseitige Schlüsselteil zu generieren. Erwägen Sie, ein 64-Bit-Suffix mit Nullen hinzuzufügen, um ihn mit dem Trigger-seitigen Schlüsselteil auszurichten und XOR einfacher zu verstehen.
   • Quellseitiger Schlüsselteil
     = <64-bit hex hash("COUNT, campaignID=12, geoID=7"))><64-bit 00000000…>
   • Beachten Sie, dass COUNT im Schlüsselstrukturzuordnungsansatz dasselbe wie measurementGoalType=0 codiert. COUNT ist etwas schlanker und expliziter.
3. Generieren Sie zum Zeitpunkt der Conversion einen String, der alle zu erfassenden Dimensionen und deren Werte enthält. Hashen Sie diesen String und fügen Sie ein 64-Bit-Präfix aus Nullen hinzu, um ein Schlüsselteil auf Triggerseite zu generieren:
   • Schlüsselelement auf Triggerseite = <64-bit 00000000…><64-bit hex hash("productCategory=25")>
4. Der Browser führt eine XOR-Verknüpfung dieser Schlüsselelemente durch, 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 Zusammenfassungsbericht für diesen Schlüssel anfordern möchten, können Sie ihn direkt generieren:
   • Generieren Sie basierend auf den Dimensionen, die Sie interessieren, einen quell- und einen trigger-seitigen Schlüsselteil, wie zuvor.
     • Quellseitiger Schlüsselteil
       = <64-bit hex hash("COUNT, campaignID=12, geoID=7"))><64-bit 00000000…>
     • Schlüsselelement auf Trigger-Seite
       = <64-bit 00000000…><64-bit hex hash("productCategory=25")>
     • Schlüsselteil auf Triggerseite = toHex(hash("productCategory=25"))
   • Genau wie der Browser können Sie diese Schlüsselelemente mit einer XOR-Verknüpfung versehen, 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 einige praktische Tipps für diesen hashbasierten Ansatz:

• Verwenden Sie immer dieselbe Reihenfolge der Dimensionen. Dadurch wird sichergestellt, dass Ihre Hashes zuverlässig neu generiert werden können. "COUNT, CampaignID=12, GeoID=7" generiert nicht den gleichen Hash wie "COUNT, GeoID=7, CampaignID=12". Eine einfache Möglichkeit, dies zu erreichen, besteht darin, Dimensionen alphanumerisch zu sortieren. Das werden wir im Beispiel tun, mit Ausnahme der Tatsache, dass immer COUNT oder VALUE als erstes Element in der Dimension festgelegt wird. Das ist aus Gründen der Lesbarkeit wichtig, da COUNT oder VALUE Informationen codiert, die sich konzeptionell von allen anderen Dimensionen leicht unterscheiden.
• Behalten Sie den Satz von Dimensionen im Auge, den Sie in Schlüsseln verwenden. Sie möchten verhindern, dass Schlüssel auf der Grundlage von Dimensionen generiert werden, die Sie noch nie verwendet haben.
• Hash-Kollisionen sind selten, wenn eine geeignete Hash-Funktion verwendet wird. Bei der Prüfung zuvor verwendeter Hashes, die gespeichert werden sollten, um die Ergebnisse des Aggregationsdienstes zu interpretieren, kann jedoch vermieden werden, dass neue Schlüssel mit älteren Schlüsseln kollidieren.

Beispiel für eine Conversion pro Klick oder Aufruf

Aggregierbare Werte in der Praxis

Das Unternehmen für Anzeigentechnologie legt aggregierbare Werte fest, wenn ein Nutzer eine Conversion ausführt.

Aus Datenschutzgründen gilt für die Beiträge der einzelnen Nutzer eine Obergrenze. Für alle aggregierbaren Werte, die einer einzelnen Quelle (Anzeigenklick oder Aufruf) zugeordnet sind, darf kein Wert höher sein als ein bestimmtes Beitragslimit.

Dieses Limit wird als CONTRIBUTION_BUDGET bezeichnet. In der Erläuterung wird dieses Limit als L1-Budget bezeichnet, ist aber mit CONTRIBUTION_BUDGET identisch.

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

Beispiel: eine Conversion pro Klick oder Aufruf

Nehmen wir für dieses Beispiel an, dass Sie die folgenden Fragen beantworten möchten:

• 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 Erkenntnisse benötigen.

Außerdem müssen Sie Folgendes erfassen:

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

Geeignete Messwerte

Viele Unternehmen im Bereich Anzeigentechnologie empfehlen Werbetreibenden, eine Vielzahl von Conversion-Typen zu konfigurieren. Die Konzentration auf die wichtigsten Conversions (z. B. Käufe) ist jedoch eine gute Möglichkeit, um detaillierte und genaue Gesamtergebnisse für diese wichtigen Conversion-Ereignisse zu erhalten. Je mehr Messwerte Sie messen, desto geringer ist Ihr Beitragsbudget pro Messwert und desto ungenauer ist wahrscheinlich jeder Wert. Daher müssen Sie sorgfältig auswählen, was gemessen werden soll.

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

Sie messen weiterhin sowohl die Anzahl der Käufe als auch den Kaufwert und haben Zugriff auf eine Vielzahl wichtiger zusammengefasster Statistiken wie den Gesamtkaufwert und geografische Aufschlüsselungen. So wird das Rauschen in einem angemessenen Rahmen gehalten und Ihr Beitragsbudget lässt sich einfach skalieren.

Was ist mit Währungen?

Bei Kampagnen, die in verschiedenen Regionen geschaltet werden, müssen die Währungen berücksichtigt werden. Sie haben folgende Möglichkeiten:

• Sie können die Währung in den Aggregationsschlüsseln als eigene Dimension festlegen.
• Alternativ können Sie die Währung von 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 von einer Kampagnen-ID ableiten können. Damit können Sie einen beliebigen Kaufwert aus der Landeswährung des Nutzers in eine Referenzwährung Ihrer Wahl umrechnen. Sie können die Conversion auch spontan ausführen, wenn der Nutzer einen Artikel kauft.

Bei diesem Verfahren befinden sich alle aggregierbaren Werte in derselben Referenzwährung und können daher summiert werden, um einen aggregierten Gesamtkaufwert – einen zusammenfassenden Kaufwert – zu generieren.

Ziele in Schlüssel umwandeln

Bei Ihren Messzielen und -messwerten gibt es eine Reihe von Optionen für Ihre Hauptstrategie. Konzentrieren wir uns auf zwei dieser Strategien:

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

Strategie A: eine tiefe Baumstruktur (eine detaillierte Schlüsselstruktur)

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

Diese Struktur wird von allen Schlüsseln verwendet.

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

• Schlüsseltyp 0: Messungszieltyp = 0. Dies legen Sie als Anzahl der Käufe fest.
• Schlüsseltyp 1: Messzieltyp = 1, den Sie als Kaufwert definieren möchten.

Zusammenfassungsberichte sehen so aus:

Sie können sich Strategie A als eine „One Deep Tree“-Strategie vorstellen:

• Jeder Zusammenfassungswert in Zusammenfassungsberichten ist allen zu erfassenden Dimensionen zugeordnet.
• Sie können diese Zusammenfassungswerte zusammen mit jeder dieser Dimensionen zusammenfassen, sodass diese Rollups so tief gehen können wie die Anzahl der Dimensionen, die Sie haben.

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

Frage	Antworten
Welche Produktkategorien sind in den einzelnen Regionen am wertvollsten?	Addieren Sie die zusammengefassten Kaufzahlen und -werte in den zusammenfassenden Berichten für alle Kampagnen. Damit erhalten Sie die Anzahl der Käufe und den Wert pro Geo-ID × Produktkategorie. Vergleiche für jede Region den Kaufwert und die Anzahl der verschiedenen Produktkategorien.
Welche Kampagnenstrategien sind in den einzelnen Regionen am effektivsten?	Addieren Sie die zusammengefassten Kaufzahlen und -werte in den zusammenfassenden Berichten für alle Produktkategorien. Damit erhalten Sie die Anzahl der Käufe und den Wert pro Kampagnen-ID × geografischer ID. Vergleichen Sie für jede Region den Kaufwert und die Anzahl der Käufe in verschiedenen Kampagnen.

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

„Wie viel Umsatz hat meine Kampagne in den einzelnen Regionen für die einzelnen Produkte generiert?“

Auch wenn die Summe der Werte verrauscht ist, können Sie ermitteln, wann Unterschiede in dem gemessenen Wert zwischen den einzelnen Kampagnen nicht allein auf Rauschen zurückzuführen sind. Weitere Informationen dazu finden Sie unter Rauschen verstehen.

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

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

Sie teilen jede dieser Schlüsselstrukturen in zwei Schlüsseltypen auf, um zwei Messziele zu unterstützen.

• Zielvorhabentyp für Messung = 0. Dies legen Sie als Anzahl der Käufe fest.
• Messwerttyp = 1, den Sie als Kaufwert definieren.

Am Ende haben Sie vier Schlüsseltypen:

• 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 wie eine Strategie mit zwei seichten Bäumen vorstellen:

• Die Zusammenfassungswerte in Zusammenfassungsberichten entsprechen einer von zwei kleinen Sätzen von Dimensionen.
• Sie können diese Zusammenfassungswerte zusammen mit den einzelnen Dimensionen in diesen Sätzen zusammenfassen. Das bedeutet, dass diese Rollups nicht so tief sind wie in Option A, da weniger Dimensionen für die Zusammenfassung vorhanden sind.

Bei Strategie B würden Sie Ihre Fragen wie folgt beantworten:

Frage	Antworten
Welche Produktkategorien sind in den einzelnen Regionen am wertvollsten?	Du kannst direkt auf die zusammengefassten Kaufzahlen und -werte in den zusammenfassenden Berichten zugreifen.
Welche Kampagnenstrategien sind in den einzelnen Regionen am effektivsten?	Du kannst direkt auf die zusammengefassten Kaufzahlen und -werte in den zusammenfassenden Berichten zugreifen.

Entscheidung: Strategie A

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

Bei Strategie A müssen Sie jedoch die zusammenfassenden Werte zusammenfassen, die Sie in den Zusammenfassungsberichten erhalten, um einige Ihrer Fragen zu beantworten. Jeder dieser Zusammenfassungswerte ist verrauscht. Durch die Addition dieser Daten wird gleichzeitig das Rauschen summiert.

Bei Strategie B ist dies nicht der Fall, da die in den Zusammenfassungsberichten dargestellten Zusammenfassungswerte bereits die benötigten Informationen enthalten. Das bedeutet, dass Strategie B wahrscheinlich weniger Auswirkungen durch Störfaktoren hat als Strategie A.

Wie sollten Sie sich für eine Strategie entscheiden? Bei bestehenden Werbetreibenden oder Kampagnen können Sie anhand von Verlaufsdaten feststellen, ob das Conversion-Volumen besser für Strategie A oder Strategie B geeignet ist. Für neue Werbetreibende oder Kampagnen haben Sie jedoch folgende Optionen:

• Mit den detaillierten Schlüsseln die Daten eines Monats erfassen (Strategie A). Da Sie die Dauer der Datenerhebung verlängern, sind die Zusammenfassungswerte höher und das Rauschen relativ niedriger.
• Beurteilen Sie die wöchentliche Conversion-Anzahl und den Kaufwert mit angemessener Genauigkeit.

Nehmen wir in diesem Beispiel an, dass die wöchentliche Anzahl von Käufen und der Kaufwert hoch genug sind, dass Strategie A zu einem verrauschten Prozentsatz führen würde, den Sie für Ihren Anwendungsfall akzeptabel erachten.

Da Strategie A einfacher ist und zu negativen Auswirkungen führt, die Ihre Entscheidungsfindung nicht beeinträchtigen, entscheiden Sie sich für Strategie A.

Hash-Algorithmus auswählen

Sie entscheiden sich für einen Hash-basierten Ansatz, um Ihre Schlüssel zu generieren. Dazu müssen Sie einen Hash-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.

Im Browser: Schlüssel und Werte festlegen

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

Als Nächstes sehen Sie eine Übersicht über die Header, die Sie zum Registrieren von Schlüsseln und Werten im Browser festlegen:

Wichtige Elemente auf Quellseite festlegen

Wenn ein Nutzer auf eine Anzeige klickt oder sie 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üsselteils festlegen, der zum Zeitpunkt der Anzeigenbereitstellung bekannt ist.

Generieren wir die wichtigsten Elemente:

Quellseitiger Schlüssel für die Schlüssel-ID...	String mit den Dimensionswerten, die Sie festlegen möchten	Hash-Wert dieses Strings als Hexadezimalwert, gekürzt auf die ersten 64 Bit (64/4 = 16 Zeichen1)	Hexadezimal-Hash mit angehängten Nullen zur Vereinfachung des XOR-Verfahrens. Dies ist der quellseitige Schlüsselteil.
key_purchaseCount	COUNT, CampaignID=12, GeoID=7	0x3cf867903fbb73ec	0x3cf867903fbb73ec0000000000000000
key_purchaseValue	VALUE, CampaignID=12, GeoID=7	0x245265f432f16e73	0x245265f432f16e730000000000000000

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 erscheinen nicht in den endgültigen Berichten. Sie werden nur verwendet, wenn Schlüssel im Browser festgelegt werden, sodass quell- und triggerseitige Schlüsselelemente einander zugeordnet und zu einem vollständigen Schlüssel kombiniert werden können.

Optional: Berichte auf Ereignisebene

Wenn Sie Berichte auf Ereignisebene parallel zu aggregierbaren Berichten verwenden müssen, müssen Sie dafür sorgen, dass für eine bestimmte Quelle die Daten auf Ereignisebene (Quellereignis-ID und Triggerdaten) und der Aggregationsschlüssel abgeglichen werden können.

Sie können beide Berichte verwenden, wenn Sie beispielsweise Berichte auf Ereignisebene verwenden möchten, um Modelle für die Anzeigentypen zu erstellen, die in der Regel zu den meisten Käufen führen.

Ein Nutzer führt eine Conversion durch.

Wenn ein Nutzer eine Conversion ausführt, wird normalerweise eine Pixelanfrage an den AdTech-Server gesendet. Nach Erhalt dieser Anfrage:

• Legen Sie die Schlüsselelemente auf Conversion-Seite (Trigger-Seite) fest, um den Schlüssel zu vervollständigen. Diese Schlüsselelemente legen Sie über die Überschrift Attribution-Reporting-Register-Aggregatable-Trigger-Data fest.
• Legen Sie den aggregierten Wert für diese Conversion über die Kopfzeile Attribution-Reporting-Register-Aggregatable-Values fest.

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

Generieren wir die wichtigsten Elemente:

Schlüsselteil auf Triggerseite für die Schlüssel-ID...	String mit den Dimensionswerten, die Sie festlegen möchten	Hash-Wert dieses Strings als Hexadezimalwert, gekürzt auf die ersten 64 Bit (64/4 = 16 Zeichen1)	Hexadezimal-Hash mit angehängten Nullen zur simplify des XOR-Verfahrens. Dies ist der quellseitige Schlüsselteil.
key_purchaseCount	ProductCategory=25	0x1c7ce88c4904bbe2	0x0000000000000000f9e491fe37e55a0c
key_purchaseValue	(gleich)	(gleich)	(gleich)

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"]
    },
  ])
);

Sie fügen denselben Schlüssel zu mehreren Schlüsseln hinzu, indem Sie mehrere Schlüssel-IDs in source_keys auflisten. Der Schlüssel wird beiden Schlüsseln hinzugefügt.

Aggregierbare Werte festlegen

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

Angenommen, der Produkttyp 25 wurde einmalig zum Preis von 52 € gekauft.

Sie legen diese nicht direkt als aggregierbare Werte fest:

• key_purchaseCount: 1 Conversion
• key_purchaseValue: 52 $

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

Sie haben zwei Ziele, für die Sie Ihr Beitragsbudget ausgeben möchten. Daher sollten Sie das Beitragsbudget möglicherweise auf zwei 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 basierend auf den bisherigen Käufen aller Nutzer der Website 1.500 $. Es kann Ausreißer geben, z. B. nur sehr wenige Nutzer, die mehr ausgegeben haben, aber Sie können diese Ausreißer ignorieren.

Der Skalierungsfaktor für den Kaufwert sollte wie folgt sein:

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

Der Skalierungsfaktor für die Anzahl der Käufe beträgt 32.768 ÷ 1 = 32.768, da Sie sich dafür entschieden haben, höchstens einen Kauf pro Anzeigenklick oder Aufruf zu erfassen (Quellereignis).

Sie können jetzt diese Werte festlegen:

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

In der Praxis würden Sie sie mit dem dedizierten Header Attribution-Reporting-Register-Aggregatable-Values so festlegen:

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

Der aggregierte Bericht wird erstellt.

Der Browser gleicht die Conversion mit einer vorherigen Ansicht oder einem vorherigen Klick ab und erstellt einen aggregierten Bericht, der die verschlüsselte Nutzlast neben den Berichtsmetadaten enthält.

Im Folgenden finden Sie ein Beispiel für die Daten, die in der Nutzlast des aggregierten Berichts gefunden werden konnten, sofern sie in Klartext lesbar waren:

[
  {
    key: 0x3cf867903fbb73ecf9e491fe37e55a0c, // = source-side key piece XOR 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 XOR 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 aggregierten Bericht.

Zusammenfassenden Bericht anfordern

• Aggregierbare Batch-Berichte. Beachten Sie die Hinweise unter Batching.
• Generieren Sie die Schlüssel, für die Sie Daten sehen möchten. So rufen 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 auf:
  • Generieren Sie den quellseitigen Schlüssel wie bei der Einstellung im Browser.
  • Generieren Sie den Trigger-Schlüssel wie bei der Einstellung im Browser.

Anzurufender Messwert1	Zentraler Bestandteil der Quelle	Schlüsselelement auf Triggerseite	Schlüssel für die Anfrage an den Aggregationsdienst2
Gesamtzahl der Käufe (COUNT)	0x3cf867903fbb73ec 0000000000000000	0x00000000000000 00f9e491fe37e55a0c	0x3cf867903fbb73 ecf9e491fe37e55a0c
Gesamtkaufwert (VALUE)	0x245265f432f16e73 0000000000000000	0x0000000000000000 f9e491fe37e55a0c	0x245265f432f16e73 f9e491fe37e55a0c

• Fordern Sie zusammenfassende Daten für diese Schlüssel an den Aggregationsdienst an.

Zusammenfassungsbericht verwenden

Letztendlich erhalten Sie einen zusammenfassenden Bericht, der wie folgt aussehen könnte:

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

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

Werte herunterskalieren

• 2.558.500 bezieht sich auf die Anzahl der Käufe für diesen Schlüssel, hochskaliert um den zuvor berechneten Skalierungsfaktor. Der Skalierungsfaktor für die Anzahl der Käufe betrug 32.768. Teilen Sie 2.558.500 durch das Beitragsbudget des Zielvorhabens: 2.558.500/32.768 = 156,15 Käufe.
• 687.060 → 687.060/22 = 31.230 € Gesamtkaufwert

Daher enthalten die Zusammenfassungsberichte folgende Informationen:

• Im Berichtszeitraum wurden mit Kampagne 12 in Europa etwa 156 Käufe (± Rauschen) für die Produktkategorie 25 erzielt.
• Im Berichtszeitraum führte Kampagne 12 in Europa zu Käufen in Höhe von 31.230 $ (± Rauschen) für die Produktkategorie 25.