Конверсия — самая недооцененная и невезучая метрика: как неправильно считают конверсию и принимают неверные решения. Часть 2

Читайте в первой части статьи, почему конверсия часто кратно влияет на прибыль и стоимость привлечения.

Маркетолог сделал один вывод — и совершил сразу три ошибки

Маркетолог интернет-магазина оценивал эффективность платных каналов привлечения. Стоимость привлечения пользователя и средний чек в канал были примерно одинаковые. Поэтому маркетолог сконцентрировался на конверсии. У канала yandex / cpc «Коэффициент конверсии для цели 12» — 1,03%. У google / cpc — 0,87%. Вывод — канал yandex / cpc работает лучше, и мы правильно делаем, что покупаем там больше трафика.

Чтобы сравнить конверсию платных каналов привлечения, маркетолог открыл в Google Analytics «Коэффициент конверсии цели».

На основе этих данных нельзя принимать решения. Маркетолог сделал один вывод и совершил сразу три ошибки.

Первая ошибка
Маркетолог оценил конверсию, посчитанную по сессиям и получил значительное искажение.
Для рассчета «Коэффициента конверсии цели» GA использует сессии. Число сессии на пользователя — случайный параметр, который меняется от 1,1 до 2,3. Причем погрешность изменяется не только по источникам привлечения, лендингам и страницам, но и во времени. Сегодня на лендинге 1,5 сессии на человека, завтра — уже 2,1.

В этом примере в канале yandex / cpc на одного пользователя приходится 1,17 сессий. А в канале google / cpc — 1,79. Если посчитать конверсию по пользователям, в канале yandex / cpc она изменится на 1,21%, а в google / cpc — на 1,56%.

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

Вторая ошибка
GA не считает купивших пользователей. Для вычисления конверсии, он использует сессии, в которых случилась покупка. Пользователь покупает в среднем 1,1..2 раза. В результате, аналитик получает искаженные данные.

Например, пользователь купил букет цветов, закрыл сайт, а потом решил докупить ещё один букет, вазу или красивую упаковку. Когда пользователь вернулся на сайт, началась новая сессия, и GA записал новое событие. Конвертировался в покупку 1 человек, а GA записал 2 достижения цели.

Это искажение появилось потому, что GA считает сессии, в которых случилось хотя бы одно событие. Число сессий не равно числу событий, а число событий не равно числу пользователей. Команда Рика встречала сервис микротранзакций, в котором было больше 20 заказов на пользователя.

В среднем, один пользователь совершает 1,1..2 действия. Число событий на пользователя — тоже случайный параметр. Конверсия, из которой можно делать выводы, должна быть посчитана по пользователям.

В интернет-магазине в канале yandex / cpc 133 пользователя сделали 184 покупки. В канале google / cpc — 42 пользователя сделали 48 покупок. Посчитанная по пользователям конверсия снова изменилась.

Третья ошибка
GA записывает только одну покупку пользователя за сессию.
Некоторые пользователи заказывали 2+ букета цветов в течение одной сессии. Но GA считает сессии, в которых случилось хотя бы одно событие. Поэтому аналитика все равно записывала 1 «Достигнутый переход к цели 12». В результате, заказ попадал в CRM, но не записывался в GA. Число заказов в GA и CRM не сходилось.
GA записал 629 «Достигнутых переходов к цели 12», хотя на самом деле в CRM появилось 824 заявки со средним чеком 2 994 р. В результате, выручка в GA — 1 883 271, а в CRM — 2 467 056.

Т.к. GA не записал событие, нельзя определить ни лендинг, на котором оно произошло, ни канал привлечения, с которого пришел пользователь. А число покупок на 1 пользователя разное в разных каналах и на разных лендингах. Как незаписанные 195 покупок и выручка на 583 785 р. распределены по каналам, определить невозможно. И из-за этого невозможно определить ROI каналов и их эффективность.

Рик считает конверсию по пользователям. Он определяет пользователей по уникальному идентификатору ga_clientID, а транзакции или заявки импортирует из CRM. В CRM каждая транзакция имеет уникальный номер transactionID, зная который, можно отсеять дубли и транзакции с ошибками.

Рик связывает ga_clientID с transactionID и узнает, какие пользователи заказали или оплатили, из каких каналов эти пользователи пришли и какие страницы посетили. Зная число уникальных пользователей на сайте или в приложении и число уникальных пользователей с заказами или оплатами, Рик рассчитывает конверсию, на основе которой вы можете уверенно делать выводы и принимать решения.

Как неправильно интерпретировать даже верно посчитанную конверсию. И когда необходимо считать конверсию по когортам

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

Средний чек и стоимость привлечения пользователей на лендингах почти не отличались. Продакт рассчитал конверсию и сделал вывод, что конверсия пользователей в покупку на лендинге А — 1,02% значительно выше, чем конверсия на лендинге В — 0,69%. Значит, лендинг В нужно отключить, и направить трафик на лендинг А.

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

Продакт-менеджер упустил, что 28% пользователей на сайте были старые пользователи. У команды цветочного магазина был отлично отстроен email-маркетинг и ретаргетинг, и много пользователей возвращались. Конверсия в покупку старых пользователей была — 2,20%, а новых — 0,44%.

Старые пользователи уже познакомились с интерфейсом заказа цветов и правилами доставки. Поэтому конверсия в покупку у них гораздо выше.

Где в GA найти настоящий ретеншн и как построить когорты

Диаграмма Новые и вернувшиеся пользователи не показывает реальный ретеншн, потому что построена по сессиям. 21,3% вернувшихся пользователей — математическое вранье.

Настоящий ретеншн в GA можно увидеть в Audience → Cohort Analysis. Здесь ретеншн посчитан по пользователям. Можно увидеть, что ретеншн после первой недели — 3,67%.

И после первого месяца — 3,87%.

Чтобы построить когорты по пользователям и по доходу, нужно использовать запросы в API.

Два запроса свести вместе поможет Pivot Table. В dimensions4 мы храним уникальный идентификатор пользователя — ga_clientID, с его помощью мы строим когорты не по сессиям, а по пользователям. Определив количество уникальных пользователей и дату первой сессии каждого пользователя, мы построим начало когорты. Определив дату и размер транзакции пользователя, мы узнаем сколько выручки и когда принесла когорта.