Calcular grupos de ingresos para el esquema de valor de conversión de la red SKAd

1. Introducción

Un poco de contexto antes de comenzar

Si es desarrollador de aplicaciones de iOS, debe haber oído hablar de las actualizaciones de privacidad de iOS 14.5+ . Para medir las acciones de conversión significativas después de la instalación, Apple proporciona la API de SKAd Network que le permite medir el éxito de sus campañas publicitarias respetando la privacidad del usuario. Según las necesidades de su negocio, puede encontrar la forma más óptima de aprovechar SKAd Network para capturar información significativa sobre sus campañas. En este codelab, examinamos una metodología de ejemplo para aprovechar sus datos GA4F en BigQuery para agrupar los ingresos posteriores a la instalación de la aplicación en depósitos, que luego puede usar para configurar con su socio de atribución de aplicaciones. Si bien este codelab utiliza un enfoque basado en ingresos, también puedes usar eventos o enfoques basados ​​en embudos para la medición de SKAN. Consulte este centro de ayuda para obtener orientación más detallada. Esto es sólo un ejemplo, no una recomendación oficial de Google . Puede diseñar su propio esquema en función de sus necesidades comerciales específicas.

Lo que pretendemos cubrir

  • Explorar datos GA4F en BigQuery
  • Encuentre datos de ingresos de usuarios que realizaron conversiones en un plazo de 0 a 2 días
  • Agrupar datos de ingresos en grupos
  • Comprender la distribución de usuarios en cada segmento
  • Implemente los depósitos en Appsflyer SKAN Conversion Studio

Requisitos previos

2. Acceder a BigQuery Export

Navegue hasta el conjunto de datos en GA4F visitando Configuración del proyecto > Integraciones > BigQuery. La alternancia debe habilitarse primero y, una vez habilitada, el conjunto de datos tarda alrededor de 48 horas en estar disponible. Puede hacer clic en el enlace que se muestra a continuación y lo llevará a BigQuery.

1aa4e20bfd3419d1.png

Ejecute algunas consultas

Ahora que estás en BigQuery, deberías ver las tablas diarias generadas. En la siguiente captura de pantalla de ejemplo, vemos 64 tablas diarias, por lo que la exportación ha estado ejecutándose durante 64 días. Si accede a él por primera vez, es posible que solo vea 1 tabla diaria con los datos del día anterior. A la derecha, ve el esquema de la tabla. Puede consultar más detalles sobre los campos aquí.

Para comenzar a escribir su consulta, puede hacer clic en Consulta > En nueva pestaña

42ba59ec655c5d1b.png

Luego puede intentar ejecutar la consulta de muestra en la nueva pestaña.

70ef90d32b7cd7f1.png

3. Analizar los datos de ingresos

Obteniendo datos de instalación

Ahora, para comenzar a crear los grupos de ingresos, primero debemos observar los datos de los usuarios que instalaron la aplicación en las últimas 24 a 72 horas. SKAd Network 4.0 le permite ver datos en 0 a 2 días, mientras que SKAd Network 3.5 permite 24 horas de forma predeterminada. (Dependiendo de las capacidades de su socio de atribución de aplicaciones, es posible que pueda modificar esta ventana de actividad generalmente a no más de 72 horas). Cuando los usuarios instalan la aplicación y la abren por primera vez, el SDK activa el evento first_open y lo registra en BigQuery.

El identificador que puedes usar para BigQuery es user_pseudo_id (también llamado ID de instancia de aplicación), por lo que puedes usar la siguiente consulta para encontrar estos usuarios.

SELECT
  user_pseudo_id,
  event_name,
  event_date,
  event_timestamp
FROM `project_name.dataset_name.events_2023*`
WHERE
  event_name = 'first_open'
  AND platform = 'IOS'

Un par de cosas a tener en cuenta sobre esta consulta

  • Reemplace el nombre de la tabla con su tabla exportada de Analytics. Puede utilizar comodines para consultar varias tablas diarias. Por ejemplo, 2023* consultará todos los datos en 2023.
  • Si tiene muchos usuarios, también puede consultar solo los últimos 30 días para un procesamiento más rápido.
  • Filtramos por plataforma = 'IOS'. En caso de que tenga varias aplicaciones de iOS en su proyecto de Firebase, también puede agregar un filtro para app_info.firebase_app_id para obtener datos para la aplicación específica.

Obteniendo datos de ingresos

Ahora, veamos una consulta para encontrar ingresos para sus usuarios. En este caso, asumiríamos que sus eventos de ingresos son in_app_purchase y ad_impression. Los ingresos de in_app_purchase están disponibles en event_value_usd, mientras que para ad_impression, los ingresos están disponibles en el parámetro value, dentro de los parámetros del evento. Si no está familiarizado con los parámetros de eventos en BigQuery, le recomendamos verificar la definición aquí y puede probar esta consulta de muestra en nuestra referencia oficial, que también cubre la extracción del valor de event_params.

SELECT
  user_pseudo_id,
  event_name,
  EXTRACT(date FROM Parse_datetime('%Y%m%d', event_date)) AS event_date,
  (
    SELECT COALESCE(value.int_value, value.float_value, value.double_value, NULL)
    FROM UNNEST(event_params)
    WHERE
      KEY = 'value'
      AND event_name = 'ad_impression'
  ) AS ad_funded_revenue,
  (
    SELECT value.string_value
    FROM UNNEST(event_params)
    WHERE
      KEY = 'currency'
      AND event_name = 'ad_impression'
  ) AS ad_revenue_currency,
  (
    CASE
      WHEN event_name = 'in_app_purchase' THEN event_value_in_usd
      ELSE 0
      END) AS iap_revenue_usd,
FROM `project_name.dataset_name.events_2023*`
WHERE
  platform = 'IOS'
  AND event_name IN (
    'in_app_purchase',
    'ad_impression')

Entendamos qué está haciendo la consulta aquí. Estas son las cosas que notarías

  • En la cláusula WHERE, estamos filtrando por los eventos de ingresos, ya que solo nos interesan esos y, como la última vez, buscamos datos de iOS.
  • Ahora, en la cláusula SELECT, tomamos el valor y la moneda para el evento de ingresos publicitarios (ad_impression) y tomamos event_value_in_usd cuando el evento es in_app_purchase.
  • Si envía varias monedas, primero deberá alinearse con una sola moneda para este análisis. A los efectos de este ejemplo, asumiremos que la moneda de los ingresos financiados por publicidad también es USD.

El resultado sería algo parecido a lo siguiente (la columna de user_pseudo_id está redactada aquí).

1e1e6943e4b3a6d8.png

Combinando estos datos

Hasta ahora, hemos realizado dos consultas, una para buscar los datos de los usuarios que instalaron y abrieron la aplicación, y otra para encontrar los ingresos de esos usuarios. Ahora, recordemos lo que discutimos sobre las limitaciones de SKAd Network. La ventana de atribución solo puede estar disponible entre 0 y 2 días después de la instalación. Por lo tanto, necesitaremos verificar las marcas de tiempo del evento para instalación e ingresos, y solo tomar la información si ocurre dentro de ese período de tiempo. Ahora intentemos combinar en una consulta que proporcione los ingresos totales por cada publicación de dos días de instalación de la aplicación.

#creating the install table
WITH
  install_table AS (
    SELECT
      user_pseudo_id,
      event_name,
      event_date,
      event_timestamp
    FROM `project_name.dataset_name.events_2023*`
    WHERE
      event_name = 'first_open'
      AND platform = 'IOS'
  ),
  #creating the revenue table
  revenue_table AS (
    SELECT
      user_pseudo_id,
      event_name,
      event_timestamp,
      EXTRACT(date FROM Parse_datetime('%Y%m%d', event_date)) AS event_date,
      (
        SELECT COALESCE(value.int_value, value.float_value, value.double_value, NULL)
        FROM UNNEST(event_params)
        WHERE
          KEY = 'value'
          AND event_name = 'ad_impression'
      ) AS ad_funded_revenue,
      (
        SELECT value.string_value
        FROM UNNEST(event_params)
        WHERE
          KEY = 'currency'
          AND event_name = 'ad_impression'
      ) AS ad_revenue_currency,
      (
        CASE
          WHEN event_name = 'in_app_purchase' THEN event_value_in_usd
          ELSE 0
          END) AS iap_revenue_usd,
    FROM `project_name.dataset_name.events_2023*`
    WHERE
      platform = 'IOS'
      AND event_name IN (
        'in_app_purchase',
        'ad_impression')
  )
SELECT
  it.user_pseudo_id AS user_pseudo_id,
  #combine ad revenue and IAP revenue, assuming both are in same currency
  sum(ifnull(rt.iap_revenue_usd,0) + ifnull(rt.ad_funded_revenue,0)) AS total_revenue,
FROM install_table it
INNER JOIN revenue_table rt
  ON it.user_pseudo_id = rt.user_pseudo_id
WHERE
  rt.event_timestamp >= it.event_timestamp
  AND rt.event_timestamp
    <= it.event_timestamp + 86400000000 * 2  #added 86400 000 millisecond as 24 hours, taking for 2 days later
GROUP BY 1

La consulta simplemente intenta unir los datos de instalación y los datos de ingresos en el campo user_pseudo_id, y luego debemos asegurarnos de que la marca de tiempo sea dentro de 2 días. Si está utilizando SKAd Network 3.5, el valor predeterminado es 24 horas, por lo que también puede cambiar la condición para incluir solo los datos de 1 día.

Agrupar los ingresos en grupos

Después de la consulta anterior, tendrás el user_pseudo_id y los ingresos totales.

2c1986b93e937d19.png

Ahora necesitaremos combinar esto en depósitos que podamos usar para nuestros rangos de valores de conversión. Para ello, utilizaremos la función approx_quantiles en BigQuery, que crea automáticamente estos rangos. Supongamos, para los propósitos de este ejemplo, que queremos crear 5 rangos, por lo que podemos usar SELECT approx_quantiles(total_revenue, 5) como depósitos.

Con eso, incorporemos esto a nuestra consulta general.

#creating the install table
WITH
  install_table AS (
    SELECT
      user_pseudo_id,
      event_name,
      event_date,
      event_timestamp
    FROM `project_name.dataset_name.events_2023*`
    WHERE
      event_name = 'first_open'
      AND platform = 'IOS'
  ),
  #creating the revenue table
  revenue_table AS (
    SELECT
      user_pseudo_id,
      event_name,
      event_timestamp,
      EXTRACT(date FROM Parse_datetime('%Y%m%d', event_date)) AS event_date,
      (
        SELECT COALESCE(value.int_value, value.float_value, value.double_value, NULL)
        FROM UNNEST(event_params)
        WHERE
          KEY = 'value'
          AND event_name = 'ad_impression'
      ) AS ad_funded_revenue,
      (
        SELECT value.string_value
        FROM UNNEST(event_params)
        WHERE
          KEY = 'currency'
          AND event_name = 'ad_impression'
      ) AS ad_revenue_currency,
      (
        CASE
          WHEN event_name = 'in_app_purchase' THEN event_value_in_usd
          ELSE 0
          END) AS iap_revenue_usd,
    FROM `project_name.dataset_name.events_2023*`
    WHERE
      platform = 'IOS'
      AND event_name IN (
        'in_app_purchase',
        'ad_impression')
  ),
  total_revenue_table AS (
    SELECT
      it.user_pseudo_id AS user_pseudo_id,
      #combine ad revenue and IAP revenue, assuming both are in same currency
      sum(ifnull(rt.iap_revenue_usd,0) + ifnull(rt.ad_funded_revenue,0)) AS total_revenue,
    FROM install_table it
    INNER JOIN revenue_table rt
      ON it.user_pseudo_id = rt.user_pseudo_id
    WHERE
      rt.event_timestamp >= it.event_timestamp
      AND rt.event_timestamp
        <= it.event_timestamp + 86400000000 * 2  #added 86400 000 millisecond as 24 hours
    GROUP BY 1
  )
SELECT approx_quantiles(total_revenue, 5) AS buckets FROM total_revenue_table

Esta consulta dividirá los ingresos en cinco grupos y BigQuery intenta mantener una distribución percentil coherente.

ba46f5d993449948.png

Analice la distribución de usuarios con estos depósitos

Este es un paso opcional , si desea comprender la distribución de sus usuarios en cada depósito. Para nuestro ejemplo, los rangos de depósitos devueltos en la consulta anterior son

  • 0.1
  • 0,5
  • 2
  • 2.5
  • 5 [el último valor no se utilizará en la configuración del rango]

Para los rangos finales, ignoraremos el último segmento 5, ya que generalmente es el valor máximo, y podemos considerar simplemente 2,5 como el último rango. Esto se debe a que los proveedores de atribución de aplicaciones tienden a calcular el ROAS utilizando la media del rango, por lo que se debe excluir el valor atípico para un cálculo más uniforme.

Ahora intentaremos ver la cantidad de usuarios para cada fecha en todos los rangos, de modo que podamos comprender el volumen diario de usuarios en cada depósito. Podemos hacerlo usando esta consulta de muestra, donde puede reemplazar los valores del depósito con sus datos reales, y la consulta se vería así

#creating the install table
WITH
  install_table AS (
    SELECT
      user_pseudo_id,
      event_name,
      event_date,
      event_timestamp
    FROM `project_name.dataset_name.events_2023*`
    WHERE
      event_name = 'first_open'
      AND platform = 'IOS'
  ),
  #creating the revenue table
  revenue_table AS (
    SELECT
      user_pseudo_id,
      event_name,
      event_timestamp,
      EXTRACT(date FROM Parse_datetime('%Y%m%d', event_date)) AS event_date,
      (
        SELECT COALESCE(value.int_value, value.float_value, value.double_value, NULL)
        FROM UNNEST(event_params)
        WHERE
          KEY = 'value'
          AND event_name = 'ad_impression'
      ) AS ad_funded_revenue,
      (
        SELECT value.string_value
        FROM UNNEST(event_params)
        WHERE
          KEY = 'currency'
          AND event_name = 'ad_impression'
      ) AS ad_revenue_currency,
      (
        CASE
          WHEN event_name = 'in_app_purchase' THEN event_value_in_usd
          ELSE 0
          END) AS iap_revenue_usd,
    FROM `project_name.dataset_name.events_2023*`
    WHERE
      platform = 'IOS'
      AND event_name IN (
        'in_app_purchase',
        'ad_impression')
  ),
  total_revenue_table AS (
    SELECT
      it.user_pseudo_id AS user_pseudo_id,
      rt.event_date,
      #combine ad revenue and IAP revenue, assuming both are in same currency
      sum(ifnull(rt.iap_revenue_usd,0) + ifnull(rt.ad_funded_revenue,0)) AS total_revenue,
    FROM install_table it
    INNER JOIN revenue_table rt
      ON it.user_pseudo_id = rt.user_pseudo_id
    WHERE
      rt.event_timestamp >= it.event_timestamp
      AND rt.event_timestamp
        <= it.event_timestamp + 86400000000 * 2  #added 86400 000 millisecond as 24 hours
    GROUP BY 1, 2
  )
SELECT
  event_date,
  sum(CASE WHEN total_revenue BETWEEN 0 AND 0.1 THEN 1 ELSE 0 END) AS Bucket1,
  sum(CASE WHEN total_revenue BETWEEN 0.1 AND 0.5 THEN 1 ELSE 0 END) AS Bucket2,
  sum(CASE WHEN total_revenue BETWEEN 0.5 AND 2 THEN 1 ELSE 0 END) AS Bucket3,
  sum(CASE WHEN total_revenue BETWEEN 2 AND 2.5 THEN 1 ELSE 0 END) AS Bucket4,
  sum(CASE WHEN total_revenue > 2.5 THEN 1 ELSE 0 END) AS Bucket5
FROM total_revenue_table
GROUP BY 1 ORDER BY 1 DESC

Devolverá los usuarios en cada rango de ingresos para cada día, como se muestra a continuación. Si ve números muy bajos en cualquier depósito o una distribución generalmente desigual, es posible que desee ajustar la cantidad de depósitos y volver a ejecutar la consulta.

bf7d73085fe94cb6.png

Unas breves palabras sobre SKAd Network 4.0

SKAd Network 4.0 proporciona múltiples ventanas de conversión de hasta 2 días, de 3 a 7 días y de 8 a 35 días. En el enfoque anterior, también puede cambiar fácilmente la ventana para analizar datos para estos escenarios adicionales. También están disponibles valores de grano grueso BAJO, MEDIO y ALTO. Nuevamente, si desea utilizar este enfoque, puede pensar en esto como 3 depósitos. Entonces, al cambiar el número de depósitos a 3, puede obtener los umbrales de BAJO, MEDIO y ALTO.

4. Implementación con su proveedor de atribución

Dependiendo de la plataforma específica, esta guía podría cambiar. Trabaje con los representantes de la plataforma para obtener la información más actualizada al respecto. Para los propósitos de este ejemplo, veremos cómo podemos implementar esto actualmente en AppsFlyer.

En la consulta que ejecutamos anteriormente, los rangos finales que recibimos como resultado fueron los siguientes

ba46f5d993449948.png

  • Rango 1: 0 a 0,1
  • Rango 2: 0,1 a 0,5
  • Rango 3: 0,5 a 2
  • Rango 4: 2 a 2,5

Recuerde que decidimos ignorar el último rango de ingresos , ya que será un valor atípico y sesgará los cálculos promedio de su proveedor de atribución de aplicaciones.

AppsFlyer ofrece SKAN Conversion Studio , donde es bastante sencillo ingresar esto directamente en la interfaz de usuario. Puede usar 4.0 directamente o usar el modo "Personalizado" si está usando 3.5 y agregar la medición de "Ingresos". Luego puede simplemente agregar los rangos de ingresos que calculó a partir del análisis anterior.

f8c56abdf9b405f4.png

Mejores prácticas y aprendizajes sobre Google Ads

Nos gustaría dejarle algunas recomendaciones si está ejecutando campañas en Google Ads y midiendo el impacto a través de un esquema de valor de conversión de SKAd Network.

  • Asegúrate de que la ventana de conversión que estás utilizando en Google Ads coincida con la ventana de actividad que has especificado en tu plataforma App Attribution. Para SKAd Network 3.5, es probable que esto ocurra dentro de 1 a 3 días, por lo que puede ajustarlo en consecuencia en Google Ads siguiendo los pasos que se enumeran aquí .

4fd625aae9d4a43.png

  • Si utiliza Appsflyer, actualmente el contador de eventos predeterminado es 1, lo que significa que no tiene en cuenta múltiples eventos por usuario. Si está utilizando un modelo basado en eventos para medir SKAN y compararlo con campañas de tCPA en Google Ads, puede optar por personalizarlo siguiendo esta guía de Appsflyer.

6c7a4d703567700a.png

5. Felicitaciones

Felicitaciones, ha configurado con éxito su esquema de valor de conversión de red SKAd. Ahora puede monitorear los datos en su informe de Google Ads SKAd Network para verificar los valores de conversión de sus campañas de Google Ads una vez que esté activo.

has aprendido

  • Cómo explorar los ricos datos sin procesar de GA4F en BigQuery
  • Enfoque analítico para calcular los ingresos de su negocio
  • Implementar el esquema con AppsFlyer