Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

А/Б-тести: як працювати з типовими помилками на старті

Мене звуть Сергій Гудков, я Product Manager у Preply та куратор у Projector. У цій статті я хочу поділитися типовими помилками, з якими стикаються новачки, коли впроваджують А/Б-тестування в компаніях. Це допоможе вам почати використовувати тестування швидше й без шкоди для бізнесу, а також заощадити час команди.

А/Б-тести — один з основних інструментів перевірки продуктових та маркетингових гіпотез. Свій перший тест я запустив у 2011 році. Тоді ми посперечалися з моїм керівником, чия ідея краща і принесе більше грошей бізнесу. У багатьох компаніях тести є обов’язковим етапом впровадження будь-якої зміни в продукт. Це дає змогу компаніям залишати в продукті лише те, що дійсно корисне для користувачів, партнерів та бізнесу.

Небезпечні гіпопотами

А/Б-тестування завжди починається з ідеї, що тестувати. Ідея стає гіпотезою, гіпотеза — реалізацією та тестом. Якість та основа гіпотези багато в чому закладають успіх експерименту. Своєю чергою, те, як команда вирішує, що тестувати, визначає успіх усього підходу.

HiPPO — це англійська абревіатура, яка означає «думка людини з найбільшою зарплатнею» (Highest Paid Person’s Opinion). По суті, це коли приходить керівник і каже, що краще знає, що треба робити, і вся команда просто повинна виконувати що сказано.

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

У реальному житті все відбувається приблизно так: приходить керівник і каже, що його сусід по дачній ділянці переглядав сайт або використовував продукт і дав кілька слушних порад. Нам обов’язково треба все запровадити, але через А/Б-тест. Для гіпотез немає реальних підстав, хоча ідеї звучать чудово. Так, ідея і гіпотеза — це не одне й те саме, але про це іншого разу. Сусід —— не представник цільової аудиторії. Експеримент програє.

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

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

Кілька років тому джуніор із сусідньої команди попросив дати йому якийсь простий А/Б-тест, щоб він спробував запустити самостійно. Я витяг для нього технічно найлегшу гіпотезу з беклогу. Керівник дізнався про це, коли розробник усе вже зробив і готовий був запускати. Гіпотеза керівнику зовсім не подобалася, але я все ж таки запустив експеримент на свій страх і ризик. Мені дуже пощастило, що через місяць тест виграв. Відтоді керівник лише пропонував свої гіпотези та просив пояснювати принципи пріоритезації, але ніколи більше не блокував наших тестів.

Копіювання кейсів інших компаній

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

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

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

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

Років чотири тому я працював у автомобільній тематиці, щось на кшталт маркетплейсу авто. До мене часом прилітали ідеї, взяті з сайтів автосалонів. Коли я не міг відбитися, ми змушені були тестувати ці ідеї. Нічого не вистрелило. Люди на інтерв’ю так і казали: «Якби мені це треба було, я пішов би в салон». Виходить, ми витрачали час та ресурси, тестуючи подібні речі.

Дострокове завершення тесту

В основі контрольованих експериментів лежить математика.

Уявіть, що ви підкидаєте монету десять разів. П’ять разів випадає герб, і п’ять —— копійка. Потім ви щось змінили — трохи підпиляли монету напилком. Далі кидаєте ще десять разів. Герб випадає шість разів. Що скажете? Чи таке трапляється? Скільки разів має випасти герб, щоб ви були впевнені, що з монетою щось не так, і герб випадає частіше?

У різних тестах та за різних умов використовують різні математичні методи. Але мета завжди однакова — зрозуміти, чи справді результати експерименту (герб випадав найчастіше) спричинені нашими змінами (ми підпиляли монетку).

Дострокове завершення тесту —— це коли ви кидаєте монетку три рази з десяти й несподівано три рази випадає герб. «Ось воно! Працює! Тепер монетка чарівна, завжди випадає герб». Відтак ви вирішуєте, що кидати ще сім разів, що залишилися, сенсу немає, і так вже все зрозуміло.

У бізнесу бажання завершити експеримент раніше дуже посилює сліпе бажання заробити чи уникнути втрат. Якщо помічають, що позитивна динаміка тримається кілька днів і що кожен день приносить +10% грошей, то навіщо продовжувати отримувати +10% тільки з половини трафіку, а не з усього? Аналогічно з втратами —— дуже боляче втрачати 10% щодня.

Погляньте на скриншот. Варіант 1 тут і зараз приносить на 20,6% більше. Імовірність перемоги —— 89%. Скільки ще ви хочете чекати та втрачати гроші?

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

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

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

Одна з найповчальніших історій сталася восени 2012 року. Ми швидко почали впроваджувати А/Б-тестування й запускали кілька тестів щотижня. У всіх була ейфорія, і результати переглядали кілька разів на день. Якщо позитивний тренд тримався кілька днів, то (ура-ура!) приймали рішення залишати зміни на сайті.

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

Ми вирішили відкотити всі зміни за останні два місяці. Через дві-три доби продажі повернулися на колишній рівень, а ми навчилися чекати на завершення тестів.

Знати результат заздалегідь

В А/Б-тестуванні можливі три варіанти результату:

  1. Зміни приносять користь.
  2. Зміни шкодять.
  3. Результати неоднозначні.

Що означає неоднозначні? Це коли експеримент не виграв і не програв. Стверджувати, що А і Б рівні, помилково. Ви можете кинути монету лише двічі. Чи достатньо цього, щоб перевірити, як спрацювало підпилювання монети?

Коли ви збираєтеся в магазин, то хочете в той чи інший спосіб переконатися, що у вас вистачить грошей на всі покупки, які збираєтеся зробити. Аналогічно слід робити й із експериментами.

Перш ніж вирішити розпочати розробку, необхідно розрахувати мінімальний ефект, який можна виявити (MDE — Minimum Detectable Effect). Наприклад, розрахунок MDE може показати, що будь-яке зростання на менше ніж 42% не буде значним. Тут варто запитати себе, чи віримо ми, що новий колір кнопки допоможе підняти продажі на 42%?

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

Розрахунок MDE є невіддільною частиною створення дизайну самого експерименту, де необхідно визначити, хто увійде до тесту, де відбуватиметься поділ аудиторії на групи тощо.

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

Спочатку ми планували виводити кількість заброньованих уроків за останню годину. Очевидно, що загальна кількість репетиторів, у яких забронювали уроки за останню годину, набагато менша, ніж тих, у кого бронювали уроки впродовж останніх 12, 24 або 48 годин.

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

Продовжувати не можна здатися

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

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

👍ПодобаєтьсяСподобалось7
До обраногоВ обраному2
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Що б порекомендували почитати по а/б тестам або курси якісь?

Багато чого різного є. На яке питання хотіли б знайти відповідь?

Хоча... є книга яку я рекомендую для оптимізації конверсії більше ніж для А/Б тестування, але там є розділ про тести и дуже гарно показана роль тестів як частини процессу.

«Добавьте в корзину. Ключевые принципы повышения конверсии веб-сайта» (978-5-91657-193-6) Дуже давно не зустрічав книгу в наявності, но бачив в Інтернеті можна скачати.

Наприклад, цікавили більш практичні питання типу як максималізувати кількість а/б тестів, які регулярно ганяються.

Дякую за книжку.

К сожалению пока таких не встречал.

А/Б-тесты — хороший инструмент в умелых руках

В умелых руках и ххх — балалайка. Вот только под понятием «умелые руки» в данном случае преполагается, что есть некий волшебный способ угадать, какая половина результатов полезна, а какая — неверна. С тем же успехом можно считать финансово эффективной рулетку в казино, вам просто нужны «умелые руки», знающие когда и на что поставить.

А правда в том, что А/Б тесты опасны тем же, чем и полезны: они тестируют только один фактор, но не зависимые. И что ещё опаснее, они не тестируют зависимость во времени, когда одно и то же воздействие оказывается одновременно и вредным, и полезным.

Пример: с точки зрения А/Б тестирования, героин — лучшее средство от простуды.

> что есть некий волшебный способ угадать, какая половина результатов полезна, а какая — неверна.
К сожалению, это правда, волшебного способа угадать нет. Потому и приходится тестировать. Если бы, да кабы, да такой волшебный метод существовал, то в А/Б тестировании не было бы никакой необходимости.

> И что ещё опаснее, они не тестируют зависимость во времени, когда одно и то же воздействие оказывается одновременно и вредным, и полезным.
Это зависит исключительно от дизайна самого эксперимента.

> Пример: с точки зрения А/Б тестирования, героин — лучшее средство от простуды.
Да, можно спроектировать тест так, что это окажется правдой. А можно спроектировать иначе. Как ответ зависит от вопроса, так же и результат теста зависит от гипотезы.

Вот и я так говорю, что без метаданных А/Б тестирование опасно. Оно даст результат близкий к просто случайному. С героином всё верно — реально ж помогал, и его допустили в медицину, и всё ещё так делают, правда с его аналогами.

Что вы подразумеваете под метаданными в этом конкретном случае и почему без них тесты дадут результат близкий к случайному?

Что цель эксперимента — поиск источников зависимостей, а не просто удачного варианта. И гипотеза должна быть подкреплена теорией, ну или теоретической гипотезой, иначе просто огромен соблазн и легка возможность отсечь «неправильные» данные.

Пример из давнего прошлого: Приватбанк решил, что ради популяризации банковских карт обслуживать только тех клиентов, у которых есть карта. В том числе юридических лиц. Эксперимент был признан удачным — 70% согласились. А на деле это полная задница: ради непонятной выгоды потерять 30% клиентов на ровном месте.

Я бы не оценивал эксперименты других компаний. Просто потому что мы не знаем целей и условий.

Что цель эксперимента — поиск источников зависимостей, а не просто удачного варианта.

Здесь вы в корне не правы. Цель эксперимента именно в опровержении нулевой гипотезы, т.е. подтверждении, что связь между двумя событиями (изменение в варианте Б и изменение целевой метрики) есть.

И гипотеза должна быть подкреплена теорией

Я бы сказал желательно подкреплена, чем должна. Это поможет увеличить шансы успеха в эксперименте.

Я лишь пример привёл. Я не неправ не «в корне», а лишь с вашей точки зрения. Если ПРОДАВАТЬ услугу тестирования — то да, я не прав, так я слона не продам :)

А вот если извлекать пользу из самого теста, тут уже нужно 99% теории и/или опыта, и 1% практики. И чаще всего в практике нет необходимости.

Что дейстивтельно тяжело в АБ тестах: отслеживаение желательного и нежелательного результата. Он зачастую совсем не мгновенный, чёрта лысого вы дёшево протестируете АБ тестом по всей последовательности AIDA, ибо это потребует с высокой достоверностью отслеживать результат на каждом этапе.

Пример: ОБЕЩАНИЯ. Да, хорошее обещание может вызвать интерес. Но как только выясняется, что наврали с три короба, клиент уходит и больше не вернётся. В то же время, АБ тест показывает резкий рост числа переходов на одном из этапов воронки. И когда нет ни теории ни опыта, крыть такие результаты нечем, они получают время-деньги на своё повторение и развитие.

Я лишь пример привёл. Я не неправ не «в корне», а лишь с вашей точки зрения. Если ПРОДАВАТЬ услугу тестирования — то да, я не прав, так я слона не продам :)

Хорошо. «С моей точки зрения», А/Б тест — это метод статистической проверки, и дальше уже по определению это лишь опровержение нулевой гипотезы. Всё остальное — это как и зачем его использовать.

Абстрактный пример про AIDA звучит хорошо, но не убедительно, потому что вопрос в деталях: цели, ожидания, гипотеза, трафик, метрики, сама воронка и много чего другого.

Лично мне, это звучит как «а вот молоток плох в забивании шурупов...». Ну да, наверное молоток не самый лучший инструмент, да и к задаче «забивание шурупов» есть вопросы...

А/B тестирование допускает, что во время эксперимента состав трафика остается равномерным.

Если августе в интернет-магазине ради теста в меню категорию «детские товары» расположить выше, то это приведет к росту заказов. Но на отрезке это может показать обратный эффект.

Это само собой, А/B тест эффективен только на краткосрочном эксперименте, хотя бы потому что он дорог. Прежде всего дорог в организации, равно как и чреват ошибками сырых версий, от которых не избавиться, каждый новый тест — грабли.

Не веришь — купи что-нить на prom.ua, там вечно какие-нить сюрпризы. За последний год мне пришлось накатать 6 багрепортов. А за все годы до того — ни единого. И это при том что я там не частый гость. Угадай с одного раза, а публичен ли способ подать багрепорт :)

Простите, почему он дорог? Очевидно, что инструмент имеет стоимость, но почему дорог, а не дёшев, или приемлемая цена?

Я правильно прочитал, что баги на Проме за последний год, вы относите на А/Б тесты?

Когда интерфейс меняется до невменяемости каждую неделю, да, я считаю, что надо мной проводят эксперименты. Но запустить эксперимент много ума не надо, а вот чтобы это всё не распадалось как Плутоний 239 — тут уж надо времяденег.

Да, так и есть (скорее всего так и будет). Это решается на уровне гипотез: хотим ли мы тестировать что-то для детей в момент сезона «скоро в школу». Если хотим, то зачем? Какова гипотеза и т.д.

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Давайте тільки не «державною», а українською. Бо ДОУ це не державна інституція щоб вимагати використання державної мови. Натомість ми прагнемо розвивати україномовне середовище, правда ж?
Є одне але. Ступінь володіння українською мовою в усіх різна, тому якість текста і, як наслідок, легкість його сприйняття читачами може впасти (це я критично дивлюся на свої спроби писати довгі тексти українською). А редакторів та коректорів на ДОУ немає. Чи готові ми пожертвувати якістю?

Підписатись на коментарі