+16
Завершен

Этапы продаж в "Показателях" в аналитике

Георгий Соловьёв 5 лет назад обновлен Саид Даштиев 10 месяцев назад 18

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

Было бы здорово или самим эти группировки добавлять, или сделать интеграцию с этапами продаж в "Показателях".

Зачем? У меня общая воронка следующая: Заявка - записан на пробное занятие (вокал) - пришел на занятие - оплата. На данный момент у меня нет возможности понять "теплоту трафика", а так будет наглядно видно, что из Директа заявок много, дозвон (собственно запись) хорошая, но почему то не доходят до нас, а из инстаграмма, к примеру, конверсия в заявку ниже, зато доходят люди лучше. Таким образом можно будет просчитать стоимость отдельного взятого этапа продаж прям в системе Roistat, не прибегая к костылям в виде ручного переноса всех данных в эксель.

Аналитика

Ответ

Ответ
На рассмотрении

Георгий, правильно ли я понял, что вы бы хотели по сути увидеть конверсию в Заявку в определенном статусе из CRM?

Ответ
На рассмотрении

Георгий, правильно ли я понял, что вы бы хотели по сути увидеть конверсию в Заявку в определенном статусе из CRM?

+1

ПОДДЕРЖИВАЮ! Очень нужна сквозная аналитика всех промежуточных конверсий от приема лида до продажи! И даже от событий визита до лида и далее до продажи.


Идеальная сквозная аналитика должна позволять посчитать КОНВЕРСИЮ и СТОИМОСТЬ КОНВЕРСИИ по каждому этапу воронки. Это позволит выравнивать стоимость конверсий в событие или стоимость конверсий в статус воронки посредством коррекции ставок в Директе или других рекламных источниках.


Я вижу это так:

  1. В События автоматически (или полу-автоматически) добавляются события из истории сделок, типа "Перешел в статус онкретный статус из CRM}". Плюс - по API можно такие события из CRM слать в Roistat
  2. В Аналитике / в настройках числовых колонок / в секции События - нужно добавить показатели:
    1. {События} (конверсия в целевого пользователя),
    2. {События} (стоимость достижения целевого пользователя)
  3. В Аналитике / в настройках числовых колонок - должна быть группа "Статусы сделок из CRM" и для каждого конкретного статуса сделок нужно предлагать показатели:
    1. {Статус} (кол-во),
    2. {Статус} (конверсия из лида),
    3. {Статус} (конверсия из визита),
    4. {Статус} (стоимость статуса)
    5. {Статус} (потенциальная выручка)
  4. В настройках интеграции и статусов CRM можно сделать конструктор для пользовательских групп статусов (составных статусов), чтобы модно было объединять статусы с близким положением в воронке. Далее эти "составные статусы" можно будет использовать в Аналитике, как отдельный статус заявки/сделки.




На голосовании

В первом варианте реализации мы это видим как виджет воронка по статусам сделок из CRM.

Если Вы имеете в виду просто картинку воронки с числовыми показателями для разных статусов, то это малополезно (на мой взгляд). Какие из этого выводы сделать? Как сравнить разныне рекламные кампании и тексты объявлений? Без группировки по источникам никаких выводов нельзя будет сделать о том, как корректировать ставки или тексты объявлений.


А если я в аналитике будут видеть, что для клиентов, откликнувшихся на "Текст 1" стоимость достижения статуса "Замер" 5000 руб, а для "Текст 2" стоимость достижения "Замера" 1200 руб., то я сделаю полезный вывод - текст 2 - привлекает более активных клиентов. Нужно его оставить, а 1й отключить.


Подобную информацию можно получить уже сейчас с помощью отчета по объявлениям. Показатели CPL или CPO, чем не удобна такая реализация для решения вашей проблемы?

+1

Прочитайте внимательнее пожалуйста. Речь идет о стоимости достижения промежуточных статусов воронки, которые находятся между Лидом (CPL) и Покупкой (CPO). Например, это могут быть статусы: "Записался на замер", "Сделали замер", "Согласовали цену", "Приступили к работе".


CPO не подходит, поскольку продаж может быть недостаточно (в каком-то разрезе или вообще) для значимой статистики.

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

Оформлю позже отдельной темой про показатель Конверсии событий.

Поддерживаю, стоимость заявки (CPL) может быть высокой по одному рекламному каналу относительно других, но зато лучше конвертируются в следующие этапы. Мы занимаемся элитной недвижимостью, средний цикл сделки — 3 месяца, поэтому CPO можно анализировать только поквартально, нужны промежуточные метрики, конверсия в следующий этап продаж, стоимость этой конверсии. Возможно это добавить хотя бы полем в «Аналитике»? По сути, кол-во сделок в разных статусах вы и сейчас по API получаете.

Думаю, это актуально для любых бизнесов с длинным циклом.

Евгений, спасибо за описание. Нам задача понятна. Срок реализации такой доработки сейчас назвать не могу, задача стоит в планах.

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


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

Например мы занимаемся установкой фундаментов перед постройкой дома. 

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


1) Достаточно, чтобы отчете в аналитике можно было добавить свои показатели и это выглядело допустим таким образом:

визиты - заявки - записи на исследование - продажи


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

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

1.2. Конверсия в это количество сделок из предыдущего статуса - показатель выражается процентным соотношением из одного статуса в другой (в нашем случае это конверсия из "количества заявок" в "количество записей на исследование")

1.3. Стоимость каждой сделки в этом статусе - количественный показатель в денежном выражении (аналог CPC, CPL, CPO и т.д., в нашем случае это "стоимость одной записи на исследование")


И в текущий отчет аналитики мы сможем преобразовать в набор показателей слева направо (пример):
- Показы

- CTR

- Расходы

- CPC

- Визиты

- Конверсия в заявки

- CPL

- Записи на исследование

- Конверсия в записи

- Стоимость записи

- Количество сделок на этапе X

- Конверсия в сделки на этапе X

- Стоимость сделки на этапе Х

....................

- Продажи

- Конверсию в продажу

- CPO

- Выручка

- Себестоимость


Важно предусмотреть один момент: большинство CRM выдает текущий статус сделки, например если сделка уже на статусе "Согласование договора", то уже не отображается, что до этого она была на статусе "Запись на исследование", но чтобы корректно считалась конверсия с этапа на этап, нужно учитывать, что статусы меняются, а значит:
- либо статусы и их изменения должны где-то фиксироваться и видимо на стороне roistat, например как "события", откуда roistat при построении отчета сможет забирать информацию об устаревших статусах (которые были когда-то, но уже изменились)

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


Мы же говорим, что Roistat отличается от веб-аналитики тем, что можно считать по деньгам, но большой доле бизнеса это не удается наладить из-за длинного цикла сделки (особенно это касается b2b). Построение же подобной воронки в отчете позволит бизнесу видеть узкие места и расширять их, понимать на каком этапе отваливается большее количество клиентов и воздействовать на это. Это очень важный этап не веб-, а именно бизнес-аналитики!


2. Вообще можно сразу реализовать и возможность создавать свои показатели по своим формулам (но это уже сложнее).

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

Формулу можно задавать следующим образом: 

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

Таким образом: мы выбираем сначала показатель (из имеющихся в roistat), затем выбираем математическое действие (сложить, умножить, делить и т.д.), затем выбираем второй показатель, затем снова математическое действие, затем третий показатель, затем снова математическое действие и т.д., заканчиваться все должно показателем.

Либо это может выглядеть как формулы в excel. Тогда после введения формулы роистат должен проверять ее корректность и должен быть справочник по формулам.

Большое спасибо за развернутое описание. 


По первому пункту реализация может быть такой: 

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

Скажите, подходит ли такое решение?


По второму пункту задача сделать пользовательские метрики уже есть в планах на следующий год. 

Если я правильно понял, да.

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

Это как раз появится в рамках пользовательских метрик. Вы сможете сами составлять формулы из доступных метрик.

Очень важный функционал! поддерживаю!

Завершен

Реализовано в рамках специальных отчетов http://help.roistat.com/pages/viewpage.action?pageId=13500830, ветку закрываю

Сервис поддержки клиентов работает на платформе UserEcho