Аналіз воронки конверсій: де інтернет-магазин втрачає покупців
Аналіз воронки конверсій починається не зі звіту, а з відновлення реального шляху покупця: як він потрапив на сайт, що переглядав, на якому кроці зупинився.
В інтернет-магазині на 1С-Бітрікс цей шлях розкладено за подіями — перегляд каталогу, додавання в кошик, перехід до оформлення, надсилання замовлення. Кожна подія фіксується, і за розривами між ними видно, де саме втрачаються гроші, а не де «щось не так з дизайном».
Типові точки обриву воронки на таких проєктах повторюються від магазину до магазину. Покупець наповнює кошик інтернет-магазину, але кидає його на кроці вибору доставки, бо не знайшов своє місто чи термін.
Інший доходить до форми замовлення й іде, коли система вимагає реєстрацію заради однієї покупки. Третій не проходить оплату, бо платіжний модуль повернув помилку, а сторінка про це промовчала.
Втрати на оформленні замовлення майже завжди концентруються в останніх двох кроках — там, де покупець уже готовий платити.
Окрема категорія — технічні обриви, які у звітах виглядають як «користувач передумав».
Повільна відповідь каталогу під час фільтрації, зірвана сесія, конфлікт кошика з кешуванням, неправильний розрахунок вартості доставки — усе це відсікає покупців до того, як вони побачать кнопку підтвердження. Конверсія в замовлення падає, але причина лежить не в маркетингу й не в цінах.
Саме тому аналіз воронки конверсій ми будуємо на наскрізних даних: пов'язуємо візити, дії в кошику, покинуті та завершені замовлення з технічними логами й налаштуваннями магазину.
Так видно, які точки обриву воронки дають основне зменшення і що з цього виправляється налаштуванням, а що потребує доопрацювання логіки оформлення. Далі розбираємо, як це закривається на проєктах під 1С-Бітрікс.
Що дає розбір воронки: ефект у цифрах
Розбір воронки починається не зі звіту, а з відновлення реального шляху покупця: які кроки він проходить від першого дотику до оплати, де саме зупиняється і що бачить у цей момент. У 1С-Бітрікс ці дані вже є — у подіях оформлення замовлення, кошику, історії статусів, логах оплат.
Ми збираємо їх в єдину картину, і вона майже завжди розходиться з тим, як процес уявляє собі бізнес.
Перший вимірюваний результат — зростання конверсії в замовлення. Коли видно, на якому кроці втрачається основна частка покупців, робота йде не «над сайтом загалом», а точково: прибираємо зайве поле, змінюємо порядок кроків, лагодимо сценарій оплати.
Частка завершених замовлень зростає не за рахунок більшого трафіку, а за рахунок тих, хто вже прийшов і був готовий купити.
Другий ефект — зниження відмов кошика та прискорення оформлення. Часто причина покинутого кошика технічна: повільний розрахунок доставки, помилка при застосуванні знижки, обов'язкова реєстрація, прихована вартість на останньому кроці.
Ми знаходимо ці місця за даними і знімаємо тертя — час оформлення скорочується, а кількість перерваних замовлень падає.
Третій — повторні покупки та середній чек. Воронка показує не лише втрати, а й поведінку тих, хто повернувся: що вони купують вдруге, які товари тягнуть за собою допродаж.
На цих даних будуються сценарії повернення та супутніх пропозицій, і середній чек зростає на вже наявній базі клієнтів.
Усі цифри вважаємо до змін і після, на однакових періодах і сегментах, щоб ефект було видно в динаміці, а не в разовій вигрузці.
Де саме рветься воронка на 1С-Битрикс
Воронка на 1С-Битрикс рветься не на етапі «клієнт передумав», а раніше — на рівні інфраструктури. Каталог із великою кількістю торгових пропозицій та багаторівневими властивостями починає віддавати сторінки за секунди, і частина відвідувачів іде, не дочекавшись відображення.
Метрика в цьому місці бреше: відмова виглядає як «не зацікавився», хоча людина фізично не побачила товар.
Другий типовий обрив — кошик. Помилки під час перерахунку знижок, невідповідність залишків із реальним складом, «товар недоступний» на останньому кроці оформлення. Клієнт уже пройшов вибір, додав позиції й отримав відмову — це найдорожча втрата, бо мотивація була максимальною.
Третій шар — зв'язка з обліковою системою. Обмін із 1С іде за розкладом, і між вивантаженнями ціни та наявність живуть у двох різних реальностях. Замовлення йде в обробку з неактуальними даними, менеджер передзвонює з вибаченнями, частина угод просто не доїжджає.
Окремо варто згадати втрату сесії: агресивне очищення cookie, конфлікт авторизації між піддоменами, скидання кошика під час перемикання пристрою. Людина повертається — а її замовлення порожнє.
Ми працюємо на 1С-Битрикс і бачимо ці обриви в логах, а не у звітах аналітики.
Дивимося час відповіді каталогу під навантаженням, журнали помилок кошика, розклад і логи обміну, поведінку сесій на різних сценаріях — і знаходимо, на якому кроці втрачається конкретний відсоток відвідувачів.
Способи збору даних: порівняння підходів
Спосіб збору визначає, які кроки воронки ви взагалі побачите. Вбудована веб-аналітика платформи швидко показує переходи за розділами каталогу та оформлення замовлення, але частина подій губиться: у неї своя сесійна модель, а дані лежать усередині системи.
Зовнішні лічильники дають наскрізну картину за каналами та рекламними мітками, однак ріжуться блокувальниками і не бачать, що відбувається на стороні сервера.
Серверні логи фіксують кожен запит без втрат, але не знають, хто саме прийшов, доки не зв'яжеш їх з ідентифікатором сесії.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Вбудовані засоби платформи | Швидкий старт, звітність за замовленнями та кошиком | Замкнуті всередині системи, обмежена сегментація, події губляться при кастомній логіці |
| Зовнішні лічильники | Оцінка каналів, рекламних міток, поведінки на сторінках | Блокувальники та відмова від відстеження занижують дані, розбіжність із замовленнями |
| Серверні логи | Аудит усіх запитів, розбір збоїв на кроках оплати | Немає прив'язки до користувача без склейки з сесією, великий обсяг сирих записів |
| Комбінований підхід | Магазини зі складною воронкою та кількома джерелами трафіку | Потребує єдиного ключа сесії та регулярної звірки джерел |
На практиці розбіжності між системами сягають двозначних відсотків, і рішення ухвалюють не за одним звітом, а за звіркою.
Ми зводимо події до спільного ідентифікатора сесії, зіставляємо замовлення з платформи із записами лічильників і логами, а розбіжності розбираємо за кроками: де саме губиться користувач — на фільтрах каталогу, в кошику чи на підтвердженні оплати.
Комбінований підхід дорожчий у налаштуванні, але саме він дає воронку, на яку можна спиратися при змінах. Якщо трафік іде з одного каналу, а воронка проста, вистачить вбудованих засобів із точковими доопрацюваннями — розбираємо, який набір закриє вашу задачу без зайвих шарів.
Як ми проводимо аудит воронки: етапи роботи
Аудит воронки починаємо не з гіпотез, а з фактів: знімаємо поточні метрики за кожним кроком — від входу на картку товару до оформлення замовлення. Дивимося, де саме втрачається частка користувачів: на фільтрах каталогу, у кошику, на формі доставки чи на етапі оплати. Без цих цифр будь-яка правка — це ставка навмання, а не інженерне рішення.
Далі працюємо за етапами, кожен завершується перевірюваним артефактом.
- Зняття метрик. Вивантажуємо дані із систем аналітики та журналів сервера, звіряємо цілі з реальними діями користувачів. На виході — карта воронки з конверсією за кожним кроком і точками обриву.
- Сегментація трафіку. Розділяємо відвідувачів за джерелами, пристроями та типом поведінки: новий покупець, повернення, покинутий кошик. Один і той самий крок може втрачати різні групи з різних причин.
- Побудова гіпотез. Формулюємо, що саме заважає переходу на наступний крок: повільна видача каталогу, зайві поля у формі, непрозора вартість доставки. У кожної гіпотези — метрика, за якою її перевіряємо.
- Пріоритизація. Відбираємо правки за співвідношенням впливу на конверсію та трудомісткості. Спершу те, що закриває великі втрати на верхніх кроках.
- Впровадження правок. Змінюємо шаблони, логіку кошика, порядок кроків оформлення, підключаємо кешування важких запитів. Кожна зміна — окремим релізом, щоб ефект був вимірюваний.
- Перевірка результату. Порівнюємо конверсію до і після на зіставному трафіку, відсікаємо сезонні коливання. Якщо правка не дала приросту — відкочуємо і повертаємося до гіпотез.
- Передача рекомендацій. Віддаємо карту воронки, список впроваджених змін і чергу наступних гіпотез з оцінкою очікуваного ефекту.
Такий цикл повторюємо: після кожного витка воронка звужується у вузьких місцях, а рішення спираються на заміри, а не на думки. Опишіть вашу задачу — повернемося з оцінкою та планом робіт.
Що ви отримуєте за підсумками аналізу
За підсумками аналізу ви отримуєте не абстрактні «рекомендації», а робочий комплект, з яким можна одразу йти в правки та в моніторинг.
Кожен артефакт закриває свою ділянку: один показує, де втрачаються гроші, другий — чому, третій — що робити, четвертий — як не втратити результат через місяць.
- Звіт по воронці — наскрізна картина за всіма етапами: від входу на сайт до оформленого замовлення, з конверсією кожного переходу та розбивкою за джерелами, пристроями й категоріями товарів. Видно не лише «де просіло», а й наскільки це відхилення від норми для вашого трафіку.
- Карта точок обриву — конкретні кроки, на яких користувачі йдуть: кошик, форма оформлення, вибір доставки, оплата. За кожною точкою — частка втрат і технічна причина: повільна видача, помилка валідації, неочевидний крок, обрив сесії.
- Список правок — пріоритезований перелік змін: що дасть ефект швидко й за малих трудовитрат, що потребує доопрацювання логіки або інтеграції з 1С. З оцінкою очікуваного приросту конверсії за кожним пунктом.
- Налаштовані звіти — готові зрізи в панелі: воронка за днями, порівняння періодів, звіт за покинутими кошиками, розріз за джерелами. Ви дивитеся їх самі, без вивантажень і ручного складання.
- Регламент моніторингу — документ із періодичністю перевірок, пороговими значеннями та списком відповідальних. Відхилення конверсії на задану величину — сигнал, а не відкриття через квартал.
- Схема даних — як події пов'язуються між сайтом, системами аналітики та обліковою системою, щоб цифри у звітах сходилися з фактичними замовленнями.
- Протокол перевірки гіпотез — порядок внесення правок і спосіб заміру результату, щоб відокремити реальний ефект від сезонних коливань.
Комплект передаємо з розбором: проходимо за кожним артефактом, пояснюємо логіку розрахунків і показуємо, як читати звіти далі самостійно. Опишіть задачу — повернемося з оцінкою та планом робіт.
Чим відрізняється аналіз воронки від наскрізної аналітики?
Аналіз воронки конверсій відповідає на питання «де саме губляться покупці всередині магазину». Ми розмічаємо етапи покупки — перегляд каталогу, додавання в кошик, початок оформлення, оплата — і рахуємо переходи між ними.
Вузьке місце видно одразу: якщо кошик кидають на кроці введення даних доставки, проблема у формі, а не в рекламі. Завдання аналізу тут локальні: прибрати тертя на конкретному кроці, спростити оформлення, полагодити фільтри.
Наскрізна аналітика дивиться ширше — на джерела трафіку та їхній внесок у виручку. Вона пов'язує рекламний канал із замовленням через весь ланцюжок дотиків: пошук, соцмережі, розсилки, повторні візити.
Питання ставиться інакше: який канал приводить покупців, а який спалює бюджет на тих, хто йде без покупки. Інструменти тут інші — системи веб-аналітики з інтеграцією рекламних кабінетів і облікових даних магазину.
Різниця підходів принципова. Воронка працює з поведінкою всередині сайту і не бачить, звідки прийшла людина. Наскрізна аналітика бачить джерело, але без розмітки етапів не покаже, на якому кроці канал втрачає клієнта.
Тому найсильніше вони працюють разом: наскрізна говорить, який канал варто масштабувати, а воронка — що в магазині заважає цьому каналу приносити виручку.
На практиці ми спочатку будуємо воронку за етапами покупки, знаходимо провали в оформленні й лише потім підключаємо наскрізну аналітику, щоб розподілити зусилля за джерелами трафіку.
Такий порядок економить час: лагодити рекламу безглуздо, поки кошик втрачає половину покупців на рівному місці.
Кейс: як зросла конверсія після усунення обривів
Що було до
Інтернет-магазин на 1С-Бітрікс з асортиментом у кілька тисяч позицій і живим трафіком. Аналітика показувала рівну картину: люди заходять, кладуть товари в кошик — і на цьому все.
Частка завершених замовлень трималася близько 1,2%, а з кожних десяти кошиків дев'ять залишалися покинутими. Оформлення займало в середньому 6 хвилин 40 секунд: покупець проходив через реєстрацію з підтвердженням, окремий крок доставки та оплату на останньому екрані.
Власник бачив лише підсумкову цифру продажів і списував провал на «слабкий трафік». Ми розклали воронку за кроками й побачили, що річ не в залученні: люди доходили до кошика, але не переживали оформлення.
Що змінили
Спочатку зібрали наскрізну воронку за подіями — від перегляду картки до підтвердженого замовлення, з розбивкою за джерелами та типами пристроїв. Обриви сконцентрувалися на двох переходах: між кошиком і формою даних та між вибором доставки й оплатою.
Далі працювали точково. Реєстрацію замінили на оформлення без обов'язкового акаунта — дані покупця зберігаються в замовленні, а обліковий запис створюється автоматично.
Кроки доставки й оплати звели на один екран, підтягнули збережені адреси та способи оплати, прибрали повторне введення. Кошик зробили редагованим прямо в процесі оформлення: правка кількості більше не викидає на попередній крок.
Окремо налаштували повернення покинутих кошиків — лист зі збереженим складом замовлення надходить через годину й повторно наступного дня.
Що стало
Частка завершених замовлень зросла з 1,2% до 2,1% — зростання конверсії майже вдвічі на тому самому трафіку. Середній час оформлення скоротився до 2 хвилин 10 секунд, а кількість покинутих кошиків на зіставному періоді впала приблизно на 40%.
Частину повернень дали листи: покупці, які пішли на етапі оплати, поверталися й доводили замовлення до кінця.
Результат впровадження тримається не на разовій правці, а на постійному циклі: воронка розкладена за кроками, у кожного переходу є метрика й власник, зміни перевіряються на частині трафіку. Такий контур дозволяє знаходити нові обриви до того, як вони з'їдять виручку.
Часті технічні сумніви
Збір даних для аналізу воронки конверсій майже завжди впирається в три технічні питання: чи не зламає це поточний магазин, чи витримає навантаження і чи не створить ризиків для персональних даних покупців. Нижче — як ми закриваємо кожен із цих сумнівів на практиці.
Чи сумісно це з поточними налаштуваннями магазину?
Так. Ми працюємо з подіями, які магазин уже генерує: оформлення замовлення, реєстрація, додавання в кошик, переходи за кроками оформлення. Складання воронки будується поверх наявної розмітки та модулів, без переписування логіки каталогу, кошика й оформлення замовлення.
Якщо частину подій не розмічено або розмічено частково — додаємо відсутні точки, не зачіпаючи робочі сценарії покупця.
Чи не зросте навантаження на сервер і чи не сповільниться сайт?
Збір подій відбувається асинхронно й не блокує віддачу сторінок: дані йдуть окремим потоком, а не в момент рендерингу каталогу.
Важкі звіти рахуються за агрегованими зрізами, а не за «сирими» логами на кожен запит, тому пікова відвідуваність не перетворюється на чергу запитів до бази. Профіль навантаження знімаємо до впровадження і після — порівнюємо час відгуку ключових сторінок.
Як забезпечується безпека даних покупців?
Персональні дані не залишають контур магазину у відкритому вигляді: в аналітику йдуть знеособлені ідентифікатори та події, а не імена, телефони й адреси. Доступ до звітів розмежовуємо за ролями — маркетинг бачить воронку, але не персональні дані. Усі зміни фіксуються в журналі, щоб було зрозуміло, хто і коли переглядав або вивантажував зріз.
Скільки триває впровадження і чи можна відкотитися?
Базову воронку збираємо ітераціями: спочатку ключові кроки оформлення замовлення, потім — вторинні сценарії. Кожен етап впроваджується окремо й перевіряється на реальному трафіку, тому проміжний результат видно вже після першої ітерації.
Відкат безпечний: збір подій вимикається незалежно від логіки магазину, а попередні налаштування зберігаються до підтвердження результату.
Обговоримо ваше завдання
Щоб повернутися з оцінкою та планом впровадження, нам потрібен контекст: як влаштований магазин зараз і де саме втрачаються покупці.
Аналіз воронки конверсій починається не зі звітів, а з вашого опису завдання — які кроки проходить клієнт від входу до оплати, на якому етапі помітний провал, що вже пробували змінювати. Чим конкретніші вхідні дані, тим точніша оцінка робіт і менше ітерацій на узгодження.
Опишіть завдання — і ми повернемося з планом впровадження, де буде видно, які дані знімаємо, які гіпотези перевіряємо і в якому порядку.
Якщо під час розбору знадобиться консультація інженера щодо спірного вузла — підключимо його до обговорення, щоб рішення спиралося на факти, а не на здогадки.
Що корисно надіслати в першому повідомленні:
- які кроки воронки вже розмічені і як рахується конверсія між ними;
- де, за вашими спостереженнями, основний провал — вхід, кошик, оформлення, оплата;
- які події фіксуються і чи є наскрізна аналітика за джерелами;
- як влаштовані кошик і оформлення замовлення, чи є покинуті кошики;
- які інтеграції зав'язані на замовлення — оплата, доставка, склад, CRM;
- що вже змінювали і який результат це дало;
- які обмеження за термінами і за доступами до систем.
Цього достатньо, щоб оцінити обсяг робіт і запропонувати план впровадження за етапами. Далі узгодимо порядок: спочатку знімаємо дані й перевіряємо гіпотези, потім вносимо зміни й заміряємо ефект на тих самих метриках. Опишіть поточну ситуацію — повернемося з оцінкою та планом.
