מעקב קלוריות באפליקציה: היכן החישוב נשבר
מעקב קלוריות באפליקציה נשבר לא בנוסחת החישוב, אלא בנתוני הקלט. המשתמש מזין "צלחת בורשט" או "מנה של אורז" — ואילו מאגר המזונות מכיל "100 גרם" מופשטים. מכאן מתחילה עבודה ידנית: לשקול, לחשב מחדש, למצוא את המנה במדריך של עשרות אלפי פריטים. ספירת הקלוריות הופכת להנהלת חשבונות שהאדם נוטש כעבור שבוע — והאפליקציה מאבדת אותו יחד עם ההיסטוריה.
נקודת הכשל השנייה — מנות מעורפלות. "צלחת בינונית", "כף", "חופן" אין להם מסה, והשגיאה בחישוב מצטברת: 20% שגיאה בכל ארוחה במהלך היום יוצרים פער שבגללו יומן התזונה מפסיק לשקף את המציאות. המשתמש רואה משקל יציב ב"גירעון" ומסיק שהשיטה לא עובדת.
הבעיה השלישית — הנתק בין תזונה לפעילות. קלוריות שנשרפו מגיעות ממעקב צעדים או ממכשיר לביש, ואילו הנאכלות — מהזנה ידנית, ושני הזרמים הללו חיים במקומות שונים. בלי סנכרון המאזן מחושב באופן שגוי, ואת הפער תולים ב"מונה לא מדויק".
הכשל הרביעי — אובדן נתונים בעת החלפת מכשיר. מאגר מקומי ללא סנכרון תקין משמעו שהתקנה מחדש של האפליקציה או מעבר לטלפון חדש מאפסים חודשים של רשומות. האדם לא משחזר את היומן מחדש — הוא עוזב.
מפרקים כיצד זה נסגר: זיהוי מנות ומנות לפי תמונה, מטמון מקומי עם סנכרון ברקע, פרופיל תזונה ופעילות מאוחד.
מה נותן מעקב קלוריות מדויק למשתמש
מעקב קלוריות מדויק אינו עניין של לוח הכפל, אלא של כמה שניות המשתמש מבזבז על רישום ארוחה וכמה ימים ברצף הוא בכלל פותח את היומן. אם הזנת מנה אחת אורכת יותר מדקה, שיעור היומנים הנזנחים בשבוע השני עולה באופן משמעותי: האדם לא נוטש את המטרה, הוא נוטש את הממשק.
לכן אנחנו מתייחסים כמדדי יעד לא ל"מספר רשומות ממוצע", אלא למהירות ההזנה, לשיעור המנות שזוהו ללא חיפוש ידני, ולשימור ביום ה-30.
מהירות ההזנה מורכבת משלושה תרחישים, וכל אחד מהם חייב להסתיים במספר נגיעות בודדות. ברקוד על האריזה — פגיעה מיידית במאגר עם מנה ונוטריינטים מוכנים. זיהוי מנות לפי תמונה או תיאור קצר מסיר את החיפוש הידני במקומות שבהם ההרכב אינו מובן מאליו: מרק, תוספת, אוכל ביתי.
הזנה ידנית עם תבניות שמורות נשארת לארוחות חוזרות — ארוחת בוקר בדרך כלל זהה מיום ליום, והחזרה צריכה לארוך פעולה אחת, ולא עשר.
שיעור המנות שזוהו ללא הזנה ידנית הוא מדד איכות אמיתי, ולא קישוט. אם הוא נמוך מסף מסוים, המשתמש חוזר לחיפוש ולהזנה, וכל הרווח במהירות נעלם.
אנחנו מודדים אותו בתרחישים אמיתיים ובוחנים בנפרד אילו קטגוריות נכשלות — בדרך כלל אלו מנות מורכבות ומטבח אזורי, שעבורם אנחנו מאמנים את המודל נוסף.
המוטיבציה נשענת על משוב, ולא על גרפים לשם גרפים. כאשר לאחר הרישום המשתמש רואה מיד את היתרה בקלוריות ובחלבון, ההחלטה "להשלים או לעצור" מתקבלת כאן ומיד, בלי מעבר למסך אחר. זהו המנגנון שהופך עניין חד-פעמי להרגל יומיומי, והרגל הוא הדבר היחיד שבאמת משפיע על שימור המשתמשים.
דרכי הזנת נתונים: ידני, סורק, צילום, קול
הזנת נתונים היא צוואר הבקבוק של כל מעקב קלוריות: אם רישום מנה אורך יותר מ-15-20 שניות, המשתמש נוטש את ניהול היומן כבר ביום השלישי. לכן אנחנו מטמיעים באפליקציה כמה מצבים ומחליפים ביניהם בהתאם למצב, ולא בוחרים אחד "נכון".
| מצב | מתי מתאים | מגבלות |
|---|---|---|
| הזנה ידנית | מנות מורכבות, אוכל ביתי, מנות לא סטנדרטיות | דורש ידיעת משקל או נפח; טעות בגרמים יוצרת פער של עד 30% |
| סורק ברקודים | מוצרים ארוזים עם סימון | חסר תועלת לאוכל מחוץ לאריזה; מאגר הברקודים אינו מלא עבור מותגים מקומיים |
| זיהוי לפי צילום | רישום מהיר של מנה מוכנה בבית קפה או בבית | הדיוק יורד בצלחות מעורבות; נדרש כיול מנה ידני |
| הזנה קולית | רישום תוך כדי תנועה, סדרות של ארוחות | רגיש לרעש ולניסוח; דורש עיבוד שפה טבעית |
ההזנה הידנית נשארת הבסיסית: היא היחידה שנותנת שליטה מלאה על הגרמים ועובדת עם כל מנה. סורק הברקודים מנצח במהירות במוצרי חנות — כיוון אחד, והפריט ביומן.
הזיהוי לפי צילום סוגר את התרחיש "צילמתי צלחת והמשכתי הלאה", אבל אנחנו תמיד מציגים את ההרכב והמשקל המשוערים, כדי שהמשתמש יאשר או יתקן את המנה.
ההזנה הקולית מחוברת כא� supplement, ולא כתחליף: היא נוחה לסדרה של פריטים ברצף, אבל זיהוי ניסוחים כמו "חצי צלחת" או "חתיכה" דורש מילון מנות למוצר הספציפי.
מסקנה מעשית למוצר: המצבים צריכים לחלוק מאגר מוצרים אחד ומודל מנות אחד, אחרת היומן יתפצל לרשומות לא עקביות. אנחנו מתכננים את ההזנה כך שכל רשומה תובא ליחידת מידה אחידה, והמשתמש יוכל להחליף את השיטה ישירות ברגע ההוספה.
כיצד אנו בונים אפליקציית מעקב קלוריות: שלבים
מעקב קלוריות נשבר לא במסך היומן, אלא במפגש של שלושה דברים: מאגר המזונות, זיהוי המנות וסנכרון בין המכשירים. לכן אנו עובדים בשלבים, ובכל שלב ללקוח יש תוצר שניתן לבדוק לפני המעבר לשלב הבא.
- ניתוח תרחישי אכילה. אנו מתעדים כיצד אדם באמת רושם אוכל: חיפוש במאגר, ברקוד, צילום צלחת, הזנה ידנית של משקל בגרמים, חזרה על ארוחה מאתמול. בתוצר — מפת תרחישים עם תדירות שימוש ורשימה של מה שאנו סוגרים בגרסה הראשונה ומה שנדחה.
- עיצוב מודל הנתונים. מוצר, מנה, ארוחה, יום — ארבע ישויות עם קשרים ברורים. כאן גם מחליטים כיצד לשמור חישוב מחדש של רכיבי תזונה בעת שינוי מתכון של מוצר, כדי שרשומות ישנות לא "יזוזו" בדיעבד.
- אינטגרציה עם מקורות מזונות. מחברים מגדירי הרכב וברקודים, מגדירים מטמון לשאילתות תכופות וכללי מיזוג כפילויות. חיפוש לפי שם חייב להגיב באופן מיידי אפילו במצב לא מקוון — אחרת האדם ינטוש את הרשומה באמצע.
- הרכבת מודול החשבונאות. יומן, מוני היום, יעדי תזונה, חישוב מחדש בעת עריכת רשומה. בנפרד בודקים את האריתמטיקה: הסכום לפי הארוחות חייב להתאים לסיכום היום עד הספרה האחרונה.
- בדיקה על נתונים אמיתיים. מריצים תרחישים עם מנות חלקיות, משקלים בשברים עשרוניים, מוצרים ללא הרכב ותיקונים בדיעבד. בבדיקות אוטומטיות מכסים את החישובים, בהרצה ידנית — את ההזנה והחיפוש.
- מסירה והשקה. מוסרים מודול עובד, תיעוד למודל הנתונים והוראות למילוי המאגר. בהמשך — עוקבים אחרי מדדי מילוי היומן ומשפרים את מה שבאמת מפריע לאנשים לנהל מעקב.
מאגר מוצרים, מנות והמרת רכיבים תזונתיים
מדריך המוצרים הוא החלק העמוס ביותר במעקב קלוריות: המשתמש מחפש פריט תוך שניות ספורות, והחישוב של רכיבים תזונתיים חייב להתאים את עצמו בכל שיטת הזנה.
אנחנו מחזיקים את המאגר כקטלוג מנורמל: כל פריט שומר הרכב ליחידת ייחוס (100 גרם או 100 מ"ל), והמנה של המשתמש היא ישות נפרדת עם מקדם המרה משלה. כך "חצי כוס", "פרוסה" ו"כף" מתורגמים לגרמים דרך טבלת מידות, ולא דרך ניחושים.
יחידות מידה הן המקור העיקרי לפערים. אנחנו קובעים מקדמים נפרדים למוצרים יבשים, נוזליים ופריטיים, כי כף דבש וכף קמח שוקלות differently. עבור מוצרים ארוזים אנחנו שומרים נתונים ל-100 גרם ולמנה לפי האריזה, כדי שהמשתמש יוכל לסרוק ברקוד ולקבל מיד המרת מנות מדויקת.
מנות מורכבות נבנות כמתכון מרכיבים: כאשר משתנה רכיב כלשהו, הרכיבים התזונתיים מחושבים מחדש לפי העץ, ולא נשמרים כסכום אחד. כך בורשט ביתי עם כמות שונה של שמנת חמוצה נותן מספרים אמיתיים, ולא פריט ממוצע מהקטלוג. דיוק החישוב הוא הסיבה שבגללה המשתמש חוזר לאפליקציה בכל יום.
אנחנו בודקים את המדריך בבדיקות אוטומטיות: סכומי ביקורת לקלוריות ולמקרונוטריינטים עבור מנות ייחוס, השוואת יחידות מידה בעת ייבוא פריטים חדשים, ורגרסיה על המרת מנות. טעות במקדם כאן עולה באמון בכל יומן התזונה, ולכן אנחנו תופסים פערים לפני השחרור, ולא לפי תלונות.
סנכרון עם התקנים לבישים ובריאות
הסנכרון מבוסס על מאגרי הבריאות הפלטפורמיים המובנים — HealthKit ב-iOS ו-Health Connect ב-Android. האפליקציה מבקשת גישה רק לסוגי הנתונים הנדרשים: צעדים, אנרגיה פעילה, אימונים, שינה, דופק.
המשתמש רואה את רשימת ההרשאות ויכול לבטל כל אחת מהן בהגדרות המערכת — אנחנו לא אוספים דבר "מאחורי הקלעים".
Apple Health והשירות המקביל ב-Android משמשים כנקודת חילוף אחודה: שעונים, צמידים, מאזניים ואפליקציות צד שלישי כותבים לשם, והמעקב קורא משם. זה מבטל את הצורך להשתלב עם כל יצרן בנפרד ומסיר סוג שלם של שגיאות — כאשר הוצאה קלורית חושבה פעמיים.
הלוגיקה המרכזית — דה-דופליקציה. אם אימון הגיע מהתקן לביש, רשומה ידנית לאותו פרק זמן לא יוצרת רשומה שנייה. עדיפות ניתנת לנתוני החיישן, והקלט הידני משמש כברורור. צעדים ואנרגיה פעילה נמשכים ברקע, ולכן ההוצאה הקלורית מתעדכנת בלי לפתוח את האפליקציה.
מה קורה בעת חוסר סנכרון
הנתונים נכתבים במנות עם חותמות זמן, ולכן קונפליקטים נפתרים לפי מקור וזמן הכתיבה, ולא לפי "מי האחרון". אם התקן התנתק ליום, האפליקציה טוענת את ההיסטוריה בהתחברות הבאה ומחשבת מחדש את המאזן. המשתמש רואה תמונה מעודכנת, ולא פער בסטטיסטיקה.
גבולות גישה ופרטיות
אנחנו מבקשים סט מינימלי של הרשאות ומעבדים את הנתונים במכשיר. לשרת נשלח רק אגרגט לסנכרון בין גאדג'טים — בלי רשומות גולמיות על בריאות. גישה כזו עוברת בדיקות של חנויות אפליקציות ולא יוצרת סיכונים בעת ביטול גישה.
מה לעשות אם האפליקציה כבר הושקה
אפליקציה שהושקה עם מעקב קלוריות היא מערכת חיה עם מאגר מצטבר: יומני תזונה, מנות מועדפות, משקלי מנות, מטרות והתקדמות לאורך חודשים. לכן שדרוג האפליקציה מתחיל לא בקוד, אלא במיפוי מה שכבר קיים: אילו ישויות נשמרות מקומית, מה מסונכרן עם השרת, היכן הפורמטים שונים בין הפלטפורמות.
כל עוד המפה הזו לא נבנתה, כל עדכון עלול לקרוע את ההיסטוריה של המשתמשים — ואי אפשר לשחזר יומן בדיעבד.
הסיכון המרכזי הוא מיגרציית נתונים. משנים את הסכמה כך שרשומות ישנות ייקראו על ידי גרסאות חדשות ללא אובדן: מוסיפים שדות עם ערכי ברירת מחדל, מנהלים גרסאות של מבנה היומן, משאירים שכבת תאימות ללקוחות שטרם עדכנו.
משתמש שפותח את האפליקציה כעבור חודש צריך לראות את התזונה שלו בשלמותה, ולא מסך ריק. משימה נפרדת היא מאגר המוצרים: הערך הקלורי וההרכב משתנים, ולכן עדכון המאגר מתבצע בנפרד מהשחרור של האפליקציה, כדי שתיקונים לא ימתינו לפרסום בחנויות.
הלאה — המנגנון עצמו של העדכון. חלק מהלוגיקה (חישובים, כללי המרה של מנות, מגבלות) מועבר לשרת, ואז השינויים מגיעים לכולם בבת אחת, בלי להמתין שהמשתמשים יורידו גרסה חדשה. זה גם מסיר את הכאב של התאימות: build ישן ממשיך לעבוד עם הכללים החדשים, ולא נשבר.
הסדר המעשי הוא כזה: תחילה ביקורת של הסכמה והתרחישים הנוכחיים, אחר כך פרויקט מיגרציה עם בדיקה על עותק של נתונים אמיתיים, ואחר כך שחרור מדורג — קודם על חלק מהקהל, עם מעקב אחר שיעור המיגרציות המוצלחות ונסיגות. כך השדרוג מתבצע מעל מוצר עובד, בלי לכתוב מחדש ובלי לאבד משתמשים.
מה הלקוח מקבל לידיו
אנחנו מוסרים את הפרויקט לא כ"תיקייה עם קוד", אלא כערכה שצוות אחר יוכל להמשיך ולנהל את המוצר בלעדינו. להלן מה בדיוק נכלל במסירה.
- קונפיגורציות בנייה וסביבות. פרופילים נפרדים לפיתוח, למתאר בדיקות ולפרודקשן, משתני סביבה, מפתחות גישה לשירותים חיצוניים, כללי חתימה ותיוג גרסאות של בניות. הפריסה משוחזרת על מכונה נקייה בפקודה אחת.
- סכמות נתונים. מבנה אחסון הפרופילים, יומן ארוחות, מנות והיסטוריית משקל: טבלאות, קשרים, אינדקסים, כללי מיגרציות. בנפרד — כיצד מחושבת המכסה היומית וכיצד נשמרות עקיפות של המשתמש.
- מאגר המוצרים. פורמט הרשומות, שדות מנות ומידות, כללי התאמה בהזנה ידנית ובסריקת ברקוד, סדר עדכון המאגר וטיפול בכפילויות.
- נהלי עדכון. כיצד מוציאה גרסה חדשה, מה נבדק לפני פרסום בחנויות, כיצד מבוצעת חזרה לאחור של מהדורה בעייתית וכיצד שינויים במאגר מגיעים למשתמשים ללא בנייה מחדש של האפליקציה.
- תיעוד לתמיכה. תיאור המודולים, נקודות אינטגרציה עם שירותים חיצוניים, פניות אופייניות וסדר הפעולות עבורן, רשימת המגבלות הידועות.
- גישות והרשאות. חשבונות, תפקידים, שיוך לחשבונות בחנויות ולפאנלים של שירותים חיצוניים, סדר רוטציה של מפתחות.
- מערך בדיקות. בדיקות אוטומטיות לחישוב המכסה, לסנכרון היומן ולעבודה במצב לא מקוון — עם דוח אילו מסלולים מכוסים ואילו לא.
הערכה מתווספת תוך כדי העבודה, ולא נאספת בשבוע האחרון. תארו את המשימה — נחזור עם הערכה ותוכנית, כולל הרכב המסירה.
מקרה בוחן: יומן תזונה עם הזנה ידנית ואובדן נתונים
הגיע אלינו שירות של יומן תזונה: המשתמש חיפש מוצר בקטגוריית "אפליקציית מעקב קלוריות", הוריד, הזין כמה מנות — ונטש. המוצר התבסס על הזנה ידנית: האדם פתח טופס, חיפש מוצר במאגר, הקליד משקל בגרמים, חיכה לחישוב מחדש. על ארוחה אחת נדרשו יותר משתי דקות, וכך בכל ארוחה.
MyFitnessPal ושירותים דומים הרגילו את השוק לסף אחר: זיהוי לפי תמונה, ברקוד, מנות אחרונות ומועדפות בלחיצה אחת. הלקוח שלנו הפסיד לא בפונקציונליות, אלא בחיכוך בכל שלב — ואיבד אנשים בדיוק במקום שבו נוצרת ההרגל.
מה גילה הניתוח
הוצאנו את המשפך לפי אירועים וראינו ש-68% מהרשומות נוצרו ידנית, ושמשך סשן ההזנה הממוצע התארך ל-2 דקות ו-40 שניות. השימור בשבוע השני עמד על 19%, והתמיכה קיבלה תלונות מסוג אחד: "הזנתי אוכל, האפליקציה נסגרה, הכול נעלם". התברר שטיוטת הארוחה נשמרה רק בזיכרון המסך — מזעור האפליקציה או אובדן רשת מחקו את מה שהוזן.
מה שינינו
כתבנו מחדש את שכבת ההזנה: אחסון מקומי כותב כל שינוי בטופס, הסנכרון עם השרת עובד בתור ומשרוד אופליין. הוספנו זיהוי לפי תמונה וברקוד, בלוק "אחרונות ותכופות" במסך הראשון, חישוב מחדש של המנה בגרירה. את מאגר המוצרים העברנו למטמון מקומי עם עדכון ברקע — החיפוש הפסיק לחכות לרשת.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| רשומות ללא הזנה ידנית | 32% | 74% |
| זמן לארוחה | 2 דק' 40 שנ' | 35 שנ' |
| שימור בשבוע השני | 19% | 41% |
| פניות לתמיכה בנושא אובדן נתונים | קבועות | בודדות |
נאמר בנפרד על התמיכה: לאחר השחרור נשארנו בליווי, וחלקן של הפניות הקשורות לאובדן נתונים ירד למקרים בודדים — לא מפני שהתחילו להסתיר אותן, אלא מפני שסוג התקלה הפסיק לשחזר את עצמו.
בואו נדון במשימת תיעוד הקלוריות שלכם
כדי שההערכה תהיה מבוססת ולא "ממוצע שוק", עלינו להבין את המוצר שלכם ואת תרחישי התזונה שעבורם מיועד מודול תיעוד הקלוריות. ספרו לנו כיצד המשתמש מנהל כיום את היומן: מחפש מוצר בחיפוש, סורק ברקוד, בוחר מהאחרונים או מזין מנה בגרמים. מכך נגזרים מבנה המאגר, לוגיקת ההמרה והנקודה המדויקת שבה המשתמש נושר בעת ההזנה.
בנפרד חשוב להבין מהיכן מגיעים נתוני ההרכב: מאגר עצמאי, מקור חיצוני או הזנה ידנית. אם המאגר עצמאי — נדון כיצד לשמור אותו מעודכן ומה לעשות עם מנות שאינן בו. אם חיצוני — כיצד לשמור את התשובות במטמון כך שהיומן ייפתח באופן מיידי ולא יהיה תלוי בזמינות של גורם אחר.
שלחו את מה שקיים: אפליקציה נוכחית או אב טיפוס, תיאור תרחישי תזונה, סקיצות של מסכי היומן. אם המוצר עדיין לא קיים — די ברשימה של מה שהמשתמש צריך להיות מסוגל לעשות במהלך היום: להוסיף ארוחה, לתקן מנה, לראות יתרה לפי הנורמה, לחזור לשבוע שעבר.
בסיום הניתוח נחזור עם הערכה ותוכנית עבודה למודול התיעוד: חלוקה לשלבים, סדר הוצאת המסכים ומה שניתן לבדוק על משתמשים אמיתיים לפני כל השאר.
- ניתוח תרחישי תזונה ונקודות ההזנה — היכן המשתמש מאבד זמן;
- סכמת מאגר המוצרים וכללי המרת המנות;
- תוכנית עבודה למודול תיעוד הקלוריות עם שלבים וסדר הוצאה;
- הערכת לוחות זמנים והרכב הצוות בהתאם להיקף שלכם;
- רשימת סיכונים: איכות הנתונים, דיוק המנות, עומס על המאגר;
- הצעות לבדיקת השערות על משתמשים חיים לפני הפיתוח העיקרי.
תארו את המשימה ואת המוצר הנוכחי — נחזור עם הערכה ותוכנית עבודה.