Troubleshooting

Pixel not firing, missing conversions, OAuth errors, plugin conflicts. The most common things that go wrong, in the order they typically come up.

Beaconry events are not arriving in any platform

Start here if nothing works.

1. Open your site in a fresh browser, accept the consent banner.
2. Open DevTools → Network tab. Reload the page.
3. Look for a POST to /wp-json/beaconry/v1/event. Status 202 means "queued for dispatch".
4. If you don't see the request: consent was rejected, or the consent banner is misconfigured. Check Beaconry → Tracking → Dashboard → "Consent state" pill.
5. If you see HTTP 4xx: WordPress REST is broken (other plugin filtering /wp-json/). Disable other plugins one by one.
6. If you see 202 but no platform conversion: open Beaconry → Logs. Each platform's response is logged with full request and response payload.

Meta: events arrive in CAPI but Match Quality is "Poor"

Beaconry sends the right hashed PII fields. Meta needs three trust signals to actually use them:

• Domain Verification in Business Settings → Brand Safety → Domains.
• Trusted domains list in Pixel → Settings → Traffic Permissions.
• Aggregated Event Measurement with priority order set on each domain.

Without these, Meta still records the event but flags it as "Poor" match. Setting all three takes ~10 minutes inside Meta and is independent of Beaconry.

TikTok: "code: 40005, content_id required"

TikTok Events API rejects events without a content_id in the contents[] array. Beaconry sets one automatically for WooCommerce events (the product SKU). For custom JS events, include content_id in contents[], not at the top level (TikTok ignores top-level content_id).

Google Ads: "PERMISSION_DENIED"

The Google account that ran the OAuth handshake doesn't have edit permission on the Customer ID. Two fixes:

• Open Google Ads → Tools → Access and security. Verify the connecting account has at least "Standard" role on this Customer ID.
• If you used a manager (MCC) account: connect with the manager account, then specify the sub-account Customer ID in Beaconry. The OAuth scope must cover the manager.

After fixing, click Connect with Google again to re-authenticate.

Google Ads: Conversion uploaded but not visible in Campaign Manager

Google Ads conversion data has up to 3 hours of latency. There is no real-time test view for the API. Wait, then check Campaign Manager → Tools → Conversions → Status column.

If after 6 hours nothing shows up: open Beaconry → Logs, find the upload, check the response. partialFailureError with details means Google rejected the row. Most common reason: Conversion Action is paused (re-enable in Campaign Manager).

LinkedIn: "403 Forbidden"

The LinkedIn account that ran OAuth lacks permission on the Ad Account. Account-Manager, Campaign-Manager or Account-Billing-Admin role required. Viewer-only is rejected by the API.

Re-authenticate with an account that has at least Campaign-Manager role.

LinkedIn: token expired warning

LinkedIn access-tokens expire after 60 days. Beaconry's Logs tab gets a daily heartbeat plus a warning when 7 days are left. Click Connect with LinkedIn to renew. Conversion-Rule-IDs and Ad-Account-ID stay configured. Only the OAuth handshake repeats.

GA4: Events in Realtime but missing in standard reports

GA4 standard reports have a 24 to 48 hour processing delay. Realtime is the source of truth for "did the event arrive". If Realtime shows the event, it will show up in standard reports tomorrow.

Tracking stops on a tab left open for hours, or on cached pages

Every dispatch is protected by a beaconry_event nonce, and WordPress nonces expire (typically after 12 to 24 hours). On a tab left open overnight, or on HTML served from a page cache, that nonce would normally be stale by the time a visitor converts. Beaconry refreshes the beaconry_event nonce client-side, so long-open tabs and page-cached HTML keep dispatching valid events without a reload. If you still see dispatches failing only after long idle periods, confirm the refresh request itself is not being blocked (an over-aggressive cache rule or firewall sitting in front of /wp-json/).

My refund is not in Meta or Google Ads

This is by design. Refund events go to GA4 only, because GA4 has a native refund event that nets the refunded revenue back against the original purchase. The ad channels (Meta, TikTok, LinkedIn, Google Ads, Microsoft Ads, Pinterest, X Ads, Snapchat, Reddit) have no real refund event, so Beaconry skips them rather than fake one. Your ad-platform conversion totals stay as the raw purchase count, and you reconcile net revenue in GA4.

Form-funnel numbers (form_start / form_abandon)

The funnel signals form_start (first field focused) and form_abandon (left without submitting) appear in GA4 only, never in the ad channels. They are analytics signals for measuring drop-off, not conversions, so there is nothing to look for in Meta or Google Ads.

To read per-form drop-off in GA4: filter the events by the form identifier, then compare the form_start count against the matching submission event for the same form. The gap is your abandonment, and form_abandon marks exactly which sessions bailed. If a form shows form_start but no submissions at all, the form's success hook is not firing (check that the form plugin's completion event reaches Beaconry).

Plugin conflicts

• Caching plugins (W3 Total Cache, WP Rocket): make sure /wp-json/ is excluded from page caching. Most WP-aware caches do this by default. If yours doesn't, the consent banner state and event dispatch can both break. Beaconry also auto-opts its own inline script out of JS optimization (concatenation, deferral, delay-until-interaction) on LiteSpeed Cache, WP Rocket, SiteGround Optimizer and Cloudflare, so the nonce-refresh and dispatch logic are never reordered or stripped.
• Other tracking plugins (PixelYourSite, Tracking Plus, Sky GA4): do not run two tracking plugins for the same destination. They will double-fire events. Either disable Beaconry's channel for that platform, or disable the other plugin entirely.
• Cookie consent plugins (CookieYes, Complianz): Beaconry includes its own consent banner (nl-data-gate). If you already have a CMP, set Beaconry's banner to "Hidden" in Beaconry → Banner and integrate via the API. The CMP should set nl_pref = "{analytics: true}" when the user accepts the analytics category.

WooCommerce events not firing

1. Beaconry hooks into woocommerce_thankyou (Purchase), woocommerce_add_to_cart and woocommerce_before_checkout_form. Verify in Beaconry → Logs that those hooks fire.
2. If a hook is missing from logs: a theme or plugin is intercepting the WooCommerce flow. Check woocommerce status → Tools → Logs for errors during checkout.
3. Custom thank-you pages: Beaconry's purchase event fires on the standard WooCommerce thankyou template. If you redirect to a custom page after order, you need to fire nlc.track('purchase', ...) manually on that page.

"My adblocker still blocks Beaconry"

Beaconry's /wp-json/beaconry/v1/event path is structurally adblocker-immune. If you see it being blocked:

• Verify the URL in DevTools. Is it actually /wp-json/beaconry/v1/event on your domain, or does it point to a different domain? If different, hybrid mode is on for some channel and that channel's pixel is loading from a third-party domain (which IS blockable).
• If hybrid mode is the cause, disable hybrid mode for that channel. Server-side dispatch resumes covering 100% of consenting visitors.

When in doubt, check the Logs

Beaconry → Logs keeps the last 200 events with full request and response payloads. Filter by channel, event-type or status. Most issues are diagnosable from the platform's response in the log entry.

For deeper debugging, set BCNR_DEBUG = true in wp-config.php. The Logs tab then includes WordPress's HTTP transport-layer messages too.

Still stuck?

Email info@beaconry.app with the affected channel name, the relevant Logs entry, and a screenshot of the platform's response. We usually reply within a working day.