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

Michaela Linhart 27 Comments

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 Cookie _ga

Screenshot: Google Analytics Cookie _ga

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:

Status Quo Clientseitiges Cookie Tracking

Screenshot: Status Quo Clientseitiges Cookie Tracking

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?

Nutzer vs Neue Nutzer in Google Analytics

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:

Customer Journeys in Google Analytics im Vergleich

Screenshot: Customer Journeys in Google Analytics im Vergleich

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“:

GA4 Technologie-Report

Screenshot: GA4 Technologie-Report

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:

GA4 Browser Report zur ITP-Analyse

Screenshot: GA4 Browser Report zur ITP-Analyse

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:

Serversite Tracking einfach erklärt

Screenshot: Serversite Tracking einfach erklärt

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?

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

Mehr über Google Analytics 4 erfahren?

Komm in meine exklusive Analytics Community:

  • großartiger Artikel, vielen Dank für die vielen Inputs.

  • Hi, ich finde den Beitrag sehr gelungen und übersichtlich. Technisch steht die Wahl für mich längst fest: Google hat die besten und ökonomisch verträglichsten Lösungen. Der europäische Datenschutz muss aus meiner Sicht moderner werden und seine Ansichten ändern: Anonyme IDs sind keine personenbezogenen Daten sind und das Schadensrisiko ist extrem begrenzt.

  • Peter Müller sagt:

    Danke Michaela für den aufschlussreichen und informativen Artikel. Ich freue mich schon auf Teil 2 und 3 🙂

  • Moritz sagt:

    Hi,
    Kommentar zu folgender Aussage: „Serverseitiges Tracking ist eine Proxy-Lösung und führt somit zu einer datenschutzkonformen Nutzung von Google Analytics.“
    Die von dir verlinkten Artikel von CNIL beschreiben ja die Anforderungen für den datenschutzkonformen Einsatz von Google Analytics. Neben dem Einsatz des Proxy Servers, wird hier auf die Entfernung von UTM-Parametern, User-Agents und Referern verwiesen (Artikel 2). Wenn du dich also auf diese Artikel beziehst, sind aus meiner Sicht die anderen Anforderungen ebenso wichtig in dieser Interpretation.
    Aus meiner Sicht ist nach diesen Anforderungen eine sinnvolle Nutzung von Google Analytics nur sehr begrenzt möglich.
    Denn ein so stark begrenztes Google Analytics, bei dem selbst die Channelreportings fehlen, da keine UTM-Parameter mehr getrackt werden, haben aus meiner Sicht wenig Aussagekraft.
    Wie siehst du das?

    Bitte nicht falsch verstehen, der Beitrag ist super. Ich möchte nur nachvollziehen, wie du diese Sachlage generell interpretierst.
    Gruß
    Moritz

    • Hallo Moritz,

      vielen Dank für deinen Kommentar und ausgezeichnete Frage.

      Wenn man 100% Datenschutzkonform unterwegs sein will, dann muss man sich vermutlich auch an diese Maßnahmen halten. Allerdings stelle auch ich mir dann die Frage, wie sinnvoll Analysen (egal ob Google Analytics oder anderes Webanalyse-Tool) dann noch sind.

      Wichtig ist, dass _immer_ mit Zustimmung getrackt wird und der User in der Datenschutzerklärung transparent aufgeklärt wird, was, wie, wo mit den Daten passiert. Dann sollte es kein Problem sein UTMs & Co zu tracken.

      Die „echten“ personenbezogenen Daten wie IP-Adresse dürfen allerdings nicht getrackt werden und dafür benötigt es einen Proxy, um 100% sicher zu stellen, dass die IP anonymisiert, gelöscht, etc. wird.

      Aber die klassische Antwort ist natürlich: Das muss jedes Unternehmen individuell mit seinem Datenschutzbeauftragten klären. ,-))

      Ganz liebe Grüße
      Michaela

  • Gottfried sagt:

    Danke für den ausführlichen, und auch für mich als „Quereinstieger“ informativen und gut lesbaren Bericht.
    In meinem Unternehmen war Analytics und Conversion Tracking bis zu meinem Arbeitsantritt noch gar kein Thema (hey, super, ich musste mich weder um das auslafende Google UA oder um das Problem der dubioserweise steigenden „Neu“nutzer kümmern).
    Allerdings stellt sich mir jetzt die Frage: macht es denn beim Start „vom weissen Blatt Papier“ überhaupt noch Sinn, sich mit herkömmlichem Tracking zu beschäftigen? Sollte ich nicht gleich alles in Richtung serverseitiges Tracking angehen? Oder profitiere ich bis 2024 noch so stark von den Daten, die ich auf dem „herkömmlichen“ Weg bekomme, dass sich die Einrichtung dennoch noch lohnt?

    • Hallo Gottfried,

      ausgezeichnete Frage, vielen lieben Dank.

      Bei allen meinen Projekten versuche ich im Zuge von GA4 auch direkt auf das serverseitige Tracking umzusteigen, weil man sofort von einer deutlich besseren Datenqualität profitiert. Insbesondere wenn man intensiv mit Google Ads und Facebook Ads arbeitet, macht SSTracking Sinn, da sonst die Kanäle in Google Analytics falsch bewertet werden.

      Aber natürlich geht das nicht immer, da das Setup mit Kosten und Aufwand verbunden ist.

      Deswegen sage ich dann immer: Bevor gar nicht getrackt wird, besser client-seitig (= herkömmlicher Weg) und im Zuge des nächsten Jahres / spätestens 2024 auf serverseitig umsteigen.

      Also wie immer im Leben: Es kommt darauf an. :-))

      Ich hoffe, dass hilft dir trotzdem weiter und ganz liebe Grüße
      Michaela

  • Britta sagt:

    Hallo Michaela, danke für deinen tollen Beitrag. Das macht nochmal alles etwas klarer! Ich habe aber trotzdem eine Verständnis-Frage. Du schreibst „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).“ Wenn ich aber bei cookiestatus.com schaue, dann steht unter „Cookies in 1st party context“ der Vermerk „No restrictions.“. Jetzt bin ich verwirrt, ob Edge die 1P Cookies wirklich begrenzt oder nicht? 🙂

    Liebe Grüße
    Britta

    • Hallo Britta,

      gerade nochmal recherchiert und du hast Recht, die Tracking-Preventions sind im Detail bei jedem Browser ein wenig anders und Edge hat anscheinend nicht diese Zeitbegrenzung für Cookies.

      Allerdings restriktiert Edge bei allen „Advertising“ Trackern den Storage-Zugriff (also Cookies/Local Storage etc.) was vermutlich zum selben Ergebnis führt. Details siehe hier: https://www.cookiestatus.com/edge/#classification-of-known-trackers

      Ganz liebe Grüße
      Michaela

      • Britta sagt:

        Vielen lieben Dank für die schnelle Antwort! Aber kannst du sagen auf welchen Zeitraum Edge und Firefox genau die Cookie-Laufzeit für Advertising bzw Analytics Tracker begrenzen? Ich habe schon so viel recherchiert und auch die cookiestatus Seite angeschaut, aber so richtig werde ich nicht schlau daraus. Jeder spricht immer nur von Safari und das Firefix und Edge es ähnlich machen aber eine genaue Aussage für beide Browser finde ich irgendwie nicht. Das Thema ist für mich so komplex und ich bin nach langer Recherche immer noch etwas verzweifelt 😀

        • Hallo Britta,

          tatsächlich habe ich nach längerer Recherche auch keine Aussage dazu gefunden. :-//

          Jetzt könnte man das technisch super mühsam durchtesten und ausprobieren. Den Aufwand habe ich mir aber noch nicht gemacht…

          Stattdessen gehe ich einfach von der selben Cookielaufzeit aus, weil in der Regel ist der Edge-Anteil nicht soooo mega groß und deswegen nicht sooo mega bedeutend. Das kann natürlich je Unternehmen und Branche unterschiedlich sein aber auch dann löst der Umstieg auf das serverseitige Tracking automatisch das Problem.

          Ich höre mich trotzdem mal um und falls ich etwas herausfinde, schreibe ich dir sofort.

          Ganz liebe Grüße
          Michaela

  • Jens sagt:

    Hi Michaela,
    danke f.d. diesen Artikel. Verstehe ich das richtig dass der Wegfall der UTM-Parameter nicht mehr wirklich als Problem zu sehen ist wenn man Serverside-Tracking einführt? Apple hat ja bspw. in der neuesten Keynote der WWDC angekündigt dass in der nächsten Safari-Version UTM-Parameter nicht mehr funktionieren werden. Da werden dann sowieso alle anderen Browser nachziehen (müssen). Heißt für mich in der Schlussfolgerung dass ich als User gar nicht mehr entscheiden werde dass es für mich, beim Besuch einer Website, o.k. ist dass ich derart getrackt werde, da der Browser diese Parameter sowieso ‘killen‘ wird.^^

    Wie geht man damit um? Das betrifft ja so ziemlich alle Online-Marketer….

    lg.

    • Hallo Jens,

      da hat Apple zuletzt wieder Panik geschnürt. :-//

      Safari wird zukünftig (ab ca. September) UTM-Parameter entfernen. Aber nur(!) im privaten Surfmodus – und nicht generell.

      Wir müssen natürlich schauen, wie es da weiter geht und ob andere Browser mitziehen – aber vorerst kein Weltuntergang, würde ich sagen.

      Serverseitiges Tracking würde in dem Fall aber auch nichts helfen, da es dabei um Cookies geht und nicht um Parameter in der URL. Deswegen zwei unterschiedliche Themen.

      Ganz liebe Grüße
      Michaela

      • Jens sagt:

        Danke dir f.d. super-zeitnahe Reaktion. Also ich denke dass man sich grundsätzlich darauf einstellen sollte dass über kurz oder lang nicht nur im Private-Surf-Modus solche Parameter pauschal entfernt werden.

        Gibt’s dahingehend schon Lösungen oder zumindest Ansätze wie man damit dann umgehen kann technisch um nicht massenhaft Datenströme zu verlieren?

        herzliche Grüße. Jens

        PS: auch wenn’s zwei unterschiedliche Themen sind, macht es das serverside-Tracking für mich gefühlt ein bisschen obsolet, denn es würde ja sowieso ganz und gar nicht aus der Misere helfen 😉

        • Hallo Jens,

          für das Paramter-Problem kenne ich noch keine Lösungsansetze. Ob das Problem zukünftig alle Browser im Standard einsetzen, bin ich mir nicht sicher. Da muss man abwarten. Sollte das doch kommen, denke ich, wird es andere Tracking-Ansätze geben.

          So wie das serverside Tracking. Dieses löst das ITP-Problem und die verkürzte Cookielaufzeit. Ein Problem, dass unabhängig von den UTM-Parametern besteht. Es ist aktuell der beste Weg für ein sauberes, Daten-freundliches Tracking und deswegen absolut empfehlenswert – und sowas wird, mit hoher Wahrscheinlichkeit, dann auch für das UTM-Problem kommen. Wie das aussehen wird, steht allerdings noch in den Sternen…

          Ganz liebe Grüße
          Michaela

  • Patryk sagt:

    Danke, dass du regelmäßig zum Thema veröffentlichst, Michaela. Was in der Diskussion vielleicht noch fehlt, ist der Aspekt, dass gerade der Consent-Click zuverlässig Bot-Traffic zu filtern scheint (vgl: https://medium.com/@lukas-oldenburg/bots-analytics-common-failing-approaches-to-bot-filtering-incl-ai-6c7c25d3e0f5), was dann ohne Cookie-Banner wegfallen würde. Aber wo das client-seitige Tracking für Ads-Attribution eh mitläuft, könnte man auch alle Banner-Clicks, also Zustimmer und Ablehner, als „human“-Interaction flaggen und ans serverseitige Tracking weiterreichen. SG

    • Hi Patryk,

      spannender Artikel von Lukas Oldenburg zum Thema Spam-Traffic vermeiden – vielen Dank fürs Teilen. :-))

      Das hat aber grundsätzlich nichts mit dem Blogartikel und serverside Tracking zu tun – oder sehe ich hier die Verbindung nicht?

      Ganz liebe Grüße
      Michaela

  • Alisa sagt:

    Hallo Michaela,
    wie steht ihr zu Tools wie EventStream von Tealium? Dies ist ja auch eine serverseitige Lösung.

    • Hallo Alisa,

      stimmt, diese Tools bieten auch serverseitiges Tracking an und habe ich gleich im Blog vermerkt.

      Da sie meiner Meinung nach eine nochmal advanctere Lösung als „reines serverseitiges Tracking“ für GA4, Google Ads, Meta sind, sind es aber Lösungen die ich im Blog nicht im Detail beschreiben würde. Dazu braucht es extra Blogartikel. :-))

      Vielen lieben Dank
      Michaela

      • Alisa sagt:

        Hallo Michaela,

        vielen Dank für deine Rückmeldung. Ich hoffe, es wird einen extra Blogartikel geben :-). Ich verfolge euren Blog auf jeden Fall gerne weiter.

        Viele Grüße
        Alisa

  • Andreas Neumann sagt:

    Hallo Michaela,

    vielen Dank mal wieder für deinen ausführlichen Beitrag zu dem Thema. Eine Frage dazu: Nach der Implementierung von serverside Tracking messen wir etwsa mehr Traffic als beim clientside Tracking in GA4 (wir haben für serverside eine eigene Property eingerichtet, damit wir die Daten vergleichen können). Allerdings funktioniert die Attribution beim serverside Tracking wesentlich schlechter als beim clientside Tracking (direct-Traffic ist angestiegen, Paid und Organic Search ging nach unten). Mit diesem Effekt haben wir nicht gerechnet. Du schreibst ja auch, dass sich die Attribution durch serverside Tracking eigentlich verbessern müsste. Hast du das auch schon bei serverseitigen Setups beobachtet? Wenn ja, woran hat das gelegen?

    Vielen Dank für dein Feedback und deine ausführlichen Infos rund um das Thema Tracking.

    Viele Grüße

    Andi

    • Hallo Andi,

      das liegt oft daran, dass die Reihenfolge der Tags nicht stimmt. Es muss immer der Google Tag mit der GA4 Konfiguration und der Server-URL zuerst feuern. Feuert ein Tag zu früh, bevor die Konfiguration aktiv ist, dann sind diese Requests Client-Side und GA4 kommt durcheinander.
      In der Web GTM Vorschau (Tag Assistant) müsstest du das gut prüfen können.

      lg Matthias

  • tom sagt:

    Hey Michaela,

    super Post und super zusammengeschrieben. Ich hab mal eine Frage. Wie bindest du denn das Server Side Tracking denn immer ein? Gehst zu z.B. bei Services wie Meta auf ein Hybridtracking (Deduplizierung) und bei Services wie Google Ads, wo es diese Möglichkeit gibt, nur wirklich über den Server? Oder sagst du du hast am Client nur den gtag der die Infos an den Server sendet und sonst kein anderen Service mehr.

    LG

    • Hi Tom,

      vielen Dank für deine Frage.

      Wir tracken meist clientseitig via GA4 (gtag) und schicken die Events serverseitig an alle Tools, welche die Daten benötigen: GA4, Google Ads, Facebook usw. Das reduziert auch die Last am Client.

      Meta empfiehlt zusätzlich zur CAPI auch das Pixel zu verwenden. Deswegen setzen wir meistens beides auf und nutzen die Duplizierung – so wie von dir beschrieben.

      Ganz liebe Grüße
      Michaela

  • Victoria Nöbauer sagt:

    Hallo Michaela,

    vielen Dank für deinen ausführlichen Blogbeitrag! Ich hätte noch eine Frage zu dem Thema. Wir haben bereits auf Jentis umgestellt und nutzen das Tool „Google Analytics 4 Server-side“, um unsere Daten zu verfolgen. Allerdings haben wir festgestellt, dass unsere Zielgruppen in Google Analytics 4 vorhanden sind, jedoch nicht in Google Ads erscheinen. Um dieses Problem zu lösen, müssen wir auch Ereignisse auf der Clientseite verfolgen, zusätzlich zu den serverseitigen Daten.

    Das führt jedoch dazu, dass wir redundante Seitenaufrufe erfassen, da die Client-ID, die für die clientseitigen Tags verwendet wird, nicht mit den serverseitigen Daten synchronisiert ist. Jetzt überlegen wir, wie wir dieses Problem angehen können. Eine Möglichkeit wäre, einen neuen Datenstrom anzulegen, oder wir könnten die Daten mithilfe einer benutzerdefinierten Dimension separieren. Hast du schon einmal ähnliche Probleme gehabt, bei denen die Zielgruppen in Google Ads nicht durch serverseitige Tags befüllt wurden? oder hättest du einen anderen Lösungsvorschlag ?

    Danke!

    • Hallo Victoria,

      vielen Dank für deine Frage.

      Das eure Zielgruppen aus GA4 nicht in Google Ads verfügbar sind, liegt an den Google Signalen. Soweit ich weiß, funktionieren diese mit JENTIS noch nicht, da dafür ein 3rd-Party-Cookie notwendig ist. Da JENTIS rein serverseitig trackt gibt es dieses 3rd-Party-Cookie allerdings nicht.

      Soweit ich weiß, arbeitet JENTIS aber gerade an einer Lösung. Melde dich diesbezüglich gerne direkt an den JENTIS Support. Falls dieser nicht weiterhelfen kann, melde dich gerne nochmals per Email an mich: michaela.linhart@gmail.com Dann schauen wir, dass wir gemeinsam ein optimales Setup zustande bekommen.

      Ein weiterer Datenstrom, eine zusätzliche Custom Dimension oder sonstige Workarounds sind nämlich nicht notwendig.

      Ganz liebe Grüße
      Michaela