Чому спліт трафіку 50/50 в A/B тестах витрачає гроші на мертві офери і що з цим робити

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

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

Що не так з класичними A/B-тестами

Уявімо просту ситуацію, де тимлід дає команді два офери в одному гео, скажімо Бразилії. Команда залила $3 000 за три дні, розділивши трафік 50/50 у звичному трекері. У понеділок вранці тимлід бачить, що перший офер дав CR 2,5%, а другий – лише 0,8%. Тобто більшу частину часу, відведеного на тестовий пролив, другий офер просто палив бюджет, але отримував рівно половину трафіку, бо «тест ще не закінчився».

Половина $3 000, тобто $1 500, пішла туди, де результат було видно ще на другий день. Технічно команда нічого не порушила, так як тест був налаштований по всіх канонах роботи з кількома оферами одночасно. Просто сам підхід «спочатку зберемо стат-значущість, потім подивимось» у гемблінгу вже не працює як треба, бо вартість тесту росте швидше, ніж збирається сама статзначущість.

Щоб A/B-тест дав хоча б мінімально показовий результат, потрібно зібрати щонайменше 50 конверсій на кожен варіант. У випадку з гемблінгом при CR з кліку у FD близько 1-2% це означає 2 500-5 000 кліків на один варіант. Але якою ціною? Якщо навіть середня вартість кліку у тій же умовний Бразилії складає $1,5-2, то це вже $4 000-10 000 бюджету на нормальний тест двох оферів. А тепер помножте це на кількість тестів, які команда проводить щомісяця.

Очевидно, що ніхто не доводить тест до повного мінімуму «наосліп». Досвідчені тимліди бачать та оцінюють результати значно раніше. Цілком достатньо по 20-40 FD на кожен офер, коли різниця в CR click2dep вже візуально кричуща, наприклад, один офер показує 2,5%, а інший – 1% і нижче. Проте навіть до цього моменту половина бюджету вже була випалена на слабкому варіанті саме через те, що трекер сумлінно ділив трафік навпіл, поки тимлід не подивиться у звіт і не закриє тест вручну. 

Ба більше, така модель сплітів закладена в саму архітектуру звичних сервісів на кшталт Voluum, Bemob, Keitaro і подібних. Всі вони за замовчуванням пропонують саме рівний поділ або ручне встановлення відсотків, які треба моніторити і змінювати самому в режимі реального часу.

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

Динамічний розподіл трафіку

На противагу застарілому методу 50/50 існує підхід, заснований на розумних алгоритмах, відомих у теорії ігор як «задача про багаторукого бандита». Замість того, щоб сліпо ділити трафік порівну, система аналізує ефективність кожного варіанта в режимі реального часу і динамічно перерозподіляє трафік на користь найефективнішого. Найвідоміший конкретний алгоритм у цьому сімействі - Thompson sampling, який вже років десять використовується такими AdTech-гігантами, як Google і Netflix для рекомендаційних систем.

Система працює за простою логікою, яка складається з розвідки та експлуатації. Спочатку, на етапі «розвідки», алгоритм направляє невелику, рівну частку трафіку на всі офери, що тестуються, з метою збору первинних даних про ефективність кожного з них. Як тільки один з варіантів починає показувати вищий CR або, що більш точно, вищий дохід на клік (EPC), система переходить до фази «експлуатації».