Налаштування Dune Analytics: де ламається ручний збір даних
Ручний збір метрик із мережі тримається, доки йдеться про один гаманець і один звітний період.
Щойно у звітність потрапляють десятки контрактів, кілька мереж і щоденні зрізи, ручна робота перестає масштабуватися: вивантаження робляться в різний час, з різною глибиною історії та з різними припущеннями про те, що взагалі вважати транзакцією.
Далі починається не аналітика, а розбір того, чому в двох відділів цифри за один місяць не збігаються.
Першим ламається оновлення. Поки вивантаження наздоганяє мережу, у звіті живе вчорашня картина: затримка оновлення даних накопичується, і рішення ухвалюються за цифрами, які вже не описують те, що відбувається.
На активних контрактах, де за добу проходять тисячі подій, ручний перерахунок не встигає за мережею в принципі — аналітик закриває минулий період рівно в момент, коли той перестав бути актуальним.
Друге — розбіжності у звітності. Два зрізи за один період не сходяться, бо в одному враховано невдалі транзакції, в іншому лише підтверджені; в одному перекази між своїми адресами пораховані двічі, в іншому вирізані.
Метрика обростає винятками, які живуть у чиїйсь таблиці, і суперечка точиться вже не про стратегію, а про методику підрахунку.
Налаштування Dune Analytics закриває саме цю частину: запити на SQL виконуються поверх уже проіндексованих даних блокчейну, тому метрика рахується один раз і за одним визначенням. Мережа оновилася — оновився й результат запиту, без ручних вивантажень і звірок.
Дашборд та API віддають ті самі числа, які бачать інженери, і розбіжності залишаються лише там, де справді розійшлися очікування щодо методики, а не там, де розійшлися дати вивантаження.
Що змінюється після впровадження: вимірюваний ефект
Ефект від Dune вимірюється на рівні процесу, а не «стало зручніше». До впровадження нове питання до блокчейн-даних — це окреме вивантаження, ручна звірка й день-два очікування; після — запит поверх уже проіндексованих контрактів, який відповідає за хвилини. Аналітик перестає бути вузьким місцем, і черга запитів від продукту більше не накопичується.
Частка ручних операцій падає передбачувано. Оновлення вітрин переводиться на розклад, перерахунок метрик іде за одним і тим самим запитом, і людина не «докручує» цифри в таблиці перед зустріччю. Звільнений час іде на формулювання метрик, а не на їхній збір.
Збіжність цифр — окремий клас відмов, який закривається архітектурно. Коли дашборди та API читають з однієї моделі даних, розбіжність між звітом для інвесторів і внутрішнім зрізом зникає за побудовою: обидві сторони рахують одну величину з одного джерела. Правка вноситься в одному місці, а не в п'яти таблицях.
Швидкість отримання метрик стає властивістю системи, а не героїзму конкретного інженера. Новий дашборд за проіндексованими даними збирається за години, а API віддає ті самі агрегати, що й візуальний шар, — без другої реалізації логіки. Це і є перевірюваний результат: менше ручних кроків, швидша відповідь, одна версія правди.
Підходи до збору метрик: порівняння варіантів
Три рівні збору відрізняються не зручністю, а тим, хто відповідає за коректність цифр і як швидко правка доходить до звіту: готові публічні запити, власні запити на зовнішній платформі та повністю власний збір даних.
Готові запити дають швидкий старт: схему контрактів не потрібно описувати вручну. Але логіку фільтрів задав автор — список адрес, пороги, вікно агрегації ви не контролюєте.
У разі зміни контракту такий дашборд мовчки показує неповну картину, і помітити це можна лише за розбіжністю з незалежним джерелом.
Три варіанти та їхні межі
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Готові публічні запити | Потрібен швидкий перший зріз: обсяги, активні адреси, динаміка за днями | Фільтри й пороги задав автор, затримка оновлення, немає гарантій після зміни контракту |
| Власні запити в Dune | Потрібні свої метрики й контроль над формулою, є людина, яка впевнено пише SQL | Обмеження джерел: не всі мережі та події проіндексовані, глибину історії диктує платформа |
| Власний збір даних | Потрібні дані поза індексаторами та свій зріз за внутрішніми системами | Своя команда та інфраструктура: вузли, зберігання, переіндексація за кожного оновлення контракту |
На практиці беруть гібрид: базові метрики живуть на платформі, а критичні для рішень дублюються власним збором. Тоді розбіжність між двома контурами стає окремою перевіркою — її видно на панелі до того, як цифри підуть у звіт.
Етапи налаштування: від аудиту джерел до передачі
Починаємо з аудиту джерел: звіряємо контракти й пули з тим, що вже проіндексовано в Dune, і визначаємо, де вистачить готових таблиць, а де потрібне декодування журналів подій. Уже на цьому кроці видно, які метрики реально зібрати, а які доведеться рахувати наближено.
- Аудит джерел. Перелік мереж, адрес і підтверджених таблиць — опора для всіх наступних запитів.
- Схема даних і метрик. Домовляємося, що означає «активна адреса», «обсяг» і «когорта»: без єдиних визначень цифри на панелі не збігатимуться з внутрішнім обліком.
- Написання запитів. SQL з параметрами за періодами й мережами; перевикористовувані розрахунки виносимо в окремі представлення, щоб панелі не дублювали логіку.
- Перевірка збіжності. Звіряємо вибірки з незалежним джерелом і розбираємо розбіжності до їх усунення — лише після цього цифрам можна довіряти.
- Складання панелей. Дашборд під конкретні рішення: динаміка, розподіл, великі учасники, а не графіки заради графіків.
- Передача доступів. Ролі в робочому просторі, інструкція щодо запитів і метрик, порядок правок без нашої участі.
Кожен етап закривається артефактом: перелік джерел, документ з визначеннями метрик, перевірений набір запитів, готові панелі. Передача не перетворюється на усну розповідь — результат можна підтримувати власними силами.
Артефакти: запити, панелі, регламенти, доступи
Аналітика тримається не на графіках, а на обв'язці навколо них — коді запитів, описах полів і правах. Без цього за місяць ніхто не пояснить, звідки у звіті взялася цифра, а будь-яке доопрацювання доведеться починати з нуля. Тому результат роботи фіксуємо в артефактах, які залишаються у вашої команди.
- Набір запитів — по одному на показник, з розбивкою за контрактами, пулами й періодами. У шапці кожного зазначено, які таблиці та фільтри використовуються і чому відсічено службові операції.
- Панелі та графіки — зведена панель для керівництва й детальні для аналітиків: обсяги, активні адреси, концентрація у великих тримачів. Періоди й визначення єдині, тому цифри на різних екранах збігаються.
- Довідник метрик — таблиця «показник → формула → джерело даних → власник». Знімає суперечки на кшталт «у нас інший обсяг»: обидві команди рахують за одним визначенням.
- Політики доступу — ролі на читання, правку й публікацію, прив'язка до корпоративних облікових записів, окремий контур для зовнішніх підрядників.
- Регламент оновлення — розклад перерахунку, перелік зовнішніх залежностей, порядок дій у разі збою джерела або зміни схеми, а також періодична звірка ключових цифр із незалежним джерелом.
- Інструкція із супроводу — як додати новий показник, де лежать версії запитів, кому повідомляти про розбіжність. Новий аналітик включається без листування з нами.
Комплект передаємо в робочий простір Dune і в репозиторій замовника з історією правок: будь-яку метрику можна відкотити до попередньої версії або показати, що саме в ній змінилося. Доступи оформлюємо на ваші облікові записи, щоб аналітика не залишилася прив'язаною до нас.
Кейс: розбіжності у звітності скоротили до нуля
Вихідна картина: дані за кількома контрактами збиралися вручну — інженери вивантажували операції з оглядача мережі в таблиці, зводили в електронній таблиці й уже звідти збирали звіт для керівництва.
За місяць виходило близько 40 ручних вивантажень, на підготовку йшло дві доби, а розбіжності між звітом і даними мережі сягали 6–8% — частина транзакцій губилася під час копіювання, частина враховувалася двічі після внутрішніх переказів.
Що змінили
Логіку розрахунку перенесли в Dune і розклали на шари. Сирі таблиці блоків, логів подій і викликів контрактів нормалізуються в проміжних SQL-представленнях: приводимо адреси до одного регістру, розмічаємо внутрішні перекази флагом, відсікаємо реверсовані транзакції.
Поверх — матеріалізовані агрегати за адресами, токенами й пулами з перерахунком за номером блоку, тому будь-яка цифра відтворюється на будь-яку дату, а не «на момент вивантаження».
Дашборд і API віддають ті самі агрегати, тобто внутрішня звітність і зовнішні запити рахуються з одного джерела.
Результат у метриках
Ручні вивантаження скоротилися з 40 до нуля — залишилася лише щомісячна звірка двох контрольних сум. Частка розбіжностей пішла в нуль і тримається протягом усіх проведених звірок: розбіжність тепер означає помилку в моделі, а не в ручній роботі, і ловиться тестом до публікації.
Новий звіт — за новою мережею, токеном або періодом — збирається за 2–4 години замість двох діб, бо перевикористовуються готові представлення, а не перезбирається ланцюжок вивантажень.
Чим відрізняється готова панель від власного збору даних?
Готова панель платформи Dune відповідає на типові питання швидко: дані вже проіндексовані, метрики пораховані, зріз за обсягами й активними адресами видно того ж дня.
Межа настає там, де потрібен свій зріз — частка гаманців із повторними операціями або стик активності з даними продукту. У чужій вітрині такий зріз або не з'явиться, або рахуватиметься за чужою логікою.
Власний збір даних — це власний розрахунковий шар: свої визначення метрик, своя глибина історії, свій графік перерахунку.
Команда сама відповідає за свіжість і повноту, за перерахунок у разі оновлення контрактів і за те, щоб метрика не розійшлася після зміни схеми на боці платформи. Натомість — контроль над даними та зміни за днями, а не за терміном чужого релізу.
Вибір зводиться до трьох режимів:
| Варіант | Коли підходить | Що обмежує |
|---|---|---|
| Готова панель платформи | Потрібен швидкий огляд: обсяги, активні адреси, рух за великими контрактами | Набір метрик заданий платформою; свій зріз і стик із даними продукту недоступні; правки — за графіком релізів |
| Власний збір і зберігання | Потрібні свої визначення метрик, глибока історія, зв'язка з внутрішніми системами | Потрібен інженер на підтримку: перерахунок індексів, контроль свіжості та пропусків |
| Гібрид: панель плюс власний шар | Огляд береться готовим, критичні метрики рахуються й зберігаються в себе | Визначення метрик потрібно синхронізувати, інакше цифри в панелі та у своєму шарі розійдуться |
Практичний критерій простий: якщо аналітика потрібна для огляду ринку — вистачає готової панелі. Якщо цифри йдуть у звітність, ризик-моделі або продуктові рішення, потрібен власний шар, інакше розбіжність у визначенні метрики спливе в момент суперечки про цифри.
Часті технічні сумніви перед стартом
Розбираємо сумніви, які найчастіше звучать до старту. Вони стосуються не самого Dune, а поведінки даних в експлуатації: швидкості індексації, змін логіки контракту, достовірності цифр і розмежування доступів.
Наскільки дані відстають від останнього блоку?
Налаштування Dune Analytics не прибирає затримку індексації: між підтвердженням блоку та його появою в запиті минає від секунд до десятків хвилин — залежить від мережі та глибини підтверджень.
Для оперативного контролю ми читаємо стан безпосередньо з вузла, а аналітичні вітрини будуємо на історії, де затримка не критична.
Контракт оновили — звіти продовжать працювати?
Зміна логіки ламає метрики мовчки: адреса та сама, а події та їхні параметри інші.
Ми фіксуємо адреси й сигнатури в конфігурації, перевіряємо появу нових сигнатур і версіонуємо запити — після оновлення видно, які панелі поїхали, замість виявлення розбіжності у звіті для керівництва.
Як переконатися, що цифри правильні?
Верифікація цифр будується не на довірі до дашборда. Звіряємо агрегати з незалежним джерелом, перевіряємо збіжність сум за адресами й періодами, додаємо тести на відомі транзакції та контроль цілісності — розбіжність спливає на етапі складання, а не на захисті бюджету.
Як віддавати дані назовні й не відкрити зайвого?
Доступ через програмний інтерфейс віддаємо окремим ключам з обмеженим набором запитів, а не повними правами на робочий простір.
Секрети зберігаємо в захищеному сховищі, розмежовуємо ролі на читання й правку, ведемо журнал звернень — у разі витоку ключа його відкликають без перезбирання всієї аналітики.
Обговоримо задачу: що потрібно від вас для старту
Для першої розмови не потрібен готовий документ із вимогами — достатньо того, що вже є під рукою.
Нижче список, який закриває майже всі питання щодо налаштування аналітики на Dune: з ним ми повертаємося не з уточненнями, а з оцінкою термінів, схемою шарів даних і планом за етапами.
- Доступи до даних: адреси контрактів за мережами, список гаманців, пулів або токенів, права на читання у внутрішніх системах — якщо частина розрахунку йде за вашими даними, а не лише за мережею.
- Перелік питань, на які звіт має відповідати: розподіл капіталу, рух за адресами, звіт для фонду або моніторинг ризиків. Від цього залежить набір метрик і деталізація.
- Приклади звітів: поточні вивантаження, таблиці, скриншоти старих панелей. Навіть незручний формат показує, які зрізи й розрізи вам справді потрібні.
- План робіт: як часто дані мають оновлюватися і хто їх дивиться — щоденний моніторинг і місячний зведений звіт для інвесторів збираються різними шарами.
- Оцінка термінів: дата, до якої потрібен перший результат, і чи є жорстка прив'язка до події — звітності, угоди, запуску продукту.
- Відповідальний на вашому боці, хто підтвердить логіку розрахунку метрик і прийме результат після завершення етапу.
Цього достатньо, щоб стартувати: решту добираємо на розмові. Опишіть задачу — повернемося з оцінкою, схемою робіт і планом, де перший робочий звіт ви побачите задовго до закриття всієї задачі.
