Markus Baersch

Analytics · Beratung · Lösungen

Start » Blog » Google Tag Manager / Serverside Tracking

27.07.2021

Ein serverside GTM Container (SSGTM) als eigener Endpunkt ist nur ein Teil eines serverside Tagging- oder Tracking Konzepts. Er ist auch nicht die einzige Option. Eigene Endpunkte als Custom Code oder andere Services sind ebenso denkbar und mögen Vorteile in Aspekten wie Kosten (GCP / AppEngine ist eine relativ teure Option, die je nach Traffic typischerweise zwischen 100,-- und 300,-- Kosten / Monat verursacht) oder eigener Persistenz, Datentransformationsmöglichkeiten, Hash Tables etc. bieten.

Ist die Entscheidung für SSGTM auf der Google Cloud Platform oder einem anderen "Containerschiff" (SSGTM kann auch auf AWS, CloudRun oder allem anderem, was Docker Container frisst, betrieben werden) gefallen, der Tag Manager Container dort eingerichtet und eine Custom Domain (ich würde sie nicht "tracking.meinedomain.de" nennen, aber das ist Geschmackssache) eingerichtet, kann theoretisch die Bestückung beginnen. Ohne eine gewisse Planung, was dabei überhaupt passieren soll, ist das Ergebnis vermutlich eher enttäuschend. Daher werden hier einige der Aspekte betrachtet, die es im Vorfeld zu bedenken gibt. So verlockend es sein mag, mit den bestehenden Tags loszulegen und zu sehen, was passiert 🙂

Tags im SSGTM

Requestformat / Datensammlung im Browser

Solange nur Google Analytics (sei es GA4 oder UA als "führendes Format") im Spiel ist, ist die Wahl des Formats relativ einfach. Es wird entweder mit GA4 gesammelt und alles (oder ausgewählte Events) gehen auch an UA oder eben umgekehrt, wenn man (was üblich / typisch ist) beide GA-Varianten mit Daten versorgen will. Wobei der zweite Fall bedeutet, dass in GA4 zwar Daten ankommen, aber ohne den ganzen Zinnober, den GA4 bei der Datensammlung im Browser veranstaltet, werden die Daten vermutlich jenseits der reinen Events und deren Properties nur in einem anageschlossenen BigQuery sinnvoll zu nutzen sein; die Bildung von Sitzungen etc. ist leider (noch) sehr an das GA4-Script im Client angewiesen. Es sollte bei Verwendung von Universal Analytics bei der Datensammlung also UA auch im Vordergrund stehen, wenn es um die Nutzung von Webanalyse Daten geht.

Zudem ist GA4 auch das Format, was andere Tags am Server "gern haben". Das sind z. B. die Facebook CAPI oder auch das relativ neue Google Ads Tracking via SSGTM. Sollen diese Mittel genutzt werden, muss bei Verwendung eines anderen Formats als GA4 im Browser eine ganze Menge gepatched oder mit anderen Tags (die auch vorhanden sind - es _gibt_ Alternativen!) gearbeitet werden.

Viele andere Formate sind denkbar - prinzipiell kann alles, was die erforderlichen Informationen enthält, um ein Tracking aufzubauen, als Requestformat dienen. Datensammlung mit dem Trackingscript von Plausible Analytics, Matomo oder einem komplett eigenen Format sind sowohl denkbar als auch erprobt.

Wenn es aber darum geht, sich bei bestehender Zustimmung einem evtl. Trackingschutz gegenüber so stabil wie möglich zu erweisen, ist ein Standardformat i. d. R. einem proprietären Format unterlegen. Und auch ein anderer Punkt muss bei der Wahl des Formats bedacht werden:

Was ist mit Consent?

Die anschließende Frage ist die, was passieren soll, wenn keine Zustimmung zum Tracking besteht. Wird dann gar nichts im Client gesammelt und bekommt so der Server entsprechend auch keine Anfragen, die er verarbeiten kann?

Ein proprietäres Format kann "einfacher" stets Daten an den eigenen Server senden. Die Consent-Lage wird dort über den Request als Parameter, Nutzlast oder Cookie empfangen. Das Tracking kann dann entsprechend reagieren. Meint: Bei Zustimmung werden Daten gesendet, bei fehlender Zustimmung nicht. Oder in reduzierter Form..  oder - wie es sich z. B. Facebook wünscht - mit einem Maximum an Infos jenseits von den fehlenden Cookies als Identifier. Mailadressen, IP, User Agent... all das kann man auch ohne Consent senden. Man muss es aber durch den ethischen Hals bekommen und sich bewusst sein, dass das, was hier an Implementierung gewünscht wird, nicht im Sinne dessen ist, was der Datenschutz erfordert. Spätestens seit der DSGVO ist das alles nicht mehr nur ein Vorschlag, also ist bewusster und sensibler Umgang mit IP & Co. nicht optional. Daher ist ein "möglichst vollständiges" FB Tracking ohne Zustimmung auch serverseitig m. E. eine nur theoretische (technisch machbare) aber dringend zu vermeidende Option, wenn es um den Vollausbau für Identifier geht. Das gilt übrigens auch für alle anderen Dienste, die sich derzeit auf den Server zurückziehen.

Der Consent Mode in GA4 ist eine Option, wenn man daran "glaubt". Es werden zumindest a) Cookies bei fehlendem Consent vermieden und b) Requests auch dann an den SSGTM abgesetzt, wenn keine Zustimmung erfolgt ist. Das ist die Grundvoraussetzung, wenn man - sei es für die Webanalyse, eine eigene First-Party-Datensammlung oder eben auch bei Bedarf FB, Google Ads oder andere - ein Tracking in einem bestimmten Umfang aufrechterhalten will. In GA4 selbst bekommt man wenig an Daten ohne Consent, aber aus Sicht von Google Ads oder auch der eigenen Auswertung / Modellierung via BigQuery Daten mag der Consent Mode in Betracht gezogen werden (nach informierter Absprache mit Datenschutz und Legal im eigenen Laden).

Den Umfang der zu verarbeitenden Daten kann man auch ohne Consent Mode durchaus sinnvoll reduzieren, indem man z. B. gezielt nur Conversions von Besuchern an FB oder Google Ads, Bing oder sonstwohin sendet, deren Sitzung mit einem Anzeigenklick begonnen hat. Oder im Fall der Webanalyse eine extrem minimierte Datensammlung in Universal Analytics aufbaut. Oder Daten an Matomo, Piwik Pro, Plausible etc. schickt, um dort eine möglichst vollständige Sammlung im Sinne der Events, aber eben reduziert hinsichtlich PII und DSCVO-relevanter Daten zu betreiben. Es gibt eigentlich immer eine Alternative zum Consent Mode 😉

Sind Cookies jetzt unnötig?

Äh... Nein. Für GA werden (je nach Einstellung, aber per Vorgabe) serverseitig gesetzte Cookies verwendet, die hinsichtlich ITP den üblichen _ga-Cookies aus dem Browser überlegen sind. Aber es sind immer noch Cookies (bei Zustimmung) im Spiel. Daran ändert sich auch für andere Dienste wie Facebook etc. erstmal wenig. Ist ein FB-Script im Browser vorhanden, werden auch Cookies verwendet. Will man diese ebenfalls "härten", kann das per SSGTM passieren - es muss aber explizit eingerichtet werden. Will man sich Click Ids auch dann merken, wenn im Browser keine Scripts mehr von FB, Google Ads oder Bing etc. laufen, ist auch das etwas, was man selbst in seiner Bestückung des SSGTM einplanen muss, wenn diese beim Tracking später nutzbar sein sollen.  Beim "serverseitigen" Google Ads Tracking wird sogar ein Riesenaufwand betrieben, um die Third-Party-Cookies des Ads Systems in den Browser zu bekommen, solange es diese noch gibt. Ähnliche Konstrukte sind auch bei Affiliate Netzwerken für den SSGTM im Einsatz oder zumindest in der Entstehung. Serverside-Tracking = Cookieless Tracking ist ein Mythos. Man kann serverseitig ohne Cookies arbeiten, aber das ist für den SSGTM sogar noch schwieriger, als für andere Lösungen.

Was ist mit dem GTM im Client?

Der Einsatz des SSGTM bedeutet nicht den Wegfall des Tag Managers im Browser. Im Gegenteil - Er bleibt vermutlich auch weiterhin unverzichtbar. Denn:

Weitere Dienste

Nicht alles ist "serverside"-fähig. Es wird also nach wie vor i. d. R. ein clientseitiger Trackinganteil auch jenseits der Datensammlung für den SSGTM erforderlich sein. Third Party Trackingscripts auf Null zu reduzieren und / oder auf den GTM im Browser ganz zu verzichten, ist also i. d. R. nicht (oder nur mit viel Aufwand und direktem Tagging in der Website) zu realisieren. Auch bei FB ist z. B. das parallele Tracking in Client und vom Server die Königsdisziplin, die auch noch eine eindeutige ID für alle Ereignisse erforderlich macht, um eine Deduplizierung zu ermöglichen. Das alles macht den GTM eigentlich auch im Browser noch unverzichtbar.

Will man aber zumindest bei "seiner" eigenen Datensammlung auf möglichst robustes Tracking bauen (sei es die minimale Webanalyse oder die eigene Datenhaltung in BigQuery oder wo auch immer), kann man streng genommen nicht (allein) auf den GTM im Client setzen, um dieses auszuspielen. Denn es mag sein, dass der Browser den GTM schlichtweg nicht laden will. Die direkt implementierte CMP fragt in so einem Fall nach Zustimmung und bei erfolgter Zustimmung kann dennoch nichts getracked werden. Will man diesem Problem entgegen wirken, muss eine direkt implementierte Datensammlung her. Google Formate und andere Standards sind dabei wieder in Gefahr, das gleiche Schicksal wie der GTM zu erleiden und blockiert zu werden.

Robuste Minimal-Datensammlung erfordert Mehraufwand

Dabei geht es längst nicht um Browser wie Brave oder aktive Anti-Tracking-Erweiterungen bzw. Einstellungen in Browsern, die jemand absichtlich und bewusst einsetzt, um nicht getracked zu werden. Wer dies tut, wird erstens kaum Zustimmung zum Tracking geben und zweitens sollte sein Wunsch auch durchaus respektiert werden, wie ich finde. Man sollte sich keine Mühe geben, um expliziten Trackingschutzmaßnahmen aus dem Weg zu gehen. Aber die Restriktionen der Browser erschweren oder verhindern Tracking aller Art mehr und mehr auch "im Standard" und hier ist es m. E. durchaus erlaubt die Frage zu stellen, ob man mit einem Standard-Setup wirklich glücklich wird. Wer ein solides, minimiertes und DSGVO konformes (Ersatz-)Tracking auf Basis von zu Sitzungen zusammengefassten Events einzelner Besucher ohne Speicherung von datenschutzkritischen Daten aufbauen will und deshalb auf serverseitiges Tracking umschwenkt, muss vermutlich zumindest die wesentlichen Events wie Seitenaufrufe direkt und ohne den GTM-Umweg an seinen eigenen Endpunkt senden können. Ist "Vollständigkeit" von Daten ein relevanter Punkt zur Erreichung der Ziele der Einführung eines SSGTM, muss faktisch ein eigenes Tracking-Script verwendet werden. Entweder vollständig oder parallel zum GTM. Die Verteilung der Hits aus unterschiedlichen Quellen an die jeweiligen Zielsysteme kann bei "mehr als nur GA" die Komplexität des serverseitigen Setups allerdings spürbar vergrößern.

Wie starten?

Es ist am Ende eine Kostenfrage, welches Setup man genau aufsetzt und wie viele der eigenen Ziele man im ersten Schritt erreichen muss, wenn ein SSGTM eingeführt wird. Oder besser: Muss dies alles bereits im ersten Schritt berücksichtigt werden oder können einzelne Dinge ggf. in einer späteren Iteration hinzugefügt werden?

"Alles jetzt" bedeutet i. d. R. auch hoher initialer Aufwand bei Bestückung, Test und maximiert die Last des SSGTM. Einer Plattform, auf der täglich noch Fehler behoben und dringend erforderliche Funktionen nachgepflegt werden. Die Zeit wird also nicht nur mehr Features und Effizienz auf der Plattform, sondern auch Clients und Tags für den SSGTM aus der Community bringen. Beides hat Potential, bestimmte Aufgaben in Zukunft leichter umsetzbar zu machen, als es ggf. heute der Fall ist.

Man sollte aber auch nicht zu klein denken. Lediglich den Vorteil von serverseitig gesetzten Cookies für GA und vielleicht über den eigenen Endpunkt ausgelieferte Tracking-Scripts und dort empfangene Hits ein wenig mehr Robustheit in das Tracking zu bringen und so ETP und ITP entgegen zu wirken, muss bei entsprechendem Traffic auch erstmal die Kosten für den Betrieb eines SSGTM rechtfertigen. Spoiler: Das alles kann man ohne SSGTM viel einfacher und kosteneffizienter mit etwas Custom Code und im schlimmsten Fall noch einem eigenen Server für das Tracking  bekommen. Es sind also vor allem die "Nebenziele", die entscheiden, womit man starten sollte. Ist es die parallele Datensammlung für Webanalyse bei fehlendem Consent? Ist es die FB-CAPI? Dann kann man sich mit den oben stehenden Fakten einen eigenen Weg planen.

Ein praxisgerechter Einstieg kann so aussehen:

  • Klein starten: Für einfachere Fälle am "Webanalyse-Fokustool" zwischen UA und GA4 als Datenformat wählen und erstmal ein Setup parallel zur derzeitigen Datensammlung betreiben
  • Anhand der Daten in GA4 und UA in eigenen neuen Properties entscheiden, welches Format tatsächlich genutzt werden soll (oder ob man ggf. beide braucht, auch das ist denkbar, wenngleich nicht wirklich effizient). Wenn Daten auch ohne Consent gesammelt werden sollen, sieht es zwar vielleicht komisch aus, wenn Daten im UA-Format dennoch an den eigenen Server gesendet werden... aber das ist auch so, wenn man GA4 nutzt.
  • Die Consent-Lage am Server aufzulösen, ist je nach Consent Tool unterschiedlich schwierig, aber immer lösbar
  • Alles, was über Analytics hinaus geht und ohne "Bastelei" wie eigene Clients, Tags oder Variablen stattfinden soll, wird am Einfachsten über das GA4-Format anzubinden sein. Das muss nicht die beste Option sein, aber ohne entsprechende Ressourcen für Custom Code & Co (oder wenn man davon nicht abhängig sein will), kann kaum zwischen UA oder GA4 wählen. Als einzige Option bleibt dann ein eigenes Format mit maximaler Flexibilität
  • Dennoch: Eigenes Datenformat und ggf. Unabhängigkeit vom clientseitigen GTM besser erst für spätere Iterationen einplanen. Es löst nur dann Probleme, wenn es um eine möglichst hohe Abdeckung und / oder Flexibilität bei der Datensammlung geht. Die Anforderungen an die Datensammlung wachsen i. d. R. erst mit der Anzahl der Dienste, die via SSGTM angebunden werden sollen.

Ja: Das Ganze ist nicht so einfach wie "Aufsetzen, ein paar Einstellungen ändern und fertig". Das soll es aber auch nicht sein - siehe Abschnitt zum "nicht zu klein denken". Nur mit einem gewissen Umfang an Planung im Vorfeld ist zu vermeiden, dass man zu viele Runden in der Implementierung drehen muss und / oder die eigenen Erwartungen an das, was bei einem Einsatz des SSGTM am Ende rauskommt, nicht enttäuscht werden. Dieser Beitrag hilft hoffentlich dabei, die Komplexität zu vermitteln, die beim SSGTM an der Schnittstelle zwischen Datenschutz, Trackingdiensten und Browsertechnologie entsteht, wenn man ein "First-Party-Tracking" aufbaut. Bei Fragen hierzu - oder freilich Bedarf an Unterstützung bei Planung und Implementierung - freue ich mich über eine E-Mail!

© 2001 - 2021 Markus Baersch