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

Недостоверные данные коллтрекинга при длинных продажах

Александр 8 years ago updated by Дмитрий 7 years ago 6

В ситуации с "длинными" продажами, когда продукт сложный и дорогой и требует много консультаций растянутых во времени, существенная доля клиентов звонит в компанию по нескольку раз на сохранившийся у них в телефоне ПОДМЕННЫЙ номер. В итоге, в текущей логике имеем существенную долю НЕДОСТОВЕРНЫХ фиксаций обращения в кампанию.

Пример:

Клиент1 позвонил по подменному номеру N, подумал полдня, и звонит по нему же позже или на след.день или в конце недели, в момент когда подменный номер N выдан уже другому новому Клиенту2 просматривающему сайт - в итоге фиксируется НЕДОСТОВЕРНОЕ обращение Клиента2.

В нашем конкретном случае доля таких "ошибок" за день бывает до 50% !!!
Просить каждого клиента перезаписать номер телефона - не серьёзно и муторно.

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


Предлагаю рассмотреть вариант прикрытия этой логической дыры системы:

Ищем в истории вызовов соответствие пары номеров входящего звонка: номер входящего + набранный подменный, если таковое совпадение найдено за последние N дней, то фиксируем данный вызов за уникальным номеров визита найденной пары номеров. N-дней - делать настраиваемым параметром, по умолчанию в 7 дней, у кого сделки ещё длиннее и требуют больших консультаций, поставит больший срок. Не панацея, но должно сильно снизить количество недостоверных данных.


Проблема СУЩЕСТВЕННА, в нашем случае делает систему коллтрекинга в текущей логике в принципе не дееспособной =((( Исправьте пожалуйста, хочется пользоваться всем остальным замечательным инструментарием!


Answer

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

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

Реализацию с поиском пары (номер звонящего - вызываемый номер) и присвоением правильного (первичного) номера визита планируем реализовать в будущем.

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

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

Реализацию с поиском пары (номер звонящего - вызываемый номер) и присвоением правильного (первичного) номера визита планируем реализовать в будущем.

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

Пришла в голову ещё одна идея, проще нежели "поиск пары", можно и по созданному Лиду делать точно такую же обработку: если Лид уже создан для этого номера, то просто не фиксировать конверсию для этого звонка, этот вариант уже не будет ресурсоёмким?

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

Если повторные звонки всё же влияют на данные, пожалуйста, опишите ситуацию более подробно.

Да, всё-таки у кого длинные сделки, это действительно существенно. У нас тоже длинные, могут 2-3 недели длится, а то и больше.

Решается по моему увеличением списка номеров. Главное, чтоб Роистат равномерно по всем раскидывал звонки)

С лидами тоже Нюас. Когда лид создали, в нашем случае он конвертируется в течении пары часов максимум, а затем может попасть в сделку. И задержка с выдачей номера актуальна пока сделка не завершится.

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

Хотя да. Если даже и есть заявки с этим номером, то они тогда будут без трекового номера роистата и мы всё равно не очистим данные таким образом.