1. Introdução

Algumas explicações antes de começar

Se você é um desenvolvedor de apps iOS, deve ter ouvido falar das atualizações de privacidade do iOS 14.5 e versões mais recentes. Para medir as ações de conversão significativas após a instalação, a Apple oferece a API SKAdNetwork, que permite medir o sucesso das campanhas publicitárias, respeitando a privacidade do usuário. Com base nas necessidades da sua empresa, você pode encontrar a melhor maneira de aproveitar a SKAdNetwork para coletar insights importantes sobre suas campanhas. Neste codelab, examinamos um exemplo de metodologia para aproveitar os dados do GA4F no BigQuery e agrupar a receita após a instalação do app em buckets, que podem ser usados para configurar com o parceiro de atribuição do app. Embora este codelab use uma abordagem baseada na receita, você também pode usar eventos ou abordagens baseadas em funil para a medição do SKAN. Consulte esta Central de Ajuda para orientações mais detalhadas. Este é apenas um exemplo, não uma recomendação oficial do Google. Você pode projetar seu próprio esquema com base nas necessidades específicas do seu negócio

O que pretendemos abordar

• Analisar dados do GA4F no BigQuery
• Encontrar dados de receita de usuários que converteram em 0 a 2 dias
• Agrupar dados de receita em buckets
• Entender a distribuição de usuários em cada bucket
• Implementar os buckets no Studio de conversão do SKAN da Appsflyer

Pré-requisitos

• SDK do GA4F no seu app iOS e todos os eventos de receita integrados (in_app_purchase ou receita proveniente de anúncios).
• Exportação do Firebase para o BigQuery ativada
• Parceiro de atribuição de app, que também registra todos os eventos de receita

2. Como acessar o BigQuery Export

Navegar até o conjunto de dados do Google Cloud

Acesse o conjunto de dados no GA4F em Configurações do projeto > Integrações > BigQuery. O botão precisa ser ativado primeiro. Depois disso, leva cerca de 48 horas para que o conjunto de dados fique disponível. Clique no link abaixo para acessar o BigQuery.

Executar algumas consultas

Agora que você está no BigQuery, as tabelas diárias geradas vão aparecer. Na captura de tela de exemplo abaixo, há 64 tabelas diárias, então a exportação está em execução há 64 dias. Se você estiver acessando pela primeira vez, talvez só apareça uma tabela diária com os dados do dia anterior. À direita, você encontra o esquema da tabela. Confira mais detalhes sobre os campos aqui.

Para começar a escrever sua consulta, clique em Consulta > Em uma nova guia.

Em seguida, tente executar a consulta de exemplo na nova guia.

3. Analisar dados de receita

Buscando dados de instalação

Agora, para começar a criar os intervalos de receita, precisamos analisar os dados dos usuários que instalaram o app nas últimas 24 a 72 horas. A SKAdNetwork 4.0 permite visualizar dados em 0 a 2 dias, enquanto a SKAdNetwork 3.5 permite 24 horas por padrão. Dependendo dos recursos do parceiro de atribuição de apps, talvez seja possível modificar essa janela de atividade para não mais que 72 horas. Quando os usuários instalam o app e o abrem pela primeira vez, o evento first_open é acionado pelo SDK e registrado no BigQuery.

O identificador que você pode usar no BigQuery é user_pseudo_id (também chamado de ID da instância do app). Use 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 observações sobre essa consulta

• Substitua o nome da tabela pela tabela exportada do Google Analytics. Você pode usar caracteres curinga para consultar várias tabelas diárias. Por exemplo, 2023* vai consultar todos os dados de 2023.
• Se você tiver muitos usuários, também poderá consultar apenas os últimos 30 dias para um processamento mais rápido.
• Filtramos em plataforma = "iOS". Caso você tenha vários apps iOS no seu projeto do Firebase, também é possível adicionar um filtro para app_info.firebase_app_id para receber dados do app específico.

Como buscar dados de receita

Agora, vamos analisar uma consulta para encontrar a receita dos seus usuários. Nesse caso, presumimos 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 que, para ad_impression, a receita está disponível no parâmetro de valor, dentro dos parâmetros do evento. Se você não conhece os parâmetros de eventos no BigQuery, recomendamos verificar a definição aqui e testar esta consulta de exemplo na 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, já que só estamos interessados neles. Como da última vez, estamos procurando dados do iOS.
• Agora, na cláusula SELECT, estamos usando o valor e a moeda do evento de receita de publicidade (ad_impression) e o event_value_in_usd quando o evento é in_app_purchase.
• Se você estiver enviando várias moedas, primeiro precisará alinhar a uma única moeda para essa análise. Para este exemplo, vamos supor que a moeda da receita proveniente de anúncios também seja USD.

A saída será semelhante à abaixo (a coluna para user_pseudo_id está editada aqui).

Como combinar esses dados

Até agora, executamos duas consultas: uma para encontrar os dados dos usuários que instalaram e abriram o app 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 até dois dias após a instalação. Portanto, precisamos verificar os carimbos de data/hora do evento para instalação e receita e coletar as informações somente se elas ocorrerem nesse período. Agora, vamos tentar combinar em uma consulta que forneça a receita total para cada dois dias após a instalação do app.

#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 tenta mesclar os dados de instalação e de receita no campo user_pseudo_id. Depois, precisamos garantir que o carimbo de data/hora esteja dentro de dois dias. Se você estiver usando a SKAd Network 3.5, o padrão é de 24 horas. Portanto, também é possível mudar a condição para incluir apenas os dados de um dia.

Como agrupar a receita em intervalos

Depois da consulta anterior, você terá o user_pseudo_id e a receita total

Agora, precisamos combinar isso em buckets que podemos usar para nossos intervalos de valor de conversão. Para isso, vamos usar a função approx_quantiles no BigQuery, que cria esses intervalos automaticamente. Vamos supor que, para fins deste exemplo, queremos criar cinco intervalos. Portanto, podemos usar SELECT approx_quantiles(total_revenue, 5) AS buckets

Vamos incorporar isso à 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

Essa consulta divide a receita em cinco grupos, e o BigQuery tenta manter uma distribuição de percentil consistente.

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

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

• 0,1
• 0,5
• 2
• 2,5
• 5 [o último valor não será usado na configuração do intervalo]

Para os intervalos finais, vamos ignorar o último bucket 5, já que esse é geralmente o valor máximo, e podemos considerar 2,5 como o último intervalo. Isso ocorre porque os provedores de atribuição de apps tendem a calcular o ROAS usando a média do intervalo. Portanto, o valor fora da curva precisa ser excluído para um cálculo mais uniforme.

Agora vamos tentar analisar o número de usuários de cada data em todos os intervalos para entender o volume diário de usuários em cada bucket. Isso pode ser feito usando esta consulta de exemplo, em que você pode substituir os valores do bucket pelos seus dados reais. A consulta vai ficar 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

Ele vai retornar os usuários em cada faixa de receita para cada dia, como abaixo. Se você encontrar números muito baixos em qualquer bucket ou uma distribuição geralmente desigual, ajuste o número de buckets e execute a consulta novamente.

Uma breve explicação sobre a SKAdNetwork 4.0

A SKAdNetwork 4.0 oferece várias janelas de conversão de até dois, três a sete e oito a 35 dias. Na abordagem acima, você pode mudar facilmente a janela para analisar os dados desses outros cenários. Os valores aproximados BAIXO, MÉDIO e ALTO também estão disponíveis. Mais uma vez, se você quiser usar essa abordagem, pense nisso como três buckets. Assim, ao mudar o número de buckets para 3, você pode receber os limites para BAIXO, MÉDIO e ALTO.

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

Dependendo da plataforma, essa orientação pode mudar. Entre em contato com os representantes da plataforma para receber as informações mais atualizadas sobre o assunto. Para este exemplo, vamos analisar como implantar isso no AppsFlyer.

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

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

Decidimos ignorar o último intervalo de receita, porque ele é um valor fora da curva e distorce os cálculos médios do seu provedor de atribuição de apps.

A AppsFlyer oferece o SKAN Conversion Studio, em que é muito simples inserir esses dados diretamente na interface. Você pode usar a versão 4.0 diretamente ou o modo "Personalizado" se estiver usando a versão 3.5 e adicionar a métrica "Receita". Em seguida, adicione os intervalos de receita que você calculou na análise anterior.

Práticas recomendadas e aprendizados no Google Ads

Confira algumas recomendações se você estiver veiculando campanhas no Google Ads e medindo o impacto usando um esquema de valor da conversão da SKAdNetwork.

• Verifique se a janela de conversão que você está usando no Google Ads corresponde à janela de atividade especificada na sua plataforma de atribuição de app. Para a SKAdNetwork 3.5, isso provavelmente vai acontecer em um a três dias. Para ajustar isso no Google Ads, siga as etapas listadas aqui.

• Se você estiver usando o Appsflyer, o contador de eventos padrão é 1, o que significa que não considera vários eventos por usuário. Se você estiver usando um modelo baseado em eventos para a medição da SKAN e comparando com campanhas de tCPA no Google Ads, poderá personalizar seguindo estas orientações do Appsflyer.

5. Parabéns

Parabéns, você configurou o esquema de valor da conversão da SKAdNetwork. Agora você pode monitorar os dados no Relatório da SKAdNetwork do Google Ads para verificar os valores de conversão das suas campanhas do Google Ads quando elas forem ativadas.

Você aprendeu

• Como analisar os dados brutos avançados do GA4F no BigQuery
• Abordagem analítica para calcular os buckets de receita da sua empresa
• Implantar o esquema com o AppsFlyer