Análisis en profundidad: Atribución móvil a través de Android Privacy Sandbox y sin GAID

Google lleva un tiempo trabajando en su iniciativa Privacy Sandbox, centrada principalmente en la web. Ayer, Google también anunció sus planes de expandir el proyecto a la plataforma Android. Mientras que la zona protegida web intenta eliminar las cookies de terceros (principalmente por presión externa), el Privacy Sandbox para Android sería descontinuar el GAID .

Si lo hicieras, tendría un impacto en muchos sistemas de marketing móvil, desde la medición, la segmentación, la reorientación y más.

La buena noticia es que la propuesta de medición de Google, tal como está ahora mismo, parece bastante buena. De hecho, es más que buena. Es sorprendentemente reflexiva, flexible y demuestra que es posible eliminar el GAID sin causar estragos en el ecosistema de aplicaciones.

Quizás no sea muy sorprendente, dadas las profundas raíces y cimientos de Google en el ecosistema publicitario, su comprensión innata del espacio y su deseo de mantenerlo intacto. Probablemente también sean las numerosas heridas de guerra que han sufrido al intentar hacer cosas similares en la web, lo que les llevó a un primer borrador bastante bueno.

Google afirma que el plazo previsto para el proyecto es de más de dos años, y sospechamos que lo que vemos hoy seguirá cambiando durante ese período. Sin embargo, quiero aplaudir a Google por presentar estas ideas como propuestas con antelación y por solicitar comentarios. No tuvimos la oportunidad de hacerlo con SKAdNetwork, y me parece una lástima..

El Sandbox de privacidad de Android tiene algunos temas que abordan la segmentación y la reorientación, pero este artículo se centrará principalmente en la atribución… porque bueno… es algo que nos importa mucho aquí en Singular 🙂

Pero primero, una advertencia:

Esta publicación se basa en mi interpretación inicial de un documento publicado por Google. Si crees que me equivoqué en algún detalle, ¡dímelo!

TL;DR: Atribución con el Sandbox de privacidad de Android

La idea principal es que Google eventualmente descontinuará GAID, pero aún quiere que los anunciantes puedan gestionar la adquisición de usuarios de forma eficaz. Como la red publicitaria más grande del planeta, Google sabe que la medición es clave para ello.

Para ello, Google creará un servicio integrado en el sistema operativo Android, denominado "API de Informes de Atribución", que tendrá las siguientes funciones:

• Visualizaciones y clics de la tienda informados por las redes publicitarias (Google los llama "fuentes")
• Almacena eventos de conversión como instalaciones, compras y registros informados por Apps/Singular (Google los llama "desencadenantes")
• Coincidir con los eventos de conversión informados y las vistas o clics informados que están almacenados en el dispositivo
• Envíe los datos a redes/socios de medición/anunciantes en dos formatos:
  • Informes a nivel de evento: informes que contienen desgloses súper detallados del embudo superior (campaña, subcampaña, creatividad, hasta el propio click_id) combinados con datos súper limitados del embudo inferior (valor de conversión de 1 a 3 bits)
  • Informes agregables: un informe más equilibrado que contiene datos seleccionados de desgloses del embudo superior (GEO, campaña, etc.) con datos más detallados del embudo inferior (ingresos, número de compras, etc.)

Los informes a nivel de evento se parecen un poco a los de SKAdNetwork. ¿Son similares?

A primera vista, parece mucho mejor que SKAdNetwok.

Los "informes a nivel de evento" brindarán un desglose súper granular de los datos del embudo superior (piense en la campaña, la subcampaña, la creatividad, hasta el click_id en sí), junto con valores de conversión bastante limitados (valores de conversión de 3 bits, frente a los 6 bits de SKAN).

Sin embargo, parece que será posible enviar hasta tres eventos de conversión en momentos distintos, cada uno atribuido a la vista o al clic. Por lo tanto, probablemente el primer evento de conversión se usará para la instalación, mientras que los dos siguientes se destinarán a KPIs significativos que pueden ocurrir más adelante en el ciclo de vida del usuario. Esto es fundamental... y era una de las principales características que buscábamos en SKAdNetwork.

A continuación se muestra un resumen de los informes a nivel de evento frente a SKAN :

¿Qué tipos de informes podemos crear con informes a nivel de evento?

Para que sea más sencillo de entender, aquí hay un ejemplo de cómo podría verse un conjunto de postbacks a nivel de evento:

El "ID del evento de origen" lo define la red y, en esencia, es el ID de clic/vista definido por ella. Esto significa que tiene una correspondencia directa con todos los datos que interesan a los profesionales del marketing, como el nombre de la campaña, el nombre de la creatividad, el país, el sistema operativo, la audiencia, etc.

El tipo de activador lo define el anunciante/MMP y es muy similar a los valores de conversión de SKAN. Tiene menos bits que SKAN, pero permite enviar hasta tres activadores en momentos diferentes, ¡así que buenas noticias para los informes de cohorte!

A continuación se muestra un ejemplo muy simple de cómo un anunciante/MMP puede definir el "tipo de activador":

• 001 = instalar
• 010 = nivel completado
• 101 = ingresos de 7 días > $10

Juntando todo esto, el resultado en un tablero Singular podría verse así:

Entonces, si bien el "tipo de activador" (valor de conversión) es más limitado que el de SKAN, se obtiene una granularidad increíble en los datos del embudo superior y se obtiene la posibilidad de enviar múltiples eventos de conversión... y eso por sí solo ya proporciona un informe más poderoso que el que estamos obteniendo actualmente de SKAdNetwork.

¿Y sabéis qué? Hay más. 

Consulte la siguiente sección sobre “Informes agregables”

¿Qué tipo de informes podemos crear con los datos “agregables”?

Esta área es particularmente interesante y tiene una implementación bastante inteligente según lo propuesto por Google, pero también hay algunos detalles vagos en este punto.

El concepto general es el siguiente:

1. Cuando una red publicitaria informa clics y visualizaciones a la API de Atribución de Android, incluye "claves de agregación" que representan ciertos desgloses. Estas claves pueden tener hasta 128 bits, lo cual es muy útil (128 bits es muchísimo). Por ejemplo, imaginemos que la red publicitaria "MobCool" siempre usa 16 bits para su ID de campaña y 16 bits para su ID de creatividad. Supongamos, sin pensarlo dos veces, que su ID de campaña es 1 y su ID de creatividad es 2. Para crear el desglose, convierten el ID de campaña y el ID de creatividad a bits y los concatenan. Esto daría como resultado una cadena de 32 bits:
   0000 0000 0000 0001 0000 0000 0000 0010
2. Más adelante, al instalar la aplicación, el anunciante/MMP reportará los eventos de conversión de la aplicación a la API de Atribución de Android. Estos eventos también pueden añadir sus propios desgloses a la clave de agregación. Por ejemplo, si el anunciante desea desglosar aún más sus informes de marketing por modelo de dispositivo, podría crear una clave de 10 bits (elegí 10 arbitrariamente; pueden usar 20 bits si lo desean), que se vería así:
3. Los bits de la red publicitaria y los del anunciante/MMP se anexarían.  Por lo tanto, para un usuario que proviene de la Campaña 1, vio la Creatividad 1 y usa Acer Liquid A1, la clave de desglose sería: 0000 0000 0000 0001 0000 0000 0000 0010 0000 0010. Y esto son solo 40 bits. Tenemos hasta 128 bits... ¡así que imagina la cantidad de desgloses útiles que se pueden lograr con esto! (Nota: aún no sabemos si hay un límite en la cantidad de desgloses diferentes que se pueden tener. 128 bits es una cantidad muy grande).
4. Al informar el evento de conversión, el anunciante/MMP también debe informar un valor numérico para dicho evento. Este puede ser un simple contador para elementos como instalaciones (p. ej., 1) o cualquier número para elementos como ingresos (p. ej., 100 $). Este valor es el que se suma al realizar la agregación (más información más adelante). (Nota: Existen límites en los valores que se pueden pasar aquí. Esto forma parte del mecanismo de privacidad diferencial que emplea Google).
5. Cada vez que se produce una coincidencia exitosa entre un evento de conversión ("desencadenante") y una vista/clic ("origen"), el servicio de Android en el dispositivo almacenará esta información, junto con la clave de agregación concatenada. Posteriormente, enviará estos datos a nivel de usuario de forma cifrada a la plataforma de tecnología publicitaria del cliente ( MMP , red publicitaria ).
6. Ahora, las plataformas de tecnología publicitaria del cliente (MMP, red publicitaria, etc.) tienen muchos registros de datos de usuario encriptados y agregables. Para agregarlos, Google ideó una idea genial: un servidor de red independiente, llamado "Servicio de Agregación", descifrará y agregará simultáneamente los datos de usuario, basándose en estas claves de agregación predefinidas. El resultado final del ejemplo anterior podría ser similar a esto:
7. Y esto es obviamente simplista. Una implementación adecuada añadiría mucha más dimensionalidad, y en Singular esta tabla también se conectaría con diversas fuentes de datos para obtener un ROI real. Google permite que la clave de agregación tenga una longitud de hasta 128 bits, lo que significa que hay mucho margen para añadir desgloses significativos, y los informes resultantes podrían ser muy buenos.

Además, en el servicio de agregación: 

Este "Servicio de Agregación" es un programa desarrollado y firmado por Google, pero se ejecutará en servidores de otras empresas en un "Entorno de Ejecución de Confianza". Esto significa que si Singular ejecuta un "Servicio de Agregación", no podemos manipular su funcionamiento y funcionará según lo previsto por Google.

¿Cómo funcionará la lógica de cascada de atribución?

Creemos entender lo que está sucediendo, pero como mencionamos al principio de este artículo, la documentación para desarrolladores actual presenta mucha complejidad y algunas direcciones poco claras. Probablemente esto se aclarará a medida que avance el proyecto, pero no todo está completamente definido ni explicado.

Esto es lo que creemos que está sucediendo:

1. Cada red publicitaria puede informar sobre las visualizaciones y/o clics (lo que Google denomina “fuentes”) de sus anuncios.
2. Las redes también pueden asignar prioridades para cada uno de sus puntos de contacto (por ejemplo, la mayoría de las redes probablemente estarán de acuerdo en que los clics deben tener una mayor prioridad que las impresiones).
3. Cuando la aplicación instalada informa un evento de conversión (lo que Google llama un "desencadenante"), Android intentará hacer coincidir ese evento de conversión con todas las vistas y clics relevantes, y elegirá el que tenga la mayor prioridad.
4. Aparentemente, esta lógica se realiza de forma completamente separada para cada red… lo que parece implicar que si dos o más redes tuvieron clics y/o vistas (algo que sucede en la vida real), ambas recibirán postbacks de atribución (informes a nivel de evento y agregados).

Claramente, el punto n.° 4 plantea la cuestión de la deduplicación en las redes publicitarias. No podemos permitir que todas las redes ganen (y reciban pagos), ya que esto distorsionaría considerablemente la visión del profesional de marketing al contabilizar dos veces.

La documentación aborda específicamente los casos de uso de medición de terceros al habilitar redirecciones en los eventos de visualización/clic. Así es como creemos que empresas como Singular podrían lograr la deduplicación en todas las redes para sus clientes:

1. Cuando las redes publicitarias informan sobre clics y visualizaciones, utilizarán el encabezado “Attribution-Reporting-Redirects” en la respuesta (consulte la función registerAttributionSource ) que incluirá el Singular .
2. Luego, la API se comunicará con los servidores de Singulary registraremos exactamente las mismas vistas y clics en función de la cascada y la elección de priorización de nuestro cliente (por ejemplo, los clics son más importantes que las vistas, la ventana de atribución debe ser X, etc.).
3. Una vez que nuestro SDK informa un evento de conversión en la aplicación del anunciante, la API de Android lo comparará con todas las vistas y clics que informamos y elegirá el punto de contacto relevante según la priorización que proporcionamos, logrando así la eliminación de duplicados en las redes publicitarias.

Si este flujo se implementa de la manera que propusimos, también tendría el beneficio adicional de proporcionar algunos informes de MTA

Preguntas abiertas: mucho más por aprender

Aún queda mucho por analizar, y muchas cosas requerirán aclaraciones de Google o del ecosistema a medida que avancemos. Aquí tengo algunas preguntas abiertas:

1. ¿Cómo detectaremos, gestionaremos y mitigaremos el fraude?
   Por ahora, no está claro qué impide que las empresas afirmen haber recibido una respuesta de Google. No observamos ninguna mención de firmas criptográficas, como sí ocurre en SKAdNetwork. Además, ¿cómo evita esta API que terceros maliciosos registren clics e impresiones sin fin cuando quieran? (En otras palabras, spam de clics). Observamos que la función registerAttributionSource espera un "InputEvent" para registrar los clics, pero no estamos seguros de cómo verifica que se trate de un clic en un anuncio y no de cualquier InputEvent. Además, para las visualizaciones, no se necesita un evento.
2. ¿Por qué URLs en lugar de parámetros?
   ¿Por qué los métodos registerAttributionSource y triggerAttribution siempre requieren recibir una URL en lugar de los parámetros directamente? (Suponemos que se trata de una protección, ya que la resolución de la URL se realizará en otro proceso, pero no podemos estar seguros).
3. ¿Cómo se coordinará la industria con las claves de agregación? En la sección anterior, explicamos cómo las claves de agregación son una combinación de valores de las redes publicitarias (que definen parte de la clave en visualizaciones/clics) y de los anunciantes/MMP (que definen la otra parte de la clave en eventos de conversión). La API permite al anunciante/MMP sobrescribir todos los desgloses, y se debe tener cuidado para no sobrescribir accidentalmente algo que la red publicitaria necesitaba. Esto genera cierta complejidad, y quizás Google podría mejorar la API para que no requiera la coordinación entre un gran número de empresas. (¿64 bits para redes, 64 bits para anunciantes/MMP? :))
4. ¿Cómo utilizará Google Ads esta funcionalidad?
   Apple tiene un proceso diferente para Apple Search Ads que el de otras redes publicitarias. ¿Seguirá Google Ads este nuevo entorno de pruebas de privacidad para Android como cualquier otra red publicitaria? Los primeros indicios apuntan a que sí, pero aún quedan algunas preguntas.
5. Cómo se puede implementar la funcionalidad de enlaces profundos diferidos en aplicaciones móviles?
   Tradicionalmente, estos enlaces profundos diferidos se han implementado mediante el procesamiento de atribución del lado del servidor, el marco de referencia de instalaciones actual de Google e incluso algunos métodos en el dispositivo.  Sin embargo, todos estos métodos podrían utilizarse para eludir los objetivos de privacidad del Privacy Sandbox. Nos gustaría ver una solución de enlaces profundos diferidos integrada en las API para ayudar a los anunciantes a ofrecer una experiencia de usuario optimizada a sus nuevos usuarios.

Resumiendo

Es muy pronto. Google acaba de anunciar esta iniciativa y, sin duda, habrá mucha iteración. Nos entusiasma que Google esté buscando comentarios y nos entusiasma colaborar con ellos en esta iniciativa. Los primeros documentos muestran un enfoque mucho más eficaz que puede ofrecer informes mucho mejores que SKAdNetwork, lo cual es muy alentador. Quién sabe, quizás Apple incluso pueda incluir algunas cosas en SKAN..

Una cosa es segura: puede contar con nosotros para seguir cubriendo este tema y trabajando en ello con Google y nuestros clientes.

Si desea analizar esto más a fondo, le recomendamos encarecidamente que se una a nuestro grupo profesional de Slack sobre todos los temas relacionados con la privacidad de la atribución móvil .