Коли класичні A/B-тести не підходять: досвід Kismia з використання switchback-методу

💡 Усі статті, обговорення, новини про продукти — в одному місці. Приєднуйтесь до Product спільноти!

Інтро

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

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

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

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

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

Контекст

Мережевий ефект

Мережевий ефект (network effect) — це явище, за якого цінність продукту або сервісу зростає зі збільшенням кількості його користувачів. Він виникає в продуктах, що функціонують як мережа — тобто система взаємопов’язаних користувачів, які взаємодіють один з одним. У такій мережі кожен новий учасник не просто додається до загальної кількості, а створює нові потенційні зв’язки та взаємодії для інших.

Саме ці зв’язки й формують цінність продукту. У соціальних мережах, таких як Instagram, це комунікація між людьми та обмін контентом. У маркетплейсах на кшталт Uber чи Airbnb — взаємодія між різними сторонами ринку: у випадку Uber це водії та люди, яким потрібно дістатися з пункту А в пункт Б, а у випадку Airbnb — орендодавці житла та туристи.

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

Експерименти за наявності мережевого ефекту

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

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

У соціальних мережах, таких як Facebook, новий алгоритм ранжування або новий формат постів для частини аудиторії змінює стрічку їхніх друзів — навіть якщо ті формально не беруть участі в тесті. У маркетплейсах на кшталт Uber зміни для частини водіїв впливають на ліквідність, час очікування та ціни для пасажирів поза тестом. У таких системах існує спільний «ринок взаємодій» і він не ділиться ізольовано.

У результаті виникає так званий spillover effect — коли контрольна група частково зазнає впливу через зміни в тестовій групі. Це порушує одну з ключових умов A/B-тестування — незалежність груп одна від одної.

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

Інший підхід — switchback experiment, коли нову логіку вмикають для всієї системи в певні періоди часу та порівнюють із контрольними періодами. Також застосовують квазіекспериментальні методи — наприклад, порівняння динаміки «до і після» з урахуванням трендів або зіставлення з подібними сегментами. У випадках, коли сплітування взагалі неможливе, використовують підхід causal impact — ефект оцінюється через прогноз очікуваної динаміки без змін і порівняння її з фактичною.

Сьогодні я хотів би поділитися нашим досвідом роботи з підходом switchback experiment.

Swithcback experiment

Switchback experiment — це тип експерименту, який часто застосовується в системах, де один і той самий користувач або об’єкт багаторазово отримує різні варіанти впровадження чи змін (наприклад, в A/B-тестуванні).

На відміну від класичного підходу, де кожному користувачу призначають один варіант на весь період експерименту, у switchback-підході система з часом перемикається між варіантами.

Time-unit — це одиниця тестування, прив’язана до певного інтервалу часу та сегмента, для якої визначається належність до контрольної або тестової групи. У класичному A/B-тесті цю роль виконує користувач. Тобто в межах одного time-unit усі користувачі мають однакову логіку, яка залежить лише від моменту часу та сегменту (в нашому випадку це регіони), для якого здійснюється підбір. Цей підхід застосовується в switchback-тестуванні, де чергування груп відбувається за часом, а не за юзером. Важливо, щоб сегменти були ізольованими — тобто не впливали один на одного.
Наявність різних ізольованих регіонів дозволяє збільшити кількість юнітів. Також варто зазначити, що сегментація залежить від продукту. У нашому випадку використовуються регіони, адже саме за цією ознакою ми можемо поділити користувачів на сегменти, що не впливають один на одного.

Стандартний t-тест, який зазвичай використовується для традиційних A/B-тестів, не рекомендується для експериментів з перемиканням. Одиниця аналізу на рівні користувача порушує вимогу до незалежних спостережень, оскільки один і той самий користувач може мати декілька груп за період тестування. Ми могли б розглядати кожен юніт як одиницю, але це, швидше за все, призведе до недостатньої потужності експерименту, оскільки загальна кількість одиниць буде низькою. Наприклад, 2-тижневий експеримент з 1-годинним вікном перемикання і 5 регіонами дасть нам лише 1680 одиниць. Цей метод вдалося знайти натрапивши на пейпер, що описував його реалізацію компанією doordash.

Експеримент

Після детального дослідження методу ми вирішили перевірити його життєздатність, провівши перший A/A-тест. Метою було спробувати порахувати метрики в логіці switchback-експерименту, а також оцінити статистичні показники.

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

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

Отже, ми дизайнили A/A switchback-тест, фактично реалізувавши розклад віддачі груп користувачам. Нашою гіпотезою полягала в тому, що при switchback-рандомізації середні значення ключових метрик у контрольних та тестових time-unit не мають статистично значущої різниці. В точці розподілу користувачів отримана група впливала на логіку роботи рекомендаційної системи, але оскільки це був A/A-тест, фактичних змін не було. Ми обрали часовий юніт тривалістю 1 година. Експеримент проводився в 6 замкнених регіонах. Щогодини юніт випадковим чином отримував значення групи. Тривалість експерименту — 2 тижні. Нижче — кілька ключових інсайтів і проблем, з якими ми стикнулися.

1. Ми зіткнулися з тим, що більшість наших агрегацій не підходять для швидкого розрахунку результатів switchback-експерименту. Значна частина даних агрегується поденно, а оскільки один юзер протягом дня може перебувати в кількох групах, для коректного підрахунку довелося писати кастомні скрипти. Це не було критично, але суттєво сповільнювало роботу. Логічним кроком було б збирати агрегації під такі експерименти за необхідними метриками.
2. Окремим викликом став розрахунок статистичних показників. Оскільки в даному сетапі одиниця в експерименті це часовий юніт, а не користувач, то ми маємо справу з малою кількістю спостережень.

Існує кілька підходів до розрахунку:

• для метрик із невідомим розподілом (наприклад, кількісних) можна використовувати bootstrap — він дозволяє отримати p-value та довірчий інтервал;
• для нормально розподілених метрик підійде парний t-test, суть якого полягає в порівнянні максимально схожих спостережень;
• також можливий підхід регресійного тестування.

У нашому випадку найкраще спрацювали перші два варіанти, проте ми продовжили рісьорчити й інші підходи.

• Окремої уваги заслуговує вибір довжини time-unit. Ми досліджували, чи не буде результат викривлюватися через те, що користувачі на стику юнітів можуть потрапляти як у поточний, так і в наступний юніт.

У результаті ми дійшли висновку, що годинний юніт є оптимальним балансом між:

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

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

Підсумки

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