Получите 14 дней бесплатного доступа ко всем возможностям OWOX BI

Как происходит расчет модели атрибуции в OWOX BI Attribution

Модель атрибуции OWOX BI оценивает эффективность ваших рекламных кампаний, учитывая вклад каждого канала в продвижение клиента по конверсионной воронке. Расчет модели в OWOX BI происходит на основе цепи Маркова.

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

Подробнее о различиях моделей атрибуции и основных принципах расчета атрибуции на основе цепей Маркова — читайте в нашем блоге.

В этой статье мы в деталях опишем весь процесс расчета модели атрибуции в OWOX BI.

На основе каких данных строится модель

Чтобы рассчитать модель атрибуции в OWOX BI вам нужны данные, загруженные в Google BigQuery и аккаунт Google с доступом BigQuery Admin ко всем данным, которые вы собираетесь подключить к модели атрибуции.

В основу модели могут лечь до трех источников данных:

  1. Данные о поведении пользователей сайта. Это могут быть: данные собранные OWOX BI с помощью потока Google Analytics → Google BigQuery или данные, экспортированные из Google Analytics 360
  2. Данные об онлайн- и офлайн-заказах из вашей CRM-системы, загруженные в Google BigQuery. Как загрузить данные из CRM в BigQuery.
  3. Кастомные события — любые другие события, загруженные в таблицу BigQuery вручную. Подробнее об атрибуции кастомных событий.

Подробнее о подготовке данных расчета модели атрибуции — в этой статье.

Расчет модели атрибуции состоит из четырех этапов:

  1. Сбор событий из источников
  2. Расчет вероятностей перехода между шагами воронки
  3. Сбор конверсий
  4. Расчет ценности событий

Далее в статье — обо всех нюансах каждого этапа.

Этап 1. Сбор событий

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

Ниже — по каким принципам происходит сбор этих событий.

Как генерируется ID сессии из данных таблиц с кастомными событиями и данными из CRM?

Кастомные события: на основании полей user_id, client_id, utm_source, utm_medium, utm_campaign, geo_region и даты в поле time.

Данные CRM: на основании полей user_id, transaction_id, transaction_created.

 Как учитываются данные из разных источников при совпадении (и несовпадении) в них транзакций?

Google Analytics + CRM: в случае совпадения данных по отдельным транзакциям, ценность будет распределена в зависимости от того, в какой таблице есть данные. Тут возможны три варианта:

1) Транзакции есть в данных Google Analytics, но их нет в таблице с транзакциями из CRM:

  • Ценность товаров из этих транзакций не будет распределена. При такой комбинации источников подразумевается, что наличие данных о транзакции в CRM подтверждает факт самой транзакции. Если транзакция не попала в CRM, то она была отменена или произошел возврат средств — уже после того, как Google Analytics учел транзакцию онлайн.

2) Транзакций нет в Google Analytics, но они есть в таблице с транзакциями из CRM:

  • Эти транзакции считаются офлайн-покупками и для них будут созданы сессии покупок с каналом (medium) 'offline'.
  • Если у покупателя до офлайн-покупки были онлайн-сессии и OWOX BI получил достаточно данных для того, чтобы объединить сессию и покупку по ID пользователя, то эти сессии получат ценность. Ценность шагов воронки между онлайн- и офлайн-взаимодействием получит сессия офлайн-покупки.
  • Если онлайн-сессий не было, то 100% ценности получит сессия офлайн-покупки.

3) Транзакции есть и в Google Analytics, и в таблице с транзакциями из CRM:
Вся информация о таких транзакциях и о сессиях, которые к ним привели, будет соответствовать данным Google Analytics.

Google Analytics + кастомные события. Цель добавления кастомных событий — дополнить данные об онлайн-конверсиях событиями, которые не может отследить Google Analytics. Например, звонок колцентра, отправленный имейл, просмотр и т.д. Поэтому при совпадении данных приоритет будет отдан транзакциям из таблицы с кастомными событиями.

CRM + кастомные события. Аналогично предыдущему случаю при совпадении данных приоритет будет отдан кастомным событиям, которые дополнят данные из CRM. Но только в том случае, если в источнике CRM есть транзакция в статусе completed. В противном случае, ценность распределена не будет.

Подробнее о настройке атрибуции кастомных событий

Google Analytics + CRM + кастомные события. Когда все источники включены, ценность атрибутируется по приоритету 1) Кастомные события, 2) Google Analytics, 3) CRM.

Подробнее об учете транзакций из разных источников

Как объединяются сессии одного пользователя с разных устройств и браузеров?

Сессии объединяются путем сопоставления параметров User ID для аутентифицированных действий и Client ID — для неаутентифицированных.

OWOX BI объединяет взаимодействия в цепочки в первую очередь по User ID, если User ID известен. Если какие-то взаимодействия совершались без аутентификации, но пользователь до или после этого был аутентифицирован на этом устройстве, то эти действия также попадут в цепочку. И так по всем его устройствам:

All_sessions_connected_ru.pngАутентифицированные сессии объединены по userId, неаутентифицированные — по clientId — все вместе они составляют одну цепочку

В случае, когда у нас несколько User ID для одного Client ID — все действия будут объединены цепочку, но будут приписаны последнему зафиксированному User ID:

All_sessions_connected_different_userId_ru.pngСессии объединены по Client ID, а все действия отнесены к последнему зафиксированному на устройстве User ID — userId 2

Client ID в разных источниках определяется по-разному:

Источник Поле в таблице BigQuery
Таблицы owoxbi_sessions и session_streaming, собранные OWOX BI Поле clientId
Таблицы BigQuery Export for GA 360 Поле fullVisitorId как session_client_id, если не указан customDimension
Кастомные события и данные из CRM Поле client_id

 

Какие ID пользователей НЕ учитываются при расчете модели?

ID пользователей (и комбинации User ID и Client ID, описанные выше), которые встречались в более 100 сессий в день за прошедшие 365 дней — игнорируются, так как это неестественная активность для реальных пользователей. Все события для этих ID учитываются при расчете, но пользователи считаются как неавторизованные.

Также к неавторизированным пользователям определяются все пользователи с User ID со значениями 'undefined', '0' или пустыми значениями. Это нужно для того, чтобы вы не получили ложных пользователей с сотнями сессий, объединенных по User ID.

Какие сессии не учитываются при расчете модели?

Если в настройках модели вы указали источники, которые следует исключить при расчете ценности, то ценность исключенного источника перейдет к предыдущему источнику в цепочке.
Это работает аналогично модели атрибуции Last Non-Direct Click, но исключить можно не только прямой трафик, но и любые другие источники.

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

Подробности и примеры — в статье «Распределение ценности сессий по источникам».

Какие данные нужны для расчета вероятностей перехода между шагами воронки?

В основу расчета ложатся свойства пользователя: тип (новый или вернувшийся), устройство и регион.

Тип пользователя определяется на основании заказов пользователя за последние 365 дней. Пользователи в сессиях до первой конверсии в рамках этого периода — получат тип 'New'. В сессиях после первой конверсии — 'Returning'.

Устройство: все сессии с одинаковыми ID пользователя и значением устройства получают соответствующее устройство: 'mobile', 'tablet' или 'desktop'. Если у одного пользователя найдено несколько разных значений устройства, то его устройство определяется как 'cross'. Анализируются сессии за прошедшие 365 дней.

Регион: все сессии пользователя получают регион, который встречается первым в сессиях за прошедшие 365 дней. Если источник для расчета модели — Google Analytics, данные о регионе берутся из Google Analytics. Для кастомных событий и CRM — значение поля transaction_region.

Этап 2. Расчет вероятностей перехода между шагами воронки

Для расчета вероятностей все шаги конверсионной воронки, указанные в настройках модели атрибуции OWOX BI, плюс шаг входа на сайт — представляются в качестве исходов в цепи Маркова.

После этого происходит расчет вероятности перехода между этими исходами:image1.png

На картинке — упрощенный пример для лучшего понимания и наглядности. В реальных случаях переходов может быть намного больше, вплоть до полного графа.

Расчет происходит на нескольких множествах таких цепей на основе собранных свойств пользователя — тип (новый или вернувшийся), устройство и регион:

  1. Для каждой тройки свойств (тип пользователя, устройство, регион)
  2. Для каждой пары (тип пользователя, устройство)
  3. Для каждого устройства
  4. Глобально

Сначала проверяется уровень вероятности для каждой тройки свойств. Если на этом уровне достаточно данных, чтобы считать вероятность достоверной, то она и ложится в основу модели атрибуции.

Вероятность перехода считается достоверной, если доверительный интервал, рассчитанный по формуле

1.645*sqrt((a_actions-b_actions)/(a*b))

, равен значению меньше 0.1.

Если интервал больше 0.1, то проверяется следующий уровень вероятности — для каждой пары. И так далее.

Если данных недостаточно на всех уровнях, то в основу расчета модели ложится глобальная вероятность.

Этап 3. Сбор конверсий

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

Например, есть похожие цепочки, но в одной 30 просмотров карточки товаров, а в другой — 5. И в первом и во втором случае мы дадим одинаковую ценность (Value) для 30 событий в первом случае и 5 — в другом. Но каждое конкретное событие получит ценность Value/30 и Value/5.

Чтобы избежать таких ситуаций и правильного рассчитать ценность, OWOX BI выбирает среди этих событий только одно.

Так каждая конверсия и каждое событие в воронке связывается с ID сессии, в которой произошло самое раннее событие. Благодаря этому на этапе расчета ценности модель атрибуции подберет вероятность для каждого уникального события.

Этап 4. Расчет ценности

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

Пример:

  • Событие B произошло после события A
  • Эти события совершил пользователь со комбинацией свойств «устройство 'cross' + регион 'Home'»
  • У этого пользователя за последние 365 дней не было покупок. То есть свойство «тип пользователя» = 'New'

При расчете ценности используется вероятность именно для этих параметров:
S(b) = 1 - P(a, b, 'cross', 'Home', 'New').

Ценность транзакции для каждого события распределяется точно так же образом, как распределились баллы по событиям.

Для одинаковых событий ценность транзакции распределяется с помощью метода time-decay — чем ближе во времени событие к транзакции, тем больше ценности оно получит. Для этого достаточно знать ценность первого среди одинаковых событий — после этого ее можно атрибутировать всем остальным подобным событиям, которые относятся к этой же транзакции.

Была ли эта статья полезной?
Пользователи, считающие этот материал полезным: 0 из 0
Еще есть вопросы? Отправить запрос

0 Комментарии

Войдите в службу, чтобы оставить комментарий.