Wie viel Ad Spend verbrennst du durch schlechtes Tracking?

Adblocker verstecken nicht nur Banner. Sie verhindern, dass Tracking-Scripts überhaupt laden: Das Pixel feuert nie, das Event existiert nicht, der Kauf ist passiert, aber kein Tool hat je davon erfahren. Das ist kein Randfall. Rund ein Drittel aller Web-Nutzer surft mit irgendeiner Form von Adblocking, und bei jungen, tech-affinen, einkommensstarken Zielgruppen, genau den Leuten, für deren Reichweite viele Marken am meisten zahlen, liegt der Anteil deutlich höher. Zusätzlich zu den klassischen Blockern blockieren inzwischen ganze Browser Tracker standardmäßig.

Fehlende Daten führen zu falscher Attribution, und falsche Attribution führt zu schlechten Entscheidungen. In der Attribution bekommen die Kanäle, über die deine geblockten Besucher kamen, zu wenig Credit, also verschiebst du Budget weg von Kampagnen, die eigentlich funktionieren, und zahlst doppelt: einmal für die Conversion, die du nicht sehen konntest, einmal für das Budget, das du an die falsche Stelle geschoben hast. In deinem E-Mail Marketing landen Besucher, die nie in dein Tracking kommen, auch nie in deinen Flows, also bleiben Segmente kleiner und getriggerte E-Mails ungesendet. Und bei deinen Postbacks optimieren die Ad-Plattformen auf die Conversions, die sie bekommen: Fütterst du sie mit 70 % der Realität, bieten ihre Algorithmen auf verzerrtes Signal, deine Audiences bleiben kleiner, und jede Learning-Phase dauert länger als nötig.

Selbst wenn ein Script lädt, entscheidet der Browser, wie lange ein Besucher wiedererkennbar bleibt. Safaris Intelligent Tracking Prevention (ITP) begrenzt Identifier, die per JavaScript gesetzt werden, auf sieben Tage. Auf iPhone und iPad reicht das weiter, als es zunächst aussieht: ITP ist auf Geräteebene in iOS eingebaut, gilt also in jedem Browser auf diesen Geräten, Chrome und Firefox unter iOS eingeschlossen, nicht nur in Safari. Auf einem Mac gilt es allein in Safari. Firefox’ Enhanced Tracking Protection isoliert bekannte Tracking-Identifier oder entfernt sie ganz. Rund ein Viertel deiner Besucher surft mit einer dieser Grenzen, und eine erteilte Cookie-Einwilligung ändert daran nichts, denn das sind Browser-Verhalten, keine Consent-Einstellungen.

Dieses Viertel ist ein webweiter Durchschnitt, also lies es als Richtwert. Ein Shop, dessen Kunden stark Richtung iPhone tendieren, kann deutlich darüber liegen, weil jeder dieser Besucher ITP mit sich trägt, egal welchen Browser er öffnet, und für diese Zielgruppen ist die Sieben-Tage-Grenze noch teurer, als der Durchschnitt vermuten lässt.

Identifikation ist der Punkt, an dem Attribution wirklich entschieden wird. Einen Kunden, der sich einloggt oder eine E-Mail eintippt, erkennst du leicht. Die Kunst ist alles davor: anonyme Besucher über Sessions und Geräte hinweg zu erkennen und zusammenzuführen, bis sie zu einem bekannten Kunden werden. Dieses Stitching läuft über Identifier, und Identifier sind nur nützlich, wenn du sie zuverlässig sammeln und am Leben halten kannst.

In der Praxis wird eine Customer Journey von einer Handvoll Identifier zusammengehalten: Click-IDs der Ad-Plattformen (gclid, fbclid, ttclid), die eine Session mit genau dem Ad-Klick verbinden; First-Party-Visitor-IDs in Cookies und localStorage, die Sessions untereinander verbinden; die E-Mail-Adresse und Telefonnummer, meist gehasht, die ein Profil mit dem CRM und den Match-Keys der Plattformen verbinden; Kunden- und Bestell-IDs aus deinem Shopsystem, die all das mit echtem Umsatz verbinden.

Es geht nicht um einen einzelnen Identifier. Es geht darum, sie jederzeit sammeln zu können. Eine Click-ID ist nur wertvoll, wenn sie zwei Wochen später beim Kauf noch mit der Visitor-ID verbunden ist. Eine E-Mail, die beim Checkout erfasst wird, ist für die Attribution nur wertvoll, wenn die anonymen Sessions davor erhalten geblieben sind und ihr rückwirkend zugeordnet werden können. Jeder Identifier, der zu früh abläuft oder nie gesammelt wird, ist ein gerissenes Glied in dieser Kette, und die Kette ist nur so stark wie ihr schwächstes Glied. Genau deshalb ist die Sieben-Tage-Grenze so viel teurer, als sie klingt: Sie löscht nicht ein Cookie, sie halbiert jede Journey, die länger als eine Woche dauert.

Manche Tools beantworten das Identifier-Problem mit Fingerprinting: Sie kombinieren Bildschirmgröße, Schriftarten, IP-Adresse und Dutzende weitere Signale zu einer wahrscheinlichkeitsbasierten Vermutung, dass zwei Sessions zur selben Person gehören. Klingt clever, ist aber eine Vermutung, und sie zerfällt. Fingerprints ändern sich mit jedem Browser-Update, jedem neuen Gerät, jedem Netzwerkwechsel. Browser randomisieren aktiv die Signale, auf die sich Fingerprinting stützt, und Aufsichtsbehörden behandeln es als die invasivste Form von Tracking, weshalb Blocklists fingerprinting-lastige Anbieter zuerst markieren. Eine Vermutung, die zu 80 % stimmt, klingt okay, bis dir klar wird, dass sie stillschweigend verschiedene Personen zusammenführt und echte Kunden in Fremde aufspaltet, und du nicht prüfen kannst, was davon was ist. Fingerprinting kann Identity-Resolution am Rand unterstützen. Das Rückgrat kann es nicht sein. Das Rückgrat muss deterministisch sein: Identifier, die du selbst setzt, besitzt und behältst.

‚First-Party-Tracking’ ist zum Label geworden, das jeder Anbieter für sich beansprucht, aber die Unterschiede darunter entscheiden, ob deine Daten wirklich überleben. Ein Script, das von deiner eigenen Domain ausgeliefert wird, wird trotzdem entfernt, wenn das Domain-Muster, an das es weiterleitet, öffentlich bekannt ist. Eine First-Party-Subdomain, die nur ein dünner Alias für den Server eines Anbieters ist, ist für Browser durchschaubar, die auflösen, wohin der Traffic wirklich geht, und Safari begrenzt über solche Konstruktionen gesetzte Cookies ohnehin auf sieben Tage. Und ein per JavaScript gesetzter Identifier wird auf sieben Tage begrenzt, egal wie First-Party die Domain aussieht.

Echte Resilienz braucht alle drei Layer gleichzeitig: Erfassung auf Infrastruktur, die wirklich dir gehört, Identifier, die server-side gesetzt werden, damit Browser-Grenzen nicht greifen, und Identity-Stitching, das auf dem Server passiert, wo kein Blocker und keine Browser-Policy herankommt. Das ist der Unterschied zwischen First-Party als Marketing-Label und First-Party als Architektur. Dein Scan zeigt den Unterschied in der Praxis: Tools mit dem Label verlieren trotzdem ein Viertel ihrer Daten, Tools mit der Architektur verlieren nichts.

Wir öffnen deine Seite in einem echten Browser, zeichnen jeden Network-Request und jedes Cookie auf, akzeptieren das Consent-Banner und zeichnen erneut auf. Kein Raten aus statischem HTML: Der Report zeigt, was für einen echten Besucher tatsächlich feuert.

Jeder erkannte Tracker wird gegen das Verhalten der großen Adblocker und die Identity-Grenzen in Safari und Firefox geprüft, damit du siehst, welchen Anteil an Besuchern jeder Tracker verliert und wo Identifier vorzeitig gekappt werden.

Die Ergebnisse fließen in drei Kategorie-Scores für Attribution, E-Mail-Marketing und Postbacks zusammen, plus einen Gesamt-Score von 0 bis 100. Jede Kategorie gewichtet, wie viele Daten ihre Tracker verlieren und wie gut sie wiederkehrende Besucher erkennen können.

Jedes ‚~X % der Nutzer’ neben einem Blocker oder Browser ist der Anteil dieses Tools an allen Web-Nutzern, aus öffentlichen Adblocker- und Browser-Nutzungsdaten, nicht ein Anteil deiner eigenen Besucher. Wenn ein Tool einen Tracker blockiert, verliert ihn jeder Besucher, der dieses Tool nutzt, also summieren sich diese Anteile zu dem potenziellen Datenverlust, den wir für den Tracker anzeigen.

Weil es Durchschnittswerte sind, sind die Zahlen eher Richtwerte als exakt, deshalb kennzeichnen wir sie als potenziellen Verlust. Deine echte Verteilung hängt von deiner Zielgruppe und Branche ab: Eine Zielgruppe mit vielen Adblocker- oder iPhone-Nutzern verliert mehr als der Durchschnitt, eine Mainstream-Zielgruppe kann weniger verlieren. Vor allem der iOS-Wert schwankt stark nach Branche, da ITP für jeden Browser auf iPhone und iPad gilt, nicht nur für Safari.

Ja. Der Checker lädt eine öffentliche Seite genauso, wie es der Browser eines normalen Besuchers täte, und schaut nur auf das, was die Seite selbst sendet: Scripts, Requests und Cookies. Nichts wird über einen kurzlebigen Ergebnis-Cache hinaus gespeichert, und von der gescannten Seite werden keine personenbezogenen Daten erfasst.