100 % Abdeckung — ein Weg für alle
Ein Tracking, das bei jedem fünften Besucher schweigt, optimiert die Kampagnen auf die falschen Leute. Deshalb hat Trackdolphin für jeden Shop denselben Anspruch: Jeder Kauf, dem der Käufer zugestimmt hat, kommt an — in jedem Browser, mit jedem Werbeblocker, auf jedem Gerät. Der Weg dorthin ist für alle Shops derselbe; nur die Umsetzung sieht je nach Plattform anders aus.
Die drei Gegner
Werbeblocker arbeiten mit Hostnamen-Listen. Ein Request an
connect.facebook.net, google-analytics.com oder auch an
irgendwas.trdph.com wird blockiert, sobald der Hostname auf einer Liste
steht — und Listen wachsen. Was auf keiner Liste stehen kann, ist die Domain
des Shops selbst: Wer die blockiert, blockiert den Shop.
Safari kürzt seit ITP 2.1 jedes per JavaScript gesetzte Cookie auf sieben
Tage — egal, welche Laufzeit das Skript anfragt. Seit 16.4 gilt dasselbe für
Cookies von Subdomains, die per CNAME auf fremde Infrastruktur zeigen. Der
Besucher, der heute über eine Anzeige kommt und in zwei Wochen kauft, ist dann
ein Unbekannter: Der Kauf zählt, die Zuordnung zur Anzeige fehlt. Nur ein
Cookie, das der eigene Server per Set-Cookie setzt, behält seine Laufzeit.
Einwilligung bleibt, wie sie ist. Trackdolphin umgeht kein Banner und erfindet keine Zustimmung. Wer Marketing ablehnt, bekommt keine Besucherkennung, und die Plattformen bekommen von ihm nur, was der Consent-Modus erlaubt. Das ist keine Lücke in der Abdeckung, sondern die Grenze, die „100 %“ meint.
Warum ein CNAME nicht reicht
Die verbreitete Antwort auf Werbeblocker ist eine eigene Tracking-Subdomain:
td.meinshop.de zeigt per CNAME auf den Collector. Gegen Hostnamen-Listen
hilft das — bis die Subdomain selbst auf einer Liste landet. Gegen Safari
hilft es seit 16.4 nicht mehr: Safari löst den CNAME auf, erkennt die fremde
Infrastruktur dahinter und behandelt die Cookies wie Third-Party. Sieben
Tage, wieder.
Was Safari nicht kappen kann, ist ein Request an dieselbe Herkunft, beantwortet von demselben Server, der auch die Seite ausliefert. Das ist kein Trick, sondern schlicht ein First-Party-Request. Werbeblocker sehen dabei nebenbei keinen fremden Hostnamen mehr.
Der eine Weg: dieselbe Herkunft
Der Browser spricht nur mit der Shop-Domain. Der Shop-Server nimmt die Events
entgegen, ergänzt Besucher-IP und User-Agent, setzt die Besucherkennung
per Set-Cookie und reicht alles an den Collector weiter. Der Kauf selbst
kommt ohnehin vom Server — aus der Bestellung, nicht aus dem Browser.
Browser ──► shop.de/…/collect ──► Shop-Server ──► Collector ──► Meta, Google, …
(dieselbe Herkunft) (Set-Cookie, (Dedup,
IP, User-Agent) Routing)Drei Ausprägungen, ein Prinzip:
Plugin-Shops: WooCommerce und Shopware
Schon eingebaut, nichts zu tun. Das Plugin läuft auf dem Shop-Server und
bringt die Route mit — bei WooCommerce /wp-json/td/v1/collect, bei Shopware
/td/collect. Das Snippet des Plugins schickt dorthin, der Server setzt
_td_vid und leitet weiter. Antwortet die Route einmal nicht (ein
Sicherheits-Plugin sperrt /wp-json), weicht das Snippet für die Sitzung
auf den direkten Collector aus — lieber ein Event ohne Tarnung als keins.
Shopify
Shopify erlaubt keine eigene Route auf der Shop-Domain — aber einen
App-Proxy: Shopify reicht Requests an einen Pfad unter der Shop-Domain
an die App weiter. Das Web Pixel schickt an https://deinshop.de/a/td/collect,
Shopify reicht das signiert an Trackdolphin weiter, und der Kauf kommt
ohnehin per Webhook von Shopifys Server. Der Händler richtet nichts ein: Der
Proxy kommt mit der App. Siehe Schnellstart
Shopify.
Headless: SvelteKit, Next.js, Nuxt, Astro, Remix
Das SDK bringt die Route mit — @trackdolphin/sdk/proxy ist ein
framework-neutraler Handler über Web-Standard Request/Response, den du
in einer Datei an deine Route hängst. Das Browser-SDK zeigt dann auf /td
statt auf den Collector. Beispiele für jedes Framework stehen auf der
SDK-Seite, der komplette Weg für SvelteKit im
Schnellstart SvelteKit.
Welcher Shop, welcher Weg
| Shop | Weg | Was du tun musst |
|---|---|---|
| WooCommerce | Plugin-Route /wp-json/td/v1/collect |
Nichts — Plugin installieren reicht |
| Shopware | Plugin-Route /td/collect |
Nichts — Plugin installieren reicht |
| Shopify | App-Proxy unter der Shop-Domain, Kauf per Webhook | Nichts — kommt mit der App; Kauf ist heute schon abgedeckt |
| SvelteKit, Next.js, Nuxt, Astro, Remix | Proxy-Route aus @trackdolphin/sdk/proxy |
Eine Datei anlegen, init({ endpoint: "/td" }) |
| Andere (Custom, PHP, …) | Eigene Route, die an den Collector weiterreicht — oder die direkte Collector-URL | Route nach dem Vorbild des SDK-Proxys bauen; sonst mit Blocker- und Safari-Verlust leben |
Was „100 %“ nicht heißt
- Nicht ohne Einwilligung. Wer Marketing ablehnt, wird nicht heimlich doch gemessen. Der Kauf wird gemeldet, aber ohne Kennungen — und je nach Einstellung gar nicht an die Werbeplattformen.
- Nicht ohne Server. Ein rein statisches Frontend ohne Server-Route hat nur die direkte Collector-URL. Das funktioniert, aber Werbeblocker und Safari holen sich dann ihren Anteil.
- Nicht rückwirkend. Besucher, deren Cookie Safari schon gekappt hat, bekommen beim nächsten Besuch eine neue Kennung. Ab da hält sie.
Die Abdeckung, die du tatsächlich erreichst, zeigt dir die Erkennungsquote nach dem Import der Historie — und der Wächter meldet, wenn sie einbricht.