A/B-тесты в TG-боте — не повод строить платформу с фича-флагами на всё

A/B-тесты в TG-боте — не повод строить платформу с фича-флагами на всё

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

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

Не усложняй инфраструктуру раньше времени. Для 80% кейсов достаточно простого распределения по user_id: хэш попал в bucket A — видит вариант A, попал в B — вариант B. Важно, чтобы разметка была стабильной, а логика — одинаковой между сессиями.

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

Делай feature flags только там, где они экономят время команды или деньги на трафике. Во всех остальных случаях выигрывает простая схема: один гипотеза — один вариант — один метрик.