Warum "Server-Side-Tracking" trotzdem 25 % der Conversions an Adblocker verliert

Die meisten Setups, die mit "Server-Side" beschriftet sind, bootstrappen weiterhin von einer Drittanbieter-Domain im Browser. Filter-Listen holen jedes Pattern in Wochen ein, sobald es populär wird. Der Fix ist kein schnellerer Fallback, sondern Same-Origin ab dem ersten Byte.

Der "Server-Side"-Etikettenschwindel

"Server-Side-Tracking" klingt wie eine Beschreibung, wo der Dispatch passiert. In der Praxis beschreibt es fast immer, wo der Dispatch deklariert wird. Die echte Sequenz auf einer typischen "Server-Side"-Page sieht weiterhin so aus:

1. Browser lädt https://tags.kunde.com/gtm.js (ein Drittanbieter-Skript, auch wenn die Subdomain First-Party aussieht).
2. Das Skript feuert Events aus dem Browser, an denselben Drittanbieter-Endpoint adressiert.
3. Dieser Endpoint leitet das Event server-zu-server an Meta, Google, TikTok weiter.

Schritt 3 ist tatsächlich Server-Side. Aber Schritt 1 ist der Einstiegspunkt, und genau dort operiert jede Adblocker-Filter-Liste. Steht tags.kunde.com auf der Liste, lädt das Skript nie. Lädt das Skript nicht, feuert kein Event. Der Server-zu-Server-Forward ist irrelevant, weil nichts den Server erreicht.

Wie Filter-Listen wirklich funktionieren

EasyPrivacy und ähnliche Listen werden gemeinschaftlich gepflegt. Neue Tracking-Patterns werden gemeldet, geprüft und in Tagen, nicht Monaten ergänzt. Die Listen werden von uBlock Origin, Brave Shields, AdGuard, Pi-hole und anderen in einem 4-bis-24-Stunden-Refresh-Zyklus eingelesen. Bis ein Tracking-Pattern populär genug ist, um zu zählen, ist es auch populär genug, um gemeldet worden zu sein.

Die genauen Regeln variieren, aber typische Signaturen sind: bekannte Tracker-Subdomains (analytics., tags., track.), bekannte Drittanbieter-CDN-Pfade, erkennbare Skript-Content-Fingerabdrücke (Meta-Pixel, gtag.js, TikTok-Pixel-Bytes-Signaturen). Sobald ein Pattern auf eine dieser Regeln matched, wird der Request auf Netzwerk-Ebene verworfen, bevor er deinen Server erreicht.

Was das für "Server-Side"-Setups heißt: in dem Moment, in dem dein Pattern erkannt wird, sinkt deine Reichweite um genau die Adblock-Quote deiner Zielgruppe. Branchen-Schätzungen liegen bei 25 bis 30 Prozent im offenen Web, höher in B2B- und Dev-Audiences (35-50 Prozent), niedriger im Retail-Mainstream (15-20 Prozent).

Das Stape-DNS-Pattern

Stapes Lösung ist, eine Kunden-Subdomain wie tags.deinshop.de per CNAME auf einen Stape-gehosteten Worker zeigen zu lassen. Aus Browser-Sicht sieht der Request First-Party aus, er geht an deine Domain. Aus Adblocker-Sicht hängt es davon ab, ob die Filter-Liste den Pattern "tags.* CNAME-zeigt-auf-stape.io" erkennt.

Eine Weile lang ist das tatsächlich besser als das Drittanbieter-Domain-Pattern. Aber Filter-Listen-Pflege merkt das Pattern. CNAME-Cloaking-Detection ist eine bekannte Fähigkeit (Brave Shields hat es per Default an, uBlock als Opt-In, NextDNS macht es serverseitig). Sobald aktiviert, wird der Request auf derselben DNS-Ebene blockiert wie zuvor.

Stapes Antwort ist, Worker-Domains zu rotieren. Resultat ist ein Katz-und-Maus-Spiel, in dem jedes neue Stape-Pattern wenige Wochen Headroom bekommt, bis es auf den Listen landet. Kunden bleiben technisch erreichbar, aber die Varianz in der Adblock-Resistenz über die Zeit ist unangenehm für jeden, der Performance-Marketing-Kampagnen in Größe fährt.

Das GTM-Server-Side- / Cloud-Run-Pattern

Googles offizielle Server-Side-Antwort ist GTM Server-Side, typisch deployt auf Cloud Run mit einer kunden-eigenen Subdomain wie server.deinshop.de. Funktional ähnlich Stape, mit zwei praktischen Unterschieden: (a) du betreibst die Infrastruktur selbst (Cloud-Run-Preise, DNS, SSL-Erneuerung) und (b) du schreibst eigene Tag-Templates.

Adblock-Resistenz folgt derselben Dynamik wie Stape. Die Custom-Subdomain hilft eine Weile, CNAME-Cloaking-Detection holt es ein. Die zusätzlichen Kosten, $30 bis $500/Monat für den Cloud-Run-Container plus Engineering-Zeit für Tag-Templates, sind erheblich für einzelne Small-to-Mid-Kunden.

Was "First-Party ab dem ersten Byte" bedeutet

Der einzige Ausweg ist sicherzustellen, dass der allererste Request, den der Browser schickt, das Einstiegs-Skript, auf keiner Filter-Liste steht und kein Pattern hat, das wahrscheinlich auf einer landet.

"First-Party" in diesem starken Sinn heißt: Same-Origin mit der Page selbst, ausgeliefert von der WordPress-Installation des Kunden, auf einem Pfad, den der WordPress-Core für sein eigenes AJAX nutzt. Keine Subdomain, kein CNAME, kein Drittanbieter-CDN, keine erkennbare Skript-Content-Signatur.

Der ehrliche Test: Site in einem Browser mit aktiviertem uBlock Origin öffnen, eine Page besuchen, Network-Tab beobachten. Wenn du einen erfolgreichen POST-Request an einen Pfad auf deiner eigenen Domain siehst, funktioniert das Tracking. Wenn du einen fehlgeschlagenen Request an irgendeine andere Domain siehst, funktioniert das Tracking für Adblock-Nutzer auf diesem Kanal nicht.

Warum /wp-json/beaconry/v1/event Adblock strukturell ausweicht

Beaconrys Endpoint ist POST /wp-json/beaconry/v1/event auf deiner eigenen Domain. Drei Eigenschaften machen ihn strukturell adblock-resistent:

• Same-Origin: der Request geht an dieselbe Domain, von der die Page ausgeliefert wird. Keine Subdomain, kein CNAME.
• Generischer WP-REST-Namespace: /wp-json/ ist der Pfad, den WordPress-Core für seinen eigenen Block-Editor, Suche, Kommentare, "weitere Beiträge laden" und tausende Drittanbieter-Plugin-AJAX nutzt. Jede Filter-Liste, die /wp-json/ blockt, würde ein Viertel des öffentlichen WordPress-Webs lahmlegen.
• Custom-JSON-Payload: der Body ist Beaconrys eigene Form, nicht das Wire-Format von Meta-Pixel oder GA4 oder TikTok-Pixel. Inhaltsbasierte Filter-Regeln können ihn auch nicht als Tracking matchen.

Die Kombination ist, was es robust macht. Domain-basierte Regeln können /wp-json/ nicht pro Kundendomain matchen. Content-basierte Regeln können den Payload nicht erkennen. Die einzige Möglichkeit, ihn zu blocken, wäre eine generische "block all /wp-json/ POSTs"-Regel, die WordPress für jede Site, die es nutzt, kaputtmachen würde.

Zahlen

Das wiedergewonnene Conversion-Volumen ist genau die Adblock-Quote deiner Zielgruppe. Konkret:

• Ein B2B-SaaS-Site mit 1.000 Leads/Monat bei 100 € Lead-Wert, 35 % Adblock-Quote: ca. 350 Leads × 100 € = 35.000 €/Monat unsichtbar im Reporting.
• Ein Retail-E-Commerce-Shop mit 5.000 Bestellungen/Monat bei 60 € Durchschnitts-Order-Wert, 20 % Adblock-Quote: ca. 1.000 Bestellungen × 60 € = 60.000 €/Monat erreichen Meta oder Google nie zur Optimierung.
• Eine Media-Site mit 50.000 Newsletter-Anmeldungen/Monat bei 5 € LTV-attribuiertem Wert, 30 % Adblock-Quote: ca. 15.000 Anmeldungen × 5 € = 75.000 €/Monat still verloren.

Probier den Reichweiten-Rechner auf der Startseite mit deinen eigenen Zahlen. Die Zahl ist das, was deinem Reporting heute Monat für Monat unsichtbar bleibt, bis der Dispatch-Pfad weg von Drittanbieter-Tracker-Domains umgelegt wird.

Fazit

Das Label "Server-Side-Tracking" beschreibt, was nach dem Laden des Einstiegs-Skripts passiert. Adblock-Verlust passiert davor. Wenn dich die 25-30 Prozent Conversions interessieren, die du in Meta oder Google aktuell nicht siehst, ist die richtige Frage an jeden Anbieter nicht "ist euer Dispatch Server-Side?", sondern "an welche URL schickt der Browser den ersten Request?". Wenn die Antwort eine Subdomain, ein CNAME oder irgendeine Drittanbieter-Domain enthält, ist die Resilienz nur gemietet.