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

Google ha estado trabajando en su iniciativa Privacy Sandbox durante un tiempo, enfocándose principalmente en la web. Ayer Google también anunció sus planes de expandir el proyecto a la plataforma Android. Mientras el sandbox web intenta eliminar las cookies de terceros (principalmente por presión externa), el Android Privacy Sandbox proyecto’s objetivo sería deprecar 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.

Aquí hay un resumen de los informes a nivel de evento vs. 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 vistas a la API de atribución de Android, incluirá “claves de agregación” que representarán ciertos desgloses. Estas claves pueden ser de hasta 128 bits, lo que es súper útil (128 bits es una TONELADA). Por ejemplo, imagina que la red publicitaria “MobCool” siempre usa 16 bits para su ID de campaña y 16 bits para su ID creativo. Y digamos sin imaginación que ID de campaña es 1 y ID creativo es 2. Para crear el desglose, convierten el ID de campaña y el ID creativo a bits y los concatenan. Esto resultaría en 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 bits del anunciante/MMP se concatenan.  Así que para un usuario que vino de la Campaña 1, vio el Creativo 1 y usa Acer Liquid A1, la clave de desglose sería: 0000 0000 0000 0001 0000 0000 0000 0010 0000 0010 Y esto es solo 40 bits. Tenemos hasta 128 bits … imagina los desglose útiles posibles con esto! (Nota: no estamos seguros aún si hay un límite en cuántos desglose diferentes puedes tener. 128 bits es 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 hay una coincidencia exitosa entre un evento de conversión (“trigger”) y una vista/clic (“source”), el servicio en el dispositivo de Android almacenará esta información, junto con la clave de agregación concatenada. Luego enviará estos datos a nivel de usuario en forma cifrada a la plataforma tecnológica 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 completamente por separado para cada red… lo que parece indicar que si dos o más redes tuvieran clics y/o vistas (algo que ocurre en la vida real), ambas recibirán respuestas de atribución (a nivel de evento y reportes 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 clics y vistas, usarían el encabezado “Attribution-Reporting-Redirects” en la respuesta (ver función registerAttributionSource) que incluirá’s Singular endpoint.
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 haremos la detección, gestión y mitigación de fraudes?
   Por ahora, no está claro qué impide que las empresas afirmen que recibieron una respuesta de Google. No vimos ninguna mención de firmas criptográficas, como las que tenemos en SKAdNetwork. Además, ¿cómo evita esta API que partes malintencionadas registren clics e impresiones infinitas cuando quieran? (En otras palabras, spam de clics.) Observamos que la función registerAttributionSource espera un “InputEvent” para registrar clics, pero no estamos seguros de cómo verifica que se trate de un clic de anuncio y no de cualquier InputEvent. Además – para vistas, no se necesita tal evento.
2. ¿Por qué URLs en lugar de parámetros?
   ¿Por qué los métodos registerAttributionSource y triggerAttribution siempre exigen una URL en vez de los parámetros directamente? (Suponemos que es una protección, ya que la resolución de la URL se hará en otro proceso, pero no estamos seguros.)
3. ¿Cómo coordinará la industria las claves de agregación?En la sección anterior explicamos que las claves de agregación combinan valores de las redes publicitarias (que definen parte de la clave en vistas/clics) y de los anunciantes/MMP (que definen la otra parte en eventos de conversión). La API permite que el anunciante/MMP sobrescriba todos los desglose, y hay que tener cuidado de no sobrescribir accidentalmente algo que la red publicitaria necesita. Esto genera complejidad y quizá Google podría mejorar la API para que no requiera coordinación entre tantas 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 soportar la funcionalidad de deep linking diferido en apps móviles?
   El deep linking diferido se ha soportado tradicionalmente con procesamiento de atribución en el servidor, el marco de referencia de instalación actual de Google y algunos métodos en el dispositivo.  Sin embargo, todos pueden usarse para eludir los objetivos de privacidad del Privacy Sandbox. Queremos una solución de deep linking diferido integrada en las API que ayude a los anunciantes a ofrecer una experiencia de usuario fluida 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 deseas profundizar, te animamos a unirte a nuestro grupo profesional de Slack sobre privacidad de atribución móvil.