Cossa: Как аналитика помогла клиенту получать на 20% больше физических лидов
eye

Автор кейса: Елена Березовская, руководитель отдела веб-аналитики в агентстве

Лена Б 1080.png

Руководитель отдела аналитики

Елена Березовская

Рассказываем Cossa, как размышления по поводу эффективности простой формы обратной связи на сайте привели к изменению бизнес-процессов.

cossa_picture.png

Бывало ли у вас так, что в отчётах маркетолога и менеджера по продажам число заявок из интернета сильно отличалось? Наверняка, да.

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

В этом кейсе вы узнаете, как мы предотвратили потерю 20% лидов, просто ответив на вопрос «Почему данные из разных отчётов не сходятся?».

Вводные

Клиент: телекоммуникации (молодой интернет-провайдер).

Время сотрудничества: 5 месяцев.

Задача

После замены формы для заказа услуги резко увеличилось расхождение количества достигнутых целей Google Analytics и фактических лидов в CRM клиента. Необходимо было определить причину такой проблемы.

Результат

  • Найдена и ликвидирована причина потери лидов.
  • На 20% увеличилось число продаж и довольных клиентов.
Проблема

Изначально на сайте клиента была размещена многошаговая форма для заказа услуги. Поскольку число входящих звонков значительно превосходило количество заполненных заявок с сайта, у нас появилось подозрение, что у пользователей не хватает терпения заполнять так много информации в форме.

Лена Б 1080.png

Руководитель отдела аналитики

Елена Березовская

Мы выдвинули гипотезу, что если текущую форму сократить, то число отправленных форм увеличится на 40% при падении числа звонков на 10%.

Затем мы решили проверить, как это будет работать на практике.

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

cossa_pic1.png График результатов анализа эффективности формы заказа услуги

На основании этого было решено сократить форму. Новая форма содержала всего 4 поля — номер телефона по заданной маске, ФИО, адрес и комментарий.

В результате после такого обновления число заявок на сайте выросло на 45%.

НО!

Всё было хорошо до тех пор, пока при сопоставлении данных о количестве заявок из СRM и Google Analytics мы не увидели расхождение более чем на 20% (при допустимом расхождении до 5%).

cossa_pic2.png Число лидов, отправленных с сайта в Google Analytics и СRM

Увидев этот график, мы стали искать причину.

Решение

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

Тогда мы решили проверить отправку данных. То есть ответить на вопрос, какие именно заявки не попадают в CRM.

Для этого мы создали отдельную таблицу, куда заявки отправлялись по тому же действию, которое отправляет данные о действии в Google Analytics и в CRM колл-центра.

В результате получили следующие наборы данных:

  • обезличенные данные в Google Analytics;
  • данные во временной таблице;
  • данные в CRM.
cossa_pic3.jpg Схема передачи данных об отправке формы
Результат

Мы сравнили данные из разных источников и увидели, что в нашей «параллельной» таблице их больше.

Сопоставив данные в таблице с данными из CRM, получили список контактов, которых нет в CRM.

Проведя анализ тех контактов, которые не отправлялись, мы выяснили, что данные не отправляются в CRM в следующих случаях, если:

  • пользователь начинал вводить номер с +380;
  • у пользователя определённые коды операторов связи, например, номера, начинающиеся с 067;
  • также выяснилось, что основная потеря происходит с устройств с разрешением экрана менее 360×640, а это порядка 45% всех пользователей. Как оказалось, оповещение о неправильном заполнении поля выводилось над формой после клика по кнопке «Подтвердить отправку» и пользователи с маленьким разрешением экрана просто не замечали этого сообщения.
cossa_pic4.png Вид предупреждения об изменении формы

Было решено:

  • доработать проверку правильности ввода номера;
  • перенести комментарий о неправильном вводе к соответствующему полю:
cossa_pic5.png Вид предупреждения после изменения формы

  • сделать неактивной кнопку отправки данных до тех пор, пока данные не введены верно.

Такое обновление позволило нам предотвратить потерю 20% заявок от пользователей.

cossa_pic6.png
Выводы

Выявление и решение проблемы показало, что:

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

Помните, важно не только предположить причину расхождения данных, но и подтвердить её существование. Гипотеза без подтверждения или опровержения — опасна, поскольку вводит в заблуждение и может привести к финансовым потерям.

Другие интересные статьи