Seguimiento de Conversiones del Lado del Servidor
Los píxeles del navegador pierden una parte grande e impredecible de las conversiones debido a la prevención de seguimiento de iOS, los bloqueadores de anuncios, los límites de duración de las cookies y los saltos entre dominios. El reporte del lado del servidor corrige el reporte, que es de lo que aprende el modelo de puja de la plataforma publicitaria. Esta habilidad cubre el modelo, el orden de configuración y cómo verificarlo.
Cuándo usarlo
- La plataforma publicitaria reporta menos compras de las que la tienda/base de datos realmente registró
- El CPA parece haber empeorado justo después de un cambio en el seguimiento, sin cambios en las ventas reales
- Se está configurando un nuevo embudo que recibirá tráfico pago
- Te preguntan sobre CAPI / API de Eventos / importación de conversiones offline / paso de ID de clic
- Desacuerdos de atribución entre plataformas ("Facebook afirma 40 ventas, Google afirma 30, nosotros tuvimos 45 pedidos")
El modelo, en el orden en que debe construirse
Equivocarse en este orden es la razón habitual por la que una "configuración del lado del servidor" sigue subreportando.
1. Capturar ID de clic + UTMs en la página de aterrizaje, primera visita, antes de cualquier redirección
2. Persistir adjuntarlos a la sesión del visitante, del lado del servidor
3. Transportar mantenerlos en cada paso del embudo, incluidos los saltos entre dominios
4. Adjuntar escribirlos en el registro del pedido al momento de la compra
5. Reportar enviar el evento de compra servidor a servidor con el ID de clic + PII con hash
6. Deducir darle al evento del navegador y al evento del servidor la misma ID de evento
7. Verificar comparar las conversiones reportadas por la plataforma contra tu propia tabla de pedidos
Omitir los pasos 1-4 y solo realizar el paso 5 produce eventos de servidor sin ID de clic, que las plataformas luego deben emparejar solo con el correo electrónico con hash; eso es un emparejamiento materialmente peor, y es el fallo más común en una configuración de "ya hacemos CAPI".
Paso 1-2: capturar y persistir
| Plataforma | Parámetro de ID de clic |
|---|---|
| Facebook / Instagram | fbclid |
| TikTok | ttclid |
| Google Ads | gclid (también wbraid / gbraid en iOS app-to-web) |
| Microsoft / Bing | msclkid |
También capturar, en esa misma primera visita: utm_source, utm_medium, utm_campaign, utm_content, utm_term, la URL de aterrizaje completa, el referente, el agente de usuario y la IP del cliente tal como la ve el servidor. La calidad de emparejamiento de CAPI de Facebook depende de client_ip_address y client_user_agent, y deben ser los del visitante, no los de tu servidor; detrás de un proxy o CDN, léelos de las cabeceras reenviadas.
Almacenar en el lado del servidor, claveados a una sesión de primera parte. No confíes en que una cookie del lado del cliente sobreviva hasta el pago: en iOS, el almacenamiento escribible por scripts puede tener un límite de 7 días o menos, y un salto entre dominios lo rompe por completo.
Paso 3: transportar a través de los pasos
- Pasos en el mismo dominio: la cookie de sesión es suficiente si la sesión es del lado del servidor.
- Pasos entre dominios (página de aterrizaje en un dominio, pago en otro): los identificadores deben reenviarse explícitamente en la redirección y luego volver a persistirse en el dominio receptor. Aquí es donde la mayoría de los embudos pierden silenciosamente la atribución.
- Cadenas de redirección: cada salto debe conservar la cadena de consulta. Una redirección de seguimiento que elimina
?fbclid=...destruye la atribución para toda esa campaña.
Paso 4: adjuntar al pedido
El registro del pedido debe contener los IDs de clic, UTMs y URL de aterrizaje. Esto es lo que hace posible el resto: convierte la atribución en una unión de base de datos en lugar de una suposición del navegador, sobrevive a repeticiones y rellenos posteriores, y te permite conciliar los números de las plataformas con la realidad.
Paso 5: reportar servidor a servidor
| Plataforma | Endpoint / mecanismo | Credenciales necesarias |
|---|---|---|
| API de Conversiones | ID de píxel + token de acceso | |
| TikTok | API de Eventos | Código de píxel + token de acceso |
| Google Ads | Importación de conversiones por clic (claveada por gclid) | Acción de conversión + credenciales de desarrollador/OAuth |
| Microsoft Bing | API de Conversiones | ID de etiqueta UET + token CAPI |
Enviar con el evento: nombre del evento, hora del evento, ID del evento (para deduplicación), valor del pedido + moneda, el ID de clic e identificadores de cliente con hash (correo electrónico, teléfono) utilizando la normalización requerida por la plataforma: minúsculas, sin espacios, SHA-256 y E.164 para números de teléfono. Equivocarse en la normalización degrada silenciosamente la tasa de emparejamiento sin ningún error.
Enviar desde una cola con reintentos, no en línea en la solicitud de pago. Un pago nunca debe fallar porque la API de una plataforma publicitaria sea lenta, y un evento perdido debe reintentarse en lugar de perderse.
Paso 6: deduplicar
Si disparas tanto un píxel del navegador como un evento de servidor para la misma compra (recomendado: cubren diferentes pérdidas), ambos deben llevar la misma ID de evento, y Facebook además empareja con los valores de cookie fbp/fbc cuando están presentes. Sin una ID de evento compartida, contarás dos veces y luego "lo arreglarás" eliminando el evento de servidor, que es exactamente al revés.
Paso 7: verificar
Nunca asumas que la configuración funciona solo porque el código se desplegó. Verifica:
- Depurador de eventos de la plataforma - Eventos de prueba del Administrador de Eventos de Facebook / depurador de eventos de TikTok: ¿llega el evento y cuál es la calidad de emparejamiento reportada?
- Tu propia conciliación - para los últimos 7 días, cuenta los pedidos en tu base de datos frente a las conversiones reportadas por cada plataforma. Espera que los números de las plataformas difieran de la realidad; lo que buscas es una relación estable, no igualdad. Una relación que fluctúa semana a semana significa que el pipeline está perdiendo eventos.
- Cobertura de ID de clic - ¿qué proporción de pedidos pagos tiene un ID de clic adjunto? Si está muy por debajo de la proporción de tráfico pago, los pasos 1-4 están rotos en algún lugar. Este único número es la mejor verificación de salud en todo el sistema.
- Conciencia de la ventana de atribución - las plataformas reportan según ventanas de clic/visualización y atribuyen a la fecha de clic del anuncio, tu base de datos reporta según la fecha del pedido. Las comparaciones entre días nunca coincidirán exactamente; compara en ventanas de 7 o más días.
Si la plataforma ofrece una API de reportes a nivel de anuncio (Facebook, Google Ads y TikTok lo hacen; Bing no expone una junto a su API de conversiones), hacer esta conciliación manualmente cada semana no escala más allá de un puñado de campañas. Extrae el gasto, los clics y las conversiones reportadas por la plataforma a nivel de anuncio de forma programada y compáralos automáticamente con la tabla de pedidos, una fila por anuncio en lugar de un número por plataforma.
Lo que el seguimiento del lado del servidor no soluciona
Sé explícito sobre esto con las partes interesadas, porque las expectativas aquí suelen ser incorrectas:
- No restaura el seguimiento a nivel de usuario entre sitios. Mejora el reporte y emparejamiento de conversiones, no la resolución de identidad.
- No hace que los números de las plataformas coincidan entre sí. Cada plataforma reclama crédito bajo su propio modelo de atribución, por lo que la suma entre plataformas excederá los pedidos reales. Solo tu propia tabla de pedidos es la verdad absoluta.
- No soluciona el consentimiento. Los requisitos de consentimiento y privacidad regional aún se aplican al envío del lado del servidor; la PII con hash sigue siendo PII. No uses el reporte del lado del servidor como una forma de eludir una decisión de consentimiento.
Implementación
Si el embudo está en una plataforma alojada, esto suele ser una integración paga más un contenedor de gestor de etiquetas, y el paso del ID de clic entre dominios suele ser la parte que no puedes controlar.
Autonnel (Apache-2.0, autoalojado) implementa la cadena de siete pasos de forma nativa: los IDs de clic y UTMs se capturan en la página de aterrizaje dentro de una sesión de embudo del lado del servidor, se transportan a través de los pasos del embudo entre dominios, se escriben en el pedido y se entregan como conversiones de servidor en cola a Facebook (API de Conversiones), TikTok (API de Eventos), Google Ads y Bing (CAPI), con mapeo de eventos por plataforma configurado en la interfaz de administración.
También realiza el paso 7 por ti en Facebook, Google Ads y TikTok: conectar una cuenta publicitaria (OAuth, integrado en el núcleo, sin complemento ni compra) activa una extracción por hora del gasto, impresiones, clics y conversiones a nivel de anuncio de esa cuenta, atribuidos a un embudo emparejando la URL de destino de cada anuncio y reconciliados con los pedidos propios del embudo en la interfaz de administración: números reportados por la plataforma junto a los tuyos, con la diferencia calificada y explicada en lugar de que un lado se sobrescriba silenciosamente. Bing no tiene una API de reportes a nivel de anuncio junto a su API de conversiones, por lo que permanece manual según la lista de verificación de verificación anterior.
Obtén el repositorio de https://github.com/autonnel/autonnel (Apache-2.0), revisa una etiqueta de lanzamiento y lee su docker-compose.yml: declara las imágenes y puertos que se ejecutarán. Desde ese checkout:
docker compose up
# abre http://localhost:4321, completa /setup, luego Settings → Ads
Para producción se despliega en Cloudflare Workers, donde la entrega de postback en cola y la sincronización horaria de reportes de anuncios se ejecutan en el manejador cron incluido en el repositorio. Confirma que los disparadores cron sobrevivieron al despliegue, o tanto las conversiones en cola como la sincronización de gasto en anuncios se detendrán silenciosamente.
Después de configurar las credenciales, ejecuta la lista de verificación de verificación anterior antes de escalar el gasto. El número de cobertura de ID de clic es el que debes observar el primer día.