פיתוח Telegram Mini App לפרויקט קריפטו

למה Telegram Mini App מאבדת משתמשים בכניסה

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

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

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

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

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

ארנק, רשת וממשק: היכן מופיע אפקט מדיד

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

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

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

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

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

דרכי חיבור: ארנק מובנה, חיצוני והיברידי

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

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

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

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

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

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

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

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

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

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

מקרה בוחן: איך צמצמנו את שיעור הפעולות שלא הושלמו

הפרויקט — שירות מסחר בתוך Mini App ב-Telegram: קנייה ומכירה של טוקנים, מילוי יתרה, משיכה. לפנינו שיעור הפעולות שלא הושלמו הגיע ל-38% — אדם פתח את האפליקציה מערוץ או מקישור לתרחיש מסוים, לא עבר בדיקת כניסה וחזר לצ'אט. במסך הראשון הוא בילה בממוצע ארבעים שניות, וזה הספיק כדי פשוט לסגור את החלון.

מה שינינו

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

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

תוצאה חודש אחרי ההשקה

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

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

במה שונה בוט Telegram ממיני-אפליקציה ומה לבחור?

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

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

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

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

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

ספקות טכניים: מפתחות, עומס, תמיכה

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

מה יקרה בעומס שיא?

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

האם זה תואם לשירותים שכבר עובדים?

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

איך מאושרת אבטחת הפעולות?

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

מה מקבלים במסירה ואיך מתבצעת התמיכה?

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

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

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

מה לשלוח לניתוח:

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

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