Рассчитать сегменты доходов для схемы ценности конверсии сети SKAd

1. Введение

Несколько слов контекста, прежде чем начать.

Если вы разработчик iOS-приложений, вы наверняка слышали об обновлениях конфиденциальности iOS 14.5+ . Для измерения значимых конверсий после установки приложения Apple предоставляет API сети SKAd , который позволяет измерять успех ваших рекламных кампаний, соблюдая при этом конфиденциальность пользователей. В зависимости от потребностей вашего бизнеса вы можете найти наиболее оптимальный способ использования сети SKAd для получения ценной информации о ваших кампаниях. В этом практическом руководстве мы рассмотрим пример методологии использования ваших данных GA4F в BigQuery для группировки доходов после установки приложения по категориям, которые затем можно использовать для настройки с вашим партнером по атрибуции приложений. Хотя в этом практическом руководстве используется подход, основанный на доходах, вы также можете использовать подходы, основанные на событиях или воронках продаж, для измерения SKAN. Для получения более подробной информации обратитесь к этому справочному центру . Это всего лишь пример, а не официальная рекомендация Google . Вы можете разработать собственную схему в соответствии с вашими конкретными потребностями бизнеса.

Что мы намерены осветить

  • Изучите данные GA4F в BigQuery.
  • Найдите данные о доходах пользователей, совершивших конверсию в течение 0-2 дней.
  • Сгруппируйте данные о доходах по категориям.
  • Понимание распределения пользователей в каждой группе
  • Внедрите корзины в Appsflyer SKAN Conversion Studio.

Предварительные условия

2. Доступ к экспорту BigQuery

Чтобы получить доступ к набору данных в GA4F, перейдите в «Настройки проекта» > «Интеграции» > «BigQuery». Сначала необходимо включить соответствующий переключатель, после чего набор данных станет доступен примерно через 48 часов. Вы можете перейти по ссылке ниже, и она перенаправит вас в BigQuery.

1aa4e20bfd3419d1.png

Выполните несколько запросов

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

Чтобы начать писать запрос, нажмите «Запрос» > «В новой вкладке».

42ba59ec655c5d1b.png

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

70ef90d32b7cd7f1.png

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 здесь скрыт).

1e1e6943e4b3a6d8.png

Объединение этих данных

До сих пор мы выполнили два запроса: один для получения данных о пользователях, которые установили и открыли приложение, и другой для расчета дохода этих пользователей. Теперь давайте вспомним, что мы обсуждали об ограничениях сети 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 день.

Группировка доходов по категориям

После выполнения предыдущего запроса вы получите псевдоидентификатор пользователя и общую выручку.

2c1986b93e937d19.png

Теперь нам нужно объединить это в группы, которые мы сможем использовать для диапазонов значений конверсии. Для этой цели мы воспользуемся функцией 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 попытается поддерживать согласованное процентное распределение.

ba46f5d993449948.png

Проанализируйте распределение пользователей с помощью этих категорий.

Это необязательный шаг, если вы хотите понять распределение ваших пользователей по каждой группе. В нашем примере диапазоны групп, возвращенные в предыдущем запросе, следующие:

  • 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

Запрос должен возвращать пользователей в каждом диапазоне доходов за каждый день, как показано ниже. Если вы видите очень низкие значения в какой-либо группе или в целом неравномерное распределение, возможно, вам следует скорректировать количество групп и повторно выполнить запрос.

bf7d73085fe94cb6.png

Несколько слов о сети SKAd Network 4.0

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

4. Развертывание с использованием вашего поставщика атрибуции.

В зависимости от конкретной платформы, эти рекомендации могут меняться. Для получения самой актуальной информации, пожалуйста, свяжитесь с представителями платформы. В качестве примера мы рассмотрим, как это можно развернуть в настоящее время на платформе AppsFlyer.

В запросе, который мы выполняли ранее, итоговые диапазоны, полученные в результате, были следующими.

ba46f5d993449948.png

  • Диапазон 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, и добавить измерение «Доход». Затем вы можете просто добавить диапазоны дохода, которые вы рассчитали на основе предыдущего анализа.

f8c56abdf9b405f4.png

Лучшие практики и уроки по работе с Google Ads

В заключение мы хотели бы дать вам несколько рекомендаций, если вы проводите рекламные кампании в Google Ads и измеряете их эффективность с помощью схемы оценки конверсии в сети SKAd.

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

4fd625aae9d4a43.png

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

6c7a4d703567700a.png

5. Поздравляем!

Поздравляем, вы успешно настроили схему значений конверсий для вашей рекламной сети SKAd. Теперь вы можете отслеживать данные в отчете Google Ads по рекламной сети SKAd , чтобы проверять значения конверсий для ваших кампаний Google Ads, как только эта функция станет доступна.

Вы узнали

  • Как анализировать обширные необработанные данные из GA4F в BigQuery
  • Аналитический подход к расчету источников дохода для вашего бизнеса.
  • Разверните схему с помощью AppsFlyer.