Estrategias de pujas basadas en valor (value based bidding) en la era de iOS 17: retos y soluciones

En un ecosistema de marketing digital en constante evolución, mantenerse a la vanguardia es crucial para el éxito. Con los cambios de privacidad de Apple en iOS 17 sacudiendo la industria, comprender el impacto en las pujas basadas en valor y adoptar soluciones basadas en etiquetado del lado del servidor se ha vuelto imperativo para mantenerse competitivo.

En este artículo, explicaré las implicaciones de iOS 17 en el marketing digital, específicamente las estrategias de pujas basadas en valor que ya no son duraderas, y cómo nosotros en Jellyfish vemos el futuro de las pujas basadas en valor.

El cambio respecto a la privacidad en iOS 17

La actualización de privacidad de Apple con iOS 17 ha introducido una característica significativa llamada “Link Tracking Protection”. Esta actualización afecta directamente a los profesionales de marketing y a cualquier anunciante que utilice identificadores de clics, especialmente en el contexto de la protección del seguimiento a nivel de usuario dentro de la navegación privada de Safari, Mail y Mensajes. Safari tiene una cuota de mercado sustancial en el espacio de navegadores (actualmente casi un 26% de cuota de mercado, según SimilarWeb), convirtiendo este desarrollo en un momento crucial para los anunciantes. No es un ajuste menor; señala un potencial nuevo paradigma para medir los esfuerzos de marketing en la web.

Captura de pantalla del comunicado de prensa de Apple, agosto de 2023

Tracking bajo escrutinio

El tracking de enlaces en iMessages, iMail y la navegación privada en Safari en todos los dispositivos se verá afectado. Dada la popularidad global de Safari (segundo después del Chrome de Google), esto representa un cambio sustancial que se debe comprender a fondo. Entender estos cambios es vital para mantener la efectividad de las campañas de marketing tanto ahora como en el futuro.

Aunque Apple no ha anunciado oficialmente los parámetros que se eliminarán de las URL, han insinuado la eliminación de identificadores de clic mientras se salvan los identificadores de campaña. Esto sugiere que identificadores como los identificadores de clic de Google (GCLID/DCLID) o Meta (FBCLID) podrían quedar afectados, mientras que los parámetros UTM permanecerían sin afectar. Los identificadores de clic son fundamentales para rastrear a usuarios individuales desde el clic en el anuncio hasta las conversiones en el sitio web, mientras que los parámetros UTM operan a un nivel agregado.

Además, los identificadores a nivel de usuario juegan un papel vital en las capacidades de atribución de las principales plataformas. La eliminación de estos identificadores podría llevar a complicaciones en la presentación de informes de conversiones, estrategias de puja y optimización de campañas basadas en conversiones.

De particular importancia es el autor etiquetado de Google Ads, que forma una piedra angular de la infraestructura publicitaria de Google. Depende en gran medida del GCLID/DCLID como un identificador clave para atribuir clics a datos web y de aplicaciones. Además, es ampliamente reconocido como una mejor práctica, principalmente debido a los posibles problemas asociados con el etiquetado personalizado.

Se confirma que el parámetro GCLID/DCLID será eliminado (modo de navegación privada), lo que se espera que interrumpa el proceso de atribución de los anuncios.

Impacto en los anunciantes

El ajuste puede no ser tan disruptivo como parece para los anunciantes de aplicaciones, pero es probable que aumenten los requisitos operativos para los desarrolladores de aplicaciones y los propietarios de productos (product owners). Sin embargo, la incertidumbre sobre qué parámetros URL se eliminarán hace difícil evaluar el impacto para los anunciantes web. Como se mencionó anteriormente, la atribución es el mayor cambio, lo que podría dificultar la presentación de informes y optimización de conversiones en plataformas digitales.

El impacto en análisis sigue siendo incierto y depende de los detalles de las actualizaciones de Apple. Podríamos ver una mayor proporción de tráfico clasificado como 'directo', lo que llevaría a una disminución en la precisión para distinguir usuarios nuevos y recurrentes de iOS y Safari.

Fuera lo viejo, dentro lo nuevo.

Actualmente, el proceso de rentabilidad implica numerosos modelos de ingesta para las puertas de compra digital, como Google Ads o Search Ads 360 (SA360) de Google Marketing Platform. La mayoría de ellos están impactados por este nuevo cambio de privacidad de Apple, dejándonos con soluciones limitadas que sean 'duraderas' y 'a prueba de futuro'.

Exploraremos soluciones para la ingesta de beneficios (profit ingestion):

1. JavaScript en la página: fácil de implementar, mantiene intactas las capacidades de modelado, pero expone el beneficio. Basado en GCLID/DCLID, no compatible con Safari/iOS.
2. Importación de Conversiones Offline: más complejo de implementar, modelado incompatible, pero el beneficio está seguro. Basado en GCLID/DCLID, no compatible con Safari/iOS.
3. Customer Match: fácil de implementar; cargas por lotes directamente en Google, mantiene intacto el modelado. Limitado a la base de usuarios registrados en Google.
4. Protocolo de Transferencia de Archivos Seguro (sFTP): permite cargar en masa datos directamente a un punto final (endpoint) de Search Ads 360. Basado en GCLID/DCLID, no compatible con Safari/iOS.
5. Protocolo de medición GA4 v2: puedes enviar datos de beneficio/interacción de usuario offline a Google Analytics mediante solicitudes HTTP. No es en tiempo real y depende del procesamiento de GA4.
6. sGTM profit feed via Firestore, apodado Soteria: Un caballero en armadura brillante. Te contaré más.

Soteria: Pujas basadas en valor con sGTM.

Primero, ¿Qué es sGTM?

En este ecosistema en evolución, sGTM surge como una solución de medición y activación resistente y duradera. No depende de identificadores no duraderos ni de identificadores de clic, lo que lo convierte en una opción estable para mantener estrategias de puja y aprovechar modelos de IA/ML basados tanto en datos de primera parte enriquecidos como en datos modelados.

Medición y Activación Resistentes/Duraderas

sGTM establece las bases para el futuro de una medición escalable y mantiene intactas las estrategias de activación, ya que no depende de identificadores no duraderos ni de identificadores de clic, manteniendo tus estrategias de puja activas y prósperas.

Combinar sGTM con el Modo de Consentimiento y conversiones mejoradas potenciará tus modelos de IA/ML basados tanto en datos de primera parte enriquecidos como en datos modelados.

Utilizando sGTM con Firestore en Google Cloud Platform (GCP), Soteria conecta datos de rentabilidad delicados con transacciones de SA360 en tiempo real. Esta integración permite a los anunciantes enviar valores totales y de rentabilidad a nivel de producto y cesta, permitiendo que los feeds de beneficios se integren sin problemas con algoritmos de puja y modelos de IA dentro de un ecosistema cerrado y seguro para la privacidad.

¿Cómo funciona Soteria?

1. Se crea CloudRun dentro de GCP para alojar la infraestructura de sGTM.
2. Se configura un contenedor web de Google Tag Manager (GTM) del lado del cliente con un evento de compra para establecer el etiquetado en el sitio.
3. El sitio web del cliente se configura para tener un evento de compra de comercio electrónico en la capa de datos: esto contiene los datos de ingresos. Cuando se realiza una compra, el evento se dispara, enviando la carga a sGTM.
4. Se construye un contenedor de sGTM con una etiqueta de configuración de cliente GA4 para apoyar los requisitos de sGTM para la conversión en transacción.
5. Se adjunta una variable personalizada a una etiqueta, activada por eventos de 'compra', que extrae los datos de beneficio de Firestore y reemplaza el valor de conversión de ingresos por el beneficio.
6. Firestore alojará todos los datos de beneficio relevantes para el catálogo de artículos. Como Firestore se encuentra dentro de Google Cloud Platform (GCP), necesitaremos encontrar la tubería más eficiente/efectiva desde/hacia su fuente de beneficio para automatizar su flujo para una actualización diaria a Firestore. (ejemplo: ingesta diaria de Beneficio a un depósito de Cloud Storage/BigQuery Storage → automatizar archivo CSV a Firestore)
7. El evento actualizado (con valor de conversión de beneficio) se envía a Google Ads o SA360 a través del Floodlight dentro de sGTM a través del conector de Firestore.

¿Cómo es una buena implementación de sGTM deployment?

¿Por qué etiquetado server-side? 

Exactitud de Datos: al reducir la dependencia del seguimiento basado en navegador, sGTM minimiza las discrepancias de datos y asegura que tus inights se basen en información confiable.

Cumplimiento de Privacidad: sGTM se alinea perfectamente con las regulaciones de privacidad. Reduce significativamente la exposición de datos del usuario a scripts de terceros, fomentando una experiencia de usuario más transparente y respetuosa con la privacidad.

Mejora del Rendimiento: con el procesamiento del lado del servidor, los tiempos de carga de tu sitio web se mantienen óptimos, mejorando la satisfacción del usuario y reduciendo las tasas de rebote.

Preparación para el Futuro: a medida que el paisaje digital evoluciona, sGTM proporciona una base sólida para tus estrategias de medición, asegurando longevidad y adaptabilidad.

En conclusión

Los cambios de privacidad en iOS 17 están remodelando el ecosistema del marketing digital. Los anunciantes deben adaptarse a estos cambios comprendiendo sus implicaciones y explorando soluciones innovadoras como las estrategias del lado del servidor, como Soteria, para navegar con éxito en este terreno en evolución.