Wie ein Event durch Beaconry fließt

Kunden-verständliche Erklärung der Event-Pipeline. Browser zu deiner eigenen Domain. Deine Domain zu Meta, TikTok, Google Ads, LinkedIn und GA4 server-side.

1. Besucher gibt Einwilligung

Beim ersten Besuch zeigt Beaconrys Consent-Banner (nl-data-gate) den Hinweis. Bis zur Zustimmung verlässt kein Event den Browser, kein Request geht an den REST-Endpoint. Consent-Status liegt im First-Party-nl_pref-Cookie.

Bei Ablehnung bleibt Beaconry still. Der Besucher kann später über den "Cookie-Einstellungen"-Link auf der Datenschutz-Seite seine Wahl ändern, den Beaconry automatisch einbindet.

2. Browser sammelt Attribution und Auto-Events

Nach Zustimmung läuft nl-data.js im Browser und:

• Fängt Click-IDs aus URL-Parametern: fbclid (Meta), ttclid (TikTok), gclid + wbraid + gbraid (Google Ads), li_fat_id (LinkedIn). Persistiert sie im nl_ext-Cookie.
• Auto-feuert PageView bei jedem Page-Load, ViewContent bei 50 % Scroll plus 10 Sek Engagement.
• Hört auf Kadence-Blocks-Form- und Fluent-Forms-Submissions, feuert generate_lead.
• Hört auf WooCommerce-Events, feuert add_to_cart, begin_checkout, purchase mit Line Items, Währung und Wert.

3. Browser POSTet an deine eigene Domain

Jedes Event wird via navigator.sendBeacon an /wp-json/beaconry/v1/event gesendet. Same-Origin heißt: deine Domain, keine Drittanbieter-Tracker-URL. Ein Adblocker, der /wp-json blockt, würde WordPress selbst kaputtmachen, also kommt der Request immer durch.

Der Payload ist Custom-JSON, kein Meta-Pixel- oder GA4-Wire-Format. Inhaltsbasierte Filter-Listen können ihn auch nicht als Tracking erkennen.

4. Beaconrys REST-Endpoint validiert und normalisiert

Der PHP-Handler (BCNR_Rest::handle_event) prüft drei Dinge:

1. Verifiziert das nl_pref-Consent-Cookie ist gesetzt und akzeptiert.
2. Normalisiert den Event-Type auf GA4-Kanonik (page_view, generate_lead, purchase).
3. Hashed PII-Felder (E-Mail, Telefon, Name, PLZ, Stadt) mit SHA-256 gemäß Metas Matching-Vorgaben, bevor irgendwelche Daten den Server verlassen.

Schlägt eine Prüfung fehl, wird das Event abgelehnt und im Logs-Tab geloggt. Erfolgreiche Events gehen an BCNR_Forwarder::dispatch().

5. Forwarder fächert auf alle konfigurierten Kanäle aus

Beaconry hält deine verschlüsselten Credentials für jeden Kanal. Der Forwarder ruft die offizielle Server-Side-API jeder Plattform parallel auf:

• Meta Conversions API via graph.facebook.com.
• TikTok Events API via business-api.tiktok.com.
• Google Ads API via Phase-2-Broker auf Cloudflare.
• LinkedIn Conversions API via api.linkedin.com.
• GA4 Measurement Protocol via www.google-analytics.com.

Jeder Call ist non-blocking gegenüber dem Besucher-Request: WordPress antwortet mit 202, sobald das Event in der Queue liegt. Gesamte Dispatch-Zeit liegt typisch bei 50 bis 250 ms server-side, der Besucher wartet nie.

6. Hybrid-Modus (optional)

Pro Kanal kannst du den Hybrid-Modus aktivieren. Beaconry lädt dann zusätzlich zum Server-Side-Dispatch den Browser-Pixel der Plattform. Browser und Server senden dasselbe Event mit derselben stabilen event_id. Die Plattform dedupliziert sie, du zählst nicht doppelt.

Wozu: Hybrid-Modus lässt der Plattform First-Party-Cookies (fbp / _ttp / li_fat_id) sehen, was die Match-Rate hebt. Trade-off: mehr Bytes für den Browser. Standardmäßig aus.

Was in DevTools zu sehen ist

• Ein POST pro Event an /wp-json/beaconry/v1/event auf deiner eigenen Domain.
• Null Requests an connect.facebook.net, analytics.tiktok.com, googleadservices.com, px.ads.linkedin.com oder www.google-analytics.com, sofern Hybrid-Modus aus ist.
• Bei aktivem Hybrid-Modus für einen Kanal: dessen Pixel-Skript in DevTools, plus ein matching Browser-Request pro Event. Beaconry dedupliziert mit dem Server-Event.