Tracking pese a la pérdida de consent

La pérdida de tracking depende mucho del setup — la pregunta no es si pierdes, sino cuánto.

Tracking de navegador clásico sin server-side: una pérdida de datos del 30–50 % es hoy el estándar. En audiencias muy de iOS (premium, salud, belleza) más hacia el 50 %; en audiencias B2B muy de Android, hacia el 30 %.

Con un setup server-side y CAPI: la match rate sube al 70–90 % — según la calidad de los datos (email hasheado, teléfono hasheado, click ID, IP).

Con un data lake propio: más del 95 % de retención de datos, porque no dependes de los informes de las plataformas, sino que analizas tus propios datos en bruto.

Lo que es «normal» no dice nada sobre lo que es posible. Una pérdida del 30–50 % es frecuente — pero no significa que tengas que aceptarla.

Hay tres métricas clave — y las tres se pueden comprobar de forma concreta.

1. Event match rate (EMQ en Meta): visible en el Meta Events Manager. Valores por debajo de 6.0 (de 10) son críticos, 7.0–8.5 es bueno, 9.0+ es muy bueno. Un EMQ bajo significa: Meta no puede asignar tus eventos a perfiles de usuario — la optimización sufre.

2. Discrepancia server-side vs. navegador: en el contenedor del Tag Manager, compara el número de eventos server-side vs. píxeles de navegador. Con un setup limpio, el server-side debería ver entre un 15 y un 30 % más de eventos que el navegador — de lo contrario se pierde la ventaja del server-side.

3. Informe de plataforma vs. ventas reales: la prueba más honesta — compara las conversiones del informe de Meta o Google con los pedidos reales del backend de la tienda. Una discrepancia por debajo del 10 % es muy buena, 10–20 % es normal, más del 20 % significa tracking roto.

Lo que estos valores dicen sobre tu stack: las tres métricas deben estar en verde al mismo tiempo.

Una de las preguntas más frecuentes — y una de las peor entendidas. La respuesta corta: necesitas ambos, en paralelo.

El píxel (tracking de navegador) ve todo lo que pasa en el navegador (parámetros UTM, click IDs, referrer), pero está muy limitado por la ITP, los adblockers y el rechazo del consentimiento.

CAPI (Conversions API) envía conversiones de servidor a servidor, independiente del navegador. No lo bloquean ni la ITP ni los adblockers. Necesita datos más ricos (email hasheado, teléfono, IP, user agent) para un buen matching.

Con event deduplication, Meta detecta automáticamente si un evento vino del píxel y de CAPI — y lo cuenta solo una vez. Obtienes las ventajas de ambos mundos: datos de clic del navegador + robustez server-side.

Regla general: el píxel solo ya no basta hoy. CAPI solo pierde la atribución de clic. Ambos juntos con una deduplication limpia es el estándar.

El server-side no es automáticamente conforme al RGPD, pero es una mejor base para la conformidad con el RGPD que el tracking de navegador puro.

• Lo que el server-side permite: pseudonimización en el servidor (hashear email/teléfono/IP), compartición selectiva de datos por plataforma, audit logs para todas las transferencias de datos, control sobre los subencargados
• Lo que el server-side no resuelve: la obligación de consentimiento (el consentimiento del usuario sigue siendo necesario), la transferencia de datos a EE. UU. (el riesgo Schrems II persiste), la obligación de banner de cookies para cookies first-party
• Lo que necesitas: una consent management platform (Cookiebot, Usercentrics), una política de privacidad que mencione el server-side tracking, en su caso una DPIA, acuerdos contractuales con los subencargados — lo configuro de forma estándar.

BigQuery es la pregunta estratégica detrás del server-side tracking — y merece la pena más a menudo de lo que se cree.

Lo que cuesta BigQuery al mes: en setups medianos (1–5 M de eventos/mes) típicamente 30–100 € de almacenamiento + costes de consulta. Escala linealmente con el volumen.

Regla general: si te tomas en serio el tracking y ves los datos como un activo a largo plazo, BigQuery (o un equivalente como Snowflake) es la inversión única que tendrás que hacer en algún momento de todos modos. Cuanto antes, más barato.

• Cuándo BigQuery tiene sentido: más de 100k pageviews/mes (si no, el sampling de GA4 es crítico), varias fuentes de datos que conectar, modelos de atribución propios, requisitos de cumplimiento para datos en bruto propios
• Cuándo está sobredimensionado: sitios pequeños con un funnel claro y un solo canal, sin recursos de SQL/dbt en el equipo, basta con un reporte puro de performance

Sí — y entonces a menudo es especialmente valioso. Un setup server-side no significa automáticamente un buen setup — muchas implementaciones siguen dejando un 30–50 % de los datos sin aprovechar sin que nadie lo note.

Lo que obtienes: un chequeo de match rate, verificación de event deduplication, reconciliación píxel ↔ CAPI ↔ ventas reales. Además, un plan de acción con palancas de optimización concretas.

Hallazgos típicos en setups existentes: triggers mal configurados en el contenedor sGTM, user properties faltantes en CAPI, campos de optimización sin usar, el modo Enhanced Conversion sin activar.

Cómo funciona la colaboración: aclaro los hallazgos técnicos directamente con tu equipo de desarrollo o agencia externa. Sin cambio de proveedor necesario.