Aggregationsschlüssel für Attributionsberichte

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

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

1. Wie viele Käufe haben Sie mit den einzelnen Produktkategorien in den einzelnen Regionen generiert?
2. Wie viel Umsatz habe ich mit den einzelnen Produktkategorien in den einzelnen Regionen generiert?

Viele Unternehmen im Bereich Anzeigentechnologie empfehlen Werbetreibenden, verschiedene Conversion-Typen zu konfigurieren. Konzentrieren Sie sich jedoch auf die wichtigsten Conversions wie Käufe, um sicherzustellen, dass Zusammenfassungsergebnisse für diese wichtigen Ereignisse detailliert und genau sind.

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

Dimensionen, Schlüssel und Werte

Sehen wir uns zur Beantwortung dieser Fragen Dimensionen, Schlüssel und Werte an.

Hinweis:Die in diesem Dokument beschriebenen Aggregationsschlüssel gelten speziell für die Attribuion Reporting API.

Abmessungen

Wenn Sie wissen möchten, wie mit Ihren Kampagnen Umsatz generiert wird (siehe Beschreibung), können Sie die folgenden Dimensionen verwenden:

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

Während die Dimensionen „Kampagnen-ID“ und „Geografische ID“ bei der Auslieferung der Anzeige bekannt sind (Zeit der Anzeigenauslieferung), wird die Produktkategorie durch ein Trigger-Ereignis erfasst, wenn der Nutzer eine Conversion ausführt (Zeitpunkt der Conversion).

Hinweis:Für das Diagramm in diesem Dokument werden die Dimensionen so dargestellt: – Dimensionen, die zum Zeitpunkt der Anzeigenbereitstellung bekannt sind, vor grünem Hintergrund. – Dimensionen, die zum Zeitpunkt der Conversion bekannt sind, vor einem gelben Hintergrund und unterstrichen

Die Abmessungen, die Sie in diesem Beispiel erfassen möchten, sehen wie in der folgenden Abbildung dargestellt aus:

Zu verfolgende Dimensionen

Was sind Aggregationsschlüssel (Buckets)?

Die Begriffe „Aggregationsschlüssel“ und „Bucket“ beziehen sich auf dasselbe. Der Aggregationsschlüssel wird in den Browser-APIs verwendet, die zum Konfigurieren von Berichten verwendet werden. Der Begriff Bucket wird in Zusammenfassungs- und Zusammenfassungsberichten sowie in den Aggregation Service APIs verwendet.

Ein Aggregationsschlüssel ist ein Datenelement, das die Werte der erfassten Dimensionen darstellt. Die Daten werden später zusammen mit den einzelnen Aggregationsschlüsseln aggregiert.

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

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

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

Was sind aggregierbare Werte?

Bei der Beantwortung Ihrer Fragen zu den beschriebenen Dimensionen ist Folgendes erforderlich:

• Die Anzahl der Käufe (die Anzahl der Käufe). Nachdem die Daten zusammengefasst und in einem zusammenfassenden Bericht zur Verfügung gestellt wurden, entspricht dies der Gesamtzahl der Käufe (Zusammenfassung).
• Der Umsatz jedes Kaufs (der Kaufwert). Nachdem die Daten zusammengefasst und in einem zusammenfassenden Bericht zur Verfügung gestellt wurden, ist dies der Gesamtumsatz (Zusammenfassungswert).

Jedes davon – 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 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 wie folgt festlegen:

Aggregationsschlüssel und aggregierbare Werte. Hinweis: Aggregierbare Werte sind auf blauem Hintergrund fett formatiert.

Aggregierbare Werte werden pro Schlüssel für viele Nutzer zusammengefasst, um zusammengefasste Statistiken in Form von Zusammenfassungswerten in Zusammenfassungsberichten zu generieren.

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

Beachten Sie, dass in diesem Diagramm keine Entschlüsselung vorgenommen wird und es ein vereinfachtes Beispiel ohne Rauschen darstellt. 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 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.

Hinweis: In der <a href="https://github.com/WICG/conversion-measurement-api/blob/main/AGGREGATE.md">Erklärung</a> wird ein {aggregation key, aggregatable value}-Paar auch als Histobeitrag bezeichnet. Es zeigt an, wie diese Conversion – und die damit verbundenen Dimensionen und Werte – zum zusammenfassenden Bericht beitragen.

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

Sie werden später feststellen, dass ein {aggregation key, aggregatable value} aggregatabler Bericht nicht genau so aussieht. Konzentrieren wir uns jedoch zunächst auf die im Bericht enthaltenen Informationen.

Wenn Sie den Browser anweisen, zwei Unterstützungsbeiträge zu generieren, erstellt der Browser einen aggregierten Bericht, sofern er die Conversion mit einem vorherigen Aufruf oder Klick übereinstimmen kann.

Ein aggregierter Bericht 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 erfolgt ist) Alle Felder in einem aggregierten Bericht ansehen

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

Die Nutzlast enthält eine Liste von Beiträgen, die jeweils ein {aggregation key, aggregatable value}-Paar sind:

• Bucket: der Aggregationsschlüssel, codiert als Bytestring.
• value: der aggregierbare Wert für das entsprechende Messziel, codiert als Bytestring

Beispiel:

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

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

Zusammenfassende Berichte

Aggregierbare Berichte werden für viele Browser und Geräte (Nutzer) so zusammengefasst:

• Ein AdTech-Anbieter fordert zusammenfassende Berichte für einen bestimmten Satz von Schlüsseln sowie einen bestimmten Satz zusammenfassender 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 zusammengefassten Berichten addiert.
• Rauschen wird zum Wert in der Zusammenfassung hinzugefügt.

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

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

• Bucket: der Aggregationsschlüssel, codiert als Bytestring.
• Wert: Der Dezimalwert für ein bestimmtes Messziel, summiert aus allen verfügbaren zusammenfassenden Berichten, mit zusätzlichem Rauschen

Beispiel:

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

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

Aggregationsschlüssel in der Praxis

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

Schlüsselstruktur

Wir verwenden den Begriff Schlüsselstruktur, um die Gruppe der in einen Schlüssel codierten Dimensionen anzugeben.

Beispiele: Kampagnen-ID x GeoID x Produktkategorie ist eine Schlüsselstruktur.

Schlüsseltypen

Aggregierbare Werte werden für einen bestimmten Schlüssel über mehrere Nutzer bzw. Browser hinweg summiert. Es hat sich jedoch gezeigt, dass mit aggregierbaren Werten unterschiedliche Messziele erfasst werden können, z. B. ein Kaufwert oder eine Anzahl von Käufen. Sie möchten sicherstellen, dass der Aggregationsdienst aggregierbare Werte desselben Typs summiert.

Codieren Sie dazu in jedem Schlüssel ein Datenelement, aus dem hervorgeht, wofür der zusammenfassende Wert steht – das Messziel, auf das sich dieser Schlüssel bezieht. Dazu können Sie z. B. eine zusätzliche Dimension für den Schlüssel erstellen, die dem Zielvorhabentyp „Messung“ entspricht.

Im Beispiel oben hätte dieser Zielvorhabentyp für die Messung zwei verschiedene mögliche Werte:

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

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

Sie können sich die Dimensionen eines Schlüssels als Messwerte vorstellen. z. B. 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 – der Anzahl der Nullen und Einsen im Binärformat, um den vollständigen Schlüssel zu erstellen. Die API lässt eine Schlüssellänge von 128 Bit zu.

Diese Größe ermöglicht sehr detaillierte Schlüssel. Detailliertere Schlüssel führen jedoch eher zu verrauschten Werten. Weitere Informationen zu Rauschen finden Sie im Hilfeartikel Rauschen verstehen.

Wie bereits erwähnt, werden Dimensionen im Aggregationsschlüssel codiert. Jede Dimension hat eine bestimmte Kardinalität, d. h. die Anzahl der einzelnen Werte, die die Dimension annehmen kann. Je nach Kardinalität muss jede Dimension durch eine bestimmte Anzahl von Bits dargestellt werden. Mit n Bits ist es möglich, 2n verschiedene Optionen auszudrücken.

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

7 Bit würden nur 27 =128 verschiedene Optionen speichern, was kleiner als die erforderlichen 200 ist.

8 Bit würden 28 =256 verschiedene Optionen speichern, was mehr als die erforderlichen 200 Bits ist, sodass Sie diese Dimension mit n=8 Bit codieren können.

Schlüsselcodierung

Wenn Sie Schlüssel im Browser festlegen, müssen diese als hexadezimal codiert werden. In Zusammenfassungsberichten werden Schlüssel im Binärformat (und in benannte Buckets) angezeigt.

Hinweis:Hexadezimaldaten wird in der Regel das Präfix „0x“ vorangestellt („x“ für hexadezimal). Beispiel: 0 x 19 ist hexadezimal 19, also 25 im Dezimalformat, nicht 19. Binärzahlen haben in der Regel das Präfix 0b ("b" für binär). Beispiel: 0b11001 ist 11001 im Binärformat, also 25 als Dezimalzahl und nicht 11.001.

Zwei Schlüsselelemente für eine vollständige Tonart festlegen

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

• Kampagnen-ID
• Geografie-ID
• Produktkategorie

Während die Dimensionen „Kampagnen-ID“ und „Geografische ID“ bei der Auslieferung der Anzeige bekannt sind (Zeit der Anzeigenbereitstellung), wird die Produktkategorie durch ein Triggerereignis ermittelt, wenn der Nutzer eine Conversion ausführt (Zeitpunkt der Conversion).

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

1. Bei Klick- oder Aufrufzeit legen Sie einen Teil des Schlüssels (Kampagnen-ID x Geografie-ID) fest.
2. Den zweiten Teil des Schlüssels (Produktkategorie) legen Sie zum Zeitpunkt der Conversion fest.

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

Zur Berechnung eines Schlüssels wird das XOR (^) seiner Schlüsselelemente verwendet.

Beispiel:

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

Schlüsselelemente ausrichten

Mit zwei 64-Bit-Schlüsselteilen, die mit sorgfältig platzierten 64-Bit-Füllern/Offsets (die sechzehn Nullen) auf 128 Bit erweitert wurden, entspricht das XOR-ing der Verkettung, was einfacher zu verstehen und zu überprüfen ist:

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

Mehrere Schlüssel pro Anzeigenklick oder Anzeigenaufruf

In der Praxis können Sie für jedes Ereignis in der Attributionsquelle (Anzeigenklick oder Anzeigenaufruf) mehrere Schlüssel festlegen. Sie können beispielsweise Folgendes festlegen:

• Schlüssel, der die Geografie-ID x Kampagnen-ID erfasst.
• Ein weiterer Schlüssel, mit dem Creative-Typ und Kampagnen-ID erfasst werden.

Strategie B ist ein weiteres Beispiel.

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 einen bestimmten Satz von Aggregationsschlüsseln an.

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

• Wenn Sie Schlüssel festlegen, wenn der Nutzer eine Anzeige ansieht oder anklickt und später eine Conversion durchführt, müssen Sie die Schlüssel zuverlässig anhand 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 sofort dieselben Schlüssel generieren oder aufrufen wie die Schlüssel, die festgelegt wurden, als der Nutzer eine Anzeige angesehen oder darauf geklickt und eine Conversion ausgeführt hat – basierend auf den Werten der Dimensionen, für die aggregierte Daten angezeigt werden sollen.

Dimensionen mit Schlüsselstrukturzuordnungen codieren

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

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

Das Erstellen und Verwalten von Schlüsselstrukturkarten bedeutet in der Praxis, dass Sie die Decoderlogik implementieren und verwalten müssen. Wenn Sie nach einer Methode suchen, bei der das nicht erforderlich ist, können Sie stattdessen einen Hash-basierten Ansatz nutzen.

Beispiel:

Angenommen, Sie möchten sowohl Käufe als auch Kaufwerte für bestimmte Kampagnen, 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 – Kaufanzahl und Kaufwert – erfassen möchten, müssen Sie dem Schlüssel eine Dimension hinzufügen, mit der der Schlüsseltyp erfasst wird. Auf diese Weise können Sie definieren, was der zusammengefasste Wert beim Empfang von {key, aggregatable value}-Paaren in Zusammenfassungsberichten tatsächlich darstellt.

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

• Produktkategorie
• Typ des Zielvorhabens der Messung
• Geografie-ID
• Kampagnen-ID

Gehen wir nun von den einzelnen Dimensionen aus. Gehen wir davon aus, dass Sie für Ihren Anwendungsfall Folgendes erfassen müssen:

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

Hier ist die Anzahl der Bits, die Sie zum Codieren der einzelnen Dimensionen in Ihrem Schlüssel benötigen:

• Produktkategorie: 5 Bit (2^5 = 32 > 29).
• Typ des Zielvorhabens der Messung: 1 Bit. Das Messziel ist entweder die Anzahl der Käufe oder der Kaufwert, es gibt also zwei unterschiedliche Möglichkeiten. Daher reicht ein Bit zum Speichern aus.

• Geografie-ID: 3 Bit (2^3 = 8). Definieren Sie außerdem eine Dimensionskarte für die Geografie-ID, um zu ermitteln, für welche geografische Region jeder Binärwert steht. Die Dimensionszuordnung für die Dimension „Geografie-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 (24 = 16)

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

In diesem Beispiel würde die Schlüsselstrukturzuordnung für diese Schlüssel so aussehen:

Sie können die Reihenfolge der Dimensionen im Schlüssel selbst festlegen.

Um zu veranschaulichen, wie Dimensionen eine Schlüsselstruktur bilden, 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 wichtigste Bit – das Bit mit dem höchsten 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üsselstrukturzuordnung verwenden würden, um einen Schlüssel zu decodieren.

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

Laut der Schlüsselstrukturzuordnung würde dieser Schlüssel wie folgt decodiert werden:

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 eingeführt wurde.

Dimensionen mit einer Hash-Funktion codieren

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

Das funktioniert so:

1. Wählen Sie einen Hash-Algorithmus aus.
2. Erstellen Sie bei der Anzeigenbereitstellung einen String, der alle Dimensionen, die Sie erfassen möchten, und deren Werte enthält. Hashen Sie diesen String, um den quellseitigen Schlüssel zu generieren, und fügen Sie gegebenenfalls ein 64-Bit-Suffix mit Nullen hinzu, um ihn an dem Trigger-seitigen Schlüsselteil auszurichten und XOR leichter zu begründen.
   • Quellseitiges Schlüsselelement
     = <64-Bit-Hexadezimalwert("COUNT, campaignID=12, geoID=7"))><64-Bit 00000000...>
   • COUNT codiert bei der Schlüsselstrukturzuordnung dasselbe Ergebnis wie „measureGoalType=0“. COUNT ist ein bisschen schlanker und deutlicher.
3. Erstellen 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 mit Nullen hinzu, um ein Trigger-seitiges Schlüsselelement zu generieren:
   • Trigger-seitiges Schlüsselelement = <64-Bit 00000000...><64-Bit-Hexadezimalwert("productCategory=25")>
4. Anhand einer XOR-Verknüpfung des Browsers wird ein Schlüssel generiert.
   • 128-Bit-Aggregationsschlüssel
     = <64-Bit-Hexadezimalwert für quellseitiges Schlüsselelement><64-Bit-Hexadezimalwert für quellseitiges Schlüsselelement>
5. Wenn Sie später einen zusammenfassenden Bericht für diesen Schlüssel anfordern möchten, können Sie ihn spontan generieren:
   • Generieren Sie basierend auf den Dimensionen, die Sie interessieren, wie zuvor einen quellen- und einen Auslöserseitigen Schlüsselelement.
     • Quellseitiges Schlüsselelement
       = <64-Bit-Hexadezimalwert("COUNT, campaignID=12, geoID=7"))><64-Bit 00000000...>
     • Triggerseitiges Schlüsselelement
       = <64-Bit 00000000...><64-Bit-Hexadezimalwert("productCategory=25")>
     • Trigger-seitiges Schlüsselelement = toHex(hash("productCategory=25"))
   • Genau wie der Browser können Sie mithilfe von XOR den Schlüssel generieren, den der Browser zuvor generiert hat.
     • 128-Bit-Aggregationsschlüssel
       = <64-Bit-Hash der Quellseite Hash><64-Bit-Hash des Quellseitigen Schlüsselelements>

Hier ein paar praktische Tipps, wenn Sie diesen Hash-basierten Ansatz verwenden:

• 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 denselben Hash wie "COUNT, GeoID=7, CampaignID=12"). Eine einfache Möglichkeit besteht darin, Dimensionen alphanumerisch zu sortieren. Dies ist die Vorgehensweise im Beispiel, es sei denn, wir stellen ANZAHL oder WERT immer als erstes Element in der Dimension ein. Aus Gründen der Lesbarkeit ist diese Option eine Wahl, da mit COUNT oder WERT Informationen codiert werden, die sich vom Konzept der anderen Dimensionen leicht unterscheiden.
• Behalten Sie den Satz von Dimensionen im Auge, die Sie in Schlüsseln verwenden. Sie möchten vermeiden, 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. Durch die Prüfung auf zuvor verwendete Hashes, die gespeichert werden sollten, um die Ergebnisse des Aggregationsdienstes zu interpretieren, können neue Schlüssel vermieden werden, die zu Konflikten mit älteren Schlüsseln führen.

Wie Sie hashbasierte Schlüssel in der Praxis verwenden, wird im Beispiel zu einer Conversion pro Klick oder Aufruf beschrieben.

Aggregierbare Werte in der Praxis

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

Aus Datenschutzgründen haben 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 einen bestimmten Beitragsgrenzwert überschreiten.

Dieses Limit bezeichnen wir als CONTRIBUTION_BUDGET. In der Erläuterung wird dieses Limit als L1-Budget bezeichnet, entspricht aber dem CONTRIBUTION_BUDGET.

Eine ausführliche Erläuterung des Beitragsbudgets findest du unter Beitragsbudget für Zusammenfassungsberichte.

Beispiel: eine Conversion pro Klick oder Aufruf

In diesem Beispiel gehen wir davon aus, 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 Statistiken benötigen.

Außerdem müssen Sie Folgendes erfassen:

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

Geeignete Messwerte

Viele Unternehmen im Bereich Anzeigentechnologie empfehlen Werbetreibenden, verschiedene Conversion-Typen zu konfigurieren. Sich auf die wichtigsten Conversions wie Käufe zu konzentrieren, ist eine gute Möglichkeit, dafür zu sorgen, dass aggregierte Ergebnisse für diese wichtigen Conversion-Ereignisse detailliert und genau sind. Je mehr Messwerte Sie erfassen, desto kleiner ist Ihr Beitragsbudget pro Messwert und desto ungenauer ist die Wahrscheinlichkeit, dass die einzelnen Werte ungenau sind. Daher müssen Sie genau auswählen, was gemessen werden soll.

In diesem Beispiel konzentrieren wir uns auf Kampagneneinrichtungen, 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 können auf verschiedene wichtige zusammengefasste Statistiken wie den Gesamtkaufwert und geografische Aufschlüsselungen zugreifen. Dadurch bleibt Störfaktoren realistisch und es wird ein einfacher Skalierungsansatz für Ihr Beitragsbudget gewährleistet.

Was ist mit Währungen?

Wenn Kampagnen in unterschiedlichen Regionen geschaltet werden, sollten Währungen berücksichtigt werden. Sie haben folgende Möglichkeiten:

• Legen Sie die Währung in den Aggregationsschlüsseln als spezielle Dimension fest.
• Alternativ können Sie die Währung von einer Kampagnen-ID ableiten und alle Währungen in eine Referenzwährung umrechnen.

In diesem Beispiel wird davon ausgegangen, dass Sie die Währung von einer Kampagnen-ID ableiten können. So können Sie jeden 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 Gesamtwert für Käufe zu generieren – einen zusammenfassenden Kaufwert.

Zielvorhaben in Schlüssel umwandeln

Bei Ihren Analysezielen und Messwerten haben Sie mehrere Optionen für Ihre Schlüsselstrategie. Sehen wir uns zwei dieser Strategien genauer an:

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

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

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

Alle Ihre Schlüssel verwenden diese Struktur.

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

• Schlüsseltyp 0: Typ des Messziels = 0. Dieser Wert legen Sie als Kaufzahl fest.
• Schlüsseltyp 1: Typ des Messziels = 1. Dieser Wert legen Sie als Kaufwert fest.

Zusammenfassende Berichte sehen so aus:

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

• Jeder Zusammenfassungswert in Zusammenfassungsberichten ist allen Dimensionen zugeordnet, die Sie erfassen.
• Sie können diese Zusammenfassungswerte neben jeder dieser Dimensionen zusammenfassen, sodass diese Rollups so tief gehen können wie die Anzahl der vorhandenen Dimensionen.

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

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

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

„Wie viel Umsatz haben meine Kampagnen in den einzelnen geografischen Regionen mit den einzelnen Produkten generiert?“

Auch wenn die Zusammenfassungswerte ungenau sind, können Sie auch ermitteln, ob die Unterschiede bei den zwischen den einzelnen Kampagnen gemessenen Werten nicht ausschließlich auf Rauschen zurückzuführen sind. Weitere Informationen dazu finden Sie unter Rauschen verstehen.

Strategie B: zwei flache Bäume (zwei grobe Strukturen)

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.

• Typ des Messziels = 0; definiert als Anzahl der Käufe.
• Typ des Messziels = 1; definiert als Kaufwert.

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

Zusammenfassende Berichte sehen so aus:

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

• Die Zusammenfassungswerte in Zusammenfassungsberichten werden einer von zwei kleinen Gruppen von Dimensionen zugeordnet.
• Sie können diese zusammenfassenden Werte zusammen mit den einzelnen Dimensionen in diesen Sets zusammenfassen. Das bedeutet, dass diese Rollups nicht so tief sind wie in Option A, da weniger Dimensionen für einen Rollup verfügbar sind.

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

Frage	Antworten
Welche Produktkategorien sind in den einzelnen Regionen am wertvollsten?	Sie können direkt auf die zusammenfassende Anzahl der Käufe und Werte in den Zusammenfassungsberichten zugreifen.
Welche Kampagnenstrategien sind in den einzelnen Regionen am effektivsten?	Sie können direkt auf die zusammenfassende Anzahl der Käufe und Werte in den Zusammenfassungsberichten zugreifen.

Entscheidung: Strategie A

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

Bei Strategie A müssen Sie jedoch die zusammengefassten Werte, die Sie in Zusammenfassungsberichten erhalten, summieren, um einige Ihrer Fragen zu beantworten. Jeder dieser zusammenfassenden Werte ist ungenau. Durch die Addition dieser Daten wird auch das Rauschen summiert.

Dies ist bei Strategie B nicht der Fall, bei der die in den zusammenfassenden Berichten enthaltenen Zusammenfassungswerte bereits die benötigten Informationen liefern. Das bedeutet, dass Strategie B wahrscheinlich weniger Auswirkungen durch Rauschen hat als Strategie A.

Wie sollten Sie entscheiden, welche Strategie Sie verwenden sollten? Bei bestehenden Werbetreibenden oder Kampagnen können Sie anhand der Verlaufsdaten feststellen, 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:

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

Hinweis:Verlassen Sie sich in Ihren Designs nicht auf die Anzahl der Berichte oder die Daten, die nur über Debug-Berichte verfügbar sind. In Zukunft werden sich die in Debug-Berichten verfügbaren Daten ändern und neben echten Berichten werden auch verrauschte Berichte generiert. Diese Signale sollten Sie also nur verwenden, um Ihre Implementierungs- und Teststrategie zu validieren.

Nehmen wir in diesem Beispiel an, dass die wöchentliche Anzahl der Käufe und der Kaufwert hoch genug sind, sodass Strategie A zu einem Rauschprozentsatz führt, den Sie für Ihren Anwendungsfall für akzeptabel halten.

Da Strategie A einfacher ist und zu einer verwirrenden Auswirkung führt, die Ihre Entscheidungsfähigkeit nicht beeinträchtigt, 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 Anzeigen anklicken oder ansehen und anschließend eine Conversion ausführen.

Als Nächstes erhalten Sie einen Überblick über die Header, die Sie festlegen, um Schlüssel und Werte im Browser zu registrieren:

Wichtige Elemente auf der Quelle 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üsselelements festlegen, der zum Zeitpunkt der Anzeigenbereitstellung bekannt ist.

Lassen Sie uns die Schlüsselelemente generieren:

Quellseitiges Schlüsselelement für die Schlüssel-ID...	String mit den Dimensionswerten, die Sie festlegen möchten	Hash dieses Strings als Hexadezimalwert, gekürzt auf die ersten 64 Bit (64/4 = 16 Zeichen^1)	Der Hex-Hash mit angehängten Nullen zur Vereinfachung des XOR-Vorgangs. Dies ist das quellseitige Schlüsselelement.
key_purchaseCount	COUNT, CampaignID=12, GeoID=7	0x3cf867903fbb73ec.	0x3cf867903fbb73ec0000000000000000
key_purchaseValue	Wert, Kampagnen-ID=12, GeoID=7	0x245265f432f16e73	0x245265f432f16e730000000000000000

¹ Jede hexadezimale Ziffer stellt vier Bits (Binärziffern) dar.

Legen wir nun die wichtigsten Punkte 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 sind in den endgültigen Berichten nicht enthalten. Sie werden nur verwendet, wenn Schlüssel im Browser festgelegt werden, damit Schlüsselelemente auf der Quell- und Triggerseite einander zugeordnet und zu einem vollständigen Schlüssel kombiniert werden können.

Optional: Berichte auf Ereignisebene

Wenn Sie Berichte auf Ereignisebene zusammen mit aggregierten Berichten verwenden müssen, müssen die Daten auf Ereignisebene (Quellereignis-ID und Triggerdaten) für eine bestimmte Quelle mit dem Aggregationsschlüssel übereinstimmen.

Sie können beide Berichte verwenden, wenn Sie z. B. 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 aus.

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 (Triggerseite) 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 aggregierbaren Wert für diese Conversion über den Header Attribution-Reporting-Register-Aggregatable-Values fest.

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

Lassen Sie uns die Schlüsselelemente generieren:

Triggerseitiges Schlüsselelement für die Schlüssel-ID...	String mit den Dimensionswerten, die Sie festlegen möchten	Hash dieses Strings als Hexadezimalwert, gekürzt auf die ersten 64 Bit (64/4 = 16 Zeichen^1)	Hex-Hash mit angehängten Nullen zur simplify des XOR-Vorgangs. Dies ist das quellseitige Schlüsselelement.
key_purchaseCount	Produktkategorie=25	0x1c7ce88c4904bbe2	0x0000000000000000f9e491fe37e55a0c
key_purchaseValue	(gleich)	(gleich)	(gleich)

¹ Jede hexadezimale Ziffer stellt vier Bits (Binärziffern) dar.

Legen wir nun die wichtigsten Punkte 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 können dasselbe Schlüsselelement mehreren Schlüsseln hinzufügen, indem Sie mehrere Schlüssel-IDs in source_keys auflisten. Das Schlüsselelement 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, der Produkttyp 25 wurde für 52 € gekauft.

Sie legen diese Werte nicht direkt als aggregierbare Werte fest:

• key_purchaseCount: 1 Conversion
• key_purchaseValue: 52 $

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

Sie haben zwei Zielvorhaben, für die Sie Ihr Beitragsbudget ausgeben möchten, und können das Beitragsbudget in zwei Ziele aufteilen.

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

Angenommen, der maximale Kaufwert für einen einzelnen Nutzer, basierend auf den bisherigen Käufen aller Nutzer der Website,beträgt 1.500 €. Es kann Ausreißer geben, z. B. sehr wenige Nutzer, die mehr ausgegeben haben, aber Sie können diese Ausreißer ignorieren.

Ihr 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 pro Anzeigenklick oder -aufruf (Quellereignis) maximal einen Kauf 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 so mit dem dedizierten Header Attribution-Reporting-Register-Aggregatable-Values 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 zusammengefasste Bericht wird

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

Im Folgenden finden Sie ein Beispiel für Daten, die in der Nutzlast des aggregierbaren Berichts zu finden sind, sofern sie im Klartext gelesen werden können:

[ {
  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 einzelnen aggregierbaren Bericht.

Zusammenfassenden Bericht anfordern

• Batch-Aggregierbare Berichte. Folgen Sie den Empfehlungen unter Batch-Verarbeitung.
• Generieren Sie die Schlüssel, für die Sie Daten sehen möchten. Um z. B. Zusammenfassungsdaten für COUNT (Gesamtzahl der Käufe) undVALUE (Gesamtkaufwert) für die Kampagnen-ID 12 × Geografie-ID 7 × Produktkategorie 25 zu sehen, gehen Sie so vor:
  • Generieren Sie das quellseitige Schlüsselelement, wie Sie es bei der Einstellung im Browser getan haben.
  • Generieren Sie das Schlüsselelement auf Triggerseite, wie bei der Einstellung im Browser.

Gewünschter Messwert^1	Quellenseitiges Schlüsselelement	Schlüsselelement auf der Triggerseite	Schlüssel für Anfrage an den Aggregationsdienst^2
Anzahl der Käufe insgesamt (COUNT)	0x3cf867903fbb73ec 0000000000000000	0x00000000000000 00f9e491fe37e55a0c	0x3cf867903fbb73 ecf9e491fe37e55a0c
Gesamtkaufwert (VALUE)	0x245265f432f16e73 0000000000000000	0x0000000000000000 f9e491fe37e55a0c	0x245265f432f16e73 f9e491fe37e55a0c

¹ Messwert, den Sie anfordern möchten (für Kampagnen-ID 12 × Geografie-ID 7 × Produktkategorie 25). ²Schlüssel für die Anfrage an den Aggregationsdienst = quellseitiges XODER Trigger-seitiges Schlüsselelement.

• Fordern Sie Zusammenfassungsdaten beim Aggregationsdienst für diese Schlüssel an.

Zusammenfassungsbericht

Am Ende 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ärformat. Der zweite Bucket ist der Schlüssel WERT im Binärformat. Hinweis: Die Schlüssel sind zwar heterogen (COUNT vs.VALUE), befinden sich aber im selben Bericht.

Hinweis: In der Praxis sind Zusammenfassungsberichte so codiert, dass Buckets und Werte anders aussehen, als Sie gerade gesehen haben. Ein Bucket kann also wie folgt aussehen: „\u0000\u0000\x80\u0000“. Bucket und value sind Bytestrings. Ein Beispiel findest du hier.

Werte verkleinern

• 2.558.500 bezieht sich auf die Anzahl der Käufe für diesen Schlüssel, hochgerechnet auf den zuvor berechneten Skalierungsfaktor. Der Skalierungsfaktor für die Kaufzahl 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.

Die zusammenfassenden Berichte enthalten somit folgende Informationen:

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

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