Trackdolphin

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.

text
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.