De un vistazo: Planifica tu migración a AppsFlyer desde otro proveedor de atribución. Entiende cómo evitar cobros dobles, duplicación de datos y pérdida de datos durante el período de migración.
Información general
La migración a AppsFlyer desde otro proveedor incluye las siguientes tareas principales:
- Integración de SDK
- Migración de dispositivos
- Migración de campañas
- Configuración de reporte de datos
Puedes trabajar en estas tareas simultáneamente. Sin embargo, te recomendamos que:
- Completes todas las tareas antes de lanzar tu aplicación actualizada con el SDK de AppsFlyer.
- Detengas las campañas de marketing existentes antes de realizar la migración del ID de dispositivo.
Nota
Si quieres comparar la medición de atribución entre tu MMP actual y AppsFlyer para las mismas campañas y fuente de medios, consulta este artículo.
Tareas
La siguiente tabla describe el alcance del trabajo requerido para cada tarea. Para ver un desglose preciso de las tareas generales en el orden en que debes cumplirlas, así como para registrar tu progreso, descarga esta hoja de cálculo.
Alcance del trabajo
| Tarea | Acción requerida | Quién debe participar | Tiempo estimado | Observaciones |
|---|---|---|---|---|
| Requisitos previos |
|
Usuario del panel de control de AppsFlyer/Marketer |
2 horas |
|
| Integración de SDK |
|
Desarrolladores de aplicaciones |
1-2 semanas |
|
| Migración de dispositivos [opcional] | Migra los ID de dispositivo para evitar la doble atribución de los usuarios existentes. | Ingeniero de datos | 1-2 semanas |
|
| Migración de campañas |
|
Gerente de UA/marketer | 1-3 semanas | |
| Configuración de reporte de datos |
|
Ingeniero de datos | 2-4 semanas |
Integración de SDK
Integración de SDK
El SDK de AppsFlyer integrado en la aplicación es el enlace entre la aplicación y la plataforma de AppsFlyer. Reporta las instalaciones de aplicaciones, aperturas de aplicaciones, eventos in-app, etc.
Para integrar el SDK de AppsFlyer:
- Integra el SDK de AppsFlyer en la aplicación.
Consulta las guías para la integración del SDK para Android y iOS. - Asigna los eventos in-app que deseas registrar, utilizando los esquemas de AppsFlyer.
Esto se puede hacer a través de SDK o de S2S. - Elimina el SDK del proveedor de atribución competidor.
Puedes hacerlo de inmediato y cambiarte exclusivamente a AppsFlyer, o ejecutar ambos SDK simultáneamente durante unas semanas. Observa un desglose de estas opciones en la tabla que figura a continuación.
Opción Qué sucede después de
lanzar la versión actualizada de la aplicaciónImpacto Elimina el SDK de la competencia (recomendado) Solo AppsFlyer registra nuevas instalaciones y las actualizaciones de los usuarios.
La competencia aún muestra los eventos realizados por los usuarios hasta que los usuarios también actualicen su aplicación.- Transición rápida.
- No hay atribución doble.
Mantén el SDK de la competencia durante un período de transición AppsFlyer y la competencia atribuyen instalaciones nuevas y reportan eventos. Más adelante, elimina el SDK de la competencia. - La validación de datos es posible. Es decir, puedes comparar los datos de AppsFlyer y del otro proveedor.
- Doble atribución, lo cual puede provocar un cobro doble de las redes publicitarias. Ver ejemplo a continuación.
- Carga de trabajo más alta.
- Una vez completadas todas las demás tareas del alcance del trabajo, actualiza la versión de la aplicación con el SDK de AppsFlyer para el mercado. AppsFlyer atribuye a los usuarios nuevos.
Nota:- Asegúrate de actualizar la aplicación para iOS, Google Play y cualquier mercado fuera de la tienda de Android relevante.
- Es posible que tu aplicación de Android exista en sitios APK no oficiales, aunque no sepas (busca el nombre del paquete de tu aplicación en la web para averiguarlo). Los sitios APK tardan un tiempo en actualizarse a la última versión, por lo que pueden traer usuarios orgánicos, que instalan versiones anteriores sin el SDK de AppsFlyer.
- Las implementaciones de actualizaciones de la aplicación en las tiendas de aplicaciones pueden tardar hasta un par de días en completarse. Es posible que los usuarios que realizaron la instalación durante esta fase obtengan la versión anterior.
Migración de dispositivos: opcional
Acerca de la migración de dispositivos
La migración de dispositivos es el proceso de cargar una lista de tus ID de dispositivos de usuario existentes (IDFA, IDFV, GAID, CUID) en AppsFlyer. Debes realizar este proceso antes de lanzar la nueva versión de la aplicación, que incluirá el SDK de AppsFlyer. Hay dos opciones al migrar dispositivos, migración atribuida o no atribuida.
La migración de dispositivos resuelve los problemas de datos asociados con los usuarios de aplicaciones existentes que descargaron la aplicación y que fueron atribuidos por tu proveedor anterior. Por ejemplo, los cargos dobles de SRN, que ocurren cuando los usuarios originalmente atribuidos a una SRN bajo tu proveedor anterior, y que todavía están dentro de la ventana retrospectiva, son reclamados nuevamente por la SRN bajo AppsFlyer.
Ejemplo
- Un usuario nuevo hace clic en un anuncio en la aplicación de Facebook e instala tu aplicación el 15 de junio.
- El 24 de junio, el usuario actualiza la aplicación a la versión con el SDK de AppsFlyer y la inicia. Para AppsFlyer, este es un usuario nuevo, que debe atribuirse en tiempo real.
- AppsFlyer consulta a Anuncios de Meta sobre el ID de dispositivo del usuario. Dado que el usuario aún se encuentra dentro de la ventana retrospectiva de 28 días de Anuncios de Meta, Anuncios de Meta se autoatribuye al usuario. Esto provoca un cobro doble al propietario de la aplicación por el mismo usuario.
Una vez que migras los dispositivos, los datos se reflejan en AppsFlyer de la siguiente manera:
- Datos de instalaciones: Son similares a las Reinstalaciones, los dispositivos migrados no tienen datos de instalación. Las instalaciones de los dispositivos migrados no se muestran en AppsFlyer.
- Datos de sesiones y eventos in-app: Se registran y se muestran como orgánicos para el método de migración de dispositivos no atribuidos, o atribuidos a la fuente de medios y a la campaña, si se utiliza el método atribuido.
- Retargeting: Las reatribuciones y los re-engagements se muestran normalmente.
- Datos de actividad: se muestran normalmente.
- Datos de retención y cohortes: los dispositivos migrados no tienen registro de instalación. Por lo tanto, no están asociados con ninguna cohorte y no se pueden mostrar en los reportes de retención y de cohortes.
Cómo migrar dispositivos
Para migrar dispositivos:
-
Decide qué población de usuarios deseas migrar. Puedes migrar todos los usuarios existentes (lo que puede impedirte obtener datos precisos de reatribución de AppsFlyer), o solo los usuarios que instalaron tu aplicación recientemente (lo que puede ocasionar cargos dobles por los usuarios más antiguos).
Recomendamos migrar los usuarios activos durante el período de la ventana de reatribución actual. Por ejemplo, si tu aplicación tiene una ventana de reatribución de 90 días, migra a los usuarios que tengan al menos una sesión durante los 90 días anteriores. - [Opcional] Dile al marketer/gerente de UA que pause las campañas de marketing actuales (de SRN, redes de publicidad no SRN, medios propios, etc.) hasta después de la migración de dispositivos.
Si decides no pausar las campañas, migra los ID de dispositivo restantes del otro proveedor tan pronto como la versión actualizada de la aplicación con el SDK de AppsFlyer se lance a las tiendas de aplicaciones. - Prepara un archivo CSV basado en la población de usuarios seleccionada, utilizando la estructura de migración atribuida o no atribuida. Ver ejemplo de CSV
- Envía el CSV a tu CSM de AppsFlyer.
Tu CSM migrará los ID de los dispositivos a AppsFlyer.
Migración atribuida
Para los dispositivos que migraron a AppsFlyer con este método, sus eventos in-app y sesiones se atribuyen y muestran de acuerdo con la fuente de medios reportada por el proveedor anterior de atribución, y de acuerdo con las políticas de retención de datos de las redes de publicidad.
Estructura del archivo CSV de migración de dispositivos atribuidos
| Nombre de la columna |
Descripción | Obligatorio | Ejemplos |
|---|---|---|---|
| app_id |
ID de aplicación tal como aparece en el dashboard de AppsFlyer |
Sí |
|
|
platform |
Plataforma del dispositivo: iOS o Android |
Sí |
|
|
device_id |
|
Sí |
|
| id_type |
|
Sí |
|
| install_time |
La fecha y hora de instalación original de la aplicación con el formato ISO 8601 UTC:
|
No |
2018-01-22T08:45:33.412 |
| media_source |
|
Sí |
Orgánico: organic |
| integrated_partner |
|
Sí |
|
| campaign |
Para obtener detalles de atribución más granulares, suministra el nombre original de la campaña. Formato: Secuencia |
No | |
| campaign_id |
Para obtener detalles de atribución más granulares, suministra el ID original de la campaña. Formato: secuencia sin espacios |
No |
Reglas de archivo CSV:
- El archivo CSV puede contener dispositivos de usuarios de varias aplicaciones.
- No dupliques la misma combinación de ID de dispositivo e ID de aplicación en varias filas. Si se produce una duplicación, se utiliza la última aparición en el archivo.
- Deben incluirse todos los encabezados de las columnas: app_id, platform, device_id, id_type, install_time, media_source, integrated_partner, campaign, campaign_id. Nota: El orden de los campos es importante y debe mantenerse.
- Puedes agregar el IDFV y el IDFA para el mismo dispositivo, pero deben estar en filas separadas. Todos los campos de las filas separadas deben ser los mismos, excepto device_id.
- Cada fila debe contener exactamente 9 campos separados por comas.
- Deja los campos no obligatorios vacíos (en blanco).
- Los archivos pueden contener hasta 20 millones de filas.
- Si tienes varios archivos, ponle a cada uno un nombre único.
- Codifica datos utilizando UTF-8.
- [Opcional] Comprime archivos con ZIP o GZIP.
Migración no atribuida
Los dispositivos migrados a AppsFlyer con este método se atribuyen, pero no se muestran, como usuarios orgánicos. Sus datos de sus sesiones y eventos in-app también se atribuyen y se muestran como orgánicos.
Estructura del archivo CSV de migración de dispositivos no atribuidos
| Columnas | Cuándo usar | Ejemplo |
|---|---|---|
| ID de aplicación + IDFA/GAID/IDFV |
|
|
| ID de aplicación + ID de dispositivo + tipo de ID de dispositivo |
Nota:
|
|
Reglas de archivo CSV:
- El archivo CSV puede contener dispositivos de usuarios de varias aplicaciones.
- Cada fila contiene un ID de dispositivo único por aplicación.
- Los archivos deben incluir todos los encabezados de las columnas como se indica a continuación:
- Opción 1: El archivo debe incluir todos los encabezados de las columnas de la siguiente manera: app_id,device_id
- Opción 2: app_id,device_id,id_type
- ID de aplicación en minúsculas
- Identificadores de Android en minúsculas
- IDFA/IDFV en mayúsculas
- Se permiten hasta 25
millones de filas
Migración de campañas
Cambia las campañas de marketing actuales a AppsFlyer para habilitar la atribución de AppsFlyer, y evita cargos duplicados y la pérdida de datos de atribución.
Nota: Puedes optar por migrar solo algunas campañas de marketing a la vez. En este caso, puedes segmentar las que deseas migrar por fuente de medios (por ejemplo, red de publicidad o agencia), geolocalización o campaña.
SRN
Las SRN responden a los MMP (partners de medición móvil) cuando se les pregunta sobre los engagements de dispositivos específicos. Si dos MMP, por ejemplo AppsFlyer y un proveedor de atribución de la competencia, consultan la misma SRN sobre la misma instalación del dispositivo, se puede incurrir en cobros dobles.
Para migrar campañas de SRN:
- Activa y configura las SRN relevantes en AppsFlyer.
Nota
- Las SRN pueden ejecutar varios MMP (excepto Anuncios de Meta y Twitter).
- Anuncios de Meta no puede desduplicar eventos in-app.
Redes de publicidad no SRN
Los enlaces de atribución de redes de publicidad registran los engagements de los usuarios y se usan posteriormente para atribuir los engagements, que se convierten en instalaciones reales.
Para migrar campañas de redes de publicidad que no sean SRN:
- Activa las redes de publicidad relevantes en AppsFlyer.
- Genera enlaces de atribución de AppsFlyer para cada red de publicidad.
- Cambia los enlaces existentes en cada una de tus campañas por los enlaces de atribución de AppsFlyer.
Medios propios
Los medios propios se refieren a los enlaces de atribución que utilizas en:
- Uso compartido de contenido
- De la web a la aplicación
- Correo electrónico
- SMS
- Publicaciones en redes sociales
- Blogs
- Comunidades de Internet (Quora, etc.)
- y más...
Para estas campañas, AppsFlyer utiliza enlaces personalizados de OneLink. Los enlaces personalizados de OneLink redirigen a los usuarios según su dispositivo a la tienda de aplicaciones correcta, directamente a la aplicación o a una URL web/página de destino.
Para cambiar los enlaces de otros proveedores a OneLinks de AppsFlyer:
- Comunícate con tu CSM, que te ayudará con la migración masiva de todos tus enlaces.
SKAN
Para la atribución de SKAdNetwork (SKAN), solo puedes hacer que un SDK actualice el valor de conversión. De lo contrario, los datos de SKAN no tienen sentido. Por lo tanto, asegúrate de que, después de la migración, solo el SDK de AppsFlyer actualice el valor de conversión de SKAN.
Obtén más información sobre cómo configurar el valor de conversión de SKAN en AppsFlyer.
Configuración de reporte de datos
Adaptar y asignar estructuras de reportes
Antes de la migración, los sistemas almacenan los datos de atribución del proveedor actual de acuerdo con los parámetros, campos y estructuras de reportes que hayas configurado con ellos. Para que AppsFlyer reporte correctamente los datos, debes adaptar y asignar tus estructuras de reportes actuales a los parámetros, campos y estructuras de reportes de AppsFlyer.
Para adaptar/asignar tus estructuras de reportes:
- Comunícate con tu CSM de AppsFlyer para obtener ayuda para adaptar/migrar rápidamente las estructuras de datos de tus reportes de Adjust, Branch/Tune o Kochava a AppsFlyer.