• Einführung in das Awin-Tracking
• Awin-Tracking mit serverside Google Tag Manager: Vogelperspektive
• Awin-Tracking mit serverside Google Tag Manager: Anleitung

Einführung in das Awin-Tracking

Als Affiliate-Marketing-Netzwerk ermöglicht Awin eine Zusammenarbeit zwischen Publishern und Advertisern. Advertiser stellen Werbemittel – mit denen sie ihre Produkte bewerben möchten – zur Verfügung. Publisher platzieren diese Werbemittel auf ihre Website. Nutzer, die auf den Werbemittel klicken (auf der Website des Publishers) werden auf die Website des Advertisers weitergeleitet, wo sie einen Kauf oder eine Bestellung durchführen können.

Damit der Advertiser weiß, von welchen Publishern welche und wie viele Abschlüsse generiert worden sind, muss ein Tracking stattfinden. Das clientside Awin-Tracking funktioniert dabei grob wie folgt:

1. Der Link auf der Publisher-Website zur Advertiser-Website enthält den awc-Parameter in der URL. Der “awc” ist der Awin Click Identifier.
2. Klickt der Nutzer drauf, dann landet er auf der Advertiser-Website inkl. awc-Parameter in der URL.
3. Auf der Advertiser-Website lädt zunächst das Awin MasterTag, welches alle Grundfunktionalitäten für das Tracking bereithält. Unter anderem wird der Wert aus dem awc-Parameter in einem First-Party-Cookie abgelegt.
4. Wenn der Nutzer einen Abschluss durchführt, dann feuert das Awin Conversion Tag und informiert das Netzwerk, dass ein Abschluss über den entsprechenden awc-Wert durchgeführt wurde. Der Advertiser weiß dadurch, welchen Publisher er vergüten muss.
5. Alternativ kann zusätzlich zum Conversion Tag auch ein Fallback Conversion Pixel feuern.

Dieses Tracking kann nun über ein serverside Tracking bzw. serverside GTM-Tagging ergänzt werden. Wie das funktioniert, zeige ich nachfolgend.

Awin-Tracking mit serverside Google Tag Manager: Vogelperspektive

Bevor ich zur praktischen Anleitung komme, schauen wir uns das Setup mit dem serverseitigen GTM-Container von der Vogelperspektive an. Das clientseitige Awin-Tracking wird grundsätzlich um das serverside Tagging erweitert und besteht dann aus 4 Komponenten:

• Awin MasterTag
• Conversion Tag
• Fallback Conversion Pixel
• Server-to-Server Tracking

Letzteres ersetzt also NICHT unbedingt euer bestehendes Awin-Tracking, sondern erweitert es. Das Setup des Server-to-Server Trackings mit dem Google Tag Managers sieht dann wie folgt aus:

Zur Erklärung:

1. Klickt der Nutzer auf ein Werbemittel auf der Website des Publishers, dann landet er auf der Advertiser-Website inkl. awc-Parameter in der URL.
2. Auf der Seite des Advertisers feuert ein GA4-Konfigurationstag, sobald “awc=” in der URL vorhanden ist. Der Hit wird über das transport_url-Feld an den eigenen Server-Endpoint geschickt.
3. Im Server-Container nimmt ein GA4-Client den Request entgegen und wandelt ihn in das Event Data Model um.
4. Dann feuert im Server-Container ein Tag, welches einen HTTP-Cookie mit dem awc-Wert setzt.
5. Sobald der Nutzer dann einen Abschluss tätigt, feuert im Web-Container ein GA4-Ereignis und schickt den Hit wieder an den eigenen Endpoint.
6. Im Server-Container nimmt wieder ein GA4-Client den Request entgegen und ein Awin Tag feuert, welches den Request an den Awin-Server schickt.

Endresultat ist ein Request vom GTM-Server an den Awin-Server, der wie folgt aussieht:

https://www.awin1.com/sread.php?tt=ss&tv=2&merchant=XXXX&amount={{totalAmount}}&ch={{channel}}&parts={{commission_group}}:{{totalAmount}}&vc={{voucher_code}}&cr={{currency_code}}&ref={{order_ref}}&testmode=0&cks={{awc}}

Der Awin-Endpoint ist also https://www.awin1.com/sread.php. Die Parameter verraten folgendes:

• tt=ss ist der Hinweis für Awin, dass es sich um einen Server-to-Server-Request handelt
• merchant=XXXX ist die Awin-Advertiser-ID (kommt statt “XXXX”)
• Unter amount={{totalAmount}} wird der Gesamtbetrag der Transaktion mitgegeben
• Als ch={{channel}} sollte immer der letzte Kanal mitgeschickt werden. “aw” sollte für Awin genutzt werden bzw. auch als Fallback
• parts={{commission_group}}:{{totalAmount}} gibt den Code für die Provisionsgruppe inkl. Gesamtbetrag weiter
• vc={{voucher_code}} gibt den verwendeten Gutscheincode weiter
• Als cr={{currency_code}} wird die Währung mitgeschickt
• ref={{order_ref}} ist die Auftragsnummer
• testmode=0 steht für das Live-Tracking, für Test-Hits wird die 1 mitgegeben
• Über cks={{awc}} wird die Awin-Klick-Id mitgeschickt

Awin-Tracking mit serverside Google Tag Manager: Anleitung

Sehen wir uns nun die Umsetzung im Detail an. Ich gehe davon aus, dass du schon ein GTM-Server-Setup hast. Außerdem gehe ich davon aus, dass bei dir – wie bei den meisten – das GA4-Tracking serverseitig läuft. Wenn nicht, dann verlinke ich nachfolgend Anleitungen auf meinem Blog, die gleichzeitig auch die Anforderungen für das serverside Awin-Tracking mit dem Google Tag Manager abdecken. Du brauchst also:

• Einen Google Tag Manager Server-Container
• Eine eigene Domain als Server-Endpoint
• Ein serverseitiges Google Analytics 4-Tracking (bzw. zumindest einen GA4-Client)
• Im besten Fall lieferst du außerdem die Google Tag Manager-Bibliothek auch schon über deinen eigenen Server-Endpoint aus

Sind diese Grundvoraussetzung erfüllt kann es losgehen. Insgesamt brauchen wir:

• Google Analytics 4-Konfigurationstag (Web-Container)
• Tag für HTTP-Cookie (Server-Container)
• Google Analytics 4-Event-Tag (Web-Container)
• Awin-Tag (Server-Container)

Google Analytics 4-Konfigurationstag (Web-Container)

Wie oben geschrieben, gehe ich davon aus, dass du GA4 schon serverseitig einsetzt. Über diesen Datenstream soll auch das Awin-Tag serverseitig feuern. Heißt also, dass clientseitig ein GA4-Tag feuert, vom GA4-Client im Server-Container entgegen genommen wird und auf Basis des Clients feuern dann die Tags. Hier visuell dargestellt:

Was man jedoch hier berücksichtigen muss: Consent. Also welchen Trigger wählt man im Web-Container für das GA4-Tag? Der Nutzer hat ja im Cookie-Banner die Möglichkeit alle Cookies zuzulassen, alle abzulehnen oder aber auch Einzel-Auswahlen zu treffen (z.B. kann nur GA4 eine Zustimmung erhalten, was bedeutet, dass die anderen Tags im Server-Container nicht feuern dürfen). In diesem ersten Schritt gibt es nun 2 Möglichkeiten.

Möglichkeit 1: Ein GA4-Tag für alle Marketing-Tags
Mit dieser Variante genießt man den Vorteil des geringeren Client-Loads (also im Browser der Nutzer werden weniger Skripte ausgeführt, was zu besseren Pagespeed führen kann). Es spiegelt die Grafik von oben wider:

Grundprinzip:

• Stimmt der Nutzer allen Cookies zu, dann feuert das GA4-Tag
• Lehnt der Nutzer alle Cookies ab, dass feuert das GA4-Tag nicht
• Lehnt der Nutzer z.B. 2 von 3 Marketing-Tools ab, dann feuert das GA4-Tag dennoch, ABER die abgelehnten Tools feuern nicht im Server-Container und somit gehen auch keine Daten raus

Damit das funktioniert, müsste man also die Consent-Stati des Nutzers im Tag selbst mitgeben – z.B. als benutzerdefinierter Parameter:

?ga4=true&facebook=false&awin=true

Anhand dieser Information kann man dann die Tags im Server-Container steuern. Die technische Implementierung hängt von der eingesetzten Consent Management Plattform und weiteren technischen Parametern ab. Eine Anleitung würde hier den Rahmen sprengen, weshalb ich zur Möglichkeit 2 komme.

Möglichkeit 2: Eigenes GA4-Tag für Awin
Zwar nicht die beste Möglichkeit, aber diejenige die aktuell am einfachsten umzusetzen ist: Für das Awin-Tracking wird ein eigenes GA4-Konfigurationstag erstellt und gefeuert (siehe aber dazu wichtigen Hinweis unter der Grafik unten). Dieses löst nur aus, wenn der Nutzer seinen Consent für Awin gegeben hat. Im Hit wird noch zusätzlich ein eigener Event-Parameter geschickt, damit man weiß, dass dieser Hit vom “GA4-Awin-Tag” kommt. Dieser Parameter kann dann für 2 Zwecke benutzt werden:

• Das HTTP-Cookie-Tag und Awin-Tag im Server-Container (komme ich später dazu) feuern nur, wenn dieser Parameter vorhanden ist.
• Alle anderen Tags im Server-Container (z.B. GA4-Tracking und Facebook CAPI) bekommen diesen Parameter als Ausnahme-Trigger, damit diese nicht doppelte Hits erfassen.

Visuell sieht das folgedermaßen aus:

Mit Möglichkeit 2 bekommt also jedes Marketing-Tool im Web-Container seinen eigenen GA4-Tag. Wie gesagt: Ist zwar nicht optimal, aber aktuell mit dem GTM-Server am einfachsten umzusetzen. Empfehlen würde ich dir diese Methode nur, wenn du “nur” eine Handvoll Tracking-Tools im Einsatz hast. Bei einem umfangreichen Serverside Tagging-Setup wird die Trigger-Logik im Server-Container unnötig aufgebläht. Da würde ich dir zu Möglichkeit 1 raten.

Legen wir aber endlich los! Zunächst müssen wir uns nochmal erinnern: Von oben wissen wir, dass der Nutzer zunächst über einen awc-Parameter von der Publisher-Website kommt. Der awc-Wert muss nun abgegriffen und in einem HTTP-Cookie geschrieben werden. Damit wir das erreichen wird zuerst ein GA4-Tag im Web-Container ausgelöst. Dieser sendet den Hit an den GTM-Server, dort reagiert dann ein Tag, welches den Cookie-Wert im Antwort-Header mitgibt (nächster Schritt).

Fangen mit dem GA4-Tag an. Erstelle in deinem Google Tag Manager Web-Container als erstes ein GA4-Konfigurationstag (unter “Tags” und dann auf “Neu” klicken):

Nun gibst du deine GA4-Mess-ID (oder eine Dummy-ID, siehe Hinweis von oben) an und setzt das blaue Häkchen bei “Beim Laden dieser Konfiguration ein Ereignis vom Typ “Seitenaufrufe” senden”. Unter “Festzulegende Felder” gibst du 2 Parameter mit:

• Über das transport_url-Feld gibst du deinen eigenen GTM-Server-Endpoint an.
• “custom_pixel_id” ist jetzt ein von mir gewählter Name, kann aber auch anders heißen (sollte nur nicht mit den Standard-Event-Parameter von GA4 kollidieren). Als Wert gebe ich “aw” (steht für mich für “Awin”) mit, damit ich darauf im Server-Container später reagieren kann.

Als Trigger für dieses Tag wählst du den entsprechenden Awin-Consent und wenn die URL den Parameter “awc=” enthält. Am Beispiel von Usercentrics brauchst du zunächst die dataLayer-Variable:

Und dann 2 Trigger. Einmal beim initialen Consent – also Opt-In auf der Einstiegsseite:

Und dann einen zweiten Trigger, der auf das Event “consents_initialized” reagiert, welches Usercentrics auf allen darauffolgenden Seiten nach dem Consent schickt:

Somit ist dieser Schritt abgeschlossen und wir können zum Nächsten kommen. Sobald also ein Nutzer auf der Seite mit awc-Parameter landet, wird hier ein Hit an unseren Server-Endpoint geschickt.

Tag für HTTP-Cookie (Servercontainer)

Diesen Hit nimmt nun ein GA4-Client entgegen, den du im Zuge des serverseitigen GA4-Trackings implementiert hast:

Der Client wandelt den Hit in das Event-Datenmodell um. Uns interessiert dort vor allem der Parameter “dl” bzw. “page_location”. Dort wird die URL inkl. awc-Parameter geschrieben. Diesen Parameter müssen wir abgreifen und im HTTP-Response als HTTP-Cookie schreiben. Wie kommen wir an den Wert des awc-Parameters? Hierzu kann man die Variable “URL Parser” (von Simo Ahava) aus der Galerie für Community-Vorlagen importieren. Füge also im Server-Container eine neue Variable hinzu, indem du zunächst auf “In Galerie suchen” klickst:

Wähle dann den “URL Parser”:

Klicke dann auf “Zum Arbeitsbereich hinzufügen”:

Danach wird nochmal gefragt, ob man die Vorlage tatsächlich in den Container importieren möchte. Du kannst dir hier durchlesen, welche Berechtigungen du dadurch erteilst. Klicke auf “Hinzufügen”:

Die Vorlage ist nun bei dir auch unter “Vorlagen” abgelegt. Wir müssen aber nun die Variable erstellen. Gehe dazu unter “Variablen” auf “Neu”:

Klicke in dieses Feld:

Wähle nun die soeben importierte Variablen-Vorlage:

Danach können die Einstellungen konfiguriert werden. Insgesamt müssen 3 Parameter konfiguriert werden:

• Als “URL Source” wählen wir “page_location”, da wir auf dieses Feld zugreifen möchten.
• Unter “Component Type” wählen wir “Query”.
• Und der Schlüssel lautet “awc”

Das Ganze sieht dann wie folgt aus:

Damit ziehen wir uns den awc-Wert aus dem entsprechenden Feld und speichern es in einer wiederverwendbaren Variable. Benenne die Variable nun (z.B. awc-parameter) und speichere. Dies ist aber nur die halbe Miete. Der awc-Wert muss auch in einem HTTP-Cookie als Rückantwort gespeichert werden. Heißt (hier der betreffende Teil rot umrandet):

1. Der Hit geht vom Browser an den Server inkl. awc-Wert
2. Der Server antwortet und schreibt den Wert in ein HTTP-Cookie

Ab da an wird bei jeder Kommunikation zwischen Browser und Server der Awin-Cookie mitgeschickt. Das macht man am besten über ein Tag im Server-Container, welcher auslöst, wenn der Pageview-Hit ein “awc” als URL-Parameter enthält. Statt ein eigenes Tag zu schreiben, welches den Cookie über die setCookie-API setzt, können wir es einfacher lösen. Und zwar mit dem Custom Tag Template “Cookie Monster” aus der Galerie von (wieder) Simo Ahava.

Unter “Vorlagen” klicken wir auf “In Galerie suchen” im Bereich der Tag-Vorlagen:

Wählen dann die “Cookie Monster”-Vorlage aus:

Im Anschluss klicken wir – wie bei der Variablen-Vorlage – auf “Zum Arbeitsbereich hinzufügen” und dann auf “Hinzufügen”. Ist das getan, sollte “Cookie Monster” unter den Tag-Vorlagen erscheinen. Nun gehen wir zu Tags und legen ein neues Tag an:

Klicke in das Feld der Tag-Konfiguration:

Und nun wähle “Cookie Monster” aus:

Mit Klick auf “Add Cookie” kannst du ein Cookie mit den notwendigen Werten anlegen. Bevor wir das tun, ist wichtig zu wissen:

• Der Name des Cookies sollte “adv_awc” sein
• Wert ist gleich der awc-Wert
• Ablaufdatum sollte auf 30 Tage gesetzt werden
• Auf “HttpOnly” setzen

Nun kannst du auf “Add Cookie” klicken:

Und setze folgende Einstellungen. Unter “Value” kommt die vorhin erstellte Variable, die sich den awc-Wert zieht:

Vergebe einen sinnvollen Namen für das Tag und speichere es vorerst ohne Trigger (wir kommen gleich wieder dazu) ab. Neben dem adv_awc-Cookie braucht es ein weiteres Cookie für den Channel. Das ist folgender Teil (hier in Farbe) aus dem Hit:

https://www.awin1.com/sread.php?tt=ss&tv=2&merchant=XXXX&amount={{order_subtotal}}&ch={{channel}}&parts={{commission_group}}:{{sale_amount}}&vc={{voucher_code}}&cr={{currency_code}}&ref={{order_ref}}&testmode=0&cks={{awc}}

Als Channel sollte immer der letzte Channel – über dem der Nutzer kam – mitgegeben werden, damit Conversions dedupliziert werden können. Vor allem wenn man mit mehreren Netzwerken und/oder Paid-Kanälen arbeitet, vermeidet man dadurch, dass man Provisionen mehrmals auszahlt. Für Awin sollte dabei “aw” benutzt werden. Auch als Fallback – also wenn sonst keine Channel-Info vorliegt – sollte “aw” gesetzt werden. Wenn man hier sauber und konsistent UTM-Parameter gepflegt hat, dann kann der Channel über das “page_location”-Feld und dem UTM-Parameter “utm_source” gezogen werden. Dazu erstellen wir also wieder eine URL-Parser-Variable und geben folgendes ein:

Die Formatwert-Einstellungen stellen sicher, dass bei fehlendem UTM-Parameter der Wert “aw” als Fallback zurückgegeben wird. Gebe der Variable einen sinnvollen Namen und speichere ab. Gehe nun wieder zu den Tags und öffne wieder das Cookie-Monster-Tag. Hier solltest du das vorhin erstellte Cookie sehen. Klicke wieder auf “Add Cookie”, um den Cookie für den Channel zu setzen:

Gebe dann folgendes ein:

Der Name sollte “source” sein und als Cookie-Wert (Feld “Value”) gibst du die soeben erstellte Variable ein. Nun musst du 2 Einträge haben:

Nun kommen wir zu dem Trigger für das Cookie-Tag. Hier kommt der benutzerdefinierte Parameter “custom_pixel_id” zum Einsatz. Diesen Parameter geben wir mit dem GA4-Tag aus dem Webcontainer mit, um den Awin-Hit zu identifizieren. Damit wir mit “custom_pixel_id” arbeiten können, müssen wir die entsprechende Variable im Server-Container erstellen:

Danach können wir unseren Trigger erstellen:

Heißt also:

• Das Cookie wird nur geschrieben, wenn ein Pageview-Hit mit “aw” (steht für Awin) im Parameter “custom_pixel_id” reinkommt.
• Dieser Pageview-Hit kommt aber nur rein, wenn im Web-Container die aufgerufene URL den Parameter “awc” enthält.

Speichere den Tag, damit wir den Cookie-Teil abschließen. Für den nächsten Schritt wechseln wir wieder in den Webcontainer.

Google Analytics 4-Event-Tag (Webcontainer)

In diesem Schritt erstellen wir ein GA4-Event-Tag, um die Conversion an den Google Tag Manager Server zu übermitteln. Von dort aus soll dann die Conversion an den Awin-Server geschickt werden.

Im Web-Container erstellen wir also ein Tag vom Typ “GA4-Ereignis”. Als Konfigurations-Tag wählen wir das aus Schritt 1 erstellte Tag. Ereignisname sollte passend zur ausgeführten Aktion sein. Zudem geben wir weitere notwendige Parameter für Awin weiter:

Die Werte der einzelnen Parametern sind hier in meinem Beispiel statisch angegeben, im besten Fall befüllen sich diese dynamisch. Dazu sollten die Werte im dataLayer zum Zeitpunkt der Conversion vorliegen, die du dann abgreifen kannst. “custom_pixel_id” ist hier eine optionale Angabe, da dieser Parameter schon über den Konfigurations-Tag mitgegeben wird. Die Event-Parameter spiegeln die notwendigen Daten aus dem Awin-Hit wider:

• totalAmount für amount={{totalAmount}}
• commissionGroupCode für parts={{commission_group}}:{{totalAmount}}
• orderRef für ref={{order_ref}}
• voucherCode für vc={{voucher_code}}

Nun musst du nur noch den passenden Trigger für deine Conversion definieren. Speichere das Tag. Mit diesem Tag werden nun alle notwendigen Daten für Awin an den GTM-Server geschickt.

Awin-Tag (Servercontainer)

Einige dieser Daten müssen wir nun abfangen – vor allem die benutzerdefinierten Event-Parameter aus dem GA4-Event-Tag. Im Server-Container müssen wir dazu zunächst ein paar Variablen erstellen. Gehe also im Server-Container zu “Variablen” und klicke dann auf “Neu”:

Füge dann die erste Variable vom Typ “Ereignisdaten” mit folgendem Wert hinzu:

Das gleiche muss für die anderen Parameter wiederholt werden. Einmal für commissionGroupCode:

Dann für orderRef:

Und um Schluss noch für voucherCode:

Benenne die Variablen jedes Mal sinnvoll und speichere ab. Bevor wir das Tag erstellen, welches den ausgehenden Awin-Request macht, bereiten wir den Trigger vor. Vorhin haben wir ein GA4-Event-Tag mit dem Namen “purchase” erstellt. Darauf kann der Tag ausgerichtet werden. Gehe im Server-Container zu “Trigger” und erstelle einen Trigger vom Typ “Benutzerdefiniert”, der wie folgt aussieht:

Nun kommen wir zum Tag. Gehe im Server-Container zu “Vorlagen” und klicke auf “Neu” bei Tag-Vorlagen:

Klicke oben rechts auf das Menü und dann auf “Importieren”:

Was musst du nun importieren? Gehe dazu auf meine GitHub-Seite, wo du die notwendige Tag-Vorlage herunterladen kannst (danke an das Awin-Entwickler-Team für die Bereitstellung!). Klicke auf “Raw”:

Es öffnet sich eine Seite mit dem Template-Code. Klicke auf eine beliebige Stelle mit der rechten Maustaste und wähle dann “Speichern unter”. Speichere die Datei als tpl-Datei ab (ganz wichtig). Dann kannst du zurück zum GTM-Server-Container gehen und die tpl-Datei nun auswählen (nachdem du auf “Importieren” geklickt hast). War alles erfolgreich musst du folgendes sehen:

Klicke oben rechts auf “Speichern”. Das soeben importierte Tag-Template sorgt dafür, dass der entsprechende Server-to-Server-Request an Awin geht. Dabei werden die entsprechenden APIs zunächst geladen:

const sendHttpGet = require('sendHttpGet');
const setResponseBody = require('setResponseBody');
const setResponseHeader = require('setResponseHeader');
const setResponseStatus = require('setResponseStatus');
const getCookieValues = require('getCookieValues');
const makeString = require('makeString');

Danach werden Cookie-Werte gezogen und der Request wird in der Konstante “url” gespeichert:

const awc = getCookieValues('adv_awc')[0] || '';
const channel = getCookieValues('source')[0] || 'aw';
const url = 'https://www.awin1.com/sread.php?tt=ss&tv=2&merchant=' + data.advertiserId + '&ref=' + makeString(data.orderRef) + '&amount=' + makeString(data.amount) + '&parts=' + data.cg + ':' + makeString(data.amount) + '&cr=' + data.currency + '&ch=' + channel + '&vc=' + data.voucher + '&testmode=' + data.test + '&cks=' + awc + '&p1=gtms2s';

Danach wird der Request abgeschickt:

// Sends a GET request and nominates response based on the response from the GET request.
sendHttpGet(url, (statusCode, headers, body) => {
  setResponseBody(body);
  setResponseHeader('cache-control', headers['cache-control']);
  setResponseStatus(statusCode);
}, {headers: {key: 'value'}, timeout: 500});
 
// Call data.gtmOnSuccess when the tag is finished.
data.gtmOnSuccess();

Im nächsten Schritt muss der Tag angelegt werden. Gehe dazu auf “Tags” und dann auf “Neu” (im Server-Container). Wähle nun das Awin-Tag aus:

Danach siehst du einige Felder, die befüllt werden müssen:

• Unter “Advertiser Id” kommt deine Awin-ID
• Unter “Order Reference”, “Total Amount”, “Commission Group” und “Voucher Code” kommen die oben erstellten Variablen
• Unter “Currency” kannst du “EUR” schreiben
• Unter “Test” sollte 0 stehen. 0 steht für Live-Tracking. Alternativ kannst du 1 hineinschreiben, wenn sich das Tracking im Test-Modus befindet. Dadurch werden die Hits von Awin nicht verarbeitet.

Endergebnis ist also:

Nun musst du nur noch den vorhin erstellten Trigger hinzufügen:

Speichere das Tag. Mit diesem Schritt wäre das Setup fertig! Was noch fehlt? Testing.

Testen und veröffentlichen

Für das Testing wechseln wir im Server-Container zunächst in den Vorschaumodus:

Jetzt gehen wir in den Web-Container und wechseln ebenfalls in den Vorschaumodus. Gebe im Tag Assistant am besten eine URL an, auf die der Nutzer landet nachdem er auf einen Awin-Werbemittel geklickt hat. Das ist also die URL mit dem awc-Parameter. Im Idealfall sind noch UTM-Parameter dran. Die URL sieht in etwa dann so aus:

https://www.deine-domain.de/landingpage?utm_source=aw&utm_medium=affiliate&utm_campaign=meine-kampagne&utm_content=mein-content&utm_term=mein-term&awc=111111

Gebe die URL also hier ein und klicke auf “Connect”:

In einem neuen Tab öffnet sich nun diese Landingpage. Da die Landingpage den awc-Parameter in der URL enthält, feuert darauf nun das GA4-Konfigurations-Tag. Dabei geht ein Hit an unseren GTM-Server-Endpoint raus. Hier sieht man dann auch die custom_pixel_id (nachfolgend ein beispielhafter, abgeschnittener Hit):

https://collect.meine-domain.de/g/collect?v=2&tid=G-A2ABC2ABCD&...&ep.custom_pixel_id=aw

Im Tag Assistant solltest du auch das Tag unter “Tags Fired” sehen. Kommt der Hit im GTM-Server an, beansprucht zunächst der GA4-Client den Request für sich (hier Screenshot vom Server-Container):

Dann sollte das Awin-Cookie-Tag feuern:

Darauf hin sollten im HTTP-Antwort-Header die Cookies gespeichert sein. Hier aus Sicht des Tags:

Hier sieht man, dass die entsprechenden Werte gezogen und gespeichert werden. Und hier aus Sicht des Headers:

Gibt man nun eine Conversion auf der Website ab, geht der Conversion-Hit wieder an den Server (inkl. Awin-Werten):

https://collect.meine-domain.de/g/collect?v=2&tid=G-A2ABC2ABCD&...&en=purchase&ep.custom_pixel_id=aw&ep.totalAmount=1&ep.commissionGroupCode=default&ep.orderRef=123456789&ep.voucherCode=10_RABATT

Request/Event kommt dann im GTM-Server an und wird vom GA4-Client beansprucht:

Awin-Tag feuert daraufhin im Server-Container:

Das Tag sorgt dann dafür, dass der Hit an den Awin-Server geht:

Im Detail sieht der Request wie folgt aus:

Alle Werte werden also abgegriffen und an Awin übermittelt.

Jetzt nur noch die Einstellungen in beiden Containern veröffentlichen!