Looker не спасает плохую модель: 7 проверок перед запуском дашборда

Looker не спасает плохую модель: 7 проверок перед запуском дашборда

Если Looker стал «красивой витриной», а не рабочим BI, проблема обычно не в графиках. Проблема в слоях: данные, метрики, права, поиск и договорённость о том, кто и зачем открывает дашборд.

Проверьте 7 вещей: — одна метрика = одно определение; — в explores нет дублей с разной логикой; — фильтры отвечают на вопрос, а не украшают интерфейс; — row-level access реально режет лишнее; — heavy joins не убивают скорость; — названия полей читаются без словаря; — в каждом дашборде есть владелец, а не «все понемногу».

Что чаще всего используют ежедневно: общие KPI, разрезы по каналам, воронка, spend/CPA/ROAS, качество лидов, cohort-метрики. Что обычно фон: десятки сырых полей, красивые, но пустые графики, «на всякий случай» таблицы и вторые копии одного и того же отчёта.

Что убрать: дублирующие explores, метрики без action point и дашборды, где за минуту нельзя понять, надо ли что-то менять. Что добавить: описание метрики прямо в LookML, SLA на обновление и один экран для алертов, а не отдельную свалку уведомлений.

Если команда не может объяснить дашборд за 30 секунд, его надо упрощать, а не расширять.