<b>Looker Studio ломается не на графиках, а на плохой структуре источника</b>

<b>Looker Studio ломается не на графиках, а на плохой структуре источника</b>

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

Что проверять в источнике:
— date должен быть датой, а не строкой
— revenue, sessions, users — числовые поля без форматирования
— campaign / source / medium — отдельные измерения, без склейки в одно поле
— null лучше заменить на явное значение, чем оставлять пустоту

Если подключаете BigQuery, делайте витрину под отчёт, а не тащите сырую событийнюю таблицу напрямую. Сырые события удобны для анализа, но для Looker Studio нужен слой, где уже посчитаны основные метрики, убраны дубли и нормализованы названия. Иначе любой фильтр превращается в маленький баг-репорт.

Ещё одна типовая ошибка — считать в самом отчёте то, что можно посчитать заранее. Формулы в Looker Studio хороши для простых преобразований, но не для тяжёлой логики, дедупликации и сложных условий. Чем меньше магии в карточках и таблицах, тем проще поддержка.

<b>Если отчёт должен жить долго, сначала проектируйте таблицу, а потом дашборд.</b>