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

אפליקציית מעקב הרגלים: איפה נשברת הנשירה ביום השלישי

אפליקציית מעקב הרגלים כמעט אף פעם לא מאבדת את המשתמש בסשן הראשון — היא מאבדת אותו בשלישי. האדם מתקין את האפליקציה, בערב מסמן «שתיתי מים» ו«קראתי פרק», ביום השני חוזר על כך, וביום השלישי просто לא פותח. מבחוץ זה נראה כמו «העניין נעלם», מבפנים — כמו שלושה מקומות קונקרטיים שבהם המכניקה נשברת.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מה נשאר בפרויקט לאחר המסירה ואיך להשתמש בכך

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

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

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

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

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

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

מה נבנה מחדש

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

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

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

במה שונה תרחיש טריגרי מתזכורת לפי לוח זמנים?

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

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

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

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

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

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

ספקות לגבי עומס, פרטיות נתונים ולוחות זמנים

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

מה רואה החלק בשרת?

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

כיצד מתנהגת האפליקציה בלי חיבור?

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

מה קורה בעת עדכון המערכת?

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

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

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

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

מה לשלוח כדי שנחזור עם הערכה:

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

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