Аналитика — это основа для принятия решений. Но данные должны быть адаптированы для конкретных бизнес-задач и отражать реальные метрики, на которые можно опираться в работе.
В этом материале для GoPractice
На разных этапах развития компании — разные требования к аналитике
Pre-PMF (до нахождения product-market fit). Здесь задача в первую очередь — понять, где ваша аудитория. Основное внимание уделяется поиску аудитории и экспериментированию с каналами привлечения. На этом этапе не требуется оптимизировать маркетинговые расходы, а значит, аналитика может быть упрощенной.
Post-PMF (масштабирование). По мере масштабирования аналитика должна отвечать более сложным требованиям — использование A/B тестов и расширение функционала BI становятся критичными. Это позволяет контролировать рост и оптимизировать маркетинговые расходы.
Кроме того, чем больше компания, тем важнее становится роль data-инженеров и автоматизация отчетности.
Основные принципы для создания полезных дашбордов
Быстрая загрузка
Дашборд должен грузиться быстро, иначе люди будут стараться минимизировать взаимодействие с ним.
Пример из жизни:
Дашборд грузится больше минуты. Каждое изменение фильтра приводит к тому, что опять приходится долго ждать. В результате менеджеры тратят несколько часов в неделю на то, чтобы выгрузить «сырые» данные в Google Spreadsheets и сделать сводные таблицы. Формально дашборд есть, но никто не может с ним эффективно работать.
Четкое предназначение
Каждый дашборд должен отвечать на конкретный набор вопросов, связанных с бизнес-целями. Не нужно делать дашборд, в котором свалены все данные во всех возможных разрезах: им будет неудобно пользоваться и он будет долго грузиться.
В идеале иметь возможность показывать только те колонки и данные, которые нужны пользователю в конкретный момент. Хороший BI-инженер может настроить это в Tableau.
Разные дашборды — для разных пользователей
Маркетологи, менеджеры и руководство — всем нужны свои, специфичные дашборды.
Когда маркетинговой аналитике нужны улучшения
Ручной сбор данных занимает много времени
Если менеджеры каждую неделю вручную собирают отчет в Excel или тратят часы на сбор данных из разных источников перед еженедельной встречей — значит, нужен дашборд, который автоматизирует эту работу.
Пример из жизни:
Команда по вторникам выгружает данные из кабинетов по затратам, показам, кликам. Далее из MMP выгружаются данные по инсталлам, регистрациям и событиям. Затем эти данные при помощи VLOOKUP склеиваются по campaign name. И на основе этого получается Excel-таблица, которую используют в работе.
Как итог, такой ручной труд ведет к потраченному времени, а точные данные доступны лишь с задержкой в неделю.
Несогласованность данных: разные дашборды показывают разные результаты
Если метрики, такие как количество пользователей или доход, расходятся более чем на 10% между отчетами маркетинга, продукта и финансов, то это создает проблемы. Эти метрики должны быть едины во всех отчетах.
Пример из жизни:
В маркетинге пользователь считается новым, если он не пользовался продуктом больше шести месяцев. В продукте пользователь считается новым, если он не пользовался продуктом никогда. Если человек шесть лет назад зарегистрировался, купил и затем перестал пользоваться продуктом, а вчера мы его заново заманили в продукт и он снова сделал покупку, то для продукта он — старый пользователь, а для маркетинга — новый. Если продукт давно на рынке в этой стране, и расхождения в цифрах — значительные, то это повод договориться с продуктовой командой о едином определении.
Пройти симуляторы от GoPractice можно в группе с опытным ментором.
Что вы получите:
✅ Онлайн-встречи для обсуждения прогресса и разбора вопросов
✅ Общение в закрытом чате для постоянной обратной связи с ментором и одногруппниками
✅ Дополнительные кейсы от ментораПоддержка ментора доступна при обучении:
→ в «Симуляторе управления продуктом на основе данных»
→ в «Симуляторе управления ростом продукта»
→ в «AI/ML-симуляторе для продакт-менеджеров»
Сложные корректировки в уме
Если вашим сотрудникам приходится умножать данные на коэффициенты, чтобы получить реальную картину, это признак плохо настроенной аналитики. Данные должны быть готовы к использованию без дополнительных вычислений.
Пример из жизни 1:
Продвижение мобильного приложения в Meta* в iOS. Из-за того, что не используется SkAd, в качестве количества покупок берутся данные из AppsFlyer. Эти данные доступны только по пользователям, которые дали ATT (App Tracking Transparency) Consent, и они умножаются на «коэффициент ATT», например 3.5.
Сопутствующая проблема: в отчете для руководства — недооцененный paid и переоцененная органика только в одной из платформ — iOS.