MVP-красный флаг: вы меряете «факт релиза», а не удержание и деньги

Типичный сценарий: выкатили MVP, посмотрели installs, DAU, пару красивых графиков в аналитике и решили «летит». Через месяц выясняется, что люди не возвращаются, платят единицы, а команда уже закопалась в фичах. Цена ошибки простая: вы оптимизируете разработку, а не продукт, и не можете объяснить, что именно сработало.

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

Минимальный стандарт измерений на первые недели, чтобы не остаться без интерпретации:

  1. Cohort retention по дате первого ценностного действия, а не по install. Когорта должна определяться тем, что реально “включает” продукт, иначе удержание будет плясать от онбординга и пушей.

  2. Activation как один конкретный факт, который коррелирует с будущим возвратом. Не «зарегистрировался», а «сделал минимальную работу в продукте». И фиксируйте time-to-activation: если она расползается, вы теряете людей ещё до retention.

  3. Early revenue signals: не выручка “в целом”, а связка конверсии в оплату и качества оплаты. Минимум: доля активированных, которые попробовали оплату, доля оплативших с повторным платежом/повторной покупкой (если применимо), и аккуратная обработка возвратов/отмен.

  4. Payback-логика как дисциплина, даже без «настоящего LTV». Вы должны уметь посчитать: сколько стоит привести пользователя, какая маржа с первых денег, и что должно быть правдой про удержание, чтобы это окупалось. Без этого “монетизация позже” превращается в религию.

  5. Требования к событиям и атрибуции: единый user_id, стабильные названия и версии событий, таймстемпы, явные статусы платежа (успех/отмена/рефанд), источник привлечения с окном атрибуции и правилами дедупликации. Если это не закрыто, любые выводы про retention и payback — про вашу телеметрию, а не про продукт.

Правильная практика в первые недели выглядит скучно: когортные таблицы, одна-две ключевые воронки, и список допущений рядом с графиками. Обычно спорят про «давайте уже A/B», но без стабильной активации, событий и источников трафика вы тестируете шум. Исключение: продукты с длинным циклом решения — там вы меряете прокси-сигналы, но дисциплина когорт и событий всё равно обязательна.