На 20% збільшили продаж за допомогою веб-аналітики за 5 місяців
Клієнт: Воля
Час співпраці: 5 місяців
Результат: На 20% збільшилася кількість продажу та задоволених клієнтів. Знайдено та ліквідовано причину втрати лідів.
Чи було у вас так, що у звітах маркетолога та менеджера з продажу кількість заявок з інтернету дуже відрізнялася? Напевно, так.
Ця проблема може мати багато причин, починаючи з тих, які пов’язані з різними методиками підрахунку, закінчуючи банальними помилками під час маніпуляцій з підрахунками. Але, якою б не була причина розбіжності даних, головне, щоб вона не призводила до втрати реальних лідів.
У цьому кейсі ви дізнаєтеся, як ми запобігли втраті 20% лідів, просто відповівши на запитання «Чому дані з різних звітів не сходяться?».
Завдання
Після заміни форми замовлення послуги різко збільшилася розбіжність кількості досягнутих цілей Google Analytics і фактичних лідів в CRM клієнта. Потрібно було встановити причину такої проблеми.
Проблема
Спочатку на сайті клієнта було розміщено багатокрокову форму для замовлення послуги. Оскільки кількість вхідних дзвінків значно перевищувала кількість заповнених заявок із сайту, у нас з’явилася підозра, що користувачі не мають терпіння заповнювати так багато інформації у формі.
Олена Березовська, керівник відділу аналітики
Ми створили гіпотезу, що за умови скорочення поточної форми, кількість відправлених відповідей збільшиться на 40%, водночас відбудеться падіння числа дзвінків на 10%. Потім ми вирішили перевірити, як це працюватиме на практиці.
Для цього налаштували відстеження переходу користувача від одного кроку до іншого під час оформлення заявки. У результаті з’ясувалося, що великий відсоток користувачів кидає оформлення заявки на другому з чотирьох етапів:
Графік аналізу результатів ефективності форми замовлення послуги
Підключити послугу «АНАЛІТИКА» від ADINDEX →
Було вирішено скоротити форму. Нова форма містила всього 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% заявок від користувачів.
Висновки
Виявлення та вирішення проблеми показало, що:
- логіка збору даних завжди має бути прозорою;
- необхідно прописувати вимоги щодо якості даних;
- необхідний процес, який дозволяє знаходити втрати даних (наприклад, зіставлення кількості даних на різних кроках);
- якщо логіка збору даних або якісь невідповідності викликають у вас питання, не зупиняйтеся, доки не знайдете причини цього.
Пам’ятайте, важливо не тільки з’ясувати причину розбіжності даних, а й підтвердити її існування. Гіпотеза без підтвердження чи спростування є небезпечною, оскільки вводить в оману і може призвести до фінансових втрат.
