Wie du deinen Server Side GTM mit Cloudflare kostenlos unter deiner Hauptdomain erreichbar machst und ITP umgehst

Die Tracking-Beschränkungen von WebKit, der Browser-Engine hinter Safari erschweren zuverlässiges Tracking, insbesondere weil sie die Lebensdauer von Cookies stark beschränken, teilweise auf 24 Stunden.
Längere Customer Journeys lassen sich damit nicht mehr zuverlässig messen, sodass die Trafficquelle eines Nutzers nicht mehr mit der späteren Conversion zusammengebracht werden kann. Am Ende wird es schwer zu entscheiden, in welche Kanäle man gewinnbringend investieren soll.

In diesem Artikel geht es darum, längere Cookielaufzeiten wieder möglich zu machen, damit deine Cookielaufzeiten nicht mehr so aussehen (hier am Beispiel von Google Analytics’ FPID Cookie):

sondern so:

Cookies per HTTP-Header zu setzen, wie es über den Server Side GTM möglich ist, reicht dagegen nur unter bestimmten Bedingungen aus: Der HTTP Request, der das Cookie setzt, muss von der selben IP-Adresse stammen wie der erste Request des Seitenaufrufs, der den HTML-Code der Website ausliefert.
Genau genommen reicht es, wenn die beiden IP Adressen zur Hälfte übereinstimmen.

Teuer: Cloudflare Enterprise

Wenn dein Unternehmen einen (teuren) Cloudflare Enterprise Account hat, kannst du eine Lösung über Origin Rules implementieren, die ohne Worker auskommt.
Es gibt dazu eine Anleitung von Google, die sich zwar auf den “First Party Mode” und nicht auf den Server Side GTM bezieht, aber vielleicht trotzdem eine gute Inspiration ist.

Kostenlos: Cloudflare Workers

Cloudflare Worker sind kleine “serverlose” Funktionen, die in JavaScript geschrieben werden und auf Cloudflares Plattform ausgeführt werden, wenn der Nutzer eine URL aufruft, die einem von dir definierten Muster entspricht. “Serverlos” / Serverless ist nicht wörtlich zu nehmen, denn natürlich ist ein Server im Spiel, man muss sich nur nicht explizit um ihn kümmern.

100.000 Ausführungen des Workers und damit auch HTTP Requests zum SGTM pro Tag (!) sind im kostenlosen Paket enthalten, was für kleinere bis mittelgroße Websites oft schon ausreichend ist.

Anleitung

Ich gehe davon aus, dass deine Website bereits Cloudflare als CDN nutzt. Davon, Cloudflare nur einzurichten, um Trackingbeschränkungen zu umgehen, rate ich ab. Die Nutzung eines CDNs hat Einfluss auf alle Bestandteile und Funktionen der Website und sollte dementsprechend nur in Abstimmung aller Stakeholder im Unternehmen erfolgen.

1. Erstelle einen neuen Worker:

Benenn deinen Worker wie du möchtest, ich habe mich für sgtm-proxy entschieden.

Klicke auf “Edit Code”, um den Worker zu bearbeiten und zum Code-Editor zu gelangen.

Kopiere dir nun den unten stehenden Code und füge ihn in den Code-Editor ein, den dort bereits vorhandenen Code ersetzt du komplett durch den neuen (1).

Schaue dir dann die Codezeilen 5 (destinationUrl) und 8 (directoryName) an und passe die URLs so an, dass sie zu deinem Setup passen.

export default {
  // Configuration object
  config: {
    // The path to your SGTM, no trailing slash
    destinationUrl: 'https://YOUR-SGTM-DEFAULT-HOSTNAME.owndn.eu',
    // The folder where your GTM dataLayer variables are stored
    // E. g. 'data' if you want to use https://yourdomain.com/data/*
    directoryName: 'data'
  },

  async fetch(request, env, ctx) {
    // Clone the original request
    let newRequest = new Request(request);

    // Create a new URL object from the original request URL
    let url = new URL(request.url);

    // Remove the configured folder from the path
    const pathParts = url.pathname.split('/');
    const folderIndex = pathParts.indexOf(this.config.directoryName);
    if (folderIndex !== -1) {
      pathParts.splice(folderIndex, 1);
    }
    const newPath = pathParts.join('/');

    // Construct the new URL by combining the destination URL and the modified path + query
    const newUrl = this.config.destinationUrl + newPath + url.search;

    // Create new headers object
    let newHeaders = new Headers(request.headers);

    // Modify the Host header
    newHeaders.set('Host', new URL(this.config.destinationUrl).host);

    // Create the new request to send to the destination
    newRequest = new Request(newUrl, {
      method: request.method,
      headers: newHeaders,
      body: request.body,
      redirect: 'manual'
    });

    // Fetch the response from the destination
    const response = await fetch(newRequest);

    // Return the response without modification
    return response;
  },
};

Als owntag Nutzer kannst du hier den Standard-Hostnamen deines Containers eintragen, der auf .owndn.eu endet.

Der Wert von directoryName ist der Seitenpfad, unter dem dein Server Side GTM erreichbar sein soll. Möchtest du deine Daten beispielsweise an https://deinewebsite.de/data/ senden, so ist der Wert hier data.
Um die Einstellungen zu testen, hänge an die im Editor angezeigte URL ein /healthy (2) an und klicke auf “Send” (3). Wenn alles korrekt eingerichtet ist, solltest im Fenster darunter ok (4) erscheinen.

Der Pfad für den du dich entscheidest, darf nicht schon für einen anderen Zweck genutzt werden. Falls du dir unsicher bist, frage vorher bei deinen Kollegen nach, ob du den Pfad problemlos nutzen kannst. /data/ ist hier nur ein Beispiel, spezifischere Alternativen wie z. B. /metrics/ oder /insights/ sind ebenfalls möglich.

Wenn das geklappt hat, kannst du den Worker mit einem Klick auf “Deploy” (5) live stellen.

Als nächstes musst du noch dafür sorgen, dass beim Aufruf deines speziellen URL-Pfades auch tatsächlich der Worker ausgeführt wird.

Im Feld “Zone” wählst du nun die Domain aus, für die du den Worker erstellt hast.

Im darunterliegenden Feld “Route” trägst du nun den URL-Pfad ein, unter dem der Worker ausgeführt werden soll.
Das geeignete Muster dafür ist

*.deinewebsite.de/data/*

Passe auch hier wieder data ggf. so an, wie du es schon in directoryName im Worker-Code definiert hast.

Damit ist die Einrichtung abgeschlossen!
Jetzt kannst du dein neues Setup testen, indem du die URL deines Workers mit einem angehängten /healthy aufrufst:

https://deinewebsite.de/data/healthy

Der Worker leitet den Request an den Server Side GTM weiter, also wird hier in unserem Beispiel die URL https://37c6a336-5346-4075-8886-c8862d8f459c.owndn.eu/healthy aufgerufen.
Der Endpunkt /healthy ist eine Standardfunktion des Server Side GTM und gibt “ok” zurück, wenn alles funktioniert wie es soll.

GTM Containersnippet anpassen

Du kannst nun dein GTM-Container-Snippet so anpassen, dass die Daten wie gewohnt in dein Tracking-System übertragen werden.

Falls du das noch nicht gemacht hast, richte einen Client in deinem Server Side GTM Container ein, der die gtm.js Datei für deinen Web Container ausliefert:

server_container_url setzen

Zuletzt musst du noch den Parameter server_container_url in deinem GTM Web Container so setzen, dass er auf die URL deines Workers zeigt, damit deine GA4-Tags die Daten nicht direkt an google-analytics.com senden, sondern an deinen Cloudflare Worker:

Sobald du die Änderungen im Preview Modus anschaust, solltest du in den ausgehenden Requests, die GA4’s charakteristisches collect in der URL enthalten, sehen, dass die Daten an die Hauptdomain deiner Website gesendet werden:

Herzlichen Glückwunsch!

Du hast es geschafft und hast nun nicht nur ein first party Setup, sondern auch noch ein same-origin Setup, mit dem du zumindest für’s erste - ITP umgehst.