Learnings Library — база знаний и поиск похожих экспериментов

9.1 Цель

Библиотека экспериментов — это память команды: чтобы через полгода не запускать тот же эксперимент второй раз “как будто впервые”. Эксперименты заканчиваются, выводы теряются, команды повторяют одни и те же тесты. Нужна библиотека знаний, которая:

• сохраняет “что пробовали и чем закончилось”;
• помогает находить похожие эксперименты (по фиче/аудитории/метрикам/настройкам);
• ускоряет планирование новых экспериментов и снижает риск повторения ошибок.

9.2 Что хранится как “learning”

В истории: после завершения эксперимента продакт фиксирует “что пробовали, что получилось, что не получилось и почему”. Это потом экономит недели. Для каждого эксперимента (особенно при завершении) хранится структурированная запись:

• Гипотеза: что хотели улучшить и почему.
• Основная метрика: по какой метрике судим успех (например, доля конверсий).
• Использованные guardrails: какие пороги стояли.
• Результат:
  • победитель / отсутствие эффекта / ухудшение,
  • что сделали: rollout / rollback / продолжить/повторить.
• Контекст и сегмент:
  • «ключ флага», продуктовая зона (теги), таргетинг (в кратком виде),
  • платформа/страны/версии, если критично.
• Ссылки:
  • ссылка на report/дашборд,
  • ссылка на тикет/PRD (если есть).
• Заметки: короткие инсайты “почему так вышло”.

Минимальное ожидание: запись не должна быть “простынёй”, лучше 5–10 строк, но обязательная.

9.3 Поиск и фильтры

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

• полнотекстовый поиск (по названию, гипотезе, заметкам, тегам);
• фильтры: ключ флага, команда/владелец, статус результата, дата, страны/платформы, основная метрика.

9.4 “Найти похожие эксперименты”

В истории: продакт не хочет начинать с нуля — он открывает похожие кейсы и копирует рабочий шаблон (и наоборот — избегает повторения фейла).

9.4.1 Что считается похожестью

Система должна уметь предлагать список похожих экспериментов по комбинации признаков:

• тот же «ключ флага» или близкая функциональная зона (по тегам);
• схожие аудитории (похожие правило участия: страны/версии/платформа);
• схожий тип изменения (например, “алгоритм поиска”, “UI баннер”, “латентность‑чувствительное”);
• схожие метрики/guardrails;
• схожая структура вариантов (A/B/n, rollout, веса).
• иные варианты, которые считаются адекватными

9.4.2 Выход “похожих”

Для каждого найденного эксперимента показываются:

• краткий итог (rollout/rollback/no effect),
• эффект по основной метрике,
• риски (были ли guardrail triggers),
• ссылка на графики и learning‑summary.

Цель: перед запуском нового эксперимента PM видит “мы уже такое делали, вот чем закончилось”.

9.5 Качество данных библиотеки

Если библиотека превращается в помойку без тегов/описаний — она перестаёт работать. Поэтому качество “learnings” тоже нужно поддерживать.

• Изменения и редактирование learnings должны быть аудируемыми (кто/когда).
• Для экспериментов без заполненного learning показывать “пусто/нужно заполнить” и не давать закрыть процесс формально (если включена политика).

9.6 Пользовательские сценарии

• PM создаёт новый эксперимент → нажимает “похожие” → читает 3–5 релевантных кейсов → копирует удачный шаблон.
• Команда делает пост‑мортем guardrail trigger → быстро находит все эксперименты, где срабатывал «95-й перцентиль задержки».
• Новый сотрудник изучает “что делали по поиску за год” по ключ флага/тегу.