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
- SDK GA4F em seu aplicativo iOS e todos os eventos de receita integrados (in_app_purchase ou receita financiada por anúncios )
- Exportação do Firebase para BigQuery ativada
- App Attribution Partner, que também registra todos os eventos de receita
2. Acessando o BigQuery Export
Navegue até o conjunto de dados do Google Cloud
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
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
Você pode então tentar executar a consulta de exemplo na nova guia
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).
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
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
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.
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
- 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.
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
- 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
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