Cómo un evento fluye a través de Beaconry

Explicación customer-facing de la pipeline de eventos. Del navegador a tu propio dominio. De tu propio dominio a Meta, TikTok, Google Ads, LinkedIn y GA4 en server-side.

Tiempo de lectura: ~4 minÚltima actualización: 2026-05-02

1. El visitante acepta el consentimiento

La primera vez que un visitante aterriza en tu sitio, el banner de consentimiento incorporado de Beaconry (nl-data-gate) pide consentimiento de analytics. Hasta que acepta, ningún evento sale del navegador, no se hace ninguna petición al endpoint REST de Beaconry. El estado de consentimiento se guarda en una cookie first-party nl_pref.

Si el visitante rechaza, Beaconry se queda en silencio. Puede cambiar su elección más tarde vía el enlace "Cookie settings" que Beaconry añade automáticamente a tu página de privacidad.

2. El navegador recoge atribución y eventos automáticos

Una vez dado el consentimiento, nl-data.js corre en el navegador y:

  • Captura los click-IDs desde los parámetros URL: fbclid (Meta), ttclid (TikTok), gclid + wbraid + gbraid (Google Ads), li_fat_id (LinkedIn). Los persiste en la cookie nl_ext.
  • Auto-dispara PageView en cada carga de página, ViewContent al 50% de scroll más 10s de engagement.
  • Escucha los envíos de Kadence Blocks Form y Fluent Forms, dispara generate_lead.
  • Escucha eventos WooCommerce, dispara add_to_cart, begin_checkout, purchase con line items, divisa y valor.

3. El navegador hace POST a tu propio dominio

Cada evento se envía vía navigator.sendBeacon a /wp-json/beaconry/v1/event. Same-origin significa tu dominio, no una URL de tracker third-party. Un adblocker que bloquease /wp-json rompería WordPress mismo, así que la petición pasa cada vez.

El payload es JSON custom, no el wire format de Meta-Pixel ni de GA4. Las filter lists basadas en contenido tampoco pueden identificarlo como tracking.

4. El endpoint REST de Beaconry valida y normaliza

El handler PHP (BCNR_Rest::handle_event) realiza tres comprobaciones:

  1. Verifica que la cookie de consentimiento nl_pref está presente y aceptada.
  2. Normaliza el tipo de evento al naming canónico de GA4 (page_view, generate_lead, purchase).
  3. Hashea los campos PII (email, teléfono, nombre, código postal, ciudad) con SHA-256 según las matching guidelines de Meta, antes de que ningún dato salga del servidor.

Si alguna comprobación falla, el evento se rechaza y se loggea en la pestaña Logs. Los eventos exitosos se entregan a BCNR_Forwarder::dispatch().

5. El forwarder reparte a todos los canales configurados

Beaconry guarda tus credenciales cifradas para cada canal. El forwarder llama a la API server-side oficial de cada plataforma en paralelo:

  • Meta Conversions API vía graph.facebook.com.
  • TikTok Events API vía business-api.tiktok.com.
  • Google Ads API vía el broker Phase-2 en Cloudflare.
  • LinkedIn Conversions API vía api.linkedin.com.
  • GA4 Measurement Protocol vía www.google-analytics.com.

Cada llamada es non-blocking respecto a la petición del visitante: WordPress responde 202 al navegador en cuanto el evento está en cola. El tiempo de despacho total es típicamente 50 a 250 ms server-side, el visitante nunca espera.

6. Modo híbrido (opcional)

Por canal, puedes activar el modo híbrido. Beaconry entonces carga el browser pixel de la plataforma además del despacho server-side. Tanto el navegador como el servidor envían el mismo evento con el mismo event_id estable. La plataforma los deduplica, así que no se duplica el conteo.

Por qué molestarse: el modo híbrido permite a la plataforma ver las cookies first-party (fbp / _ttp / li_fat_id), lo que mejora el match-rate. Trade-off: más bytes enviados al navegador del visitante. Desactivado por defecto.

Qué hay en DevTools cuando visitas un sitio Beaconry

  • Un POST por evento a /wp-json/beaconry/v1/event en tu propio dominio.
  • Cero peticiones a connect.facebook.net, analytics.tiktok.com, googleadservices.com, px.ads.linkedin.com o www.google-analytics.com a menos que el modo híbrido esté activado.
  • Si el modo híbrido está activo para un canal: el script del pixel de ese canal en DevTools, y una petición browser-side correspondiente por evento. Beaconry deduplica con el evento server-side.