Servicio
Server-side tracking y event forwarding
Diseño y configuro flujos server-side para controlar eventos, deduplicación, identidad first-party y envíos a plataformas de activación.
Qué incluye
- 01
Arquitectura de eventos client-side y server-side.
- 02
Configuración con Tealium EventStream, server-side GTM o Adobe Event Forwarding según el alcance.
- 03
Integraciones con Meta Conversions API, Google Enhanced Conversions o Measurement Protocol.
- 04
Reglas de deduplicación, identidad first-party y control de payloads.
- 05
Pruebas, monitorización y documentación operativa.
Experiencia y criterio relacionados
-
Construido 2021–2024
Tracking server-side y atribución de paid media
Píxeles de paid media desplegados client-side y server-side, con el enrutado sobre Tealium EventStream y GTM server-side. Los identificadores salían hasheados desde el navegador, validados antes de hashear y solo si el consentimiento lo permitía. La plataforma procesaba decenas de millones de eventos al mes.
- EventStream
- Server-side GTM
- Paid media
- Atribución
-
Construido 2018–2021
SDKs de analítica en iOS y Android, e integraciones híbridas
Implementación de los SDKs nativos y resolución de las integraciones híbridas entre la capa nativa y la web embebida. Es donde se pierden las sesiones y las identidades, y no se mira hasta que los números dejan de cuadrar.
- iOS
- Android
- SDK
- App híbrida
-
Construido 2018–2021
Tagging server-side con clientes propios, cuando sGTM acababa de salir
Un contenedor server-side con clientes propios, no solo los de serie. Uno para la recogida heredada, otro para la nueva y otro de plataforma publicitaria, más peticiones salientes a una API propia. El contenedor está exportado en marzo de 2021, con la herramienta recién salida.
- Server-side GTM
- Clientes propios
- Recogida
Preguntas frecuentes
¿El tracking server-side esquiva los bloqueadores?
No, y quien lo venda así te está vendiendo un problema. Reduce la dependencia del navegador y mejora la calidad del dato que llega a los destinos, pero un usuario que rechaza el consentimiento sigue fuera. El objetivo es control y calidad, no recuperar cobertura por la puerta de atrás.
¿Hace que la web cargue más rápido?
Puede ayudar, pero no es un proyecto de rendimiento. Mover etiquetas al servidor quita trabajo al navegador, y cuánto se nota depende de cuántas había y de qué hacían. Si el objetivo principal es la velocidad, primero conviene medir qué está costando cada etiqueta.
¿Con qué plataforma se monta?
Con la que ya tengas: Tealium EventStream, server-side GTM o Adobe Event Forwarding. La decisión sale del stack actual y de dónde vive el consentimiento, no de una preferencia mía. Si hay que elegir desde cero, eso es selección de plataforma y va aparte.
¿Vale si ya tenemos el consentimiento implementado?
Sí, y suele ser justo donde aparece el problema. El consentimiento resuelto en el navegador no viaja solo hasta el servidor ni hasta el destino final. Comprobar que llega, y que llega con el mismo significado, es parte del trabajo.
¿Encaja con tu problema?
Cuéntame el contexto y te diré si este alcance es el adecuado o conviene empezar por otro sitio.