"Llevaba 18 meses con ROAS reportado 3,4x. Cuando monté CAPI server-side con email y teléfono hasheados, descubrí que el ROAS real era 2,3x. La diferencia: 32% de conversiones que Meta se atribuía nunca tuvieron click ID. La culpa no era de Meta, era de iOS 17 borrando los fbclid antes de la compra."
Eso nos lo dijo el director de marketing de una marca D2C de complementos con 2,1M€ anuales. Llevaba 18 meses optimizando hacia un ROAS reportado de 3,4x. Cuando implementó CAPI server-side enriquecido con datos hasheados, descubrió que la atribución real era 2,3x. La causa: iOS 17 Link Tracking Protection borraba el 32% de los fbclid antes de que el usuario llegara al checkout. Meta atribuía esas ventas porque el pixel client-side disparaba, pero el click ID original se había perdido.
En 17 cuentas D2C España auditadas 2025-2026 con +35% tráfico iOS, la mediana de discrepancia entre ROAS reportado y real fue 32%. Las cuentas con CAPI server-side completo redujeron la discrepancia a 11%. Esta guía cubre qué cambió, qué resuelve CAPI y qué no, y el plan de 6 pasos para minimizar el daño.
iOS 17/18 borra fbclid/gclid/utm en Safari, Mail y Mensajes. Sin CAPI server-side, D2C con +35% tráfico iOS pierde 18-32% de atribución correcta. CAPI enriquecido con datos hasheados recupera 60-85% del gap. El 15-40% restante requiere AEM bien priorizado + MMM + geo-experiments. Plan de 6 pasos en 2-3 semanas.
Lo que vas a aprender
- Qué cambió exactamente con iOS 17/18 a nivel técnico.
- Cuánto se desploma la atribución en D2C españolas con tráfico iOS alto.
- Qué resuelve CAPI server-side y qué no.
- Cómo afecta al algoritmo de optimización y las audiencias lookalike.
- El plan de 6 pasos para minimizar el daño.
Qué cambió con iOS 17 e iOS 18
iOS 17 (septiembre 2023) · Link Tracking Protection. Apple limpia fbclid, gclid, utm cuando el usuario abre un anuncio Meta. Meta pierde el click ID. No hay forma de matchear la conversión con el click original.
iOS 17.4 (marzo 2024) · Ampliación. Apple extiende la lista de parámetros y los contextos: Mensajes, Mail, Safari privado y otros navegadores WebKit.
iOS 18 (septiembre 2024) · Private Relay + ITP reforzado. Cookies first-party de scripts third-party caducan a 7 días. La IP llega ofuscada cuando Private Relay está activo. La combinación de las tres hace que el tracking client-side pierda la mitad de su señal.
Efecto neto sobre D2C con +35% tráfico iOS: pérdida de 18-32% de eventos atribuidos correctamente. Sin CAPI server-side, el ROAS reportado es 25-40% superior al real.
Cuánto se desploma la atribución
En auditorías 2025-2026 en D2C con 35-55% de tráfico iOS y setups en píxel + CAPI básica:
Eventos Purchase atribuidos correctamente: -15 a -28% vs total real en Shopify.
Event Match Quality (EMQ): cae de 7,5 a 5,5-6 tras una actualización iOS.
Ventana 7d-click + 1d-view: pierde 30-45% de conversiones ocurridas, típico en ticket +150€ con ciclo +7 días.
Discrepancia ROAS reportado vs real: se abre del 18-22% habitual al 30-45%.
AEM sigue siendo crítico
AEM es el mecanismo por el que Meta agrega y modela conversiones de usuarios iOS que rechazan tracking o cuyo click ID se ha perdido.
Configuración obligatoria: 8 web events activos, Purchase en posición 1, AddToCart/InitiateCheckout/Lead en las siguientes, dominio verificado, SKAdNetwork para campañas de app.
Sin AEM bien priorizado, los usuarios iOS que rechazan tracking no se atribuyen de ninguna forma. La cuenta entera reporta peor de lo que rinde.
Qué resuelve CAPI server-side y qué no
Lo que CAPI resuelve (60-85% del gap):
- Eventos de iOS con click ID perdido.
- Conversiones ocurridas fuera de la ventana de atribución client-side.
- Cookies third-party bloqueadas.
- Navegadores con ITP reforzado.
Lo que CAPI no resuelve (15-40% restante):
- Usuarios con Private Relay activo + ATT rechazado.
- Compras como guest sin email en el checkout.
- Sesiones donde Apple ya borró fbc antes de que sGTM lo persistiera en cookie first-party.
La consecuencia operativa: CAPI es necesario pero no suficiente. El gap real se cubre combinando CAPI + AEM bien priorizado + modelado adicional propio (MMM, geo-experiments, holdout tests).
Cómo afecta al algoritmo y las audiencias lookalike
Doble impacto en el algoritmo de Meta:
Primero, las audiencias lookalike entrenadas con eventos de baja calidad (poco matching, datos cliente sin enriquecer, fbp/fbc perdidos) se vuelven más anchas y menos predictivas. El CTR de prospecting LAL cae 8-18% comparado con cohortes pre-iOS 17.
Segundo, el algoritmo de pujas se entrena con menos señal real, lo que se traduce en fase de aprendizaje que dura más (12-18 días en lugar de 7-10), CPA inestable durante 2-3 semanas tras cualquier cambio significativo, y peor performance de campañas Advantage+ Shopping en cuentas con bajo coverage server-side.
La solución: entrenar las semillas con eventos enriquecidos al máximo (LTV alto, no AddToCart genérico) y mantener server-side +85% de coverage para que el algoritmo aprenda con la señal completa.
Plan de 6 pasos para minimizar el daño
Paso 1 · Tracking server-side completo. sGTM o Stape, no solo Shopify CAPI nativa. EMQ objetivo +8,0. Coverage Purchase server-side +85%. fbc/fbp persistidos en cookie first-party con dominio propio.
Paso 2 · AEM correctamente priorizado. 8 web events activos, Purchase en posición 1, dominio verificado, sin solapamiento de event_name.
Paso 3 · Eventos enriquecidos con datos cliente hasheados. SHA-256 de email, phone, nombre, dirección. Con email solo no llegas a EMQ 8.
Paso 4 · Ventanas de atribución actualizadas. 7d-click + 1d-view, no 1d-click para D2C con ticket +50€ y ciclo de decisión real.
Paso 5 · MMM ligero o geo-experiments mensuales. Validar lift real vs lift reportado. Si Meta dice ROAS 3,5 y geo-test confirma incremental 2,8x, ajustas el modelo de presupuesto.
Paso 6 · Dashboard blended ROAS y blended CAC. No solo Meta-attributed. Lo que escala el negocio es la suma, no la atribución de plataforma.
Errores frecuentes
Seis errores vistos en 12 de 17 cuentas auditadas.
| Error | Síntoma | Consecuencia | Solución |
|---|---|---|---|
| Solo CAPI nativa Shopify | EMQ estancado en 5,5-6 | Discrepancia ROAS sin cerrar | sGTM o Stape con datos hasheados |
| AEM mal priorizado | Conversiones iOS rechazadas no atribuidas | ROAS subreportado 25-40% | Purchase en 1, 8 events activos |
| Sin eventos enriquecidos | EMQ 5,5 máximo | Algoritmo con señal incompleta | SHA-256 de email, phone, dirección |
| Ventana 1d-click en ticket +50€ | Conversiones de ciclo largo perdidas | ROAS subreportado 15-25% | 7d-click + 1d-view |
| Confiar en Meta Attribution solo | Decisiones sobre datos inflados | Presupuesto mal asignado | Cruzar con Shopify 7d |
| Sin geo-experiments | Validación sin causalidad | Lift real desconocido | Test mensual 4 semanas |
Cómo trabajamos en DayByDay
En DayByDay operamos el stack de tracking server-side completo para D2C con +30K€/mes de Meta Ads.
- Semanas 1-2: setup sGTM + Stape, configuración CAPI, eventos hasheados.
- Semanas 3-4: validación EMQ +8, coverage +85%, AEM priorizado.
- Mes 2: dashboard blended ROAS y CAC, geo-experiments piloto.
- Mes 3+: MMM mensual, calibración de modelos de atribución.
Para quién: D2C con +30K€/mes de Meta Ads y +35% tráfico iOS. Coste: 4-8K€ de setup + 50-300€/mes de stack. ROI típico 4-7x en 6 meses.
Acción de hoy (15 minutos)
- Abre Events Manager de Meta y mira tu EMQ. Si está por debajo de 7, el tracking está roto. CAPI incompleta o client-side-only.
- Mira tu coverage server-side del evento Purchase. Si está por debajo de 80%, el 20%+ de conversiones se atribuyen solo por píxel client-side, que iOS 17/18 está bloqueando.
- Calcula la discrepancia entre tu ROAS Meta y tu ROAS Shopify 7d. Si supera 25%, tu atribución está inflada. Decides presupuesto sobre datos que mienten.
Si las tres respuestas no encajan con un tracking sano, agenda una llamada de 30 minutos con nosotros. Te decimos qué arreglar primero.
Recap + cliffhanger
Cubrimos tres cosas concretas:
- Qué cambió con iOS 17/18: Link Tracking Protection borra fbclid/gclid/utm. Private Relay ofusca IP. ITP caduca cookies. Sin CAPI server-side, -18 a -32% de eventos perdidos.
- CAPI recupera 60-85% del gap. El 15-40% restante requiere AEM + MMM + geo-experiments. CAPI sola no es suficiente.
- Plan de 6 pasos en 14 días: sGTM o Stape, AEM priorizado, eventos hasheados SHA-256, ventana 7d-click, MMM mensual, dashboard blended.
La semana que viene: el framework para construir un MMM ligero en D2C. Cuándo compensa, qué herramientas usar y cómo cruzar MMM con incrementality para decisiones anuales.
---