מדוע תוכנית נאמנות של בורסת קריפטו אינה משמרת סוחרים
תוכנית נאמנות של בורסת קריפטו בדרך כלל נשברת לא במכניקת הבונוסים, אלא במודל הזיכוי. נקודות מוצמדות לאירוע בודד ביומן הפעולות — «העסקה בוצעה» — במקום באגרגט של פעילות מסחר לתקופת חישוב.
ברגע שסוחר מתחיל לעבוד בביצועים חלקיים, לבטל הזמנות, להעביר פוזיציות בין תתי-חשבונות או לסחור במקביל במספר מכשירים, אותו מחזור נספר פעמיים או לא נספר כלל.
אי-ההתאמה מצטברת בשקט: סוחר פעיל רואה יתרת תגמולים שאינה תואמת את המחזור האמיתי שלו. הוא מפרש זאת לא כתקלה, אלא ככללים לא הוגנים — ושימור הסוחרים קורס מהר יותר מאשר בהיעדר בונוסים בכלל.
לאחר מכן מצטרפת התמיכה: כל אי-התאמה יש לנתח ידנית, להצליב היסטוריית עסקאות ולתקן יתרה ישירות במסד הנתונים.
מכאן שני מדדים קשורים. העומס על התמיכה גדל ביחס למחזור, משום שכל פנייה דורשת הצלבה ידנית, ונטישת חשבונות פעילים — ביחס למספר ההסברים מסוג זה: עוזב לא מי שסוחר מעט, אלא מי שסוחר הרבה ואינו רואה על כך תגמול.
סיבה נפרדת לכך שזה לא נרפא בתיקון יתרה: חישוב מחדש שאינו קשור לתקופת חישוב ואינו מוגן מפני עיבוד חוזר של אותו אירוע מחזיר תיקונים ידניים במעבר הבא על היומן. נסביר כיצד זה נסגר.
מה מעניקה מערכת הנאמנות החדשה: השפעות מדידות
תוכנית נאמנות מפסיקה להיות טבלה נפרדת עם נקודות והופכת לחלק מיתרת המשתמש. זיכוי, חיוב והחלפת רמה פועלים ברגע העסקה, ולא בחישוב המחודש הבא בלילה, לכן הסטטוס באזור האישי תואם את היקף הפעולות בפועל.
התגמולים מחושבים בזמן אמת
כללים — היקף מסחר בחלון, החזקת כספים בחשבון, מספר חשבונות מופנים — נבדקים לפי אירוע ומיד משנים את המכפיל. ההשהיה בין הפעולה לזיכוי מתקצרת משעות לשניות, וזיכויים שנויים במחלוקת פוחתים.
שיעור החשבונות הפעילים והפקדות חוזרות
מכניקה צפויה מחזירה את המשתמש לעתים קרובות יותר: הוא רואה כמה נותר עד לרמה הבאה. שיעור החשבונות עם פעולות בחודש גדל, והפקדות חוזרות מפסיקות להיות תלויות בתפוצות ידניות — תרחישים קשורים להתנהגות, לא ללוח שנה.
התמיכה מתפנה
פניות בנוסח «לא זוכה» ו«מדוע השתנתה הרמה» נסגרות בעזרת היסטוריה שקופה: לכל זיכוי יש קישור לאירוע ולכלל שהופעל. העומס על קו ראשון יורד, וניתוח מקרים שנויים במחלוקת אורך דקות.
ההשפעה של מערכת הנאמנות מדידה: צמיחת מחזור הבורסה, שיעור החשבונות הפעילים, תדירות הפקדות חוזרות והיקף הפניות לתמיכה נראים בדוחות לפי קוהורטות. מקורות חיצוניים כמו Chainalysis עוזרים להצליב את הפעילות עם נתוני הרשת, כדי שהמדדים לא ייפרדו מהמציאות.
אפשרויות לבניית התוכנית: נקודות, רמות, מנויים
בחירת המכניקה נקבעת לא לפי עיצוב האזור האישי, אלא לפי האירוע שממנו נספר הזיכוי וכמה מהר גדל ההתחייבות של הבורסה. מערכת נקודות מזכה על פעולות, החזר חלק מהעמלה קשור למחזור בפועל, מנויי רמות — להחזקת יתרה ולהיקף מסחר בתקופת חישוב.
לכן המודל נבחר לפי פרופיל הלקוחות: שיעור הסוחרים עם מחזור גבוה, תוחלת החיים הממוצעת של הפיקדון, רגישות לגובה העמלה.
מגבלות צפות על פני השטח במפגש עם חשבונאות. אם רמות מחושבות מחדש בדיעבד, ונקודות והחזר עמלה מזוכים על אותה עסקה, נוצר תגמול כפול — רואים אותו רק בהצלבה. לכן מודל הזיכוי מקובע בכללים ומריצים אותו על נתונים היסטוריים לפני ההשקה.
| מכניקה | מתי מתאימה | מגבלות |
|---|---|---|
| מערכת נקודות | צריך לעודד פעולות ספציפיות: אונבורדינג, הזמנות, משימות | נקודות מאבדות ערך ללא סולם המרה ברור; קשה לחזות את היקף ההתחייבויות |
| החזר חלק מהעמלה | לקוחות רגישים לעלות העסקה וסוחרים בתדירות גבוהה | חותך ישירות את ההכנסות; ללא קישור למחזור אמיתי מעודד ניפוח מחזור |
| מנויי רמות | יש גרעין של לקוחות שמוכנים להחזיק יתרה לשם סטטוס | דורשים חישוב מחדש של הרמה לתקופה וטיפול נכון בירידת יתרה |
| מודל משולב: נקודות ורמות | צריך גם למשוך חדשים וגם לשמר פעילים | גדלה מורכבות הכללים וההצלבות; בלי מרשם זיכויים אחיד אי-התאמות בלתי נמנעות |
קריטריון מעשי אחד: המכניקה חייבת להיספר מתוך נתונים שהבורסה כבר שומרת, ולאפשר בדיקה ידנית של כל זיכוי.
שלבי ההטמעה: מביקורת נתונים ועד להשקה
הפרויקט מחולק לשלבים, משום שמחיר הטעות בזיכוי אינו דומה לשבוע שהושקע בהצלבה: מכפיל שגוי מתפשט על פני מאות אלפי אירועים ומתבטל ידנית. סדר העבודות בנוי כך שכל צעד הבא נשען על נתונים שנבדקו בשלב הקודם.
- ביקורת נתונים. ספירת מלאי של אירועים: עסקאות, הפקדות, משיכות, סטייקינג, קשרי הפניה, ביטולים והיפוכים. בודקים את עומק שמירת היומנים ואת שלמות המזהים שלפיהם האירוע נקשר למשתתף.
- סכימת זיכויים. רמות, מכפילים לפי מוצרים, ספי מעבר, תוקף נקודות, התנהגות בעת היפוך עסקה. מתארים זאת באופן הצהרתי, כדי ששינוי סף לא יצריך תיקון קוד.
- הגדרת אינטגרציות. מינוי לזרם אירועים דרך Kafka, הכתיבה אידמפוטנטית לפי מזהה האירוע — מסירה חוזרת אינה יוצרת זיכויים כפולים. ההשהיה בין האירוע לזיכוי הנקודות הופכת לפרמטר מדיד.
- בדיקת חישובים. הרצה על נתונים היסטוריים של מספר חודשים והצלבה עם תפוקות ייחוס לכל מוצר. אי-התאמת היעד — אפס; כל מה שלא מתלכד מנתחים עד הסיבה, ולא עד לסף סובלנות.
- השקה מבוקרת. תחילה מצב צל, שבו החישוב מתבצע במקביל לידני ללא זיכוי נקודות, אחר כך קבוצת משתמשים מוגבלת והפעלה הדרגתית על כל בסיס המשתמשים עם כיבוי נקודתי של כללים.
- מסירה. תיעוד הסכימה, פאנל ניטור אי-התאמות, נוהל לניתוח אירועים וגישות לקונפיגורציה — תיקון ספים כבר לא דורש אותנו.
מה מוסרים לידיים: סכימות, מדיניויות, נהלים
פרויקט תוכנית נאמנות אינו מסתיים בהשקה: בהמשך צוות הלקוח בעצמו משנה מקדמים, מנתח זיכויים שנויים במחלוקת ומשיב למשתמשים. לכן אנו מרכיבים ערכת ארטיפקטים שלפיה ניתן לנהל ולפתח את התוכנית בלעדינו, ומוסרים אותה לא כארכיון, אלא בדיון עם מי שיעסוק בכך.
- סכימת ארכיטקטורה: כיצד קשורים שירותי הזיכוי וחשבונאות הנקודות, היכן נמצאת היסטוריית הפעולות, אילו אירועים מגיעים מבחוץ ואילו נולדים בפנים.
- נוהל זיכוי: נוסחאות הרמות והחזר חלק מעמלת המסחר, תקופות חישוב, כללי עיגול, מגבלות למשתתף וסדר התאמות רטרואקטיביות כשהתנאים משתנים.
- מדיניויות גישה: תפקידים — תמיכה, אנליסט, קצין סיכונים, מפתח — ומה כל אחד רשאי לקרוא ולשנות, הפרדת סביבות, סדר הענקה ושלילת הרשאות.
- תיעוד אירועים: סיווג תקלות (זיכוי כפול, אי-התאמת יתרה, משיכת נקודות תקועה), סדר עצירת זיכויים, תרחישי ביטול ופיצוי.
- הנחיות לשירות התמיכה: נוסחי תשובות, עץ הסלמה, מה אפשר להבטיח למשתמש מיד ומה רק לאחר החלטת קצין סיכונים.
- נוהל דיווח: אילו מדדים נלקחים — שיעור המשתתפים הפעילים, היקף הזיכויים, מעברים בין רמות — וכיצד מצליבים אותם עם החשבונאות.
הקבלה מתבצעת במתחם בדיקות: צוות הלקוח בעצמו מריץ שינוי מקדמים וניתוח אירוע טיפוסי, כדי שאחרי המסירה לא יישאר «עובד, אבל לא ברור למה».
מקרה בוחן: החזרת סוחרים שעזבו וצמיחת פעילות
לפני הפרויקט תוכנית הנאמנות התבססה על חישוב מחודש באצווה בלילה: תגמולים על כל בסיס המשתמשים חושבו במשך כמה שעות, ואי-התאמה בין יתרת הסוחר ליומן הפעולות צפה רק בעקבות תלונה.
שיעור החשבונות הפעילים עמד על כשליש מהנרשמים, והתמיכה מדי חודש ניתחה מאות פניות זהות בנוגע לנקודות שלא זוכו.
| מדד | לפני | אחרי |
|---|---|---|
| שיעור החשבונות הפעילים בחודש | 31% | 54% |
| חישוב מחדש של תגמולים על כל בסיס המשתמשים | 6 שעות | 11 דקות |
| פניות לתמיכה בנוגע לזיכויים | 380 בחודש | 45 בחודש |
| הצלבת יתרות עם יומן הפעולות | ידנית, לפי תלונות | מדי יום, אוטומטית |
מה שינו בחישוב
את מסלול התגמול פרקו מהעסקה ועד לזיכוי: אירועי מסחר נכנסים לתור, הזיכוי נספר באופן אינקרמנטלי, וכל רשומה מקבלת מפתח אידמפוטנטי — עיבוד חוזר אינו מכפיל את היתרה.
את משיכת התגמולים הוציאו לרשת Polygon, שבה העמלה לא אוכלת סכומים קטנים: בתגמולים החלו להשתמש, ולא לצבור אותם עד למינימום לא נוח.
היסטוריית הזיכויים הוצגה באזור האישי, והתמיכה קיבלה גישה ליומן לפי מזהה הפעולה. זה הסיר את הסיבה העיקרית לנטישה: סוחר שלא הבין מאין הגיע המספר ביתרה просто הפסיק לסחור. בקרב מקטע מקבלי התגמולים הנטישה ירדה בצורה בולטת יותר מאשר בכלל הבסיס.
במה שונה מערכת נקודות ממנויי רמות?
מערכת נקודות ומנויי רמות נבדלות לא בעיצוב המסך, אלא במקום שבו נשמר מצב המשתמש. במקרה הראשון המכניקה צוברת זיכויים ביתרה: הנקודות מורכבות מעשרה מקורות — מחזור מסחר, הפניות מובאות, החזקת נכסים, השתתפות במבצעים. במקרה השני המצב הוא סטטוס עם תאריך סיום, שמחושב מחדש בחלון נע לפי אגרגט אחד.
מכאן ההבדל ביכולת החיזוי של החישוב. מערכת נקודות היא מולטיפליקטיבית: תיקון מקדם או מקור זיכוי חדש משנה את התוצאה אצל כל מי שכבר צבר נקודות, לכן נדרשים עיבוד אירועים אידמפוטנטי, דה-דופליקציה ושכבה נפרדת של חישוב מחדש — אחרת היתרה נפרדת מהיסטוריית הפעולות. מנוי רמות הוא דיסקרטי: מעבר בין רמות נספר לפי סף בחלון, התוצאה משוחזרת ומוסברת למשתמש בשורה אחת.
עלות התמיכה נובעת מאותו דבר. נקודות יוצרות זרם פניות «זיכו פחות ממה שציפיתי»: כדי לנתח כל אחת, המהנדס צריך יומן זיכויים עם מקור ומקדם לכל אירוע. מנויים יוצרים זינוק בפניות בגבול התקופה ובעת הורדת סטטוס, אבל הניתוח מצטמצם לבדיקת אגרגט אחד. טעות בסף עולה יותר מטעות במקדם: היא משפיעה על כל הרמה בבת אחת.
מקטעי משתמשים מגיבים באופן שונה. סוחרים פעילים סופרים נקודות ורגישים למכפילים, מחזיקים גדולים מחזיקים נכס לשם סטטוס וכמעט לא שמים לב לזיכויים נקודתיים, מתחילים הולכים לאיבוד באריתמטיקה רב-שכבתית.
לכן בחירת המכניקה — מערכת נקודות או מנויים — נקבעת לפי איזו התנהגות צריך לחזק, ולא לפי איזה מודל «נכון יותר».
בפועל השוואת מודלים לעתים רחוקות מסתיימת בניצחון של אחד: לרוב מרכיבים היבריד, שבו רמות מאגרגטים בחלון קובעות סטטוס ופותחות הרשאות, והנקודות חיות בתוך הרמה כמשאב מתכלה להחלפה בעמלות ובמגבלות.
ספים, חלונות ומקדמים מוציאים לקונפיגורציה, כדי לשנות מכניקה בלי ריליס, ויומן הזיכויים נכתב מההתחלה — אי אפשר לשחזר אותו בדיעבד.
ספקות טכניים: זיכוי, אנטי-פראוד, משיכות
לפני ההתחלה בדרך כלל מעלים אותן נושאים: זיכויים כשסוחר אחד מחזיק כמה חשבונות, העברת נקודות שכבר זוכו, הגנה מפני מסחר עצמי ודיווח על תגמולים. להלן תשובות ישירות.
לסוחר יש כמה חשבונות — אתם סופרים כל אחד בנפרד?
זיכויים אנחנו קושרים למזהה הלקוח, ולא למספר החשבון: כל חשבונות המסחר של סוחר אחד מסתכמים ליתרה אחת. לא ניתן לעקוף מגבלות על ידי פיצול חשבונות, והתגמול נשאר מובן לסוחר עצמו.
האם נקודות שזוכו לפי המכניקה הישנה מועברות?
זיכוי וחיוב עוברים דרך יומן נפרד: לכל פעולה יש מזהה ומקור. היסטוריה קודמת נטענת בהצלבה עם היתרה הנוכחית, ועד להתאמתה הכללים החדשים לא מופעלים — נקודות לא נעלמות ולא משוכפלות.
איך אתם מסננים מסחר עצמי וניפוח?
אנטי-פראוד פועל לפי כללים: מחשבים את חלק ההיקף שבו שני צדי העסקה הם אותו לקוח, תופסים זינוקי פעילות מיד לאחר זיכוי, ומצליבים חשבונות קשורים לפי נתוני תשלום. פעולות חשודות נשלחות להסגר, לכן סוחר תמים לא מאבד תגמול בגלל התראת שווא.
מה ייכלל בדיווח על תגמולים?
זיכויים, חיובים ויתרה לכל לקוח עם קישור לפעולת המקור, בנפרד — כללי אנטי-פראוד שהופעלו ונקודות מוקפאות. הייצוא מתבצע כטבלה ומוצלב עם יתרת התוכנית: אי-התאמה נראית לפני פנייה לתמיכה.
נדון במשימה: נחזור עם הערכה ותוכנית עבודה
כדי לחזור עם הערכת פרויקט, ולא עם טווח «מקצה לקצה», אנחנו צריכים הקשר: כיצד בנויה כיום מכניקת הנאמנות, באילו מערכות היא נוגעת ואילו מגבלות חלות. די בנתוני פתיחה אלה כדי להרכיב את היקף העבודות, סדר השלבים ונקודות בקרה — אנחנו מנתחים אותם ומנסחים בעצמנו מה ובאיזה סדר לעשות.
מה עוזר להתחיל מהר יותר:
- תיאור המכניקה הנוכחית: רמות, זיכוי וחיוב נקודות, תוקפן, כללי אנטי-פראוד;
- רשימת מערכות שאליהן יהיה צריך לקשר את תוכנית הנאמנות של בורסת הקריפטו, והאחראים מצדן;
- גישות: מתחם בדיקות, חשבונות עם ההרשאות המינימליות הנדרשות, ארגז חול לפעולות זיכוי ומשיכה;
- היקפים צפויים: משתמשים פעילים ופעולות ביום — מהם תלויה סכימת האחסון והמטמון;
- מגבלות לוחות זמנים להשקה, דרישות הרגולטור וצורת הדיווח בפניו.
בתגובה תקבלו מסמך שלפיו אפשר לקבל החלטה: היקף העבודות לפי בלוקים, סדר השלבים עם תלויות, רשימת גישות ותפקידים, תוכנית בדיקות ונקודות בקרה שבהן התוצאה נראית לפני הקבלה הסופית. תארו את המשימה בצורה חופשית — נחזור עם הערכה ותוכנית עבודה, ומקומות שנויים במחלוקת ננתח בנפרד.