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

1. Введение

Некоторый контекст, прежде чем мы начнем

Если вы разработчик приложений для iOS, вы наверняка слышали об обновлениях конфиденциальности iOS 14.5+ . Для измерения значимых действий-конверсий после установки Apple предоставляет API сети SKAd , который позволяет вам оценивать успех ваших рекламных кампаний, соблюдая при этом конфиденциальность пользователей. Основываясь на потребностях вашего бизнеса, вы можете найти наиболее оптимальный способ использования сети SKAd Network для сбора значимой информации о ваших кампаниях. В этой лаборатории кода мы рассмотрим пример методологии использования ваших данных 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'

Несколько вещей, которые следует отметить по этому запросу

  • Замените имя таблицы на экспортированную таблицу Google 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, а затем мы должны убедиться, что временная метка находится в пределах двух дней. Если вы используете SKAd Network 3.5, значение по умолчанию составляет 24 часа, поэтому вы также можете изменить условие, чтобы оно включало только данные за 1 день.

Группировка доходов по корзинам

После предыдущего запроса у вас будет user_pseudo_id и общий доход.

2c1986b93e937d19.png

Теперь нам нужно будет объединить это в сегменты, которые мы сможем использовать для наших диапазонов ценности конверсии. Для этой цели мы будем использовать функцию Approx_quantiles в BigQuery, которая автоматически создает для вас эти диапазоны. Предположим, для целей этого примера мы хотим создать 5 диапазонов, поэтому мы можем просто использовать сегменты SELECT приблизительно_квантили(total_revenue, 5) AS.

Теперь давайте включим это в наш общий запрос.

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

Теперь мы попытаемся посмотреть количество пользователей на каждую дату во всех диапазонах, чтобы понять ежедневный объем пользователей в каждом сегменте. Мы можем сделать это с помощью этого примера запроса, в котором вы можете заменить значения сегмента на ваши фактические данные, и запрос будет выглядеть примерно так

#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 Рекламе

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

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

4fd625aae9d4a43.png

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

6c7a4d703567700a.png

5. Поздравления

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

Вы узнали

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