Modo híbrido: cuándo volver a meter el pixel del navegador

Server-side por sí solo cubre el 100 % de los visitantes con consentimiento. El modo híbrido añade cookies first-party fbp / _ttp / li_fat_id para mejor match-rate. event_id estable evita el double-counting. Recorrido del trade-off y heurísticas concretas para cuándo activarlo por canal.

El problema del match-rate

El dispatch server-side envía eventos con los datos a los que tu instalación de WordPress tiene acceso: email y teléfono hasheados si el visitante envió un formulario, nombre y dirección hasheados si WooCommerce los capturó en el checkout, IP y user agent siempre. Eso cubre muchos casos pero deja match-rate sobre la mesa para un grupo específico de visitantes: los que hicieron clic en un anuncio y todavía no han entregado PII.

Para esos visitantes, el mecanismo de atribución principal de la plataforma es el click-ID guardado en una cookie first-party. fbp para Meta, _ttp para TikTok, li_fat_id para LinkedIn, _gcl_aw para Google Ads. Beaconry captura el click-ID del parámetro URL al aterrizar (fbclid, ttclid, etc.) y lo persiste en nl_ext. Eso funciona server-side. Pero las plataformas pueden hacer matching más granular cuando también ven sus propias cookies first-party, que solo su propio pixel de navegador puede escribir.

Qué hace realmente el modo híbrido

Con modo híbrido activado para un canal, Beaconry carga además del dispatch server-side el script del pixel del navegador de esa plataforma. El pixel del navegador establece las cookies first-party de la plataforma (fbp, _ttp, li_fat_id) y dispara el mismo evento que está disparando el servidor, con un detalle crítico: una event_id estable compartida entre las dos fuentes.

Concretamente, en un evento de purchase en WooCommerce con modo híbrido activado para Meta:

1. Beaconry genera un event_id en el momento de la compra: un hash determinista del Order ID de WooCommerce. Mismo valor en cada reintento, mismo valor en navegador y servidor.
2. El navegador dispara fbq('track', 'Purchase', {...}, {eventID: 'abc123'}).
3. El servidor dispara el mismo evento Purchase con event_id: 'abc123' vía Meta CAPI.
4. Meta recibe ambos, deduplica por event_id, lo cuenta como una compra.

La plataforma toma el evento con más señales de matching. El lado navegador tiene fbp + fbc (cookies first-party que Meta conoce). El lado servidor tiene email + teléfono + ciudad + código postal hasheados. Con ambos llegando para la misma event_id, la plataforma fusiona los datos y los trata como una conversión de alta calidad.

Cómo funciona realmente la dedup en cada plataforma

El patrón general es el mismo, la implementación difiere:

• Meta: deduplica por event_id + event_name dentro de una ventana de 48 horas. Documentado y estable. La más predecible de las tres.
• TikTok: deduplica por event_id dentro de una ventana de 24 horas. Documentado y funciona como anuncia.
• LinkedIn: dedup basada en idempotency-key para la Conversions API. El tag de navegador y la CAPI del servidor usan la misma idempotency-key. Funciona pero la documentación es escasa, normalmente verificas comprobando que el contador de Campaign Manager no se duplica.

GA4 y Google Ads no tienen el mismo patrón de dedup porque su dispatch en navegador y en servidor típicamente corren como propiedades separadas, así que el double-counting no es preocupación allí en la misma forma.

El coste

Real, no negligible:

• Bytes: ~30 KB extra en el navegador por plataforma para la que actives híbrido. Cinco canales con híbrido activado = 150 KB de carga adicional. Visible en Lighthouse, posiblemente perceptible en conexiones lentas.
• Vulnerabilidad a adblockers para ese subconjunto: el script del pixel del navegador lo bloquean los adblockers. Para visitantes con adblocker pierdes el boost de match-rate, sigues teniendo el evento server-side con PII hasheada, pero la dedup es unilateral. No peor que apagado, tampoco mejor.
• Cambios de CSP: la CSP de Beaconry se amplía automáticamente cuando activas híbrido para un canal (añade el dominio de la plataforma a script-src y connect-src). Si tienes una CSP estricta, es un cambio de política visible.
• Postura de privacidad: el navegador del visitante ahora habla directamente con la plataforma, no solo same-origin con tu WordPress. Más difícil de vender como "sin tracking de terceros", porque lo hay, aunque event_id-deduplicado.

Cuándo gana el híbrido

• Campañas de purchase de alta intención donde el match-rate es el cuello de botella de atribución.
• Audiencias con tasas de adblock más bajas (retail mainstream, 15-20 %).
• Volúmenes de conversión lo bastante altos para que una mejora de 5-10 % en match-rate cambie materialmente el ROAS de la campaña.
• Meta específicamente: el match-rate de Meta es más sensible a las cookies first-party que las otras plataformas, así que el híbrido ayuda más allí.

Cuándo pierde el híbrido

• Audiencias B2B con tasas de adblock altas (35-50 %): el boost de match-rate del híbrido se lo come igualmente el script de pixel bloqueado.
• Campañas de bajo presupuesto donde la mejora absoluta del match-rate (en conversiones) es de un solo dígito por mes.
• Marcas posicionadas en privacidad donde el trade-off "sin dominios externos" forma parte de la propuesta de valor.
• Entornos de CSP estricta donde añadir nuevas entradas de script-src dispara revisión interna.

Implementación en Beaconry

Un toggle por canal, sin código del lado cliente que escribir. WordPress Admin → Beaconry → Tracking → [canal] → Modo híbrido. Toggle activado, guardar.

Por debajo, Beaconry ahora: (a) emite el script del pixel del navegador de la plataforma vía wp_enqueue_script con defer, (b) monta un pequeño puente JS que escucha los mismos eventos que dispara el camino server-side, (c) adjunta la misma event_id estable a ambos, (d) amplía la CSP para permitir el dominio de la plataforma. El visitante ve ~30 KB más de JavaScript, las plataformas ven dos eventos con una event_id.

Verificación:

• Network tab de DevTools: deberías ver cargarse el script del pixel de la plataforma y el request en formato pixel de la plataforma disparar al evento.
• Tab Logs de Beaconry: la entrada de log del evento server-side muestra la misma event_id que el evento del lado navegador en DevTools.
• Vista de debug de la plataforma (Meta Test Events, TikTok Test Events, Campaign Manager de LinkedIn): el evento llega una vez, no dos. Si lo ves dos veces en la vista de debug, algo en tu generación de event_id no es determinista.

Posición de partida recomendada

Por defecto modo híbrido apagado en todos los canales. Server-side por sí solo cubre el 100 % de los visitantes con consentimiento y es más rápido en la página. Activa híbrido por canal cuando tengas un problema concreto de match-rate que está causando el canal, el aviso "Match Quality is Poor" de Meta es el disparador más común, GA4 y TikTok rara vez lo piden.

Reevalúa cada trimestre. El valor relativo del modo híbrido se desplaza según las plataformas ajusten sus ventanas de atribución, según suban las tasas de adblock, según cambie la composición de tu audiencia. El toggle es reversible; sobreusar el modo híbrido cuesta silenciosamente bytes y limpieza de CSP sin comprar match-rate proporcional.

Para llevar

El modo híbrido no es una feature de "más es mejor". Es una herramienta precisa para un problema específico: mejorar match-rate en plataformas que dependen de cookies first-party para la atribución. Server-side por sí solo es el default correcto; el híbrido es la respuesta correcta cuando el reporting de la plataforma te dice que el match-rate es el cuello de botella. La event_id estable es lo que mantiene honesto el trade-off, el mismo evento enviado desde dos fuentes, deduplicado a uno, con la plataforma eligiendo la señal más rica.