Session-based-аналитика должна умереть? Будущее за user-centric?

Недавно Алексей Никушин, организатор конференции «Матемаркетинг», в своем фейсбуке затеял знатный холивар на тему session-based и user-centric. Не смог промолчать и я, Игорь Кузин, CEO в smartanalytics.io и соавтор телеграм-канала #прокачайаналитику.

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

1. Event-based – аналитика на основе «ивентов». Я говорю «ивентов» не случайно. Дело в том, что «событие» на практике понимают зачастую как конкретную сущность в Google Analytics. На самом деле ивенты в GA – это и хиты, и, собственно, сами эти события, т.е. это строки в БД аналитической системы. Обычно 1 ивент – одна строка (т.е. просмотр 3х страниц и 1 клик по кнопке, это 4 строки в БД; далее будем говорить о событиях, как о синониме event’a).

2. Session-based – аналитика на основе сессий. Сессия (она же «визит» и «посещение») – это группа событий, объединенных по более-менее общепринятой логике. Основная логика в том, чтобы сгруппировать события, между которыми прошло менее 30 мин. и источник посещения один и тот же.

3. User-centric – аналитика на основе пользователей. Пользователь (он же «visitor») – это группа сессий, объединенных на основе куки. Сессии распределены во времени и, объединяя их, мы получаем своего рода профиль пользователя внутри аналитической системы.

4. Person-based – аналитика на основе контактных данных. Пользователи объединяются в «персону», обладающую персональными данными.

С понятийным аппаратом разобрались? Если нет, то читайте дальше, все прояснится!

Откуда есть пошла session-based аналитика

С тех пор, как поисковые и другие системы стали продавать рекламу с оплатой за клик, возник интерес к тому, что там происходит на сайте после этого самого клика (бородатые аналитики еще помнят термин «постклик анализ»). Но ведь рекламодатель не хочет покупать клики, он хочет, чтобы люди заходили к нему на сайт. Так вот такие «заходы на сайт», да простит меня профессиональное сообщество, и есть сессии.

Сессия в веб-аналитике – это сущность, наиболее близкая к клику по смыслу. На первый взгляд даже может показаться, что сессии и клики должны соответствовать 1:1. Но, на самом деле - нет. После клика может случиться обрыв соединения (например, из-за медленного мобильного интернета или снижения скорости загрузки страницы из-за пиковой нагрузки), или клик и вовсе может оказаться «фродовым». Или, наоборот, пользователь несколько раз кликнул по ссылке, что рекламная система, скорее всего, засчитает за один клик (получим 1 клик и N сессий).

А в чем замес-то? Или что не так с session-based аналитикой

Анализ, основанный на сессиях, в первую очередь, хорош тем, что он очень прост. Вот есть N кликов, вот +/-N сессий, вот некое $ за них уплачено. Все как бы понятно. Однако возникает много «но».

1. Глухая универсальность логики группировки ивентов в сессии. Все бизнесы разные, причесывая всех под одну гребенку, группировка неизбежно в неком % случаев будет неудачной. Другой аспект этой проблемы – это app+web. Сессии приложения и сессии на сайте выражают разные вещи, попытка универсализировать это пока, кажется, приводит к не самым лучшим последствиям.

2. Покупают не сессии, а люди. Информация о том, что пользователь не купил в некий конкретный визит малоинформативна, т.е. он мог вернуться и купить. В огромной доле бизнесов покупка не достигается в одно касание. Кроме того, на логике сессий строятся другие параметры и показатели. Например, конверсия. Фокус на такой конверсии, сформированой по логике сессий, может нанести ущерб бизнесу.

3. Эти самые люди используют разные устройства (кросс-девайс). Или даже находятся на сайте (в приложении) с разных устройств одновременно. В случае кросс-девайса показатель сессий также малоинформативен.

4. Как быть с офлайн-активностями людей? Стандартная логика сессий изначально ориентирована на веб и начинает ломаться при попытке охватить ею офлайн-коммуникации.

И все, всего 4 «претензии»? Да, пожалуй, все недостатки сэшн-бейсд аналитики можно объединить в эти четыре группы. А вот event-based, user-centric и person-based как раз позволяют решить эти проблемы.

Event-based VS session-based. Fight!

Event-based – это то, что нужно для продуктовой аналитики. Когда необходимо глубоко анализировать поведение пользователя внутри продукта, осознавать логику его поведения и пользования, то аналитика должна строиться вокруг событий. И не смотря на то, что сессия группирует ивенты, на практике данные о сессии – это, главным образом, данные первого хита (первого события, означающего попадание на некую конкретную страницу сайта или приложения). Сюда же клеятся источники-каналы, кампании и масса атрибутов, наследующих информацию о клике.

Кроме того, event-based предполагает получение детальных данных по ивентам, а значит, позволяет формировать собственную логику сессий и считать визиты так, как этого требует специфика бизнеса или бизнес-юнита. Это, собственно, и закрывает недостаток №1 session-based: универсальность логики группировки ивентов в сессии.

Стоит также заметить, что на практике системы аналитики, обеспечивающие event-based подход, также обладают возможностями user-centric и person-based (см. ниже).

Однако, когда речь заходит об омниканальном маркетинге, который предполагает серию касаний пользователя с различными источниками/каналами, то от понятия «сессия» уйти все-таки не удается. Да, мы можем использовать «первый хит», но, на самом деле, это не очень удобно с точки зрения DWH аналитических систем. Ведь сессия – это агрегат, а использование агрегатов существенно экономит ресурсы (селекты бегают по меньшему числу строк). Да, и помните, с чего мы начали историю о сэшн-бейсд? Да-да, с того, что это просто и доступно в том числе и диджитал-маркетологам, не погруженным глубоко в аналитику.

Session-based VS user-centric. Какие возможности открывает аналитика на основе данных о пользователях?

Кстати, вы заметили, что мы только-только, собственно, добрались до самого вопроса, заданного в самом начале? Отлично! Наконец-то мы готовы в этом разобраться.

User-centric подход предполагает, что мы группируем сессии в пользователей. Обычно делается это на основе куки, но объединять эффективнее, если мы можем сделать это на основе логина (это отлично удается, конечно, когда есть личный кабинет или что-нибудь вроде того; осюда, кстати, и берется «user» перед «centric»). И, конечно, мы можем использовать смешанную логику объединения сессий в пользователей.

Юзер-центрик закрывает главную боль сэшн-бейсд: №2 покупают люди, а не сессии. Пользователь покупает (в том числе и повторно) через серию сессий, распределенных во времени. И если даже привычные метрики начинать считать по пользователям, то результаты могут оказаться совершенно неожиданными. А управленческие решения, основанные на юзер-центрик данных, могут быть совершенно противоположными тем, что основаны на сэшн-бейсд.

Когорты – решение проблемы денег, распределенных во времени

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

Вкратце суть работы с когортами в маркетинге в том, что мы определяем группу пользователей, объединенных кроме привычных условий сегментации (вроде «пришел с яндекса» или «мобильные устройства») еще и неким временным интервалом. И затем отслеживаем динамику метрик по этой группе пользователей во времени. Примеры когорт в сквозной аналитике маркетинговых коммуникаций:

  • пользователи, пришедшие с поисковых РК яндекса в марте; отслеживать их будем в диапазоне с марта по август;

  • пользователи, пришедшие с мобильных устройств по facebook с кампании АВС 12 недель назад; отслеживать будем 12 недель;

  • пользователи, пришедшие с сетевой площадки XYZ Google, в этом месяце; отслеживать будем на протяжении 12 месяцев (да, так тоже можно).

Представим себе, что, например, в первой из этих когорт (пользователи, пришедшие с поисковых РК яндекса в марте) покупают, в основном, через 2 месяца после первой сессии. Session-based подход по умолчанию приведет нас к ошибочным выводам. Продаж за март почти не будет, а расходы будут. ROAS низкий, надо отключить такой трафик. НО! Если мы будем следить за этой группой пользователей в течение нескольких месяцев, то мы получим совершенно другие результаты!

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

Атрибуция – это session-based или user-centric?

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

Суть в том, что цепь сессий пользователя представлена различными источниками/каналам (кампаниями, таргетингами и прочими срезами). Как ответить на вопрос о том, какой источник/канал привел пользователя к покупке? Ведь в формировании решения о покупке участвовала сразу серия источников/каналов. Моделирование атрибуции предполагает, что надо распределить эту заслугу по-честному. Определить логику, по которой веса будут распределяться по этим касаниям, и представить ответ на вопрос «кто виноват» в виде простой и наглядной таблицы.

Логика распределения весов (модель атрибуции) может быть самой различной. Однако суть подхода остается неизменной – распределить «достижение» по сессиям.Для чего? Для того, чтобы строить привычные session-based отчеты.

Хм, а есть какие-то альтернативы моделированию атрибуции для омниканальной аналитики?

Вспомним наш исходный вопрос: «какой источник/канал привел пользователя к покупке»? Прежде, чем ответить на него, давайте посмотрим на один интересный феномен из квантовой механики.

Подсмотрено в фейсбуке у Никиты Широбокова. Свет одновременно состоит и из волн, и из частиц.

И на вопрос «какой источник/канал привел к пользователя к покупке» ответим «да»! К целевому действию привела вся совокупность шагов, так давайте оценивать эффективность всей этой совокупности.

Сгруппируем пользователей по их омниканальным паттернам, рассчитаем расход и доход для каждого паттерна и ROAS. Кстати, эти паттерны, объединяющие пользовательские группы, и будут когортами, т.е. будут 100% юзер-центрик подходом.

О таком подходе к аналитике, основанном на неатрибуциорованных пользовательских путях, мы рассказывали на конференции «Матемаркетинг 2019». Интересно, что первый фидбэк, который как правило приходит в голову, это что-то вроде «так это то же самое, что и в гугл аналитикс» (инструмент, показывающий цепи конверсий). Но, на самом деле, эти решения как метиловый и этиловый спирты – запах схожий, но эффект, мягко говоря, немного разнится. Инструмент GA не позволяет оценивать ROAS пользовательских путей, а, значит, не подходит для анализа в условиях омниканальности. Кстати, ROAS для пользовательского пути ~ LTV/CAC.

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

User-centric VS person-based

Персон-бейсд – это про контактные данные. Пользователи склеиваются на основе контактных данных. В принципе, это все, что надо знать об отличии user-centric от person-based. Это решает проблему №3 session-based аналитики, а именно -проблему кросс-девайса. Однако на практике выстроить DWH, успешно сочетающую в себе быстродействие, объединение больших массивов разрозненных записей и возможность перезаписи данных, которая необходима для реализации персон-бейсд логики, не так-то просто. И даже более того, это, скорее, разнонаправленные задачи.

Session-based: жить нельзя умереть (запятая по вкусу)

Давайте подведем итоги. Session-based – это большое упрощение действительности. Аналитика, построенная на таком упрощении, может нанести вред больший, чем полное ее отсутствие. Event-based, user-centric/person-based должны стать основой для принятия решений в маркетинге и управлении продуктом.

Однако, сессии – сущность, необходимая для аналитики. Да, здорово, если получается их кастомно генерировать. Да, значимость ее вообще невелика по отношению к таким метрикам, как ROAS, CAC, LTV. Однако, если мы вдруг решим исключить их из аналитики, то нам придется выдумать что-то другое, что по смыслу окажется... сессиями.

Вердикт: session-based подход должен умереть, но сессии должны остаться.

И да, если вам не нравятся сессии – не используйте их.

Читатель, если ты такой молодец и осилил статью до конца, то вот тебе бонус. В телеграм-канале #прокачайаналитику мы опубликуем решение №4 проблемы сэшн-бейсд: как быть с миром офлайна, ведь он не ложится на логику сессий.

0
20 комментариев
Написать комментарий...
Дмитрий Анпилогов

Супер! Было интересно! 

Ответить
Развернуть ветку
Roman Bednarsky

Алексей затронул важную тему.

Ссылка на конференцию:
https://matemarketing.ru/

Ответить
Развернуть ветку
Игорь Кузин
Автор

Успехов ММ2020!!!

Ответить
Развернуть ветку
Дмитрий Сильнов

А каким образом ROAS приравнивается к LTV? 
С моей точки зрения, это разные сущности, в том числе, с арифметической точки зрения.

Ответить
Развернуть ветку
Игорь Кузин
Автор

Дмитрий, спасибо, что обратили внимание! Действительно, в тексте была опечатка. Исправил на: "ROAS для пользовательского пути ~ LTV/CAC". Поясню в чем суть.

Группа пользователей, активности по которой показаны на скриншоте, это когорта (если дополнительно отфильтровать по условию "новый пользователь", то получится та самая когорта, с которой мы привыкли работать в рамках когортного анализа). Объем продаж для когорты — это LTV (тут вопрос в том, конечно, какой период брать; предполагается, что берем некий "довольно длинный"). CAC — расходы по когорте. В числителе ROAS на практике зачастую оказывается именно объем продаж, т.к. себестоимость из CRM клиент передает редко, по причине того, что себестоимость в CRM в основном и не подтягивается. Т.е. ROAS по когортам на практике — это, грубо говоря, соотношение продаж по когортам (LTV) и расходов по когортам (CAC). 

Ответить
Развернуть ветку
Дмитрий Сильнов

Спасибо!

Ответить
Развернуть ветку
Иван Гуляев

Пардон за чрезмерное упрощение и возможно глупый вопрос, но разве это не вопрос группировки данных/вращения измерений?

Ответить
Развернуть ветку
Игорь Кузин
Автор

Иван, спасибо за вопрос! Только я его, кажется, не совсем понял) Правильно ли я понимаю, что Вы считаете, что рассматриваемый вопрос, это вопрос уровня группировки данных и использования тех или иных метрик?

Ответить
Развернуть ветку
Alexey Laptev

Самый понятный вариант для сквозной аналитики User-centric без сессий.

Для базовой сквозной аналитики не важно сколько раз клиент зашел на сайт, он либо купил либо нет.

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

Ответить
Развернуть ветку
Игорь Кузин
Автор

Алексей, так ведь без сессий не поймем источник/канал и расход на пользователя.

Ответить
Развернуть ветку
Alexey Laptev

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

Ответить
Развернуть ветку
Игорь Кузин
Автор

Алексей, мне кажется, вот Вы как раз несколько путаете сессии и клики. Клики нельзя сгруппировать в пользователя, а вот сессии можно. Собственно, это как раз несколько выше описано.

Ответить
Развернуть ветку
Alexey Laptev

Зачем группировать? Источник берётся из клика по client Id в соотвествии с атрибуцией. Сессия это группа кликов в определённый период и смысла от факта для аналитики не очень много..

Ответить
Развернуть ветку
Игорь Кузин
Автор

Алексей, сохраню себе эту оригинальную точку зрения о том, что "сессия это группа кликов в определенный период". Назовем это click-based подход имени Алексея Лаптева)

Ответить
Развернуть ветку
Alexey Laptev

«Сеанс – это последовательность взаимодействий пользователя с веб-сайтом за указанный промежуток времени. «

Я то как раз оперирую стандартными понятиями, а не выдумываю своё )

Ответить
Развернуть ветку
Игорь Кузин
Автор

В данном случае "взаимодействия" — это хиты, а не клики

Ответить
Развернуть ветку
Alexey Laptev

Хит/клик/переход - это одно и тоже, как и сессия/визит. В разных сервисах к сожалению одни и тоже вещи называются по разному.

Ответить
Развернуть ветку
Игорь Кузин
Автор

Нет, хит — это переходы по страницам, события. Клик может вызывать сессию (а, значит, и хит), а может и нет.

Ответить
Развернуть ветку
Игорь Кузин
Автор

И да, кстати, об этом написано в статье)

Ответить
Развернуть ветку
Alexey Laptev

Океей, бесполезно спорить . Это все становиться очевидным когда знаешь на техническом уровне как это работает, напишу потом статью )

Ответить
Развернуть ветку
17 комментариев
Раскрывать всегда