Calcular intervalos de receita para o esquema de valor de conversão da rede SKAd

1. Introdução

Algum contexto antes de começarmos

Se você é um desenvolvedor de aplicativos iOS, deve ter ouvido falar das atualizações de privacidade do iOS 14.5+ . Para medir ações de conversão significativas após a instalação, a Apple fornece a API SKAd Network , que permite medir o sucesso de suas campanhas publicitárias, respeitando a privacidade do usuário. Com base nas necessidades do seu negócio, você pode encontrar a maneira ideal de aproveitar a SKAd Network para capturar insights significativos sobre suas campanhas. Neste codelab, examinamos um exemplo de metodologia para aproveitar seus dados do GA4F no BigQuery para agrupar a receita após a instalação do aplicativo em intervalos, que você pode usar para configurar com seu parceiro de atribuição de aplicativos. Embora este codelab use uma abordagem baseada em receita, você também pode usar abordagens baseadas em eventos ou funil para medição de SKAN. Consulte esta central de ajuda para obter orientações mais detalhadas. Este é apenas um exemplo, não uma recomendação oficial do Google . Você pode criar seu próprio esquema com base nas necessidades específicas do seu negócio

O que pretendemos cobrir

  • Explore os dados do GA4F no BigQuery
  • Encontre dados de receita de usuários que realizaram conversões em 0 a 2 dias
  • Agrupar dados de receita em intervalos
  • Entenda a distribuição de usuários em cada bucket
  • Implemente os buckets no Appsflyer SKAN Conversion Studio

Pré-requisitos

2. Acessando o BigQuery Export

Navegue até o conjunto de dados no GA4F visitando Configurações do projeto > Integrações > BigQuery. A alternância precisa ser habilitada primeiro e, depois de habilitada, leva cerca de 48 horas para que o conjunto de dados esteja disponível. Você pode clicar no link mostrado abaixo e ele o levará ao BigQuery

1aa4e20bfd3419d1.png

Execute algumas consultas

Agora que você está no BigQuery, deverá ver as tabelas diárias geradas. Na captura de tela do exemplo abaixo, vemos 64 tabelas diárias, portanto a exportação está em execução há 64 dias. Se você estiver acessando pela primeira vez, poderá ver apenas 1 tabela diária com os dados do dia anterior. À direita, você vê o esquema da tabela. Você pode consultar mais detalhes sobre os campos aqui

Para começar a escrever sua consulta, você pode clicar em Consulta > Em nova aba

42ba59ec655c5d1b.png

Você pode então tentar executar a consulta de exemplo na nova guia

70ef90d32b7cd7f1.png

3. Analise os dados de receita

Buscando dados de instalação

Agora, para começar a construir os grupos de receita, precisamos primeiro analisar os dados dos usuários que instalaram o aplicativo nas últimas 24 a 72 horas. O SKAd Network 4.0 permite visualizar dados em 0 a 2 dias, enquanto o SKAd Network 3.5 permite 24 horas por padrão. (Dependendo dos recursos do seu parceiro de atribuição de aplicativos, você poderá modificar essa janela de atividade geralmente para no máximo 72 horas). Quando os usuários instalam o aplicativo e o abrem pela primeira vez, o evento first_open é acionado pelo SDK e registrado no BigQuery.

O identificador que você pode usar para o BigQuery é user_pseudo_id (também chamado de ID da instância do aplicativo). Portanto, você pode usar a consulta abaixo para encontrar esses usuários

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'

Algumas coisas a serem observadas sobre esta consulta

  • Substitua o nome da tabela pela tabela exportada do Analytics. Você pode usar curingas para consultar diversas tabelas diárias. Por exemplo, 2023* consultará todos os dados em 2023
  • Se você tiver muitos usuários, também poderá consultar apenas os últimos 30 dias para um processamento mais rápido
  • Filtramos em platform = 'IOS'. Caso você tenha vários aplicativos iOS em seu projeto Firebase, você também pode adicionar um filtro para app_info.firebase_app_id para obter dados para o aplicativo específico

Buscando dados de receita

Agora, vamos analisar uma consulta para encontrar receita para seus usuários. Nesse caso, presumiríamos que seus eventos de receita são in_app_purchase e ad_impression. A receita de in_app_purchase está disponível em event_value_usd, enquanto para ad_impression, a receita está disponível no parâmetro value, dentro dos parâmetros do evento. Se você não estiver familiarizado com parâmetros de evento no BigQuery, recomendamos verificar a definição aqui . Experimente este exemplo de consulta em nossa referência oficial, que também aborda a extração do 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')

Vamos entender o que a consulta está fazendo aqui. Estas são as coisas que você notaria

  • Na cláusula WHERE, estamos filtrando os eventos de receita, pois só estamos interessados ​​neles e, como da última vez, estamos procurando dados do iOS
  • Agora, na cláusula SELECT, pegamos o valor e também a moeda do evento de receita publicitária (ad_impression) e pegamos o event_value_in_usd quando o evento é in_app_purchase
  • Se você estiver enviando várias moedas, primeiro será necessário alinhar-se a uma única moeda para esta análise. Para efeitos deste exemplo, assumiremos que a moeda para a receita financiada por publicidade também é o dólar americano.

A saída seria algo como abaixo (a coluna para user_pseudo_id está redigida aqui).

1e1e6943e4b3a6d8.png

Combinando esses dados

Até agora, executamos duas consultas, uma para encontrar os dados dos usuários que instalaram e abriram o aplicativo e outra para encontrar a receita desses usuários. Agora, vamos lembrar o que discutimos sobre as limitações da rede SKAd. A janela de atribuição só pode estar disponível dentro de 0 a 2 dias após a instalação. Portanto, precisaremos verificar os carimbos de data e hora do evento para instalação e receita, e só pegar as informações se acontecer dentro desse prazo. Vamos agora tentar combinar uma consulta que forneça a receita total para cada postagem dois dias após a instalação do aplicativo

#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

A consulta apenas tenta juntar os dados de instalação e os dados de receita no campo user_pseudo_id, e então temos que garantir que o carimbo de data / hora esteja dentro de 2 dias. Se você estiver usando o SKAd Network 3.5, o padrão é 24 horas, então você também pode alterar a condição para incluir apenas os dados de 1 dia

Agrupando a receita em grupos

Após a consulta anterior, você terá o user_pseudo_id e a receita total

2c1986b93e937d19.png

Agora precisaremos combinar isso em grupos que podemos usar para nossas faixas de valores de conversão. Para isso, usaremos a função approx_quantiles do BigQuery, que cria automaticamente esses intervalos para você. Vamos supor, para os fins deste exemplo, que queremos criar 5 intervalos, então podemos apenas usar SELECT approx_quantiles(total_revenue, 5) AS buckets

Com isso, vamos incorporar isso em nossa consulta geral

#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á a receita em cinco intervalos e o BigQuery tentará manter uma distribuição percentual consistente

ba46f5d993449948.png

Analise a distribuição de usuários com esses buckets

Esta é uma etapa opcional se você quiser entender a distribuição de seus usuários em cada bucket. Para nosso exemplo, os intervalos de bucket retornados na consulta anterior são

  • 0,1
  • 0,5
  • 2
  • 2,5
  • 5 [o último valor não deve ser usado na configuração da faixa]

Para os intervalos finais, devemos ignorar o último intervalo 5, pois geralmente é o valor máximo, e podemos considerar apenas 2,5 como o último intervalo. Isso ocorre porque os provedores de atribuição de aplicativos tendem a calcular o ROAS usando a média do intervalo, portanto, o valor discrepante deve ser excluído para um cálculo mais uniforme.

Tentaremos agora observar o número de usuários para cada data em todos os intervalos, para que possamos entender o volume diário de usuários em cada intervalo. Podemos fazer isso usando este exemplo de consulta, onde você pode substituir os valores do intervalo por seus dados reais, e a consulta seria mais ou menos assim

#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

Deve retornar os usuários em cada faixa de receita para cada dia, conforme abaixo. Se você observar números muito baixos em qualquer intervalo ou uma distribuição geralmente desigual, convém ajustar o número de intervalos e executar novamente a consulta.

bf7d73085fe94cb6.png

Uma palavra rápida sobre SKAd Network 4.0

SKAd Network 4.0 oferece múltiplas janelas de conversão de até 2 dias, 3 a 7 dias e 8 a 35 dias. Na abordagem acima, você também pode alterar facilmente a janela para analisar dados para esses cenários adicionais. Valores granulares grossos de BAIXO, MÉDIO e ALTO também estão disponíveis. Novamente, se quiser usar essa abordagem, você pode pensar nisso como 3 intervalos. Portanto, alterando o número de intervalos para 3, você pode obter os limites para BAIXO, MÉDIO e ALTO

4. Implantação com seu provedor de atribuição

Dependendo da plataforma específica, esta orientação pode mudar. Trabalhe com os representantes da plataforma para obter informações mais atualizadas sobre isso. Para os fins deste exemplo, veremos como podemos implantar isso atualmente na AppsFlyer

Na consulta que executamos anteriormente, os intervalos finais que recebemos como saída foram os seguintes

ba46f5d993449948.png

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

Lembre-se de que decidimos ignorar a última faixa de receita , pois será uma exceção e distorcerá os cálculos médios do seu provedor de atribuição de aplicativos.

A AppsFlyer oferece o SKAN Conversion Studio , onde é bastante simples inserir isso diretamente na UI. Você pode usar o 4.0 diretamente ou usar o modo "Personalizado" se estiver usando o 3.5 e adicionar a medição "Receita". Você pode então simplesmente adicionar as faixas de receita calculadas na análise anterior.

f8c56abdf9b405f4.png

Melhores práticas e aprendizados no Google Ads

Gostaríamos de deixar algumas recomendações se você estiver executando campanhas no Google Ads e medindo o impacto por meio de um esquema de valor de conversão da rede SKAd

  • Certifique-se de que a janela de conversão que você está usando no Google Ads corresponde à janela de atividade especificada em sua plataforma App Attribution. Para a rede SKAd 3.5, isso provavelmente ocorrerá dentro de um a três dias, então você pode ajustá-lo adequadamente no Google Ads seguindo as etapas listadas aqui

4fd625aae9d4a43.png

  • Se você estiver usando o Appsflyer, atualmente o contador de eventos padrão é 1, o que significa que ele não contabiliza vários eventos por usuário. Se você estiver usando um modelo baseado em eventos para medição SKAN e comparação com campanhas tCPA no Google Ads, poderá optar por personalizar seguindo esta orientação da Appsflyer

6c7a4d703567700a.png

5. Parabéns

Parabéns, você configurou com êxito seu esquema de valor de conversão da rede SKAd. Agora você pode monitorar os dados em seu relatório da rede SKAd do Google Ads para verificar os valores de conversão de suas campanhas do Google Ads quando ele estiver ativo

Você aprendeu

  • Como explorar os ricos dados brutos do GA4F no BigQuery
  • Abordagem analítica para calcular faixas de receita para o seu negócio
  • Implante o esquema com AppsFlyer