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 – аналитика на основе контактных данных. Пользователи объединяются в «персону», обладающую персональными данными.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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