Как «ломают» воронку продаж при построении отчётности

В одном из интервью Марк Твен сказал: «Есть три вида лжи: ложь, наглая ложь и статистика». Статистику и различного рода вычисления можно использовать, чтобы доказать правоту каждой из сторон конфликта, если посмотреть на ситуацию под нужным углом. Но в этой статье я хочу рассказать о непредумышленном создании бесполезных отчетов с воронками продаж.

Проблематика

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

Давайте разберем простой пример:

У нас есть три строки с данными о количестве купленных товаров и их цене.

Теперь посчитаем их общую стоимость. Для этого мы по очереди перемножаем количество каждого купленного товара на его цену, а уже потом суммируем получившееся значение в столбце «Стоимость».

Каким могло бы стать альтернативное решение?

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

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

Что такое воронки и зачем они строятся?

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

К нам на сайт пришел клиент по имени Вася, ему всё понравилось и он оформил заказ. После оформления заказа в CRM была создана сделка со статусом «Новый заказ». После этого сделка успела побывать на следующих этапах, и, когда заказ добрался до своего получателя, была с успехом закрыта.

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

Отлично, получается, что в нашем отчёте должна быть следующая информация:

Если всё так, то мы легко можем посчитать, что для этого клиента конверсия по переходам из одного этапа в другой была равна 100%. Может показаться странным считать конверсию на одном покупателе, но это важно, т. к. в большинстве случаев аналогичный отчёт по такому клиенту выглядит вот так:

Давайте разбираться, что же здесь произошло. Дело в том, что из CRM для клиента подгружается не вся история статусов его сделки, а только текущий этап.

Казалось бы, ну и что здесь такого? Если наша задача — посчитать количество успешных заказов, то ничего криминального. Но нам надо было контролировать конверсию между этапами и работать над её улучшением.

В нашем случае получается, что воронка формируется из данных, на основе которых она формироваться не может. Можно было бы сказать «Невозможное — возможно», но нет, это не тот случай, так не работает. Предлагаю рассмотреть ещё пару примеров, цель которых — объяснить, почему так делать неправильно.

Вернёмся к нашим этапам воронки. Когда речь идёт об одном человеке, то всё выглядит понятно, но как будут вести себя данные, когда добавится ещё хотя бы два потенциальных покупателя?

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

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

А как же сравнивать?

В том-то и дело, что никак. Точнее, сравнивать можно, но это будет сравнение одной кучи данных с другой кучей данных. С таким же успехом можно скачать отчёт из Google Analytics и свои личные расходы за месяц, чтобы попытаться найти какую-то связь.

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

Подведём итоги:

1. Прежде чем создавать любой отчёт/виджет, разберитесь с тем, как должны вести себя данные и будут ли они полезны в текущем варианте.
2. Фиксируйте все этапы сделки, если CRM не позволяет загружать все этапы — используйте webhook'и и сохраняйте статусы на своей стороне.
3. Сверьте информацию по сделке в CRM и в ваших отчётах. Данные по статусам и датам должны совпадать.
4. Не коллекционируйте бесполезный мусор, вникайте в данные и применяйте их на благо бизнеса.
5. Используйте инструменты сравнения, чтобы убедиться, что предложенные и внедрённые изменения благоприятно повлияли на конверсию по воронке.