דשבורדים של 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 עם הרשאות קריאה בלבד, תפקידים במאגר הקוד ושאילתות בדיקה, אם האנליטיקה כבר מתנהלת.
- תדירות ועומק: באיזו תכיפות הנתונים מתעדכנים ואיזו תקופה של היסטוריה דרושה.
- קוראים: מי פותח את הדשבורד ואיזו מסקנה הוא אמור לקחת — צוות סיכונים, צוות מוצר או שותפים חיצוניים.
- פורמט המסירה: האם דרוש ייצוא לטבלאות ותפוצה סדירה, או שדי בעמוד עם פילטרים וחתכים.
בשיחה נפרק איך מתאימים את המספרים לנתונים ברשת, איך מטפלים בהרכבה מחדש של בלוקים ובטרנזקציות מאוחרות, ואיפה עובר הגבול בין מדדי אונצ'יין למדדים מחושבים. אחר כך נחזור עם תוכנית עבודה באנליטיקה: הרכב השאילתות, השלבים, סדר הקבלה ומה שתוכלו לתחזק בכוחות עצמכם. תארו את המשימה — נדון בה ונחזור עם הערכה ותוכנית.