Migración a AppsFlyer desde otros proveedores

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:

1. Integra el SDK de AppsFlyer en la aplicación.
   Consulta las guías para la integración del SDK para Android y iOS.
2. 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.
3. Elimina el SDK del proveedor de atribución competidor.
   Puedes hacerlo de inmediato y cambiarte exclusivamente a AppsFlyer, o ejecutar ambos SDKs simultáneamente durante unas semanas. Observa un desglose de estas opciones en la tabla que figura a continuación.
    

   Opción	Qué pasa después del lanzamiento de la versión actualizada de la aplicación	Impacto
   Elimina el SDK de la competencia (recomendado)	Solo AppsFlyer registra las nuevas instalaciones y 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. Sin 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 ad networks. Ver ejemplo a continuación. Carga de trabajo más alta.

4. 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 Android exista en sitios APK no oficiales, aunque no la conozcas (busca en internet el nombre del paquete de tu aplicación 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.

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 a la hora de 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 de lookback, son reclamados nuevamente por la SRN bajo AppsFlyer.

Una vez que migras los dispositivos, los datos se reflejan en AppsFlyer de la siguiente manera:

• Datos de instalación: Al igual que en 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 integrados in-app: Se graba y se muestra como orgánico para el método de migración de dispositivos sin atribución, o se atribuye a la fuente de medios y a la campaña, si se utiliza el método atribuido.
• Redireccionamiento: Las reatribuciones y re-engagements se muestran con normalidad.
• Datos de actividad: Se muestra con normalidad.
• Datos de retención y cohorte: Los dispositivos migrados no tienen ningún 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.  

Para migrar dispositivos: 

1. Decide qué usuarios deseas migrar. Puedes migrar a todos los usuarios existentes (lo que puede impedir que obtengas datos de reatribución precisos de AppsFlyer) o a los usuarios que instalaron tu aplicación recientemente (lo que puede hacer que se les cobre el doble a los usuarios algo más antiguos).
   Recomendamos migrar a los usuarios que estén activos durante el período de reatribución actual. Por ejemplo, si tu aplicación tiene un período de reatribución de 90 días, migra a los usuarios que hayan tenido al menos una sesión durante los 90 días anteriores.
2. [Opcional] Pídele al marketer/gerente de UA que pause las campañas de marketing existentes (de SRNs, ad networks no SRNs, medios propios, etc.) hasta que se complete la migración del dispositivo.
   Si decides no pausar las campañas, migra los ID de dispositivo restantes del otro proveedor tan pronto como se publique en las tiendas de aplicaciones la versión actualizada de la aplicación con el SDK de AppsFlyer.
3. 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
4. Envía el CSV a tu CSM de AppsFlyer.
   Tu CSM migrará los IDs de los dispositivos a AppsFlyer. 

Los eventos y sesiones integrados en la aplicación de los dispositivos migrados a AppsFlyer con este método se graban y se muestran de acuerdo con la fuente de medios reportada por el proveedor de atribución anterior y de acuerdo con las políticas de retención de datos de las ad networks.

Estructura del archivo CSV de migración de dispositivos atribuidos

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 5 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.
   

Ver ejemplo de CSV

Los dispositivos migrados a AppsFlyer con este método se atribuyen, pero no se muestran, como usuarios orgánicos. Los 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

Opción	Columnas	Cuándo usar	Ejemplo
1	ID de la aplicación + IDFA/GAID	Si todos tus usuarios de Android tienen identificadores GAID. Solo usuarios de iOS
2	ID de aplicación + ID de dispositivo + tipo de ID de dispositivo	Si algunos de tus usuarios de Android solo tienen IMEI o ID de Android, pero no ID de publicidad de Google (GAID) (mercados fuera de la tienda, versiones de Android inferiores a 4.4.2). El ID de Android debe tener un formato hexadecimal. Nota: Utiliza las cadenas exactas para la columna de tipo de ID: advertiserId (también es compatible con amazon_aid), idfa, idfv, android_id, imei. Si usas android_id o imei, y más tarde, AppsFlyer recibe un mejor identificador, se puede registrar una nueva atribución.

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. 
• Según la opción de estructura de archivos que elijas, las columnas de los archivos deben ser las siguientes (y en el orden indicado):
  • Opción 1: 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

Ver ejemplo de CSV

Las SRNs responden a los MMPs (partners de medición móvil) cuando se les pregunta sobre los engagements de dispositivos específicos. Si dos MMPs, 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.

Los enlaces de atribución de ad networks 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 ad networks que no sean SRN:

1. Activa las ad networks relevantes en AppsFlyer.
2. Genera enlaces de atribución de AppsFlyer para cada ad network.
3. Cambia los enlaces existentes en cada una de tus campañas por los enlaces de atribución de AppsFlyer. 

Los medios propios se refieren a los enlaces de atribución que utilizas en:

• Uso compartido de contenido
• Web-to-app
• Correo electrónico
• SMS
• Publicaciones en redes sociales
• Blogs
• Comunidades de internet (Quora, etc.)
• y más...

Para estas campañas, AppsFlyer usa enlaces de OneLink. Los enlaces de OneLink redireccionan a los usuarios según su dispositivo a la tienda de aplicaciones correcta, directamente a la aplicación o a una URL web/landing page.

Para cambiar tus enlaces de medios propios actuales a enlaces de AppsFlyer OneLink:

• Ponte en contacto con tu CSM, quien te ayudará a transformar tus propios enlaces de medios en enlaces de OneLink según los canales y las herramientas que utilices actualmente.

En el caso de la atribución 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.

Saber más sobre cómo configurar el valor de conversión de SKAN en AppsFlyer.

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:

• Contacta 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.

Puedes obtener reportes de raw data y agregados de AppsFlyer utilizando varios métodos. Familiarízate con los métodos y configura los que sean relevantes para ti.

Los métodos de reportes incluyen:

• Dashboards
• Exportar reportes
• API Push
• API Pull
• Data Locker