Event-routing reference
One event fires inside WordPress, but not every channel should receive it. Beaconry routes each event to exactly the platforms that have a real use for it, and silently skips the rest. This page is the full matrix plus the reasoning behind every skip, taken straight from the dispatcher, not from a vendor's marketing page.
The one rule behind the whole table
Each platform gets exactly the events it can use. A channel only receives an event when that event maps to something the channel can actually optimise on or report. Sending a platform an event it has no slot for does not help you, it just produces a junk custom event that clutters that platform's Events Manager, splits a counter, or in the worst case collides with a different event in a shared slot. So Beaconry filters per channel before anything goes on the wire.
There are two filtering models, because the ten channels split into two families:
- Standard-event channels (Meta, TikTok, Pinterest, Snapchat, Reddit) have a published vocabulary of standard event names. Beaconry maps your event onto that vocabulary and sends it, unless the event is on that channel's skip list. The skip list is what this page is mostly about.
- Slot / goal channels (Google Ads, Microsoft Ads, LinkedIn, X Ads) do not have a flat event vocabulary. Each conversion is tied to a thing you create in that platform's UI: a Conversion Action (Google Ads), a Conversion Goal (Microsoft Ads), a Conversion Rule (LinkedIn) or a configured event_id (X Ads). Beaconry only sends an event to one of these channels when the event maps to a known slot and you have filled in the ID for that slot. Everything else is dropped, there is no custom-event fallback.
GA4 sits slightly apart: it is the analytics destination, so it receives almost everything, including the events that no ad platform should see.
GA4 is the catch-all
GA4 (Measurement Protocol) receives every event Beaconry dispatches, with three exceptions: user_engagement, session_start and first_visit. Those three are GA4 reserved names that the platform derives on its own from engagement time and new client/session IDs. Sending them yourself does nothing useful and the Measurement Protocol silently drops them under its default validation, so Beaconry skips them at the dispatcher to keep the wire clean and the dashboard counters honest.
Everything else reaches GA4: the full commerce funnel including view_item_list, view_cart, remove_from_cart and refund, plus the form-funnel signals form_start and form_abandon (the latter only when you opt into form-funnel forwarding). That is deliberate. GA4 is where you want the complete picture, including the behavioural and analytics-only events that have no place on an ad platform.
The commerce funnel matrix
This is the WooCommerce ten-event funnel (EDD and SureCart fire the same set minus search, and SureCart's cart-stage events arrive via the browser bridge). "Standard" means the channel receives it as one of its native event names. "Custom" means it still reaches the channel, but as a custom event because that channel has no native equivalent. A dash means the event does not reach that channel at all.
| Event | GA4 | Meta | TikTok | Snapchat | Google Ads | Microsoft Ads | X Ads | |||
|---|---|---|---|---|---|---|---|---|---|---|
view_item | Yes | Standard | Standard | Standard | Standard | Standard | – | – | Slot | – |
view_item_list | Yes | – | – | Standard | – | – | – | – | – | – |
view_cart | Yes | Custom | – | – | – | – | – | – | – | – |
add_to_cart | Yes | Standard | Standard | Standard | Standard | Standard | Slot | Slot | Slot | Slot |
remove_from_cart | Yes | Custom | – | – | – | – | – | – | – | – |
search | Yes | Standard | Standard | Standard | Standard | Standard | – | – | – | – |
begin_checkout | Yes | Standard | Standard | Standard | Standard | Custom | Slot | Slot | – | – |
add_payment_info | Yes | Standard | Standard | Standard | Standard | Custom | – | – | – | – |
purchase | Yes | Standard | Standard | Standard | Standard | Standard | Slot | Slot | Slot | Slot |
refund | Yes | – | – | – | – | – | – | – | – | – |
Two columns need a word of warning so you read the table correctly.
- The "Custom" cells (Meta
view_cart/remove_from_cart, Redditbegin_checkout/add_payment_info) mean the event reaches the platform but as a custom event, because that platform has no standard name for it. It still counts and can still feed a custom audience, it just is not a first-class optimisation event there. - The "Slot" cells for Google Ads, Microsoft Ads, LinkedIn and X Ads are conditional. The event only actually sends if you have configured the matching Conversion Action / Goal / Rule / event_id ID for it. With no ID configured for that slot, the event is silently dropped even though the table marks it "Slot". See the slot-channel section below.
Why each skip exists
refund goes to GA4 only
This is the most surprising row, so it gets the fullest explanation. A refund is sent to GA4 and to no ad channel at all.
GA4 has a native refund event that nets the refunded revenue back out against the original purchase, so your reported revenue stays correct after a return. That is a real, first-class event with real semantics.
No ad channel has an equivalent. Meta CAPI and TikTok Events API simply have no refund event type in their supported list (Meta's refund handling lives in a separate Commerce-Platform order-management API, not the Conversions API). Pinterest, Reddit and the slot channels have no native refund either. Sending a custom "Refund" event to any of them would not net revenue and would not feed Smart Bidding, it would just be a counter that inflates your custom-event list. On Snapchat it would be actively harmful: a custom refund falls onto the same CUSTOM_EVENT_1 slot Beaconry reserves for form leads, so refunds and leads would become indistinguishable in Snap reporting. So refund is GA4-only, full stop.
view_item_list goes to GA4 and Pinterest only
On Meta, TikTok, Snapchat and Reddit, a list/collection view maps to the same standard event as a single product view (ViewContent / VIEW_CONTENT). On a shop or category page that includes product detail, that means two ViewContent events with different IDs arriving for one page view, which double-counts in reporting and confuses Smart Bidding (which optimises on product-detail signals, not list views). So view_item_list is skipped on those four.
Pinterest is the exception: it has a dedicated view_category event distinct from view_content, so the list view maps cleanly to its own event type with no collision. Pinterest gets it.
view_cart and remove_from_cart are GA4-centric
Neither is a standard event on most ad platforms. view_cart reaches Meta as a custom event and nowhere else among the ad channels; on TikTok, Snapchat and Reddit it would re-map onto ViewContent and double-count (SureCart in particular opens a cart drawer right after add-to-cart, firing a cart view immediately behind the add), and Pinterest has no cart-view concept at all. remove_from_cart reaches Meta as a custom event and nowhere else; the other platforms either have no mapping (so the event is silently swallowed and just wastes bytes) or, on Snapchat, would collide with the reserved lead slot. Smart Bidding optimises on add-to-cart and purchase, not on removes, so skipping costs you no optimisation signal.
page_view and user_engagement
TikTok's Events API has no Pageview in its standard web-events list, so a server-side page_view there becomes a custom event TikTok silently drops, invisible in Test Events and dead in the Conversion Manager. Beaconry skips it. user_engagement (the ten-second active-dwell signal) maps to ViewContent on Meta and TikTok, so it only makes sense to send when the matching hybrid browser pixel is also live and can deduplicate it via a shared event_id. With hybrid off it would be a one-sided ViewContent with no browser counterpart, so it is skipped unless hybrid is on for that channel. It is also a GA4 reserved name, so GA4 derives it itself.
form_start and form_abandon are analytics-only
These two are behavioural funnel signals, not ad conversions, and they are guaranteed never to reach any ad channel by a single central gate in the dispatcher. form_start reaches GA4 only. form_abandon reaches GA4 only when you opt into form-funnel forwarding, and by default touches only the in-plugin funnel store and nothing on the wire. There is no per-channel skip entry needed for this and no way for a future ad channel to start receiving them by accident, because the gate runs once, up front, for the whole fan-out. See Forms setup for the funnel feature itself.
The slot / goal channels in detail
Google Ads, Microsoft Ads, LinkedIn and X Ads do not take a free-form event vocabulary. Beaconry maps your GA4 event to a fixed slot, and only sends when you have configured the platform-side ID for that slot. If a commerce event has no slot in the map below, it is never sent to that channel, no custom-event fallback, no junk row in the platform.
Practical consequence: top-of-funnel and mid-funnel events that do appear in the slot map (add_to_cart, begin_checkout) still only fire if you actually created and filled in a Conversion Action / Goal / Rule for them. Most setups configure purchase and lead and leave the rest empty, which is fine. The slot exists so you can feed those mid-funnel signals to Smart Bidding if you want to.
| GA4 event | Google Ads | Microsoft Ads | X Ads | |
|---|---|---|---|---|
purchase | purchase | purchase | purchase | purchase |
add_to_cart | add_to_cart | add_to_cart | addtocart | addtocart |
begin_checkout | begin_checkout | begin_checkout | – | – |
view_item | – | – | keypageview | – |
page_view | – | – | – | pageview |
generate_lead | lead | lead | lead | lead |
submit_application | lead | lead | lead | lead |
contact | contact | contact | lead | lead |
sign_up | signup | signup | signup | signup |
start_trial | signup | signup | – | – |
subscribe | subscribe | subscribe | signup | signup |
schedule | schedule | schedule | – | – |
A few things to read out of this table:
- Google Ads and Microsoft Ads share one slot map. They have the same Purchase / Lead / SignUp / Subscribe / Schedule / Contact conversion shape, so the same eight kinds apply to both. Google Ads also needs a gclid on the event to attribute it, Microsoft Ads needs an msclkid, and an upload without the matching click ID is silently skipped.
- LinkedIn and X Ads do not take begin_checkout, add_payment_info, search or refund. Their slot vocabularies are narrower (purchase, add-to-cart, lead, signup, plus keypageview on LinkedIn and pageview on X). Anything outside those slots is dropped.
- contact and submit_application collapse onto lead on LinkedIn and X, because those platforms do not differentiate them, while Google and Microsoft keep contact as its own slot.
- None of the four slot channels receive
view_item_list,view_cart,remove_from_cartorrefund. There is no slot for them, so the question of skip rules never even arises.
Form lead types follow the same logic
A form submit fires a lead-type event (generate_lead by default, or Contact, Application, Subscribe, Registration, Appointment, Trial, and so on). That event is routed by exactly the same machinery: GA4 gets it as its canonical name, the standard-event channels get their native name for that lead type, and the slot channels fire only if the matching Conversion Action / Goal / Rule / event_id is configured. The per-form lead-type to per-channel-name table lives in Forms setup; this page covers the commerce and funnel side.
Can I override a skip?
For the standard-event channels, yes, per form. A form caller can set an explicit per-channel event name on the event, which overrides the skip for that channel and sends a custom event under the name you chose. That is an advanced lever for the form adapters, not a global toggle, and the commerce funnel skips are not meant to be overridden because every one of them exists to prevent a double-count or a slot collision. For the slot channels there is nothing to override: an event with no slot has nowhere to go on that platform.
If you genuinely need a non-standard routing (a custom rate per market, a bespoke event to one platform), hook the bcnr_pre_dispatch_event filter and rewrite the event before fan-out. That is the sanctioned extension point, the same one Multi-currency and the form funnel use.