Когда дашборд врёт, команда оптимизирует фантом

Один из самых дорогих багов в продукте может жить не в продукте.

Он может жить в отчёте.

В одном разборе всплыло, что воронки были занижены примерно в 7 раз. ARPPU в дашборде показывался около 366 рублей, а реальный был ближе к 675.

Это не маленькая погрешность.

Это другая картина бизнеса.

Если команда верит такому дашборду, она начинает чинить не реальность, а фантом. Спорит про конверсию, ищет проблемы в продукте, меняет приоритеты, хотя сначала надо было задать скучный вопрос: а мы вообще правильно видим ситуацию?

В этом главная опасность дашбордов.

Они выглядят уверенно.

График аккуратный. Цифры обновляются. Таблица собрана. Воронка нарисована. Можно обсуждать.

Мозг быстро принимает это как реальность.

Но дашборд - это не реальность. Это сборка из событий, правил, фильтров, JOIN-ов, атрибуции, таймзон, дублей, пропущенных статусов и старых решений, про которые уже никто не помнит.

Если в этой сборке ошибка, команда получает очень красивую ложь.

И чем аккуратнее интерфейс, тем меньше хочется сомневаться.

Фаундер часто принимает решения на уровне "куда ставим следующую неделю".

Чиним активацию.

Переделываем онбординг.

Меняем оффер.

Режем канал.

Усиливаем retention.

Если входные цифры неверные, каждое такое решение может быть логичным внутри отчёта и неправильным внутри бизнеса.

Это самый неприятный тип ошибки: команда не тупит. Она рассуждает последовательно. Просто исходная картинка кривая.

Поэтому спорить о стратегии до проверки измерения иногда бессмысленно.

Допустим, дашборд показывает слабую конверсию на одном шаге.

Команда начинает думать:

Появляются задачи. Макеты. Гипотезы. Эксперименты.

А потом оказывается, что часть событий не попадала в нужный статус. Или считались не те пользователи. Или один источник данных жил по другой логике. Или повторные платежи смешались с первыми.

И внезапно проблема уже не в продукте.

Проблема в том, что команда месяц разговаривала с неправильной тенью продукта.

Я люблю этот вопрос.

Не "какая у нас конверсия".

А: что должно быть корректно собрано, чтобы мы могли верить этой конверсии?

Например:

Это скучно. Зато без этого обсуждение роста превращается в театр.

Кстати, я всё чаще начинаю разбор проекта именно с таких скучных вопросов. Для этого и собрал Project X-Ray: он не пытается сразу придумать стратегию, а сначала отделяет факты от догадок и показывает, где в цепочке не хватает нормального основания:

Не всегда нужен огромный аудит данных.

Иногда достаточно взять 20-30 реальных пользователей и пройти их путь руками.

Открыть CRM. Платёжку. Таблицу событий. Логи. Админку.

И спросить:

Это неприятная ручная работа.

Но она быстро возвращает контакт с землёй.

Особенно когда цифры в отчёте влияют на деньги, а не просто украшают презентацию.

Потому что проверка измерения почти всегда проигрывает нормальным задачам.

Переделать экран интереснее.

Запустить кампанию понятнее.

Добавить фичу приятнее.

Проверять, почему ARPPU не сходится, скучно и немного стыдно. Как будто команда должна была уже знать.

Но бизнесу всё равно, насколько скучная работа. Если отчёт врёт, остальные решения стоят на песке.

И чем быстрее команда растёт, тем выше риск, что старые допущения в аналитике никто не пересматривает.

События добавлялись кусками. Названия менялись. Старые воронки копировались. Кто-то когда-то "временно" поправил фильтр. Потом временное стало постоянным.

Через полгода все обсуждают график, который уже никто не может объяснить.

Если метрика стала основанием для решения, я бы сделал короткий sanity check.

Если дашборд говорит одно, а платёжная реальность другое, верить надо деньгам.

Потом уже разбираться, почему отчёт отстал.

Хотя бы 20 кейсов, где путь пользователя проверен глазами.

Без этого легко обсуждать агрегаты, которые никто не видел вживую.

Если никто в команде не может объяснить метрику простыми словами, она не годится для решения.

Можно использовать её как индикатор. Но не как основу для приоритета.

Новый и повторный покупатель.

Органика и giveaway.

Целевой лид и случайный входящий.

Если всё смешано, среднее значение начинает врать очень уверенно.

Хорошая аналитика не убирает суждение.

Она даёт команде способ быстрее спорить с реальностью.

Плохая аналитика делает обратное: создаёт ощущение, что спор уже закрыт, потому что цифра есть.

Вот это опасно.

Цифра без понятного происхождения не дисциплинирует мышление. Она его усыпляет.

Команда перестаёт спрашивать "почему мы так думаем" и начинает спрашивать "что делать с этой цифрой".

Иногда первый правильный ответ: ничего. Сначала проверить цифру.

Если в вашем проекте сейчас есть большая продуктовая гипотеза, завязанная на метрику, я бы перед запуском сделал один скучный шаг.

Проверил бы метрику руками.

Не всю аналитику. Только ту, которая двигает решение.

Если решили чинить retention - проверить, кто попал в cohort.

Если решили резать канал - проверить атрибуцию и повторные покупки.

Если решили переделывать оплату - проверить реальные платежи и статусы.

Если решили, что менеджеры плохо продают - проверить, кто вообще до них доходит.

Иногда после такой проверки гипотеза не становится слабее. Она становится точнее.

А иногда исчезает совсем.

И это хороший результат. Лучше убить фантом за день, чем оптимизировать его месяц.

Если хочется пройти такую проверку по своему проекту, можно забрать Project X-Ray. Он не заменит аналитику, но поможет разложить: где факты, где догадки, какую метрику нельзя трогать без проверки и какой тест делать первым.

Пользуйтесь и не врите себе! )