· 17 min · Samet Durgun

¿Por qué mi trial y mi compra no son elegibles para Meta AEM?

Soy Samet Durgun, fractional Head of UA. Llevo el paid UA de apps de suscripción y juegos móviles, y aquí escribo lo que veo en las cuentas que manejo. Este artículo pertenece al tema Signal engineering; más sobre mí.

Un evento que llega a Events Manager todavía no es un evento para el que puedas optimizar. Meta marca cada evento de iOS como elegible o no elegible para Aggregated Event Measurement por separado, y entre los motivos que enumera están un evento enviado por una integración distinta de la de tu evento de instalación, datos que faltan y que la ruta tiene que transportar, o muy pocas señales en los últimos 30 días. Cuál de ellos se aplica depende de tu ruta: RevenueCat enviando directo a Meta tiene requisitos distintos de RevenueCat enviando a AppsFlyer, que después los envía de vuelta a Meta.

En mis cuentas, hay un orden que suele resolverlo: configurar AEM en Events Manager y activar la atribución probabilística en el MMP, lanzar una campaña de instalación, y solo entonces pasar la optimización al trial o a la compra cuando Events Manager lo muestre como elegible. Esa es mi práctica, no una solución que Meta documente; la sección sobre el orden de configuración más abajo tiene los detalles.

Alcance: campañas de app promotion de Meta para iOS 14+ que usan AEM y optimizan para eventos de app o valor (los objetivos de Meta “maximize number of app events” y “maximize value of conversions”). Dos rutas, mantenidas separadas de principio a fin: RevenueCat directo a Meta, y RevenueCat a AppsFlyer a Meta. La sección sobre el orden de configuración nombra también los ajustes equivalentes en Adjust y Singular. Nada de esto es específico de una región. Todas las páginas de proveedores de abajo se comprobaron el 29 de septiembre de 2026. Las páginas de ayuda de Meta no muestran fechas y cambian sin aviso, así que vuelve a comprobarlas antes de actuar.

¿Dónde dice Meta que un evento no es elegible?

En Events Manager. La página de Meta How to check if your app events are eligible for Aggregated Event Measurement da la ruta: Datasets, tu dataset, la pestaña Settings, Setup tasks for iOS app events, y luego Check app eligibility en la sección “Meta’s attribution for iOS 14+”. La columna Eligibility marca cada evento como elegible o no elegible, More details explica por qué, y un estado pending significa que Meta sigue esperando o verificando información de tu integración.

La página de Meta Troubleshoot issues with app eligibility for Aggregated Event Measurement lista cada mensaje con lo que puede significar y la solución. Anota el mensaje exacto y la fecha antes de que alguien toque la configuración, porque cada mensaje de esa página apunta a una solución distinta.

¿Es recepción, datos requeridos o elegibilidad?

Tres preguntas distintas se esconden detrás de “el evento no funciona”:

  • Recepción. ¿Recibió Meta el evento? La página de Meta Ads de RevenueCat dice que Events Manager puede tardar hasta 24 horas en mostrar los eventos aceptados.
  • Datos requeridos. ¿Lleva el evento lo que tu ruta necesita para AEM? Esto cambia según la ruta.
  • Elegibilidad para optimizar. ¿Dejará Meta que una campaña optimice para él? La página de RevenueCat es explícita: una entrega correcta solo significa que Meta aceptó el evento, y Meta sigue decidiendo si es elegible para una campaña, un objetivo o un reporte.

La tabla ordena los síntomas habituales por capa. La columna de la ruta importa: un requisito documentado para una ruta no es evidencia sobre la otra.

Capa Síntoma Sistema a revisar Evidencia necesaria Siguiente acción
Recepción StartTrial o Subscribe no aparecen en Events Manager (RevenueCat directo) Customer History de RevenueCat, fila de entrega de Meta Ads Pestañas Request y Response; para la Conversions API, el fbtrace_id Sin fila: revisa los atributos requeridos y sigue la resolución de problemas de RevenueCat para una fila de entrega ausente. Aceptado: espera hasta 24 horas, como documenta RevenueCat, antes de mirar Events Manager
Recepción Faltan eventos en AppsFlyer (ruta de AppsFlyer) Atributos de cliente de RevenueCat Si $appsflyerId se fijó antes de la compra Fíjalo después de configurar el SDK de Purchases y antes de la primera compra
Datos requeridos Llegan pocos o ningún evento del App Store a Meta (RevenueCat directo) Ajustes de Meta Ads en RevenueCat y atributos de cliente $fbAnonId o un IDFA real, el estado de ATT, el ajuste “Send events when ATT consent is not authorized” Decide el ajuste de consentimiento de forma deliberada, con tu propia revisión de privacidad
Datos requeridos Eventos de servidor a servidor no elegibles (ruta de AppsFlyer) Un payload de evento en bruto IP e IDFV presentes en cada evento Recoge los identificadores del dispositivo en RevenueCat para que $ip y $idfv estén fijados antes de la compra
Datos requeridos “Contact your mobile measurement partner (MMP) to check eligibility steps for Meta’s attribution for iOS 14+” El dashboard del MMP Si el ajuste de AEM del MMP está activado Actívalo; el orden de configuración de abajo lo nombra para cada MMP
Datos requeridos “IP data version isn’t optimal for setup” La integración que nombra el mensaje Si la IP falta o se envía de forma inconsistente Envía la IP de forma consistente; en la ruta de AppsFlyer, desactiva el enmascaramiento de IP
Datos requeridos “Advertiser Tracking Enabled parameter volume out-of-range” Estado de ATT en los eventos entrantes Porcentaje de eventos con el tracking no habilitado o con un IDFA a cero Revisa la tasa de consentimiento de ATT; para este mensaje Meta remite a tu account manager
Elegibilidad “Different integrations across multiple event types” Events Manager, el evento de instalación y el evento de trial o compra Qué integración envía cada uno Envía el evento de instalación y el de optimización por la misma integración
Elegibilidad “Multiple integrations for the same event” Events Manager, Manage event Todas las fuentes que envían el evento Elige una integración para el evento; elimina el registro duplicado del lado del cliente
Elegibilidad “Not enough signals from last 30 days” Events Manager y la herramienta de eventos de prueba Recuentos de eventos en 30 días Confirma la configuración con eventos de prueba y luego mira cuánto volumen deja pasar la ruta
Elegibilidad Pending, “Awaiting or verifying information from your integration” Events Manager Fecha en que apareció el estado Vuelve a comprobar en 3 días, como dice Meta

¿Qué necesita la ruta directa de RevenueCat?

La página de Meta Ads de RevenueCat expone cuatro puntos que importan aquí.

El SDK de Meta se queda. RevenueCat dice que mantengas el SDK de Meta para la instalación, la activación y las señales en el dispositivo; sus eventos de servidor a servidor no sustituyen la configuración del SDK de Meta para campañas de instalación, SKAdNetwork o AEM. Recomienda la Conversions API sobre la App Events API por fiabilidad y soporte a largo plazo, y señala que puede enviar conversiones de trial y renovaciones cuando la app no está abierta.

La entrega depende de los identificadores y del consentimiento. Para los eventos del App Store por la Conversions API, RevenueCat intenta la entrega solo cuando el cliente tiene $fbAnonId o $idfa, más un estado de ATT authorized, a menos que esté activado el ajuste del dashboard “Send events when ATT consent is not authorized”. Trata los valores de IDFA vacíos o a cero como ausentes. El IDFV, la IP, el email y el número de teléfono no están entre los atributos que exige para la entrega; los lista como atributos que Meta puede usar para el matching cuando están presentes. RevenueCat te pide fijarlos después de configurar su SDK y antes de la primera compra siempre que sea posible, y volver a recoger los identificadores del dispositivo una vez concedido el permiso de ATT.

RevenueCat dice que dejar el ajuste desactivado exige el consentimiento de ATT authorized antes de enviar los eventos del App Store. Su página no dice expresamente en qué estado empieza una integración nueva, así que mira el ajuste en tu propio dashboard antes de sacar conclusiones de los recuentos de eventos de Meta. Así que, con él desactivado, los eventos de trial y compra del App Store de usuarios que no autorizaron el tracking no se envían a Meta por esta ruta, y Meta ve menos eventos de los que registra RevenueCat. Mi lectura es que en una cuenta pequeña esta es una vía plausible hacia “Not enough signals from last 30 days”. Activar el ajuste es una decisión de privacidad, no un retoque de medición.

Subscribe es amplio. Por defecto RevenueCat mapea Trial Started a StartTrial, y Trial Converted, Initial Purchase y Renewal a Subscribe. Una compra no renovable va a fb_mobile_purchase. Así que un recuento de Subscribe en Events Manager mezcla primeros pagos con renovaciones. RevenueCat te deja elegir otros nombres de evento estándar de Meta para estos eventos, y señala que Meta recomienda eventos estándar para optimizar campañas. Si alguien cambió el mapeo, comprueba para qué nombre de evento optimiza tu campaña antes que nada.

Una fuente por evento, y la cuestión de la integración. RevenueCat dice que elimines el registro de compras y revenue del lado del cliente para los eventos que envía, porque el SDK de Meta y RevenueCat no comparten un event_id. La página de resolución de problemas de Meta añade una regla que aquí importa: un evento puede no ser elegible para objetivos de app event o de valor cuando llega por una integración distinta de la de tu evento de instalación, y la solución es usar la misma integración para ambos. La página de Meta About Partner Integrations for app events, en su consejo para la optimización por valor, nombra el SDK de Facebook, un MMP y la Conversions API como canales separados y te pide enviar cada evento por uno solo. En la ruta directa, las instalaciones vienen del SDK de Meta y los trials y pagos de la Conversions API. Las páginas de Meta citadas aquí no dicen si trata ese emparejamiento como dos integraciones para esta regla, así que comprueba en Events Manager la integración elegida para ambos eventos en lugar de suponerlo.

¿Qué necesita la ruta de AppsFlyer?

RevenueCat envía los eventos a AppsFlyer, que los devuelve a Meta. Dos páginas fijan los requisitos, y difieren.

La página de AppsFlyer Meta Ads Aggregate Event Measurement (AEM) for iOS dice que para los eventos in app enviados de servidor a servidor, Meta exige tanto la dirección IP como el IDFV en el payload del evento, y que sin ellos el evento no es elegible para la atribución de Meta en AEM. La página de AppsFlyer de RevenueCat marca como requerido solo $appsflyerId. Lista $idfa, $idfv y $ip como recomendados, y te pide fijar los atributos después de configurar el SDK de Purchases y antes de la primera compra, avisando de que algunos eventos pueden no entregarse sin el AppsFlyer ID. El helper collectDeviceIdentifiers de RevenueCat recoge $idfa, $idfv y $ip. En esta ruta, trata “recomendado” como requerido para AEM, porque AppsFlyer dice que Meta necesita ambos.

El checklist de resolución de problemas de AppsFlyer para eventos no elegibles, en su orden, sin su paso para campañas de remarketing:

  1. Advanced Data Sharing activado en la integración de Meta Ads (Collaborate, Active Integrations, Meta Ads). Con él desactivado, solo se comparten los eventos de usuarios con un advertiser ID. La tabla resumen de AppsFlyer lo nombra como el interruptor que habilita AEM para app promotion, y es el ajuste del MMP en el orden de configuración de abajo.
  2. Enmascaramiento de IP desactivado en App Settings. AppsFlyer dice que los eventos con IP enmascaradas no son elegibles.
  3. Dirección IP e IDFV en cada evento de servidor a servidor.
  4. Tasa de consentimiento de ATT revisada. Meta acepta un volumen limitado de eventos con IDFA ausentes o a cero.
  5. Postbacks mapeados a “Send all (including organic)”. La página de partners de Meta da el mismo consejo.
  6. Si los eventos siguen sin ser elegibles, fija el tráfico del MMP como conexión preferida en Events Manager.

RevenueCat también te pide eliminar el seguimiento de revenue del lado del cliente en el SDK de AppsFlyer para evitar contar dos veces. Mi lectura es que esta ruta puede poner las instalaciones y los eventos de trial o compra en una sola integración, que es lo que pide la solución de Meta de usar la misma integración, siempre que ninguna otra fuente envíe los mismos eventos.

¿Meta sigue limitando las apps a ocho eventos?

La página de Meta “How to configure app events to use Meta’s Aggregated Event Measurement”, que fijaba ocho espacios de evento para la configuración de AEM de una app, ahora devuelve Page Not Found (comprobado el 29 de septiembre de 2026), así que las guías que te dicen que ordenes ocho app events para AEM describen una configuración que Meta ya no documenta. La página de Meta About Meta’s Aggregated Event Measurement dice que está desplegando poco a poco actualizaciones de las campañas de app, y que con ellas puedes correr campañas de app promotion sin configurar app events para SKAdNetwork, con más app events disponibles para optimizar. El ranking de eventos que Meta sigue documentando pertenece a la configuración de SKAdNetwork: su página About value sets describe allí IDs de prioridad del 1 al 63, y dice que no necesitas habilitar value sets para los eventos enviados por AEM. Ninguno de los mensajes de la página de resolución de problemas de Meta trata del orden de los espacios, así que no gastes un diagnóstico en eso.

¿Cuánto debería esperar después de una corrección?

Cambia una sola cosa, anota la fecha y espera la ventana que corresponda:

  • Los eventos aceptados pueden tardar hasta 24 horas en aparecer en Events Manager (RevenueCat).
  • Un cambio en la integración elegida puede tardar hasta 24 horas en reflejarse, según la página de Meta Choose a single integration for app events in Meta Events Manager if you send events from multiple integrations.
  • Un evento pendiente: vuelve a comprobar en 3 días (Meta).
  • Después de seleccionar una integración para resolver un mensaje: hasta 7 días para volver a comprobar, y la edición de campañas puede no estar disponible mientras tanto (Meta).
  • Después del checklist de AppsFlyer: hasta 2 o 3 días para que Meta refleje la elegibilidad (AppsFlyer).

Dos cambios dentro de una misma ventana te dejan sin poder decir cuál funcionó.

¿Qué orden de configuración suele resolverlo?

En mis cuentas, este orden suele resolver un evento de trial o compra no elegible, y en una app nueva lo configuro antes de la primera campaña de instalación. La página de resolución de problemas de Meta no lista una campaña de instalación entre sus soluciones, así que lee el tercer paso como mi experiencia, no como una instrucción de Meta.

  1. Configura AEM en Events Manager antes de la primera campaña de instalación. Abro la pestaña Settings del dataset, voy a Setup tasks for iOS app events y recorro la sección “Meta’s attribution for iOS 14+”, aceptando los términos de Meta cuando los pide. Las páginas de Meta que revisé no documentan un interruptor de AEM aparte ni un paso de términos para apps: About Meta’s Aggregated Event Measurement dice que no hace falta ninguna acción para recibir las actualizaciones de las campañas de app, aunque quizá tengas que actuar para que tu app sea elegible. Si Events Manager te muestra un aviso, acéptalo; si no muestra ninguno, sigue adelante.
  2. Activa la atribución probabilística en el MMP, y su ajuste de AEM. La página de Meta Recommendations for setting up Meta Aggregated Event Measurement with a mobile measurement partner te pide activar cualquier interruptor o ajuste de AEM que tenga el dashboard de tu MMP, comprobar si app promotion y retargeting necesitan ajustes separados, y avisa de que restringir el uso compartido de la IP o limitar el uso compartido de datos de los usuarios que rechazan pueden interferir incluso con el interruptor activado. La página de Meta no menciona la atribución probabilística; activarla es mi práctica. Cómo se llaman los ajustes depende del MMP:
    • AppsFlyer: Advanced Data Sharing en la integración de Meta Ads. La tabla resumen de AppsFlyer dice que habilita AEM para app promotion, incluidos los eventos de usuarios sin advertiser ID y los claims no deterministas donde correspondan. El interruptor probabilístico está en App Settings, y la página de AppsFlyer le da dos nombres: “Enable view-through attribution via probabilistic modeling” en la tabla y “Enable view-through attribution via campaign measurement modeling” en el texto. Cubre los claims de view through, y yo lo activo también.
    • Adjust: su página de configuración de Meta dice que la integración admite campañas de instalación de AEM automáticamente, y que el modelado probabilístico está activado por defecto en todos los links de campañas de instalación de AEM aunque lo hayas desactivado a nivel de app. Aun así se puede cambiar en los ajustes de atribución de un link, así que comprueba que nadie lo haya desactivado ahí. Su interruptor “Enable AEM for MAE” es para campañas de retargeting, no de instalaciones.
    • Singular: “Include Advanced AEM Attributions” en la configuración del partner de Facebook, marcado por defecto. Su página de integración con Meta dice que la configuración por defecto ya envía los eventos de usuarios que no concedieron el permiso de ATT.
    • RevenueCat directo: no hay ningún MMP en el camino. El ajuste más cercano es “Send events when ATT consent is not authorized”, tratado más arriba, y es una decisión de privacidad.
  3. Lanza primero una campaña de instalación. Lanzo una campaña de app promotion optimizada para instalaciones, y le pido a Meta que optimice para trials o compras solo después. Mi lectura de por qué funciona: la campaña de instalación le da a Meta instalaciones, y eventos posteriores de esos usuarios, antes de pedirle que optimice para un evento más raro. La página de Meta se acerca sin decirlo: uno de los motivos que da para “Integration quality issue” es “We’ve received a low number of install events”, y su solución es enviar todos los eventos de conversión, no correr una campaña de instalación.
  4. Pasa el evento de optimización cuando aparezca como elegible. Comprueba la columna Eligibility, como se describe arriba, antes de cambiar la campaña a maximize number of app events o maximize value of conversions para el trial o la compra.

Dos límites. Si More details nombra un campo que falta o una integración dividida, esa solución va primero: una campaña de instalación no añade un IDFV que falta, no desenmascara una IP ni mueve un evento a la integración de la instalación, y más presupuesto tampoco. Si la ruta está limpia y el evento es demasiado raro, la pregunta pasa a ser qué evento debería optimizar una subscription app.

¿Está permitido enviar IP e IDFV de usuarios que rechazaron el tracking?

Esa es tu decisión legal, y nada de aquí es asesoría legal. La página de Apple User privacy and data use dice que el IDFV no puede combinarse con otros datos para rastrear a un usuario en apps y sitios web de otras empresas, y te deja la responsabilidad de cumplir la ley aplicable. AppsFlyer te pide confirmar que Advanced Data Sharing cumple las políticas y normativas de tu plataforma antes de activarlo.

¿Qué evidencia debería reunir antes de escalar a soporte de Meta?

La página de resolución de problemas de Meta remite varios mensajes a tu account manager de Meta, y AppsFlyer pide una captura de pantalla de los eventos no elegibles con cualquier ticket. Llega con:

  1. Una captura de pantalla con fecha de la columna Eligibility y el mensaje completo de More details.
  2. ID del dataset, ID de la app y cada nombre de evento exactamente como se envió, indicando si es estándar o personalizado.
  3. La integración elegida para el evento de instalación y para el evento de trial o compra, y una lista de todas las fuentes que envían cada uno.
  4. Para RevenueCat directo: la fila de entrega de un cliente de prueba reciente con el Request, el Response y el fbtrace_id.
  5. Para la ruta de AppsFlyer: un evento de servidor a servidor con los datos sensibles ocultos que muestre IP e IDFV presentes, más los ajustes de Advanced Data Sharing, enmascaramiento de IP y postbacks.
  6. El porcentaje de autorización de ATT en los últimos 30 días.
  7. Un registro de cada cambio con su fecha, y cuánto esperaste después de cada uno.

¿Quién puede arreglar CAPI y el mapeo de eventos para Meta?

Este es el trabajo que asumo dentro de signal engineering: trazar cada evento desde la compra hasta Events Manager, decidir qué integración se encarga de él, y arreglar lo que le falta a la ruta antes de que nadie toque las pujas o los presupuestos.

Antes de la primera campaña de instalación de una app en Meta, configuro AEM en Events Manager, acepto los términos de Meta donde los pide, y activo la atribución probabilística en el MMP junto con cualquier ajuste de AEM que tenga. Solo entonces sale la campaña de instalación, y el trial o la compra pasa a ser el evento de optimización una vez que Events Manager lo marca como elegible.

Fuentes

Cada página se abrió y se comprobó el 29 de septiembre de 2026.

Preguntas frecuentes

¿Enviar una compra desde RevenueCat la hace elegible para Meta AEM?

No. La página de Meta Ads de RevenueCat dice que una entrega correcta significa que Meta aceptó el evento, y que Meta aún puede decidir que el evento no es elegible para una campaña, un objetivo de optimización o un reporte. Recepción y elegibilidad son comprobaciones distintas.

¿Los eventos de servidor a servidor necesitan la dirección IP y el IDFV para Meta AEM?

En la ruta de AppsFlyer, sí: AppsFlyer documenta que Meta exige ambos en el payload de los eventos in app enviados de servidor a servidor, y que los eventos sin ellos no son elegibles para la atribución de Meta en AEM. La integración directa de RevenueCat con Meta no exige el IDFV ni la IP para la entrega y los usa para el matching cuando están presentes, así que el requisito pertenece a la ruta, no a todas las configuraciones.

¿Cuánto tarda Meta en actualizar la elegibilidad de AEM después de una corrección?

Depende de la corrección. AppsFlyer dice que hasta 2 o 3 días después de completar su checklist. Meta dice que un evento pendiente debe volver a comprobarse en 3 días, y que después de seleccionar una integración la comprobación puede tardar hasta 7 días, con la edición de campañas posiblemente no disponible mientras tanto.

¿Meta sigue limitando las apps de iOS a ocho eventos de AEM?

La página de Meta sobre cómo configurar app events para AEM, que fijaba ocho espacios de evento, devuelve Page Not Found (comprobado el 29 de septiembre de 2026), así que las guías que te dicen que ordenes ocho app events para AEM describen una configuración que Meta ya no documenta. El ranking de eventos que Meta sigue documentando pertenece a la configuración de SKAdNetwork, y ninguno de sus mensajes de elegibilidad de AEM trata del orden de los espacios.

¿Una campaña de instalación o más presupuesto harán que mis eventos sean elegibles?

En mi experiencia, una campaña de instalación suele resolverlo cuando corre después de dos pasos de configuración: AEM configurado en Events Manager, con los términos de Meta aceptados donde los pide, y la atribución probabilística activada en el MMP, junto con cualquier ajuste de AEM que tenga. Paso la optimización al trial o a la compra cuando Events Manager lo muestra como elegible. Esa es mi práctica, no una instrucción de Meta: su página de resolución de problemas no lista ningún nivel de gasto ni ninguna campaña de instalación entre sus soluciones. Más presupuesto por sí solo no añade un campo que falta ni mueve un evento a la integración de la instalación.