Помилки A / B-тестування в AirBnB

    
Сьогодні на airbnb вийшов дуже цікавий пост про те, як вони роблять A / B-тести. Мені здалося, що переклад цієї статті буде цікавий Хаброжітелям, так як багато хто створює власні проекти, і методи аналізу airbnb як максимум можуть виявитися корисними, як мінімум дозволять задуматися про те, що непогано б тестувати метрики вашого продукту.
 
 
 Airbnb — це онлайн майданчик, на якій зустрічаються пропозиції людей з оренди будинків і запити людей, які шукають, де їм зупинитися в поїздці. Ми проводимо контрольовані експерименти, які дозволяють нам приймати рішення при розробці продукту, починаючи від дизайну і закінчуючи створенням алгоритмів. Це дуже важливо при формуванні зручності для користувача.
 
Принципи при проведення експериментів прості, але часто призводять до виявлення несподіваних підводних каменів. Іноді експерименти зупиняються занадто швидко. Інші, які не працюють на звичайній торговельній площадці, чомусь починають працювати на спеціалізованій типу airbnb. Ми сподіваємося, що наші результати допоможуть комусь уникнути підводних каменів і це дозволить вам робити краще дизайн, краще управляти, і проводити більш ефективні експерименти в ваших проектах.
 
 Навіщо експерименти?
 
Експерименти — простий спосіб зробити зрозумілий інтерфейс. Це часто несподівано складно — розповісти те, що ти робиш простою мовою, і подивіться що відбувається на першій ілюстрації:
 
 
Ілюстрація 1
 
Зовнішній світ сильно змінює продукт. Користувачі можуть вести себе по-різному в залежності від дня тижня, часу року, погоди (щодо нашого сервісу, або іншого туристичного проекту), або дізнаються про сервіс через рекламу, або органічно. Контрольовані експерименти ізолюють вплив на зміну продукту поки контролюються вищезгадані зовнішні фактори. На ілюстрації 2, ви можете побачити приклад нової фічі, яку ми тестували, але від якої відмовилися. Ми думали, що впровадимо новий спосіб вибору ціни, який буде приємний користувачеві, але отримали зменшення конверсії, тому відмовилися від неї.
 
 
Малюнок 2 — приклад нової фічі, яку ми тестували, але відмовилися
 
Коли ти тестіруешь поодинокі зміни типу цього, то методологія називається зазвичай A / B-тестування або спліт-тести. Цей пост не містить базової інформації про застосування A / B-тестів. Є кілька великих компаній, де ви можете знайти подібні сервіси. Наприклад, Gertrude , Etsy's Feature , and Facebook's PlanOut ,
 
 Тестування в AirBnb
 
У AirBnB ми створили власний A / B-фреймворк для тестування, в якому можливо запускати експерименти. Є кілька спеціальних фіч в нашому бізнесі, які тестуються більш ретельно, ніж звичайні зміни кольору кнопки і саме тому ми зробили власний фреймворк.
 
По-перше, користувачі можуть переглядати сайт, коли вони авторизовані або не авторизовані, що робить тестування досить складним. Люди часто переключаються між пристроями (між веб і мобільним) в проміжку між бронюванням. Також бронювання може зайняти кілька днів, і тому ми повинні чекати результати. У підсумку заявки і швидкі відгуки власників житла — фактори, які ми також хочемо контролювати.
 
Існує декілька варіацій при бронюванні. Спочатку, відвідувач користується пошуком. Потім зв'язується з орендодавцем. Потім орендодавець підтверджує заявку і потім гість бронює місце. На додаток у нас є варіації, які також можуть призводити до бронювання іншими шляхами — гість відразу бронює без зв'язку з хостером або може зробити запит на бронь відразу ж. Ці чотири візуально показані на малюнку 3. Ми об'єднали процес проходження цих кроків і загальну конверсію між пошуком і бронюванням, які є нашими основними показниками.
 
 
Малюнок 3 — приклад експериментів
 
 Як довго варто вести експерименти
 
Найбільший джерело плутанини в онлайн-експериментах полягає в тому, що ти не знаєш скільки часу ти повинен вести експеримент, щоб отримати результат. Проблема полягає в тому, що коли ви наївно використовуєте p-value , як критерій зупинки експерименту і покладаєтеся на ці результати. Якщо ж ви продовжуєте моніторити тест і результати P-value, то ви швидше за все побачите ефект. Інша загальна помилка — зупиняти експеримент занадто рано, до того, як ефект стає видним.
 
Тут приклад наших експериментів, які ми запускали. Ми тестували максимальне значення ціни, яка бере участь у фільтрі на пошукової сторінці, змінюючи його від $ 300 до $ 1000:
 
 
Ілюстрація 4 — Приклад тестування ціни у фільтрі
 
В ілюстрації 5 ми показуємо тест за часом. Верхній графік показує treatment effect , а знизу графік, що показує залежність p-value від часу. Як ви бачите, P-value перевищує 0.05 після 7 днів, в якому значення ефекту 4%. Якщо ми зупинили б експеримент там, то не отримали значних результатів, які отримали при бронюванні. Ми продовжили експеримент і дійшли до моменту, коли експеримент став нейтральним. Остаточний ефект був практично дорівнює нульовому p-значенню, сигналізуючи, що залишився тільки шум.
 
 
Ілюстрація 5 — результат залежності фільтра експерименту від часу
 
Чому ми не зупинили експеримент, коли p-значення дорівнювало 0.05? Виявляється, що в звичайних системах такого не відбувається. Для цього є кілька причин. Користувачі часто досить довго приймають рішення про замовлення і ранні замовлення занадто сильно впливають на початок експерименту.
 
Щоб отримати правильний результат ви повинні виконувати статистичний тест кожен раз, коли ви обчислюєте р-значення, і чим більше ви це робите, тим більше вірогідність того, щоб отримати ефект.
 
Звертаємо увагу, що люди, які близько працювали з сайтом могли помітити, що під час запуску тесту для максимального значення ціни effect був нейтральним. Ми виявили, що певні користувачі, які бронюють досить дорогі будинки, сильно не впливають на цю метрику, так як замовляють швидко.
 
Як довго експеримент повинен бути запущений, щоб запобігти негативні зміни? Краща практика полягає в тому, щоб запускати експерименти з мінімальними ефектами, які дозволять вирахувати розмір ефекту.
 
Існує момент, коли експеримент призводить до успіху або до невдачі, навіть коли ще не вийшло час. У разі фільтрації ціни приклад, який ми показали збільшення було першим досягненням, але графік не явно це показав, тому що криві не зійшлися. Ми знайшли цей момент дуже корисним, коли результати можуть бути не зовсім стабільними. Це важливо для дослідження і розробки важливих метрик, тому швидше розглядаючи одиночний результат з p-значенням.
 
Ми можемо використовувати цей приклад для ще більшого розуміння того, коли саме потрібно зупиняти експеримент. Це може бути корисно, якщо ви робите багато екперімент в один і той же час. Інтуїція підказує, що ви повинні бути недовірливі до будь першим результатам. Тому, коли результати занадто низькі спочатку — це нічого не означає.
 
 
Ілюстрація 6
 
Слід зауважити, що ця крива частково параметр нашої системи, який ми використовуємо в експериментах. Для вашого проекту будуть свої значення.
 
Друга пастка — аналіз результатів у загальному контексті. В основному практика оцінки успіху експерименту базується на одиночній метриці. Однак через це ви можете втратити масу цінної інформації.
 
Наведемо приклад. Останній рік ми провели за редизайном нашої пошукової сторінки. Пошук це фундаментальний компонент Airbnb. Це головний інтерфейс нашого продукту і найпряміший шлях захопити користувачів нашим сайтом. Тому так важливо зробити її правильною. На ілюстрації 7 ви можете побачити сторінку до і після змін. Новий дизайн містить більший розмір картинок велику карту, на якій показано, де розташовані об'єкти. Ви можете прочитати про зміни дизайну в іншому пості.
 
 
Ілюстрація 7
 
Багато роботи ми провели за цим проектом і ми думали і намагалися зробити дизайн якнайкраще, після чого захотіли оцінити наш дизайн за допомогою експерименту. Великою спокусою було запустити дизайн і показати його відразу всім, щоб не упустити маркетингову можливість. Однак, зібравшись з духом, спочатку ми протестували новий дизайн.
 
Після очікування достатньої кількості часу за методологією описаної вище, ми отримали результати. Зміни глобальних метрик були крихітними і p-значення сигналізувало про нульовий ефекті. Однак ми вирішили подивитися глибше на результати, щоб зрозуміти всі причини та наслідки. Ми знайшли, що новий дизайн був краще в більшості випадках, за винятком Internet Explorer. Потім ми вирішили, що новий дизайн ламає можливість кликати в старих версіях цього браузера, що значно вплинуло на результати. Коли ми поправили це, IE став показувати близькі результати до інших браузерам, показуючи підвищення в 2%.
 
 
Ілюстрація 8
 
Це навчило нас більш уважно ставитися нас до тестування в IE. Цей приклад добре ілюструє, що потрібно розбиратися в контексті тестування. Ви можете отримати низькі результати з безлічі причин схожими на версію браузера, країни і типу користувача. Звичайні фреймворки можуть просто не відобразити деяку специфіку, яку ви можете виявити, досліджуючи вручну. Ви можете безліч разів проганяти одні й ті ж тести, але в звичайно підсумку виявити маленьку річ, яка приведе до значного ефекту. Причиною цього може бути те, що ви запускаєте відразу безліч тестів, вважаючи, що вони всі працюють незалежно, але це не так. Одним із способів досягти цього — знизити p-значення до рівня, при якій ви вирішите, що ефект реальний. Детальніше про це можна почитати тут.
 
 Система повинна працювати
 
Третій і заключний підводний камінь на сьогодні полягає у припущенні, що система працює. Ви можете думати, що ваша система працює і експерименти проходять. Однак, система може не відображати реальності. Це може статися, якщо фреймворк пошкоджений, або ви використовуєте його неправильно. Один із способів оцінити систему і ваше токування їй полягає у формулюванні гіпотез і їх перевірки.
 
 
Ілюстрація 9
 
Інший спосіб поглянути на результати, які можуть здатися занадто хорошими, щоб бути правдою. Коли ви вивчаєте результати, схожі на ці, то хорошою практикою є спочатку їх уважно вивчити до того, як порахувати правдою.
 
Найпростіший приклад, коли treatment дорівнює контрольному значенню. Це називається A / A або фіктивні експерименти. В ідеальному світі система поверне нейтральні результати. Але що повертає ваша система? Ми запускали безліч експериментів схожих на ці (ілюстрація 9) і порівняємо припущення з результатами. В одному випадку ми запустили фіктивні експерименти.
 
Ви можете бачити, що в експериментах де контрольовані і treatments групи зі схожими розмірами, результати виглядають так.
 
Ілюстрація 10
 
 Висновок
 
Контрольовані експерименти — хороший спосіб для прийняття рішення при розробці продукту. Будемо сподіватися, що уроки, показані в цьому пості, допоможуть запобігти деякі помилки, що допускаються при A / B-тестуванні.
 
По-перше, кращий спосіб визначити як довго потрібно продовжувати експеримент, щоб робити висновки. Якщо система дає тобі ранні результати, ти можеш почати робити нестрогую оцінку або тренди повинні зійтися. Потрібно бути консервативним в даному сценарії.
 
Важливо дивитися результати в їх контексті. Розподіліть їх по осмисленим групам і спробуйте глибше їх зрозуміти. В основному, експерименти можуть бути гарною дискусією про те, як поліпшити продукт, швидше ніж почати агресивно оптимізувати продукт. Оптимізація не не можливе, але часто керуватися авантюристським поривом не варто. Фокусуючись на продукті ви можете обговорити і прийняти правильне рішення.
 
У закінченні потрібно бути на ти з вашою системою звітів. Якщо щось не виглядає правильним чи здається занадто гарним, щоб бути правдою, то вивчіть це. Найпростіший спосіб зробити це, запустити фіктивні тести, тому що будь-які знання про те, як система веде себе будуть корисні для розуміння результатів. У AirBnb ми знайшли достатню кількість помилок завдяки цьому.
 
 Джерело
    
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.