Build vs Buy для платформы A/B: красный флаг — выбирать по “красивому UI”, не по устройству экспериментов.
Ситуация знакомая: продукт “хочет запускать больше тестов”, аналитик “хочет доверять результатам”, а в итоге покупают тулзу или начинают пилить свою. Через пару месяцев выясняется, что метрики не сходятся, разрезов нет, рандомизация течёт, а любой нестандартный дизайн делается руками. Цена ошибки простая: вы платите дважды — деньгами и решениями, принятыми на шуме.
Почему так ломается: платформа экспериментов — это не экран “вариант А против Б”. Это контракт про единицу рандомизации, про то, как считаются метрики в разных окнах, как контролируются пересечения экспериментов, и как данные доходят до витрин без сюрпризов. Если контракт не сформулирован заранее, build превращается в вечный недострой, а buy — в вечные обходные пути.
Минимальный стандарт, который реально определяет выбор (дерево решений без романтики):
- Единица рандомизации и идентичность: user, device, session, household, account, merchant. Если нужна кросс-девайс склейка, гостевой трафик, офлайн-события или несколько идентификаторов одновременно — “просто купим и заведём флаг” обычно не взлетает без серьёзной интеграции.
- Метрики и разрезы: нужны ли удержание и LTV-окна, когорты, атрибуция, антифрод-фильтры, выручка с возвратами, метрики на уровне сущностей (заказ, продавец) и разрезы по продуктовым состояниям. Чем больше “условных” метрик, тем важнее единый слой определения метрик, а не отчёты в разных местах.
- Сложность экспериментов: sequential, CUPED/стратификация, кластеры, переключения, multi-cell, holdout, взаимные исключения, эксперименты на алгоритмах. Если это ваш план на год, платформа должна управлять конфликтами и дизайном, а не только логировать exposure.
- Интеграции и качество данных: где живёт assignment, как логируются exposures, есть ли guardrails по задержке и потерям, как это приезжает в DWH и BI. Если нет наблюдаемости и data quality на критических событиях, платформа будет “правой” только на демо-данных.
- SLA и комплаенс: права доступа, аудит, PII, региональность, ретеншн, инциденты. Если у вас жёсткие требования, “свой велосипед” становится не свободой, а обязательством 24 на 7.
Как выглядит правильная практика: сначала фиксируете контракт эксперимента (идентичность, assignment, окна метрик, конфликт-менеджмент, путь данных), потом выбираете, что закрывать покупкой, а что оставить себе как слой метрик и контроля качества. Обычно спорят про стоимость лицензии, но чаще всего дорого обходится поддержка: debug рандомизации, расхождения метрик, “почему в отчёте одно, в витрине другое”.
Граница применимости: если тесты редкие, метрики простые, а риск решений низкий, можно начать с минимального buy или лёгкого build вокруг флагов — но контракт всё равно нужен, иначе вы просто быстрее начнёте ошибаться.
