The Loss Of A Full Bit Single Source Ios...

¿Realmente vale la pena perder un bit completo? La verdad sobre la atribución de una sola fuente en iOS 14.5 y las versiones posteriores

La medición en iOS 14.5 y las versiones posteriores se ha hecho más compleja para los mercadólogos y los anunciantes. Para ayudar a enfrentar esta complejidad, los socios de medición móvil (MMP) y las plataformas de analytics han estado trabajando en diferentes herramientas desde que se anunció este sistema operativo en abril de 2020. En Adjust, reconocemos la importancia de estos cambios y estamos creando la nueva generación de herramientas para ayudar a los clientes a proteger la privacidad de los datos al mismo tiempo que impulsan el crecimiento. 

Nuestro enfoque gira en torno a aprovechar los datos de SKAdNetwork (SKAN) y a nivel de dispositivo lado a lado para crear informes completos en un formato tabular altamente preciso. Algunas otras herramientas disponibles en el mercado utilizan un enfoque "todo en uno" o "de una sola fuente", con lo que, básicamente, intentan calcular la superposición entre las instalaciones atribuidas por medio del entorno de trabajo SKAN y las instalaciones atribuidas por medio del entorno de trabajo App Tracking Transparency (ATT). Aunque esto suena bien en teoría, tiene algunas deficiencias importantes. Además, lo que es más importante, debes sacrificar un bit completo para obtener esta información. 

El problema con los datos de las campañas "todo en uno" de iOS

En teoría, al calcular la superposición entre las instalaciones de SKAN y las instalaciones de ATT se puede ver cuáles instalaciones de SKAN ya fueron atribuidas por ATT. Esto significaría que los mercadólogos podrían confirmar, a nivel agregado, que Instalaciones totales de SKAN = Instalaciones pagadas totales del MMP. Una de las maneras en que se podría utilizar este sistema es para confirmar las diferencias inesperadas entre los dos conjuntos de datos. Sin embargo, este proceso de resolución de problemas no incluye ningún otro paso. Por lo tanto, se desperdicia un bit muy importante, solo para demostrar cifras que no coinciden.

Veamos un par de ejemplos para ilustrar este punto

  1. En primer lugar, tenemos el ejemplo que llamamos Esperanza falsa:

    Plazo: julio de 2022

    Instalaciones pagadas del MMP: 80 000

    Instalaciones orgánicas del MMP: 40 000

    Instalaciones de SKAN: 100 000, donde, al utilizar el bit atribuido, 80 000 de ellas se devolvieron con un valor de 1, lo que significa que se atribuyeron

    En este escenario, un gerente de UA podría creer erróneamente que todas sus instalaciones de SKAN se atribuyeron, que su MMP muestra el mismo número de instalaciones pagadas y que los informes incluyen la cifra correcta. Esta conclusión es falsa. Aunque parece que los números coinciden a nivel general, debemos ir un paso más allá. De las 80 000 instalaciones atribuidas por SKAN, digamos que 40 000 se atribuyeron a Facebook y las otras 40 000 se atribuyeron a Google con muy poca información sobre la campaña. Por su parte, el MMP muestra 20 000 instalaciones atribuidas a Facebook, 20 000 atribuidas a Google, 20 000 atribuidas a una campaña web (que actualmente no se puede ejecutar por medio de SKAN) y 20 000 atribuidas a AppLovin. Por lo tanto, aunque son los mismos totales, los socios atribuidos no coinciden. Aunque podrías hacer revisiones cruzadas de las ventanas de atribución con tu MMP, ya que no puedes ver las ventanas de SKAN, no tienes la capacidad para comparar adecuadamente los conjuntos de datos. El simple hecho de que los totales coinciden no significa que estás más cerca de contar con una sola fuente de verdad.

  2. En segundo lugar, tenemos el ejemplo más común, al que llamamos El callejón sin salida:

    Plazo: julio de 2022

    Instalaciones pagadas del MMP: 80 000

    Instalaciones orgánicas del MMP: 40 000

    Instalaciones de SKAN: 60 000, donde, al utilizar el bit atribuido, 40 000 de ellas se devolvieron con un valor de 1, lo que significa que se atribuyeron

    En este caso, el gerente de UA puede ver que únicamente la mitad de las instalaciones mostradas por el MMP como pagadas aparecen en sus totales de SKAN. Luego, el gerente de UA puede revisar si estas 40 000 instalaciones "faltantes" provinieron de campañas que no son compatibles con SKAN, como web, correo electrónico, influencers, etc. Digamos que el MMP atribuyó 50 000 instalaciones a varias campañas web, 20 000 a Google y 10 000 a Facebook. Las instalaciones de SKAN se atribuyeron a Google y Facebook (30 000 a cada socio). ¿Cómo puedes mapear estas cifras en conjunto? Las 40 000 instalaciones faltantes en el lado de SKAN no coinciden con las 50 000 de las diferentes campañas web. Además, ¿por qué es tan diferente la atribución de Google y Facebook entre SKAN y el MMP, respectivamente?  En teoría, podrías investigar las razones exactas por las que la atribución se realizó de cierta manera con el MMP, pero no puedes hacer lo mismo con SKAN. En otras palabras, estás en un callejón sin salida.

En teoría, el modelo de una sola fuente te permitiría deducir los KPI de rendimiento de eCPI*,* CPE y ROAS a nivel general. Pero, con las limitaciones inherentes en cuanto a la precisión, no sería nada aconsejable optimizar las campañas (escalar, pausar, detener) con base en el cálculo utilizado para obtener una aproximación del rendimiento. Puedes ver los detalles específicos sobre las limitaciones relacionadas con la precisión más abajo.

En resumen, los modelos de una sola fuente proporcionan una visión general aproximada del total de instalaciones de iOS procedentes de ambos entornos de trabajo a cambio de un bit completo.

Explicación de la lógica del bit 

Con el modelo de una sola fuente, el sexto bit (que es el más alto) se asigna a una marca TRUE/FALSE, lo que significa que se pierde la mitad de los 63 valores de conversión que se pueden utilizar para el mapeo de eventos o para las condiciones de rango de ingresos. En la representación binaria, tiene el siguiente aspecto:

Cada bit puede tomar un valor de 0 o 1. Por lo tanto, en el primer escenario, podemos ir desde 000000 hasta 111111, o desde 0 hasta 63 en representación decimal, lo que significa que los 63 valores de conversión se pueden utilizar para las condiciones de mapeo. Sin embargo, en el segundo escenario, podemos ir desde 00000 hasta 11111, o desde 0 hasta 31 en representación decimal, y el sexto bit ahora se convierte en TRUE o 1. Esto significa que, para los valores de conversión de CV=1 a CV=31, cualquier condición de evento asignada al CV supone que no se presentó ninguna atribución de ATT. De manera similar, para los valores de CV=32 a CV=63, cualquier condición de evento asignada al valor de conversión supone que la atribución de ATT se llevó a cabo. Al utilizar un bit para la marca de atribución de ATT, el CV enviado desde el dispositivo incluirá un valor TRUE o FALSE, o estará traducido como 1 o 0 en lenguaje binario.

La consecuencia de esto es que, básicamente, tendrías que repetir dos veces la misma condición del evento en tu esquema de CV (desde CV=1 hasta CV=31, y nuevamente desde CV=32 hasta CV=63) para poder tomar en cuenta la posibilidad de que se realice una atribución de ATT. Además, lo que es más importante, pierdes la mitad de los CV que tienes a tu disposición, y recibes un postback de SKAN que incluye un CV diseñado para informarte si la instalación de SKAN también se atribuyó mediante el entorno de trabajo ATT o no. Es importante tomar en cuenta que este postback no incluye al socio atribuido según ATT. En teoría, sería posible enviar esta información mediante el postback, pero luego tendrías que usar aún más bits, y no hay suficientes bits disponibles para agregar la información del socio sin acabártelos.

Para entender esto y obtener un conjunto de datos "todo en uno" o "de una sola fuente", se realiza el siguiente cálculo:

Instalaciones totales = Instalaciones pagadas de ATT + Instalaciones orgánicas de ATT + Instalaciones pagadas de SKAN (sin marca de ATT)

Este cálculo supone erróneamente que el número de instalaciones pagadas de SKAN (con la marca de ATT) es igual que el número de instalaciones pagadas de ATT durante un período específico.

Una cantidad peligrosa de suposiciones

Estos modelos utilizan demasiadas suposiciones en un ecosistema que depende de la precisión. En este artículo, identificamos las cuatro suposiciones clave que realizan los modelos todo en uno/de una sola fuente y explicamos los problemas que implica cada una.

1. Modelos de cálculo diferentes y desconocidos: el cálculo de Instalaciones totales en sí mismo supone que el número de instalaciones pagadas atribuidas por medio de SKAN que incluyen la marca de ATT es el mismo que el número total de instalaciones pagadas atribuidas en el entorno de trabajo ATT. Sabemos por experiencia que esto es incorrecto. Estas son algunas de las razones:

  • Los socios con los que ejecutas tus campañas deben ofrecer compatibilidad para ambos entornos de trabajo a fin de que los datos coincidan, lo que actualmente no es el caso, por ejemplo, con el tráfico web y los influencers.
  • Es posible que las SAN no sean capaces de reclamar las instalaciones en el entorno de trabajo ATT debido a la falta de autorización de los usuarios, pero se podría atribuir a los mismos usuarios exactos a una SAN en el entorno de trabajo SKAN (debido a que la atribución se realiza independientemente de la autorización de los usuarios).
  • La falta de acceso a la información sobre el engagement y la cascada de atribución de SKAN provocan que sea imposible investigar la manera en que una instalación se atribuyó a un socio específico.
  • SKAN y ATT tienen ventanas de atribución diferentes.

2. Atribución de socios por entorno de trabajo: el cálculo supone que, si SKAN atribuyó una instalación a un socio específico, el MMP también lo hizo (como mencionamos anteriormente, la fuente del socio no se incluye en el bit que lleva la información sobre si la instalación se atribuyó por medio del entorno de trabajo ATT o no). Esta información no se puede confirmar ni refutar, por lo que simplemente no es confiable. Es posible suponer que el número de instalaciones se equilibra en ambos lados al revisar únicamente los totales. Sin embargo, como mencionamos en el punto anterior, esto implica la suposición de que estás ejecutando tu campaña con los mismos socios en ambos entornos de trabajo, lo que significa que la situación se complica cuando hay discrepancias entre los socios. Al tomar en cuenta la manera en que funciona SKAN, esta situación no es inusual. Los anunciantes solo pueden ejecutar campañas de marketing internas (promoción cruzada, marketing por correo electrónico, campañas con influencers y campañas web móviles) dentro del entorno de trabajo ATT. Sin embargo, con un modelo de una sola fuente, estas instalaciones también se envían con la marca de atribución "true" y se agregan al número de instalaciones de SKAN con una marca de ATT, bajo la suposición de que, debido a la superposición de inventarios, SKAN atribuyó estos mismos dispositivos a una red de publicidad. Esto significa que no puedes suponer que Instalaciones pagadas de ATT = Instalaciones pagadas de SKAN (con una marca de ATT), y que cualquier eCPI o ROAS general derivado será impreciso.

3. Día de la instalación: el día de la instalación también es una aproximación del lado de SKAN, ya que el postback no incluye la marca de tiempo exacta. Esta aproximación se puede basar en la ventana de CV utilizada y en el hecho de si el postback incluye un CV que no sea 0. Una de las complicaciones más importantes en este sentido es que, para Google, la marca de tiempo de SKAN no se refiere al día en que Google recibió el postback, como es el caso con todos los demás socios. En lugar de esto, se refiere al día aproximado del engagement, que es un cálculo realizado por Google. Por lo tanto, debes calcular la fecha aproximada de la instalación de SKAN con base en la hora aproximada del engagement de Google. Una vez más, esto implica demasiadas aproximaciones y no es muy confiable.

4. El umbral de privacidad: el umbral de privacidad de Apple genera más complicaciones al intentar crear un cálculo de una sola fuente. Algunos postbacks enviados desde SKAN hacia los socios incluyen el valor CV=null, lo que significa que no obtienes la información del postback que necesitas para saber si la instalación de SKAN se atribuyó en el entorno de trabajo ATT o no. El porcentaje de postbacks que regresan con valores null varía mucho según los socios y las campañas (entre el 10% y el 40%), y no siempre está clara la razón por la que una campaña tiene un mayor porcentaje de valores null que otra. Solo Apple sabe realmente qué es lo que cumple o no cumple con el umbral. En cuanto a las instalaciones pagadas de SKAN (sin marca de ATT), no existe ninguna opción para realizar una aproximación con un factor de multiplicación debido a la ambigüedad de la manera en que se aplica el umbral de privacidad. Una vez más, cualquier intento sería una aproximación.

Los datos lado a lado son la clave para obtener informes precisos y confiables sobre las campañas de iOS

El enfoque de una sola fuente o "todo en uno" para los datos de las campañas de iOS está basado en demasiadas suposiciones. Las herramientas que existen actualmente en el mercado tienen el objetivo de combinar los datos de SKAN y ATT, utilizan varias capas de suposiciones y sacrifican la mitad de los valores de conversión disponibles para los clientes. No vale la pena sacrificar un bit a cambio de obtener datos imprecisos y poco prácticos. Si deseas utilizar los datos más optimizados y de la mejor calidad para apoyar tu crecimiento, simplemente no puedes confiar en los trucos baratos. Los datos claros, precisos y prácticos son indispensables para tomar las decisiones estratégicas más importantes, como dónde asignar los presupuestos, cuáles campañas se deben pausar o escalar, y en qué canales debes enfocarte.

Al tomar en cuenta todas las limitaciones que existen en SKAN, Adjust recomienda la elaboración de informes lado a lado con nuestra herramienta de analytics llamada Datascape. Todos los datos disponibles se muestran en un formato fácil de entender que no utiliza atajos, por lo que realmente puede ser tu herramienta de una sola fuente de verdad. Datascape ofrece una gran variedad de KPI relacionados con SKAN (conversión, ingresos y eventos), con lo que te ayuda a crear informes completos que se pueden utilizar lado a lado con tus datos de atribución normales de Adjust. Esta es la mejor opción para garantizar la precisión.

La opción más efectiva para realizar la medición en el ecosistema complejo de iOS es el uso de aprendizaje automático y predicciones que proporcionen información precisa sobre el eCPI, el CPE y el ROAS, y Adjust está desarrollando la nueva generación de herramientas con estas características. En última instancia, los mercadólogos necesitan algo muy sencillo: una herramienta que demuestre claramente los ingresos que recibe una campaña por cada dólar gastado, para poder decidir si se debe pausar o escalar de forma rápida y confiable.

Si deseas más información, comunícate con tu contacto de Adjust.

¿Quieres información mensual de tus aplicaciones? Suscríbete a nuestro boletín.

Sigue leyendo