UXPUB 🇺🇦 Дизайн-спільнота

Cover image for Продуктове А/Б тестування. Як не стати жертвою своєї впевненості у гіпотезі?
Oksana Nosenko
Oksana Nosenko

Опубліковано

Продуктове А/Б тестування. Як не стати жертвою своєї впевненості у гіпотезі?

Всім привіт! Мене звуть Оксана Носенко, я Head of Analytics в українській продуктовій компанії Jooble. І сьогодні я хочу зачепити тему А/Б тестування в компаніях.

Рано чи пізно компанії приходять до того, що будь-які зміни в продукті варто впроваджувати тільки після проведення А/Б експерименту.

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

Але коли компанія і продукт стають зрілішими, і виникає бажання “погратися” з візуальними елементами, впроваджувати невеликі зміни чи вибирати зі списку фічей найнеобхідніші для користувача, на допомогу приходить А/Б тестування.

А/Б тестування дає однозначні відповіді на запитання і не залишає місце для здогадів і припущень.

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

Запитань може бути дуже багато, і на жаль, дуже часто продакт овнери намагаються на них відповісти, користуючись своєю інтуїцією, а не довіряючи відповіді аудиторії свого продукту.

Чому довіряти нашій інтуїції чи нашому досвіду може бути погано для продукту

Чому довіряти нашій інтуїції чи нашому досвіду може бути погано для продукту?

  • Тому що ми, швидше за все, не ЦА нашого продукту.
  • Тому що ми упереджені та визнати помилку – це визнати втрату грошей, витрачених на експеримент.
  • Тому що для нас завжди тестований варіант виглядає оптимальнішим і кращим, не дарма ж ми його реалізували.
  • Тому що ми не знаємо, з якого вже існуючого функціоналу в продукті перехопимо увагу користувача на нові фічі.
  • Тому що 80% всіх експериментів зазвичай провальні, і тільки ґрунтуючись на даних ми можемо виловити ті 20%, що залишилися.
  • Тому що у нас може бути багато варіантів покращень, і варто дати можливість користувачеві вибрати найбільш підходящий для нього.

Припустимо, я вас переконала і ви все ж таки вирішили почати впроваджувати А/Б тестування у своїй компанії.

З чого почати АБ тестування

З чого почати А/Б тестування?

Дуже важливо підготувати технічну та аналітичну бази для тестування, поставленого на потік. Для того, щоб ваші А/Б гілки були рівномірними і рівнозначними, з технічного боку варто подбати про функціонал, який розбиватиме всю аудиторію продукту на рівні випадкові групи. Зазвичай, прив'язуються до cookie label у web, та device id у mob. Важливо, максимально точно визначити користувача і розбивати на гілки тестування саме користувача, а не, наприклад, його візити. Адже якщо відвідувач сьогодні побачить дефолтний функціонал, завтра - той, що тестується, а післязавтра знову дефолтний – враження від вашого продукту буде не дуже, а показники до того ж стануть нерелевантними.

На скільки гілок можна розбивати аудиторію? Тут все залежить від її обсягів, але я не рекомендувала б тестувати більше 3-4 груп у рамках одного експерименту. Звичайно, хочеться за раз провести тест з усіма можливими дизайнами, але це небезпечно тим, що тест доведеться тримати на продукті кілька місяців, поки збереться достатня кількість користувачів. Такий підхід не гнучкий і не дозволяє робити швидкі покращення. Дайте вашій команді дизайну проголосувати за запропоновані варіанти, і виберіть із 10 всього 3, які наберуть найбільше голосів.

Що відноситься до аналітичної бази? Ваша команда аналітики може підготувати інструменти, які дозволять бачити основні метрики продукту із розбивкою на тестові групи та експерименти. У такому разі у вас не буде необхідності наступного дня після запуску тесту нудитися в очікуванні хоч якихось показників і дошкуляти аналітика своїми "Ну як там?". Ви зможете вільно зайти в аналітичний інструмент і побачити основні показники самостійно. Звичайно, якийсь глибший аналіз доведеться почекати, але завдяки готовим інструментам ви зможете і самі розуміти успішний тест чи ні. Такий підхід дозволить проводити тести швидше та вдаватися до допомоги аналітиків лише за необхідності додаткових досліджень. А такі дослідження потрібні лише за масштабних тестів.

Які ще є заборони, які варто пам'ятати під час проведення експериментів

Які ще є заборони, які варто пам'ятати під час проведення експериментів?

  1. Не робити висновків завчасно. Найбільший біль аналітика, коли продакт овнер хоче застосовувати тест, не дочекавшись статистично значущих результатів. (Що це таке, можна почитати тут). Це зазвичай стосується звичайно експериментів, які в перші дні показують позитивну динаміку. Зростання показника навіть на +0.1% може підштовхнути продакт овнера до поспішних радісних висновків та поспішному рішенню застосувати тест на всій аудиторії. Найчастіше такі коливання нормальні, особливо в перші дні тесту, тому дуже важливо дочекатися потрібної кількості аудиторії у кожній гілці.

  2. Не запускати одночасно кілька експериментів, націлених на ту саму частину продукту. Уявіть, що одна команда тестує редизайн фільтра на сайті, інша – послідовність елементів фільтра, третя – місце, де цей фільтр розташовується. Якщо користувач потрапить у групу хоча б із двома змінами, його результати вже будуть неправильними. Дуже важливо відстежувати такі моменти і тестувати схожі експерименти або послідовно, або технічно розносити тести один від одного, щоб користувач міг потрапити лише на один змінений елемент.

  3. Не намагатись дати експерименту шанс. Дуже часто я стикалася з ситуацією, коли команда дочекалася потрібної кількості аудиторії, гілка, що тестується, показала не статистично значуще зростання (тобто закладений в експеримент показник покращився, але його поліпшення могло бути випадковим), але овнер тесту хоче застосовувати його зі словами: “У експерименту є потенціал”. Це помилкове судження, адже тестування показало, що новий функціонал ніяк не вплинув на метрики, тому чекати, що після його застосування на всю аудиторію, щось змінитися - неправильно.

  4. Не проводити 101 тест, націлений на одне й теж. У моїй практиці частенько були випадки, коли команда чи продакт овнер безнадійно намагаються покращити якусь частину продукту. Візьмемо, наприклад, дизайн листів. Ставалися ситуації, коли проводили по 5-6 тестів, націлених на поліпшення клікабельності якогось окремого листа, при цьому не отримуючи жодних позитивних результатів. У такому разі важливо вчасно зупинитися та перейти на іншу ініціативу. Адже якщо не вийшло з другого чи третього разу, швидше за все, якщо потенціал у покращенні і є, він незначний. Адже функціонал, який потребує поліпшення, піддається експериментам майже одразу. Якщо дизайн супер застарілий або неоптимальний, і ви намагаєтеся його змінити на більш актуальний, метрики не забаряться. Але якщо ваші спроби не увінчалися успіхом, можливо потенціал покращення тут невеликий.

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

Як зробити фінальне рішення щодо експерименту

Як зробити фінальне рішення щодо експерименту?

Насправді це не так просто, як здається. Теоретично, тест чи успішний чи ні. Усі метрики або яскраво горять зеленим, або жахливе мерехтять червоним. Але на практиці не все так однозначно – одна частина метрик може рости, інша – падати, а третя взагалі буде без змін. Тому важливо зробити правильне зважене фінальне рішення. Ще перед початком експерименту варто подумати, які показники ми хочемо покращити і насамперед при аналізі дивитися на них. Але важливо не забути про ключові або цільові показники компанії. Якщо ви покращуєте Activation своїм експериментом, але просідає Retention, а виростити Retention це поточна мета бізнесу, варто серйозно задуматися перед прийняттям тесту. Швидше за все, варто знайти причину в просіданні Retention і робити другу ітерацію. Фінальне рішення можуть ухвалювати різні люди. Найчастіше це продакт менеджет, CPO, керівник аналітики або овнер експерименту. Хто б це не був, якщо експеримент показує спірні результати, я раджу зібрати кілька спеціалістів та ухвалити спільно рішення.

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

Які ще моменти варто врахувати при А/Б тестуванні?

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

Сподіваюся, ця стаття допоможе вам трохи розібратися в темі А/Б тестування. Буду рада питанням!

Найстарші коментарі (0)