Допомогли клієнтові отримати на 20% більше фізичних лідів
Автор кейсу: Олена Березовська, керівник відділу веб-аналітики в агентстві.
Клієнт. Телекомунікації (молодий інтернет-провайдер).
Тривалість співробітництва. 5 місяців.
Чи бувало у вас так, що в звітах маркетолога та менеджера з продажу число заявок з інтернету сильно відрізнялось? Напевно, так.
У цієї проблеми може бути багато причин, можна починати з тих, що пов’язані з різними методиками підрахунку, а закінчити банальними помилками під час маніпуляцій з підрахунками. Але, якою б не була причина розбіжності даних, головне, щоб вона не приводила до втрати реальних лідів.
У цьому кейсі ви дізнаєтеся, як ми запобігли втраті 20% лідів після відповіді на питання «Чому дані з різних звітів не сходяться?».
Завдання
Після заміни форми для замовлення послуги різко збільшилася розбіжність кількості досягнутих цілей Google Analytics і фактичних лідів в CRM клієнта. Необхідно було визначити причину такої проблеми.
Результат
- Знайдена і ліквідована причина втрати лідів.
- На 20% збільшилася кількість продажів і задоволених клієнтів.
Підключити послугу «АНАЛІТИКА» від ADINDEX →
Проблема
Спочатку на сайті клієнта була розміщена багатокрокова форма для замовлення послуги. Оскільки число вхідних дзвінків значно перевершувало кількість заповнених заявок з сайту, у нас виникла підозра, що у користувачів не вистачає терпіння заповнювати так багато інформації в формі.
Ми створили гіпотезу, що, якщо поточну форму скоротити, то число відправлених форм збільшиться на 40% під час падіння числа дзвінків на 10% водночас.
Потім ми вирішили перевірити, як це буде працювати на практиці.
Для цього налаштували відстеження переходу користувача від одного кроку до іншого під час оформлення заявки. У результаті з’ясували, що великий відсоток користувачів кидає оформлення заявки на другому з чотирьох етапів:
Графік результатів аналізу ефективності форми замовлення послуги
На підставі цього вирішено скоротити форму. Нова форма містила всього 4 поля – номер телефону, ПІБ, адреса і коментар.
У результаті, після такого поновлення, число заявок на сайті зросла на 45%.
АЛЕ!
Все було добре до тих пір, поки під час зіставлення даних про кількість заявок з СRM і Google Analytics ми не побачили розбіжність більш ніж на 20% (з допустимою розбіжністю до 5%).
Число лідів, відправлених з сайту в Google Analytics і СRM
Побачивши цей графік, ми стали шукати причину.
Рішення
В першу чергу ми перевірили правильність налаштування події і цілі Google Analytics, які відповідають за надсилання форми. Мета працювала коректно.
Тоді ми вирішили перевірити відправку даних. Тобто відповісти на питання, які саме заявки не потрапляють в CRM.
Для цього ми створили окрему таблицю, куди заявки відправлялися по тій же дії, що відправляє дані про дію в Google Analytics і в CRM колл-центру.
У результаті отримали такі набори даних:
- знеособлені дані в Google Analytics;
- дані в тимчасовій таблиці;
- дані в CRM.
Схема передачі даних про відправку форми
Результат
Ми порівняли дані з різних джерел і побачили, що в нашій «паралельній» таблиці їх більше.
Зіставивши дані в таблиці з даними з CRM, отримали список контактів, яких немає в CRM.
Провівши аналіз тих контактів, які не працювали у формі, ми з’ясували, що дані не відправляються в CRM в наступних випадках, якщо:
- користувач починав вводити номер з +380;
- у користувача певні коди операторів зв’язку, наприклад, номери, що починаються з 067;
- також з’ясувалося, що основна втрата відбувається з пристроїв з дозволом екрану менше 360 × 640, а це близько 45% усіх користувачів. Як виявилося, сповіщення про неправильно заповнені поля було над формою після кліка за кнопкою «Підтвердити відправку» і користувачі з маленьким дозволом екрану просто не помічали цього повідомлення.
Вид попередження про зміну форми
Було вирішено:
- Доопрацювати перевірку правильності введення номера;
- Перенести коментар про неправильне введення до відповідного поля:
Вигляд попередження після зміни форми
- Зробити неактивною кнопку відправки даних до тих пір, поки дані не будуть введені правильно.
Таке оновлення дозволило нам запобігти втраті 20% заявок від користувачів.
Висновки
Виявлення та вирішення проблеми показало, що:
- логіка збору даних завжди повинна бути прозорою;
- необхідно прописувати вимоги до якості даних;
- необхідний процес, який дозволяє знаходити втрати даних (наприклад, зіставлення кількості даних на різних етапах);
- якщо логіка збору даних або якісь невідповідності викликають у вас питання, не зупиняйтеся, поки не знайдете причину цього.
Пам’ятайте, важливо не тільки допустити причину розбіжності даних, але і підтвердити її існування. Гіпотеза без підтвердження або спростування – небезпечна, оскільки вводить в оману і може призвести до фінансових втрат.
