Beaconry vs Stape vs GTM Server-Side: gleiches Ergebnis, sehr unterschiedliche Mechanik

Alle drei behaupten "Server-Side-Tracking". Alle drei landen mit unterschiedlicher Adblock-Resistenz, unterschiedlichem DNS-Setup, unterschiedlichen Monatsrechnungen. Side-by-side Teardown des Dispatch-Pfads bei jedem, plus wann eine der anderen zwei wirklich die bessere Wahl ist.

Die drei Dispatch-Pfade

Jedes Tool endet letztlich am gleichen Set von Plattform-APIs (Meta CAPI, Google Ads API, GA4 Measurement Protocol, etc.). Die Unterschiede liegen ausschließlich auf dem Pfad zwischen Browser und diesem Endpoint.

• Beaconry: Browser POSTet an /wp-json/beaconry/v1/event auf der eigenen WordPress-Installation des Kunden. WordPress dispatched server-zu-server an die Plattformen.
• Stape: Browser lädt https://tags.kunde.de/gtm.js, ein CNAME auf einen Stape-gehosteten Worker. Stapes Worker leitet Events durch Tag-Templates und dispatched.
• GTM Server-Side: Browser lädt https://server.kunde.de/gtm.js, ein CNAME (oder A-Record) auf einen Cloud-Run-Container, den der Kunde selbst betreibt. Container führt Tag-Templates aus und dispatched.

Adblock-Resistenz

Der einzige folgenreichste Unterschied, und der, der in Vergleichs-Decks am häufigsten überspielt wird:

• Beaconry: strukturell adblock-immun. /wp-json/ ist der WordPress-Core-REST-Namespace; ihn zu blocken würde WordPress selbst kaputt machen. Getestet gegen uBlock Origin, Brave Shields, AdGuard, NextDNS, Pi-hole, alle lassen es durch. Custom-JSON-Payload, keine erkennbare Pixel-Format-Signatur.
• Stape: anfällig für CNAME-Cloaking-Detection. Brave Shields hat es per Default an, uBlock als Opt-In, NextDNS macht es serverseitig. Filter-Listen-Pfleger ergänzen Stape-Pattern-Detection mit der Zeit. Das Katz-und-Maus-Spiel führt dazu, dass Stape Worker-Domains rotiert, mit wenigen Wochen Vorsprung pro Zyklus. Behandle es als "läuft meistens", nicht "läuft".
• GTM Server-Side: gleiche Dynamik wie Stape, plus der GTM-Browser-seitige gtm.js-Bytecode wird selbst von einigen content-basierten Filter-Regeln erkannt. CNAME versteckt das Ziel, Content-Fingerabdruck kann es trotzdem aufdecken.

Konkrete Auswirkung: eine B2B-Audience mit 35 % Adblock-Quote sieht grob 5-15 % Conversion-Verlust auf Stape/GTM SS über ein Quartal, abhängig von Filter-Listen-Update-Zyklen. Beaconrys Zahl bleibt im selben Fenster nahe Null.

Setup-Zeit

• Beaconry: Plugin installieren, Credentials einfügen, Test-Events senden. Live in 15 bis 30 Minuten pro Kanal. Fünf Kanäle (Meta, TikTok, Google Ads, LinkedIn, GA4) brauchen typisch einen Nachmittag, um sauber verdrahtet zu sein.
• Stape: Signup, CNAME auf Stape zeigen, Tag-Templates in Stapes UI konfigurieren, Test-Events senden. 2 bis 4 Stunden für ein typisches Setup, mehr wenn deine Tag-Template-Logik nicht-Standard ist.
• GTM Server-Side: GCP-Projekt provisionieren, Cloud-Run-Container deployen, DNS konfigurieren, SSL aufsetzen, Tag-Templates in GTM schreiben, testen. 1 bis 3 Tage für ein typisches Setup, Tage mehr wenn dein Team nicht bereits GCP-fluent ist.

Preise

• Beaconry: einmalige Lizenz. Solo $69, Studio $149, Agency $349. Lifetime-Updates inklusive. Keine gemeterte Nutzung, keine Kosten pro Event.
• Stape: monatliches Abo, skaliert mit Traffic. Kleinster Plan ist um $20-30/Monat für begrenztes Volumen. Mid-Traffic-Sites landen bei $50-100/Monat. High-Traffic bei $100-300/Monat.
• GTM Server-Side: Cloud-Run-Pricing, skaliert mit Request-Volumen. Low-Traffic-Sites $30-50/Monat, Mid-Traffic $100-300/Monat, High-Traffic $500+/Monat. Plus Engineering-Zeit für die Pflege des Cloud-Run-Containers, Tag-Templates, Container-Updates.

Total Cost of Ownership über 3 Jahre auf einer Mid-Traffic-Site: Beaconry $149, Stape ca. $2.500, GTM SS ca. $5.000+ (Cloud Run + Wartungszeit). Die Headline-Preisspanne ist real; die Engineering-Zeit-Spanne bei GTM SS ist größer, als sie auf der Rechnung aussieht.

Tag-Template-Engine und Customisation

Hier kippt der Vergleich. Beaconry hat keine Tag-Template-Engine: es kommt mit hardcoded Support für Meta, TikTok, Google Ads, LinkedIn, GA4 plus WooCommerce-/Kadence-/Fluent-Hooks. Fünf Kanäle, opinionated Mapping. Einen sechsten Kanal hinzufügen heißt Plugin-Update, keine kundenseitige Template-Änderung.

• Beaconry: opinionated, schnell aufzusetzen, keine Template-Sprache zu lernen. Falsche Wahl, wenn du Custom-Tags für ein Nischen-Werbenetzwerk oder einen Custom-Analytics-Endpoint brauchst.
• Stape: volle GTM-kompatible Template-Engine in ihrer UI. Reichhaltige Bibliothek vorgefertigter Templates. Custom-Templates mit gesandboxtem JavaScript baubar. Richtige Wahl, wenn du viele Custom-Tags brauchst.
• GTM Server-Side: gleiche Template-Engine wie Stape (beide sind GTM unter der Haube), plus du kontrollierst den Container und kannst Custom-Code-Pfade hinzufügen. Richtige Wahl bei maximaler Flexibilität und Engineering-Kapazität.

Multi-Tenant-Agentur-Szenarien

Agenturen, die Tracking für viele Kunden fahren, treffen unterschiedliche Entscheidungen:

• Beaconry Agency-Tier: $349 einmalig, unbegrenzte Kunden-Site-Aktivierungen. Jede Kunden-WP hält ihre eigenen Credentials. Separate WP-Installationen = separate Seats gezählt. Richtige Wahl, wenn Kunden überwiegend WordPress sind und die Agentur planbare Kosten will.
• Stape: Pro-Kunde-Abo, Agenturen verkaufen oft mit Marge an Kunden weiter. Richtige Wahl, wenn Kunden Nicht-WordPress sind oder die Agentur Tag-Management über diverse Stacks zentralisieren will.
• GTM Server-Side: jeder Kunde besitzt typisch sein eigenes GCP-Projekt und Cloud Run. Agentur betreibt sie, zahlt sie aber meist nicht. Richtige Wahl für High-Touch-Enterprise-Consulting-Engagements.

Nicht-WordPress-Stacks

Beaconry ist von Architektur WordPress-only. Der Same-Origin-REST-Endpoint ist /wp-json/..., den nur WordPress ausliefert. Wenn dein Stack Shopify, Webflow, Custom-Node.js ist, alles was nicht WordPress ist, funktioniert Beaconry nicht für dich.

• Shopify mit Server-Side-Tracking: Stape hat Shopify-spezifische Tools, GTM SS funktioniert, braucht aber Custom-Integration.
• Webflow / Squarespace / Wix: GTM SS via Cloud Run, Stape wenn ihre Integration deine Plattform abdeckt.
• Custom Node.js / Rails / Django: GTM SS oder Self-Built. Stape, wenn ihr Template passt.
• Headless Commerce + Next.js / Astro: hängt vom Back-End ab. Wenn WordPress die headless Quelle ist, kann Beaconry auf der WP-Seite sitzen und von dort dispatchen.

Wann NICHT Beaconry wählen

Konkrete Fälle, in denen eines der anderen zwei wirklich die bessere Wahl ist:

• Dein Stack ist nicht WordPress.
• Du brauchst Custom-Tag-Templates für einen Nischen-Kanal, den Beaconry nicht ausliefert.
• Du brauchst eine UI, damit Nicht-Engineering-Teammitglieder Tracking ergänzen und ändern können, ohne Plugin-Update.
• Du hast bereits ein laufendes GTM-Server-Side-Setup, und die Migrationskosten überwiegen die Beaconry-Ersparnis.
• Du bist ein Enterprise mit dediziertem Tracking-Engineering-Team und willst maximale Kontrolle.

Migrations-Pfade

Wenn du dich entscheidest, zu Beaconry zu wechseln, hängen die Migrations-Schritte davon ab, was du verlässt:

Von Stape: Beaconry installieren, dieselben fünf Kanäle mit den schon vorhandenen Credentials konfigurieren. Eine Woche parallel laufen lassen, mit Hybrid-Modus aus auf Beaconry, die Plattform-Reports beobachten, Beaconrys Volumen sollte Stapes erreichen oder übertreffen. Wenn das Vertrauen da ist, den Stape-CNAME entfernen und die Stape-Tag-Templates deaktivieren. Kein Datenverlust, kein historischer Attributions-Verlust (die plattformseitige Historie gehört der Plattform, nicht dem Dispatch-Tool).

Von GTM Server-Side: gleicher Parallel-Run-Ansatz. Cloud Run für den Parallel-Zeitraum am Leben halten, side-by-side beobachten. Cloud Run dekommissionieren, sobald Beaconry eine Woche saubere Zahlen hat. Die Migration ist einfacher als das ursprüngliche GTM-SS-Setup; das Knifflige ist, den Cloud-Run-Container zu dekommissionieren, ohne DNS-Records auf Nichts zeigen zu lassen.

Von Browser-only GA4 / Meta-Pixel: Beaconry installieren, konfigurieren, deine Hybrid-Modus-Events deduplizieren gegen den bestehenden Browser-Pixel via stabiler event_id. Null Double-Counting, null Datenverlust, sofort bessere Adblock-Resistenz.

Fazit

Drei verschiedene Tools, die denselben Use-Case an unterschiedlichen Punkten auf dem Komplexität-vs-Flexibilität-Spektrum bedienen. Beaconry ist die richtige Wahl für WordPress-basierte Small-to-Mid-Kunden, die planbare Kosten, schnelles Setup und strukturelle Adblock-Resistenz wollen. Stape und GTM Server-Side sind die richtige Wahl für Nicht-WordPress, Custom-Tag-lastige oder Enterprise-Szenarien, in denen Flexibilität die Setup-Zeit überwiegt. Wähle nach Stack und Komplexitätsbedarf, nicht danach, welches Tool sich am lautesten "Server-Side" nennt.