אינטגרציית פלטפורמת Galxe לקווסטים: הגדרת קווסטים ו-OAT

מדוע האינטגרציה עם Galxe נשברת בשלב חלוקת הפרסים

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

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

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

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

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

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

מה נותנת מכניקת קווסט מנוהלת וכיצד למדוד אותה

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

הראשון — שיעור הזיכויים האוטומטיים. בתחילת הקמפיין הוא נשמר סביב 60–70%: חלק מהמשימות דורש בדיקה ידנית — הרשמות, דוחות, פעילות מחוץ לרשת. לאחר הגדרת הכללים וחיבור הבדיקות למקורות נתונים, השיעור עולה מעל 95%, ופעולות ידניות נשארות רק לחריגים.

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

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

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

אינטגרציה עם Galxe: אילו מצבי חיבור לבחור

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

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

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

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

תארו את המשימה — נחזור עם הערכה ותוכנית עבור המצב הנבחר.

סדר העבודה: מביקורת קמפיינים ועד מסירת ההגדרות

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

1. ביקורת התרחישים הקיימים — רשימת הקווסטים, סוגי הפרסים והשלבים; מסמנים כפילויות, חפיפות בזמנים ומקומות שבהם הזיכוי נשען על עריכה ידנית.
2. סכמת הנתונים של הקווסט — ישויות וקשרים: קמפיין, שלב, תנאי השלמה, פרס, חלון פעילות, מכסה למשתתף; מסמנים אילו שדות מגיעים ממערכות חיצוניות.
3. בניית התנאים — מתרגמים את הדרישות לכללים ברי-בדיקה: סף הפעולה, סדר השלבים, הגבלת זמן, מעבר חוזר.
4. הרצת בדיקה על קבוצה קטנה — רשימת ארנקים סגורה והרצת כל הענפים: השלמה, אי-השלמה, חזרה, ביטול, חלוקת הפרס.
5. קבלה — משווים את יומן הזיכויים להיגיון הצפוי, בודקים חלוקות כפולות ותקינות הסטטוסים אצל המשתתף.
6. מסירת ההגדרות והדרכת הצוות — הרשאות, תיאור הקמפיינים ותקנון: כיצד להוסיף קווסט, לשנות תנאי, לעצור חלוקה.

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

מה נמסר לידיים: קונפיגורציות, סכמות, תקנונים

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

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

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

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

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

היכן נתקעו

ההשוואה הידנית יצרה שלושה אפקטים בבת אחת. זמן חלוקת הפרס נמתח ל-3–4 יממות, ומשתתף שהשלים את התנאים בתוך דקה חיכה לו כמעט שבוע; שגיאות בהעברת כתובות הגיעו ל-4–6% מהחלוקות, ומקרים שנויים במחלוקת כמו «העסקה עברה, אך הסימון לא נספר» עברו לתמיכה. פניות בנוגע לפרסים תפסו עד 40% מכלל ההודעות בקמפיין, והזרם לא פחת עם גידול הפעילות.

מה הועבר לבדיקה אוטומטית

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

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

במה נבדל קווסט בדומיין שלכם מקמפיין ב-Galxe?

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

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

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

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

ספקות טכניים: מכסות, כפילויות וביטול פרסים

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

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

מה לעשות אם הפלטפורמה משנה כללים?

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

כיצד אתם מחשבים מחדש תוצאות אם נמצאה שגיאה?

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

האם אפשר לבטל פרס ומה עם היציבות של הקמפיין?

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

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

נדון במשימה: מה נדרש להערכת קמפיין קווסט

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

שלחו או הציגו בשיחה:

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

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

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