¡Gracias!

Se acerca Privacy Sandbox: ¿Qué deberían hacer los marketers?

Roy Yanai
Android Privacy Sandbox is coming. What should marketers do next_ OG

En febrero de 2022, Google anunció sus planes para mejorar la privacidad del usuario en Android, lo que le llamó la atención a los marketers. Tras las conmociones en torno a la App Tracking Transparency (ATT) de Apple, las preguntas sobre qué planea hacer exactamente Android y cómo afecta a las empresas que estuvieron, y siguen estando, en la vanguardia de la mente de todos. 

El entusiasmo es grande, a pesar de que la eliminación del Google Advertising ID (GAID) no se producirá hasta 2024. Y por una buena razón, ya que cambia la vida tal como la conocemos para los marketers de todo el mundo.

Para ayudarte a prepararte para Privacy Sandbox, describimos algunos de los principales cambios que introduce esta iniciativa y cuál será la base de la nueva normalidad. La información que se describe aquí se basa en una estrecha colaboración con el equipo de Google, una revisión exhaustiva de la documentación y pruebas prácticas de la solución. Entremos en detalles.

Aquí está GAID: El fin de la información a nivel de usuario en Android

Como base para Privacy Sandbox, exploremos las formas en que se utiliza principalmente GAID en la actualidad: 

  1. Atribución: GAID ayuda a los marketers a medir la eficacia de sus campañas y comprender el viaje del usuario.
  2. Gestión de audiencias: GAID ayuda a los marketers a personalizar sus campañas de remarketing. 
  3. Intercambio de datos con terceros:  GAID ayuda a las redes publicitarias a crear gráficos de personas para ayudarlos a asignar los mejores anuncios para cada persona.

Ahora que entendemos cómo se ha utilizado GAID, determinemos quién es que más lo aprovecha, para que podamos identificar qué debe cambiar cuando GAID sea eliminado y cómo.

ObjetivoAcciones requeridas por
MediciónMMPs, Marketers
RemarketingMarketers, redes publicitarias, MMPs
TargetingRedes publicitarias

Al revisar el uso de GAID, podemos ver en la tabla anterior que los marketers se verán afectados principalmente por su desuso en sus esfuerzos actuales de medición y remarketing. Centrémonos en esas áreas para determinar cómo prepararnos.

Medición 

Cuando se trata de mediciones y análisis, no hay por qué entrar en pánico. La obsolescencia de GAID no indica el fin de la medición del marketing. 

Hasta el momento, Android no ha anunciado ningún plan para eliminar Google Play Install Referrer, que es uno de los principales métodos de atribución en Android, y esto dice mucho cuando se trata de la continuación del negocio. Actualmente, el 29% de las atribuciones de instalación de AppsFlyer en Android se realizan a través del referente de Google Play. 

Para ayudarte a prepararte para Privacy Sandbox, te sugerimos que analices cómo se ven tus datos actuales. En los reportes de raw data de AppsFlyer, puedes ver que uno de los campos se llama <match_type>. En <match_type>, puedes identificar cuántas de tus instalaciones actuales utilizan la atribución de Google Play Referrer. Esta simple consulta de datos puede ayudar a aliviar cualquier preocupación sobre cambios significativos en la medición de la atribución. 

A pesar de la importancia del Google Play Install Referrer, no se puede negar que GAID es actualmente la base y el pilar de una gran parte de las actividades de medición. 

Para ayudar a los marketers a continuar con sus esfuerzos de atribución sin GAID, Privacy Sandbox presenta nuevos métodos para medir campañas con el lanzamiento de la API de atribución. Esta API ofrece dos tipos de reportes: a nivel de evento y agregados. Cada reporte presenta diferentes ventajas e insights de la siguiente manera:

Reportes a nivel de evento

Si bien los reportes a nivel de evento ofrecen una medición limitada de los eventos de instalación y posteriores a la instalación, se encuentran en el nivel de ID de clic, lo que permite a las redes publicitarias obtener señales precisas para el anuncio mostrado. Sin embargo, para proteger la privacidad del usuario final, los reportes se retrasan un mínimo de un día para view-through y dos días para click-through y se atribuyen un máximo de tres postbacks por fuente. Si bien, en la superficie, es posible que algunos quieran comparar los postbacks que ofrece Sandbox con las que proporciona SKAN, una comprensión profunda de Sandbox demuestra que estos postbacks son diferentes tanto en naturaleza como en uso. Tal como está actualmente esta solución, los reportes a nivel de eventos son más impactantes para que las redes publicitarias los utilicen para la optimización y son menos reveladores para los marketers.

Reportes agregados

Los reportes agregados ofrecen insights más completos a los marketers, ya que pueden incluir dimensiones detalladas de la campaña, como el nombre de la campaña, la fecha, el conjunto de anuncios, la ubicación geográfica y las creatividades. Los detalles de las dimensiones de la campaña incluidas en los reportes agregados dependen de la red, el MMP y el anunciante para definirlos. Los postbacks de datos que componen los reportes agregados se envían el mismo día. Los reportes agregados proporcionan LTV de instalación y posterior a la instalación, brindando a los especialistas en marketing insights útiles para aprender sobre la campaña. 

Tanto el reporte agregado como el de nivel de evento ofrecen atribución entre redes, y la determinación de la atribución del último clic entre redes se comparte únicamente con el MMP.
Los especialistas en marketing pueden configurar ventanas retrospectivas de hasta 30 días, pero ten en cuenta que deben configurarse para cada red publicitaria, una tarea increíblemente ardua cuando la realizan los propios marketers. La configuración de ventanas retrospectivas se simplifica cuando se utiliza un MMP, ya que se integrarán y coordinarán directamente con las redes publicitarias, asumiendo el trabajo pesado. 

Si bien todo esto suena genial, hay algunas desventajas: ahora será más complejo que nunca para los marketers deduplicar sus datos. Esto se debe a que la API de atribución es agregada y no proporciona datos a nivel de usuario del lado del anunciante, lo que hace imposible fusionar estos datos con los análisis recibidos de Google Play Install Referrer.  

Para superar este desafío, AppsFlyer incorpora un mecanismo de Single Source of Truth, que deduplica los datos de atribución y los mejora con insights valiosos.

Remarketing

Hoy en día, el remarketing se basa en gran medida en el uso de GAID, ya que los especialistas en marketing pueden definir audiencias según las preferencias del usuario, los intereses y el uso de la aplicación para generar una lista de GAID para activar una campaña de remarketing. A la luz de la próxima obsolescencia de GAID, Google presentó FLEDGE, una solución de publicidad y gestión de audiencias centrada en la privacidad en el dispositivo (no enviada a ningún servidor).

Para marketers

Para ellos, los cambios que introduce FLEDGE pueden sentirse en distintos niveles. Por ejemplo, los clientes de AppsFlyer que utilizan la herramienta Audiences no sentirán un cambio significativo; La creación de audiencia dentro de AppsFlyer admite los cambios de FLEDGE y permitirá que diferentes redes publicitarias personalicen los anuncios según las configuraciones que establezca cada marketer.

Sin embargo, si estás acostumbrado a crear audiencias dentro de tu propio BI, es posible que tengas que hacer mucho trabajo. Ya no será posible crear listas de usuarios y enviarlas a diferentes partners. 

Entonces, ¿cómo puedes adaptarte? Hay algunas opciones:

  1. Administrar FLEDGE. con FLEDGE, aún podrás crear audiencias y ‘etiquetarlas’ como disponibles para ser dirigidas por una red publicitaria específica; sin embargo, tendrás que comunicar esta integración a los diferentes partners. Por ejemplo, si deseas crear una audiencia de “add-to-cart-did-not-purchase” y asignarla a un DSP, potencialmente puedes hacerlo, pero requerirá una integración con ese DSP (para aprobar y obtener datos de ellos).
  2. Trabajar con un MMP. AppsFlyer ya está creando integraciones para habilitar FLEDGE a través de diferentes partners, lo que respaldará la gestión de audiencias en la era posterior a GAID y facilitará el remarketing personalizado.

Para redes publicitarias

Además de los cambios que sienten los especialistas en marketing, FLEDGE introduce muchos cambios en las redes publicitarias en dos aspectos principales:

  1. Definición de audiencias: En la estructura actual de FLEDGE, se requiere un SDK, que tiene la capacidad de comunicarse con FLEDGE, en la aplicación del anunciante para agregar o eliminar un usuario de una audiencia. Las redes publicitarias, con la ayuda de MMPs, necesitarán crear integraciones que permitan funcionalidades de creación de audiencia. 
  1. Ofertar por un usuario que pertenece a una audiencia: Además de generar audiencias, una parte importante de FLEDGE en realidad está ayudando a las redes publicitarias con una solución de ofertas centrada en la privacidad. FLEDGE ofrece un intercambio de ofertas en el dispositivo entre el SSP y el DSP. Se requerirá que las redes publicitarias adapten sus estrategias y soluciones de oferta para garantizar que los anuncios correctos se muestren a los usuarios correctos de la manera más rentable. 

Más allá de la solución actual de AppsFlyer y en línea con nuestra visión de alto nivel de promover insights centrados en la privacidad, apoyamos el ecosistema facilitando la creación de audiencia en el lado de la red publicitaria. Como se señaló, FLEDGE es una solución en el dispositivo; cualquier creación de audiencia requiere una presencia en el dispositivo (SDK). AppsFlyer facilitará la creación de audiencia por parte de cualquier red publicitaria a través de integraciones dedicadas.

Targeting

Uno de los principales insumos para las capacidades de orientación de las redes publicitarias son los datos de third-party. Es decir, cuando app.game.com envía datos de uso del usuario123 a una red publicitaria, que luego se pueden usar para dirigirse al usuario123 con anuncios en una aplicación de juegos diferente. 

La noción de segmentación entre aplicaciones basada en datos a nivel de usuario es una parte importante de lo que Google está tratando de evitar; es probable que veamos un impacto importante en la capacidad de segmentación de las redes publicitarias en la era post-GAID. La buena noticia es que existen soluciones que podrían ayudar a las redes publicitarias a garantizar la entrega de anuncios contextuales, incluidas

  1. Temas: Como una de las soluciones sugeridas por Google, los temas ayudan con el marketing entre aplicaciones. Esta es una solución en el dispositivo y está diseñada para proteger la privacidad del usuario al tiempo que permite señales de orientación entre aplicaciones. Las diferentes redes publicitarias tendrán que adoptar temas y optimizarlos en función de ellos.
  2. Señales de API de atribución: Como se señaló anteriormente, una de las características clave que ofrece esta API es la generación de reportes a nivel de evento, que ofrece una cantidad limitada de postbacks de datos basadas en datos a nivel de usuario. Por ejemplo: una red publicitaria tendrá la capacidad de saber que click-id123 realizó una compra en la aplicación anunciada, pero estos reportes se retrasarán para proteger la privacidad del usuario final.

Este invierno se acerca Sandbox, pero eso no significa que las heladas vayan a atacar

Si bien el cambio da miedo (y Privacy Sandbox trae mucho de eso), los cambios que Android está introduciendo están moviendo el ecosistema en la dirección correcta: lejos de la adicción a los datos a nivel de usuario y hacia enfoques que promueven la privacidad. 

Para comenzar a prepararse para la eliminación de GAID hoy, alentamos a los marketers a reducir su dependencia de los datos a nivel de usuario y comenzar a adoptar y utilizar insights agregados. 

Finalmente, prepárate para un invierno acogedor y continúa aprendiendo más sobre este framework en evolución; Google proporciona una amplia documentación y, como siempre, AppsFlyer está aquí para responder cualquier pregunta y ayudarte a navegar por cualquier cambio nuevo, antes de que surja.

Roy Yanai

Roy Yanai es Jefe de Producto en AppsFlyer. En los últimos 4 años, Roy dirigió diferentes áreas de producto dentro de AppsFlyer, incluyendo el intercambio de datos y el análisis. Actualmente, Roy lidera los esfuerzos de producto del grupo de trabajo SKAdNetwork de AppsFlyer. Antes de trabajar en AppsFlyer, Roy fue CEO y Jefe de Producto en Mego, una empresa emergente destinada a resolver los problemas de entrega del eCommerce, y fundó HackIDC, el mayor Hackathon de Israel.
Background
¿Listo para empezar a tomar buenas
decisiones?