How an event flows through Beaconry

Customer-facing explanation of the event pipeline. Browser to your own domain. Your own domain to Meta, TikTok, Google Ads, LinkedIn and GA4 server-side.

1. The visitor accepts consent

The first time a visitor lands on your site, Beaconry's bundled consent banner (nl-data-gate) prompts for analytics consent. Until they accept, no event leaves the browser, no request to Beaconry's REST endpoint is made. Consent state is stored in a first-party nl_pref cookie.

If the visitor rejects, Beaconry stays silent. They can change their choice later via the "Cookie settings" link Beaconry adds to your privacy page automatically.

2. The browser collects attribution and auto-events

Once consented, nl-data.js runs in the browser and:

• Captures click-IDs from URL parameters: fbclid (Meta), ttclid (TikTok), gclid + wbraid + gbraid (Google Ads), li_fat_id (LinkedIn). Persists them in the nl_ext cookie.
• Auto-fires PageView on every page load, ViewContent at 50% scroll plus 10s engagement.
• Listens for Kadence Blocks Form and Fluent Forms submissions, fires generate_lead.
• Listens for WooCommerce events, fires add_to_cart, begin_checkout, purchase with line items, currency and value.

3. Browser POSTs to your own domain

Every event is sent via navigator.sendBeacon to /wp-json/beaconry/v1/event. Same-origin means your domain, not a third-party tracker URL. An adblocker that blocks /wp-json would break WordPress itself, so the request goes through every time.

The payload is custom JSON, not Meta-Pixel or GA4 wire format. Content-based filter lists cannot identify it as tracking either.

4. Beaconry's REST endpoint validates and normalises

The PHP handler (BCNR_Rest::handle_event) performs three checks:

1. Verifies the nl_pref consent cookie is present and accepted.
2. Normalises the event-type to GA4 canonical naming (page_view, generate_lead, purchase).
3. Hashes PII fields (email, phone, name, ZIP, city) with SHA-256 per Meta's matching guidelines, before any data leaves the server.

If any check fails, the event is rejected and logged to the Logs tab. Successful events are handed to BCNR_Forwarder::dispatch().

5. The forwarder fans out to all configured channels

Beaconry holds your encrypted credentials for each channel. The forwarder calls each platform's official server-side API in parallel:

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

Each call is non-blocking from the visitor's request: WordPress responds 202 to the browser as soon as the event is queued. Total dispatch time is typically 50 to 250 ms server-side, the visitor never waits.

6. Hybrid mode (optional)

Per channel, you can enable hybrid mode. Beaconry then loads the platform's browser pixel in addition to the server-side dispatch. Both the browser and the server send the same event with the same stable event_id. The platform deduplicates them, so you don't double-count.

Why bother: hybrid mode lets the platform see first-party cookies (fbp / _ttp / li_fat_id), which improves match-rate. Trade-off: more bytes shipped to the visitor's browser. Off by default.

What's in DevTools when you visit a Beaconry-powered site

• One POST per event to /wp-json/beaconry/v1/event on your own domain.
• Zero requests to connect.facebook.net, analytics.tiktok.com, googleadservices.com, px.ads.linkedin.com or www.google-analytics.com unless hybrid mode is on.
• If hybrid mode is on for a channel: that channel's pixel script in DevTools, and one matching browser-side request per event. Beaconry deduplicates with the server-side event.