Условие
У Aviasales есть метапоисковая воронка: юзер → поиск → билет → выбор партнёра → переход на сайт партнёра → покупка. За покупку партнёр платит комиссию.
К нам приходит новый потенциальный партнёр и хочет, чтобы мы добавили его в поисковую выдачу. Как оценить целесообразность добавления партнёра? Считаем, что в пределах разумного можем проводить любые эксперименты.
Решение
Подход
Метапоиск — это маркетплейс, где партнёры конкурируют за клик. Добавление нового партнёра — это не про прирост спроса, а про перераспределение кликов между партнёрами + потенциальное улучшение/ухудшение пользовательского опыта.
Декомпозиция вопроса:
- Перфоманс на уровне партнёра. Будет ли партнёр конвертить клики в покупки?
- Каннибализация. Не съест ли он клики/покупки у текущих партнёров с более высокой комиссией?
- Юнит-экономика. EPC (earnings per click) нового партнёра vs средневзвешенный EPC выдачи.
- Пользовательский опыт. Не ухудшится ли CTR/конверсия в покупку из-за того, что юзер «сорвался» у плохого партнёра и больше не вернётся?
- Стратегические соображения. Покрытие новых направлений / класса тарифов / гео.
Реализация — план эксперимента
Шаг 1. Тестовая закупка трафика без A/B (warm-up). Сначала проверяем «сырые» метрики партнёра без полноценного тестирования: добавляем его в малую долю трафика (1–5%, либо отдельный сегмент — например, один город), смотрим:
- CTR ставки нового партнёра при равных условиях (не первая позиция).
- Conversion rate (CR) клик → покупка по техническим логам партнёра.
- Cancellation rate / refund rate. Высокие отмены = плохой партнёр.
- Технические гарды: timeouts, 5xx, latency ответа партнёра в нашем мете.
Если по этим базовым метрикам партнёр катастрофически плох — отказ без A/B.
Шаг 2. A/B-тест с рандомизацией по поисковой сессии.
- Контроль (A): текущая выдача без нового партнёра.
- Тест (B): выдача с включённым партнёром (естественная сортировка по цене, как у всех).
Декомпозиция метрик:
| Уровень | Метрика | Что показывает |
|---|---|---|
| Decision | Revenue per Search (RPS) | главное — стало больше денег с поиска или меньше |
| Decision | Comission per Search | то же, но в комиссии (если EPC партнёра ниже среднего, это поймает) |
| Funnel | CTR по партнёрам | каннибализация |
| Product | CR клик → покупка | качество партнёра |
| UX | Bounce rate, return-to-search rate | юзер сорвался и не вернулся? |
| Guardrail | Refunds, complaints | системные проблемы |
Шаг 3. Расчёт размера выборки и длительности.
RPS — непрерывная метрика с большой дисперсией (много нулей). Используйте CUPED или truncation хвостов, иначе MDE будет неподъёмным. Длительность — минимум 14 дней (недельная сезонность + bookings ≥ 30 дней до вылета).
Шаг 4. Анализ результатов и решение.
Решение принимаем по RPS (или прибыльной комиссии, если у партнёра она нестандартная) с учётом гардов и сегментов:
- RPS вырос статзначимо → выкатывать.
- RPS упал → не добавлять, проанализировать причины (каннибализация, плохой CR).
- RPS не изменился, но изменились пропорции → решение по стратегии (например, важно покрытие новых направлений).
Анализ / интерпретация
Главная ловушка — рассуждать только в терминах «партнёр приносит X кликов = X * EPC». Это валидно только если спрос фиксирован и партнёр приносит инкрементальные конверсии. На метапоиске обычно спрос не растёт от добавления партнёра — мы просто перераспределяем клики. Поэтому центральная метрика — это выручка с поиска, а не «выручка от партнёра».
Подводные камни
- «Партнёр платит больше комиссию = выгоднее». Если CR партнёра ниже, чем у текущего, итоговый EPC всё равно меньше. Считаем end-to-end.
- Каннибализация дорогих партнёров. Если новый партнёр забирает клики у партнёра с высокой комиссией, мы теряем деньги, даже если CTR общий вырос.
- Эффект новизны. Первые дни партнёр может «забрать» клики просто как «новенькая» опция — не делайте выводы на 1–2 днях.
- Sample Ratio Mismatch. Если рандомизация на уровне сессии и юзер видит обе ветки в разных сессиях — добавьте sticky assignment по
user_id. - Сегменты. Партнёр может быть хорош в Москве, плох в регионах. Сегментный анализ обязателен.
- Длинный конверсионный лаг. Покупка билета может произойти не в день клика — учитывайте окно атрибуции (3–7 дней).
- Дисперсия и MDE. RPS — heavy-tailed, считайте MDE с учётом реальной дисперсии и используйте CUPED/винзоризацию.
Альтернативы
- Multi-armed bandit вместо классического A/B: если партнёров много и хочется быстро находить лучшие.
- Контр-фактический анализ на исторических данных (если у нас есть API партнёра и можно «proxy» его выдачу) — дешевле, но менее надёжно.
Эталонный ответ
Решение — через A/B по поисковой сессии с decision-метрикой RPS / комиссия с поиска. Партнёра добавляем не как «инкрементальный канал», а как часть конкуренции в выдаче — поэтому проверяем именно совокупную выручку маркетплейса, а не только перформанс самого партнёра.