La época dorada del Marketing Digital ha terminado. Durante una década, los especialistas en marketing pudieron copiar y pegar un píxel de Facebook en el encabezado y rastrear todo mágicamente. Luego vino el RGPD. Luego Safari ITP (Prevención de seguimiento inteligente). Luego iOS 14.5 (Transparencia de seguimiento de aplicaciones). Luego, la adopción de AdBlock alcanzó el 30%. Y finalmente, Chrome Phase 3 elimina la cookie de terceros.

Si todavía dependes de los píxeles de JavaScript del lado del cliente, estás perdiendo 20-30% de tus datos. Estás gastando presupuesto en anuncios que generan ventas, pero el algoritmo cree que no es así, por lo que deja de mostrar el anuncio. Esta es la crisis de la “pérdida de señal”.

En Maison Code Paris, migramos marcas de 8 cifras al Server-Side Tagging (SGTM). Esto no es sólo “Análisis”; es “Infraestructura de datos”. Mueve la lógica de seguimiento desde el navegador del Usuario (entorno bloqueado y no confiable) a Su Servidor (entorno desbloqueado y confiable).

Por qué Maison Code habla de esto

En Maison Code Paris, actuamos como la conciencia arquitectónica de nuestros clientes. A menudo heredamos stacks “modernos” construidos sin una comprensión fundamental de la escala.

Discutimos este tema porque representa un punto de inflexión crítico en la madurez de la ingeniería. Implementarlo correctamente diferencia un MVP frágil de una plataforma resistente de nivel empresarial.

Por qué Maison Code centraliza los datos

Ya no confiamos en el navegador. Es un entorno hostil para la exactitud de los datos. Entre ITP, AdBlockers y GDPR, el seguimiento del lado del cliente no funciona. Implementamos SGTM para recuperar la Soberanía de Datos para nuestros clientes:

Control: Tú decides qué datos van a Facebook (hash de correos electrónicos, eliminación de PII).
Precisión: normalmente vemos un aumento del 20 % en los ingresos atribuidos después de cambiar a CAPI del lado del servidor.
Cumplimiento: aplicamos automáticamente el “Modo de consentimiento” a nivel del servidor, garantizando que no se filtren datos si el usuario opta por no participar.

Los beneficios: ¿Por qué optar por el lado del servidor?

1. Evite los bloqueadores de anuncios (contexto propio)

Los AdBlockers buscan solicitudes a facebook.com o google-analytics.com. En SGTM, el navegador envía datos a analytics.yourbrand.com. Dado que se trata de un subdominio de su sitio principal, se trata de una Solicitud propia. Los AdBlockers (generalmente) no lo bloquean, porque el bloqueo de solicitudes de origen daña el sitio web. Resultado: Recuperas ~15 % de los eventos perdidos.

2. Extensión de cookies (venciendo a ITP)

Safari elimina las cookies del lado del cliente (establecidas por JS) después de 7 días (o 24 horas si provienen de un enlace publicitario). Si un usuario hace clic en un anuncio el lunes, navega y regresa 8 días después para comprar, Facebook lo ve como un “nuevo usuario”. Se pierde la atribución. Las cookies configuradas por el servidor (encabezado Set-Cookie) son confiables. Duran hasta 2 años. SGTM le permite actualizar las cookies de marketing (_fbp, _ga) del servidor, manteniendo abierta la ventana de atribución.

3. Rendimiento de la página (Core Web Vitals)

Un sitio de lujo típico tiene: Facebook, TikTok, Pinterest, Snapchat, LinkedIn, GA4, Hotjar, Criteo. Son 8 bibliotecas de JavaScript pesadas que analizan el DOM en el hilo principal. Con SGTM, los eliminas todos. Cargas Un script (GTM). Envía Un flujo de datos a su servidor. Luego, su servidor lo distribuye entre los 8 proveedores de API a API. Resultado: TBT (tiempo total de bloqueo) 300 ms más rápido.

Guía de integración: el enfoque híbrido

No recomendamos pasar “100% del lado del servidor” inmediatamente. Usamos un enfoque híbrido con Deduplicación.

Para eventos como PageView o ViewContent, el navegador es mejor (captura el agente de usuario y tamaños de ventana específicos). Para eventos como “Compra”, el servidor es mejor (Precisión).

Para una configuración sólida, enviamos AMBOS.

El navegador envía “Compra” al píxel de Facebook.
El servidor envía “Compra” a Facebook CAPI.
Facebook recibe 2 eventos. Necesita saber que son la misma transacción.

La clave: ID del evento

Debes generar un event_id único y enviarlo con ambas transmisiones.

// utilidades/analytics.ts
función de exportación generarEventId() {
  devolver cripto.randomUUID(); // "a4b5c6..."
}

// Lado del cliente
const eventId = generarEventId();
fbq('pista', 'Compra', { valor: 100 }, { eventID: eventId });
dataLayer.push({ evento: 'compra', event_id: eventId });

Cuando Facebook ve dos eventos con ID “a4b5c6” dentro de 48 horas, descarta uno (Deduplicación). Si AdBlock bloqueó el evento del navegador, Facebook usa el evento del servidor. Si ambos llegan, Facebook usa el evento del navegador (generalmente datos más ricos) pero lo confirma con el evento del servidor. Esto maximiza la Calidad de coincidencia de eventos (EMQ).

Arquitectura: Google Cloud Run

Alojamos el contenedor del servidor GTM en Google Cloud Run. ¿Por qué ejecutar en la nube? Escalado automático. El Black Friday, es posible que tengas 10.000 solicitudes por segundo. Cloud Run pone en marcha 50 contenedores. El martes a las 3 a.m., baja a 0 o 1. Pagas por lo que usas.

Configuración:

URL de transporte: apunte su Web GTM a https://analytics.maisoncode.paris.
Encabezado de vista previa: conecte el contenedor del servidor al contenedor web.
Clientes: El “Cliente GA4” en SGTM reclama la solicitud entrante y la convierte en un objeto de datos de evento.

Privacidad: redacción de datos

Esta es una enorme victoria en materia de cumplimiento. Cuando el navegador habla directamente con Facebook, Facebook ve todo (IP de usuario, encabezados, referencia). Cuando realiza proxy a través de SGTM, Usted controla los datos. Puedes:

Eliminar la dirección IP.
Hash de la dirección de correo electrónico (sha256(email)).
Eliminar parámetros de URL específicos (por ejemplo, restablecer tokens).
Bloquear el evento por completo si el usuario dio su consentimiento para “Análisis” pero no para “Marketing”.

Implementamos un filtro Modo de consentimiento en SGTM. Si el encabezado “x-consent-marketing: denegado” está presente, la etiqueta CAPI de Facebook no se activa.

Ingeniería de costos

SGTM cuesta dinero (uso del servidor + ancho de banda). Un sitio con mucho tráfico puede costar entre 200 y 500 dólares al mes. Optimización: Filtra eventos inútiles. No envíe eventos scroll a su contenedor de servidor si no los necesita para CAPI. Configure la etiqueta de configuración GA4 para excluir eventos de alto volumen y bajo valor del flujo del servidor.

Patrón avanzado: el “cliente de datos”

En lugar de utilizar el protocolo GA4, estamos viendo un cambio hacia Conectores JSON genéricos. Creamos un punto final personalizado /api/collect. La interfaz PUBLICA una carga útil JSON limpia:

{
  "evento": "pedido_realizado",
  "carga útil": { "id": "123", "total": 500 },
  "contexto": { "user_id": "u_999" }
}

El “Cliente JSON” de SGTM lo ingiere. Esto desacopla su capa de datos integral de las idiosincrasias de Google Analytics.

10. Persistencia de datos: seguimiento de auditoría de Firestore

El GTM estándar es efímero. Los datos fluyen y desaparecen. ¿Qué sucede si desea auditar “Cada agregado al carrito” por razones legales? En SGTM, agregamos una Etiqueta Firestore Writer. Cada evento válido se escribe en una colección analytics_logs/{date}/{eventId}. Esto nos brinda un registro de auditoría permanente y consultable (BigQuery) de cada punto de datos enviado a Facebook. Si Facebook afirma “Sin conversiones”, podemos consultar nuestros propios registros para demostrar que están equivocados.

11. Estrategias de control de costos (el problema de los €500)

Cloud Run puede resultar costoso si te ataca una botnet. Implementamos Filtrado de bots en el ingreso. En app.yaml, bloqueamos los agentes de usuario que coinciden con patrones de bot conocidos antes de que activen una instancia de contenedor. También utilizamos Límite de memoria (512 MB) para evitar que una pérdida de memoria en una plantilla personalizada afecte la factura. SGTM debería costar el 1% de su gasto en medios. Si es más, estás sobreaprovisionado.

13. La puerta de enlace CAPI frente al SGTM completo

Facebook ofrece un “CAPI Gateway” (imagen de AWS). Es una versión simplificada y automatizada de SGTM.

Pros: Configuración con 1 clic. Sin mantenimiento.
Contras: Caja negra. No se pueden filtrar datos. No puedes evitar que envíe PII. Para el cumplimiento empresarial (GDPR), no podemos usar CAPI Gateway. Debemos ser dueños de la infraestructura (Full SGTM en Cloud Run) para garantizar que no estamos filtrando datos de los usuarios.

14. Mejorar el ROAS con conversiones sin conexión

No todas las ventas se realizan en línea. El usuario hace clic en Anuncio -> Navegación -> Llama al equipo de ventas -> Compra por teléfono. Facebook cree que el anuncio falló. Usamos SGTM para canalizar Conversiones sin conexión. Sales CRM (Salesforce) envía el evento “Cerrado ganado” a nuestro punto final SGTM con el fbp (ID del navegador de Facebook) capturado durante la navegación inicial. Facebook atribuye retroactivamente la venta al anuncio en el que se hizo clic hace 3 días. Esto mejora la visibilidad del ROAS en un 20 % para los artículos de alto precio.

15. Conclusión

El etiquetado del lado del servidor es la tabla “para adultos” del marketing digital. Requiere recursos de ingeniería. No es gratis. Pero es la única manera de construir un canal de datos sostenible y compatible con la privacidad que sobreviva a las guerras de los navegadores.

En Maison Code, creemos que los Datos de origen son el activo más valioso que po

¿Los datos no coinciden?

¿Shopify dice 100 pedidos, pero Facebook dice 60?

Implementar seguimiento del lado del servidor. Contrate a nuestros arquitectos.