הטמעת התראות על מכירות NFT באפליקציה לנייד

מדוע התראות NFT באפליקציה מגיעות באיחור

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

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

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

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

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

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

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

מה נותן ערוץ התראות מתוקן על מכרזים

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

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

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

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

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

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

גישות למעקב אחר אירועי מסחר ומגבלותיהן

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

כיצד נבחרת התכנית

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

היכן נשברות אפשרויות הקצה

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

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

איך אנחנו בונים את מסירת ההתראות של NFT

התראות על הצעות הן לא קריאה אחת לשירות push, אלא מסלול של אירוע מהבלוקצ'יין ועד למסך הטלפון. ставка גבוהה: אות שהוחמץ על הצעה על לוט פירושו מכרז מופסד. לכן אנחנו מתכננים את המסירה כתת-מערכת נפרדת עם אידמפוטנטיות, ניסיונות חוזרים ונראות, ולא כפונקציה של "לשלוח פוש".

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

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

מה הלקוח מקבל לאחר ההטמעה

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

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

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

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

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

מדדים לפני העבודה: חציון מסירת ההתראה על הצעה חדשה — 40 שניות, שיעור התצוגות המוצלחות — 71%, החמצת אירועים בעומס שיא (דרופ המוני של קולקציה) — עד 9% מכלל ההצעות.

מה היה לא תקין

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

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

מה שינו

העברנו את המסירה לזרם אירועים בצד השרת: האינדקסר מפרסם שינויים בהצעות ל-bus, worker מתאים אותם למנויים של המשתמשים ושולח push ממוקד.

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

תוצאה

חציון המסירה — 3 שניות במקום 40, שיעור התצוגות המוצלחות עלה מ-71% ל-98.6%, החמצת אירועים בשיא — 0.2% לעומת 9%. בנפרד מדדנו את המדד "הספיק לעקוף את ההצעה": שיעור המשתמשים שהגיבו לפני סגירת המגרש גדל פי שלושה — זה כבר עניין של כסף הלקוח, ולא של תשתית.

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

במה שונה מנוי בזרימה מסקר תקופתי?

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

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

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

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

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

ספקות טכניים נפוצים

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

מה יקרה בעת עלייה בעומס ברגעי שיא של מכרזים?

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

איך זה ישתלב בתשתית הקיימת שלנו?

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

אפשר לבטל או להשבית סוגים מסוימים של התראות?

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

בואו נדון במשימת ההתראות שלכם

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

מה ננתח בשיחה הראשונה

• מקורות אירועים. מאיפה מגיעים הנתונים על מסחר: בקאנד משלכם, מרקטפלייסים חיצוניים, אירועים ישירים מהרשת. זה קובע אם נדרש שכבת אגרגציה נפרדת ובאיזו תדירות לשאול את המקורות.
• כללי מנוי. לפי אילו קולקציות, לוטים וספים המשתמש רוצה לקבל התראות NFT — ואיפה הכללים האלה נשמרים: בצד הלקוח, בשרת או בשניהם.
• ערוצי מסירה. Push דרך שירותי מערכת, הודעות בתוך האפליקציה, ערוצי גיבוי למקרה ש-push לא הגיע. ננתח מה קריטי לתרחיש שלכם.
• ארכיטקטורה נוכחית. מה כבר קיים באפליקציה: אימות, פרופיל משתמש, עבודה עם בלוקצ'יין. זה יראה מה נשתמש מחדש ומה נצטרך לבנות.
• עומס והתנהגות. כמה משתמשים, כמה אירועים בשיא, באיזו תדירות משתנים הלוטים. מזה תלויה סכמת התורים והדה-דופליקציה.
• פלטפורמות ומגבלות. iOS ו-Android עובדים באופן שונה עם התראות רקע והרשאות — ניקח זאת בחשבון בתוכנית, ולא אחרי ההשקה.
• קריטריוני מוכנות. מה עבורכם אומר "עובד": השהיית מסירה, שיעור נמסרים, היעדר כפילויות. נתעד זאת לפני תחילת הפרויקט.

מה לשלוח לפני השיחה

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

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