Cuando configurás un pixel de conversión en Meta Ads o Google Ads, estás diciéndole a una plataforma de terceros que se registre en el navegador del usuario y te reporte cuándo ocurre una conversión. Es cómodo, tarda minutos en configurar, y durante mucho tiempo fue suficiente. Hoy, para una parte creciente del tráfico, no lo es.
Por qué el pixel de browser pierde conversiones
El pixel de conversión funciona con cookies de terceros y con JavaScript que corre en el navegador del usuario. Tres mecanismos distintos bloquean esa lectura:
- ITP (Intelligent Tracking Prevention) en Safari. Apple introdujo ITP para limitar el tracking cross-site. En versiones actuales de Safari, las cookies de terceros se eliminan agresivamente y el JavaScript del pixel tiene acceso restringido al almacenamiento del navegador.
- Bloqueadores de anuncios y extensiones de privacidad. uBlock Origin, AdGuard, y extensiones similares bloquean los dominios de tracking conocidos (pixel.facebook.com, googletagmanager.com, etc.) antes de que el script se ejecute.
- Navegadores con bloqueo nativo. Firefox y Brave bloquean por defecto buena parte del tracking basado en cookies de terceros. No requieren extensión adicional.
El resultado: el pixel reporta menos conversiones de las que realmente ocurren. Las plataformas de ads entonces ven una tasa de conversión artificialmente baja y sus algoritmos de optimización aprenden de datos incompletos. El problema no es que el pixel "no funcione" — funciona para los usuarios que no tienen bloqueo. El problema es que la proporción de usuarios con algún tipo de bloqueo activo es suficientemente alta como para distorsionar los resultados.
Qué hace la atribución server-side
En lugar de depender de JavaScript en el navegador del usuario, la atribución server-side registra el evento de conversión en el backend de tu propio servidor y lo envía a la plataforma de ads (o a tu sistema de analítica) desde ese servidor. El flujo es:
- El usuario completa una acción de conversión (compra, formulario, cotización).
- Tu servidor recibe el evento de conversión y lo registra en tu base de datos.
- Tu servidor envía el evento a la API de conversiones de Meta, la API de Google Ads conversions, o a tu sistema de analítica.
- La plataforma de ads recibe el evento directamente desde tu servidor, sin depender del navegador del usuario.
El bloqueo del navegador ya no importa porque el evento nunca pasa por el navegador. La única cosa que el usuario puede bloquear es la cookie de primer partido que identifica la sesión — pero esa cookie es tuya, no de terceros, y los navegadores modernos la respetan.
La arquitectura en la práctica
Una implementación de atribución server-side tiene tres componentes:
1. Identificador de sesión de primer partido. Cuando el usuario llega a tu sitio, tu servidor genera un ID de sesión y lo escribe en una cookie de primer partido (tuya, no de Meta ni Google). Esta cookie persiste en navegadores con ITP porque es cookie first-party.
2. Registro del touchpoint de llegada. Cuando el usuario llega desde un ad, la URL trae parámetros de atribución (gclid para Google, fbclid para Meta). Tu servidor captura esos parámetros y los asocia al ID de sesión. Los parámetros quedan en tu base de datos, no en el LocalStorage del navegador.
3. Envío del evento de conversión. Cuando ocurre la conversión, tu servidor recupera el ID de sesión y los parámetros de atribución asociados, y los envía a la API de conversiones de la plataforma correspondiente junto con los datos del evento (valor de la conversión, tipo, timestamp). Meta y Google reciben el evento y lo asocian al ad que generó el click original.
El resultado es que la plataforma de ads recibe conversiones que el pixel de browser nunca habría podido reportar. Los algoritmos de optimización aprenden de un dataset más completo. El CAC calculado sobre datos server-side es más cercano al CAC real que el calculado solo sobre datos del pixel.
Cuándo importa la diferencia
No todas las audiencias tienen la misma tasa de bloqueo. Los factores que aumentan la proporción de usuarios con bloqueo activo:
- Audiencia técnica (desarrolladores, IT, producto digital): alta adopción de bloqueadores y Firefox/Brave.
- Usuarios de iPhone con Safari: afectados por ITP en distintos grados según la versión de iOS.
- Mercados europeos con alta conciencia de privacidad: mayor adopción de extensiones.
- Contenido de alto valor percibido que atrae usuarios con perfil técnico.
Si tu tráfico tiene una proporción alta de cualquiera de estos segmentos, la brecha entre lo que reporta el pixel y lo que ocurre realmente puede ser lo suficientemente grande como para distorsionar las decisiones de budget. La atribución server-side no reemplaza el pixel — los complementa: el pixel reporta en tiempo real en la interfaz de la plataforma, el server-side captura lo que el pixel no puede. El resultado final es más completo que cualquiera de los dos por separado.
Cómo implementa esto Autonomah
En el modelo de embudo directo, Autonomah controla el endpoint de conversión. Eso significa que todos los eventos de conversión pasan por el backend de Autonomah antes de llegar a la plataforma de ads. La implementación es la arquitectura descrita arriba: cookie first-party para el ID de sesión, captura de parámetros de atribución en el servidor, envío via Conversions API.
El tenant no necesita implementar nada: la atribución server-side está incluida en la configuración del canal. Los datos de atribución están disponibles en el dashboard desagregados por canal, por pieza de contenido, y por segmento de audiencia.
¿Querés ver cómo funciona la atribución en tu vertical?
En el discovery preparamos un demo con datos sintéticos de tu industria.
Agendar discovery