Server-side tagging: dejar de medir con el navegador ajeno
Bloqueadores, Safari e iOS ya te quitaron entre 20% y 40% de las conversiones observadas. Mover la medición al servidor no es sofisticación: es recuperar datos que ya perdiste.
Escucha este artículo
El agujero que llevas meses tapando con estimaciones
Si tu reporte de Analytics no cuadra con el CRM, y la brecha crece cada trimestre, no es un error de configuración. Es el resultado acumulado de cookies de terceros restringidas, bloqueadores instalados por defecto en navegadores móviles y límites de expiración de cookies propias en Safari. En LATAM el efecto es fuerte por la altísima proporción de tráfico móvil.
La consecuencia práctica no es cosmética. Las plataformas de pauta optimizan sobre las conversiones que reciben. Si reciben 30% menos señales, el algoritmo aprende peor, sube el CPA y tú tomas decisiones de presupuesto sobre una foto incompleta.
Qué cambia con el tagging del lado del servidor
En lugar de que el navegador del usuario envíe eventos directamente a Meta, Google y el resto, tu sitio manda el evento a un contenedor propio en tu dominio, y ese contenedor reenvía a las plataformas. Tres consecuencias inmediatas:
- Los bloqueadores dejan de ver destinos de terceros. El evento viaja a tu propio dominio.
- Controlas qué se envía. Puedes recortar parámetros sensibles antes de que salgan, lo cual importa mucho para cumplimiento de privacidad.
- Puedes enriquecer. El evento sale con datos que el navegador no tenía: valor real del pedido tras validación, margen, estado de crédito.
Lo que no arregla
Conviene ser claro, porque se vende como bala de plata y no lo es. El server-side tagging no crea consentimiento donde no lo hay: si el usuario rechazó el rastreo, sigue rechazado. No arregla una taxonomía de eventos mal diseñada; si tus nombres de eventos son un desastre, ahora será un desastre más rápido. Y no elimina la necesidad de modelado: siempre habrá una porción no observable.
El orden correcto de implementación
Primero limpia el plan de medición: qué eventos importan, cómo se llaman, qué parámetros llevan. Segundo, monta el contenedor de servidor en un subdominio propio con certificado válido. Tercero, migra un solo evento crítico (compra o lead) y corre las dos rutas en paralelo dos semanas para comparar volúmenes. Cuarto, migra el resto y recién ahí apaga la ruta de navegador.
Saltarse el paralelo es el error que hemos visto arruinar proyectos: se apaga lo viejo, el volumen cae, nadie sabe si es pérdida real o error de configuración, y se pierden semanas de pauta a ciegas.
El costo de infraestructura es real pero modesto frente a lo que se recupera en eficiencia de pauta. La pregunta no es si migrar, es cuántos trimestres más vas a optimizar con datos incompletos.