Всем привет! Меня зовут Анастасия Козлова, я Senior BI Analyst в маркетинге Skyeng. Сегодня хочу рассказать, как мы научились справедливо оценивать вклад каждого рекламного канала с помощью кастомной мультиканальной модели атрибуции, что нас к этому подтолкнуло и как мы её настроили технически. 

Skyeng — огромная платформа, мы провели уже более 50 миллионов уроков. Соответственно, через нашу базу проходит невероятное количество данных о пользователях, их касаниях и взаимодействиях с компанией, и всю эту маркетинговую информацию мы, конечно же, отслеживаем. Но до недавних пор у этого была и обратная (негативная) сторона.

«Аналитика — враг и отбирает у нас заявки»

Такой образ сложился у наших коллег из разных подразделений маркетинга из-за модели атрибуции Last Click, которой мы придерживались раньше.

Обычно Last Click работает так: если человек увидел десять реклам в разных каналах (Ютуб, рассылка, блогерская интеграция) и в итоге оставил заявку после десятой, то она атрибутируется этому десятому каналу. Для нашей атрибуции целевое действие — это именно заявка. Недавно мы попробовали атрибутировать сущность транзакции, но эта схема пока в процессе тестирования, так что сейчас мы разбираемся именно с заявками — всё привязывается к ним.

В нашем случае Last Click был не простой, а с приоритетом перформанс-каналов (в терминологии «Яндекс Метрики» — «последний значимый»).

Это значит, что было два вида источников трафика:

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

• Незначимые — органические переходы к нам на сайт, переходы с внутренних страниц.

Ещё одна важная вводная: несмотря на то, что для нашей атрибуции целевым действием была заявка, также был один нюанс, связанный с оплатой.

Например, пользователь знал о нас давно. Он вбил наше название в поисковике, перешёл на сайт и оставил заявку. Такая заявка определяется в канал органики. Но через несколько дней клиенту пришла рассылка с выгодным промокодом. Он оплатил пакет уроков, и… В этот момент заявка переместилась. В таком случае и заявка, и оплата попадают в канал CRM-маркетинга.

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

Это приводило к войне каналов: условно-бесплатные боролись с платными за то, что те постфактум отбирали у них заявки и оплаты. Особенно остро это ощущалось в конце месяца, если не выполнялись таргеты и какие-то каналы запускали акции на «догрев» пользователей, чтобы выполнить планы. Атрибуция становилась причиной невыполнения планов, а крайними во всём этом были мы, аналитики. 

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

Какие ещё модели атрибуции бывают?

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

• Последний переход — такая же логика, но есть два варианта модели: обычный последний переход и последний значимый переход. Второй вариант — это и есть та модель, которую мы использовали. В ситуации, когда у вас есть и бесплатные каналы, и платные, она применяется чаще.

Мультиканальные модели

• Линейная модель — заявка «делится» поровну между всеми каналами, которые участвовали в цепочке на пути к цели. 

• U-образная (или U-shape) модель — самый большой вес отводится первому и последнему касанию, всё остальное делится поровну между всеми остальными каналами.

• Модель атрибуции по времени — чем ближе мы к целевому действию, тем выше процентовка, которую мы отдаём каналу. 

На чём остановились мы?

Мы выбрали для себя что-то в духе U-образной модели, но с небольшими нюансами, которые касаются самого главного: как распределять «вес» между каналами.

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

• Первое касание: получает свой вес, потому что оно познакомило пользователя с нами.

• Последнее касание: получает свой вес, потому что оно привело к заявке.

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

Если каналы сработали в синергии — привели вместе больше, чем по отдельности, — то «лишний» процент мы поделим между ними. Если же каналы, наоборот, сработали в тандеме хуже — вычтем. Давайте посмотрим подробнее, как устроена эта математика справедливости.

Допустим, у нас есть 100 заявок и есть отдельные моноконверсии для каналов, А и Б.

Если мы говорим об их синергии, то у нас получается 18%, или 18 оплат. То есть тотал, который они привели вместе, больше, чем то, что они бы привели по отдельности. В этом случае мы берём разницу и просто делим её пополам. 

В обратной ситуации, когда мультиконверсия получается меньше, чем сумма моноконверсий, мы точно так же делим разницу — просто вычитаем её из каждого тотал-канала. 

Как это устроено технически?

Мы собираем вообще всю информацию о том, где пользователь побывал, — эта метрика известна вам как «визиты», но у нас называется «хиты». Внутри отчётов мы не пользуемся «Яндекс Метрикой», потому что у нас есть собственный JavaScript-код (под названием hit.Js, отсюда и имя метрики). Он установлен на всех наших сайтах и записывает всё: откуда пришёл клиент, когда оставил заявку, когда звонил, с какими метками переходил на страницы оплаты. Более того, здесь мы учитываем все акции, реферальные программы и даже данные о кешбэках от банков.

Зачем нужно домохозяйство?

Вся информация о пользователе у нас прошита единой ID, Skyeng ID, её внутреннее название — SEID. По ней мы можем идентифицировать пользователя: с каких он устройств заходил, к какому домохозяйству привязан и так далее. Своя инхаус-система на JavaScript позволяет нам отслеживать несемплированные данные. Казалось бы, у нас есть единая ID, можно пользоваться ей и сводить все посещения пользователя. Но у нас не один продукт, мы продаём не только английский для взрослых. Бывают ситуации, когда заявка оформлена на ребёнка, но при этом оставлял её родитель. В таком случае нам важно отследить полную картину по семье, чтобы обеспечить справедливое распределение метрик по каналам. И даже если пользователь зашёл к нам с телефона, потом с компьютера, а потом оставил заявку через приложение, SEID и ID домохозяйства свяжут все эти действия в один путь.

Все эти данные помогают составить грамотную картину о взаимодействии пользователя с нами и корректно распределить вес каждого канала, повлиявшего на решение пользователя оставить заявку/оплатить продукт.

Как хранить такой объём данных?

Чтобы старая LC-модель соседствовала с новой мультиканальной, потребовался глобальный рефакторинг. После семи месяцев работы над ним в нашем хранилище появилось 15 с лишним таблиц, которые соответствуют различным этапам сборки атрибуции. Например, сначала собираем все заявки и их атрибуты, потом связываем их с пользователями, потом крепим к домохозяйству и так далее. Такая многоступенчатость обусловлена тем, что обновлять весь этот массив полностью неудобно, долго и дорого. 

Суммарно было написано более 4000 строк SQL-кода, и теперь ежедневно за плюс-минус полтора часа у нас атрибутируются вчерашние заявки, а на основе этих данных потом обновляется ещё более 35 других отчётов. На выходе мы получаем подробную таблицу: в какой период была заявка, какой канал был первым касанием, какой — последним, сколько всего было касаний и какая доля (процентов заслуги) была у каждого из них.

Как во всём этом разобраться не аналитикам?

Теперь мы можем отследить конкретную долю и конкретное влияние каждого канала по каждой отдельной заявке. Но есть нюанс: в результате получился настолько тяжёлый датасет для отчёта, что им не только бизнес не понимал, как пользоваться, но и другие аналитики. Открываешь — а там стена текста, куча непонятных колонок, ещё и длинную инструкцию нужно изучать, чтобы хоть что-то понять. В общем, этот отчёт никто не смотрел. Оказалось, что мало сделать круто — нужно сделать ещё и понятно.

Вот что мы придумали:

• Упростить отчёт и сделать его максимально лаконичным.

• Показать Last Click и Multi-Touch рядом: теперь маркетологи видят свои цифры по старой модели и сразу рядом — по новой.

• Ввести метрику «Недооценённость»: это просто разница между показателями Last Click и Multi-Touch. Если она положительная, значит, канал недооценён и вносит больше вклада, чем кажется. Это стало понятным индикатором для оптимизации.

И теперь это работает так: мы отчитываемся по Last Click (так привычнее и проще), но оптимизируемся по Multi-Touch. Ребята из SEO, email-маркетинга, контент-маркетинга теперь видят реальный вклад своих усилий и могут доказать, что их работа приносит пользу. А бизнес понимает, куда уходят деньги, и может тратить их эффективнее. Мы, аналитики, тоже довольны, потому что создали сложную, но при этом оптимально собранную и очень полезную систему. А заявки больше не «переезжают» с канала на канал, и мир в Skyeng стал чуточку справедливее.

Спасибо за внимание! Надеюсь, эта история была полезной. Если у вас есть свои кейсы или вопросы, буду рада обсудить их в комментариях!