Aggregationsschlüssel für Attributionsberichte

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

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

1. Wie viele Käufe aus jeder Produktkategorie wurden mit meinen Kampagnen in den einzelnen Regionen erzielt?
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 erhoben werden.

Dimensionen, Schlüssel und Werte

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

Dimensionen

Wenn Sie wissen möchten, wie Sie mit Ihren Kampagnen Umsatz erzielen, sollten Sie die folgenden Dimensionen erfassen:

• Werbekampagnen-ID: Die Kennung der jeweiligen Kampagne.
• Geografische ID: Die 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 in dem 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 Kaufanzahl). Nach der Zusammenfassung und Verfügbarkeit in einem Zusammenfassungsbericht entspricht dieser Wert der 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).

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

Wenn ein Nutzer mit der Standort-ID 7 eine Anzeige für Kampagnen-ID 12 sieht und später ein Produkt aus Produktkategorie 25 für 120 $ kauft (vorausgesetzt, Ihre Währung ist USD), können Sie einen Aggregationsschlüssel und aggregierbare Werte wie die folgenden festlegen:

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

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

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 sich aggregierbare Schlüssel und Werte auf Berichte auswirken.

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.

In unserem Beispiel wird der Browser angewiesen, zwei Beiträge zu generieren (jeweils einen pro Analyseziel), wenn ein Nutzer auf eine Anzeige klickt oder sie sich ansieht und später eine Conversion ausführt.

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 Bericht, der aggregiert werden kann, enthält Folgendes:

• Die von Ihnen konfigurierten Beiträge.
• Metadaten zum Klick- oder Aufrufereignis und zum Conversion-Ereignis, z. B. die Website, auf der die Conversion stattgefunden hat. 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.
• Aggregierbare Berichte werden vom Aggregationsdienst entschlüsselt.
• Für jeden Schlüssel werden die aggregierbaren Werte aus den entsprechenden Berichten addiert.
• 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 einen Satz von Schlüssel/Wert-Paaren im Stil eines JSON-Wörterbuchs. Jedes Paar enthält Folgendes:

• bucket: der als Bytestring codierte Zusammenfassungsschlüssel
• value: Der zusammengefasste Wert in Dezimalform für ein bestimmtes Analyseziel, der aus allen verfügbaren aggregierbaren Berichten ermittelt wird, mit zusätzlichem Rauschen.

Beispiel:

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

In der Praxis werden Zusammenfassungsberichte so codiert, dass sich Buckets und Werte von den im Beispiel angegebenen unterscheiden. Ein Bucket kann also beispielsweise \u0000\u0000\x80\u0000 lauten. Bucket und Wert sind beide 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 bezeichnen 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 dafür sorgen, dass der Aggregationsdienst aggregierbare Werte desselben Typs addiert.

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

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

• Kaufmenge ist der erste Messvorhabentyp.
• Kaufwert ist der zweite Messvorhabentyp.

Wenn Sie n Messzielvorhaben haben, hätte der Zielvorhabentyp n verschiedene Arten von Werten.

Die Dimensionen eines Schlüssels können Sie sich als Messwerte vorstellen. Beispiel: „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 Rauschen finden Sie unter Rauschen verstehen.

Wie bereits erwähnt, werden Dimensionen in den 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 können 2ⁿ verschiedene Optionen ausgedrückt werden.

Die Kardinalität einer Länderdimension kann beispielsweise 200 betragen, da es etwa 200 Länder auf der Welt gibt. Wie viele Bits sind zum Codieren dieser Dimension erforderlich?

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 sie hexadezimal codiert sein. In Zusammenfassungsberichten werden Schlüssel im Binärformat angezeigt und als Buckets bezeichnet.

Zwei Schlüsselteile 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. Sie legen einen Teil des Schlüssels – Kampagnen-ID × Geografie-ID – beim Klicken oder Aufrufen fest.
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üsselteile bezeichnet.

Zur Berechnung eines Schlüssels wird das ODER (v) seiner Schlüsselteile genommen.

Beispiel:

• Quellseitiger Schlüssel = 0x159
• Schlüsselteil auf der Triggerseite = 0x400
• Schlüssel = 0x159 v 0x400 = 0x559

Wichtige Elemente ausrichten

Wenn zwei 64‑Bit-Schlüsselteile mithilfe sorgfältig platzierter 64‑Bit-Füller/Offset (die 16 Nullen) auf 128 Bit erweitert werden, entspricht das OR-Verknüpfen der Schlüsselteile dem Zusammenführen der Schlüsselteile, was einfacher zu begründen und zu überprüfen ist:

• Quellseitiger Schlüsselteil = 0xa7e297e7c8c8d0540000000000000000
• Schlüsselteil auf der Triggerseite = 0x0000000000000000674fbe308a597271
• Schlüssel = 0xa7e297e7c8c8d0540000000000000000 v 0x0000000000000000674fbe308a597271 = 0xa7e297e7c8c8d054674fbe308a597271

Mehrere Schlüssel pro Anzeigenklick oder -aufruf

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

• Ein Schlüssel, mit dem die Kombination aus Standort-ID und Kampagnen-ID erfasst wird.
• Ein weiterer Schlüssel, mit dem der Creative-Typ und die Kampagnen-ID erfasst werden.

Sehen Sie sich Strategie B als Beispiel an.

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 darauf klickt und später eine Conversion ausführt, müssen Sie die Schlüssel zuverlässig anhand der Werte der entsprechenden Dimensionen festlegen.
• Wenn Sie die Schlüssel definieren, für die Sie Zusammenfassungsberichte anfordern möchten, müssen Sie dieselben Schlüssel wie die Schlüssel generieren oder dynamisch abrufen, die festgelegt wurden, als der Nutzer eine Anzeige aufgerufen oder angeklickt und eine Conversion ausgeführt hat. Dabei müssen Sie sich an den Werten der Dimensionen orientieren, 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 Pflegen von Schlüsselstrukturkarten, dass Sie Dekodierungslogik implementieren und pflegen müssen. Wenn Sie nach einer Methode suchen, bei der Sie das nicht tun müssen, sollten Sie stattdessen einen hashbasierten Ansatz verwenden.

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. So können Sie festlegen, was der aggregierbare Wert tatsächlich darstellt, wenn Sie {Schlüssel, aggregierbarer Wert}-Paare in Zusammenfassungsberichten erhalten.

Bei diesen Analysezielen 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)
• Art des Messziels: 1 Bit. Das Messziel ist entweder die Anzahl der Käufe oder der Kaufwert. Das bedeutet, dass zwei unterschiedliche Möglichkeiten vorhanden sind. Daher reicht ein Bit aus, um sie 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	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 würde die Schlüsselstrukturkarte für diese Schlüssel so aussehen:

Die Reihenfolge der Dimensionen innerhalb des Schlüssels liegt bei Ihnen.

Um zu veranschaulichen, wie sich Dimensionen zu einem Schlüssel zusammensetzen, verwenden wir eine Binärdarstellung. Die Kampagnen-ID (erste Bits) ist daher die äußerste rechts und die Produktkategorie (letzte Bits) die äußerste links.

Innerhalb jeder Dimension ist das höchstwertige Bit – das mit dem größten numerischen Wert – das Bit ganz links. Das Bit mit dem kleinsten numerischen Wert ist das Bit ganz rechts.

Sehen wir uns an, wie Sie mit einer Schlüsselstrukturkarte einen Schlüssel decodieren.

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

Gemäß der Schlüsselstrukturkarte würde dieser Schlüssel in folgende Zeichenfolge decodiert:

`11001 0 011 1100`

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

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 Hash-Algorithmus aus.
2. Erstellen Sie zum Zeitpunkt der Anzeigenbereitstellung einen String, der alle zu erfassenden Dimensionen und ihre Werte enthält. Um das Quellschlüsselelement zu generieren, hashen Sie diesen String und fügen Sie gegebenenfalls ein 64-Bit-Suffix mit Nullen hinzu, um es mit dem triggerseitigen Schlüsselelement auszurichten und die OR-Bedingung leichter verständlich zu machen.
   • Quellseitiger Schlüssel
     = <64-bit hex hash("COUNT, campaignID=12, geoID=7"))><64-bit 00000000…>
   • Beachten Sie, dass COUNT im Ansatz der Schlüsselstrukturkarte dasselbe codiert wie measurementGoalType=0. 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. Um einen Trigger-Schlüssel zu generieren, hashieren Sie diesen String und fügen Sie ein 64-Bit-Präfix aus Nullen hinzu:
   • Schlüsselelement auf Triggerseite = <64-bit 00000000…><64-bit hex hash("productCategory=25")>
4. Der Browser verbindet diese Schlüsselelemente mit einer OR-Verknüpfung, 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 im Handumdrehen generieren:
   • Generieren Sie basierend auf den Dimensionen, die Sie interessieren, einen quell- und einen trigger-seitigen Schlüsselteil, wie zuvor.
     • Quellseitiger Schlüssel
       = <64-bit hex hash("COUNT, campaignID=12, geoID=7"))><64-bit 00000000…>
     • Schlüsselteil auf der Triggerseite 
       = <64-bit 00000000…><64-bit hex hash("productCategory=25")>
     • Schlüsselteil auf der Triggerseite = toHex(hash("productCategory=25"))
   • Genau wie der Browser können ODER diese Schlüsselelemente verwendet werden, 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 die 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. 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, können jedoch neue Schlüssel vermieden werden, die mit älteren Schlüsseln kollidieren.

Im Beispiel Eine Conversion pro Klick oder Aufruf erfahren Sie, wie Sie hashbasierte Schlüssel in der Praxis verwenden.

Aggregierbare Werte in der Praxis

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

Zum Schutz der Privatsphäre der Nutzer gibt es ein Obergrenze für die Beiträge einzelner Nutzer. 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, entspricht aber dem CONTRIBUTION_BUDGET.

Ausführliche Informationen zum Beitragsbudget finden Sie im Hilfeartikel Beitragsbudget für Zusammenfassungsberichte.

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 im Blick behalten:

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

Geeignete Messwerte

Viele Anbieter von Anzeigentechnologien empfehlen Werbetreibenden, eine Vielzahl von Conversion-Typen zu konfigurieren. Wenn Sie sich jedoch auf die wichtigsten Conversions wie Käufe konzentrieren, können Sie dafür sorgen, dass die zusammengefassten Ergebnisse für diese wichtigen Conversion-Ereignisse detailliert und genau sind. 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 Kampagnen, bei denen nur eine Conversion pro Klick oder Aufruf erfasst wird: ein Kauf.

Sie können weiterhin sowohl die Anzahl der Käufe als auch den Kaufwert erfassen und auf eine Vielzahl wichtiger zusammengefasster Statistiken wie den Gesamtkaufwert und geografische Aufschlüsselungen zugreifen. 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.
• Sie können die Währung auch aus einer Kampagnen-ID ableiten und alle Währungen in eine Referenzwährung umrechnen.

In diesem Beispiel wird davon ausgegangen, dass Sie die Währung aus einer Kampagnen-ID ableiten können. Damit lässt sich ein bestimmter Kaufwert aus der Landeswährung des Nutzers in eine Referenzwährung Ihrer Wahl umrechnen. Sie können diese Conversion auch direkt 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: Ein tiefes Verzweigungsbaum-System (eine detaillierte Schlüsselstruktur)

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

Diese Struktur wird für alle Ihre Schlüssel verwendet.

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

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

Zusammenfassungsberichte sehen so aus:

Strategie A kann als „ein tiefes Baumdiagramm“ beschrieben werden:

• Jeder Zusammenfassungswert in Zusammenfassungsberichten ist allen Dimensionen zugeordnet, die Sie erfassen.
• Sie können diese zusammengefassten Werte mit jeder dieser Dimensionen zusammenfassen. Die Zusammenfassungen können also so detailliert sein wie die Anzahl der Dimensionen.

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

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.

• Messvorhabentyp = 0, den Sie als Anzahl der Käufe definieren.
• Messwerttyp = 1, den Sie als Kaufwert definieren.

Sie erhalten vier Haupttypen:

• 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 so beantworten:

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 Summe der zusammengefassten Werte in den Zusammenfassungsberichten berechnen, um einige Ihrer Fragen zu beantworten. Jeder dieser Zusammenfassungswerte ist verrauscht. Wenn Sie diese Daten zusammenfassen, summieren Sie auch den Rauschenpegel.

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 zu weniger Auswirkungen von Rauschen führt als Strategie A.

Wie sollten Sie entscheiden, 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 können Sie jedoch Folgendes festlegen:

• Sie erfassen Daten für einen Monat mit den detaillierten Schlüsseln (Strategie A). Da Sie die Dauer der Datenerhebung verlängern, sind die Summenwerte höher und die Abweichungen relativ geringer.
• Bewerten Sie die Anzahl der wöchentlichen Conversions 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 sich ansehen und anschließend eine Conversion ausführen.

Im Folgenden finden 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üsselelement festlegen, der zum Zeitpunkt der Anzeigenbereitstellung bekannt ist.

Erstellen 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 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 zusammen mit 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 in der Regel eine Pixelanfrage an den AdTech-Server gesendet. Wenn Sie diese Anfrage erhalten, geschieht Folgendes:

• Legen Sie die Schlüsselelemente auf Conversion-Seite (Triggerseite) fest, um den Schlüssel zu vervollständigen. Diese wichtigen Informationen legst du über den Header Attribution-Reporting-Register-Aggregatable-Trigger-Data fest.
• Legen Sie den aggregierbaren Wert für diese Conversion über die Kopfzeile Attribution-Reporting-Register-Aggregatable-Values fest.

Setzen Sie die Schlüsselteile auf der Auslöserseite, um den Schlüssel fertigzustellen.

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 dasselbe Schlüsselelement hinzufügen, indem Sie mehrere Schlüssel-IDs in source_keys angeben. Das Schlüsselelement wird dann 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 Abweichungen zu minimieren.

Sie haben zwei Ziele, für die Sie Ihr Beitragsbudget ausgeben möchten. Sie können es also in zwei Teile aufteilen.

In diesem Fall wird jedem Zielvorhaben maximal CONTRIBUTION_BUDGET/2 zugewiesen (= 65.536 ÷ 2 = 32.768).

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 so sein:

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

Der Skalierungsfaktor für die Kaufanzahl beträgt 32.768 ÷ 1 = 32.768, da Sie festgelegt haben, maximal einen Kauf pro Anzeigenklick oder -aufruf (Querereignis) zu erfassen.

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 Aufruf- oder Klicksitzung ab und generiert einen aggregierbaren Bericht, der neben den Berichtsmetadaten die verschlüsselte Nutzlast 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 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 aggregierten Bericht.

Zusammenfassenden Bericht anfordern

• Berichte, die in Batches zusammengefasst werden können. Folgen Sie den Tipps 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.

• 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 VALUE-Schlüssel im Binärformat. Die Schlüssel sind zwar heterogen (COUNT im Vergleich zu VALUE), sie befinden sich aber im selben Bericht.

Werte herunterskalieren

• 2.558.500 bezieht sich auf die Anzahl der Käufe für diesen Schlüssel, multipliziert mit dem zuvor berechneten Skalierungsfaktor. Der Skalierungsfaktor für die Anzahl der Käufe betrug 32.768. Dividieren 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:

- 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.