Дашборд Google Ads в Looker Studio 2026: почему цифры не сходятся с кабинетом

Картина, знакомая почти каждому, кто хоть раз собирал отчётность для клиента или для себя: в Google Ads за октябрь расход 418 240 ₽ и 1 212 конверсий, а в красивом дашборде на том же аккаунте — 402 980 ₽ и 1 184 конверсии. Разница небольшая, объяснить её никто не может, и доверие к отчёту заканчивается ровно в этот момент. Дальше все всё равно идут смотреть в кабинет, а дашборд превращается в слайд для созвона.

Проблема почти никогда не в том, что «Looker Studio врёт». Проблема в том, что отчёт собран без понимания того, как коннектор достаёт данные, что делает с ними смешение источников и в каком часовом поясе живёт аккаунт. В этом материале — разбор того, где именно расходятся цифры, как собрать дашборд Google Ads в Looker Studio по слоям, какие вычисляемые поля нужны почти всем, когда отчёт пора переносить в BigQuery, и чек-лист приёмки, после которого отчёту можно верить без сверки с кабинетом.

Что умеет нативный коннектор Google Ads — и где его потолок

Нативный коннектор Google Ads в Looker Studio бесплатный, не требует ни прокладок, ни сторонних сервисов, и для 80% задач его достаточно. Но он не «витрина данных», а срез отчётности, и это нужно держать в голове с первой минуты.

Что выбирается при подключении

При создании источника вы выбираете аккаунт и тип отчёта. Именно тип отчёта определяет, какие поля вам будут доступны и на каком уровне агрегации придут строки:

• Аккаунт — верхнеуровневые метрики, без разбивки по кампаниям.
• Кампания — самый частый выбор: расход, клики, показы, конверсии в разрезе кампаний.
• Группа объявлений — тот же набор на уровень ниже.
• Ключевое слово / поисковый запрос — семантика и то, по чему реально показывались объявления.
• Объявление / ассет — креативный срез.
• Видео и прочие специализированные срезы — доступность зависит от типов кампаний в аккаунте.

Ключевая механика, которую пропускают: в одном источнике живёт один тип отчёта. Нельзя взять «кампании» и «ключевые слова» из одного источника — это два разных подключения. Если в отчёте на одной странице и срез по кампаниям, и срез по запросам, у вас уже два источника, и дальше нужно следить, чтобы они были настроены одинаково (тот же аккаунт, тот же часовой пояс, те же настройки свежести).

Чего коннектор не отдаёт

Список коротких, но дорогих ограничений:

• Нет истории изменений — вы не увидите, когда кто-то поднял ставку или переписал объявление. Change History живёт только в кабинете.
• Нет данных старше окна хранения отчёта для части срезов (поисковые запросы — самый частый пример). Если вам нужна длинная ретроспектива по запросам, коннектор не поможет.
• Нет сырых событий — только агрегаты. Посчитать уникальных пользователей или собрать воронку «клик → лид → продажа» на уровне записи невозможно.
• Нет кросс-аккаунтной сшивки «из коробки». Подключение на уровне управляющего аккаунта (MCC) даёт не всё и не всегда так, как ожидается — см. раздел про валюту ниже и отдельный разбор конверсий на уровне MCC и cross-account tracking.
• Нет ваших денег — маржи, себестоимости, LTV. Всё, что про прибыль, приходит из вашей системы, а не из Google.

Нативный коннектор отвечает на вопрос «что происходило в кабинете». На вопрос «сколько мы заработали» он не отвечает в принципе — для этого нужен второй источник и аккуратная сшивка.

Семь причин, почему Looker Studio и кабинет показывают разные цифры

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

Симптом	Вероятная причина	Где проверять
Расход отличается на 1 день в начале/конце периода	Часовой пояс источника ≠ часовой пояс аккаунта	Настройки источника данных
Расход отличается в разы или на курс валюты	Отчёт на уровне MCC сводит валюты	Валюта аккаунта и валюта отчёта
Конверсии «сегодня» занижены, через неделю подросли	Атрибуция по времени клика + лаг конверсии	Столбец конверсий, окно конверсии
Цифры вчерашние, хотя обновили страницу	Кэш и настройка свежести данных	Data freshness источника
Сумма по таблице ≠ итогу в карточке	Разные диапазоны дат у элементов	Date range на уровне графика
Расход задвоился после добавления разбивки	Сегмент размножает строки	Добавленные измерения
После blend метрики «поехали»	Тип join и дублирующиеся ключи	Конфигурация смешения

1. Часовой пояс

Самая частая и самая обидная причина. Аккаунт Google Ads живёт в своём часовом поясе, выбранном при создании и неизменяемом без обращения в поддержку. Источник в Looker Studio — в своём. Если аккаунт в UTC+3, а источник в UTC, граница суток сдвигается на три часа, и весь расход с 21:00 до 00:00 уезжает в соседний день. На длинном периоде это почти незаметно, на отчёте за вчера — расхождение в десятки процентов.

Что делать: в настройках источника данных явно выставить тот же часовой пояс, что и у аккаунта, и зафиксировать это в документации отчёта. Если аккаунтов несколько и пояса разные — сравнивать их в одной таблице по дням нельзя, только по неделям и месяцам.

2. Валюта и управляющий аккаунт

Подключение на уровне MCC удобно: один источник, много аккаунтов. Но если у суб-аккаунтов разные валюты, Google конвертирует их в валюту управляющего аккаунта по своему курсу на дату — и ваша сумма в отчёте не сойдётся ни с одним отдельным кабинетом. Это не ошибка, это дизайн.

Что делать: либо вести отчёт в валюте MCC и честно подписывать это на дашборде, либо подключать аккаунты по одному и приводить валюты самостоятельно через вычисляемое поле с фиксированным курсом. Второй путь честнее для юнит-экономики, но требует дисциплины: курс надо обновлять.

3. Атрибуция по времени клика против времени конверсии

Google Ads по умолчанию относит конверсию к дате клика, а не к дате самой конверсии. Пользователь кликнул 3 октября, купил 9 октября — конверсия встанет в 3 октября и появится в отчёте только после того, как произойдёт. Поэтому вчерашний день всегда недосчитан, а позавчерашний продолжает «дозаполняться» ещё неделю-две.

В Looker Studio это выглядит так: вы смотрите отчёт за вчера, видите мало конверсий, пугаетесь, а через пять дней та же дата показывает другое число. Отчёт не сломался — он просто догрузился. Механика лага и окна конверсии подробно разобрана в материале про окно конверсии и лаг конверсий в Google Ads.

Что делать: на дашборде никогда не показывать последние 1–3 дня как «факт». Либо вводить сдвиг окна (например, период «последние 30 дней, исключая вчера»), либо явно подписывать свежие дни как неполные. И не сравнивать «вчера» с «тем же днём недели месяц назад» — это сравнение полного периода с неполным.

4. Кэш и свежесть данных

Looker Studio не ходит в Google Ads при каждом открытии отчёта — он кэширует. У каждого источника есть настройка свежести данных (data freshness): коннектор Google Ads по умолчанию обновляется раз в несколько часов, Google Таблицы — чаще, BigQuery настраивается отдельно. Точные значения зависят от коннектора и периодически меняются, поэтому их стоит один раз открыть и проверить в настройках конкретного источника, а не держать в голове.

Что делать: если отчёт используется для ежедневных решений, уменьшить интервал свежести; если по нему только отчитываются раз в неделю — наоборот, увеличить (меньше обращений, быстрее загрузка). И добавить на дашборд текстовое поле с временем последнего обновления, чтобы человек на том конце понимал, на что он смотрит.

5. Диапазон дат на уровне элемента

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

6. Сегменты, которые размножают строки

Добавили в таблицу измерение «устройство» — и сумма расхода выросла? Нет, расход тот же, просто строк стало втрое больше, а вы смотрите на подытог по неверному уровню. Но бывает и настоящее задвоение: часть измерений в Google Ads относится к другому уровню агрегации, и метрика повторяется для каждой строки разбивки. Логика сегментации и того, какие разбивки совместимы с какими метриками, разобрана отдельно в материале про сегменты отчётов Google Ads.

Правило простое: после добавления любого нового измерения в таблицу сверьте итог по расходу с предыдущей версией. Разошлось — измерение несовместимо с этой метрикой на этом уровне.

7. Blend, собранный «на глаз»

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

Как собрать дашборд, которому можно верить: три слоя

Рабочая архитектура отчёта — не «накидать графиков», а три отдельных слоя, каждый со своей зоной ответственности. Смешивать их — значит получить отчёт, который невозможно отладить.

Слой 1. Источники

На этом слое решается только одно: откуда берутся числа. Правила:

• Один источник = один тип отчёта = один аккаунт (или осознанно весь MCC).
• Источники создаются отдельными объектами и переиспользуются в разных отчётах, а не создаются заново внутри каждого.
• Часовой пояс, валюта, свежесть данных выставляются здесь и больше нигде.
• Имя источника говорит само за себя: GAds_Кампании_Аккаунт-RU_UTC+3, а не «Google Ads (2)».

Слой 2. Вычисляемые поля

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

Поля, которые нужны почти всем:

Поле	Формула (псевдокод Looker Studio)	Зачем
CPA	Cost / Conversions	Базовая метрика эффективности
ROAS	Conv. value / Cost	Для всего, где есть ценность конверсии
CR клика в конверсию	Conversions / Clicks	Отделяет проблему трафика от проблемы посадочной
Группа кампании	CASE WHEN REGEXP_MATCH(Campaign, '^BRAND.*') THEN 'Бренд' ELSE 'Небренд' END	Брендовый трафик нельзя считать вместе с остальным
Маржинальный ROAS	(Conv. value * Маржа) / Cost	Переводит отчёт из выручки в прибыль
Флаг неполных дней	CASE WHEN Date >= DATE_ADD(CURRENT_DATE(), INTERVAL -2 DAY) THEN 'Неполные данные' ELSE 'Факт' END	Честная подпись свежих дат

Поле «Группа кампании» — на самом деле главное из списка. Оно работает только при дисциплине в именовании кампаний, и это та же дисциплина, что и в UTM-разметке и naming conventions: если сегодня кампания называется BRAND_RU_Search, а завтра brand-ru-search-new, любой regexp сломается молча, и отчёт начнёт врать, не показав ни одной ошибки.

Слой 3. Визуализация

Здесь — только оформление: что на какой странице, какие фильтры, какой порядок. Никаких формул, никаких «временных» метрик на уровне графика. Практические правила:

• Одна страница — один вопрос. «Как мы потратили», «Что принесло деньги», «Что сломалось» — три страницы, а не одна простыня из двадцати блоков.
• Первый экран — пять чисел максимум. Расход, конверсии, CPA, ROAS, доля бюджета. Всё остальное — ниже.
• Сравнение с предыдущим периодом включено везде. Число без динамики не решение, а факт.
• Диапазон дат один на страницу, наследуется всеми элементами.
• Подпись источника и времени обновления в подвале каждой страницы.

Blend: где он ломает цифры и как его готовить

Смешение источников (blend) — то место, где нормальный отчёт превращается в генератор случайных чисел. Механика простая, но коварная: Looker Studio соединяет таблицы по ключу и возвращает объединённый набор строк. Если ключ неуникален, метрики размножаются.

Пример. Слева — расход по кампаниям из Google Ads (одна строка на кампанию). Справа — продажи из CRM по дате заказа (много строк на кампанию). Соединяем по полю «кампания», тип соединения — left outer. Результат: расход кампании повторится столько раз, сколько заказов нашлось, и сумма расхода вырастет в десятки раз. Отчёт при этом не покажет ни одной ошибки.

Правила безопасного blend

• Агрегируйте до соединения. Обе стороны должны быть на одном уровне гранулярности: одна строка на пару «дата + кампания» слева и справа. Если CRM отдаёт заказы построчно, сверните их в суммы по дате и кампании до того, как соединять.
• Ключ должен быть составным и совпадать по формату. Дата + кампания. И «дата» с обеих сторон должна быть датой, а не текстом, иначе соединение просто ничего не найдёт и вы увидите нули вместо ошибки.
• Тип соединения выбирается осознанно. Доступны left outer, right outer, inner, full outer и cross. Для связки «реклама + продажи» почти всегда нужен left outer с рекламой слева: вы хотите видеть все кампании, включая те, что не принесли продаж. Inner молча спрячет кампании-неудачники — и отчёт покажет ROAS лучше, чем он есть.
• Ограничьте число таблиц. В одном смешении Looker Studio позволяет объединить до пяти таблиц (значение стоит перепроверить в справке — Google его периодически меняет), но практический потолок ниже: уже на трёх отладка становится мучительной. Если нужно больше — это сигнал, что данные пора сводить не в отчёте, а в хранилище.
• Проверяйте итог после каждого шага. Собрали blend — сверьте сумму расхода с несмешанным источником за тот же период. Разошлось хоть на рубль — разбирайтесь сейчас, через месяц причину не найдёте.

Отдельная засада — расхождения между рекламным кабинетом и аналитикой, которые blend не исправляет, а маскирует. Девять причин, по которым Google Ads и GA4 показывают разные конверсии, разобраны в отдельном материале про расхождение конверсий Google Ads и GA4. Если вы кладёте в один отчёт обе системы, сначала объясните разницу, а потом рисуйте график.

Когда отчёт тормозит: Extract Data

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

Встроенное лечение — извлечение данных (Extract Data). Вы создаёте источник-снимок: выбираете нужные измерения, метрики, фильтры и период, и Looker Studio сохраняет результат у себя. Отчёт начинает читать локальный снимок, а не ходить в API.

Как это делается: на главной странице Create → Data Source, в списке коннекторов выбрать Extract Data, указать исходный источник, перетащить нужные поля, при необходимости задать агрегацию и фильтры, выставить период, включить Auto update с расписанием и нажать Save and Extract.

Жёсткие ограничения, о которые разбивается большинство попыток:

• Размер — до 100 МБ. Больше — извлечение падает с ошибкой.
• Строки — до 750 000. Больше — данные молча обрезаются, и отчёт становится неполным. Это опаснее ошибки: вы ничего не заметите.
• Данные статичны до следующего обновления по расписанию.
• Извлечение из агрегированного источника даёт разагрегированные данные, и правила агрегации метрик могут отличаться от исходного источника — итоги способны слегка разойтись с оригиналом.
• Удаление источника удаляет и сами данные с серверов Google.

Практический вывод: Extract Data отлично работает для дашбордов уровня «кампании за 13 месяцев» и совершенно не подходит для уровня «поисковые запросы по всем аккаунтам» — там 750 000 строк заканчиваются за пару недель. Подробности и актуальные лимиты — в официальной документации по Extract Data.

Когда пора уходить в BigQuery

Нативный коннектор плюс Extract Data закрывают большинство задач одного-двух аккаунтов. Но есть четыре признака, при которых дальнейшая борьба с Looker Studio — потеря времени:

1. Больше 5–7 аккаунтов, которые нужно видеть в одной таблице с едиными правилами именования и валютой.
2. Нужна история глубже, чем отдаёт коннектор — особенно по поисковым запросам и по изменениям структуры.
3. Данные из трёх и более систем (реклама + CRM + биллинг + колл-трекинг) в одном отчёте.
4. Нужны сложные расчёты: когортный анализ, окупаемость по дням с момента первого клика, маржинальность по товарам.

В этот момент Looker Studio перестаёт быть местом, где данные соединяются, и становится тем, чем должен быть — витриной поверх готовой модели. Как устроен перенос в хранилище, сколько это стоит и где в модели данных Google Ads считают дважды — в разборе выгрузки Google Ads в BigQuery.

Отдельно стоит сказать про полноту самих конверсий. Если тег не досчитывает заказы, никакая архитектура отчёта это не починит — дашборд просто аккуратно покажет неполные данные. В 2026 году у Google есть штатный механизм достройки: мультиисточниковые конверсии подключают CRM или базу заказов к существующему конверсионному действию и дозаполняют пропуски по transaction ID. Это работа не отчётности, а измерения, и делать её нужно до того, как строить дашборд.

ИИ-отчёты и Looker Studio: что кому поручать

В 2026 году у Google появились AI-дашборды внутри самого кабинета: отчёт по текстовому запросу, без конструктора. Соблазн закрыть ими задачу велик, но функции разные. Диалоговый отчёт хорош для разовой проверки гипотезы («покажи кампании, где CPA вырос больше чем на 30% за две недели»). Он плох как постоянная отчётность: его нельзя зафиксировать, он не хранит вашу бизнес-логику и не умеет отличать модельные данные от наблюдаемых — об этом подробно в материале про AI-дашборды в Google Ads и то, чему в них верить.

Разделение, которое работает: Looker Studio — постоянный контур (одни и те же метрики, одни и те же правила, сравнение периодов), ИИ-отчёты — разведка внутри аномалии, которую этот контур подсветил.

Приёмка дашборда: чек-лист из двенадцати пунктов

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

1. Часовой пояс источника совпадает с часовым поясом аккаунта.
2. Валюта отчёта подписана прямо на дашборде.
3. Расход за закрытый месяц сходится с кабинетом до копейки.
4. Конверсии за закрытый месяц сходятся с кабинетом.
5. Свежие 1–2 дня либо исключены, либо подписаны как неполные.
6. У всех элементов страницы один унаследованный диапазон дат.
7. Все расчётные метрики живут на уровне источника, а не внутри графиков.
8. Для каждого blend проверено: сумма расхода не изменилась после смешения.
9. Брендовый и небрендовый трафик разделены.
10. На каждой странице есть подпись «данные обновлены время».
11. Отчёт открывается меньше чем за пять секунд.
12. Доступы выданы по принципу минимальной достаточности: просмотр — всем, редактирование — одному-двум людям.

Последний пункт недооценивают. Отчёт, который может править кто угодно, через полгода превращается в набор чужих экспериментов с формулами. Особенно это важно при работе с внешними подрядчиками и на агентских аккаунтах Google Ads, где несколько человек смотрят на одни и те же данные: отчётность должна быть одна, а право её менять — у одного владельца.

Пять ошибок, которые стоят денег

Ошибка 1. Сравнивать неполный период с полным

«За эту неделю CPA вырос на 40%» — классика, если неделя ещё не закончилась, а конверсии продолжают догружаться. Решение: сравнивать только закрытые периоды, либо «первые N дней периода» с «первыми N днями предыдущего».

Ошибка 2. Считать средний CPA по кампаниям

Среднее арифметическое от столбца CPA — не CPA аккаунта. Правильно: суммарный расход разделить на суммарные конверсии. В Looker Studio это значит, что CPA должен быть вычисляемым полем из агрегатов, а не средним по строкам. Ошибка тихая: цифра выглядит правдоподобно и всегда смещена.

Ошибка 3. Смотреть на конверсии, не понимая, какие именно это конверсии

Столбец «Конверсии» показывает только те действия, у которых включён флаг «учитывать в столбце Конверсии». Если в аккаунте первичные и вторичные конверсии настроены иначе, чем вы думаете, дашборд покажет не ту цифру, по которой принимаются решения о ставках. Проверять нужно в кабинете, в настройках конверсионных действий, а не в отчёте.

Ошибка 4. Одна модель атрибуции в кабинете, другая в голове

Google Ads отдаёт конверсии в своей модели атрибуции, а вы читаете их как last click. На каналах, где много ассистирующих показов, расхождение с реальностью достигает десятков процентов. Разбор моделей и того, как они переписывают историю, — в материале про модели атрибуции DDA против last click.

Ошибка 5. Строить дашборд раньше, чем починено измерение

Самая дорогая. Красивый отчёт на кривых данных опаснее отсутствия отчёта: он создаёт уверенность. Порядок работ всегда один: сначала конверсионные действия и их полнота, потом разметка и именование, потом отчётность. Попытка начать с третьего шага гарантированно приводит к тому, что через месяц отчёт придётся переделывать целиком.

Что сделать на этой неделе

1. Открыть существующий дашборд и сверить расход и конверсии за прошлый закрытый месяц с кабинетом. Записать расхождение в процентах.
2. Если расходится — пройти по таблице семи причин сверху вниз, начиная с часового пояса.
3. Вынести все формулы из графиков на уровень источника.
4. Проверить каждый blend на задвоение: сумма расхода до и после смешения.
5. Добавить подпись источника, валюты и времени обновления на каждую страницу.
6. Исключить последние два дня из основных виджетов или подписать их как неполные.

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

Если отчётность — часть более широкой задачи по запуску и масштабированию платного трафика, посмотрите, что ещё закрывается на стороне инфраструктуры: сервисы и инструменты для работы с Google Ads.

FAQ: дашборд Google Ads в Looker Studio

Почему расход в Looker Studio меньше, чем в Google Ads?

В 90% случаев причина одна из трёх: разный часовой пояс источника и аккаунта, устаревший кэш (данные ещё не обновились) или фильтр на уровне элемента, про который забыли. Проверяйте в этом порядке — расхождение в целые сутки почти всегда часовой пояс.

Можно ли подключить несколько аккаунтов Google Ads в один источник?

Да, через подключение на уровне управляющего аккаунта (MCC). Но если у суб-аккаунтов разные валюты, Google сведёт их в валюту MCC по своему курсу, и сумма не совпадёт с отдельными кабинетами. Для точной юнит-экономики надёжнее подключать аккаунты по одному.

Как часто обновляются данные в Looker Studio?

По расписанию кэша, которое задаётся в настройках источника (data freshness), а не при каждом открытии отчёта. Значения по умолчанию различаются у разных коннекторов и меняются со временем, поэтому их стоит проверить в настройках конкретного источника. Для ежедневных решений интервал уменьшают, для еженедельной отчётности — увеличивают ради скорости.

Почему после blend сумма расхода выросла?

Ключ соединения неуникален хотя бы с одной стороны: на каждую строку слева нашлось несколько справа, и метрика размножилась. Лечится агрегацией обеих таблиц до одинаковой гранулярности (обычно «дата + кампания») до соединения.

Какой тип соединения выбирать для связки рекламы и CRM?

Почти всегда left outer с рекламой слева: так вы видите все кампании, включая те, что не принесли ни одной продажи. Inner join молча выбросит убыточные кампании, и отчёт покажет ROAS лучше реального.

Сколько данных помещается в Extract Data?

До 100 МБ и до 750 000 строк. При превышении размера извлечение падает с ошибкой, при превышении числа строк данные обрезаются без явного предупреждения — это опаснее, потому что отчёт выглядит рабочим.

Почему конверсии за вчера всё время меняются?

Google Ads относит конверсию к дате клика, а не к дате самой конверсии. Пользователь кликнул вчера, а купит через неделю — и вчерашний день будет дозаполняться всё это время. Поэтому свежие 1–3 дня нельзя показывать как факт.

Нужен ли платный коннектор вместо нативного?

Нативного достаточно, пока вы работаете с одним-двумя аккаунтами и стандартными срезами. Платные коннекторы покупают ради автоматической сшивки многих рекламных систем и более глубокой истории. Если задача именно в объединении трёх и более источников, чаще дешевле и надёжнее собрать витрину в BigQuery.

Можно ли в Looker Studio посчитать прибыль, а не выручку?

Да, но только если вы сами принесёте маржу. Создайте вычисляемое поле с коэффициентом маржи и считайте маржинальный ROAS. Если маржа различается по товарам, одним коэффициентом не обойтись — нужна выгрузка себестоимости и соединение по товару, а это уже уровень хранилища.

Почему отчёт грузится по двадцать секунд?

Обычно это сочетание трёх вещей: много элементов на одной странице, несколько blend, пересчитываемых на лету, и длинный период дат. Лечится извлечением данных (Extract Data), разнесением по страницам и сокращением числа виджетов на первом экране.

Как давать доступ к отчёту клиенту?

Выдавайте доступ на просмотр к отчёту, а не к источникам данных, и проверьте, в каком режиме учётных данных настроен источник: от владельца (клиент видит данные без собственного доступа к аккаунту) или от зрителя (клиенту нужен свой доступ). Право на редактирование оставляйте одному-двум людям.

С чего начать, если дашборда ещё нет?

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