Guía para marketers sobre la integración con el SDK para iOS

Fondo

A partir del iOS 14.5, la recolección del identificador de anunciante (IDFA) requiere el consentimiento del usuario. En la práctica, significa que el acceso al IDFA se regirá por el marco de la App Tracking Transparency (ATT). En dispositivos con iOS 14+, el SDK utiliza el marco de la ATT para obtener acceso al IDFA del dispositivo. 

Para informarte sobre la ATT, consulta Principios de la ATT.

Cuando la atribución se produce utilizando el IDFA, es importante que el IDFA se envíe con el evento del primer inicio. Por esta razón, el SDK proporciona la utilidad waitForATTUserAuthorization.

Descripción general de waitForATTUserAuthorization

waitForATTUserAuthorization te permite configurar cuánto tiempo debe diferir el SDK en el envío de datos a los servidores de AppsFlyer y esperar el estado del ATT.

Cuando un usuario inicia la aplicación, el estado de ATT es notDetermined. Durante el intervalo de tiempo de espera waitForATTUserAuthorization:

• El SDK pone en cola el evento de inicio y los eventos in-app consecutivos en la memoria, de forma similar a cómo se atribuyen los eventos fuera de línea.
• Si el usuario da su consentimiento al aviso de la ATT (recopilación del IDFA):
  • El SDK agrega el IDFA a los eventos almacenados en caché.
  • El SDK inicia y envía los eventos almacenados en caché con el IDFA (sin esperar a que finalice el tiempo de espera).
• Si el usuario rechaza el aviso de la ATT:
  • El SDK inicia y envía los eventos almacenados en caché sin el IDFA (sin esperar a que finalice el tiempo de espera).
• Si el tiempo de espera termina y el estado de la ATT permanece como notDetermined:
  • El SDK inicia y envía los eventos almacenados en caché sin IDFA.

consideraciones

• Si se llama a requestTrackingAuthorization sin configurar waitForATTUserAuthorization, los inicios y eventos se enviarán sin IDFA para dispositivos con iOS 14+.
• Si el usuario mueve la aplicación al fondo durante el tiempo de espera:
  • El temporizador se pone en pausa hasta que la aplicación vuelva al primer plano.
  • Los eventos se almacenan en caché en la memoria.
• Si el usuario cierra o se finaliza la aplicación durante el tiempo de espera:
  • El temporizador se reinicia en el próximo inicio de la aplicación.
  • Los eventos almacenados en caché se pierden.

Puedes elegir personalizar el aviso de ATT. Un mensaje que indique claramente el propósito de la solicitud podría ayudar a aumentar las tasas de suscripción para los usuarios.

Ten en cuenta lo siguiente al crear tu mensaje:

• Utiliza el texto que mejor explique a tus usuarios por qué la aplicación solicita el consentimiento del usuario.
• Informa a los usuarios sobre cómo se utilizarán sus datos. Para obtener más información sobre la privacidad del usuario y el uso de datos, haz clic aquí.

Una vez que tu mensaje esté completo, proporciona a tu desarrollador el texto y estas instrucciones.

Para ver algunos ejemplos externos de mensajes de ATT, haz clic aquí.

SKAdNetwork es una clase que iOS utiliza y que valida las instalaciones de aplicaciones impulsadas por los anunciantes. El proceso de validación de la instalación de la aplicación involucra a la aplicación fuente y a la aplicación anunciada. 

Una aplicación fuente es una aplicación que participa en campañas publicitarias mostrando los anuncios firmados por una red de publicidad. La configuración de tu aplicación para mostrar anuncios no está dentro del alcance del SDK de AppsFlyer. Para configurarla, sigue las instrucciones de Apple.

Para la aplicación anunciada (la aplicación con el SDK de AppsFlyer), la Solución SKAdNetwork de AppsFlyer utiliza SKAdNetwork para proporcionar el postback de atribución mientras AppsFlyer recopila, traduce y agrega los datos, manteniendo la privacidad del usuario. Al iniciar la aplicación por primera vez, la plataforma de AppsFlyer utiliza la configuración establecida por el marketer para instruir al SDK sobre cómo establecer el valor de conversión de SKAdNetwork.

Para usar la Solución SKAdNetwork:

• El marketer debe configurar la medición de SKAdNetwork en AppsFlyer. El desarrollador no tiene que realizar ninguna tarea.
• El SDK de AppsFlyer llama automáticamente a las APIs necesarias de SKAdNetwork.
• Asegúrate de desactivar las llamadas de SKAdNetwork en otros SDK cuando confíes en AppsFlyer para la atribución de SKAdNetwork.
• No se requiere ninguna otra acción o proceso de registro por parte del desarrollador o del marketer en la App Store. 

Para desactivar la atribución de SKAdNetwork, indica a tu desarrollador que la deshabilite en el SDK. 

Puedes enviar los ingresos con cualquier evento in-app. Asegúrate de utilizar el parámetro af_revenue para incluir los ingresos. Es el único parámetro de evento que AppsFlyer cuenta como ingresos reales en el raw data y en el panel de control. Para más detalles, haz clic aquí. 

Para obtener instrucciones para desarrolladores, consulta el registro de ingresos.

El SDK de AppsFlyer proporciona verificación de servidor para las compras in-app. Al validar una compra in-app, se envía automáticamente un evento de compra in-app a AppsFlyer. Si envías este evento tú mismo, se crea un reporte de evento duplicado.

Si tu aplicación pertenece a una vertical como viajes, gaming o comercio electrónico, consulta nuestra lista de eventos in-app recomendados por vertical.

Para los usuarios que no tienen tu aplicación instalada, OneLink detecta el tipo de dispositivo y los redirige al destino correcto (por ejemplo, Google Play, Apple App Store, tienda de aplicaciones de terceros o página web). Esto se basa en la configuración de la plantilla de OneLink. Aprender más

Nota: La detección y redirección de dispositivos no requiere el SDK de AppsFlyer. Sin embargo, se requiere el SDK para los enlaces profundos.

Para los usuarios con tu aplicación instalada, OneLink abre la aplicación. Además de abrir la aplicación, también puedes establecer deep links entre los usuarios y cualquier actividad o página específica dentro de tu aplicación. Esto requiere que tu desarrollador implemente Unified Deep Linking (UDL).

Nota:

• UDL requiere SDK V6.1+.
• Los clientes que ya usan OneLink para enlaces profundos pueden estar usando el método heredado, en lugar de UDL.

Consulta nuestra guía sobre configuración de enlaces profundos con OneLink.

Para los usuarios que no tienen tu aplicación instalada, OneLink detecta el tipo de dispositivo y los redirige al destino correcto (por ejemplo, Google Play, Apple App Store, tienda de aplicaciones de terceros o página web). Una vez que el usuario inicia la aplicación, puedes usar Deferred Deep Linking para redirigirlos a una actividad o página específica dentro de la aplicación.

Esto requiere que tu desarrollador implemente Unified Deep Linking (UDL).

Nota:

• UDL requiere SDK V6.1+.
• Los clientes que ya usan OneLink para Deferred Deep Linking pueden estar usando el método heredado, en lugar de UDL.

Consulta nuestra guía sobre enlaces profundos diferidos para aprender más.

AppsFlyer admite la medición de las campañas de notificaciones push de todos los proveedores y también puede admitir a los desarrolladores que utilizan Google Cloud Messaging o los servicios de notificaciones push de Apple directamente. Las conversiones, definidas como aplicaciones que se abren a partir de mensajes de notificaciones push, se muestran en el panel de control de retargeting.

Puedes usar OneLink para medir el re-engagement de usuarios a través de notificaciones push. Consulta nuestra guía sobre la medición de campañas de re-engagement de notificaciones push.

Para saber cómo configurar la medición de desinstalaciones, lee aquí.

Si quieres recibir una confirmación de que el SDK comenzó satisfactoriamente y notificó a los servidores de AppsFlyer, implementa el controlador startWithCompletionHandler. A continuación, puedes aplicar una lógica para manejar el éxito o el fracaso del inicio del SDK.

Ejemplo de implementación

[[AppsFlyerLib shared] startWithCompletionHandler:^(NSDictionary<NSString *,id> *dictionary, NSError *error) {
        if (error) {
            NSLog(@"%@", error);
            return;
        }
        if (dictionary) {
            NSLog(@"%@", dictionary);
            return;
        }
    }];

 AppsFlyerLib.shared()?.start(completionHandler: { (dictionnary, error) in
            if (error != nil){
                print(error ?? "")
                return
            } else {
                print(dictionnary ?? "")
                return
            }
        })

En caso de que se produzca un error durante la escucha de la solicitud, se proporciona un código de error y una descripción de la cadena, como se indica en la tabla que figura a continuación.

La API setAdditionalData te permite agregar datos personalizados a los eventos enviados desde el SDK. Normalmente se utiliza para integrarse en el nivel del SDK con varias plataformas de partners externos, incluidos Segment, Adobe y Airship.

Ejemplo de código de setAdditionalData:

NSDictionary* customDataMap = [[NSDictionary alloc] initWithObjectsAndKeys:@"value_of_param_1", @"custom_param_1", nil];
[[AppsFlyerLib shared] setAdditionalData:customDataMap];

let customDataMap: [AnyHashable: Any] = [
  "custom_param_1" : "value_of_param_1"
]
AppsFlyerLib.shared().customData = customDataMap

Los propietarios de aplicaciones que usan enlaces universales para deep linking (sin OneLink) y tienen un dominio asociado con su aplicación pueden atribuir sesiones iniciadas a través de este dominio mediante el método appendParametersToDeepLinkingURL.

Por ejemplo, un usuario busca en Google y hace clic en tu dominio, www.ejemplo.com:

• Si el usuario no tiene la aplicación instalada, será direccionado al sitio web (www.ejemplo.com).
• Si el usuario tiene la aplicación instalada en su dispositivo, tendrá enlaces profundos a la aplicación asociada con www.ejemplo.com. La sesión se atribuye a la fuente de medios (parámetro pid) especificada en appendParametersToDeepLinkingURL.

Consulta la referencia del SDK del iOS para obtener más información.

Nota: Los Smart Banners ayudan a los propietarios de aplicaciones a convertir a los visitantes del sitio web en usuarios de la aplicación.

De manera predeterminada, deben pasar por lo menos 5 segundos entre 2 instancias de inicio de la aplicación para que cuenten como 2 sesiones separadas (más información acerca del recuento de sesiones).

Usa la siguiente API para establecer el tiempo mínimo entre sesiones:

[AppsFlyerLib shared].minTimeBetweenSessions = <your_custom_time_in_seconds>;

AppsFlyerLib.shared().minTimeBetweenSessions = <your_custom_time_in_seconds>

Establecer un valor alto para el tiempo personalizado entre inicios podría afectar negativamente las API que dependen de los datos de sesión, como los enlaces profundos.

No disponible en iOS. 

Algunos servicios de terceros, como los proveedores de servicio de correo electrónico encapsulan enlaces en los mensajes de correo electrónico con sus propios dominios de registro de clics. Algunos incluso te permiten configurar tus propios dominios de registro de clics. Si OneLink está encapsulado en tales dominios, su funcionalidad podría verse limitada.

Para resolver este problema, puedes usar la API setResolveDeepLinkURLs. Usa esta API para obtener el OneLink de los dominios de clics que inician la aplicación.  Asegúrate de llamar a esta API antes de la inicialización del SDK.

Por ejemplo, tienes tres dominios de clics que redirigen a tu OneLink, que es https://mysubdomain.onelink.me/abCD. Usa esta API para obtener el OneLink al cual redirigen tus dominios de clics.  Este método de API recibe una lista de dominios que el SDK resolverá.

[AppsFlyerLib shared].resolveDeepLinkURLs = @[@"example.com",@"click.example.com"];

AppsFlyerLib.shared().resolveDeepLinkURLs = ["example.com", "click.example.com"]

El código anterior te permite usar tu dominio de clics y, al mismo tiempo, preservar la funcionalidad de OneLink. Los dominios de clics son responsables de iniciar la aplicación. A su vez, la API obtiene el OneLink de estos dominios de clics y, a continuación, tú puedes usar los datos de este OneLink para establecer enlaces profundos y personalizar el contenido de los usuarios.

Con AppsFlyer, puedes medir notificaciones push como parte de las campañas de retargeting.

Para habilitar esta función, llama al método handlePushNotificationData dentro de AppDelegate.m.

-(void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)userInfo fetchCompletionHandler:(void (^)(UIBackgroundFetchResult))completionHandler {
[[AppsFlyerLib shared] handlePushNotification:userInfo];
}

func application(_ application: UIApplication, didReceiveRemoteNotification userInfo: [AnyHashable : Any], fetchCompletionHandler completionHandler: @escaping (UIBackgroundFetchResult) -> Void) {
    AppsFlyerLib.shared().handlePushNotification(userInfo)
}

Para obtener más información sobre la medición de notificaciones push, lee aquí.

Permitir que tus usuarios actuales inviten a sus amigos y contactos como nuevos usuarios de tu aplicación puede ser un factor de crecimiento clave para tu aplicación. Con AppsFlyer, puedes atribuir y registrar instalaciones que se originen a partir de invitaciones de usuarios dentro de tu aplicación.

Para conocer más detalles, consulta el artículo sobre atribución de invitaciones de usuarios.

¡Nota! La promoción cruzada por identificador de proveedor (IDFV) requiere el SDK 6.0.2+. El IDFV se recoge automáticamente y no se requiere ninguna acción adicional por parte del desarrollador.

Un ID de dispositivo exclusivo de AppsFlyer se crea para cada instalación nueva de una aplicación. Puedes usar este ID con diversos fines:

• Enviar eventos in-app de servidor a servidor.
• Vincúlala con los registros de usuarios en tus sistemas de backend.
• Asignar entradas cuando se fusionan datos de las API de extracción y envío (Pull/Push API).

Usa la siguiente API para obtener el ID único de AppsFlyer:

NSString *appsflyerId = [AppsFlyerLib shared].getAppsFlyerUID;

let appsflyerId = AppsFlyerLib.shared().getAppsFlyerUID()

Para configurar tu ID de usuario de cliente:

[AppsFlyerLib shared].customerUserID = @"my user id";

AppsFlyerLib.shared().customerUserID = "my user id"

En iOS, el ID de usuario de cliente debe configurarse con cada inicio de la aplicación. Te recomendamos configurar el ID de usuario de cliente lo antes posible en el flujo de tu aplicación, ya que solo se asocia con los eventos reportados después de su configuración:

• Si se llama a setCustomerUserId antes de llamar a start, el ID de usuario de cliente aparece en los reportes de raw data de instalaciones y eventos.
• Si se configura después, el ID de usuario de cliente se asocia solo con eventos registrados después de configurar dicho ID.

Para evitar configurar el valor del ID de usuario de cliente nuevamente después del primer inicio, y reducir las llamadas a tu servidor para obtener el ID de usuario de cliente, puedes verificar si su valor está vacío, o no, de la siguiente forma:

NSString *customerUserID = [AppsFlyerLib shared].customerUserID;

let customerUserID = AppsFlyerLib.shared().customerUserID

Para obtener más información sobre el ID de usuario de cliente, haz clic aquí.

Puedes retrasar la inicialización del SDK hasta que se configure el ID de usuario de cliente. Esto es útil si deseas que los datos de instalación y eventos contengan tu ID de usuario de cliente.

Implementa el siguiente código:

- (void)applicationDidBecomeActive:(UIApplication *)application {
    NSString *customUserId = [[NSUserDefaults standardUserDefaults] stringForKey:@"customerUserId"]; // Your custom logic of retrieving CUID
    if (customUserId != nil && ![customUserId  isEqual: @""]) {
        [AppsFlyerLib shared].customerUserID = customUserId; // Set CUID in AppsFlyer SDK for this session
        [[AppsFlyerLib shared] start]; // Start
    }
}

func applicationDidBecomeActive(_ application: UIApplication) {
        let customUserId = UserDefaults.standard.string(forKey: "customUserId")  //  your logic to retrieve CUID
        if(customUserId != nil && customUserId != ""){
            AppsFlyerLib.shared().customerUserID = customUserId // Set CUID in AppsFlyer SDK for this session
            AppsFlyerLib.shared().start() // Start
        }
    }

Para aprender más acerca de cómo retrasar la inicialización del SDK hasta que esté disponible el ID de usuario de cliente, ve aquí.

Es posible que desees retrasar la inicialización del SDK y el envío de datos hasta que el usuario lo autorice (por ejemplo, el consentimiento del RGPD y la CCPA).

Nota: Esto no está relacionado con la incorporación de ATT en iOS 14. 

Para retrasar la inicialización del SDK:

1. Evita que la sesión se envíe en transición de fondo a primer plano. En un método sendLaunch() que se llama en cada applicationDidBecomeActive (como en la sección 3.3), encapsula la llamada en start con una comprobación de la condición. Por ejemplo:
   
   

   -(void)sendLaunch:(UIApplication *)application {
       if (consent_given) { // check the condition
           [[AppsFlyerLib shared] start]; // Start
       }
   }

2. Envía la sesión tan pronto como el motivo de la demora deje de ser relevante (justo después de que cambie la condición). Llama a start cuando estés listo para enviar los datos de la primera sesión. Por ejemplo:
   
   

   ...
   consent_given = YES; // change the condition
   [[AppsFlyerLib shared] start]; // Start
   ...

En algunos casos extremos, tal vez necesites desactivar todo el registro de datos del SDK para cumplir con la ley y las políticas de privacidad. Puedes hacer esto con la propiedad isStopped. Una vez que esta propiedad se configura como verdadera, el SDK deja de funcionar y ya no se comunica con los servidores de AppsFlyer.

Existen varios casos para que un usuario opte por la exclusión. Es muy recomendable que sigas las instrucciones exactas para la situación correspondiente a tu aplicación.

[AppsFlyerLib shared].isStopped = true;

AppsFlyerLib.shared().isStopped = true

En cualquier evento, se puede reactivar el SDK llamando a la misma API y pasando un valor falso.

Usa esta API durante la Inicialización del SDK para anonimizar explícitamente las instalaciones, los eventos y las sesiones de un usuario:

[AppsFlyer shared].anonymizeUser = YES;

AppsFlyerLib.shared().anonymizeUser = true

Para reiniciar el registro de datos, puedes configurar anonymizeUser como false (falso).

Usa el SDK de modo estricto para eliminar completamente la funcionalidad de recopilación del identificador de anunciante (IDFA) y las dependencias del marco de AdSupport (por ejemplo, al desarrollar aplicaciones para niños).

Nota: El IDFV sigue estando disponible.

En tu Podfile, reemplaza la dependencia de AppsFlyerLib con:

pod 'AppsFlyerFramework/Strict','6.2.3'

Para deshabilitar los marcos AdSupport e iAd, el SDK proporciona los siguientes configuradores:

• disableCollectASA = true. Más información
• disableAdvertisingIdentifier = true. Más información

Para desactivar los marcos de anuncios:

[AppsFlyerLib shared].disableCollectASA = YES
[AppsFlyerLib shared].disableAdvertisingIdentifier = YES;

AppsFlyerLib.shared().disableCollectASA = true
AppsFlyerLib.shared().disableAdvertisingIdentifier = true

En algunos casos, es posible que los anunciantes deseen dejar de compartir datos a nivel usuario con las redes de publicidad o los partners para usuarios específicos. Las razones para esto incluyen: 

• Políticas de privacidad como la CCPA o el RGPD
• Mecanismos de exclusión opcional de los usuarios
• Competencia con algunos partners (redes de publicidad, terceros)

AppsFlyer proporciona dos métodos de la API para dejar de compartir datos con algunos o todos los partners:

• setSharingFilter: Utilizado por los anunciantes para evitar el intercambio de datos con algunas (una o más) redes/partners integrados.
• setSharingFilterForAllPartners: Utilizado por los anunciantes para evitar el intercambio de datos con todas las redes y partners integrados.

Estos métodos de filtrado son compatibles a partir del SDK V5.4.1.

El método de filtrado debe llamarse cada vez que se inicializa el SDK y afecta a toda la sesión. Si se necesita tiempo para determinar si es necesario configurar los filtros de compartición, entonces retrasa la inicialización del SDK. 

Cuando el método se activa antes de la primera llamada a start:

• Los usuarios de SRN se atribuyen como orgánicos, y sus datos no se comparten con los partners integrados.
• Los usuarios de redes de publicidad de clic (no SRN) se atribuyen correctamente en AppsFlyer, pero no se comparten con las redes de publicidad a través de postbacks, API, reportes de raw data o por cualquier otro método.

Actualmente, los datos de desinstalación no pueden filtrarse con estos métodos. Sin embargo, puedes dejar de enviar los eventos de desinstalación a los partners usando sus páginas de configuración en AppsFlyer.