Server-Side Tracking(Was es kann. Und was nicht.)

Willkommen beim Marketing Techie Podcast, dem Podcast über die Technik hinter dem Online-Marketing. Verständlich erklärt, auch für Non-Techies. Mit Emilian Buza von trace5.co. In der heutigen Folge: Server-Side Tracking – was es ist, was es kann und was nicht.

Es gibt eine Firma, von der du wahrscheinlich noch nie gehört hast. Und trotzdem schreibst du als Online-Marketer oft ihren Namen. Vielleicht jede Woche. Möglicherweise sogar jeden Tag. Die Firma heißt Urchin.

Oder vielmehr: hieß Urchin. Und du schreibst ihren Namen in jeden Kampagnenlink. Denn genau dafür steht das U in UTM.

Wie in utm_source oder utm_campaign: Urchin.

Jedes Mal also, wenn du einen Link für Google Ads, deinen Newsletter oder LinkedIn taggst, verewigst du eine Firma, die es seit über 20 Jahren nicht mehr gibt. Und das Beste: Wofür die anderen beiden Buchstaben stehen, ist nicht mal ganz klar.

Google sagt: Urchin Tracking Module. Einer der Gründer sagt: Damals hieß das Urchin Traffic Monitor. Du tippst also jeden Tag eine Abkürzung, bei der sich nicht mal ihre Erfinder und Google einig sind, was sie überhaupt bedeutet.

Ähm … aha. Und wie kam's dazu? Nun, die Firma hinter Urchin entstand Mitte der 90er in San Diego. Aber nicht als Marketing-Firma. Die Gründer waren nämlich Webhoster.

Du weißt schon … Sie haben Websites für Kunden gebaut und auf ihren eigenen Servern betrieben. Und damals war Bandbreite teuer. Also die Datenmenge, die ein Server an die Besucher rausschickt. Jede Seite, jedes Bild kostete Geld.

Und dieses Geld wollten die Gründer ihren Kunden natürlich korrekt in Rechnung stellen. Aber woher weiß ein Webhoster, wie viele Daten die Website eines Kunden verbraucht hat? Aus der Logdatei. Eine Logdatei ist eine Liste, die der Server selbst schreibt.

Jede Anfrage, die bei ihm ankommt, wird dort notiert. Welche Seite abgerufen wurde, wann, von welcher IP-Adresse und wie viele Bytes der Server dafür verschickt hat.

Also hat einer der Gründer ein kleines Programm geschrieben, das diese Logdateien auswertet und die Bytes zusammenzählt. Ergebnis: eine Rechnung. Und jetzt denk mal kurz mit.

Wenn in der Logdatei sowieso steht, welche Seite wann aufgerufen wurde … dann kann man damit ja nicht nur Bytes zählen … sondern auch Besucher. Genau das machte Urchin dann auch.

Und irgendwann haben die Gründer ihr Hosting-Geschäft verkauft und nur noch dieses Programm weiterentwickelt. Urchin wurde damit zum Standard bei Webhostern.

Die Webanalyse ist also nicht entstanden, um Marketing zu messen, sondern weil ein Webhoster seine Rechnungen korrekt schreiben wollte. Das hatte nur einen Haken. In der Logdatei steht zwar die IP-Adresse, aber die verrät nicht zuverlässig, wer da eigentlich kommt.

Viele Menschen surften über dieselbe IP-Adresse ihres Internetanbieters. In der Logdatei sahen sie dann aus wie ein einziger Besucher.

Und wer sich am nächsten Tag neu einwählte, bekam oft eine neue IP-Adresse und wurde plötzlich als neuer Besucher gezählt. Dazu kamen Seiten, die aus einem Zwischenspeicher geladen wurden, kamen beim Server gar nicht erst an.

Wie viele Besucher eine Website wirklich hatte, ließ sich aus der Logdatei also nur ungenau ablesen. Doch dann hat Urchin ein Skript gebaut, das direkt auf der Website im Browser läuft und Besucher mit Cookies wiedererkennt.

Und mit genau dieser Version kamen auch die UTM-Parameter. Im März 2005 hat Google Urchin gekauft. Berichten zufolge für rund 30 Millionen Dollar. Kurz darauf hieß das Produkt: Google Analytics.

Und es war kostenlos. Spätestens damit ist das Tracking dann endgültig in den Browser umgezogen. Ein Stück JavaScript auf jeder Website. Und das blieb 20 Jahre lang der Standard.

Doch wie sieht es damit im Jahr 2026 aus? Jetzt reden alle über Server-Side Tracking. Der Browser schickt die Daten nicht mehr direkt an Google oder Meta, sondern erst einmal an deinen eigenen Server. Und dort entscheidest du, was weitergeht.

Das ist nicht dasselbe wie die Logdatei von damals. Aber das Tracking wandert wieder dahin, wo es angefangen hat: auf den Server. Server-Side Tracking ist also nicht nur die Zukunft. Es ist auch ein Comeback.

Und heute geht's um genau dieses Comeback.

Und damit du das wirklich verstehst, müssen wir erst mal klären, wie Tracking normalerweise funktioniert. Also das ganz klassische Tracking, mit dem du wahrscheinlich jeden Tag arbeitest.

Beim klassischen Tracking passiert alles im Browser. Also bei deinem Besucher, auf seinem Rechner, auf seinem Handy. Wenn du den Google Tag Manager einrichtest, bekommst du ein kleines Stück Code, ein sogenanntes Skript. Ein Skript ist eine Liste von Anweisungen für einen Browser. Dieses Skript baust du in deine Website ein.

Oder dein Entwickler macht das für dich. Ab jetzt steckt es in jeder Seite deiner Website. In diesem Skript steht alles, was du im Tag Manager eingestellt hast. Vor allem zwei Dinge. Regeln, wann etwas passieren soll, das sind die Trigger, und Aufgaben, was dann passieren soll, das sind die Tags.

Jetzt ruft jemand deine Website auf. Nennen wir ihn deinen Besucher. Er sitzt zu Hause an seinem Laptop. Sein Browser lädt deine Seite auf seinen Laptop, findet darin das Skript und führt es aus. Ab hier läuft alles auf dem Laptop deines Besuchers.

Nicht bei dir und nicht bei Google. Der Browser deines Besuchers hat keine Ahnung von Tracking. Er weiß nicht, was Google Analytics ist. Er macht einfach, was das Skript ihm sagt. Das Erste, was das Skript im Browser deines Besuchers tut, es sagt diesem Browser, wenn hier jemand klickt, sag mir Bescheid.

Dann wartet es. Jetzt klickt dein Besucher auf einen Button. Sein Browser merkt das und denkt, da wollte doch jemand Bescheid wissen. Also sagt er dem Skript, hier wurde geklickt, und zwar auf diesen Button. Das Skript, immer noch im Browser deines Besuchers, schaut jetzt in seine Regeln.

Es fragt sich, soll ich bei diesem Klick etwas tun? Eine Regel könnte lauten, wenn jemand auf den Kontaktbutton klickt, dann melde das. Passt der Klick nicht, passiert nichts. Passt die Regel, führt der Browser deines Besuchers jetzt den Tag aus, der zu dieser Regel gehört. Der Tag ist ebenfalls ein Teil des Skripts, eine Liste von Anweisungen.

Falls dich das jetzt verwirrt, stell es dir einfach als Wenn-Dann vor. Wenn jemand auf den Button klickt, ist der sogenannte Trigger. Dann, sende Google die Informationen, ist der Tag selbst. Das Skript prüft also. Passt der Klick zur Regel?

Ja. Und was soll dann passieren? Der Tag wird ausgeführt. Und was macht der Tag, den du in das Skript eingebaut hast? Er fragt beim Browser nach, auf welcher Seite dein Besucher gerade ist und welchen Button er angeklickt hat.

Aus diesen Antworten setzt der Tag eine Nachricht zusammen, direkt auf dem Laptop deines Besuchers. Zum Schluss sagt der Tag zum Browser deines Besuchers, und jetzt schick diese Nachricht bitte an Google. Und der Browser deines Besuchers schickt sie direkt von dessen Laptop aus los, ohne nachzufragen. Nochmal in einem Satz. Alles bis zum Verschicken passiert im Browser deines Besuchers auf seinem Gerät.

Das Skript meldet sich an, sein Browser sagt Bescheid, die Regel prüft, der Tag schreibt die Nachricht und sein Browser verschickt sie. Und das passiert nicht nur einmal. Auf den meisten Websites laufen GA4, das Meta-Pixel, Google Ads, LinkedIn und noch ein paar mehr. Und jedes dieser Tags verschickt seine eigene Nachricht. Findest du das nicht auch etwas gruselig?

Denn stell dir das mal bildlich vor. Dein Besucher sitzt in seiner Wohnung, und in seinem Wohnzimmer stehen zehn fremde Postboten. Jeder schreibt fleißig mit, was er so tut, und rennt dann mit seinem Brief raus. Das wäre im echten Leben alles andere als akzeptabel. Im Tracking war das jahrzehntelang Standard.

Und genau deshalb finden das so einige Menschen und Organisationen auch sehr seltsam. Ein Adblocker zum Beispiel. Der weiß natürlich, wie das Tracking von Google, Meta und Co. aussieht, und blockiert, dass Conversions zurückgemeldet werden können. Conversion weg.

Auch manche Browser blockieren das selbst. Safari zum Beispiel ist da ziemlich rigoros. Cookies, die per JavaScript gesetzt werden, damit dein Besucher wiedererkannt wird, räumt Safari nach ein paar Tagen einfach wieder ab. Kommt dein Kunde nach zwei Wochen zurück und kauft? Tja.

Für dein Tracking ist das ein völlig neuer Mensch. Und es sind nicht nur Datenschutzbedenken, die diese Art von Tracking so problematisch machen. Hinzu kommt noch die Performance. Denn stell dir mal vor, was es bedeutet, wenn eine ganze Reihe von Skripten geladen werden muss. Das macht die Seite langsam.

Und eine langsame Seite kostet dich was? Natürlich. Conversions. Du siehst also, es ist nicht zum Besten um unser sogenanntes Client-Side Tracking bestellt. Tracking im Browser ist laut, es ist langsam und es leckt an allen Ecken.

Und da kommt jetzt Server-Side Tracking ins Spiel. Die Idee dahinter ist eigentlich ganz simpel. Es ändert sich nur der letzte Schritt. Das Verschicken. Der Browser deines Besuchers schickt die Nachricht nicht mehr an Google, Meta, LinkedIn und die anderen, sondern an deinen eigenen Server.

Erst dein Server, also ein Rechner, den du kontrollierst, verteilt sie dann an Google, Meta und die anderen. Technisch sieht das meistens so aus. Du hast weiterhin einen Google Tag Manager auf deiner Website. Der normale, den du kennst. Aber der schickt seine Daten nicht mehr direkt an Google oder Meta, sondern an einen zweiten Tag Manager.

Einen Server-Container. Und der läuft auf deinem Server. Machen wir das mal ganz konkret. Mit einer Person, die gerade in deinem Shop einkauft. Nennen wir sie Lisa.

Lisa kauft Laufschuhe. Sie klickt auf Jetzt kaufen, zahlt, landet auf der Danke-Seite. Beim klassischen Tracking würden jetzt im Browser von Lisa vier, fünf Tags gleichzeitig loslegen. Jedes verschickt seine eigene Nachricht. Kauf, Laufschuhe, 129 Euro.

Mit Server-Side Tracking passiert stattdessen Folgendes. Aus Lisas Browser geht eine einzige Nachricht raus. An deinen Server. Da steht drin, Kauf, Laufschuhe, 129 Euro, Bestellnummer sowieso. In deinem Server-Container nimmt zuerst ein sogenannter Client diese Nachricht entgegen.

Der Client liest die Daten aus und bereitet sie so auf, dass die Tags im Server-Container damit arbeiten können. Und jedes dieser Tags ist für eine Plattform zuständig. Eins erstellt daraus eine Nachricht an GA4. Eins eine an Google Ads. Eins eine an Meta.

Jedes in dem Format, das die jeweilige Plattform haben will. Aus einer Nachricht werden also wieder vier. Aber eben nicht mehr auf Lisas Laptop, sondern auf deinem Server. Unter deiner Kontrolle. Und, ganz wichtig, dieser Server läuft idealerweise unter deiner eigenen Domain.

Also nicht irgendwas-google.com, sondern zum Beispiel daten.deinshop.de. Warum ist das wichtig? Weil der Browser deines Besuchers fremde Adressen strenger behandelt als die Website, auf der er gerade ist. Geht die Nachricht an deine eigene Domain, darf dein Server dort ein Cookie setzen, das länger hält. Und Adblocker, die nach bekannten Tracking-Adressen wie Google suchen, finden deine Adresse auf keiner ihrer Listen.

Aber wo steht dieser Server jetzt eigentlich physisch? Da gibt's im Grunde drei Möglichkeiten. Du kannst den Server-Container in der Google Cloud laufen lassen. Das ist der Weg, den Google selbst vorschlägt. Du kannst einen spezialisierten Anbieter nehmen, der dir das Hosting abnimmt und das Ganze für ein paar Dutzend Euro im Monat betreibt.

Oder du stellst das Ding auf einen eigenen Server, wenn du jemanden hast, der sich darum kümmert. Für die meisten Marketer ist der Anbieterweg der bequemste. Du musst dich nicht um Server, Updates und Skalierung kümmern. Aber du solltest wissen, wo dieser Anbieter seine Server stehen hat. Denn wenn dein Server am Ende in einem Rechenzentrum in Virginia steht, hast du datenschutzrechtlich ein ganz eigenes Kapitel aufgeschlagen.

Gut, du siehst jetzt, Server-Side Tracking scheint besser zu sein als das klassische Client-Side Tracking. Aber scheint besser zu sein ist nicht sehr aussagekräftig. Was genau bringt dir das jetzt konkret? Erstens, Kontrolle über die Daten. Und das ist für mich der wichtigste Punkt, auch wenn er auf LinkedIn am wenigsten Likes kriegt.

Auf deinem Server kannst du jede Nachricht öffnen, bevor sie rausgeht. Du kannst die IP-Adresse rausnehmen. Du kannst E-Mail-Adressen entfernen, die da versehentlich drinstehen. Du kannst entscheiden, dass Meta nur erfährt, dass gekauft wurde, aber nicht, was genau im Warenkorb lag. Das heißt, du entscheidest, welche Daten am Ende an die Werbekonzerne rausgehen.

Nicht sie. Beim klassischen Tracking im Browser kannst du das nicht. Da hat jeder Tracking-Code direkten Zugriff auf alles, was er sehen kann. Und was er mitnimmt, das entscheidet er, nicht du. Aber warte mal, das klingt jetzt komisch, oder?

Als Marketer willst du ja eigentlich mehr Daten, nicht weniger. Aber überleg mal, was du davon hast. Nimm die IP-Adresse. Die wird bei jeder Nachricht, die der Browser deines Besuchers verschickt, automatisch mitgeschickt. Sonst wüsste der Empfänger gar nicht, wohin er antworten soll.

Beim klassischen Tracking geht die Nachricht direkt an Google. Und Google kennt damit automatisch die IP deines Besuchers, ob du das willst oder nicht. So, jetzt habe ich mich echt lange über den ersten Vorteil von Server-Side Tracking ausgelassen. Dabei gibt es neben der Kontrolle über die Daten noch einige weitere wichtige Vorteile. Der zweite ist die Performance.

Weniger Skripte im Browser bedeuten, deine Seite wird schneller. Ich will jetzt aber nicht übertreiben. Deine Seite wird nicht in jedem Fall dramatisch, aber immerhin messbar schneller. Der dritte Vorteil? Die Cookies halten länger.

Wenn dein eigener Server unter deiner eigenen Domain ein Cookie setzt, dann ist das ein sogenanntes First-Party-Cookie, das vom Server kommt und nicht von einem JavaScript-Schnipsel. Und solche Cookies behandeln Browser wie Safari deutlich gnädiger. Dein Besucher wird also länger wiedererkannt. Dann haben wir noch einen vierten Vorteil. Adblocker können das schwerer blocken.

Viele Adblocker arbeiten mit Listen bekannter Adressen. Google, Meta, die üblichen Verdächtigen. Wenn dein Tracking aber an daten-punkt-deinshop-punkt-de geht, steht diese Adresse auf keiner Liste. Die Anfrage kommt also häufiger durch. Häufiger.

Nicht immer. Gute Blocker schauen inzwischen nicht nur auf die Adresse, sondern auch darauf, welches Skript da überhaupt geladen wird und wie die Anfrage aufgebaut ist. Das ist ein Katz-und-Maus-Spiel. Und das wird es auch bleiben. Und schließlich, fünftens, ein Punkt, den viele gar nicht auf dem Schirm haben.

Dein Server kann auch Daten an Google oder Meta schicken, die gar nicht aus dem Browser kommen. Nimm ein Beispiel. Ein Interessent füllt auf deiner Website ein Anfrageformular aus. Drei Wochen später trägt dein Vertrieb im CRM ein, dass daraus ein echter Auftrag geworden ist. Das passiert nicht im Browser.

Der Besucher ist längst nicht mehr auf deiner Seite. Aber dein Server kann diese Information trotzdem an Google Ads oder Meta melden. Und plötzlich optimieren deine Kampagnen nicht mehr auf ausgefüllte Formulare, sondern auf echten Umsatz. Das ist, wenn du mich fragst, der eigentlich spannende Teil von Server-Side Tracking. Nicht das Austricksen von Blockern, sondern dass du endlich die Daten melden kannst, die wirklich zählen.

Und wo wir gerade bei Meta sind, vielleicht hast du schon mal von der Conversions API gehört. Das ist genau dieser Weg. Eine offizielle Schnittstelle, über die Metadaten direkt von deinem Server annimmt, statt aus dem Browser deines Besuchers. Bei Google Ads geht das ebenfalls. Entweder über den Server-Container oder über den Import von Offline-Conversions.

Und hier lauert eine Falle, in die erstaunlich viele reintappen. In der Praxis lassen viele das Meta-Pixel im Browser einfach weiterlaufen und schicken zusätzlich die Daten über den Server. Das ist erstmal gar nicht verkehrt, weil der Browser manche Informationen hat, die der Server nicht hat. Und umgekehrt. Aber jetzt bekommt Meta für denselben Kauf zwei Meldungen.

Eine vom Meta-Pixel aus dem Browser deines Besuchers und eine von deinem Server. Und wenn du Meta nicht sagst, dass es derselbe Kauf ist, dann zählt Meta eben zwei Käufe. Und der Algorithmus optimiert fröhlich auf Zahlen, die es gar nicht gibt. Die Lösung heißt Deduplizierung. Klingt furchtbar, ist aber simpel.

Beide Meldungen bekommen dieselbe Ereignis ID, also eine eindeutige Nummer für genau diesen einen Kauf. Meta sieht dann zweimal die Ereignis ID 4711 und weiß, das ist ein und derselbe Kauf. Gezählt wird er nur einmal. Also, wenn nach der Umstellung auf Server-Side deine Conversions plötzlich durch die Decke gehen, freu dich nicht zu früh. Prüf erstmal, ob die Deduplizierung funktioniert.

So viel zum Thema, was ist Server-Side Tracking überhaupt? Hoffe, du bist schon überzeugt? Ja? Bevor du jetzt losrennst und alles unternimmst, um es auch bei dir umzusetzen, warte bitte noch einen Augenblick und hör weiter. Denn um das Thema haben sich auch ein paar Gerüchte festgefressen, die du kennen solltest, damit du nicht auf sie reinfällst.

Fangen wir mit dem größten Mythos an. Mit Server-Side Tracking brauchst du keinen Content mehr. Nein. Ganz klares Nein. Der DSGVO ist egal, ob die Daten direkt aus dem Browser deines Besuchers kommen oder über deinen Server.

Entscheidend ist, welche Daten verarbeitet werden und wer sie bekommt. Wenn du personenbezogene Daten an Google oder Meta weitergibst, brauchst du eine Rechtsgrundlage. Egal über welchen Weg. Dein Content-Banner bleibt also. Und dein Server-Container muss die Entscheidung des Besuchers genauso respektieren wie vorher die Tags im Browser.

Wer Server-Side Tracking als Trick verkauft, um den Content zu umgehen, der verkauft dir im Zweifel ein Bußgeldrisiko. Und das ist nicht als Anwalt gesprochen, das ist einfach gesunder Menschenverstand. Mythos Nummer 2. Mit Server-Side Tracking hast du wieder 100% deiner Daten. Auch Nein.

Denk dran, die erste Nachricht kommt immer noch aus dem Browser deines Besuchers. Irgendetwas muss ja erfassen, was er auf deiner Seite tut. Und wenn sein Browser oder sein Adblocker diese Nachricht blockiert, kommt auf deinem Server gar nichts an. Und was nicht ankommt, kann dein Server auch nicht weiterleiten. Server-Side Tracking holt dir also einen Teil der verlorenen Daten zurück.

Manchmal einen spürbaren Teil. Aber eben nicht alles. Und wer dir konkrete Prozentzahlen verspricht, ohne deine Seite, deine Zielgruppe und deinen Traffic zu kennen, der rät. Mythos Nummer 3. Das ist schnell eingerichtet.

Naja. Den Server-Container anlegen? Das geht tatsächlich in einer Stunde. Aber dann geht's los. Du brauchst einen Server.

Und der kostet Geld. Je nach Anbieter und Traffic sind das schnell ein paar Dutzend Euro im Monat, bei großen Shops auch deutlich mehr. Du brauchst die Subdomain, den DNS-Eintrag, das Zertifikat. Du musst jedes Tracking-Tag, das bisher im Browser lief, sauber im Server-Container nachbauen. Und du musst das Ganze warten.

Updates, Monitoring, Fehlersuche. Und die Fehlersuche, die wird nicht leichter. Erinnerst du dich an die Stationen aus der letzten Folge? Server, Browser, Tag Manager, Blocker, Architektur? Mit Server-Side Tracking hast du jetzt zwei Tag Manager.

Einen im Browser deines Besuchers und einen auf deinem Server. Also eine Stelle mehr, an der etwas schief gehen kann. Du bekommst also ein deutlich besseres System. Aber die bisherigen Fehlerquellen verschwinden dadurch nicht. Also, lohnt sich das Ganze jetzt?

Meine Einschätzung, für einen kleinen Blog mit ein paar hundert Besuchern im Monat? Eher nicht. Da steht der Aufwand in keinem Verhältnis. Für einen Shop oder ein Unternehmen, das ernsthaft Geld in Google Ads oder Meta steckt? Da sieht's anders aus.

Vor allem, wenn du die Chance nutzt, echte Geschäftsdaten zurückzumelden. Umsätze, abgeschlossene Deals, stornierte Bestellungen. Dann wird aus Server-Side Tracking nicht nur ein Reparaturwerkzeug, sondern ein echter Hebel für deine Kampagnen. Und ganz egal, wie du dich entscheidest, nimm dir eins mit. Server-Side Tracking ist kein Zaubertrick.

Es ist ein eigener Server zwischen dem Browser deines Besuchers und den Werbeplattformen. Und auf diesem Server entscheidest du selbst, welche Daten rausgehen und an wen. Und das ist, finde ich, schon eine ganze Menge. Aber eins hast du in dieser Folge vielleicht gemerkt. Egal wie gut dein Server eingerichtet ist, alles fängt im Browser deines Besuchers an.

Da läuft das Skript. Da liegen die Cookies. Da sitzt der Adblocker. Und wenn dort etwas schief geht, kann dein Server nichts mehr retten. Genau deshalb habe ich meinen Kurs Was passiert im Browser gemacht.

Dort gehe ich mit dir Schritt für Schritt jede Station durch, die nach einem Klick durchlaufen wird. Wie Cookies wirklich funktionieren. Was ein Skript im Browser darf und was nicht. Warum ein Tag feuert und trotzdem nichts ankommt. Was du davon hast?

Du erkennst Probleme mit deinen Kampagnen viel schneller. Wirst ein gutes Stück unabhängiger von der IT und kannst auf Augenhöhe mitreden, wenn dir das nächste Mal jemand Server-Side Tracking verkaufen will. Du merkst dann nämlich sofort, ob der weiß, wovon er redet. Schau es dir an, wenn du Lust darauf hast. Wenn nicht, hoffe ich, dass du zumindest Lust hast, in die nächste Folge reinzuhören.

Und wenn dir diese hier gefallen hat, erzähl es weiter. Am besten der Agentur, die dir gerade Server-Side Tracking als Wundermittel verkaufen will. Bis dahin einen schönen Tach auch und viele Grüße aus Berlin.