Кастомные дашборды аналитики на Dune: разработка под ключ

Дашборды Dune Analytics: где ломается аналитика ончейн-данных

Покажем типовой сбой. Руководство просит цифры по транзакциям и уникальным адресам за квартал сразу по нескольким сетям. Инженер выгружает CSV из обозревателя блоков, сводит в таблице вручную, чистит дубли. Ответ уходит через три-четыре дня — и часть цифр к этому моменту уже устарела.

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

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

Цена такой схемы — не только часы инженеров. Решения принимаются по данным недельной давности, а отчётность по транзакциям нельзя воспроизвести — значит, она не аргумент в разговоре с инвестором или аудитом.

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

Dune Analytics под задачу: что меняется в работе команды

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

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

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

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

Готовые шаблоны, кастомные панели или свой индекс: что выбрать

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

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

Этапы работы: от аудита данных до передачи дашборда

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

1. Разбор вопросов бизнеса. Фиксируем решения, которые будут приниматься по панелям, и превращаем их в список метрик с однозначным определением каждой — без «активности в целом» и прочих размытых формулировок.
2. Аудит источников данных. Проверяем, какие таблицы Dune Analytics покрывают нужные контракты и события, есть ли декодированные логи и полна ли история с момента запуска. Если покрытия нет — описываем, что придётся декодировать самостоятельно.
3. Схема метрик. Для каждой цифры задаём формулу: какие события берём, какие адреса исключаем (бридж, казначейство, боты), как считаем уникальных участников и как обходим дубли при пересчёте.
4. Сборка панелей. Пишем запросы, настраиваем графики, фильтры по сетям и периодам, добавляем подписи с определениями метрик — чтобы одну и ту же цифру нельзя было истолковать двояко.
5. Проверка сходимости метрик. Сверяем итоги с сырыми данными и независимыми источниками, расхождения разбираем до причины, а не сглаживаем округлением или сужением периода.
6. Передача дашборда. Отдаём доступы, документацию, запросы с комментариями, обучаем команду и оставляем порядок правок на случай изменения контрактов.

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

Что остаётся у вас: документация, схемы и регламенты

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

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

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

Кейс: как выросла скорость отчётности по ончейн-метрикам

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

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

На Dune собрали единый слой запросов: определения метрик зафиксировали один раз, переиспользуемые таблицы обновляются по расписанию, поверх них — панели под конкретные роли. Затем сравнили метрики до и после.

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

Что делать, если отчётность уже собрана на другой платформе?

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

Форматов перехода три, и выбор определяется тем, как часто меняются определения метрик и кто принимает решения по цифрам.

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

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

Сомнения по нагрузке, доступам и поддержке дашбордов

Дашборды на Dune Analytics — это SQL-запросы поверх индексированных блокчейн-данных и витрин, которые мы собираем сами. Ниже — четыре вопроса, которые чаще всего возникают перед приёмкой: приватность, поведение отчётов при росте объёмов, права доступа и сопровождение.

Что будет с отчётами при росте объёмов?

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

Как разграничить доступ между командами?

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

Кто поддерживает дашборды после сдачи?

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

Обсудим вашу задачу и вернёмся с планом работ

Чтобы оценка дашборда была предметной, к первому разговору достаточно короткого вводного — остальное уточним на созвоне. Ниже то, что помогает сразу увидеть объём работ по аналитике и не тратить встречу на сбор базовых данных.

• Метрики и вопросы: какие показатели нужны и какое решение по ним принимается — от этого зависит гранулярность запросов и состав визуализаций.
• Источники: сети, адреса контрактов и пулы кошельков, по которым считаем; есть ли готовые выгрузки для сверки.
• Доступ: ключ к Dune с правами только на чтение, роли в репозитории и тестовые запросы, если аналитика уже ведётся.
• Периодичность и глубина: как часто обновляются данные и за какой период нужна история.
• Читатели: кто открывает дашборд и какой вывод должен унести — риск-команда, продуктовая или внешние партнёры.
• Формат выдачи: нужен ли экспорт в таблицы и регулярная рассылка или достаточно страницы с фильтрами и срезами.

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