פרסור נתוני אוספי NFT: מחיר רצפה, נפח מסחר, מחזיקים ואנליטיקה

פרסינג NFT: מדוע נתוני האוספים חלוקים בין מקורות

כששתי פלטפורמות מציגות לאותו אוסף מחיר מינימלי שונה, הבעיה בדרך כלל אינה בטעות של אוסף הנתונים. כל מקור נתונים של NFT מתעד תמונת מצב משלו של השוק: המוכר הסיר את הלוט בין השאילתות, חלק מהעסקאות בוצעו מחוץ לספר הציבורי, השער חושב מחדש בזמן אחר. פערי המדדים מצטברים דווקא מפני שמשווים דברים שאינם זהים.

המקור השני לפערים — היעדר היסטוריה. ממשקים ציבוריים מחזירים מצב נוכחי ולעיתים רחוקות מאפשרים לשחזר מה היה המחיר המינימלי לפני יום, כמה כתובות החזיקו באוסף לפני חלוקה גדולה, וכיצד השתנה נפח המסחר לאחר ההכרזה.

פרסינג NFT לפי לוח זמנים נותן נקודות בודדות בגרף, אך את הרווחים ביניהן יש להשלים בדמיון — דווקא שם מתרחשות התנועות החדות.

השלישי — ייצוא ידני. בזמן שנתוני אוספי NFT מרוכזים בטבלה, חלק מהשורות מתיישנות, אותה כתובת נכנסת פעמיים לרשימת המחזיקים, ואיש לא הפעיל מסננים לעסקאות חשודות. משם המספרים האלה ממשיכים לדוחות ולהחלטות: הערכת בטחונות, כניסה לפוזיציה, הכרזה על מכירה.

המסקנה המעשית פשוטה: איסוף מהימן אינו סקריפט אחד, אלא צינור עם הגדרה אחידה של המדד, יומן שינויים ותיעוד של רגע הדגימה. בהמשך נסביר איך זה בנוי.

מה נותן צינור איסוף מכויל של מדדי שוק

ייצוא ידני נשבר בנקודות החיבור: floor price נלקח ברגע אחד, volume — ברגע אחר, ורשימת holders מגיעה מצילום מצב בן שבוע. בדוח המספרים האלה עומדים זה לצד זה וסותרים זה את זה — החלטות מתקבלות לפי מספרים שמעולם לא התקיימו בו-זמנית.

צינור נתוני NFT נבנה סביב תמונת מצב אחת: מסנכרנים בלוק, פורשים אירועי מרקטפלייס — ליסטינגים, עסקאות, ביטולים — ומהם מחשבים נגזרות. Floor price ו-volume לכל אוסף מחושבים מחדש מאותה חתכה, ולכן בתצוגת המדדים הם מתואמים בזמן, ולא מודבקים ממקורות שונים בזה אחר זה.

נתוני הגלם נלקחים מצמתים פתוחים ברשת ומתצוגות מרקטפלייס, כולל OpenSea — עם ניסיונות חוזרים ותור לעיבוד מחדש של רשומות כשלוניות.

שלמות היסטוריית המכירות נשענת על כתיבה אידמפוטנטית: מפתח «עסקה + לוג» לא מאפשר להכפיל את הנפח במעבר חוזר לאחר ניתוק. פער שזוהה נסגר בחישוב מחדש של הקטע — התצוגה מגיעה לאותו מצב כמו באיסוף רציף, בלי תיקונים ידניים ו"נתקן בטבלה".

בפלט — תצוגת מדדים אחת במקום כמה ייצואים ידניים, עם הגדרות שדות זהות וחתכות מתואמות. פערים בין דוחות נעלמים כקטגוריה: המקור אחד. אוטומציה של אנליטיקת NFT סוגרת גם את הבעיה השנייה — פערים וחוסר סנכרון נתפסים בבדיקות תקופתיות, ולא בידי אנליסט יום לפני הגנת המספרים.

מצבי איסוף נתונים: השוואת גישות ומגבלות

שלמות והשהיה — דרישות שמושכות לכיוונים מנוגדים: ככל שהאירוע טרי יותר, כך יש בו פחות הקשר, וחישוב היסטוריה עמוק נתקל במגבלות בקשות. לכן מצב האיסוף נבחר לפי המדד: מחיר מינימלי ונפח מסחר דורשים טריות, ואילו מחזיקים והיסטוריית עסקאות — שלמות.

בפועל, לרוב עובד איסוף היברידי: מנויי זרימה נותנים תגובה מיידית לעסקאות ולהעברות, וסריקה תקופתית של ממשקים ציבוריים משלימה את החסר ומחלקת פערים. אינדקסר עצמאי מחברים כשצריך חתכות נגזרות — מחזיקים ייחודיים, התפלגות לפי ארנקים, מחיר ממוצע בחלון תצפית.

את המצב מתעדים לפני תחילת העבודה: לכל מדד מציינים מקור, השהיה מותרת והתנהגות בעת כשל. אז התמונה לא מתפרקת כשמשתנה פורמט התשובה או כשיש אי-זמינות זמנית של הפלטפורמה.

שלבי העבודה: מביקורת מקורות ועד מסירת נהלים

סדר השלבים זהה גם לאוסף גדול וגם לקבוצת חוזים עם לוגיקה לא סטנדרטית: קודם מנתחים את המקורות, אחר כך מתעדים סכימה, ורק לאחר מכן מגדירים פרסינג של אוספי NFT. אם מדלגים על שני השלבים הראשונים, מחיר מינימלי, נפח מסחר ומחזיקים מתחילים להיחשב לפי חתכות שונות ומפסיקים להתאים זה לזה.

1. ביקורת מקורות נתונים. בודקים אילו פלטפורמות ואינדקסרים מוסרים מידע, עובדים דרך ממשק תוכנה ציבורי או זרם אירועים, באיזו השהיה ואילו מגבלות על קצב הפניות. בנפרד מתעדים אם קיימת היסטוריית עסקאות ובאיזה עומק.

2. סכימת נתוני האוסף. מתארים ישויות — אוסף, טוקן, עסקה, בעלים, אירוע — המפתחות שלהן, הקשרים וכללי הסרת כפילויות. חתכות נשמרות לפי תאריכים, כדי שאפשר יהיה לחשב מחדש כל מדד לתקופה קודמת.

3. הגדרת איסוף מדדים. קובעים מה מחשבים (מחיר מינימלי, נפח, מחזיקים, התפלגות לפי ארנקים), באיזו תדירות, וכיצד מטפלים בחסרים ובכפילויות בעת כשלי מקור.

4. בדיקת התאמה. משווים את התוצאה לערכים ציבוריים של הפלטפורמות ומנתחים פערים, בנפרד בודקים אירועים נדירים: ביטול עסקה, מכירה מחוץ לפלטפורמה, העברה בין ארנקים אישיים.

5. מסירת נהלים וליווי. מוסרים תיאור סכימה, לוח זמנים לאיסוף, רשימת מדדי בקרה וסדר פעולות בעת כשל. בהמשך עוקבים אחר שלמות הנתונים ושינויים בצד הפלטפורמות, כדי שפערים לא יגיעו לדוחות.

מה נשאר אצל הלקוח: ארטיפקטים ותיעוד

צינור איסוף נתונים עבור אוספי NFT אינו סקריפט חד-פעמי למשימה מסוימת, אלא מערכת ארטיפקטים שנשארת פיזית במעגל הלקוח. אנחנו מוסרים אותם יחד עם הסבר, כדי שמהנדס הלקוח יוכל להוסיף אוסף, לשנות לוח זמנים או לחשב מחדש היסטוריה בלעדינו.

• תצורות איסוף. כתובות חוזים של אוספים, רשימת פלטפורמות, לוח זמנים לסקירה, מגבלות בקשות וכללי ניסיונות חוזרים בעת כשל — נערכים בקובץ הגדרות, בלי שינוי בקוד.
• סכימות נתונים. תיאור ישויות: אוסף, טוקן, עסקה, מחזיק. מפתחות, קשרים, סוגי שדות, פורמט אחסון — לפי הסכימה אפשר לחבר כל כלי אנליטי מעל התצוגה.
• מילון מדדים. floor price, נפח מסחר, מספר מחזיקים, קונים ייחודיים: לכל מדד — נוסחה, חלון אגרגציה ומקור. זה מסיר את הכאב העיקרי של אנליטיקה כשהמספרים בשני דוחות אינם תואמים.
• נהל עדכון נתונים. תדירות סקירה, פיגור מותר של התצוגה מהרשת, סדר חישוב מחדש של היסטוריה לאחר כשל וכללי חיתוך כפילויות.
• הרשאות ותפקידים. חשבונות שירות עם הרשאת קריאה בלבד, רוטציית מפתחות, הפרדה בין שכבת גלם לשכבת אגרגציה: אנליסט עובד עם התצוגה, אך אינו יכול לשנות את הצינור.
• תיעוד הצינור. תרשים זרימות, נקודות כשל, הוראות להפעלה מחדש של שלב בודד וסדר חיבור אוסף חדש.

משלימים במעקב טריות: התראה נשלחת אם התצוגה מפגרת אחרי הרשת ביותר מהמרווח שהוגדר. התוצאה — איסוף עובד וסט מלא של חומרים כדי להפעיל אותו בכוחות עצמך.

מקרה בוחן: איסוף מדדי אוסף בלי ייצוא ידני

מקרה בוחן של אנליטיקת NFT, שבו איסוף ידני הפריע להחלטות: אוסף של 10,000 טוקנים גדל מהר יותר מכפי שהצוות הספיק לעדכן מספרים.

מחיר מינימלי ונפח מסחר נאספו ידנית ממרקטפלייסים, מספר המחזיקים חושב לפי חתכת כתובות מ-Etherscan, והיסטוריית העסקאות חייתה בייצואים מפוזרים — העברה בין ייצואים פשוט אבדה. הדוח נמשך שעות, ועד הפרסום הנתונים התיישנו ביממה.

מה הוחלף באיסוף

במקום ייצואים הותקן מנוי לאירועי החוזה עם אינדוקס מחדש בעת ארגון מחדש של שרשרת הבלוקים: מחזיקים מחושבים מחדש באופן מצטבר לפי העברות, הנפקה ושריפה נלקחות בחשבון בסימנים נפרדים. נפח המסחר נבדק מול ההעברות — פער מעל סף שהוגדר מעלה אזהרה, ולא נכנס לדוח בשקט.

שלמות ההיסטוריה גדלה עד לכל העסקאות מרגע ההנפקה, תדירות חישוב המדדים — משבוע לדקות, ולא נותרו פעולות ידניות במחזור. הדוח נבנה מעצמו, והזמן שהתפנה עבר לניתוח במקום לאיחוד טבלאות.

פרסינג NFT: ממשקים ציבוריים או אינדקסר עצמאי?

תשובה קצרה: ממשקים ציבוריים — נקודות תצפית על בלוקים כמו Etherscan ותצוגות מרקטפלייסים — מכסים את שכבת הסקירה: floor price נוכחי, נפח מסחר לתקופה, מספר מחזיקים ברגע השאילתה. ברגע שצריך שלמות היסטוריה לכל טוקן באוסף או עומק נתונים מעבר למרקטפלייסים, החתכה הציבורית נגמרת.

את האינדקסר בונים סביב אירועים: קוראים בלוקים, מפרסרים לוגים של חוזי האוסף, מנרמלים לסכימה «טוקן — בעלים — אירוע — בלוק» ושומרים צילומי מצב של מחזיקים.

Floor price מחשבים בעצמנו לכל מרקטפלייס, תוך התחשבות נפרדת בעמלות, מטבע החישוב ועסקאות שבוטלו — לכן אותו מדד במקורות שונים מפסיק להיות שונה.

עלות התחזוקה של הפתרון גם היא שונה. ממשקים ציבוריים לא דורשים תשתית, אבל את המגבלות, השהיות העדכון והחסרים בזמן ארגון מחדש של השרשרת צריך לטפל אצלך — בבדיקות ובשאילתות חוזרות. לאינדקסר דרושים צומת עם היסטוריה מלאה, מקום לאירועים וסדר לאינדוקס מחדש בשינוי לוגיקה.

הקריטריון נגזר מייעוד המדד. אם הוא נדרש בסקירה ו«עכשיו» — די במקורות פתוחים. אם הוא משתתף בהחלטה (הערכת בטחונות, דירוג אוסף, איזון מחדש אוטומטי) — דרושה היסטוריה ניתנת לשחזור, ובלי אינדקסר עצמאי אי אפשר להשיג אותה.

ספקות טכניים: שלמות, מגבלות, השהיות

ספקות הנדסיים אופייניים לפני פרסינג של אוספי NFT הם אותם ספקות: האם נתקל במגבלות של פלטפורמות, עד כמה טריים המספרים שנקבל, מה יקרה להיסטוריה כשמשתנה סכימת התשובה. בהמשך — כיצד הסיכונים האלה סגורים בארכיטקטורת האיסוף.

עד כמה מעוכבת התעדכנות המדדים?

הזרמים מופרדים: floor price ופעילות מסחר מתעדכנים בחלון קצר, holders והרכב המחזיקים — לפי אישור עסקאות, שם השהיה של דקות היא נורמלית. לכל אינדיקטור חלון העדכון שלו, ובדוח מתועד הרגע שאליו מתייחסים המספרים — אין ערכים «בערך טריים» בלי חתימת זמן.

הפלטפורמה שינתה את סכימת התשובה — הנתונים יאבדו?

תשובות גלם נשמרות, והניתוח מתבצע בשכבת נרמול נפרדת: שינוי שמות שדות או הוספת שדות חדשים לא שוברים היסטוריה שכבר נאספה. בשינוי סכימה מתקנים את ההמרה ומחשבים מחדש מדדים לתקופות קודמות מהתשובות השמורות — הגרפים נשארים רציפים. שלמות נשמרת באמצעות הסרת כפילויות לפי מזהה טוקן וזמן עסקה, ובנוסף בדיקת שלמות הסריקה.

נדון במשימה: תוכנית איסוף נתונים לאוסף שלך

מה צריך לדעת על המקורות שלך כדי לבנות תוכנית איסוף נתונים לאוסף מסוים: איזו פלטפורמה נחשבת לעוגן ל-floor, היכן נמצאים המטא-נתונים של הטוקנים, האם דרושה היסטוריית עסקאות או רק חתכה נוכחית. מזה תלויים סכימת סקירת המקורות, תדירות העדכון ואילו מדדים מחושבים נכון.

• כתובות חוזים של האוסף והרשתות שבהן הם פרוסים — בלי זה אי אפשר לבנות סריקת מחזיקים;
• רשימת פלטפורמות ואגרגטורים שאת מחיריהם לוקחים כעוגן ל-floor;
• עומק ההיסטוריה: עסקאות לכל תקופת חיי האוסף או חלון של החודשים האחרונים;
• תדירות עדכון נדרשת לתצוגה — פעם ביום, פעם בשעה או לפי אירוע הנפקה ומכירה;
• מדדים בדוח: floor, נפח, מחזיקים ייחודיים, התפלגות לפי ארנקים, חיתוך עסקאות פיקטיביות;
• לאן לשמור את התוצאה — בסיס נתונים משלך, טבלאות או פאנל דיווח חיצוני;
• מגבלות הרשאה: מפתחות של שירותים חיצוניים, צמתים משלך, מגבלות בקשות.

לאחר הדיון נשלח הערכת פרויקט: הרכב העבודות לפי שלבים, תרשים מקורות עם נתיבי גיבוי, טיוטת מודל נתונים וסט בדיקות לפערים מול הפלטפורמה.

הצעד הבא — שיחה קצרה לעניין: אתם מתארים את המשימה, ואנחנו חוזרים עם הערכה ותוכנית איסוף נתונים לאוסף שלכם, עם לוחות זמנים ונקודות בקרה.