1. Введение
Несколько слов контекста, прежде чем начать.
Если вы разработчик iOS-приложений, вы наверняка слышали об обновлениях конфиденциальности iOS 14.5+ . Для измерения значимых конверсий после установки приложения Apple предоставляет API сети SKAd , который позволяет измерять успех ваших рекламных кампаний, соблюдая при этом конфиденциальность пользователей. В зависимости от потребностей вашего бизнеса вы можете найти наиболее оптимальный способ использования сети SKAd для получения ценной информации о ваших кампаниях. В этом практическом руководстве мы рассмотрим пример методологии использования ваших данных GA4F в BigQuery для группировки доходов после установки приложения по категориям, которые затем можно использовать для настройки с вашим партнером по атрибуции приложений. Хотя в этом практическом руководстве используется подход, основанный на доходах, вы также можете использовать подходы, основанные на событиях или воронках продаж, для измерения SKAN. Для получения более подробной информации обратитесь к этому справочному центру . Это всего лишь пример, а не официальная рекомендация Google . Вы можете разработать собственную схему в соответствии с вашими конкретными потребностями бизнеса.
Что мы намерены осветить
- Изучите данные GA4F в BigQuery.
- Найдите данные о доходах пользователей, совершивших конверсию в течение 0-2 дней.
- Сгруппируйте данные о доходах по категориям.
- Понимание распределения пользователей в каждой группе
- Внедрите корзины в Appsflyer SKAN Conversion Studio.
Предварительные условия
- Интеграция SDK GA4F в ваше iOS-приложение и всех событий, приносящих доход (покупки внутри приложения или доход от рекламы ).
- Экспорт из Firebase в BigQuery включен.
- Партнер по атрибуции приложений, который также регистрирует все события, приносящие доход.
2. Доступ к экспорту BigQuery
Перейдите к набору данных Google Cloud.
Чтобы получить доступ к набору данных в GA4F, перейдите в «Настройки проекта» > «Интеграции» > «BigQuery». Сначала необходимо включить соответствующий переключатель, после чего набор данных станет доступен примерно через 48 часов. Вы можете перейти по ссылке ниже, и она перенаправит вас в BigQuery.

Выполните несколько запросов
Теперь, когда вы находитесь в BigQuery, вы должны увидеть сгенерированные таблицы за каждый день. На скриншоте ниже мы видим 64 таблицы за день, то есть экспорт выполнялся в течение 64 дней. Если вы заходите в систему впервые, вы можете увидеть только одну таблицу за предыдущий день. Справа вы видите схему таблицы. Более подробную информацию о полях можно найти здесь.
Чтобы начать писать запрос, нажмите «Запрос» > «В новой вкладке».

Затем вы можете попробовать выполнить пример запроса в новой вкладке.

3. Анализ данных о доходах
Получение данных установки
Чтобы начать формировать потоки дохода, нам сначала нужно проанализировать данные по пользователям, установившим приложение за последние 24–72 часа. SKAd Network 4.0 позволяет просматривать данные за 0–2 дня, а SKAd Network 3.5 по умолчанию — за 24 часа. (В зависимости от возможностей вашего партнера по атрибуции приложений, вы можете изменить этот временной интервал активности, установив его не более чем на 72 часа). Когда пользователи устанавливают приложение и открывают его в первый раз, SDK генерирует событие first_open, которое записывается в BigQuery.
Идентификатор, который можно использовать в BigQuery, — это user_pseudo_id (также называемый идентификатором экземпляра приложения), поэтому вы можете использовать приведенный ниже запрос для поиска этих пользователей.
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'
Несколько замечаний по поводу этого запроса.
- Пожалуйста, замените имя таблицы на имя вашей экспортированной таблицы из Analytics. Вы можете использовать подстановочные знаки для запроса нескольких таблиц с данными за каждый день. Например, запрос 2023* будет выполняться по всем данным за 2023 год.
- Если у вас много пользователей, вы также можете запрашивать данные только за последние 30 дней для более быстрой обработки.
- Мы используем фильтр по платформе = 'IOS'. Если в вашем проекте Firebase несколько iOS-приложений, вы также можете добавить фильтр по app_info.firebase_app_id, чтобы получить данные для конкретного приложения.
Получение данных о доходах
Теперь давайте рассмотрим запрос для получения дохода от ваших пользователей. В данном случае мы предполагаем, что ваши события получения дохода — это in_app_purchase и ad_impression. Доход от in_app_purchase доступен в event_value_usd, а доход от ad_impression — в параметре value, входящем в параметры события. Если вы не знакомы с параметрами событий в BigQuery, рекомендуем ознакомиться с их определением здесь , а также вы можете попробовать этот пример запроса в нашем официальном справочнике, который также описывает извлечение значения из 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')
Давайте разберемся, что делает этот запрос. Вот что вы заметите.
- В условии WHERE мы фильтруем данные по событиям, связанным с доходом, поскольку нас интересуют только они, и, как и в прошлый раз, ищем данные iOS.
- Теперь в предложении SELECT мы берем значение и валюту события получения дохода от рекламы (ad_impression), а также значение event_value_in_usd, когда событие — in_app_purchase.
- Если вы отправляете средства в нескольких валютах, вам сначала необходимо выровнять валюту для проведения анализа. В этом примере мы будем считать, что валютой дохода от рекламы также является доллар США.
Результат будет выглядеть примерно так (столбец user_pseudo_id здесь скрыт).

Объединение этих данных
До сих пор мы выполнили два запроса: один для получения данных о пользователях, которые установили и открыли приложение, и другой для расчета дохода этих пользователей. Теперь давайте вспомним, что мы обсуждали об ограничениях сети SKAd. Период атрибуции доступен только в течение 0-2 дней после установки. Следовательно, нам нужно проверять временные метки событий установки и дохода и брать информацию только в том случае, если они произошли в этот промежуток времени. Теперь давайте попробуем объединить их в запрос, который будет показывать общий доход для каждого пользователя в течение двух дней после установки приложения.
#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
Запрос просто пытается объединить данные об установках и данные о доходах по полю user_pseudo_id, и затем необходимо убедиться, что временная метка находится в пределах 2 дней. Если вы используете SKAd Network 3.5, по умолчанию используется 24 часа, поэтому вы можете изменить условие, чтобы включить только данные за 1 день.
Группировка доходов по категориям
После выполнения предыдущего запроса вы получите псевдоидентификатор пользователя и общую выручку.

Теперь нам нужно объединить это в группы, которые мы сможем использовать для диапазонов значений конверсии. Для этой цели мы воспользуемся функцией approx_quantiles в BigQuery, которая автоматически создает эти диапазоны. Предположим, что для целей этого примера мы хотим создать 5 диапазонов, поэтому мы можем просто использовать SELECT approx_quantiles(total_revenue, 5) AS buckets
Итак, давайте включим это в наш общий запрос.
#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
Этот запрос разделит выручку на 5 категорий, и BigQuery попытается поддерживать согласованное процентное распределение.

Проанализируйте распределение пользователей с помощью этих категорий.
Это необязательный шаг, если вы хотите понять распределение ваших пользователей по каждой группе. В нашем примере диапазоны групп, возвращенные в предыдущем запросе, следующие:
- 0.1
- 0,5
- 2
- 2.5
- 5 [последнее значение не должно использоваться в конфигурации диапазона]
Для итоговых диапазонов мы проигнорируем последний диапазон 5, поскольку это, как правило, максимальное значение, и можем считать 2,5 последним диапазоном. Это связано с тем, что поставщики услуг атрибуции приложений обычно рассчитывают ROAS, используя среднее значение диапазона, поэтому выброс необходимо исключить для более равномерного расчета.
Теперь давайте посмотрим на количество пользователей за каждую дату во всех диапазонах, чтобы понять ежедневный объем пользователей в каждой группе. Мы можем сделать это, используя этот пример запроса, где вы можете заменить значения групп своими фактическими данными, и запрос будет выглядеть примерно так.
#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
Запрос должен возвращать пользователей в каждом диапазоне доходов за каждый день, как показано ниже. Если вы видите очень низкие значения в какой-либо группе или в целом неравномерное распределение, возможно, вам следует скорректировать количество групп и повторно выполнить запрос.

Несколько слов о сети SKAd Network 4.0
SKAd Network 4.0 предоставляет несколько окон конверсии: до 2 дней, от 3 до 7 дней и от 8 до 35 дней. В описанном выше подходе вы можете легко изменить окно для анализа данных и в этих дополнительных сценариях. Также доступны значения с более крупным масштабом : НИЗКИЙ, СРЕДНИЙ и ВЫСОКИЙ. Опять же, если вы хотите использовать этот подход, вы можете рассматривать это как 3 сегмента. Таким образом, изменив количество сегментов на 3, вы можете получить пороговые значения для НИЗКОГО, СРЕДНЕГО и ВЫСОКОГО уровней.
4. Развертывание с использованием вашего поставщика атрибуции.
В зависимости от конкретной платформы, эти рекомендации могут меняться. Для получения самой актуальной информации, пожалуйста, свяжитесь с представителями платформы. В качестве примера мы рассмотрим, как это можно развернуть в настоящее время на платформе AppsFlyer.
В запросе, который мы выполняли ранее, итоговые диапазоны, полученные в результате, были следующими.

- Диапазон 1: от 0 до 0,1
- Диапазон 2: от 0,1 до 0,5
- Диапазон 3: от 0,5 до 2
- Диапазон 4: от 2 до 2,5
Помните, что мы решили игнорировать последний диапазон доходов , поскольку он будет выбросом и исказит расчеты среднего значения для вашего поставщика услуг атрибуции приложений.
AppsFlyer предлагает SKAN Conversion Studio , где довольно просто ввести эти данные непосредственно в пользовательский интерфейс. Вы можете использовать версию 4.0 напрямую или режим «Пользовательский», если используете версию 3.5, и добавить измерение «Доход». Затем вы можете просто добавить диапазоны дохода, которые вы рассчитали на основе предыдущего анализа.

Лучшие практики и уроки по работе с Google Ads
В заключение мы хотели бы дать вам несколько рекомендаций, если вы проводите рекламные кампании в Google Ads и измеряете их эффективность с помощью схемы оценки конверсии в сети SKAd.
- Убедитесь, что окно конверсии, используемое в Google Ads, совпадает с окном активности , указанным на вашей платформе атрибуции приложений. Для сети SKAd 3.5 это, скорее всего, будет в пределах 1-3 дней, поэтому вы можете соответствующим образом скорректировать его в Google Ads, следуя инструкциям, приведенным здесь.

- Если вы используете Appsflyer, в настоящее время счетчик событий по умолчанию равен 1, что означает, что он не учитывает несколько событий на одного пользователя. Если вы используете модель на основе событий для измерения SKAN и сравниваете с кампаниями tCPA в Google Ads, вы можете настроить ее, следуя этим рекомендациям от Appsflyer.

5. Поздравляем!
Поздравляем, вы успешно настроили схему значений конверсий для вашей рекламной сети SKAd. Теперь вы можете отслеживать данные в отчете Google Ads по рекламной сети SKAd , чтобы проверять значения конверсий для ваших кампаний Google Ads, как только эта функция станет доступна.
Вы узнали
- Как анализировать обширные необработанные данные из GA4F в BigQuery
- Аналитический подход к расчету источников дохода для вашего бизнеса.
- Разверните схему с помощью AppsFlyer.