# Кейс: дашборды по рекламе — расход, заявки и сверка с CRM

> Как собраны сводные дашборды по рекламе: данные из кабинетов и веб-аналитики в одной витрине, сверка расхода с заявками из CRM, срезы по регионам.

- Источник: https://lokai.ru/keysy/dashbordy-po-reklamnym-kabinetam/
- Организация: Local AI — Внедрение ИИ в закрытом контуре
- Обновлено: 2026-08-07
- Раздел: Главная → Кейсы → Дашборды по рекламе

---

Недельный разбор рекламы начинается с готовой витрины, а не с часов ручной сборки таблиц. Данные из рекламных систем и веб-аналитики собираются по расписанию, расход сводится с заявками из CRM, срезы строятся по регионам и кампаниям, а заметные отклонения система подписывает сама. Решения по ставкам и бюджетам принимает человек.

- **минуты** — на недельный разбор вместо ручной сборки таблиц
- **1** — витрина вместо выгрузки из каждого кабинета отдельно
- **3** — слоя сводятся: реклама, веб-аналитика, заявки из CRM
- **0** — ручных переносов данных между таблицами

## Задача: собрать картину рекламы в одном месте

Данные о рекламе живут в трёх разных мирах. В кабинетах — показы, клики и расход. В веб-аналитике — поведение на сайте и достижение целей. В CRM — заявки, их качество и сделки. Каждый мир считает по своим правилам, и пока их сводят руками, разбор недели превращается в несколько часов копирования между таблицами.

Хуже, что при ручной сборке ошибку почти невозможно заметить. Один срез скопировали за другой период, в другом потеряли регион, третий взяли до корректировки расхода. Решение принимается по цифре, происхождение которой уже никто не восстановит.

Мы собрали витрину как внутренний продукт: регулярная выгрузка, единое хранилище, сверка слоёв между собой и автоматические заметки о том, что заметно отклонилось. Интеграция со стороны заявок чаще всего делается через [Битрикс24](https://lokai.ru/integratsiya-bitrix24/) или учётную систему.

## Что построили

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

1. **Регулярный сбор по API.** Рекламные системы и системы веб-аналитики опрашиваются по расписанию, сырые ответы сохраняются как есть — чтобы можно было пересчитать витрину, не дёргая кабинеты заново.
2. **Единая витрина.** Все источники приводятся к общей структуре: дата, кампания, регион, расход, клики, цели, заявки. Ключом служит идентификатор объекта, а не его название.
3. **Сверка расхода с заявками.** Расход из кабинета сопоставляется с заявками и сделками из CRM за тот же период, чтобы цена заявки считалась по одному правилу для всех каналов.
4. **Срезы по регионам и кампаниям.** Один и тот же показатель разворачивается по географии и по кампаниям, иначе средняя цифра по стране прячет и провалы, и точки роста.
5. **Заметки об отклонениях.** Система пишет факты с числами: расход вырос относительно сопоставимого периода, цена заявки вышла за привычный коридор, источник перестал отдавать данные.
6. **Отметки свежести.** У каждого источника видно, когда он обновлялся в последний раз. Отсутствие данных показывается как отсутствие, а не как ноль.

## Грабли, на которые наступили

Эта часть полезнее описания архитектуры. Все шесть проблем встречаются на любом проекте со сбором рекламных данных, и лечатся они не кодом, а договорённостями.

*Типовые проблемы сбора рекламных данных и как мы их закрываем*

| Проблема | Как проявляется | Что делаем |
|---|---|---|
| Суммы не сходятся между срезами | Итог по кампаниям не равен итогу по дням: округления, НДС, корректировки задним числом | Фиксируем эталонный срез, остальные сверяем с ним, расхождение показываем числом |
| Квоты API | Выгрузка обрывается на середине периода или возвращает пустой отчёт | Разбиваем запросы на окна, кэшируем сырые ответы, повторяем с паузой |
| Асинхронные отчёты | Кабинет отвечает «отчёт в очереди», а не данными | Опрашиваем статус и переносим кусок на следующий цикл, не роняя весь прогон |
| Измеримость в CRM | Заявки без источника, дубли карточек, сделки без даты | Сначала чиним поля и правила заведения, выводы о конверсии делаем после |
| Переименование кампаний | Название поменяли — история распалась на две | Ключом делаем идентификатор, название храним как изменяемый атрибут |
| Часовые пояса | Кабинет и веб-аналитика режут сутки по-разному | Приводим к одному поясу на входе, дату фиксируем при записи в витрину |

## Что изменилось в разборе рекламы

Главный эффект не в графиках, а в том, с чего начинается встреча. Раньше первые часы уходили на сборку и на спор о том, чьи цифры правильные. Теперь разбор начинается с готовой витрины и вопроса «почему», а не «сколько».

Второе изменение — видимость мелочей. Кампания, которая тихо перестала отдавать данные, раньше всплывала через две недели. Сейчас пропуск источника подсвечивается на следующем цикле, потому что витрина отличает ноль от отсутствия данных.

Третье — дисциплина в CRM. Как только цена заявки считается автоматически и видна всем, доля заявок без источника перестаёт быть чьей-то частной проблемой. Это, пожалуй, самый недооценённый эффект: витрина заставляет чинить учёт, а не только рекламу.

## Ограничения

Витрина — инструмент подготовки решения, а не замена решению. Границы очерчиваем сразу, чтобы от неё не ждали лишнего.

- **Ставки и бюджеты меняет человек.** Система показывает отклонение и сопоставимый период, но сама в кабинет с правками не ходит.
- **Витрина не лучше источника.** Если половина заявок приходит без источника, дашборд честно покажет «источник не определён», а не додумает недостающее.
- **Атрибуция остаётся моделью.** Сведение расхода и заявок даёт сопоставимость между каналами, а не истину о вкладе каждого касания.
- **Свежесть ограничена расписанием и квотами.** Для решений внутри дня по-прежнему смотрят в сам кабинет.
- **Часть срезов недоступна по API.** Если показатель существует только в интерфейсе кабинета, мы говорим об этом на старте, а не строим витрину с дырой.
- Соседний внутренний продукт, [генератор посадочных страниц](https://lokai.ru/keysy/generator-posadochnyh-stranic/), поставляет в эту же витрину данные по страницам.

## Частые вопросы про дашборды по рекламе

**Почему суммы в разных срезах не сходятся?**

Потому что срезы считаются по разным правилам, и это нормальное поведение рекламных систем, а не ошибка сборки. Расход по дням и по кампаниям расходится из-за округлений, НДС и корректировок задним числом. Данные по конверсиям расходятся ещё сильнее: у кабинета и у веб-аналитики разные окна атрибуции и разные определения визита. Мы не пытаемся заставить цифры совпасть. Выбирается эталонный срез, остальные сверяются с ним, а расхождение показывается явным числом. Пока величина в пределах ожидаемой, тревоги нет; выход за границу подсвечивается.

**Зачем чинить CRM до того, как строить дашборд?**

Потому что иначе дашборд аккуратно нарисует неправильную картину, и по ней начнут принимать решения. Типовые поломки: заявка заведена без источника, один клиент существует тремя карточками, сделка закрыта без даты, стадию поменяли задним числом. Ни одну из них витрина исправить не может — она их только унаследует. Поэтому первый шаг всегда одинаковый: разбираем, как заявка попадает в CRM и какие поля заполняются обязательно. Иногда на этом этапе выясняется, что проблема не в рекламе, а в том, что половина обращений вообще не доходит до системы.

**Что система пишет сама, а что пишет человек?**

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

**Что делать с квотами API рекламных систем?**

Квоты — главное ограничение регулярного сбора, и обходить их не нужно, нужно под них проектировать. Запросы разбиваются на окна по датам и по объектам, сырые ответы кэшируются, повторный запуск берёт из кэша, а не дёргает кабинет заново. Часть систем формирует отчёт асинхронно: в ответ приходит «отчёт в очереди», и это не ошибка, а статус — сборка опрашивает его и переносит недостающий кусок на следующий цикл. Из-за этого витрина не гарантирует данные день в день по всем источникам, и в интерфейсе показано, когда каждый источник обновлялся.

**Можно ли отдать системе управление ставками?**

Технически да, практически мы этого не делаем. Ставки и бюджеты — необратимое действие с прямыми деньгами, и на такие действия у нас всегда стоит подтверждение человеком. Витрина доводит подготовку до конца: показывает срез, отклонение, сопоставимый период и вероятную причину, чтобы решение занимало минуты, а не полдня раскопок. Дальше человек идёт в кабинет. Отдельная причина осторожности — качество исходных данных: пока часть заявок теряет источник, автоматическое перераспределение бюджета усилит ошибку измерения, а не исправит её.

**Какие системы подключаются к витрине?**

Рекламные кабинеты и системы веб-аналитики, которые отдают данные по API, плюс CRM как источник заявок и сделок. Конкретный список зависит от того, чем пользуется компания, и от того, что в её кабинетах вообще доступно по API — часть срезов существует только в интерфейсе. Поэтому перед сборкой мы проверяем доступность каждого нужного среза, а не обещаем его заранее. Если срез недоступен, честнее сказать это на старте, чем строить витрину с дырой. Со стороны CRM чаще всего это Битрикс24 или 1С.

---

Бесплатный аудит и расчёт окупаемости на ваших данных: https://lokai.ru/besplatnyy-audit-ii/

Почта: hello@lokai.ru · 123112, Москва, ММДЦ «Москва-Сити» · Пн–Пт, 09:00–19:00 МСК