Atribución granular compatible con iOS 14

Esta publicación del blog se actualizó el 29 de julio de 2020 para incluir más detalles sobre las maneras en que Adjust apoyará a sus clientes y socios después de la llegada de iOS 14, otros escenarios posibles para tener una solución confiable en los dispositivos, y nuestra postura sobre el hash de atribución.

Como describimos en nuestra publicación anterior del blog, Adjust ha estado investigando a profundidad todas las opciones para ofrecer una atribución precisa y granular bajo las nuevas reglas propuestas que se incluirán en iOS14.

En Adjust, apoyaremos a nuestros clientes y socios mediante tres métodos diferentes:

• Atribución determinista por suscripción mediante el entorno de trabajo AppTrackingTransparency
• Medición probabilista impulsada por varias señales no deterministas
• SKAdNetwork como conjunto de datos adicional

Nuestra solución de atribución cumple con todos los lineamientos de Apple, incluso para los usuarios que no se suscriben. Sin embargo, independientemente de la atribución, recomendamos que los desarrolladores de aplicaciones implementen en su aplicación un flujo de autorización que aproveche el entorno de trabajo AppTrackingTransparency, presentado por Apple en WWDC2020, para obtener una ventaja competitiva en el lado de la oferta y en el lado de la demanda.

Esta publicación presenta las investigaciones que hemos realizado en torno a una propuesta de solución, a la que llamamos el "hash de atribución". Con este blog, queremos fomentar debates y recopilar opiniones sobre lo que "device attribution" podría ser. El objetivo a largo plazo es lograr que Apple valide una solución confiable en el dispositivo, la cual se pueda aprovechar en el sector sin dejar de respetar los lineamientos de Apple.

Creemos que Apple debe ser la única parte que controle el ID de los dispositivos, así como las API para la atribución en el dispositivo, según la definición de privacidad incluida en iOS14, y esperamos que la solución evolucione hacia esa dirección.

A continuación presentamos los pasos que deben seguir los diferentes participantes del ecosistema.

El lado de la oferta

Comencemos con los publishers de anuncios. Esto incluye a todas las aplicaciones, desde las redes sociales hasta los juegos, que generan sus ingresos a partir de los anuncios y las redes publicitarias que utilizan para monetizar.

Para que los usuarios de las aplicaciones decidan activamente compartir su IDFA en iOS 14, son los publishers de aplicaciones quienes deberán demostrar el valor o el beneficio que pueden ofrecerles a los consumidores. Apple no ha prescrito ninguna limitación sobre la manera en que se puede comunicar este intercambio de valor con los usuarios, lo que genera nuevas oportunidades.

Por ejemplo, los publishers de aplicaciones podrían ofrecerles a los usuarios la posibilidad de elegir entre una versión de la aplicación que sea gratuita con soporte publicitario y una versión de pago sin publicidad.

Las aplicaciones de redes sociales podrían simplemente agregar a sus términos y condiciones que los usuarios les deben permitir mostrar anuncios y compartir el IDFA para poder utilizar todas las funciones de la aplicación.

Al fin y al cabo, mientras haya demanda, la oferta tiene incentivos para innovar. Las aplicaciones de publishers que demuestren su valor obtendrán la autorización de los usuarios con mayor frecuencia, y estos publishers obtendrán un mejor inventario como recompensa.

Creemos que la oferta se regirá por este principio básico de economía.

El lado de la demanda

El mayor desafío de ofrecer la atribución basada en el IDFA en iOS 14 es que en el momento en que se instale la aplicación de un anunciante, se necesitaría el IDFA del dispositivo.

Si una aplicación se monetiza mediante suscripciones y compras dentro de la aplicación y no muestra anuncios, no existe un incentivo lógico para que los usuarios autoricen compartir su IDFA al instalarla.

Este es el problema central y una de las principales razones por las que algunos participantes del sector lo han llamado "la muerte del IDFA".

Sin embargo, Apple describió una excepción crucial en su entorno de trabajo de AppTrackingTransparency.

Entonces, ¿cómo podemos atribuir una instalación o un re-engagement sin enviar ningún dato del dispositivo que pueda identificar al usuario o al dispositivo?

Encontramos una solución potencial: el hash de atribución.

Detalles técnicos del hash de atribución

La idea es bastante simple: una vez abierta, la aplicación del anunciante lee el IDFA y el IDFV.

Luego, la aplicación calcula un SHA256 (hash seguro) para el IDFA y el IDFV, y lo convierte en algo que llamaremos el "hash de atribución".

Por ejemplo, si el IDFA es 236A005B-700F-4889-B9CE-999EAB2B605D y el IDFV es C305F2DB-56FC-404F-B6C1-BC52E0B680D8, entonces el hash de atribución se convierte en a5a884a5dd3758ae7f0d333f56933df76d4a609a77e54ecc5db51ac8651fb5658.

Entonces, ¿cuál es la naturaleza de este hash?

Primero, vamos a repasar qué es un hash. En pocas palabras, es una función unidireccional que siempre produce el mismo resultado (output) para una entrada específica (input), pero no permite invertir la salida para convertirla en la entrada. Este video muestra una explicación sencilla de lo que es el hash y cómo funciona.

La entrada del hash de atribución hereda la naturaleza de la entrada más volátil. Esto significa que nuestro hash se comportará de forma muy parecida al IDFV: nunca será el mismo entre dos aplicaciones diferentes ubicadas en el mismo dispositivo, a menos que sean del mismo publisher de aplicaciones, al igual que el IDFV.

Esto significa que no puedes usarlo para hacer retargeting ni para construir el perfil de un usuario mediante otras aplicaciones del dispositivo. También significa que no identifica ni al usuario ni al dispositivo, igual que el IDFV.

Ahora, imaginemos que el SDK de un MMP toma este hash y el IDFV, y lo envía al backend de el MMP.

Ningún identificador de usuario o de dispositivo ha salido del dispositivo, y el IDFA únicamente se utilizó de forma local para calcular el hash.

Para atribuir el uso de este hash, un MMP revisaría todos los IDFA que recibió del lado de la oferta para las interacciones publicitarias que podrían haber impulsado esta actividad en la aplicación. Y recuerda: todos esos IDFA se enviaron a el MMP con la autorización obtenida en la aplicación donde se publican los anuncios.

Luego, el MMP puede calcular todos los hashes SHA256 de cada coincidencia posible con los IDFA e IDFV que recibió. Si uno de esos hashes es igual al hash de atribución del dispositivo, se genera una coincidencia exacta, lo que te permite atribuir casi de la misma manera en que lo harías con los IDFA actualmente.

Lo elegante de esta solución es que, incluso teniendo el IDFV y el hash de atribución, no es posible obtener el IDFA de vuelta sin conocerlo de antemano. A menos que hayas recibido un IDFA aprobado por el usuario, no puedes hacer nada con el hash de atribución.

Debido a su naturaleza limitada, los MMP solo utilizarían el hash de atribución de forma interna.

En resumen

Cuando se tiene acceso al IDFA desde el lado de la oferta, Adjust propone utilizar para la atribución un hash de IDFA e IDFV (o cualquier otra sal aleatoria), calculado por la aplicación del lado de la demanda de manera local. De este modo, no se necesita el permiso del usuario para enviar el IDFA fuera del dispositivo, lo que resuelve el problema de la autorización del lado de la demanda.

El hash de atribución tiene varias ventajas:

• Privacidad: no se envía ningún ID de usuario o dispositivo desde el dispositivo, y el IDFA se adquiere con autorización previa, de acuerdo con las nuevas regulaciones de Apple.
• Transparencia: esta solución es fácil de entender y comunicar para los responsables de la implementación técnica en todo el sector.
• Precisión: este método ofrece el mismo nivel de coincidencia que la coincidencia pura del IDFA. En algunos casos, incluso puede proporcionar un nivel mejor, tomando en cuenta que Apple descontinuó el LAT, y la lectura del IDFA siempre funcionará en la aplicación del anunciante.
• Seguridad: es imposible obtener el IDFA por la fuerza, incluso si se conoce la mitad de la entrada del hash.
• Simplicidad: esta solución solo requerirá cambios menores en los SDK de las MMP. Todas las MMP deberían ser capaces de adaptar su backend para este tipo de coincidencias sin tener que invertir grandes cantidades de recursos.

Existen otros escenarios posibles para la solución en el dispositivo:

• Un elemento equivalente a Google Referrer en Android: Incluso podría requerir la autorización del lado de la oferta en un modelo en que, solamente si el usuario acepta participar en el tracking del lado de la oferta, la aplicación del lado de la demanda recibe un callback delegado en el momento de la instalación, el cual se puede leer en nuestro SDK. La carga útil puede ser un ID de clic (por ejemplo, la etiqueta de referencia interna de Adjust), la información de la campaña o el ID de la aplicación de origen.
• Emparejamiento de ID en el propio dispositivo: En lugar de que los IDFA se envíen desde el SDK hacia los servidores de Adjust, los servidores envían todos los IDFA recibidos durante el engagement hacia el SDK, junto con el tracker de clics, que es un punto de datos agregado. El SDK empareja el IDFA y devuelve únicamente el tracker.
• Hash de atribución generado por Apple: Nuestro SDK ni siquiera leería el IDFA: únicamente recibiríamos el hash y la sal por parte de Apple.

La conclusión es que existen muchas soluciones posibles que se pueden investigar para la atribución en el dispositivo, y algunas de estas se podrían proporcionar como parte de las próximas mejoras implementadas en SKAdNetwork.

Estamos en comunicación constante con Apple, así como con diferentes desarrolladores de aplicaciones y socios de marketing, para encontrar una solución que pueda impulsar al sector sin poner en riesgo la privacidad de los usuarios.

Si quieres unirte a nosotros, o si deseas más información sobre las maneras en que puedes mostrar tu apoyo, envía un mensaje a ios14@adjust.com. ¡Nos da mucho gusto compartir información y conocer las opiniones de los diferentes miembros del sector!