Por qué cayeron las conversiones de Meta después de iOS 14 (AEM, verificación de dominio, límite de 8 eventos)

"Desde la actualización a iOS 14, nuestras conversiones de anuncios de Meta (Facebook) han caído de forma visible." Esta sigue siendo una de las quejas más comunes en la operación de anuncios. No cambiaste nada en la configuración de tus campañas ni en la implementación de tu pixel — y aun así el número de conversiones en Events Manager y en tus campañas bajó. Casi siempre, la causa es un malentendido sobre ATT (App Tracking Transparency), introducido en iOS 14.5, y el mecanismo AEM (Aggregated Event Measurement) que Meta creó para adaptarse a este cambio.

¿Te suena alguno de estos síntomas?

• Las conversiones de Meta cayeron claramente cuando iOS 14.5 se adoptó de forma masiva
• El número de conversiones de Meta es menor que el de tu GA4 o tu backend
• Events Manager muestra un aviso o advertencia de que solo puedes configurar hasta 8 eventos
• Algunas conversiones se reportan como "modeladas" (estimadas)
• Las conversiones aparecen en los reportes con un retraso considerable después de haber ocurrido

Esta guía explica cómo iOS 14 provoca que las conversiones de Meta caigan o se pierdan, la relación entre ATT, AEM, el límite de 8 eventos y la verificación de dominio, cómo verificar — en tu entorno real de producción — exactamente cómo se te está midiendo en este momento, y cómo mitigarlo con CAPI.

Primer principio: el cambio de iOS 14 es un cambio estructural de especificación, no una falla

La razón principal por la que esto sale mal es tratar la caída de conversiones como una falla — "el pixel se rompió" o "metimos la pata en la implementación". En realidad, la mayor parte de la caída desde iOS 14.5 proviene de un cambio estructural de especificación hecho por privacidad. No es el tipo de cosa donde arreglar algo hace que los números vuelvan a ser los mismos.

Si confundes esto, caes en el pantano de ajustar configuraciones sin parar mientras "los números nunca vuelven". Así que veamos, en orden, qué cambió realmente.

ATT (App Tracking Transparency): más exclusiones

Desde iOS 14.5, Apple introdujo ATT (App Tracking Transparency). Antes de que una app pueda rastrear a un usuario a través de otras apps y sitios, debe mostrar un diálogo de permiso: "¿Permitir que esta app te rastree?"

El punto clave: muchos usuarios tocan "Pedir a la app que no rastree". Cuando un usuario que llegó a tu sitio desde dentro de la app de Facebook/Instagram ha rechazado el rastreo, Meta ya no puede vincular el comportamiento de ese usuario como lo hacía antes.

Como resultado, Meta ya no puede asumir la medición precisa a nivel de persona en la que se apoyaba antes. Para compensar esto, Meta introdujo AEM, que veremos a continuación.

Tasas de aceptación de ATT: cuánta señal se pierde en realidad

¿Qué tan grande es la brecha? Los benchmarks de la industria dan un panorama concreto. A mediados de 2025, la tasa global de aceptación de ATT ronda el 25–35 % — es decir, aproximadamente el 65–75 % de los usuarios de iOS rechazan el rastreo. Las tasas varían según la categoría de app (las apps deportivas llegan a un 50 % de aceptación; muchas apps de utilidades y redes sociales se mantienen por debajo del 20 %), pero el efecto agregado es el mismo: Meta pierde señal a nivel de persona para la mayoría del tráfico de iOS.

Para anunciantes cuya audiencia está muy concentrada en iOS — algo común en Japón, donde la cuota de mercado del iPhone supera el 60 % — la pérdida de señal es proporcionalmente mayor, y la proporción de conversiones que terminan siendo modeladas o no medidas crece en consecuencia. Por eso la misma configuración de pixel puede producir niveles de subconteo muy distintos para diferentes anunciantes: la brecha está determinada por la proporción de iOS y el comportamiento de aceptación de tu audiencia, no por un porcentaje universal.

AEM (Aggregated Event Measurement): 8 eventos priorizados por dominio

AEM (Aggregated Event Measurement) es el mecanismo de Meta para medir las conversiones web de los usuarios que rechazaron el rastreo mediante ATT — no a nivel individual, sino de forma agregada. Está diseñado para encajar dentro del marco de privacidad de Apple.

En la práctica, la regla con mayor impacto es esta.

Restricción principal de AEM	Qué significa
Límite de eventos	Solo puedes configurar hasta 8 eventos por dominio
Priorización	Debes asignar un orden de prioridad a esos 8 eventos
Una conversión, un evento	Para los usuarios que rechazaron el rastreo, solo se mide el único evento de mayor prioridad por acción
Eventos de menor prioridad	Los eventos fuera de los 8, o con baja prioridad, no se miden / no se reportan

En otras palabras, los eventos de conversión que antes medías libremente, en cualquier cantidad, ahora tienen que competir por prioridad dentro de un límite de 8. Si un sitio de e-commerce medía a la vez vistas de página, agregar al carrito, compra y varias microconversiones, las que no entran en las 8 — o quedan en un lugar bajo — se descartarán para los usuarios que rechazaron el rastreo.

Error común: configurar tu evento de compra importante (Purchase) con una prioridad baja. Como AEM mide solo el evento de mayor prioridad por acción, si la compra tiene baja prioridad, un microevento anterior puede ganarle y la compra —lo más importante— queda sin reportar.

Actualización de 2025: Meta eliminó el límite manual de 8 eventos

En junio de 2025 Meta hizo un cambio importante: se retiró el panel de configuración manual de AEM en Events Manager. Los anunciantes ya no necesitan elegir, ordenar ni priorizar manualmente 8 eventos. El sistema de Meta ahora agrega automáticamente, en segundo plano, todos los eventos estándar y personalizados elegibles.

Lo que esto significa en la práctica:

• La pestaña de configuración "Aggregated Event Measurement" en Events Manager desapareció
• Ya no hay un límite manual de eventos — todos los eventos elegibles se procesan automáticamente
• Ya no necesitas preocuparte de que un evento de baja prioridad desplace a uno de alta prioridad
• AEM en sí mismo sigue operando por debajo para los usuarios que rechazaron ATT, pero se eliminó el paso de configuración que veía el anunciante

Sin embargo, la restricción de privacidad subyacente no ha cambiado. Para los usuarios que rechazaron ATT, la medición sigue siendo agregada y con retraso, y las conversiones modeladas siguen llenando el vacío. Lo que cambió es que ahora Meta gestiona la selección de eventos de forma automática en lugar de exigir que los anunciantes la administren. Si antes dedicabas tiempo a optimizar tu lista de prioridades de 8 eventos, ese trabajo ya no es necesario — pero implementar CAPI y verificar la deduplicación entre pixel y CAPI sigue siendo igual de importante.

Verificación de dominio: sin ella, ni siquiera puedes configurar la medición

Como requisito previo para configurar las prioridades de eventos en AEM, Meta comenzó a exigir la verificación de dominio — el proceso mediante el cual un anunciante prueba ante Meta que "este dominio es mío".

• Sin la verificación de dominio, tu permiso para configurar y editar los 8 eventos es inestable
• Cuando varias empresas o cuentas publicitarias usan el mismo dominio, esto también determina quién tiene el control sobre la configuración de eventos

Si te encuentras con que "intenté configurar los 8 eventos pero no puedo tocarlos / nada surte efecto", la causa subyacente suele ser que la verificación de dominio simplemente no está completa. Es lo primero que debes confirmar como requisito previo a la implementación.

Cómo "cambian" los números: retraso, modelado, ventanas más cortas

La medición después de iOS 14 no solo "cae". La naturaleza misma de los números cambia de la siguiente manera. Sin entender esto, no puedes leer los reportes correctamente.

• Retraso en el reporte: las conversiones de usuarios que rechazaron el rastreo pueden reportarse de forma agregada con hasta unas 72 horas de retraso a través de AEM. "Los números de hoy se ven bajos" a veces se debe simplemente a que la agregación todavía está en proceso.
• Conversiones modeladas (estimadas) mezcladas: Meta estima estadísticamente y rellena lo que no puede medirse a nivel individual. Tus conversiones reportadas incluyen estimaciones, no mediciones directas. Esto es por diseño, no una falla.
• Ventana de atribución más corta: desde iOS 14, la ventana de atribución predeterminada se acortó (por ejemplo, con 7 días de clic convirtiéndose en un estándar base), así que resultados que antes se contaban bajo una ventana más larga ahora parecen haber disminuido.

Error común: juzgar que "cayó" comparando contra reportes antiguos. Como la ventana de atribución predeterminada cambió, hablar de aumentos o caídas sin comparar bajo las mismas condiciones te lleva a la causa equivocada. Alinea la configuración de la ventana antes de comparar.

Por qué caen las conversiones aunque el pixel "se dispare"

En DevTools puedes ver que la solicitud del pixel (facebook.com/tr) se envía sin problemas. Y aun así el número de conversiones de Meta cae — este es el patrón más confuso después de iOS 14. La razón: el disparo desde el navegador (se envía una solicitud) y la conversión completa que Meta mide y reporta quedan desacoplados por ATT y AEM.

Para los usuarios que rechazaron el rastreo, incluso si el pixel se dispara:

• No puede vincularse a nivel individual, así que pasa a la medición agregada de AEM, donde el reporte se retrasa y se restringe
• Si queda fuera del orden de prioridad de los 8 eventos, ese evento no se reporta
• El vacío se llena con modelado (estimación), así que ya no es un conteo real

Así que aunque confirmes que "facebook.com/tr se dispara en Network", si ese es el recorrido de un usuario que rechazó el rastreo, no necesariamente se reporta como una conversión completa y utilizable para anuncios. Revisar solo si el pixel se dispara nunca revelará las pérdidas posteriores a iOS 14.

Para diagnosticar problemas generales de "no se rastrea", consulta la guía aparte sobre cómo diagnosticar por qué no se rastrean las conversiones de Meta.

Mitigación: reforzar el lado del servidor con CAPI

La contramedida estándar para las pérdidas posteriores a iOS 14 es CAPI (la Conversions API). En lugar de depender solo del pixel del navegador, envía las conversiones a Meta directamente desde tu servidor, lo que lo hace menos afectado por las limitaciones del lado del navegador (bloqueadores de anuncios, prevención de rastreo, cierta pérdida de señal).

• Ejecuta el pixel del navegador y CAPI en conjunto, compartiendo el mismo nombre de evento y event_id para que Meta los deduplique
• Envía la información que tienes de forma confiable en el servidor para elevar tu calidad de coincidencia de eventos (event match quality)

Dicho esto, CAPI no es "instálalo y listo". Es esencial verificar que la deduplicación y el payload estén configurados correctamente. Consulta cómo verificar que la Meta Conversions API (CAPI) funciona para los detalles de las validaciones.

Más allá del conteo de conversiones: impacto en la segmentación y la optimización

La caída de conversiones es el síntoma más visible, pero los efectos de iOS 14 van más allá — hasta la forma en que Meta segmenta y optimiza los anuncios desde el principio.

• Las audiencias de retargeting se reducen. Cuando un usuario rechaza ATT, Meta no puede vincular su comportamiento en el sitio web de vuelta a una Custom Audience. Dado que la mayoría de los usuarios de iOS rechazan el rastreo, los grupos de retargeting construidos a partir de visitantes del sitio web (por ejemplo, "visitó la página de producto pero no compró") pueden perder el 50 % o más de su segmento de iOS.
• La calidad de las audiencias similares (lookalike) se degrada. Las lookalikes dependen de que Meta identifique patrones entre los miembros de tu audiencia semilla. Con menos señal entre apps, los modelos lookalike construidos a partir de semillas de eventos del sitio web (agregar al carrito, compra) se vuelven menos precisos, y el costo por adquisición (CPA) tiende a subir.
• Los algoritmos de optimización reciben menos retroalimentación. El algoritmo de entrega de Meta aprende de las señales de conversión. Menos conversiones observadas significa que el algoritmo necesita más presupuesto y tiempo para salir de la fase de aprendizaje, y el rendimiento de las campañas puede volverse más volátil.

La conclusión práctica: después de iOS 14 no basta con arreglar solo la medición. Los anunciantes que también migran hacia estrategias de audiencias first-party — subiendo listas de CRM, usando audiencias de interacción dentro de la app, y apoyándose en datos first-party para el seguimiento de conversiones — tienden a recuperar la efectividad de la segmentación más rápido que quienes dependen únicamente de audiencias basadas en el pixel.

Ten en cuenta que el mismo problema de "los números caen por medidas de privacidad" ocurre del lado de Google mediante un mecanismo distinto llamado Consent Mode. Para una comparación en paralelo, consulta por qué el Consent Mode hace que caigan tus conversiones.

Cómo verificar "cómo se me está rastreando ahora mismo" en producción

Método 1: revisa la verificación de dominio y la configuración de los 8 eventos de AEM

En Events Manager, confirma primero la base.

1. ¿Está completa la verificación de dominio en la configuración del negocio?
2. En la pantalla de "Aggregated Event Measurement", ¿están registrados 8 eventos con el orden de prioridad que buscabas?
3. ¿Está tu conversión más importante (generalmente Purchase o Lead) ubicada en la cima de la lista de prioridades?

Qué te dice esto: si los requisitos previos para la medición (verificación) y las prioridades están configurados correctamente.

Método 2: observa el disparo del pixel en Network de DevTools

1. Abre la página de producción objetivo (especialmente la página de compra completada / agradecimiento) y abre la pestaña "Network"
2. Filtra por facebook.com/tr
3. Realiza la acción y verifica si la solicitud se dispara y si id (ID del pixel) y ev (nombre del evento) son correctos

Qué te dice esto: que el evento se dispara desde el navegador (etapa ②). Qué no te dice: cómo maneja Meta esto como medición agregada en el recorrido de un usuario que rechazó ATT (etapa ③).

Método 3: revisa los eventos de prueba y la ventana de atribución en Events Manager

• ¿Tus eventos objetivo llegan en tiempo real en Test Events?
• ¿La ventana de atribución del reporte está configurada bajo las mismas condiciones que los datos pasados con los que quieres comparar?
• ¿Qué porcentaje de las conversiones están etiquetadas como "modeladas" / "estimadas"?

Qué te dice esto: la realidad de la recepción, y la naturaleza de los números (reales vs. estimados, y si las ventanas están alineadas).

Lo que revisar en tu propia máquina no puede decirte

Los métodos anteriores son útiles, pero probar una sola vez en tu propia máquina tiene dos puntos ciegos específicos de la medición posterior a iOS 14.

1. Tu entorno no es el entorno de tus usuarios de producción. El dispositivo o navegador con el que pruebas normalmente ha permitido el rastreo, o es un equipo de escritorio no afectado por ATT. Pero quienes están tirando hacia abajo tus números de Meta son los usuarios que rechazaron ATT en iOS. Concluir "se dispara, así que está bien" desde tu propio entorno pasa por alto toda la pérdida.
2. Todo lo que involucra un clic en un anuncio es difícil de reproducir. Para ver correctamente "cómo se trata en el lado de Meta a una persona que llegó por un anuncio de Facebook y luego rechazó ATT", tendrías que hacer clic en un anuncio en vivo para recrear el recorrido — lo cual conlleva el riesgo de violar la política de anuncios por ser un autoclic.

Las pérdidas posteriores a iOS 14 ocurren en el recorrido "del usuario de producción que rechazó", no "del tú que permitiste". El hecho de que se vea bien cuando permites el rastreo es precisamente lo que genera una falsa sensación de seguridad.

Una lista de verificación para confirmar con confianza

• ¿Está completa la verificación de dominio?
• ¿Están registrados los 8 eventos de AEM con el orden de prioridad que buscabas?
• ¿Está tu conversión más importante en la cima de la lista de prioridades?
• ¿Se dispara facebook.com/tr en DevTools, con el ID de pixel y el nombre de evento correctos?
• ¿Alineaste la ventana de atribución del reporte con aquella que estás usando para comparar?
• ¿Estás leyendo los números sabiendo que incluyen conversiones "modeladas" (estimadas)?
• ¿Estás teniendo en cuenta el retraso del reporte (hasta ~72 horas) antes de malinterpretar un número bajo del mismo día?
• ¿Implementaste CAPI como contramedida y verificaste la deduplicación (event_id)?
• ¿Verificaste bajo condiciones reales de visitantes de producción (incluyendo quienes rechazan ATT), no solo un patrón en tu máquina?

Preguntas frecuentes

P. ¿Cuánto caen las conversiones de Meta después de iOS 14? R. Varía. El tamaño depende de la proporción de tu tráfico que rechaza ATT en iOS, tu configuración de los 8 eventos de AEM y el cambio en la ventana de atribución. Lo importante es que se trata de un cambio estructural impulsado por especificaciones de privacidad, no una falla. Puedes mitigar las pérdidas con la optimización de la configuración y CAPI, pero en lugar de aspirar a restaurar exactamente los números previos a iOS 14, la postura correcta es volver a medir bajo las nuevas suposiciones.

P. ¿Qué es exactamente el "límite de 8 eventos"? R. En AEM solo puedes configurar hasta 8 eventos de conversión por dominio, cada uno con una prioridad. Para los usuarios que rechazaron el rastreo, solo se mide el único evento de mayor prioridad por acción. Mientras más eventos estaba midiendo un sitio, más se ve afectado por eventos que quedan fuera del límite o con baja prioridad y se descartan.

P. ¿Qué pasa si no verifico mi dominio? R. Configurar y editar los 8 eventos de AEM se vuelve inestable, y los requisitos previos para la medición no quedan en su lugar. Cuando varias cuentas usan el mismo dominio, esto también deja indefinido "quién controla la configuración". Es lo primero que debes hacer antes de comenzar la implementación.

P. ¿Qué es una "conversión modelada"? ¿Es una falla? R. No. Es una conversión que Meta estima estadísticamente y rellena para lo que no puede medirse a nivel individual, como los usuarios que rechazaron el rastreo mediante ATT. No es una medición directa, así que el número se comporta de forma distinta, pero está funcionando tal como fue diseñado.

P. ¿CAPI hará que mis números vuelvan a ser los originales? R. No "por completo", pero el envío del lado del servidor — menos afectado por las limitaciones del lado del navegador — mitiga las pérdidas y eleva la calidad de coincidencia de eventos. Sí requiere que la deduplicación y el payload estén configurados correctamente. Consulta la guía de verificación de CAPI para más detalles.

P. ¿Esto es lo mismo que el problema de "caída por Consent Mode" en Google Ads? R. El tema general — "los números caen por medidas de privacidad" — es similar, pero los mecanismos son distintos. Meta usa ATT + AEM; Google usa Consent Mode. La comparación está detallada en el artículo sobre Consent Mode.

Conclusión: vuelve a medir bajo "nuevas suposiciones", no como una "falla"

El problema de que las conversiones de Meta caigan después de iOS 14 no se puede diagnosticar solo observando si el pixel se dispara. Lo importante es verificar — partiendo de los cambios estructurales de ATT, el límite de 8 eventos de AEM, la verificación de dominio, el retraso en los reportes y el modelado — cómo se está midiendo realmente a tus usuarios reales de producción (especialmente a quienes rechazaron ATT). Para el panorama completo del rastreo de Meta, consulta la guía hermana Meta conversion tracking, guía completa.

ConversionOK ejecuta tu página en vivo en un navegador independiente y aislado, e intercepta los eventos y parámetros del pixel realmente enviados para verificarlos — sin necesidad de hacer clic en tu propio anuncio y sin interferencia del entorno de tu oficina. Empieza con una verificación estática gratuita para confirmar el punto de entrada de tu medición.