El SDK Runtime de Android en Privacy Sandbox es un cambio radical

El entorno de ejecución del SDK propuesto por Google para Privacy Sandbox en Android es revolucionario y representa una gran oportunidad para reducir el fraude publicitario y mejorar la privacidad de los usuarios. Además, no me sorprendería que Apple lo copiara en iOS, pero lo lanzara antes del plazo mínimo de dos años establecido por Privacy Sandbox.

Esta es la primera parte de una serie más larga de análisis profundos de Privacy Sandbox para Android, donde analizaré la nueva tecnología de Google para la privacidad y el marketing:

• Tiempo de ejecución del SDK (esta publicación)
• API de temas (cómo Privacy Sandbox gestionará la segmentación de anuncios)
• FLEDGE en Android (cómo Privacy Sandbox realizará la reorientación de anuncios)
• Informes de atribución (cómo propone Google que funcione la medición de anuncios)

Ver también Atribución móvil a través de Android Privacy Sandbox y sin GAID, Singular CEO Gadi Eliashiv’s inmersión profunda en la atribución móvil después de GAID.

Y por último, regístrate para la transmisión en vivo de LinkedIn que Gadi y yo realizaremos el jueves.

SDK y aplicaciones: la promesa y el peligro

Al principio, estaba la aplicación. Un desarrollador dijo: «Necesito más funcionalidades y aplicaciones, pero no tengo la receta ni la capacidad para hacer todo yo solo». Los proveedores de soluciones llenaron ese vacío con deliciosas ventajas precodificadas que los desarrolladores de aplicaciones podían crear fácilmente en código sin mucho esfuerzo.

¿Maravilloso?

Seguro.

Pero SDKs con código de huellas extensivo fueron la causa de Apple rechazando actualizaciones de apps en los primeros días de iOS 14.5. Son ’ una forma en que algunas apps han sido eliminadas del App Store. Y los SDKs de redes publicitarias fraudulentas han sido acusados de impulsar fraude de atribución en miles de millones de dispositivos y orquestar exfiltración de datos que amenaza la privacidad … incluyendo espionaje de comunicaciones en apps.

El ecosistema de aplicaciones moderno no podría funcionar sin los SDK. Son fundamentales para el software del que dependen todos los usuarios de teléfonos inteligentes o tabletas.

Pero también son un arma de doble filo.

Google cree que tiene una solución.

Ve a tu habitación ahora mismo (los SDK están siendo castigados)

Porque algunos SDKs han sido muy malos — y puedes apostar que tenemos menos información sobre simplemente cómo peor que Google mismo — Google los está limitando.

O confinarlos a un arenero.

Un “entorno de ejecución”, por así decirlo.

Dentro de este entorno de ejecución, los SDK tendrán permisos específicos y los ejecutarán fuera del proceso principal de la aplicación. En otras palabras, los SDK tendrán una visión mucho menos implícita de lo que hacen las aplicaciones y los desarrolladores tendrán control explícito total, o al menos mayor, sobre lo que un SDK ve y hace.

En Privacy Sandbox para Android, los procesos están aislados. 

Los SDK viven en un mundo aparte. Los SDK de tecnología publicitaria ya no pueden ver ni rastrear el uso de las aplicaciones mediante identificadores persistentes sin el conocimiento ni el consentimiento del desarrollador, y también tendrán muchas más dificultades para recopilar identificadores perecederos, o factores que puedan resumirse en un identificador temporal.

Además, Google está dificultando que los SDK manipulen la funcionalidad de otros SDK.

Al mismo tiempo, sin embargo, Google está dejando espacio para que los SDK detecten y prevengan el fraude publicitario y el tráfico no válido, cuando los desarrolladores lo permitan.

Google es tu mensajero ahora, SDK

En el modelo antiguo (actual), las aplicaciones y los SDK se comunican sin trabas. Al fin y al cabo, conviven en el mismo espacio y pueden comunicarse cuando y como quieran.

En el nuevo mundo, que Google ofrecerá en versión beta a finales de 2022, Google creará una “capa de ordenación” a la que los desarrolladores llamarán desde dentro de una aplicación.

1. La aplicación necesita el SDK para hacer algo.
2. El código de la aplicación llama a la capa de serialización y entrega un paquete
3. La capa de serialización envía la solicitud al SDK (probablemente verificando primero su legitimidad)
4. El SDK envía una respuesta al servicio de serialización
5. La capa de ordenamiento completa el ciclo con los datos o la funcionalidad necesarios para la aplicación

Un punto importante: esto podría ser asíncrono. Según la definición actual de Google, el SDK satisface las solicitudes de forma asíncrona y responde mediante las devoluciones de llamada. Esto podría interferir con la funcionalidad que requiere respuesta instantánea, lo cual resulta un poco confuso: prácticamente todo en una aplicación requiere respuesta instantánea, ya que la aplicación debe presentar opciones a los usuarios y luego proporcionar respuestas basadas en sus decisiones e indicaciones.

Sin embargo, todo esto es pre-beta por el momento, por lo que no hay necesidad de preocuparse demasiado por eso todavía.

También: Google está incorporando funcionalidad para la comunicación SDK‑a‑SDK en escenarios como mediación y pujas. Eso’s una parte enorme del ecosistema adtech móvil con redes SDK que ofrecen servicios de mediación como el nuevos titanes del adtech: ironSource, Liftoff+Vungle, AppLovin, Digital Turbine, y Unity.  Habrá la capacidad, dice Google, de que los SDK ofrezcan impresiones publicitarias o ejecuten subastas al comunicarse con otros SDK, ya sea dentro o fuera del entorno de ejecución del SDK.

Sin embargo, hay preguntas abiertas aquí: observe el lenguaje Google usa como “should” y “investigation.”

El SDK coordinador, con o sin RE [habilitado para tiempo de ejecución], debería poder acceder a todos los SDK, tanto de RE como de otros, para su funcionamiento normal. El renderizado en este contexto es un área de investigación activa

Creadores de SDK: prepárense para enviar

En cierto sentido, los desarrolladores de SDK han tenido vía libre. Mientras que las aplicaciones deben pasar por un proceso de aprobación en la App Store de iOS o Google Play, los SDK simplemente se han adaptado a los esfuerzos de sus clientes o desarrolladores.

Probablemente ya no.

Dado el singular entorno de ejecución aislado en el que ahora existirán los SDK, Google propone que los desarrolladores de SDK los envíen a Google Play y que luego estén disponibles para su uso en las aplicaciones a través de Google Play. Google afirma que esto garantizará la calidad y la consistencia, agilizará la publicación y hará que las actualizaciones menores de los SDK (que no requieren cambios en el código de la aplicación para funcionar) sean más rápidas y sencillas.

Sin embargo, las ideas de Google aquí son bastante nebulosas y en este momento no está diciendo explícitamente que este sea el futuro de la distribución para todos los SDK.

Sin embargo, los desarrolladores de software pueden leer las hojas de té tan bien como cualquier otra persona, y una vez que este mecanismo esté implementado y disponible, no es difícil imaginar que se convertirá en el método preferido (y con el tiempo probablemente el obligatorio) de distribución de SDK.

Mucho más que investigar

Como mencioné arriba, hay mucho más por explorar aquí. Suscríbete a las actualizaciones de nuestro boletín del blog para ser notificado cuando publiquemos más.

También, estoy haciendo una transmisión en vivo con Singular CEO Gadi Eliashiv sobre este tema el jueves 24 de febrero. Suscríbete aquí.