Spotify: почему хороший эксперимент не обязан выиграть

Коротко

Ценность эксперимента задаётся тем, на какой вопрос он отвечает, а не знаком эффекта. Но «мы всё равно чему-то научились» работает при одном условии: критерий решения записан до того, как кто-то увидел цифры.

• Spotify разделяет win rate — долю тестов с положительным эффектом — и learning rate, долю тестов, после которых решение стало обоснованным.
• Пригодных исходов три: запустить, откатить и «эффекта нет, но мы бы его увидели».
• Третий существует только при достаточной мощности, причём по всем метрикам решения, а не по одной основной.
• Отрицательный результат экономит разработку ровно настолько, насколько гипотеза была сформулирована до старта и не менялась по ходу.
• Главные способы «выиграть» после факта: смена основной метрики, нарезка на сегменты, продление теста и пересказ провала как частичного успеха.
• Переносится не процент, а процедура: фиксация решения до старта, ревью и отдельная проверка мощности нейтрального результата.

Spotify считает не победы, а тесты, после которых решение стало обоснованным

В их формулировке эксперимент с обучением удовлетворяет двум условиям сразу. Валидность: механика раздачи и сбор данных отработали как задумано, числам можно верить. Пригодность для решения: результата достаточно для выбора, а не для ещё одного теста, который объяснит, что произошло.

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

Категория назначается не по знаку изменения, а по тому, хватает ли результата для выбора. Поэтому из обучения выпадает четвёртый случай, который в большинстве команд маскируется под нейтральный: метрики не сдвинулись, но данных было мало. Формально «не подтвердилось», фактически тест не состоялся.

64% против 12% — это не две оценки одной программы, а два разных вопроса

В статье Spotify приводит средний learning rate 64% при разбросе по командам от 16% до 76%, а для двух организаций, на которые приходится около 80% их экспериментов, называет learning rate порядка 64% при win rate около 12%. Примерно каждый восьмой тест двигает метрику в нужную сторону, и это нормальное соотношение для зрелой программы, а не признак слабых идей.

Такой порядок величин согласуется с тем, что публично рассказывают другие крупные продукты: доля тестов с положительным эффектом доходит до десятков процентов только там, где идеи проходят жёсткий отбор до запуска, а типичная картина ближе к одному успеху из десяти. Если строите процесс, а не отдельный тест, эти оценки подробно разобраны в книге Kohavi, Tang и Xu «Trustworthy Online Controlled Experiments».

Важнее самого числа разброс 16–76%. Он показывает, что learning rate измеряет не продукт, а дисциплину команды: как она выбирает гипотезы, считает выборку и закрывает тесты. Брать 64% как цель бессмысленно — у вашей программы свой потолок, и его задают трафик и число метрик в правиле решения.

Нейтральный результат становится знанием только после проверки мощности — по каждой метрике решения

«Разницы нет» и «мы бы разницу не увидели» выглядят в отчёте одинаково: интервал накрывает ноль, p-value больше порога. Отличает их только то, какой эффект тест был способен обнаружить. Если минимально значимый для бизнеса эффект — полтора процента конверсии, а интервал получился плюс-минус шесть, результат не говорит ничего ни в пользу идеи, ни против неё.

У Spotify это условие жёсткое: мощность требуется по всем релевантным метрикам, а исход «нейтрально, но данных недостаточно» в learning rate не попадает. Отсутствие эффекта неотличимо от неспособности его заметить, поэтому такой тест не даёт права на решение.

Практический вывод важнее формального. Если в правиле решения участвует guardrail, мощность нужна и по нему. «Удержание не просело» без расчёта означает ровно «выборки не хватило, чтобы увидеть просадку удержания», и под этой формулировкой в продукт уезжают тихие ухудшения. Guardrail обычно мельче основной метрики по ожидаемому эффекту, то есть требует больше данных, а не меньше. В статье 2024 года про решения по нескольким метрикам Spotify описывает то же через риски: вероятности ложноположительного и ложноотрицательного вывода планируются заранее, и вторую приходится корректировать на число guardrail-проверок.

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

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

Второй эффект — отрицательные результаты исчезают из памяти команды. Невыигравший тест не доводят до разбора: нет документа, нет решения, нет записи о проверенном механизме. Через полгода гипотезу предлагают заново, и теперь у неё нет даже противника в виде прошлого замера.

Третий — дробление. Одну идею запускают четырьмя вариантами оформления и объявляют успехом тот, который случайно дал значимый результат. Формально это один эксперимент, фактически — четыре проверки с одним порогом значимости и предсказуемо завышенной долей ложных находок.

Четыре способа выиграть после того, как результат уже получен

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

Разведочный анализ сам по себе полезен — он порождает следующие гипотезы. Проблема появляется, когда найденный в нём срез подаётся как результат проверки, хотя проверка этого среза не планировалась. У такого вывода статус идеи, и его нужно помечать как идею.

Подмена метрики видна в истории карточки, а не в отчёте

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

Нужны два технических условия. Карточка эксперимента хранится с историей изменений, а не перезаписывается: документ в репозитории, строка в реестре с временем правки, задача с логом. И в реестре есть отметка времени первого показа варианта пользователю, чтобы было с чем сравнивать.

Дальше проверка занимает минуту. Основная метрика, правило решения и список заранее объявленных срезов, изменённые позже первого показа, — не обязательно нарушение, но повод прочитать, что поменялось и почему. Чаще всего выясняется безобидное: уточнили определение метрики. Иногда — что тест начали читать раньше, чем собирались.

Гипотеза, после которой отрицательный результат что-то значит

Формулировка «новый экран онбординга повысит активацию» непригодна для отрицательного результата. Если активация не выросла, непонятно, что опровергнуто: экран, порядок шагов, сам тезис о влиянии онбординга или просто размер эффекта оказался меньше различимого. Любой из вариантов потом подойдёт для объяснения, а значит ни один не проверялся.

Рабочая гипотеза содержит механизм и наблюдаемое следствие этого механизма. Механизм — чем именно изменение действует: убирает шаг, снимает неопределённость, переносит выбор в другой момент. Следствие — какая промежуточная метрика сдвинется первой, если механизм работает. Эта пара делает провал информативным: промежуточная метрика не шевельнулась — отвергнут механизм, а не вся тема.

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

Решение записывается до старта, иначе оно будет придумано по результату

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

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

Spotify отмечает, что появление ревьюеров эксперимента заметно влияет на learning rate — и за счёт практики расчёта, и за счёт более строгого отбора идей. Малой команде это переносить почти ничего не стоит: достаточно, чтобы карточку перед запуском прочитал не автор гипотезы и задал три вопроса — какая метрика сдвинется первой, хватит ли трафика на эффект нужного размера, что делаем при нейтральном исходе. Если на третий вопрос ответа нет, тест лучше не запускать.

• Механизм и промежуточная метрика, которая сдвинется первой.
• Основная метрика: определение, знаменатель, окно.
• Guardrail: порог и причина, по которой порог такой.
• Минимальный эффект из экономики и размер выборки под него.
• Дата остановки и правила исключения данных.
• Действие при каждом исходе, включая «эффекта нет».
• Отметка времени, когда всё перечисленное зафиксировано.

Отрицательный результат измеряется в несделанной работе

Экономику теста удобно считать не в uplift, а в том, от чего он избавил. Пример условный, числа здесь не чьи-то опубликованные, а подстановка для арифметики: полная версия фичи — шесть человеко-недель плюс поддержка, прототип для теста — одна. Тест показал, что эффекта нужного размера нет, полную версию не стали делать, пять недель остались другим задачам.

У такой оценки есть условие: прототип проверял тот же механизм, что и полная версия. Если в тесте был упрощённый вариант без половины логики, отрицательный результат говорит про прототип, а не про идею, и «сэкономили пять недель» превращается в самообман. Это стоит держать в карточке отдельной строкой: чем тестовая реализация отличается от целевой.

На метрику обучения тоже нужен guardrail, иначе её начнут набивать

Любой показатель, ставший целью, обрастает способами получить его дешевле, чем задумано. Learning rate не исключение: можно объявлять обучением любой закрытый тест, не доводить до конца сложные эксперименты, занижать ожидаемый эффект, чтобы нейтральный результат всегда выглядел мощным.

Spotify оговаривает это прямо и перечисляет, за чем следит рядом с learning rate: чтобы сохранялась здоровая доля положительных результатов, чтобы тесты доводились до конца и чтобы размеры эффектов были определены, а оценки оставались надёжными. Конструкция та же, что внутри A/B-теста: основная метрика не принимается без набора проверок рядом.

Небольшой команде хватит двух ограничителей. Доля тестов, остановленных раньше расчётной даты: растёт — падает дисциплина. И доля нейтральных исходов, у которых минимальный эффект задан заранее, а не подогнан под полученный интервал, — без этого условия «нейтрально, но мощно» становится самым удобным исходом в программе.

Свой learning rate считается по реестру за один вечер

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

Классификацию фиксируйте в одном месте, иначе через квартал разные аналитики посчитают по-разному. В запросе ниже исходы сведены к четырём категориям из разбора выше, а обучением считаются запуск, откат и нейтральный результат при достаточной мощности по всем метрикам решения.

Смотреть надо не на общий процент, а на причины, по которым тесты выпадают из обучения. Преобладает «нейтрально при недостатке данных» — проблема в размере выборки и слишком мелких изменениях. «Настройка невалидна» — в инструментировании и проверке равномерности раздачи. «Решение не записано» — в процессе, и это самая дешёвая из трёх проблем.

with classified as (
  select
    e.experiment_id,
    e.team,
    case
      when not e.setup_valid                      then 'invalid_setup'
      when e.stopped_at < e.planned_stop_at       then 'stopped_early'
      when e.primary_effect_positive
       and not e.guardrail_breached               then 'ship'
      when e.guardrail_breached
        or e.primary_effect_negative              then 'abort'
      when e.all_decision_metrics_powered         then 'neutral_powered'
      else 'neutral_underpowered'
    end as outcome,
    e.decision_recorded
  from experiments as e
  where e.stopped_at >= date '2026-07-01'
    and e.stopped_at <  date '2026-10-01'
)
select
  outcome,
  count(*)                                           as experiments,
  count(*) filter (where decision_recorded)          as with_decision,
  round(100.0 * count(*) / sum(count(*)) over (), 1)  as share_pct
from classified
group by outcome
order by experiments desc;

-- learning rate = доля (ship + abort + neutral_powered),
-- у которых decision_recorded = true

Чего у вашего продукта нет и не будет: трафика, частоты и права на 64%

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

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

Не переносится сама цифра, сравнение команд по learning rate и привычка отвечать на любой вопрос A/B-тестом. На малом трафике разумнее меньше тестов и крупнее шаги, долгий holdout вместо серии коротких проверок, а часть вопросов закрывается наблюдением за поведением и интервью. Сравнение «до и после» и квазиэксперимент тоже допустимы, но у них своя оговорка: за эффект легко принять сезонность или совпавший релиз.

Вывод пишется так, чтобы его нашли через полгода

Итог эксперимента живёт дольше самого эксперимента, если записан как утверждение о пользователе, а не о варианте B. «Вариант B не выиграл» через полгода не говорит ничего. «Сокращение регистрации на один шаг не двигает активацию: доля брошенных регистраций упала на 4 п.п., активация осталась в пределах плюс-минус 1 п.п. при пороге 2 п.п.» — говорит, и именно это остановит повторную попытку.

Минимальный формат — пять строк. Какой механизм проверяли. Что измеряли и с каким порогом. Что получилось, с интервалом, а не одним числом. Какое решение приняли. Какой вопрос стал следующим по приоритету. Последняя строка и отличает отрицательный результат от потерянного квартала.

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

Что здесь факт, а что объяснение

Из публикаций Spotify взяты: критерий «эксперимент с обучением» и три пригодных для решения исхода, требование мощности по всем релевантным метрикам, отказ считать обучением нейтральный результат при недостатке данных, средний learning rate 64% при разбросе по командам 16–76%, win rate около 12% для двух организаций с основной массой экспериментов, набор показателей рядом с learning rate и наблюдение о влиянии ревьюеров. Их статья 2024 года про решения по нескольким метрикам описывает планирование рисков ложноположительного и ложноотрицательного вывода и поправку на число guardrail-проверок.

Объяснение, а не факт — всё остальное: механизмы подгонки, поле metric_locked_at, порядок ревью, счёт экономии в человеко-неделях и рекомендации для малого трафика. Это перенос их логики на команды без такой выборки и без платформы, и проверять его нужно на своих данных: публичная статья описывает правила одной компании и не знает ни вашего трафика, ни стоимости вашей разработки.