Малий трафік і A/B-тест: що перевірити, перш ніж шукати переможця

Шостий тиждень на сторінці працюють два варіанти. У першому заголовок обіцяє зрозумілий результат, у другому - докладніше пояснює послугу. У таблиці видно: у варіанта Б на дві заявки більше. Хтось уже пропонує закрити тест і переписати решту сайту за його зразком.

Але завтра одна заявка може прийти в інший варіант - і «перемога» зникне. Не тому, що команда щось зіпсувала. Просто за малої кількості звернень дані легко коливаються від випадку до випадку. Якщо назвати таке коливання доказом, процес починає керувати собою, як зламаний світлофор: усі дивляться на сигнал, але їхати безпечно від цього не стає.

A/B-тест - порівняння двох версій сторінки чи елемента, які випадково бачать різні відвідувачі. Він перевіряє одну припущену причину дії, а не допомагає вгадати красивіший заголовок.

Коли відвідувачів і заявок небагато, найгірші крайнощі схожі. Перша - місяцями не торкатися сторінки, бо «для тесту все одно мало даних». Друга - міняти все одразу й вірити кожній новій цифрі. В обох випадках ти не дізнаєшся, що саме допомогло або завадило.

Перехід від відвідування до звернення - не лише про кнопки. Зведи шлях людини, її запити, одну важливу проблему й послідовні перевірки до простого правила: запуск тесту сам по собі не є рішенням.

Почни з буденного речення: «На цій сторінці я хочу, щоб людина зробила ось це». Для B2B це може бути не тільки відправлена форма. Цільова дія - конкретний крок, який справді наближає розмову про роботу: запит прорахунку, бронювання консультації, завантаження технічного опису після залишення контактів. Якщо команда сперечається, що саме вважати успіхом, тест уже не має одного чесного запитання.

Від дії у звіті - до дії для бізнесу

Важливо не плутати зручну для звіту дію з корисною для бізнесу. Клік по номеру телефону може бути цінним спостереженням, але він не підтверджує розмову. Перегляд сторінки з цінами може свідчити про інтерес, але не дорівнює запиту. Визнач головну дію так, щоб після тесту ти міг пояснити, чому саме вона має значення. Тоді команда не сперечатиметься про цифру, яка просто найшвидше з’явилася в таблиці.

Припустімо, ти продаєш послуги для виробничих компаній. Якщо на сторінку приходять люди, які шукають постачальника, але форма надсилає подію після натискання кнопки, а не після успішного відправлення, ти вимірюєш намір натиснути, а не реальне звернення. Заголовок тут ні до чого: спочатку виправ точку вимірювання.

Інша ситуація: сторінка про складну послугу отримує мало заявок, зате частина людей переходить до калькулятора вимог. Такий ранній сигнал - дія, що логічно передує головному зверненню, - можна спостерігати окремо як допоміжну підказку. Але не називай його перемогою сторінки й не підміняй ним заявки. Він лише показує, де варто придивитися уважніше.

Конверсія - це зафіксована цільова дія відвідувача, наприклад успішно надіслана форма. Вона існує у звіті лише тоді, коли сайт правильно передав подію. Тому до висновку про сторінку перевір сам ланцюжок: людина виконала дію, сайт її зафіксував, система вимірювання отримала саме ту подію, яку ти очікуєш.

Measurement Protocol - спосіб передати подію до Google Analytics із сайту або сервера. До запуску в робочому середовищі перевір реалізацію та ключі події, щоб не отримати гарний, але хибний графік.

Практично це означає не «подивитися, чи є цифра». Візьми одне реальне тестове звернення й звір його шлях. Чи змінився екран після успішного надсилання? Чи спрацювала потрібна подія, а не клік по кнопці? Чи не відправляється вона двічі після оновлення сторінки? Чи її назва та параметри збігаються з тим, що показує звіт? Якщо на ці питання немає ясної відповіді, порівнювати варіанти зарано.

Порівняй не тільки події, а й шлях

Корисно також перевірити, чи не змінився сам шлях людини між варіантами. Наприклад, один варіант відкриває форму на сторінці, а інший веде на окремий екран. Переконайся, що успішне завершення фіксується в обох сценаріях однаково, інакше тест покаже різницю не в переконливості пропозиції, а в місці, де загубилася подія. Вимірювання - не технічна дрібниця: воно дає право робити висновок. На послузі аналітики можна побачити, чому рішення починається з того, що саме фіксується. А кейс відновлення відстеження конверсій показує: панель із цифрами не стане опорою, доки цільові дії не зібрані коректно.

Подивися також, хто приходить на сторінку. Якщо один варіант частіше бачать люди з рекламного оголошення про ціну, а інший - ті, хто шукає опис послуги, ти порівнюєш не лише сторінки. Ти порівнюєш різні очікування. У тесті обидві гілки мають отримувати відвідувачів випадково; інакше різниця може бути наслідком джерела переходу, а не зміни на сторінці.

Це не привід відмовлятися від реклами чи відкладати сторінку до «ідеального» часу. Просто перед висновком подивися, чи не змішалися в одному тесті різні повідомлення, кампанії або групи відвідувачів. Якщо змішалися, не роби висновок про заголовок. Спершу вирівняй порівняння або назви його обмеження в записі результату.

Гіпотеза - це перевірюване припущення про те, чому людина не робить потрібний крок і яка зміна може їй допомогти. Не «зробімо кнопку яскравішою», а, наприклад: «Людина не залишає запит, бо до форми не розуміє, які дані отримає у відповідь; якщо поруч коротко назвати склад відповіді, вона частіше дійде до відправлення».

Щоб така думка не була здогадом із наради, зведи її до кількох полів у звичайному документі:

• цільова дія, яку ти рахуєш;
• сторінка й група відвідувачів, для яких помітив проблему;
• спостереження: де людина зупиняється або що не розуміє;
• одна зміна, яку ти пропонуєш;
• очікуваний напрямок, але без обіцянки результату;
• спосіб перевірити, що подія зафіксована правильно.

Ці поля корисні не для паперу. Вони відсікають три різні проблеми, які часто змішують. Перша: люди не доходять до сторінки або приходять не з тим очікуванням - тоді дивись на повідомлення в рекламі та відповідність сторінки запиту. Друга: людина доходить, але не розуміє пропозицію або наступний крок - тоді працюй зі змістом сторінки. Третя: дія відбувається, але не потрапляє в дані - тоді не чіпай заголовок, доки не виправиш вимірювання.

Є й четверта ситуація: основна дія настільки рідкісна, що тест ще не може дати надійний висновок. Тут не потрібно вдавати, ніби проблема вирішиться новим кольором. Збережи основну ціль, порахуй потрібний обсяг для кожної гілки й подумай, який ранній крок справді передує їй. Ранній сигнал допоможе вчитися про шлях людини, але не замінить результату бізнесу.

Умовний приклад: ти бачиш, що відвідувачі читають умови послуги, але рідко переходять до форми. Це ще не означає, що текст поганий. Можливо, перед формою бракує пояснення, що станеться після запиту; можливо, джерело переходу обіцяє інше. Запиши, яке саме спостереження маєш, і вибери тільки одну причину для перевірки. Якщо водночас переписати заголовок, ціну, форму й рекламне оголошення, наступна цифра не скаже тобі, що спрацювало.

Корисно розділяти доказ і підказку. Запис дзвінка, відповідь менеджера або спостереження за діями на сторінці можуть підказати, що перевірити. Вони не доводять, що зміна сама по собі збільшила кількість звернень. Доказ причинного результату потребує чесного порівняння, у якому ти не змінив заразом ще п’ять речей.

Вибірка - це кількість відвідувачів або зафіксованих дій, на яких ти робиш висновок. Для A/B-тесту потрібний обсяг рахують окремо для кожної гілки ще до запуску. Він залежить від поточної частки цільових дій і від того, яку різницю ти хочеш бути здатним помітити. Універсального числа, яке підійде кожному сайту, немає.

Це не означає, що тобі треба самому будувати складні формули. Важливо зафіксувати дві речі перед стартом: який обсяг потрібен за обраним розрахунком і що ти зробиш, якщо він не набереться в прийнятному для бізнесу темпі. Наприклад, не будеш нескінченно тримати тест лише тому, що він уже запущений; повернешся до якості вимірювання, цільової дії або більш раннього сигналу.

Потрібний обсяг - не планова дата завершення. Він лише показує межу, після якої дані можуть дозволити сильніший висновок. Якщо потік відвідувачів малий, визначення переможця справді може тривати довше. Це не поломка тесту. Поломка починається тоді, коли команда підганяє правило під цифру, яка сьогодні їй подобається.

Статистична значущість - оцінка того, наскільки спостережена різниця може бути випадковим шумом. Вона допомагає не переплутати випадковість із результатом, але не дає стовідсоткової певності. Тому формулюй висновок за силою даних. «Варіант Б має обнадійливий ранній сигнал, але вибірки недостатньо» - чесніше й корисніше, ніж «Б переміг». Такий запис не гальмує роботу: він захищає наступне рішення від самовпевненої помилки.

Не зупиняйся на моменті, коли цифра виглядає приємно, і не продовжуй тест лише тому, що сьогодні вона неприємна. Обидва рішення мають спиратися на правило, яке ти визначив до читання результату. Інакше тест перевіряє не гіпотезу, а терпіння команди.

A/B-тест має сенс, коли в тебе є одна конкретна зміна, коректно зафіксована цільова дія, випадковий розподіл відвідувачів і розрахунок достатньої вибірки. Це не гарантує бажаного результату. Зате створює умови, за яких відповідь не буде схожа на прогноз погоди з вікна.

Якщо тест не набрав потрібних даних, це теж результат, але не поразка й не перемога. Зафіксуй, що саме перевірялося, які дані встигли зібратися, чи працювало вимірювання і чого даних не вистачило, щоб зробити сильний висновок. Тоді обери наступну дію відповідно до причини: уточни гіпотезу, перевір ранній крок, переглянь якість трафіку або відклади саме порівняння. Невизначеність не потрібно прикрашати - назви її так, щоб наступна людина в команді розуміла межу даних і не перетворила припущення на «доведений факт».

Перший крок простий: відкрий поточний тест або сторінку, яку хотів тестувати, і одним реченням запиши цільову дію. Потім перевір її на одному реальному проході від форми до звіту. Лише після цього є сенс сперечатися про переможця.