Build vs Buy для платформы экспериментов: красный флаг — выбирать по “красивому UI” и цене лицензии

Типичная сцена: команда хочет “запустить A/B”, берёт готовый тул, через пару месяцев выясняется, что половина метрик не сходится, рандомизация не там, где нужно, разрезы не те, а “эксперименты” превращаются в бесконечные исключения. Цена ошибки не в деньгах, а в доверии: один раз обжёгся — и дальше любые результаты воспринимают как маркетинг.

Почему так ломается? Платформа экспериментов — это не кнопка “включить тест”. Это контракт между продуктом, данными и инфраструктурой: что именно считаем, на какой единице сравниваем, как атрибутируем события, где храним экспозиции, кто и как дебажит расхождения, какой SLA у расчётов и логов, и что будет при инциденте. Если этот контракт не совпадает с вашим продуктом, вы либо “допиливаете” чужое до неузнаваемости, либо строите костыли вокруг.

Минимальный стандарт в виде дерева решений выглядит так:

  1. Единица рандомизации и “липкость”. Если вам нужен не только user-level, но и device/session/account, плюс кросс-девайс и мердж идентификаторов — большинство коробок начнёт течь. Тут либо very careful buy с проверкой на реальных ID-цепочках, либо build.

  2. Метрики и разрезы. Если достаточно стандартных product-метрик и пары сегментов — buy обычно ок. Если нужны сложные атрибуции, долгие окна, частые пересчёты, разрезы “как в BI”, плюс единые определения метрик между командами — готовое решение часто упирается в “у нас так не поддерживается”.

  3. Сложность экспериментов. Мультивариантность, взаимные исключения, иерархии флагов, переключение между holdout и rollout, квази-эксперименты, sequential/triggered логика — это быстро превращает “простую” платформу в продукт внутри продукта. Если это ваш ежедневный хлеб, build начинает выглядеть рациональнее.

  4. Интеграции и наблюдаемость. Нужны событие экспозиции в трекинге, консистентность в DWH, нормальный дебаг “почему пользователь попал в ветку”, алерты на Sample Ratio Mismatch и data quality. Если интеграции придётся писать и поддерживать вам — вы уже наполовину строите сами.

  5. SLA, комплаенс и стоимость поддержки. Если есть требования по данным, региональности, аудитам, доступам, ретеншну, а также ожидание “работает всегда” — проверьте, кто реально несёт ответственность: вендор, ваша платформа, ваша аналитика. Часто buy становится дорогим именно в поддержке и согласованиях.

В правильной практике решение принимают не “build или buy”, а “какой контракт нам нужен” и “кто его сможет честно поддерживать”. И да, обычно спорят про функциональность, а решает в итоге операционка: инциденты, дебаг, доступы, и то, насколько быстро можно понять, что эксперименту нельзя верить. Граница применимости простая: если эксперименты редкие и простые, а требований к данным минимум — не надо строить платформу ради идеи платформы.