Serverseitiger Google Tag Manager Tiefenwirkung

Bevor wir uns mit dem serverseitigen Google Tag Manager (GTM) beschäftigen, möchte ich diesem Beitrag eine Warnung voranstellen: respektieren Sie immer die Privatsphäre der Nutzer.

Alle hier besprochenen Datenerfassungstechniken müssen rechtschaffen angewandt werden und nicht als Umgehung der Vorschriften zur Einwilligung in die Datenerfassung dienen.

10.000 Fuß Ansicht

Hier ist eine vertraute Situation - Google Tag Manager, wie wir ihn seit Jahren kennen.

Ihr Container wird auf allen Seiten oder Bildschirmen Ihrer Website/App geladen, und auf der Grundlage von Trigger-Ereignissen werden Daten an Erst- und Dritt-Endpunkte gesendet.

Es funktioniert, es ist gut, aber es ist nicht perfekt. Tracking-Blocker, JavaScript-Fehler, viele, viele anfragen an Endpunkte und ineffizientes JavaScript sind allesamt Risiken und potenzielle Leistungsprobleme, die zu Problemen mit der Datenqualität führen können.

Serverseitiges GTM verlagert die Anfrage des Tag-Anbieters vom Client auf einen Server - einen Server auf Google Cloud Platform, der sich auf einer Subdomain Ihrer Website befindet. Der in den Browser/die Anwendung geladene Container enthält immer noch Tags und sendet immer noch eine Anfrage, hat aber viel weniger Code, sendet weniger Anfragen, wird nicht unbedingt von Anti-Tracking-Software beeinträchtigt, sendet die IP-Adresse des Nutzers nicht an Tag-Anbieter von Drittanbietern und Cookies von Erstanbietern werden korrekt in einer ITP-konforme Weise gesetzt.

Out of the Box - Was ist cool?

Das serverseitige GTM hat viel zu bieten, denn auf der Client-Seite ist alles sehr vertraut-aber viel besser! Der "traditionelle" digitale Vermarkter kann immer noch seine Facebook-Tags mit denselben Triggern einrichten und Floodlights nach Bedarf einsetzen. Dasselbe, dasselbe... aber anders.

Wie bereits erwähnt, werden die Daten nicht an den Endpunkt des Tag-Anbieters, sondern an eine Subdomain gesendet. Wenn Sie sich zum Beispiel auf www.mysite.comsendet das serverseitige GTM die Daten an tracking.mysite.com, eine Subdomain, die Sie konfigurieren können.

Und das ist großartig, weil...?

• Es respektiert die Privatsphäre der Nutzer: Die IP-Adresse des Nutzers wird nicht an Dritte weitergegeben.
• Es bewahrt die Datenqualität: Bei Anfragen an Ihre eigene Domain wird kein Tracking verhindert.
• Es verringert den Code-Bloat auf der Client-Seite: Die Tags erfordern weniger Arbeit im Browser und verlagern die Arbeitslast stattdessen auf den Server. Das bedeutet, dass das, was im GTM auf dem Browser verbleibt, weniger Arbeit macht, so dass die Website schneller läuft.
• Es konsolidiert Anfragen von der Client-Seite: Sie können mehrere Anfragen vom Server senden, die auf einer Anfrage vom Client basieren.

Bei MightyHive setzen wir uns dafür ein, dass das Beste für den Benutzer im Vordergrund steht, nicht die Möglichkeit, Anti-Tracking-Software zu umgehen oder zu unterlaufen. Zur Erinnerung: handle rechtschaffen, nicht egoistisch. Gegenwärtig werden Daten gesammelt, nicht erfasst. In Zukunft werden Daten ausgetauscht... Denken Sie einmal darüber nach.

Tiefer gehende Auswirkungen

Ist Ihnen schon aufgefallen, dass Tracking-Anfragen an Ihre Domäne und nicht an eine Domäne eines Drittanbieters gesendet werden? Die Arbeitslast der Datenerfassung wird in Ihre Infrastruktur verlagert.

Kommt Ihnen das wie eine Rückkehr zur Webserver-Protokollierung vor? Wie sehr unterscheidet sich dies von der Webserver-Protokollierung?

Sehr stark.

Die Analysedaten werden formatiert (sessionized), bereinigt (PII entfernt), integriert (zusammen mit Daten von Google Ads, Search Ads/Display & Video 360) und so präsentiert, dass sie ihre Funktion erfüllen können: Analyse und Optimierung aller Aspekte des Online-Geschäfts, bei dem es, seien wir ehrlich, um besseres Marketing geht.

Webserver-Protokolle erfassen nicht alle Verhaltensdaten. In der Regel werden die Daten auf Log-Ebene nicht mit den Daten der Marketingkanäle integriert, d. h. es gibt keine Rückkopplungsschleife zur Aktivierung der Daten.

Es gibt jedoch Ähnlichkeiten zwischen serverseitigem GTM und Webserver-Logging. Der Webserver empfängt eine Anfrage, typischerweise für eine Seite, baut den Seiteninhalt auf und antwortet, wobei er möglicherweise First-Party-Cookies zusammen mit der Antwort setzt. Der Server-seitige GTM-Endpunkt empfängt ebenfalls Anfragen und antwortet, möglicherweise mit Cookies (aber mit weniger Inhalt).

Nun... der Webserver weiß welche Seite er zurückgibt.

Er weiß welche Daten auf der Datenebene zu rendern sind, um (zum Beispiel) eine Transaktion aufzuzeichnen.

Die Datenebene wird von einem im Browser abgefeuerten Tag abgeholt und dann zurück an den Tracking-Endpunkt gesendet.

Der Endpunkt nimmt dann die gleichen Daten und sendet sie an Google Analytics (GA), um die Reise zu vervollständigen und Ihre Analysedaten zu erfassen.

Puh!

Warten Sie eine Minute. Wenn der Webserver weiß, dass er eine "Danke"-Bestätigungsseite rendert, und er weiß, welche Daten auf der Datenebene zu rendern sind, warum sollte er sich dann die Mühe machen, diese Daten an den Browser zu senden, damit der Browser sie einfach an den Tracking-Endpunkt und dann an GA zurücksendet?

Warum nicht ein paar Schritte einsparen, um die Effizienz zu steigern? Der Webserver weiß, dass er eine Bestätigungsseite rendert. Er erstellt also genau die gleiche Anfrage wie der Browser und sendet die GA-Transaktionsdaten direkt an den Tracking-Endpunkt. Der Client muss nicht mehr hin- und herreisen.

Es ist ganz normal, Conversion-Tags, Floodlights, FB-Pixel, Adnxs, TTD usw. abzufeuern, um Transaktionen aufzuzeichnen. Schicken Sie diese nicht an den Client, um sie zu verarbeiten. Wenn der Webserver mit der Bestätigungsseite antwortet, senden Sie diese Anfragen direkt an den Tracking-Endpunkt. Der Endpunkt antwortet mit den Details der zu setzenden Cookies, und der Webserver sendet diese zusammen mit dem Inhalt der Bestätigungsseite in der Antwort an den Kunden.

Bedenken Sie, wie viele Marketing-Tags und Tracking-Pixel bei Ereignissen auf Seitenebene ausgelöst werden. Wie viele Tags müssen tatsächlich auf dem Client ausgelöst werden? Wie viele Tags müssen dem Browser gar nicht angezeigt werden? Was wäre, wenn Sie vielleicht nur event-ausgelöste Tags auf Seitenebene hätten? Vielleicht brauchen Sie das Tracking auf Seitenebene nur, wenn Sie alle Ihre datenflut? Dann brauchen Sie die Tracking-Subdomain nicht mit CNAME zu versehen, sondern können den Zugriff auf Ihren Tracking-Endpunkt so einschränken, dass Ihr Webserver nur über https darauf zugreifen kann (z. B. durch Einschränkung des IP-Bereichs). Das ist ein Haufen weniger Komplexität und eine Menge beweglicher Teile aus der Lösung entfernt.

Einfacher ist besser. Kein Code ist besser als kein Codeso lautet ein altes Sprichwort.

Fazit

Die serverseitige GTM-Lösung bietet eine gute und richtige Lösung für die Messung von Digital Analytics. Sie ist gut, weil die Datenqualität verbessert werden kann, die Privatsphäre der Nutzer weiter geschützt wird und sie ist ein wichtiger Schritt in Richtung weniger Arbeit im Browser, was bedeutet, dass Websites und Anwendungen schneller werden.

Wenn man mit der richtigen Motivation über die möglichen Lösungen nachdenkt, die die Technologie bietet, wird deutlich, wie vielseitig die Lösung ist, wie viel Leistung zur Verfügung steht und welche Möglichkeiten noch erforscht werden müssen, um First-Party-Daten zu nutzen.