Метрики до дашборда: с чего начинать BI-проект

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

Сразу о рамке. Клиентских историй про то, как три отдела считали выручку тремя способами, здесь не будет: те, что у меня есть, я описать не могу, а выдумывать нельзя. Все примеры ниже из моего собственного измерительного контура. Это небольшая, но настоящая аналитическая система: витрина со своими источниками, расписанием сборки и владельцем. Она про сайт и инфраструктуру, а не про выручку и маржу, но ошибки в ней ровно те же, что в любом BI-проекте. И за четыре месяца с июня она показывала мне неправду как минимум семь раз. Все цифры сверены 26 сентября 2026 года.

Экран не решает спор о цифрах

Обычная история: в компании спорят, сколько у неё клиентов или какая выручка за квартал, потому что у продаж одно число, а у финансов другое. Решение напрашивается: собрать всё в один дашборд, и спор закончится. Он не заканчивается. Он переезжает на новый экран, где теперь одно число, и обе стороны по-прежнему считают его неправильным.

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

Мой контур маленький, но настоящий

Для сайта у меня есть витрина: таблица, где на каждую пару русской и английской страниц приходится строка. Сейчас в ней 151 строка и 78 колонок: адреса, даты, попадание в карту сайта, индексация в Google и Яндексе, оценка SEO, внутренние ссылки, структура текста и ещё десятки признаков. Собирается она скриптом из нескольких источников: самого WordPress, модуля переводов, карты сайта, Google Search Console, Яндекс Вебмастера и плагина Rank Math. Результат синхронизируется в Google Таблицы.

Рядом работают автоматические проверки: 39 критических, от целостности разметки до того, что страницы действительно отдаются, и еженедельный отчёт, который уходит мне в Telegram. То есть у этой системы есть всё, что есть у корпоративного BI: несколько источников, регулярная сборка, витрина, отчёт и владелец. Ниже то, что она показывала неправильно, и почему.

Витрина свежая, а колонка заморожена с июля

Это главный пример, и я нашёл его, когда собирал цифры для этой статьи. Число страниц, проиндексированных в Google по русской версии, в витрине равно 53. Оно равно 53 с 23 июля 2026 года. С тех пор витрину пересобирали десятки раз, последний раз вчера, а число не сдвинулось ни на единицу. Английское стоит на 48, Яндекс на 138, тоже с 23 июля.

Причина прозаическая. Доступ к Google Search Console пропал при переносе рабочего окружения, а сборка витрины устроена разумно: если источник недоступен, она не затирает колонку нулями, а сохраняет прежнее значение. Это правильное решение, иначе одна сетевая ошибка обнуляла бы всю историю. Но у него есть следствие: дата сборки витрины перестала совпадать с датой данных в колонке. Таблица говорит «собрано вчера», и это правда. Колонка индексации при этом двухмесячной давности, и нигде это не написано.

Дальше хуже. За это время на сайте стало больше страниц: было 139 строк, стало 151. Новые строки приходят без данных об индексации, числитель стоит на месте, знаменатель растёт, и доля проиндексированных страниц сама ползёт вниз: с 38 процентов до 35. Посмотрев на это, легко решить, что индексация ухудшается, и начать её чинить. На самом деле о ней с июля не известно ничего.

Вывод, который я из этого делаю: у каждой метрики должна быть своя дата «по состоянию на», и показывать её надо рядом с числом, а не одну на всю таблицу. В моей витрине этого пока нет, и число 53 ровно следствие этого.

Ноль, который означал «нет данных»

В начале июня колонка индексации в Яндексе неделю показывала ноль из 131. Не потому, что Яндекс не проиндексировал ни одной страницы, а потому, что источник ещё не был подключён. 8 июня его подключили, и число за один день стало 130.

Ноль и «нет данных» это разные значения, а в таблице они выглядят одинаково. Если в колонке, где ожидаются числа, появляется ноль из-за неподключённого источника, любой, кто посмотрит, прочитает его как факт. В BI-проекте это самая частая причина паники на пустом месте: отчёт показывает ноль продаж за день, а на деле за этот день просто не загрузились данные. Пустое значение должно быть пустым и выглядеть пустым.

Одно слово, три разных числа

В витрине есть три колонки, которые в разговоре одинаково называют «проиндексировано». В карте сайта 151 страница из 151. В индексе Яндекса 138. В индексе Google 53. Все три числа верны, и ни одно не противоречит другим, потому что это три разных вопроса: что я сообщил поисковикам, что взял Яндекс и что по данным консоли взял Google.

Спор начинается, когда кто-то говорит «проиндексировано 150 страниц», а кто-то «проиндексировано 53», и оба правы. Это та же история, что с выручкой по счетам и по оплатам. Метрике нужно не название, а определение: откуда берётся, что именно считается, на какую дату. «Проиндексировано» без указания источника это не метрика, а повод для спора.

Зелёный ответ, который ничего не сделал

Одно время я отправлял новые страницы в Google через Indexing API. На каждый запрос API отвечал успехом: «принято». Если записывать это в витрину как «отправлено на индексацию», таблица зеленеет. Проверка показала другое: сразу после такого «принято» запрос статуса этой же страницы отвечал «не найдено».

Документация Google пишет об этом прямо: Indexing API можно использовать только для страниц с разметкой вакансий или трансляций. Для обычных статей запрос принимается и ничего не запускает. С тех пор в витрине этот статус записывается как «принято», а не как «проиндексировано» и не как «отправлено». Разница в одном слове, но именно она отделяет факт от надежды.

Правило, которое из этого выросло: успешный ответ означает только то, что запрос дошёл. Всё, что должно было случиться после, проверяется отдельно. В корпоративном BI это выглядит как «задача загрузки завершилась успешно», при том что загрузилось ноль строк.

Слово «день» тоже требует определения

У того же API есть суточная квота. Я запланировал разовый запуск на 04:30 по UTC, чтобы на следующий день отправить остаток страниц, и получил 139 отказов по превышению лимита и ни одного успешного запроса. Причина: суточная квота Google сбрасывается в полночь по тихоокеанскому времени, а не по UTC и не по местному. В 04:30 по UTC у Google ещё шли предыдущие сутки, и их лимит был исчерпан.

Это кажется мелочью, пока не попадает в отчёт. «Продажи за день» в системе, которая считает день по UTC, и в бухгалтерии, которая считает по местному времени, расходятся на все заказы, сделанные ночью. Граница суток, недели и месяца это часть определения метрики, а не настройка сервера.

У числа должен быть один адрес

Оценка SEO, которую плагин Rank Math показывает в редакторе, считается в браузере и хранится в собственной таблице плагина, а не в метаданных записи, где её обычно ищут. Если читать не оттуда, получается другое число или никакого. В витрине оценка берётся ровно из того места, где её хранит сам плагин, и это место записано рядом с кодом.

В компании то же самое выглядит как выручка, которая есть и в учётной системе, и в CRM, и в выгрузке для инвестора, и везде немного разная. У каждой метрики должно быть одно каноническое место, откуда она берётся. Все остальные копии производные, и когда они расходятся с каноническим, права каноническая.

Правильное число, которое приходит поздно

В июне на сайте было 96 страниц-сирот, на которые не ведёт ни одна внутренняя ссылка. Я расставил полторы сотни ссылок, опубликовал и сразу пересчитал: сирот стало 89. Выглядело так, будто работа почти ничего не дала. На деле граф ссылок в плагине обновляется не сразу, а с задержкой. Сейчас сирот 58.

Число 89 было правильным для того момента и неправильным для решения. Если бы я по нему решил, что метод не работает, я бы бросил метод, который работает. У каждой метрики есть задержка между событием и его отражением, и её надо знать до того, как смотреть на число. Решение по метрике, которая ещё не догнала реальность, это решение по прошлому.

Определение меняет число сильнее, чем данные

Однажды проверка показала, что у 29 страниц нет призыва к действию. Я начал разбираться и выяснил, что проверка неверна: по-настоящему битая ссылка была одна. Двадцать девять было не свойством сайта, а свойством правила подсчёта.

Второй случай из той же серии. Проверка повторяющихся ссылок сначала считала, сколько разных страниц ссылается на цель, и видела немного проблем. Когда правило поменяли на «сколько раз одна статья ссылается на одну и ту же цель», из текстов ушло 270 лишних ссылок. Данные не изменились ни на байт. Изменилось определение, и число выросло в сотни раз.

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

Метрика, которая врёт в половине случаев

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

Такую метрику нельзя делать показателем эффективности, «довести расхождения до нуля». Её правильное место в списке на ручной разбор: она хорошо находит кандидатов и плохо выносит вердикты. В BI-проекте так же: часть метрик это сигналы, которые надо смотреть глазами, а не цели, которые надо выполнять. Если их перепутать, люди начнут исправлять число, а не то, что оно должно было показывать.

Зелёный экран при мёртвых страницах

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

Метрика «сайт доступен» измеряла не сайт, а кэш. Она была точной, свежей и совершенно бесполезной. Исправление было не в метрике, а в её определении: проверка теперь обходит кэш и ищет на странице текст критической ошибки. Раз в неделю отдельно обходится вся карта сайта. Вопрос «что именно мы измеряем» оказался важнее вопроса «как часто».

Что из этого следует для BI-проекта

Все случаи выше про одно: число было правильно посчитано и неправильно понято. Поэтому BI-проект у меня начинается с документа, а не с инструмента. Для каждой метрики в нём записано:

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

Инструмент выбирается после этого документа, и тогда выбор становится простым. Power BI, Tableau или обычная таблица решают одну и ту же задачу, если определения записаны, и одинаково бесполезны, если нет.

Проект данных начинается с человека, а не с хранилища

Второе правило со страницы услуги: «не оставляю систему, которую некому вести: если в компании нет человека, отвечающего за данные, предлагаю начать с него, а не с хранилища». Оно следует из первого. Определения метрик меняются вместе с бизнесом, источники отваливаются, как отвалился доступ к Search Console, и кто-то должен это заметить.

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

Чего я сознательно не делаю

• Не строю дашборды до согласования определений. Иначе спор просто переезжает на новый экран.
• Не показываю число без даты «по состоянию на». Дата сборки таблицы не равна дате данных в колонке.
• Не записываю «принято» как «сделано». Успешный ответ означает, что запрос дошёл, и больше ничего.
• Не превращаю сигнальные метрики в цели. Иначе люди начинают исправлять число.
• Не оставляю систему без владельца. Если отвечать за данные некому, начинать надо с этого человека.
• Не выдумываю клиентские истории для примеров. Все случаи в этой статье из моего собственного контура.

Стек

• Google Search Console и Яндекс Вебмастер: источники данных об индексации.
• Rank Math: оценка SEO и граф внутренних ссылок.
• Python: сборка витрины из всех источников.
• Google Таблицы: витрина для просмотра.
• Ansible: автоматические проверки и еженедельный отчёт.

Почему это важно тому, кто платит

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

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

Частые вопросы

С чего начинать BI-проект?

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

Почему дашборд не решает спор о цифрах?

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

Чем опасна метрика без даты?

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

Почему нельзя показывать ноль, когда данных нет?

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

Нужен ли Power BI или Tableau для начала?

Нет. Если определения записаны, Power BI, Tableau и обычная таблица решают одну задачу, и выбор делается по удобству и стоимости. Если определений нет, одинаково бесполезен любой инструмент.

Кто должен отвечать за метрики?

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

Источники

• Google Indexing API: только для страниц с разметкой вакансий и трансляций.
• Квоты Indexing API: суточная квота сбрасывается в полночь по тихоокеанскому времени.
• Отчёт об индексировании в Search Console: что Google считает проиндексированным.

Нужна консультация?

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