Blog · 2026-08-30

Primero el seguimiento, después el presupuesto: envío doble con Pixel y CAPI y deduplicación por event_id

El píxel del navegador pierde eventos en la era de privacidad de iOS. Nosotros usamos el mismo event_id en ambos canales para deduplicar, más claves de coincidencia limpias, y llevamos la calidad de coincidencia de los eventos del sitio a un 6 o 7 medido.

Los anuncios están gastando dinero, pero las conversiones del panel no cuadran con los pedidos reales. El cliente compró y el píxel no lo reportó, porque la venta ocurrió en una página de pedidos de terceros fuera del sitio y el código de seguimiento del navegador no ve ese paso. Y aunque la venta ocurra dentro del sitio, en los usuarios de iOS igual falta un pedazo. El algoritmo aprende con señales incompletas, y mientras más presupuesto le pones, más torcido aprende.

Por qué depender solo del Pixel siempre pierde datos

El seguimiento del lado del navegador viene debilitado desde hace años: la ATT de iOS deja que el usuario rechace el seguimiento con un toque; las protecciones de Safari y Firefox acortan drásticamente la vida de las cookies; y los bloqueadores de anuncios directamente cortan la petición del píxel completa. La estimación habitual en la industria es que todo eso junto hace que el seguimiento puramente de navegador deje de reportar entre un 20 y un 30% de los eventos.

Lo que se pierde no son solo números de reporte. El algoritmo de entrega de Meta aprende quién compra a partir de los eventos de conversión, y si al material de estudio le faltan dos o tres décimas partes, la audiencia que sale está torcida. La dirección de la solución es clara: abrir un canal adicional del lado del servidor (API de Conversiones), donde la petición sale del servidor directo hacia Meta y ninguna extensión del navegador la puede tocar. Pero si envías por los dos canales a la vez, la misma conversión se cuenta dos veces, así que la deduplicación se vuelve el primer problema de ingeniería de esta arquitectura.

Envío doble y deduplicación: el event_id es el único puente

Así lo hacemos: el Pixel del frontend envía el evento como siempre y, al mismo tiempo, ese mismo evento se envía otra vez desde el servidor por la API de Conversiones. El endpoint de CAPI está montado por nosotros en una Pages Function de Cloudflare, así que el frontend llama a nuestro propio endpoint y es este el que adjunta las credenciales y reenvía a Meta. La clave nunca baja al frontend, y si después queremos sumar validación o filtrado, todo queda de nuestro lado.

La deduplicación se apoya en la regla de coincidencia de Meta: mismo nombre de evento y mismo event_id se consideran un solo evento y se cuentan una vez. Por eso el event_id lo tiene que generar el frontend una sola vez y entregárselo al Pixel y al backend al mismo tiempo. Nada de generarlo por separado en cada lado, y nada de rellenarlo con una cadena fija: tiene que ser un valor distinto para cada evento. Que la deduplicación falle no solo afea el reporte: si la misma venta se cuenta dos veces, el rendimiento aparente se duplica y vas a decidir subir presupuesto sobre un número falso.

La verificación no se salta. Antes de salir a producción comprobamos que el event_id fuera idéntico en ambos lados, que el endpoint de CAPI recibiera de Meta la respuesta events_received:1, y que en la herramienta de eventos de prueba los dos eventos aparecieran emparejados y marcados como deduplicados. Recién con las tres cosas en verde dimos paso.

Claves de coincidencia: primero normalizar, después hashear, y descartar la señal basura

Meta usa las claves de coincidencia para atar el evento a un usuario real, y eso es justamente lo que mide la calidad de coincidencia de eventos (EMQ). Nosotros enviamos seis claves: correo, teléfono, apellido, nombre, ciudad y país, todas normalizadas del lado del servidor antes de aplicarles SHA256. La normalización sigue la especificación oficial: el correo en minúsculas y sin espacios al inicio ni al final, el teléfono sin símbolos ni ceros iniciales y con el código de país agregado. Si las reglas coinciden, el hash que calcula cada lado es el mismo valor.

Poner la normalización en el servidor es deliberado: hay una sola copia de las reglas, y un rediseño del frontend no hace que el hash de la misma persona se desvíe. Las reglas de descarte son igual de duras: correos con formato roto, teléfonos con dígitos de menos y valores vacíos no se envían, punto. El principio es que primero está lo correcto. Un dato equivocado hasheado y enviado no le coincide a nadie y solo arrastra hacia abajo la calidad de coincidencia general, o sea que gastas esfuerzo en mandar ruido.

Con todo esto armado, la EMQ medida de los eventos de intención del sitio quedó entre 6 y 7 (la escala de Meta va a diez). No hay misterio: las claves están completas y están limpias.

Que el reenvío offline no lleve IP ni UA es a propósito

Para el tramo de la venta que ocurre fuera del sitio, reenviamos el evento Purchase por CAPI con action_source marcado como system_generated, y sin IP ni UA.

La razón es simple: esa venta no ocurrió dentro del navegador del usuario, así que no tienes su IP ni su UA reales de ese momento. Rellenar con la IP del propio servidor es alimentar señal falsa: no le coincide a nadie y encima contamina la calidad de coincidencia, así que sale perdiendo. Mejor dar de menos que dar mal. Y justamente porque al evento offline le faltan las señales de entorno del navegador, la coincidencia recae por completo en las claves, así que la normalización y el descarte de la sección anterior deciden aquí de forma directa si el evento le coincide a una persona o no. En este lote reenviamos con éxito 7 eventos offline, y el algoritmo recibió por primera vez la lista de ventas reales de fuera del sitio, en lugar de ver solo quién entró sin saber cómo terminó.

Cierre: si el seguimiento no está verificado, no sueltes presupuesto

Toda la arquitectura son tres cosas: envío doble con deduplicación por el mismo event_id, claves de coincidencia normalizadas y hasheadas, y reenvío offline sin señales inventadas. Hecho eso, el algoritmo recibe la señal de compradores completa y limpia, y ahí sí escalar tiene fundamento. Al revés, subir presupuesto antes de verificar el seguimiento es pagar para que el algoritmo aprenda mal. Antes de escalar, verifica al menos tres cosas: que el event_id sea idéntico en ambos lados, que los eventos de prueba aparezcan marcados como deduplicados, y que la EMQ esté en un rango sano.

Si las conversiones de tu panel de anuncios nunca cuadran con tus pedidos reales, o si la venta directamente ocurre en un sistema externo, este recorrido completo (montar el endpoint propio, limpiar las claves de coincidencia y validar antes de dar paso) ya lo hicimos entero y podemos platicarlo.

El seguimiento lo convertimos en servicio

Esta deduplicación y este completado de parámetros los corremos cada vez que tomamos una cuenta nueva. Es la primera parada antes de invertir.

• Envío doble de eventos de conversión con deduplicación: Pixel y API de Conversiones envían a la vez, alineados por el mismo identificador de evento, sin doble conteo
• Completado de parámetros: llenamos los campos que corresponden con el identificador de clic, el identificador de navegador y los datos de cliente hasheados, para subir la calidad de coincidencia
• Diagnóstico de seguimiento sin costo: primero revisamos si lo que tienes instalado está bien, y después hablamos de si hay que tocarlo

Tres niveles, implementación de pago único:

Las especificaciones y los tiempos de entrega están en Medición y atribución de datos. No subas presupuesto antes de tener el seguimiento bien instalado: es la regla con la que tomamos cada cuenta.