Referencia de enrutamiento de eventos
Un evento se dispara dentro de WordPress, pero no todos los canales deberían recibirlo. Beaconry enruta cada evento exactamente a las plataformas que tienen un uso real para él, y omite el resto en silencio. Esta página es la matriz completa más el razonamiento detrás de cada omisión, tomado directamente del dispatcher, no de la página de marketing de un proveedor.
La única regla detrás de toda la tabla
Cada plataforma recibe exactamente los eventos que puede usar. Un canal solo recibe un evento cuando ese evento se corresponde con algo sobre lo que el canal realmente puede optimizar o reportar. Enviar a una plataforma un evento para el que no tiene un espacio no te ayuda, solo produce un evento personalizado basura que satura el Events Manager de esa plataforma, divide un contador o, en el peor caso, choca con un evento distinto en un espacio compartido. Por eso Beaconry filtra por canal antes de que nada salga al cable.
Hay dos modelos de filtrado, porque los diez canales se dividen en dos familias:
- Canales de eventos estándar (Meta, TikTok, Pinterest, Snapchat, Reddit) tienen un vocabulario publicado de nombres de eventos estándar. Beaconry mapea tu evento a ese vocabulario y lo envía, salvo que el evento esté en la lista de omisión de ese canal. De esa lista de omisión trata principalmente esta página.
- Canales de espacio/objetivo (Google Ads, Microsoft Ads, LinkedIn, X Ads) no tienen un vocabulario de eventos plano. Cada conversión está ligada a algo que creas en la UI de esa plataforma: una Conversion Action (Google Ads), un Conversion Goal (Microsoft Ads), una Conversion Rule (LinkedIn) o un event_id configurado (X Ads). Beaconry solo envía un evento a uno de estos canales cuando el evento se corresponde con un espacio conocido y has rellenado el ID de ese espacio. Todo lo demás se descarta, no hay respaldo de evento personalizado.
GA4 queda algo aparte: es el destino de analítica, así que recibe casi todo, incluidos los eventos que ninguna plataforma publicitaria debería ver.
GA4 es el cajón de sastre
GA4 (Measurement Protocol) recibe cada evento que Beaconry despacha, con tres excepciones: user_engagement, session_start y first_visit. Estos tres son nombres reservados de GA4 que la plataforma deriva por sí misma a partir del tiempo de interacción y los nuevos IDs de cliente/sesión. Enviarlos tú mismo no aporta nada útil y el Measurement Protocol los descarta en silencio bajo su validación predeterminada, así que Beaconry los omite en el dispatcher para mantener el cable limpio y los contadores del panel honestos.
Todo lo demás llega a GA4: el embudo de commerce completo, incluidos view_item_list, view_cart, remove_from_cart y refund, más las señales de embudo de formulario form_start y form_abandon (este último solo cuando activas el reenvío del embudo de formulario). Es deliberado. GA4 es donde quieres la imagen completa, incluidos los eventos de comportamiento y solo de analítica que no tienen cabida en una plataforma publicitaria.
La matriz del embudo de commerce
Este es el embudo de diez eventos de WooCommerce (EDD y SureCart disparan el mismo conjunto menos search, y los eventos de etapa de carrito de SureCart llegan a través del puente del navegador). "Estándar" significa que el canal lo recibe como uno de sus nombres de evento nativos. "Personalizado" significa que aún llega al canal, pero como evento personalizado porque ese canal no tiene un equivalente nativo. Un guion significa que el evento no llega en absoluto a ese canal.
| Evento | GA4 | Meta | TikTok | Snapchat | Google Ads | Microsoft Ads | X Ads | |||
|---|---|---|---|---|---|---|---|---|---|---|
view_item | Sí | Standard | Standard | Standard | Standard | Standard | – | – | Slot | – |
view_item_list | Sí | – | – | Standard | – | – | – | – | – | – |
view_cart | Sí | Custom | – | – | – | – | – | – | – | – |
add_to_cart | Sí | Standard | Standard | Standard | Standard | Standard | Slot | Slot | Slot | Slot |
remove_from_cart | Sí | Custom | – | – | – | – | – | – | – | – |
search | Sí | Standard | Standard | Standard | Standard | Standard | – | – | – | – |
begin_checkout | Sí | Standard | Standard | Standard | Standard | Custom | Slot | Slot | – | – |
add_payment_info | Sí | Standard | Standard | Standard | Standard | Custom | – | – | – | – |
purchase | Sí | Standard | Standard | Standard | Standard | Standard | Slot | Slot | Slot | Slot |
refund | Sí | – | – | – | – | – | – | – | – | – |
Dos columnas necesitan una advertencia para que leas la tabla correctamente.
- Las celdas "Custom" (Meta
view_cart/remove_from_cart, Redditbegin_checkout/add_payment_info) significan que el evento llega a la plataforma, pero como evento personalizado, porque esa plataforma no tiene un nombre estándar para él. Sigue contando y aún puede alimentar una audiencia personalizada, simplemente no es allí un evento de optimización de primera clase. - Las celdas "Slot" para Google Ads, Microsoft Ads, LinkedIn y X Ads son condicionales. El evento solo se envía realmente si has configurado el ID de Conversion Action / Goal / Rule / event_id correspondiente. Sin un ID configurado para ese espacio, el evento se descarta en silencio aunque la tabla lo marque como "Slot". Consulta la sección de canales de espacio más abajo.
Por qué existe cada omisión
refund va solo a GA4
Esta es la fila más sorprendente, así que recibe la explicación más completa. Un refund se envía a GA4 y a ningún canal publicitario en absoluto.
GA4 tiene un evento refund nativo que descuenta los ingresos reembolsados frente a la compra original, de modo que tus ingresos reportados se mantienen correctos tras una devolución. Ese es un evento real, de primera clase, con semántica real.
Ningún canal publicitario tiene un equivalente. Meta CAPI y TikTok Events API simplemente no tienen un tipo de evento de refund en su lista compatible (el manejo de reembolsos de Meta vive en una API de gestión de pedidos de Commerce Platform aparte, no en la Conversions API). Pinterest, Reddit y los canales de espacio tampoco tienen un refund nativo. Enviar un evento "Refund" personalizado a cualquiera de ellos no descontaría ingresos ni alimentaría Smart Bidding, sería solo un contador que infla tu lista de eventos personalizados. En Snapchat sería activamente perjudicial: un refund personalizado cae en el mismo espacio CUSTOM_EVENT_1 que Beaconry reserva para leads de formulario, así que reembolsos y leads se volverían indistinguibles en los informes de Snap. Por eso refund es solo para GA4, punto.
view_item_list va solo a GA4 y Pinterest
En Meta, TikTok, Snapchat y Reddit, una vista de lista/colección se corresponde con el mismo evento estándar que una vista de producto individual (ViewContent / VIEW_CONTENT). En una página de tienda o de categoría que incluye detalle de producto, eso significa dos eventos ViewContent con IDs distintos llegando por una sola vista de página, lo que cuenta doble en los informes y confunde a Smart Bidding (que optimiza sobre señales de detalle de producto, no sobre vistas de lista). Por eso view_item_list se omite en esos cuatro.
Pinterest es la excepción: tiene un evento view_category dedicado, distinto de view_content, así que la vista de lista se corresponde limpiamente con su propio tipo de evento sin colisión. Pinterest lo recibe.
view_cart y remove_from_cart son centrados en GA4
Ninguno es un evento estándar en la mayoría de las plataformas publicitarias. view_cart llega a Meta como evento personalizado y a ningún otro lugar entre los canales publicitarios; en TikTok, Snapchat y Reddit se reasignaría a ViewContent y contaría doble (SureCart en particular abre un cajón de carrito justo después del add-to-cart, disparando una vista de carrito inmediatamente detrás del add), y Pinterest no tiene ningún concepto de vista de carrito. remove_from_cart llega a Meta como evento personalizado y a ningún otro lugar; las demás plataformas o bien no tienen correspondencia (así que el evento se traga en silencio y solo malgasta bytes) o, en Snapchat, chocarían con el espacio de lead reservado. Smart Bidding optimiza sobre add-to-cart y purchase, no sobre eliminaciones, así que omitirlo no te cuesta ninguna señal de optimización.
page_view y user_engagement
La Events API de TikTok no tiene Pageview en su lista de eventos web estándar, así que un page_view del lado del servidor allí se convierte en un evento personalizado que TikTok descarta en silencio, invisible en Test Events y muerto en el Conversion Manager. Beaconry lo omite. user_engagement (la señal de permanencia activa de diez segundos) se corresponde con ViewContent en Meta y TikTok, así que solo tiene sentido enviarlo cuando el píxel híbrido de navegador correspondiente también está activo y puede deduplicarlo a través de un event_id compartido. Con el híbrido apagado sería un ViewContent unilateral sin contraparte de navegador, así que se omite salvo que el híbrido esté activo para ese canal. También es un nombre reservado de GA4, así que GA4 lo deriva por sí mismo.
form_start y form_abandon son solo de analítica
Estos dos son señales de embudo de comportamiento, no conversiones publicitarias, y está garantizado que nunca llegan a ningún canal publicitario gracias a una única compuerta central en el dispatcher. form_start llega solo a GA4. form_abandon llega a GA4 solo cuando activas el reenvío del embudo de formulario, y por defecto toca únicamente el almacén de embudo dentro del plugin y nada en el cable. No se necesita ninguna entrada de omisión por canal para esto y no hay forma de que un futuro canal publicitario empiece a recibirlos por accidente, porque la compuerta se ejecuta una vez, por adelantado, para todo el fan-out. Consulta Configuración de formularios para la función de embudo en sí.
Los canales de espacio/objetivo en detalle
Google Ads, Microsoft Ads, LinkedIn y X Ads no aceptan un vocabulario de eventos de forma libre. Beaconry mapea tu evento de GA4 a un espacio fijo, y solo envía cuando has configurado el ID del lado de la plataforma para ese espacio. Si un evento de commerce no tiene un espacio en el mapa de abajo, nunca se envía a ese canal, sin respaldo de evento personalizado, sin fila basura en la plataforma.
Consecuencia práctica: los eventos de la parte alta y media del embudo que sí aparecen en el mapa de espacios (add_to_cart, begin_checkout) solo se disparan si realmente has creado y rellenado una Conversion Action / Goal / Rule para ellos. La mayoría de las configuraciones configuran purchase y lead y dejan el resto vacío, lo cual está bien. El espacio existe para que puedas alimentar esas señales de la parte media del embudo a Smart Bidding si quieres.
| Evento GA4 | 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 | – | – |
Algunas cosas que leer de esta tabla:
- Google Ads y Microsoft Ads comparten un mapa de espacios. Tienen la misma forma de conversión Purchase / Lead / SignUp / Subscribe / Schedule / Contact, así que los mismos ocho tipos aplican a ambos. Google Ads además necesita un gclid en el evento para atribuirlo, Microsoft Ads necesita un msclkid, y una carga sin el click ID correspondiente se omite en silencio.
- LinkedIn y X Ads no aceptan begin_checkout, add_payment_info, search ni refund. Sus vocabularios de espacios son más estrechos (purchase, add-to-cart, lead, signup, más keypageview en LinkedIn y pageview en X). Cualquier cosa fuera de esos espacios se descarta.
- contact y submit_application colapsan en lead en LinkedIn y X, porque esas plataformas no los diferencian, mientras que Google y Microsoft mantienen contact como su propio espacio.
- Ninguno de los cuatro canales de espacio recibe
view_item_list,view_cart,remove_from_cartnirefund. No hay espacio para ellos, así que la cuestión de las reglas de omisión ni siquiera se plantea.
Los tipos de lead de formulario siguen la misma lógica
Un envío de formulario dispara un evento de tipo lead (generate_lead por defecto, o Contact, Application, Subscribe, Registration, Appointment, Trial, etc.). Ese evento se enruta con exactamente la misma maquinaria: GA4 lo recibe con su nombre canónico, los canales de eventos estándar reciben su nombre nativo para ese tipo de lead, y los canales de espacio se disparan solo si la Conversion Action / Goal / Rule / event_id correspondiente está configurada. La tabla de tipo de lead por formulario a nombre por canal vive en Configuración de formularios; esta página cubre la parte de commerce y embudo.
¿Puedo anular una omisión?
Para los canales de eventos estándar, sí, por formulario. Quien invoca un formulario puede establecer un nombre de evento por canal explícito en el evento, lo que anula la omisión para ese canal y envía un evento personalizado con el nombre que elijas. Esa es una palanca avanzada para los adaptadores de formulario, no un interruptor global, y las omisiones del embudo de commerce no están pensadas para anularse porque cada una de ellas existe para evitar un doble conteo o una colisión de espacios. Para los canales de espacio no hay nada que anular: un evento sin espacio no tiene a dónde ir en esa plataforma.
Si realmente necesitas un enrutamiento no estándar (una tasa personalizada por mercado, un evento a medida a una plataforma), engánchate al filtro bcnr_pre_dispatch_event y reescribe el evento antes del fan-out. Ese es el punto de extensión autorizado, el mismo que usan Multi-currency y el embudo de formulario.