Первое правило клуба вайбкодеров? Навайбкодить дашборд. Второе правило? Рассказать об этом маме и всем подписчикам.
Платный, бесплатный, на коленке, в Lovable, Cursor, Replit, где угодно. И выглядит круто. Человек не писал код, а сегодня собрал себе панель с графиками, фильтрами и красивой кнопкой «Export». Круто же!
С одной стороны — да. Это ровно тот мир, о котором мы мечтали: меньше зависимости от разработки, меньше очередей, больше свободы у маркетологов, аналитиков и продактов.
Но есть и другая сторона.
Сделать дашборд стало проще. Но парадокс — это не решило старые проблемы, а прибавило новых!
Как так? Смотрите.
Дашборд — это функция. С его помощью принимаются более эффективные решения. Это не волшебная палочка, это лопата, с помощью которой можно выкопать яму.
То есть дашборд — как и любой аналитический сервис — сам по себе работу по принятию решений не делает. На самом деле он часто покупает вам новую работу: открыть, исследовать, понять, объяснить коллегам, превратить в задачу, проконтролировать, вернуться и проверить.
Вопрос на засыпку: зачем мы покупаем себе новую работу?
Почему дашборды стали плодиться именно сейчас?LLM и вайбкодинг резко упростили создание продуктов. Лендинг, прототип, форма, внутренняя админка, интеграция, небольшой инструмент для команды — все это стало собираться быстрее. То, что раньше выглядело как отдельный проект, теперь иногда делается за вечер.
И что мы делаем с этой новой суперсилой?
Быстрее делаем еще один экран с графиками.
Смешно? Да. Логично? Тоже да.
Дашборд был дорогим артефактом. Его надо было поставить в очередь, описать требования, попросить аналитика, потом BI-разработчика, потом подождать, потом переделать половину, потому что «я вообще-то имел в виду другое».
Теперь его можно собрать самому.
И это меняет поведение. Когда что-то становится доступным, мы начинаем делать это чаще. Даже когда не очень надо. Не потому, что мы тупые. Потому что мы люди.
Проблема в том, что скорость создания дашборда не равна скорости принятия решения.
Можно за вечер собрать пять новых графиков. Но утром все равно придется понять:
что изменилось?
почему?
кого это касается?
кто отвечает?
И самое главное — что нам делать дальше?
И вот ведь жопа. Больше дашбордов ведут не к большему числу решений, а к большему числу вопросов.
Еще раз. Дашборды — лопаты. Вопрос: вам нужно больше красивых лопат?
Что PostHog понял про следующий шаг аналитики?Недавно я слушал интервью James Hawkins, co-founder и CEO PostHog.
PostHog начинался как open-source продуктовая аналитика: события, воронки, записи сессий, ошибки, эксперименты.
Но в интервью Hawkins говорит вещь поинтереснее: PostHog идет к self-driving software. То есть к софту, который не только показывает проблему, но и помогает ее исправить.
Вот это очень важный сдвиг.
Не «сделаем еще один dashboard».
А «создадим новые эффективные решения».
Например: видим данные, ошибки, записи сессий, тикеты поддержки, сообщения в Slack и разговоры с клиентами. Понимаем, где человек застрял. Предлагаем маленькое изменение. Создаем issue или draft pull request. Человек проверяет. После релиза система смотрит, стало ли лучше.
Аналитика перестает быть источником новых проблем. Она решает старые.
Сколько людей нужно, чтобы исправить одну проблему?Как выглядит традиционный метод решения проблем:
Пользователь жалуется. Support создает тикет. Аналитик смотрит события, воронку, записи сессий и ошибки. Product manager формулирует задачу. Engineer чинит. Через неделю или месяц кто-то проверяет метрику.
Логично? Нет! Это покупка новой головной боли.
На каждом шаге теряется кусок контекста. Дашборд в этой цепочке часто не сокращает путь. Он просто добавляет еще один этап:
«Теперь кто-то должен посмотреть на график и решить, что с ним делать».
Плохой дашборд — это генератор работы.
Он не помогает принять решение быстрее. Он просто увеличивает количество мест, куда надо смотреть.
Увы, но практически любой вайбкод-дашборд — плохой.
Что должно происходить после графика?Вот тут, кажется, и должен поменяться главный вопрос.
Не «какой еще график нам нужен?»
А «для чего он нам?»
Давайте еще раз посмотрим на флоу продуктовой аналитики:
данные → график → человек смотрит → человек думает → человек ищет причину → человек пишет задачу → кто-то делает → кто-то потом проверяет.
Что если немного поменять? Например:
данные → объяснение → возможное действие → review человеком → проверка результата.
Разница вроде небольшая. Но в реальной жизни — огромная.
Например, система видит, что после изменения в onboarding упала активация новых пользователей.
Продукт вашей аналитики — не график и даже не алерт. А запрос к стейкхолдеру на апрув:
«Падение началось после релиза. Сильнее всего пострадали пользователи с мобильного трафика. Они застревают на шаге подключения интеграции. Возможное действие: добавить понятное объяснение и запасной CTA. Вот задача, примеры и метрика для проверки».
Это все еще не магия. Просто нормальная работа, которую раньше делали люди между созвонами, Slack, Jira и фразой «а кто у нас это возьмет?»
То есть вы не смотрите в дашборд. Вы смотрите в draft pull request и читаете аргументы агента.
Человек остается на review, merge, приоритетах и ответственности.
Ответственность и есть самая дорогая часть аналитики. Не построить график. А добиться, чтобы после него что-то изменилось.
Что я делаю, когда клиент просит дашборд?Для меня это не абстрактная тема.
Я работаю как Fractional Head of Marketing Analytics. И чаще всего клиент действительно приходит за дашбордом.
Это нормальный запрос.
Команде нужно видеть каналы, лиды, CAC, ROAS, выручку, воронку, конверсии, качество трафика.
Но я все чаще думаю, что дашборд сам по себе — это половина работы. Иногда четверть.
Потому что дашборд в лучшем случае отвечает на вопрос: «Что происходит?»
А бизнесу интересно: «Что с этим делать?»
Это парадокс. Даже когда клиент просит дашборд, я по умолчанию думаю не про «какие графики туда поставить».
Я думаю: какое решение этот дашборд должен ускорить?
Если ответ непонятен, у нас не задача на дашборд. У нас задача на терапию ожиданий.
То есть я всегда проектирую и включаю то, что пробустит самое главное — решения.
Иногда для этого действительно нужен дашборд.
Иногда — чат к данным: «Почему вчера просел paid search?», «Где вырос CAC, но не вырос pipeline?», «Какие сегменты стоит отключить?»
Иногда — автоматическое объяснение аномалий.
Иногда — alert, который не просто кричит «метрика изменилась», а показывает возможные причины.
А иногда лучший дашборд — это тот, который мы не сделали.
Да, звучит опасно. Особенно если вы продаете дашборды.
Но хороший слой маркетинговой аналитики должен уменьшать работу. Не создавать новую.
Каждый раз, когда вы заказываете дашборд, вы покупаете не только инструмент. Вы покупаете себе еще одну работу: открыть, изучить, понять, объяснить команде, превратить в задачу, проконтролировать действие, вернуться и проверить результат.
И кстати: если вы продаете дашборды — у меня для вас плохая новость.
Почему AI должен уменьшить количество дашбордов?Каждый второй человек вайбкодит себе панель управления жизнью, бизнесом, сном, лидами, бюджетом, котлетами и духовным ростом.
Но потом обязательно наступит похмелье. И это круто!
Я жду, когда всем станет очевидно: проблема не в том, что у нас мало дашбордов! Проблема в том, что у нас мало решений.
Чем проще будет создавать продукты и внутренние инструменты, тем чаще люди будут спрашивать: «А зачем мне дашборд перед очередным дашбордом?»
И это, как ни странно, круто.
AI тихо прививает нам самый важный BI-навык: не строить дашборд автоматически, потому что попросили, а спросить: какую работу он должен убрать?
Что спросить перед новым отчетом?Не надо сразу строить AI, который коммитит в прод.
Большинству компаний это сейчас не нужно. И, честно говоря, страшновато. Мы еще с UTM-метками не всегда договорились.
Начать можно проще.
Перед каждым новым отчетом спросить: какое решение он поможет мне принять?
Потом немного покурить. И задать себе еще один вопрос: могу ли я делать это без отчета?
Сделать алерт на падение метрик просто.
А что если сделать так, чтобы alert создавал не только тревогу, но и следующий шаг?
Потом можно двигаться к issue и draft PR для маленьких безопасных изменений. Merge оставить человеку. Продуктовые решения оставить человеку.
А всю скучную работу между «мы увидели проблему» и «мы сформулировали первое действие» — постепенно сокращать.
Что ваша аналитика сделала после вывода?Дашборд был нормальным интерфейсом для эпохи, где аналитика заканчивалась «Вот что произошло».
Но если AI уже умеет писать код, читать логи, резюмировать звонки, находить аномалии и объяснять данные, странно останавливаться на графике.
Вывод — это только середина. Дальше начинается новая работа.
Настоящий вопрос другой: что ваша аналитика сделала после того, как поняла проблему?
Если ответ «показала еще один дашборд», возможно, вы купили себе не решение. Вы купили себе еще одну работу.
Больше о работе с данными в продукте и маркетинге есть в Телеграм-канале "Модель атрибуции”
