Дашборди Dune Analytics: де ламається аналітика ончейн-даних
Покажемо типовий збій. Керівництво просить цифри щодо транзакцій та унікальних адрес за квартал одразу за кількома мережами. Інженер вивантажує CSV з оглядача блоків, зводить у таблиці вручну, чистить дублі. Відповідь іде через три-чотири дні — і частина цифр на той момент уже застаріла.
Щойно одну метрику рахують двоє людей, ончейн-аналітика перетворюється на звірку. Різняться моменти знімка: в один звіт потрапив блок до, в інший — після.
Різняться мітки адрес: біржовий гаманець, казначейство, контракт у кожного свої, тому «активний користувач» у двох звітах означає різне.
Окремий головний біль — внутрішні перекази й токени. Одна подія дає кілька рядків або не дає жодного, розрядність токенів різна, і суми в ручних вивантаженнях не сходяться до третього знака. Звірити це постфактум майже неможливо: вихідне вивантаження вже перезаписано.
Ціна такої схеми — не лише години інженерів. Рішення ухвалюються за даними тижневої давності, а звітність щодо транзакцій не можна відтворити — отже, вона не аргумент у розмові з інвестором або аудитом.
Дашборди Dune Analytics прибирають саме ручне складання: запити йдуть до декодованих таблиць, метрика описана один раз і оновлюється за розкладом, довідник міток адрес спільний для всіх. Нижче розбираємо, де саме ламається аналітика блокчейн-даних і чим це закривається.
Dune Analytics під задачу: що змінюється в роботі команди
Дашборд на Dune Analytics — це не набір графіків, а шар доступу до ончейн-даних. Метрики ончейн описуються один раз — у запитах поверх індексованих таблиць і матеріалізованих представлень, — і будь-який звіт бере вже пораховане значення. Єдине джерело даних знімає питання «чиїй цифрі вірити на зустрічі».
Швидкість підготовки звіту змінюється в рази. Раніше вивантаження збиралося вручну з кількох місць і на момент презентації встигало застаріти; тепер оновлення йде за розкладом, а період, мережа й адреса контракту задаються параметром панелі. Новий напрям додається окремим блоком, без перезбирання всього дашборда й повторної звірки цифр.
Аналітика під задачу прибирає цілий клас помилок — розходження ручного зведення. Поки метрика рахувалася в особистій таблиці в кожного аналітика, дві команди отримували різні значення через різні фільтри, округлення й момент знімка. Коли формула закріплена в спільному шарі, спір іде про трактування показника, а не про арифметику.
Навантаження на інженерів падає: питання на кшталт «скільки було за минулий період» і «як змінювалася частка активних адрес» закриваються доступом до кастомних дашбордів, без разових вибірок і правок у коді.
Ми описуємо метрики, пороги й розмежування доступу, а команда далі працює з цифрами самостійно — без посередника у вигляді розробника.
Готові шаблони, кастомні панелі чи власний індекс: що вибрати
Аналітика на Dune Analytics будується на трьох рівнях, і вибір між ними — це вибір того, хто відповідає за шар даних: платформа, ми в панелі поверх готових таблиць або ми в завантаженні й моделі. Різниця проявляється не в графіках, а в тому, які питання до даних узагалі можна поставити.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Публічний шаблон | Метрика типова: обіги протоколу, припливи й відпливи, активність адрес | Розрахунок заданий автором шаблону — свій фільтр, свою метрику або внутрішні мітки до нього не додати |
| Кастомна панель на готових даних | Потрібен власний розріз і подача, а вихідні таблиці вже завантажені й оновлюються платформою | Обмежена доступними наборами й затримкою їх оновлення; розходження з внутрішнім обліком не закрити |
| Власна модель даних із регулярним завантаженням | Потрібні поля, яких немає в публічних наборах: розмітка адрес, внутрішні ідентифікатори, дані своєї інфраструктури | Потребує супроводу: контроль кожного завантаження, усунення дублів, перерахунок історії, оповіщення про пропуски |
Вибір іде від питання, а не від інструмента. Якщо метрика збігається з типовою — шаблон закриває задачу й майже не потребує підтримки. Коли справа в подачі й розрізах, достатньо кастомної панелі поверх готових таблиць.
Власна модель потрібна там, де дані доводиться збирати й нормалізувати самим: тоді панель стає надбудовою, а основна робота переходить у завантаження й якість — розбираємо це на етапі оцінки.
Етапи роботи: від аудиту даних до передачі дашборда
Робота починається не з графіків, а з питань: які рішення ухвалюються за метриками й що ми вважаємо правильним відповіддю. Далі панель збирається як сервіс — зі схемою даних, перевірками чисел і версіонуванням запитів, щоб результат можна було відтворити, передати й розвивати.
- Розбір питань бізнесу. Фіксуємо рішення, які ухвалюватимуться за панелями, і перетворюємо їх на список метрик з однозначним визначенням кожної — без «активності загалом» та інших розмитих формулювань.
- Аудит джерел даних. Перевіряємо, які таблиці Dune Analytics покривають потрібні контракти й події, чи є декодовані логи й чи повна історія з моменту запуску. Якщо покриття немає — описуємо, що доведеться декодувати самостійно.
- Схема метрик. Для кожної цифри задаємо формулу: які події беремо, які адреси виключаємо (бридж, казначейство, боти), як рахуємо унікальних учасників і як обходимо дублі під час перерахунку.
- Складання панелей. Пишемо запити, налаштовуємо графіки, фільтри за мережами й періодами, додаємо підписи з визначеннями метрик — щоб ту саму цифру не можна було витлумачити двозначно.
- Перевірка збіжності метрик. Звіряємо підсумки із сирими даними й незалежними джерелами, розходження розбираємо до причини, а не згладжуємо округленням або звуженням періоду.
- Передача дашборда. Віддаємо доступи, документацію, запити з коментарями, навчаємо команду й залишаємо порядок правок на випадок зміни контрактів.
Кожен етап залишає артефакт: визначення метрики, запит, результат звірки. Це знімає головну проблему аналітики в блокчейні — коли різні панелі рахують те саме по-різному, і довіри немає до жодної.
Що залишається у вас: документація, схеми й регламенти
Передаємо не лише доступи, а й увесь контекст, за яким дашборд аналітики на Dune живе далі без нас. Це робоча документація, а не папка з вивантаженнями: за нею новий аналітик розгортає звітність і розуміє, звідки взялася кожна цифра.
- Модель метрик — що рахує кожен показник: формула, джерело, гранулярність, які сегменти виключено. Розходження у звітах розбирається за цим описом, а не з пам’яті автора.
- Схема даних — зв’язки між таблицями, ключі з’єднань і місця, де виникають дублі; окремо зазначено, як ми їх знімаємо під час зведення.
- Правила доступу до даних — ролі й розмежування за рядками та зрізами, порядок надання прав і їх відкликання, включно з виходом співробітника.
- Регламент оновлення метрик — періодичність перезбирання, хто підтверджує зміну формули, що робимо під час правки джерела.
- Каталог перевірок якості — тести на пропуски, від’ємні значення та розриви в рядах. Перевірка падає раніше, ніж викривлену цифру побачить керівництво.
- Інструкції для команди — як додати метрику, виправити запит, подивитися історію збірок і відкотитися на попередню версію.
- Журнал змін — версія запиту, автор і причина правки, щоб через пів року було зрозуміло, чому метрика рахується саме так.
Комплект пишеться мовою вашої команди й оновлюється разом зі звітом: будь-яка зміна формули спершу потрапляє в документацію, потім у дашборд.
Кейс: як зросла швидкість звітності за ончейн-метриками
Замовник — продукт з активністю в мережі: перекази, розподіл держателів, динаміка за контрактами. Звіти за цими метриками збирали вручну — вивантаження з оглядачів блоків, звірка адрес, зведення в таблицях.
Тижневий зріз займав два робочі дні аналітика, а будь-яка правка на прохання керівника запускала збір заново.
Втрати були не у швидкості вивантаження, а в узгодженні визначень. Той самий показник рахували по-різному для звіту й для внутрішньої панелі, тому цифри між документами розходилися: на звірку йшов ще день.
Кожне нове питання на кшталт «скільки було активних адрес за минулий місяць» перетворювалося на окрему задачу з нуля — з тією самою ручною роботою.
На Dune зібрали єдиний шар запитів: визначення метрик зафіксували один раз, багаторазово використовувані таблиці оновлюються за розкладом, поверх них — панелі під конкретні ролі. Потім порівняли метрики до й після.
| Що вимірювали | До | Після |
|---|---|---|
| Підготовка тижневого звіту | 2 робочі дні | 3 години |
| Оновлення панелі після запиту | 1–2 дні | хвилини |
| Розходження цифр між звітами | регулярні | зведені до нуля |
| Нова метрика у звітності | 1–2 дні | 2–4 години |
Швидкість підготовки звітів перестала залежати від завантаження аналітика: панель відкривається будь-якої миті, а не раз на тиждень. Правки визначень тепер робляться в одному місці й одразу видно в усіх зрізах. Звільнений час команда витрачає на розбір даних, а не на їх зведення.
Що робити, якщо звітність уже зібрана на іншій платформі?
Звітність на іншій платформі — не привід її ламати.
Поки старий контур вважається коректним, він залишається джерелом істини, а новий росте поруч: міграція аналітики майже ніколи не проходить за один день, бо моделі запитів, довідники й логіка агрегатів переїжджають порціями, і на кожному кроці метрики мають сходитися з попередніми в зрозумілих межах.
Форматів переходу три, і вибір визначається тим, як часто змінюються визначення метрик і хто ухвалює рішення за цифрами.
Практичний орієнтир: за живих визначень метрик починаємо з паралельного контуру — він дає запас на звірку; за стабільної логіки поетапне перенесення дешевше за часом інженерів; повне перенесення виправдане, коли старий контур уже не читають.
Переносимо дашборди з фільтрами й розрізами, документуємо розходження між Dune і попередньою платформою та ведемо звірку, поки ключові показники не збіжаться.
Сумніви щодо навантаження, доступів і підтримки дашбордів
Дашборди на Dune Analytics — це SQL-запити поверх індексованих блокчейн-даних і вітрин, які ми збираємо самі. Нижче — чотири питання, які найчастіше виникають перед прийманням: приватність, поведінка звітів під час зростання обсягів, права доступу й супровід.
Наскільки захищені наші дані?
Публічні мережі відкриті й так, тому приватність стосується внутрішніх вітрин: адрес, міток клієнтів, розрахунків за портфелем. Їх тримаємо в закритому просторі команди, доступ видаємо за сервісними ключами з мінімальними правами, а в зовнішні дашборди йдуть лише агрегати.
Що буде зі звітами під час зростання обсягів?
Важкі запити сканують мільйони рядків і впираються в ліміт часу. Ми матеріалізуємо проміжні таблиці, перераховуємо лише нові блоки й виносимо агрегати в окремі вітрини — графіки відкриваються швидко, а глибина історії не гальмує оновлення.
Як розмежувати доступ між командами?
Права налаштовуємо на трьох рівнях: простір, запити, окремі дашборди. Аналітик бачить вихідні таблиці, менеджер — лише графіки, підрядник — конкретний набір запитів. Ролі описані в конфігурації й переносяться в новий акаунт без ручного переналаштування.
Хто підтримує дашборди після здачі?
Індексатори змінюють схему подій, контракти оновлюються — запити без супроводу ламаються тихо. Передаємо документацію щодо кожного запиту, ставимо оповіщення про невдалі оновлення й правимо логіку за змін у контрактах.
Обговоримо вашу задачу й повернемося з планом робіт
Щоб оцінка дашборда була предметною, для першої розмови достатньо короткого вступного — решту уточнимо на онлайн-зустрічі. Нижче те, що допомагає одразу побачити обсяг робіт з аналітики й не витрачати зустріч на збір базових даних.
- Метрики й питання: які показники потрібні й яке рішення за ними ухвалюється — від цього залежить гранулярність запитів і склад візуалізацій.
- Джерела: мережі, адреси контрактів і пули гаманців, за якими рахуємо; чи є готові вивантаження для звірки.
- Доступ: ключ до Dune з правами лише на читання, ролі в репозиторії й тестові запити, якщо аналітика вже ведеться.
- Періодичність і глибина: як часто оновлюються дані та за який період потрібна історія.
- Читачі: хто відкриває дашборд і який висновок має винести — ризик-команда, продуктова чи зовнішні партнери.
- Формат видачі: чи потрібен експорт у таблиці й регулярна розсилка або достатньо сторінки з фільтрами та зрізами.
На онлайн-зустрічі розберемо, як звіряємо цифри з даними в мережі, як обробляємо перезбирання блоків і пізні транзакції, де проходить межа між ончейн-метриками й розрахунковими.
Після цього повернемося з планом робіт з аналітики: склад запитів, етапи, порядок приймання й те, що ви зможете підтримувати власними силами. Опишіть задачу — обговоримо її й повернемося з оцінкою та планом.
