Понедельник, девять утра. Владелец онлайн-школы аналитики открывает дашборд в Data Studio, который маркетолог собрал из сквозного отчёта по кампаниям: двадцать три графика, от сеансов и отказов до круговой диаграммы устройств. Медиабайер пишет в чат: «Meta за неделю: 52 заявки по 2 308 ₸, лучшая неделя». Владелец листает экран и не может ответить на единственный вопрос, ради которого его открыл: давать ли Meta больше денег. Цифры в уроке условные, школа та же, что в уроках про GA4 и сквозную аналитику.
Инструмент тут ни при чём. Выбор между Data Studio, Power BI и Tableau - отдельная задача, а правила ниже одинаково работают в любом из них.
Один дашборд - один вопрос
Дашборд начинают не с графиков, а с фразы: кто его открывает, когда и какое решение принимает. У школы это владелец в понедельник утром, и решает он, как разделить 200 000 ₸ рекламного бюджета следующей недели между Meta и Google. Вопрос к экрану получается такой: что изменилось за прошлую неделю в заявках и оплатах, в каком канале и что проверить, прежде чем двигать деньги.
Всё, что на этот вопрос не отвечает, уходит с экрана туда, где с этим работают. CTR, CPM и частота нужны медиабайеру, и он смотрит их в Ads Manager. Сеансы и отказы нужны тому, кто правит сайт. Tableau в советах по дашбордам предлагает то же: начинать с цели и читателя, ставить главный график в левый верхний угол и держать на одном дашборде два-три вида, а если нужно больше, делать второй дашборд. Совет вендорский, но в Data Studio и Power BI он работает так же. У школы на первом экране два вида, главное отклонение и таблица по каналам, а объявления и заявки открываются по клику, вторым уровнем.
Экран школы сверху вниз:
| Блок | Что на нём | На какой вопрос отвечает |
|---|---|---|
| Шапка | Неделя, источники и время их последней загрузки | Каким цифрам уже можно верить |
| Главное отклонение | Доля заявок, по которым заплатили в ту же неделю, против прошлой недели | Что изменилось |
| Таблица по каналам | Расход, заявки, оплаты и расход на оплату в каждом канале | Где изменилось |
| Детали канала | Объявления выбранного канала и список его заявок со статусами из CRM, открываются по клику | Что проверить дальше |
| Сверка | Заявки в GA4 против заявок в CRM | Не сломался ли сбор данных |
Отклонение и его контекст
Главная цифра для владельца - оплаты, но с ними есть подвох. Человек, оставивший заявку в пятницу, может заплатить и через десять дней, перед стартом потока. 15 оплат из сквозного отчёта набрались не сразу: к концу самой недели их было 10, остальные пять пришли позже. Если сравнить свежую неделю с итоговыми 15, падение выйдет пугающим при любом раскладе.
Поэтому на дашборде метрика с одинаковым сроком для всех недель: доля заявок, по которым заплатили в ту же неделю. Неделей раньше это 10 оплат из 65 заявок, 15%. На прошлой неделе 7 из 84, 8%. Вот и отклонение: заявок стало на 19 больше, а оплат на три меньше. Три оплаты на таких числах тоже могут быть случаем: плитка показывает, куда смотреть, а не ставит диагноз. Уверенно здесь видно одно - заявок стало заметно больше, а оплат не прибавилось.
Рядом с цифрой ставят то, без чего её прочитают неправильно.
- Определения. «Заявка» - карточка в CRM, а не событие
generate_leadв GA4. «Оплата» - статус «Оплачено» в CRM. Две строки мелким шрифтом под цифрой экономят полчаса спора на каждой планёрке. - База процента. С 15% до 8% - это минус 7 процентных пунктов. Подпись «-7%» неверна: в пунктах пишут «-7 п.п.», а относительное падение около 46%.
- Свежесть каждого источника. Data Studio показывает время последнего обновления данных в левом нижнем углу отчёта (как устроена свежесть данных), но это время, когда Data Studio последний раз забрал данные, а не час, по который данные есть в таблице. Выгрузка заказов и оплат из CRM приходит в таблицу каждый день в 18:00, поэтому в понедельник утром оплаты в ней только по 18:00 воскресенья. Вечерние оплаты придут со следующей выгрузкой, и к вечеру понедельника 7 может стать 8.
Свежесть данных источника
| Поле отчёта | Значение |
|---|---|
| Отчёт обновлён | 09:00 |
| Последняя выгрузка заказов | Вчера, 18:00 |
Время обновления отчёта - не то время, по которое в нём есть данные.
Окупилась ли неделя, этот блок не скажет: для этого нужны итоговые оплаты, а они станут известны к старту потока. Их держат на второй странице дашборда, в той же таблице, что в сквозном отчёте. Там видно, что Meta при расходе 120 000 ₸ нужно 8 оплат в неделю, чтобы выйти в ноль.
Разбивка: где изменилось
Общая цифра показывает, что что-то сдвинулось, но не говорит, куда смотреть. Следующий блок раскладывает её по каналам. В ячейках стоят числа, а не только проценты, потому что по проценту не видно, что за ним две оплаты.
| Канал | Расход за неделю | Заявки: неделей раньше → прошлая | Оплатили на той же неделе | Расход на такую оплату |
|---|---|---|---|---|
| Meta | 120 000 ₸ | 34 → 52 | 4 → 2 | 30 000 → 60 000 ₸ |
| Google Ads | 80 000 ₸ | 18 → 19 | 4 → 4 | 20 000 → 20 000 ₸ |
| Telegram-канал школы | 0 ₸ | 8 → 9 | 1 → 1 | - |
| Нет меток | 0 ₸ | 5 → 4 | 1 → 0 | - |
| Всего | 200 000 ₸ | 65 → 84 | 10 → 7 | 20 000 → 28 571 ₸ |
Прирост почти целиком дала Meta: плюс 18 заявок из 19, и цена заявки там упала с 3 529 до 2 308 ₸. Этому и радуется медиабайер. Но оплат из Meta стало меньше, и расход на оплату вырос вдвое. У Google всё как было.
Про причину две оплаты против четырёх ничего не скажут: разницу в две оплаты легко даёт случай. Таблица даёт другое - адрес. Изменилось в Meta, туда и смотрят дальше.
Первый разрез выбирают по решению. Бюджет школа делит по каналам, значит, и разбивка по каналам. Города или устройства понадобятся, когда о них появится решение. Строку «Нет меток» не прячут: если она растёт, где-то форма или ссылка перестала передавать метки.
Путь к причине
Клик по строке Meta фильтрует блок ниже, и в нём остаются объявления этого канала. Они называются так же, как utm_content по схеме меток школы, поэтому заявки из CRM ложатся на них без ручной сверки.
Фильтр тоже должен читаться. Когда клик по Meta отфильтровал нижний блок, на экране написано «Показано: Meta» и есть способ сбросить выбор. Если плитка с общей долей наверху осталась по всем каналам, это подписано, иначе 8% по всей школе прочитают как 8% по Meta.
| Объявление | Неделей раньше: заявки / оплатили | Прошлая неделя: заявки / оплатили | Менеджер связался, прошлая неделя |
|---|---|---|---|
video_teacher | 20 / 3 | 22 / 2 | 18 из 22 |
carousel_program | 14 / 1 | 30 / 0 | 11 из 30 |
Рост дала карусель: 30 заявок вместо 14. Оплат с неё ноль, но и этого числа мало, чтобы что-то утверждать. Поэтому в таблице есть шаг пораньше, где случаев больше: удалось ли менеджеру поговорить с человеком по телефону или в WhatsApp. С видео преподавателя он связался с 18 людьми из 22, с карусели с 11 из 30. Эта разница уже заметная, и с неё начинается проверка.
Последнее звено пути - список: 30 заявок с карусели, у каждой номер, статус в CRM и комментарий менеджера. Телефоны и имена на дашборд не выносят, карточку по номеру заявки менеджер откроет в CRM сам. Дальше вопросы уже к людям. Что обещает карусель и что человек видит на странице после клика? Что сказали те 11, с кем удалось поговорить? Если они ждали бесплатный вебинар, дело, возможно, в обещании объявления и качестве заявок. Пока менеджер не прочитал свои записи, это гипотеза.
Решение, которое подсказывает такой экран, скромнее «лучшей недели»: бюджет карусели не поднимать, пока менеджер не разберёт её заявки, а выводы о Meta делать по итоговым оплатам к старту потока.
GA4 и CRM на одном экране
В неделю из сквозного отчёта GA4 насчитал 69 событий generate_lead: 40 из Instagram, 20 из Google, 9 из Telegram. В CRM за ту же неделю 65 заявок: 34 из Meta, 18 из Google, 8 из Telegram и 5 без меток. Поставьте обе цифры на дашборд с подписью «Заявки», и каждый понедельник будет начинаться со спора, какая из них правильная.
Цифры для решения берут из CRM, потому что только там у заявки есть статус оплаты. GA4 уходит вниз, в строку сверки: «GA4: 69 событий, CRM: 65 заявок». Небольшой разрыв нормален: GA4 считает срабатывания тега, включая повторные отправки формы и тесты коллег (как GA4 считает заявки), а каналы определяет по своим правилам, так что по строкам цифры один в один не сойдутся, сверяют итог. Если же разрыв вдруг вырос, скажем, GA4 показывает 70, а CRM 40, сначала чинят форму или передачу заявок в CRM и только потом читают остальной экран.
Что не ставить на дашборд
- Метрики площадок: показы, CTR, CPM, частоту. Медиабайеру они нужны для работы с объявлениями, а владельцу не помогут выбрать между каналами.
- Сеансы, отказы, устройства и карту посетителей. Это экран для работы над сайтом.
- Экзотические диаграммы ради разнообразия: спидометры, пузырьковые, 3D. Число, которое сверяют с CRM, лучше читается в таблице, сравнение каналов - на столбцах от нуля, динамика по неделям - на линии, где последняя неполная неделя отмечена отдельно.
- Цель, которой нет. Полоска «выполнено на 70%» без согласованного плана рисует порог, который никто не ставил.
- Красный и зелёный без подписи. Рост заявок раскрасится зелёным, хотя оплат стало меньше. Цвет показывает, лучше это для решения или хуже, и рядом стоит знак или слово.
А вот определения метрик с экрана не убирают даже ради компактности. Без них владелец сравнит заявки из GA4 с заявками из CRM и примет решение по двум разным цифрам с одним названием.
Упражнение: покажите дашборд читателю
Возьмите дашборд, который вы ведёте для клиента, или соберите простой по своему сквозному отчёту из трека «Старт».
Выполнено 0 из 7
Если читатель ответил «заявок больше, всё отлично», главное отклонение стоит не там или рядом с заявками нет оплат. Если он сравнил 7 оплат с 15 и испугался, на экране не видно, что сроки у недель разные. Если он сказал «Meta сломалась, выключаем», экран выдаёт разницу в две оплаты за вывод: держите числа рядом с процентами, чтобы было видно, как мало за ними случаев. А если он нашёл и отклонение, и канал, но не понял, что делать дальше, не хватает последнего звена - списка записей и человека, который их разберёт.
Видео: правила хорошего дашборда
Анна Шестопалова о правилах дашборда, примеры в Power BI.