Warum die meisten Ad- und Conversion-Tracking-Tools nicht funktionieren

E-Commerce-Marken, Betreiber und Performance-Marketer geben jedes Jahr Millionen für Werbung und Tausende für Tracking- und Attribution-Tools aus. Die meisten dieser Tools verpassen 30 % oder mehr der Sessions, die sie messen sollen.

Das ist kein Attributionsproblem. Es ist ein Tracking-Problem, und die meisten Teams merken es nicht, weil beide vermischt werden.

Tracking ist nicht Attribution

Tracking ist der Moment, in dem ein Skript im Browser eines Nutzers feuert und Daten schreibt, entweder auf deine Server oder auf das Gerät des Nutzers. Alles Nachgelagerte hängt an diesem einen Event. Attribution. Conversions-API-Feedback an Meta, Google, TikTok. Klaviyo-Warenkorbabbruch-Flows. A/B-Test-Ergebnisse. Onsite-Verhaltensanalytics.

Feuert das Skript nicht, existiert nichts davon. Der Nutzer ist unsichtbar. Die Session hat in deinen Daten nie stattgefunden.

Attribution ist die Ebene, auf der du entscheidest, welcher Touchpoint den Credit für eine Conversion verdient. Das ist ein Modellierungsproblem, und ein schweres. Aber jedes Attributionsmodell der Welt beginnt bei den Daten, die das Tracking erfasst hat. Hat das Tracking 60 % der Sessions erfasst, läuft deine Attribution auf 60 % der Realität. Da modellierst du dich nicht heraus.

Das ist der Teil, der in jedem Anbieter-Pitch untergeht. Die meisten Attribution-Tools reden über Modellierungslogik, Identity Graphs, Walled-Garden-Abgleich. Wichtige Arbeit. Aber all das sitzt auf dem Tracking, und ist das Tracking löchrig, ist der Rest Theater.

Technische Hürden für Ad- und Conversion-Tracking

Der Anteil der Nutzer, die in einer Umgebung mit Tracking-Prävention surfen, ist größer, als die meisten Teams annehmen. Zwei Kategorien führen zum selben Ergebnis: die Tracking-Prävention, die der Browser selbst mitbringt, und Ad-Blocker-Erweiterungen, die Nutzer obendrauf installieren.

Tracking-Prävention im Browser

Vier große Browser liefern standardmäßig eine Form von Tracking-Prävention aus. Der Mechanismus ist jeweils anders, aber der Effekt auf das Tracking-Skript eines typischen Anbieters ist derselbe: Requests verworfen, Cookies gekappt, besuchsübergreifende Wiedererkennung zusammengebrochen.

1. Safari Intelligent Tracking Protection (ITP). In jeder Safari-Installation standardmäßig an. Nutzt algorithmische Erkennung von Cross-Site-Trackern, keine öffentliche Blocklist. ITP kann ein Skript erwischen, das keine Blocklist markiert hat.

2. Firefox Enhanced Tracking Protection (ETP). In jeder Firefox-Installation standardmäßig an. Nutzt die Disconnect.me-Blocklist.

3. Brave Shields. Fest im Brave-Browser eingebaut. Nutzt mehrere öffentliche Filterlisten. Standardmäßig der aggressivste der vier.

4. Microsoft Edge Tracking Prevention. Edge liefert Tracking-Prävention standardmäßig auf der Stufe „Ausgewogen“ aus und nutzt Microsofts Trust Protection Lists. Der leichteste der vier, blockiert aber trotzdem bekannte Third-Party-Tracker für Nutzer, die ihre Einstellungen nie anpassen.

Die Tabelle unten zeigt, was jede Umgebung mit einem Tracking-Skript und den Cookies macht, die es setzt.

Quelle: cookiestatus.com, die Referenz für die Specs von Ad-Blockern und Browser-Tracking-Prävention.

Safari ist die Zeile, auf die es ankommt. Die anderen drei stützen sich auf öffentliche Blocklists, die eine saubere Domain umgehen kann. Safaris ITP nutzt stattdessen algorithmische Erkennung: Selbst ein blocklist-immunes Setup kann markiert werden, wenn ein Anbieter dasselbe Tracking-Skript über Tausende Kunden-Websites ausliefert. ITP erkennt das Cross-Site-Muster und fängt an, es einzuschränken. Und das 7-Tage-Cookie-Limit bei erkanntem Cloaking lässt die besuchsübergreifende Wiedererkennung still zusammenbrechen, selbst im First-Party-Kontext, sobald irgendein Anbieter-Fingerabdruck in der Domain auftaucht.

Browser-Verbreitung laut StatCounter, April 2026:

• Weltweit, alle Geräte: Chrome 68 %, Safari 17 %, Firefox 2 %.
• Weltweit, mobil: Safari macht 26 % der mobilen Sessions aus, nur geschlagen von Chrome mit 66 %.
• Deutschland, alle Geräte: Chrome 51 %, Safari 19 %, Firefox 10 %, Edge 9 %. Safari und Firefox zusammen machen ~29 % des deutschen Traffics aus.
• Deutschland, mobil: Safari macht 30 % der mobilen Sessions aus. Firefox weitere 3 %.

Ad-Blocker

Zusätzlich zur Prävention auf Browser-Ebene installiert ein nennenswerter Anteil der Nutzer Ad-Blocker-Erweiterungen, die dieselbe Infrastruktur blockieren. Die häufigsten:

• uBlock Origin (Open Source, dominant auf Firefox und Chrome)
• Ghostery (datenschutzfokussiert, tracker-bewusst)
• AdBlock Plus (historisch das meistinstallierte, vor allem auf Chrome)
• AdGuard (plattformübergreifend, systemweites Blocking)
• Disconnect (zugleich die Quelle der Blocklist, die in Mozilla-Produkten steckt)

Rund 30 % weltweit und 31,5 % in Deutschland der Internetnutzer setzen einen ein (GWI, Q2 2025). Der Anteil ist höher unter dem technisch versierten Publikum, das die meisten DTC-Marken eigentlich erreichen wollen.

Alle diese (und Firefox ETP und Brave Shields ebenso) arbeiten unter der Haube gleich: öffentliche Blocklists. Du kannst sie selbst nachlesen. cookiestatus.com ist ein Startpunkt. Die Listen sind lang, öffentlich und werden aggressiv gepflegt. Domains und URL-Fragmente, die mit bekannter Tracking-Infrastruktur verknüpft sind, werden ergänzt. Browser und Erweiterungen greifen auf die Listen zu und blockieren passende Requests.

Daraus folgen zwei Dinge.

Erstens zielen die Listen auf Third-Party-Domains. Sie identifizieren Infrastruktur, die über viele Websites geteilt wird. Deine eigene, kundenseitige Domain, die die Nutzer in die Adressleiste getippt haben, steht per Definition nicht auf der Liste. Sie kann es nicht. Sie zu blockieren hieße, die Website zu blockieren, die der Nutzer gerade aufrufen wollte.

Zweitens arbeiten die Listen mit Pattern-Matching, nicht nur mit exakten Treffern. Lädt dein Tracking-Skript von einer Domain mit erkennbaren Zeichenketten (einem Anbieternamen, gängigen Tracker-Mustern), ist sie ein Kandidat für die Liste, selbst wenn die konkrete Subdomain neu ist.

Das ist die vollständige Antwort auf „Warum verpasst mein Tracking 30 % meines Traffics.“ Anbieter betreiben ihre Skripte von Domains, die sie kontrollieren. Diese Domains landen auf Blocklists. Die Skripte werden blockiert. Der Traffic verschwindet aus deinen Reports.

Selbst nach Abzug der Überschneidung (Safari- und Firefox-Nutzer, die zusätzlich Ad-Blocker einsetzen) liegt der kombinierte Anteil der Sessions, die durch mindestens eine Umgebung mit Tracking-Prävention laufen, bequem über 30 % weltweit und um die 50 % in Deutschland und ähnlichen datenschutzbewussten Märkten. Das ist der Anteil deiner Besucher, deren Browser aktiv die Datenerhebung verhindern, auf die dein Stack angewiesen ist.

Regulatorische Hürde beim User-Tracking

Die DSGVO und § 25 TDDDG (der Nachfolger des deutschen TTDSG) machen User-Tracking mit der Absicht, jemanden über Besuche hinweg wiederzuerkennen, einwilligungspflichtig. Keine Ausnahmen. Keine cleveren Workarounds. Ein Nutzer, der die Einwilligung ablehnt, ist für die langfristige Wiedererkennung nicht trackbar, Punkt.

Jeder Attribution-Anbieter sitzt hier im selben Boot wie Meta und Google. Kein Anbieter löst das regulatorische Problem. Die Unterschiede zwischen den Anbietern sind hier null.

Das ist wichtig, weil es der Teil des Gesprächs ist, der in Sales-Calls die meiste Zeit bekommt, und zugleich der Teil, in dem niemand einen Vorteil hat. Weiter.

Worauf gutes Tracking hinausläuft

Nimm die Marketing-Schicht weg, und gutes Tracking läuft auf eine Frage hinaus:

In wie vielen Browser-Umgebungen feuert dein Tracking-Skript wirklich und speichert Daten dauerhaft?

Das ist alles. Nicht „ist es serverseitig“. Nicht „ist es First-Party“. Nicht „hast du einen Conversions-API-Connector“. Nur: Läuft das Skript, und überleben die Daten, die es schreibt, lange genug, um zu zählen.

Die eine Frage, die jeden Anbieter-Pitch durchschneidet

Vergiss jede andere Einrahmung. „Server-Side-Tracking“ nützt nichts, wenn das clientseitige Skript, das das serverseitige Event auslöst, blockiert ist. „First-Party-Kontext“ nützt nichts, wenn die Umsetzung die Daten weiterhin über eine Anbieter-Subdomain leitet, die per Pattern-Matching auf einer Blocklist landet. „Fingerprinting“ nützt nichts, wenn das Skript, das die Browser-Merkmale sammelt, gar nicht erst läuft.

CNAME-Cloaking, bei dem ein Anbieter einen CNAME-Record wie track.deinemarke.de auf tracking.anbieter.com zeigen lässt, sieht oberflächlich First-Party aus. In der Praxis fliegt es trotzdem oft auf:

1. Steht tracking.anbieter.com oder seine übergeordnete Domain auf einer Blocklist, fliegt die Auflösung auf.
2. Enthält die Subdomain, die du anlegst, weiterhin den Anbieternamen (etwa anbieter-tracking.deinemarke.de), erwischt sie das Pattern-Matching.
3. Safaris ITP bestraft erkennbares CNAME-Cloaking gezielt mit einem 7-Tage-Cookie-Limit statt der üblichen 400 Tage. Die besuchsübergreifende Wiedererkennung bricht zusammen.

Der eine Test, der alle Anbieter-Pitches durchschneidet:

Lädt das Tracking-Skript von einer URL auf einer Domain, die dir wirklich gehört und die du anderswo nutzt, ohne irgendwo im Domainnamen einen Anbieternamen?

Falls ja, gehörst du zur kleinen Minderheit der Setups, die über die >50 % der Umgebungen mit Blocking-Technik hinweg feuern.

Falls nein, verlierst du Daten. Der genaue Prozentsatz hängt von deinem Traffic-Mix ab, aber 20 bis 40 % Session-Verlust ist der realistische Bereich für die meisten DTC-Marken.

Die Shopify-Falle, über die niemand spricht

Speziell für Shopify-Händler gibt es eine besonders scharfe Variante davon, die enorm viele Marken erwischt.

Shopify bietet zwei Stellen, um Tracking-Skripte zu installieren:

• Den <head> des Themes, der Skripte von der Domain lädt, auf die du sie zeigen lässt.
• Customer-Events-Pixel, die innerhalb von Shopifys Pixel-Infrastruktur laufen.

Customer-Events-Pixel sind bequem. Sie fühlen sich wie der „richtige“ Weg an, Tracking 2025 zu installieren. Sie werden aber über Shopifys Pixel-Domains geleitet, die auf Blocklists stehen. Ist ein Customer-Events-Pixel dein einziger Installationspunkt, ist dein Tracking für die Mehrheit der Nutzer blockiert.

Viele Anbieter empfehlen Customer Events klammheimlich als primäre Installation, weil es ihre Time-to-Live verkürzt. Der versteckte Preis: Die Daten, die du zu erheben beginnst, sind deutlich löchriger als das, was derselbe Anbieter über eine saubere Theme-Header-Installation auf einer kundeneigenen Domain liefern würde.

Wie du es selbst in fünf Minuten testest

Öffne die Doku des Anbieters oder sieh dir seine Referenzkunden auf der Website an und prüfe, von welchen Domains ihre Skripte laden. Wenn du dich nicht durch die Doku wühlen willst, füg sie in einen AI-Assistenten ein, mit der Frage „von welchen Domains lädt das Tracking-Skript dieses Anbieters in Produktion“. Die Antwort bekommst du in Sekunden.

Installiere einen Ad-Blocker (Ghostery, uBlock Origin, irgendeinen gängigen) in einem sauberen Browser-Profil. Besuche eine der Referenzkunden-Websites des Anbieters. Öffne die DevTools, geh zum Network-Tab, filtere nach der Domain des Anbieters.

Du siehst eines von zwei Dingen:

• Rote X neben den Tracking-Requests. Das Skript wird blockiert. Der Anbieter verliert diesen Nutzer.
• Grüne Statuscodes. Das Skript feuert. Der Anbieter erfasst diesen Nutzer.

Schalte den Ad-Blocker ab und lade neu. Die blockierten Requests sollten feuern. Schalte ihn wieder an, und sie stoppen erneut. Das ist dein A/B-Test.

Wiederhole es in Brave für die strengste mögliche Umgebung. Wiederhole es in Safari und prüfe unter Application → Storage → Cookies, wie die Cookie-Abläufe in der Praxis tatsächlich aussehen.

Wenn ein Vertriebsmitarbeiter des Anbieters dir die genaue Domain, von der sein Skript lädt, nicht nennen kann oder will, ist das schon die Antwort.

Was du gewinnst, wenn das Tracking sauber ist

Die Zahlen hebeln sich durch den ganzen Stack:

• 20 bis 40 % mehr erfasste Sessions, der direkte Kehrwert der Blockraten oben.
• 20 bis 30 % mehr Conversions, die über die Conversions API an die Ad-Plattformen zurückgemeldet werden. Meta, Google, TikTok, Taboola, Outbrain. Mehr Signal bedeutet besseres Bidding, bessere Lookalikes, niedrigere CACs.
• 20 bis 30 % mehr ausgelöste Abbruch- und Verhaltens-Flows in Klaviyo oder deinem CRM, weil die User-Events, die sie auslösen, jetzt sichtbar sind.
• Sauberere A/B-Test-Auswertungen, weil die meisten Test-Tools (VWO, Chameleon und Ähnliche) ebenfalls im Third-Party-Kontext arbeiten und denselben Traffic-Anteil verpassen. Fahr deine Tests über sauberes Tracking, und die Varianz sinkt.
• Ehrliche Onsite-Analytics, bei denen der Funnel die tatsächliche Nutzerbasis abbildet statt nur die Teilmenge, deren Browser das Tracking-Skript zulässt.

Das ist der Hebel, den Anbieter-Pitches überspielen. Attributionsmodellierung, Identity Resolution, Walled-Garden-Abgleich: Jedes dieser Probleme ist real und lohnt sich zu lösen. Aber sie alle bauen auf dem Tracking auf. Ein Datenverlust von 40 % im Fundament lässt sich nicht durch clevere Logik obendrauf wegmodellieren.

Was wir bei adtribute bauen

Die Tracking-Schicht baut auf einem einzigen Prinzip: Das Skript lädt von einer Domain, die dem Kunden gehört, ohne Anbieter-Fingerabdruck in der Subdomain. Kein CNAME-Cloaking, das auf ein adtribute.io-Elternteil zurückverweist. Keine geteilte Third-Party-Infrastruktur, die nach einem Jahr Wachstum auf einer öffentlichen Blocklist landet.

Dieses Setup ist für Blocklists unsichtbar, weil es gar nicht auf einer landen kann. Aus demselben Grund ist es für Brave unsichtbar. Es fährt volle 400-Tage-Cookies in Safari, weil es ein echter First-Party-Kontext ist, kein getarnter. Das Ergebnis ist der Kehrwert der Verlustzahlen oben: 20 bis 40 % mehr getrackte Sessions, als dieselbe Marke auf einem typischen aufgesetzten Stack sähe.

Identity Resolution und Attribution sitzen darauf. Beide zählen. Beide sind leichter, wenn die Basisebene ehrlich ist über das, was sie sehen kann.

Cookies, Fingerprinting, serverseitige Relays, Post-Purchase-Surveys: All das sind nachgelagerte Identitätstechniken. Sie arbeiten mit dem, was das Tracking-Skript erfasst hat. Ist die Erfassungsrate löchrig, erbt jede davon dieses Leck.

Die Frage an deinen jetzigen Anbieter

Eine Frage, an deinen Account Manager geschickt:

Kannst du mir die genaue URL zeigen, von der mein Tracking-Skript in Produktion lädt? Und: Steht diese Domain auf EasyList, EasyPrivacy oder Disconnect?

Die Antwort sagt dir fast alles, was du wissen musst, wie viel deines Traffics dein jetziger Stack tatsächlich erfasst.

Ist die Antwort unbequem, ist der richtige Schritt nicht, das Attributionsmodell zu wechseln. Sondern zuerst das Tracking zu reparieren.