Serverside Tracking (Teil 1): Die Zukunft der Webanalyse trackt serverseitig – aber wie?24 min Lesezeit

Serverside Tracking: Man hört es im Zusammenhang mit dem neuen Google Analytics 4, mit Datenschutz, mit dem Auslaufen der 3rd-Party Cookies oder gar einer Cookie-losen Zukunft. Man verbindet es mit dem Serverside GTM, Googles App Engine – oder war da nicht was mit JENTIS? Was also ist dieses serverseitiges Tracking? Wer braucht es? Wann braucht man es? Und von wo bekommt man es? Die Antworten dazu findest du in diesem Blogartikel sowie eine Übersicht aller aktuellen Serversite Tracking Lösungen.

Starten wir ganz von vorne:

Serverseitiges Tracking – Eine Herleitung.

Das serverseitige Tracking ist keine neue Idee – du hast bestimmt schon von Logfile-Analysen gehört.

Die Logdatei-Analyse ist die älteste Methode des Serverside Trackings und geht auf die 1990er-Jahre zurück, als die internationale Ausbreitung des Internets began. Schon damals wollte man wissen wie beliebt die eigene Website ist und zählte – ganz simpel – alle Client-Anfragen (Requests) an den Webserver. Die Logdaten.

Das Verfahren ist super einfach und gleichzeitig super begrenzt, da Serverprotokolle keine Interaktionen auf der Website wie bspw. Clicks oder Scrolltiefen kennt.

Gezählt werden lediglich die Anzahl der Client-Anfragen.

Man wollte aber mehr wissen – genauere Besucherstatistiken, woher die Besucher kommen und was sie auf der Website machen (Engagement und Conversion).

Die klassische Webanalyse, wie du sie heute kennst.

Die Tracking-Methode: Clientseitig – die schnellste und einfachste Art der Datenerfassung und deswegen die, die sich in den letzten Jahrzehnten durchgesetzt hat.

Sprung-Tipp🦘: Du kannst den Exkurs zum Clientseitigen Tracking (Status Quo) hier überspringen und direkt zu den Details über Serverseitiges Tracking hüpfen.

Exkurs: Clientseitiges Tracking am Beispiel Google Analytics

Besuchst du bspw. die ANALYTICSkiste und schenkst mir deine Zustimmung (Consent), wird beim clientseitigen Tracking direkt in deinem Browser (= Client) ein Google Analytics Cookie (_ga) gesetzt, dass automatisch bei jeder Sitzung erfasst wird:

Google Analytics trackt also keine Menschen – wie dich und mich – sondern clientseitige mittels JavaScript gesetzte Browser-Cookies auf deinem Gerät, die eine spezielle Client ID speichern.

Typ: 1st-Party Cookie🍪

Hinweis: 1st Party Cookies sind Cookies, die von der eigenen Website (Domäne) gesetzt und lokal im Browser des Users gespeichert werden. Sie geben keine Informationen an andere Websites weiter.

Ihr einziger Nutzen: Das Speichern von Informationen wie bspw. die Client ID für Google Analytics.

Diese ClientID nutzt Google Analytics zur Wiedererkennung, wenn du die Website zu einem späteren Zeitpunkt erneut besuchst (Neue vs. wiederkehrende User).

Wechselst du allerdings den Browser oder das Gerät (und somit den Browser) erhältst du ein neues Browser Cookie.

Google Analytics kann dich nicht (automatisch) wiedererkennen und du wirst als neuer User gezählt:

So ist Webanalyse.

Ein Trendanalyse – mit der einen oder anderen Schwachstelle.

Wichtig: In der Webanalyse geht es nicht um exakte Zahlen, sondern darum, Trends in deinen Daten zu erkennen und aus diesen Trends Maßnahmen abzuleiten.

Lies dazu auch diesen Blogbeitrag: >> Google Analytics in der Praxis: Das bringt dir Webanalyse wirklich

Und immerhin, mittels Clientseitigen Tracking erhalten wir weeeeeesentlich mehr und genauere Daten als mit (altmodischen) Logfile-Analysen.

Doch in den letzten Jahren häuften sich die Schwachstellen rund um das Clientseitige Tracking:

Clientseitiges Tracking und seine Schwachstellen

Nehmen wir als Beispiel einen Klick auf eine Google Ads Anzeige, die zu einer Conversion auf deiner Website führt.

Ein Nutzer klickt auf deine Werbeanzeige und kommt auf deinewebsite.com/?gclid=123456789.

2 Wochen später erfolgt der Kauf.

Die ID am Ende der URL (= gclid = Google Click ID) ermöglicht, dass Conversions auf deinerwebsite.com dem ursprünglichen Anzeigenklick zugeordnet werden und somit der Erfolg der Anzeige gemessen wird.

Damit diese Zuordnung auch beim nächsten Seitenaufruf oder gar beim nächsten Website-Besuch möglich ist, wird die gclid in einem First Party Cookie zwischengespeichert.

Ursprüngliche Cookie-Lebensdauer: 90 Tage.

Das heißt: Die Conversion ist auch nach 89 Tagen der Anzeige zuordnenbar.

Zusätzlich speichert Google Analytics die ClientID in das _ga First-Party Cookie um sowohl den aller ersten Besuch (via Google Ads) als auch die Conversion (via direct) – sprich die gesamte Customer Journey – in Google Analytics abbilden zu können.

Ursprüngliche Cookie-Lebensdauer: 2 Jahre.

Das war bis jetzt so.

Denn dann kam ITP:

Cookies, ITP und der unvermeidbare Datenverlust

2017 hat Apple erstmals bekannt gegeben, dass Safaris Intelligent Tracking Prevention (kurz: ITP) client-seitige Drittanbieter (3rd-Party) Cookies gänzlich blockiert.

Wichtig: ITP ist standardmäßig seit dem Safari 11 Browser und somit für Millionen Apple-User (iOS / macOS) aktiv!

>> Details dazu hier bei Webkit (Grundlage des Safari Browsers).

Anfang 2019 ging Apple aber noch einen Schritt weiter.

Ab ITP 2.1. ist die Laufzeit von clientseitig-gesetzten 1st Party-Cookies (sprich: Google Analytics Cookies) auf 7️⃣ Tage (!) beschränkt – statt bisher 2 Jahre.

Besuchen User deine Website also erst nach 8 Tagen wieder, werden sie als neue User in Google Analytics erfasst und somit NICHT wiedererkannt. Das Cookie hat seine Gültigkeit verloren. Ein neues Cookie wird gesetzt.

Aber es geht noch schlimmer.

Wenn deine Website-Besucher über Quellen mit “Tracking Capabilities” (gclid von Google Ads, fbclid von Facebook, etc.) kommen, beträgt die Cookie Laufzeit sogar nur noch 2️⃣4️⃣ Stunden (!) – statt bisher 90 Tage.

Besuchen User deine Website also nach 25 Stunden wieder und konvertieren, wird die Conversion NICHT der Kampagne zugeordnet. Das Cookie hat seine Gültigkeit verloren. Ein neues Cookie wird gesetzt.

Wichtig: Auch alternative Datenspeicher wie localStorage, Indexed DB oder ähnliche sind von diesen Maßnahmen betroffen. Ein Ausweichen ist daher nicht (mehr) möglich!

Safari hat es vorgemacht – alle anderen Browser zogen mit.

So sind mit JavaScript gesetzte 1st Party-Cookies seit 2019 nicht nur für Apples Safari begrenzt, sondern auch für Firefox (ETP – Enhanced Tracking Prevention) und Edge (TP – Tracking Prevention).

Hinweis: Firefox geht sogar noch einen Schritt weiter und blockiert im “Strict Mode” gängige Tools wie Google Analytics oder Facebook gänzlich.

Seit Juni 2022 und mit Version 102 von Firefox, gibt es sogar eine Einstellung in der alle Querystring-Parameter wie bspw. UTM-Parameter aus der URL entfernt werden, wie Analytics Boosters hier schreibt.

Wer ist also betroffen?

• Safari (ITP – Intelligent Tracking Prevention)
• Firefox (ETP – Enhanced Tracking Prevention, Strict Mode)
• Edge (TP – Tracking Prevention)

Was ist mit Google Chrome? 🤔

Chrome wehrt sich (natürlich) mit A-L-L-E-N Mitteln gegen die Einführung von Tracking Preventions, denn die Auswirkung auf Werbung – dem wichtigsten Business Modell von Google – sind dramatisch. Dazu komme ich gleich.

Der Druck ist allerdings groß und auch Google MUSS mitziehen.

Aktuell geplant: Mitte 2024, wie Google hier angekündigt hat.

Hinweis: Den jeweils aktuellen Status der Tracking Preventions in den einzelnen Browsern kannst du hier nachsehen: https://www.cookiestatus.com/

Der Nachteil: Chrome verzeichnet weltweit ⅔ des gesamten Browser Traffics.

Wenn Google also mit seiner Tracking Prevention in Chrome nachzieht und dein Tracking weiterhin clientseitig implementiert ist, kannst du Google Analytics im Prinzip auch gleich lassen.

Die Daten sind Müll.

Dein Bauchgefühl wäre genauer als die Daten in Google Analytics.

Und auch der Erfolg deine Google Ads Kampagnen wird katastrophal einbrechen – wenn nicht schon längst geschehen.

Klingt wahnsinnig dramatisch?

Ist es auch!

Wie dramatisch zeige ich dir im Folgenden: 👇

ITP & Co und die Auswirkungen in der Webanalyse

Eine verkürzte Cookie-Laufzeit (7 Tage / 24h) klingt im ersten Moment gar nicht so schlimm.

Es führt allerdings zu einer schlechten Wiedererkennbarkeit deiner Nutzer – und somit zu mehr “neuen Nutzern” in deinen Google Analytics Reports.

Ist dir schon aufgefallen, dass der Anteil an neuen Nutzer in Google Analytics ziemlich hoch ist?

Im Vergleich zu 2018? 2017?

Tipp💡: Überprüfe die Daten in deinem Google Analytics.

Gehen dazu in Universal –> Zielgruppe –> Übersicht und Vergleiche deine Nutzer mit Neuen Nutzern in einem Zeitraum von bspw. dem letzten Quartal oder sogar Halbjahr.

Wie hoch ist der Anteil an neuen Nutzern? Im Vergleich zu 2018? 2017?

Screenshot: Nutzer vs Neue Nutzer in Google Analytics

Du hast (vermutlich) nicht einfach MEHR wiederkehrende Nutzer oder MEHR Bestandskunden als früher – schon gar nicht so einen utopisch hohen Anteil.

Vielmehr führen Browsern mit Tracking Preventions zu dieser Ungenauigkeit. Das prüfen wir gleich nach.

Was bedeutet jetzt aber „mehr neue Nutzer“ in Google Analytics?

Es bedeutet, dass die Customer Journey deiner Nutzer nicht mehr so genau abgebildet werden kann, weil (fast) jede neue Sitzung einem neuen User zugeordnet wird.

Google Analytics weiß nicht (mehr), dass der User zuerst über Google Ads, dann über SEO und schließlich Direct konvertiert ist. Der direkte Kanal gewinnt die Conversion – alles davor ist unsichtbar.

Das sieht man bspw. in Universal Analytics unter Conversions -> Multi-Channel-Trichter -> Top-Conversion Pfade sehr schön:

Früher (vor ITP & Co) verzeichnete Google Analytics unzählig viele, sehr individuelle und häufig auch sehr lange Conversion Pfade.

Seit 2019 sind die Conversion Pfade in Google Analytics deutlich geschrumpft – und somit deutlich unrealistischer, denn User benötigen in der Regel zahlreiche  Touchpoints bis sie sich entscheiden zu konvertieren.

Customer Journey Analysen seit ITP 2.1?

Tot. ⚰️

„Kürzere Conversion-Pfade” haben aber noch einen weiteren schwerwiegenden Nachteil – sie führen zu einer eingeschränkten Attributions-Modellierung.

Was ist Attribution?

Lies dazu diesen Blogbeitrag: >> MCT – Kanalübergreifende Analysen und Budget-Optimierung in Google Universal Analytics

Kurz gesagt: Conversions werden nicht mehr dem „richtigen“ Kanal zugeordnet.

Jetzt kommt der Stein ins rollen, denn das führt zu einer (stark) eingeschränkten Messung der Kampagnenleistung.

Google Ads, Facebook, Email… egal welcher Kanal, deine Kampagnen haben (vermutlich) seit ITP & Co deutlich an Leistung verloren.

Nicht weil sie schlechter konvertieren, sondern weil die Conversion aufgrund von ITP & Co nicht mehr korrekt zuordenbar ist.

Werbebudget-Allokierung mit Google Analytics (und jedem anderen Cookie-basierten Analyse-Tool)?

Unmöglich.

Kurz gesagt: Die Daten sind im A***** und sinnvolle Analysen in Google Analytics (fast) unmöglich‼️

Machen wir Nägel⛏️ mit Köpfen:

Wie stark bist du von ITP & Co betroffen?

Wie stark DU schon jetzt von ITP & Co betroffen bist, kannst du in Google Analytics schnell analysieren.

Gehe dazu in Google Analytics 4 –> Berichte –> Nutzer –> Techn. –> Technologie-Details und wähle als primäre Dimension „Browser“:

Erstelle nun einen Vergleich um den prozentualen Anteil der Safari, Firefox und Edge User zusammenzufassen und das ganze Ausmaß von ITP & Co für deine Webanalyse und deine Daten zu sehen:

1/4 meiner Website-User kommen also über Browser mit Tracking Preventions auf die ANALYTICSkiste.

1/4 meiner User werden also fälschlicherweise als „neue User“ ausgewiesen, obwohl sie möglicherweise Wiederkehrer sind.

1/4 meiner User haben eine verkürzte Customer Journey und sind von einer eingeschränkte Attributionsmodellierung betroffen.

1/4 meiner User die konvertieren, werden meinen Google Ads und Facebook Kampagnen NICHT korrekt zugeordnet.

Shit ne? 🙄

Wie sieht es bei dir aus?

Remarketing ist tot

Das deine Daten aufgrund der eingeschränkten Lebensdauer von 1st-Party Cookies schlecht sind, ist eine Sache. Nämlich deine Sache.

Die viel größere Sache ist jedoch, dass dadurch Remarketing auf Basis von 1st-Party-Daten gestorben ist, weil die User schlecht wiedererkannt werden (24h / 7 Tage).

Für die Werbeindustrie ist das kritisch –  es geht um viel Geld.

Sie sucht fieberhaft nach „privacy-first“ Alternativen.

Noch gibt es dazu aber keine Entscheidung.

Eine mögliche Lösung (aber sehr umstritten) ist die Privacy-Sandbox von Google mit offenen Standards für die Nachverfolgung von Nutzern bei gleichzeitigem Schutz ihrer Privatsphäre (z. B. durch neue Browser-APIs wie „Trust-Tokens“).

Ist Tracking damit gestorben?

Sind Cookies damit gestorben?

Stichwort: Cookie-less Future.

Cookieless-Future: Ist die Zukunft wirklich Cookie-los?

Grundsätzlich versteht man unter „cookieless future“: Die Zukunft der digitalen Werbung ohne klassischen Cookies.

Was sind klassische Cookies?

• 3rd-Party Cookies (Werbecookies)
• clientseitig gesetzte 1st-Party Cookies

Diese Cookies werden in der nächsten Zeit von der Bildfläche verschwinden.

Das sind aber nicht alle Cookies, die es gibt.

Ganz, ganz wichtig ist, dass First Party Cookies technisch zwei Typen unterscheiden:

Clientseitig gesetzte First Party Cookies

Clientseitig-gesetzte First Party Cookies sind jene Cookies die direkt im Browser des Nutzers gesetzt werden („client side“), vorrangig durch extern nachgeladene Dienste: YouTube, Google Maps, Google Analytics oder auch Facebook, Bing und Slideshare.

Diese Cookies sind vom aussterben bedroht, weil sie schon jetzt von zahlreichen Browsern beschränkt und somit nicht mehr sinnvoll nutzbar sind.

Heute noch nicht ganz, weil in Google Chrome bisher alles wie gewohnt funktioniert – aber ab 2024, sobald Google ebenfalls eine Tracking Prevention einführt.

Spätestens 2024 ist also das clientseitige Tracking mittels 1st-Party Cookie gestorben.

Spätestens 2024 ist auch das Remarketing mit 1st-Party Daten gestorben.

Spätestens 2024 sind auch Drittanbieter-Cookies, Werbecookies und somit Remarketing über 3rd-Party Cookies gestorben.

So drastisch es klingt – es ist so.

Es gibt aber noch einen zweiten Typ:

Serverseitig gesetzte First Party Cookies

Serveseitig-gesetzte First Party Cookies sind Cookies die vom Server der Website gesetzt werden („server side“) um Einstellungen des Nutzers zu speichern wie bspw. die Sprache (DE vs EN), das Land (Shipping nach AT), der Login Status, usw.

Vom Server gesetzte Cookies sind in der Regel Cookies, die gesetzt werden damit die Website ordnungsgemäß funktioniert.

Diese Cookies dürfen vom Browser nicht beschränkt werden.

Stell dir vor, du müsstest dich bei Amazon bei jedem neuen Seitenaufruf neu einloggen oder deine Sprache neu auswählen.

Das Internet würde nicht mehr funktionieren.

Es wird also IMMER eine Möglichkeit geben vom Server Informationen zwischen zu speichern damit die Website funktioniert, denn das http-Protocol  – das Protokoll mit dem das Internet funktioniert – ist stateless (zustandslos).

stateless bedeutet, dass der Server von einer Anfrage (Request) zur nächsten alles vergessen hat.

Bist du bspw. auf Seite A eingeloggt, weiß der Webserver auf Seite B nicht mehr, dass du eingeloggt bist. Er „vergisst“ alle zuvor ausgeführten Sende-Operationen.

Das Internet ist also grundsätzlich „dumm“.

Es benötigt IMMER „etwas“ um Information zu speichern – Cookies🍪, Candys🍬 oder Lollipops🍭. Nenn es wie du willst.

Ganz egal.

Ist die Zukunft also wirklich Cookie-los?

Nein, es wird auch in Zukunft Cookies geben – anders wie bisher müssen diese jedoch durch den Server gesetzt werden.

Typ: Serverseitig gesetzte First Party Cookies🍛.

Genau da setzt das serverseitige Tracking an:

Serverseitiges Tracking einfach erklärt

Mit der Weiterentwicklung des Internets, entwickelte sich auch das serverseitige Tracking weiter.

Wir sprechen heute nicht mehr von simplen Logfile-Analysen sondern von einer hybriden Tracking Methode.

Bei der hybriden Tracking Methode sammelt ein JavaScript-Snippet Daten vom Webbrowser (Client) und gibt diese an eine serverseitige Komponente weiter. Die serverseitige Komponente sendet die Daten anschließend serverseitig weiter an die ausgewählten Dienste wie bspw. Google Analytics:

Das hybride Tracking nutzt also die Vorteile des bisherigen, client-seitigen Trackings und hebelt dessen Nachteile durch das Hinzufügen einer zusätzlichen Ebene – den Server – aus.

Technisch funktioniert das ganze so: Du benötigst einen Webserver – einen Proxy-Server – der sich innerhalb der Hauptdomäne deiner Website befindet.

Die Domain des Proxy-Servers muss eine Subdomain der Website sein, auf der das Tracking eingebaut wird. Nur so kann der Server First-Party Cookies setzen.

Am besten wählst du eine Tracking Subdomain wie bspw. data.analyticskiste.blog

Was du ebenfalls und weiterhin benötigst sind Cookies🍪 zur Wiedererkennung deiner User.

Diese Cookies werden allerdings serverseitig – von DEINEM Proxy-Server – im Browser des User gesetzt und sind somit unantastbar.

Sie unterliegen weder den Tracking Preventions, noch können sie von Ad- oder Cookieblockern geblockt werden.

Es sind Cookies, die essentiell für den Betrieb deiner Website verantwortlich sind – vergleichbar wichtig wie ein Login-Cookie.

Der Tracking-Request geht nun vom Browser des User direkt an die eigene Domäne, bevor sie anschließend weiter an Google Analytics übertragen wird.

Wichtig: Aus Datenschutzgründen benötigst du auch für das serverseitige Tracking die Zustimmung (Consent) des Users!

Das ist nicht nur sehr klug, sondern bietet auch eine Reihe von Vorteilen:

Vorteile des serverseitigen Trackings

Der – für uns Webanalysten – riesengroße, gigantische Vorteil von serverseitig gesetzten 1st-Party Cookies ist:

Höhere Datengenauigkeit

Als Marketer sind wir in hohem Maße auf Daten angewiesen, um herauszufinden, welche Kanäle und Taktiken erfolgreich sind und wo wir unser Budget umschichten oder unsere Strategie anpassen müssen.

Je mehr Daten, je höhere Datengenauigkeit, desto bessere Entscheidungen, desto größer der Erfolg.

Serverseitig gesetzte Cookies liefern diese gewünschte Datenqualität, da die Laufzeit der Tracking-Cookies wieder auf max. 2 Jahre (Google Analytics) bzw. 90 Tage (Google Ads, Facebook & Co) hochgesetzt wird.

Das ist was wir brauchen, denn eine 2-jährige Cookielaufzeit führt zu einer besseren Wiedererkennung und weniger neuen Nutzern in deinen Google Analytics Berichten.

Das wiederum führt zu längeren, realistischeren Conversion Pfaden.

Das wiederum führt zu einer sinnvollen Attributions-Modellierung.

Das wiederum führt zu einer sinnvollen Analyse deiner Werbekampagnen.

Das wiederum führt zu den heiß ersehnten, kanalübergreifenden Analysen.

Werbebudgets können somit wieder effizient verteilt werden.

Intelligent Tracking Prevention beeinflussen deine Daten nicht mehr.

Das genialste an der Sache: Auch Ad- und Cookie-Blocker können das Google Analytics Cookie nicht mehr blockieren, den serverseitig gesetzte 1st-Party Cookies dürfen von den Browser nicht beschränkt werden.

Damit erhältst du zusätzlich im Durchschnitt +15% mehr Daten in deinem Google Analytics.

Halleluja.

Lang lebe Serverseitiges Tracking.🙌

Und es kann noch mehr:

Verbesserter Datenschutz

Serverseitiges Tracking ist nicht nur eine geniale Lösung, um die Lebensdauer von 1st-Party Cookies zu erhöhen und Tracking-Blocker zu umgehen, sondern es bietet auch die Möglichkeiten die Daten zu adaptieren bevor sie an Google Analytics gesendet werden.

Mit der Zwischenschaltung eines eigenen Servers, wird der Daten-Stream nämlich nicht direkt zu Google Analytics sondern ZUERST auf deinen Server geleitet.

Hier kannst du alles machen, was du möchtest.

So kannst du bspw. die IP-Adresse deiner User tatsächlich anonymisieren, bevor du die Daten weiter nach Google Analytics leitest:

IP-Adresse anonymisieren / entfernen

Laut DSGVO dürfen personenbezogene Daten wie bspw. die IP-Adresse oder auch eine Client ID NICHT an US-Unternehmen übergeben werden.

Bei Universal Analytics muss du dich selbst um die Anonymisierung der IP-Adresse kümmern (anonymizeIp = true).

Bei GA4 ist diese Anonymisierung voreingestellt.

Das ist zwar bequem, jedoch nicht ganz so DSGVO-konform wie gewünscht. Denn um die Anonymisierung vornehmen zu können, muss Google die Daten zunächst erhalten und verarbeiten. Die IP Adresse wird somit zumindest kurzfristig bei Google gespeichert. Die Anonymisierung erfolgt zu spät.

Die Lösung wurde erst am 7. Juli 2022 von der französischen Datenschutzbehörde (CNIL) bestätigt:

Es benötigt einen Proxy-Server, der „jeden direkten Kontakt zwischen dem Endgerät des Internet-Benutzers und den Servern des Messwerkzeugs vermeidet“. (Artikel 1, Artikel 2, deutsche Übersetzung von JENTIS)

Serverseitiges Tracking ist eine Proxy-Lösung und führt somit zu einer Datenschutzkonformen Nutzung von Google Analytics.

Natürlich sind noch weitere Punkte zu beachten, wie TrendingTopics in diesem Artikel sehr schön zusammengefasst hat.

PII entfernen

Ein weiteres Beispiel ist das Entfernen von PII – Personal Identifiable Information.

Aus Datenschutzgründen dürfen keine personenbezogenen (PII) Daten an Google Analytics gesendet werden. Das ist Gesetz und zum Schutz der Website-Nutzer.

Ist das nicht der Fall erwarten dich dank DSGVO nicht nur hohe Geldstrafen, sondern Google kann auch deinen Google Analytics Account löschen. Alle bisher gesammelten Daten sind dann einfach weg.

Lese-Tipp📙: >> PII Check – Warum du deine Google Analytics Daten verlieren könntest (und was du dagegen tun kannst)

Serverseitiges Tracking führt zu einem hohen Maß an Datenhoheit und Datenkontrolle.

Du entscheidest selbst, welche Daten getrackt werden und wohin sie gesendet werden.

Durch die direkte Kommunikation der Server können die Daten auch nicht durch Drittanbieter eingesehen werden.

Entdeckst du bspw. PII in deinen Daten, kannst du diese ganz einfach entfernen, bevor du die Daten weiter nach Google Analytics leitest.

Es ist eine sichere Methode zum Tracking sensibler Daten und zur Abbildung der gesamten Customer Journey – einschließlich der Post-Login-Bereiche.

Halleluja.

Lang lebe Serverseitiges Tracking.🙌

Und es kann noch mehr:

Weitere positive Nebeneffekte

SEO: Schnellere Website durch kürzere Ladezeiten

Durch das serverseitige Tracking werden wesentlich weniger Tracking Tags direkt im Browser des Users hinterlegt.

Statt Pixel-Overhead gibt es eine deutliche Pixel-Reduktion.

Das wiederum führt zu einer signifikanten Verbesserung des Page Speeds.

Schnellere Ladezeiten führen zudem zu einer besseren Nutzererfahrung – die Conversion-Rate steigt.

Serverseitiges Tracking ist also auch für SEOs eine willkommene Lösung.

SEO: Weniger Last auf dem Client-Browser

Tracking Snippets im Frontend verringern die Ladegeschwindigkeit der Website. Je mehr Pixel, desto drastischer der Effekt. Der Page Speed ist allerdings ein wichtiger Rankingfaktor für Suchmaschinen.

Durch das serverseitige Tracking wird weniger Tracking-Last im Client-Browser hinterlegt.

Die Daten müssen nur einmal erfasst und können an verschiedene Tools geschickt werden: Google Analytics, Google Ads, Facebook, usw.

Die Arbeit die Daten an verschiedenen Tools zu schicken liegt beim Server.

Serverseitiges Tracking ist also auch für SEOs eine doppelt gute Lösung.

Data Enrichment

Serverseitiges Tracking ist außerdem eine sichere Methode zum Tracking sensibler Daten.

So können bspw. kostbare Daten aus dem CRM serverseitig in Google Analytics angereichert werden:

• Customer Lifetime Value (CLV)
• Kundenklasse
• Einkaufspreis
• Marge

Oder aus dem Shopsystem:

• Produktdaten
• Lieferanten
• IDs

Der Vorteil ist, dass diese wichtigen Daten im Frontend nicht einsehbar sind und trotzdem für Targeting und Optimierung genutzt werden können.

RAW Data

Nicht zuletzt verfügst du mittels serverseitigen Tracking über DEINE Rohdaten. Im Zeitalter von KI hast du somit ein fundamentales Asset.

Diese Daten kannst du in deine eigene Datenbank schicken und zur Weiterverarbeitung nutzen.

Klingt zu gut um wahr zu sein? 🤩

Meine ich auch, deswegen: Run auf Serverside Tracking – aber wie konkret? 👇

Serverside Tracking Lösungen im Überblick

Der Markt an Lösungen für Serverseitiges Tracking ist (noch) überschaubar.

Es gibt Google – natürlich.

Es gibt mittlerweile ein paar unabhängige Google-Lösung Anbieter wie bspw. Stape und Taggers.

Es gibt JENTIS – schon davon gehört?

Es gibt CommandersAct und DLYX.

Es gibt Customer Data Platforms (CDPs), die ebenfalls serverseitig tracken wie Tealium, Segment & Co. Das ist allerdings ein wenig mehr als reines serverseitiges Tracking für GA4 und Google Ads und deswegen an dieser Stelle nicht im Detail erklärt.

Und es gibt „Analytics ohne Einwilligung“ – ein Tool, welches ebenfalls cookielos und serverseitig trackt und damit wirbt, keinen Cookiebanner zu benötigen. Das Tracking funktioniert ähnlich wie bei Matomo und nur für GA4. Google Ads & Co wird nicht berücksichtigt. Das ist allerdings ein wenig weniger als die oben beschriebenen serverseitigen Tracking Lösungen und ist deswegen an dieser Stelle nicht im Detail erklärt.

Mehr Möglichkeiten kenne ich (noch) nicht.

Wichtig: Schreib mir suuuper gerne eine Nachricht, falls ich einen Serverside Tracking Anbieter vergessen habe oder du einen neuen Anbieter gefunden hast. Das interessiert mich mega! 🤩

Jeder Anbieter hat seine Vor- und Nachteile.

Damit du dich für den richtigen Anbieter entscheiden kannst, habe ich begonnen die – mir bekannten – Lösungen zu vergleichen.

Wichtig: Das Sheet ist erst im Aufbau und wird regelmäßig von mir erweitert. Nagel mich daher bitte nicht fest, falls derzeit noch etwas fehlt, unvollständig oder nicht 100% korrekt ist. Ich arbeite daran (und freue mich über deinen Input). 😬

Wo ist das Sheet? Hier direkt drüber. 👆

Serverside Tracking mit Google

Lesetipp📙: >> Serverseitiges Tracking Teil 2: Googles Lösung mit dem Google Tag Manager & Google Cloud Run (+ Alternativen)

Im folgenden zusammengefasst:

Der größte Vorteil der Google-Lösung ist – wie immer – die nahtlose Integration aller Google Produkte mit- und untereinander.

Sie ist relativ schnell und relativ einfach konfiguriert.

Und sie ist – je nach Setup – relativ günstig.

Deswegen ist die serverseitige Tracking Lösung mit dem Serverside GTM und bspw. Google Cloud Run die vermutlich beste Wahl für KMUs, die vor allem die Kosten im Auge haben.

Die Sache hat allerdings einen Haken.

Rechtlich gesehen ist es irrelevant, ob eine US-Cloud ihren Server-Standort in Europa oder in den USA hat. FISA (Foreign Intelligence Surveillance Act) und das Cloud-Gesetz erlaubt US-Überwachungsbehörden den Zugriff auf Daten von US-Unternehmen. Somit ist eine Einhaltung der DSGVO mit einer US-Cloud nicht möglich.

Wen du also eine Datenschutzrechtlich saubere Lösung suchst, gibt es drei Alternativen:

Stape

Lesetipp📙: >> Google Cloud Alternative Stape.IO

Stape ist zwar ein serverseitiger Tracking Anbieter aus Amerika, hat jedoch auch ein Europäisches Unternehmen und nutzt eine EU-Cloud (Scaleway). Somit ist Stape  datenschutzkonformer als Google Cloud Run.

Der Vorteil von Stape ist, dass er auf die Google-Lösung aufsetzt. D.h. du verwendest weiterhin einen WEB und SERVER Google Tag Manager Container. Das Cloud-Setup übernimmt Stape und wird mit wenigen Schritten direkt in der Benutzeroberfläche von Stape vorgenommen.

Für bis zu 10.000 Requests (= sehr, sehr kleine Websites) ist Stape kostenlos.

Bis zu 500.000 Requests kostet Stape 20€/Monat. Danach wird es deutlich mehr, siehe Pricing.

Taggrs

Taggrs ist mir erst kürzlich von einem aufmerksamen Leser empfohlen worden – Danke Kurt. 😊

Aktuell bin ich dran mir Taggrs anzusehen – ein Update folgt.

JENTIS

Lesetipp📙: >> SST Teil 3: JENTIS – datenschutzkonformes, serverseitiges Tracking

Im folgenden zusammengefasst:

JENTIS ist der europäische Tech-Pionier für serverseitigen Trackings mit Ursprung in Österreich.

Das Scale-Up hat eine innovative Technologie entwickelt, die nicht nur für bessere Datenqualität sondern Datenhoheit bei voller Compliance sorgt.

Der Technologie-Anbieter ist ein europäisches Unternehmen. Die Server, auf denen JENTIS gehostet ist, befinden sich in der EU und gehören EU-Unternehmen. Somit ist die Lösung 100% Datenschutzkonform.

Klingt nach Marketing-blabla – ist es tatsächlich nicht.

Ich habe JENTIS nicht nur auf meiner ANALYTICSkiste implementiert sondern bin, zusammen mit MarTech Developer Matthias Hausdorf, JENTIS-Implementierungspartner. Wir setzen JENTIS-Projekte gemeinsam mit bzw. bei Unternehmen um.

Fun Fact: Thomas Tauchner, Co-CEO und Gründer von JENTIS, war tatsächlich mal mein Chef, als wir beide vor vielen Jahren in der selben Firma arbeiteten. Die Welt🌐 ist klein…

Ähnlich wie bei der Google-Lösung oder jedem anderen Hosting-Anbieter kosten Server-Kapazitäten ein wenig Geld. Da JENTIS mehr als nur den Server zur Verfügung stellt, kostet JENTIS auch etwas mehr als im Vergleich zu Google.

Die Kosten sind abhängig vom Traffic (monatliche Sessions) und den Konnektoren (Tool-Anbieter wie Google Analytics, Google Ads, Facebook…). Die Preise starten ab €1.000 und richtet sich somit eher an größere Unternehmen und Enterprises.

DLYX

Wichtig: Der detaillierte Blogartikel zum serverseitigen Tracking mit DLYX kommt asap als Teil 4 dieser Serie.

Im folgenden zusammengefasst:

DLYX.io – The DataLayer Proxy ist eine Lösung von meinem Branchen Kollegen Wolfram Bartke.

Ich habe die Lösung am ANALYTICS Summit 2019 kennen gelernt und war sofort begeistert.

Es ist eine geniale Alternative zu Google – allerdings sehr technisch. Man muss schon wissen was man tut, erhält aber großartigen Support von Wolfram. Für Tekki-Lover unbedingt empfehlenswert, obwohl noch nicht offiziell released.

CommandersAct

Dazu habe ich leider momentan noch wenige Infos, weil noch nicht selber getestet.

Das steht allerdings auf meiner TODO-Liste.

Fazit und meine Empfehlung

Eine zuverlässige Datenerfassung ist die Grundlage JEDER datengesteuerten Marketingstrategie – andernfalls werden falsche Entscheidungen getroffen.

Client-seitiges Webtracking wird aufgrund von Datenschutz-, Compliance- und Eigentumsfragen immer eingeschränkter und unzuverlässiger – diese Einschränkungen werden weiter zunehmen.

Serverseitiges Tracking ist die Zukunft der digitalen Analyse.

Es ermöglicht die benötigten Daten zu sammeln, die volle Kontrolle darüber zu behalten und zu bestimmen, mit wem sie geteilt werden.

Wer braucht es? JEDER der weiterhin Daten erfassen und bspw. in Google Analytics analysieren möchte – also (vermutlich) auch du. 😬

Wann brauchst du es? JETZT – um die Datenqualität in Google Analytics schon jetzt zu erhöhen. Spätestens aber Mitte 2024, wenn auch Google Chrome seine Tracking Präventionen in seinem Browser hinzufügen wird. Denn spätestens dann ist KEINE sinnvolle Datenanalyse in Google Analytics (und jedem anderen Analyse-Tool) mehr möglich.

Von wo bekommst du es?

• Von Google.
• Von Stape.
• Von Taggrs.
• Von JENTIS.
• Von DLYX.
• Von CommandersAct.

Mehr Serverside Tracking Anbieter sind derzeit noch nicht am Markt. >> Lies hier welche Lösung für dich am besten in Frage kommt.

Fragen?

Du hast eine Frage zum serverseitigen Tracking die dich Nachts nicht schlafen lässt?

👉 Großartig, schreibe sie einfach in die Kommentare. Ich helfe, wo ich kann.

Happy Analyzing,

Deine Michaela