גילוי נאות: המדריך כולל קישורי שותפים ל-Base44. הרשמה דרכם אינה מייקרת לכם דבר. חלק מהקישורים למטה יוחלפו בקישורי Impact כשיהיו מוכנים.
שער 11: מדידה, ביצועים ותחזוקה
מה קורה לאפליקציה אחרי ההשקה, ואיך יודעים זאת לפני שהלקוח מתקשר? הפרק הזה עוסק בשכבה שרוב בוני האפליקציות מדלגים עליה: לוגים, אנליטיקס, הקלטות סשן, מדדי ביצועים וסדר פעולות קבוע לפתרון תקלות. זה ההבדל בין אפליקציה שעובדת לבין אפליקציה שאתם יודעים שהיא עובדת.
לפני הפרסום, השאלה היא אם האפליקציה עובדת אצלכם על המסך. אחרי הפרסום, השאלה משתנה לגמרי: האם היא עובדת אצל כולם, כמה מהר, ואיפה בדיוק אנשים מוותרים באמצע? Base44 נותן לזה כמה שכבות תצפית נפרדות, וכל אחת מהן עונה על שאלה אחרת.
הלוגים עונים על מה קרה ולמי. האנליטיקס עונה על כמה ואיפה. הקלטות הסשן עונות על איך זה הרגיש למשתמש. מדדי הביצועים עונים על כמה זמן זה לקח. ה-Activity Monitor מראה אילו קריאות רשת האפליקציה באמת מבצעת, וממשקי ה-Monitoring וה-Audit Logs מוציאים את התמונה לרמת הארגון. הטעות הנפוצה היא לנסות לענות על כל השאלות בכלי אחד ואז להסיק מסקנה שגויה. הפרק מסדר מתי לפתוח מה ומוסיף מתודולוגיית תקלות קבועה במקום ניחושים.
11.1 לוגים של האפליקציה
רמה: מתקדם
כשמשתמש מדווח ש"משהו לא עובד", הלוגים הם המקום הראשון לחפש בו, לא הצ'אט עם ה-AI. Logs (יומן האירועים) הוא הרישום של כל מה שקרה באפליקציה: פעולות משתמשים, קריאות לפונקציות, שינויי סכימה ושינויים באינטגרציות. בלי זה אתם מנחשים, ואיתו אתם רואים בדיוק מה קרה ובאיזו שנייה.
הלוגים יושבים בעורך האפליקציה: נכנסים ל-Dashboard ובוחרים Logs בתפריט הצד. מה שנפתח הוא טבלה עם העמודות Type, User ו-Timestamp, וכל שורה נפתחת לפרטים המלאים של האירוע.
האירועים מחולקים לשתי קטגוריות. Runtime הוא כל מה שמשתמשים עושים בפועל: יצירה, עדכון, מחיקה ושחזור של רשומות, הרשמות והתחברויות, שינויי תפקיד, ביקורים בעמודים, בקשות גישה, קריאות לפונקציות, הרצות של אינטגרציות ואוטומציות, שיחות של סוכני AI, ייבוא נתונים, העלאות קבצים ובדיקות אבטחה. Setup הוא שינויי התצורה: יצירת האפליקציה, פרסום והסרת פרסום, שינויי סכימה של ישויות (Entity), הגדרת תשלומים ו-OAuth ושינויי דומיין. ההפרדה הזאת שימושית מאוד: כשמשהו נשבר פתאום בלי שנגעתם בקוד, סינון ל-Setup עונה תוך שניות על השאלה אם מישהו אחר בצוות שינה סכימה או דומיין.
הסינון הוא מה שהופך ערימת שורות למשהו שמיש. יש תפריט קטגוריה עם All Categories, Runtime ו-Setup, תפריט All Events לבחירת סוג אירוע ספציפי, שדה סינון לפי כתובת אימייל של משתמש, ומתג Errors only שמשאיר רק אירועים שנכשלו. יש כפתור רענון, ויש X שמנקה את כל הסינונים בבת אחת. שילוב של שלושה סינונים – משתמש, טווח זמן וסוג אירוע – מצמצם אלפי שורות לשורה אחת.
נניח שבעלת סטודיו ליוגה בגבעתיים מדווחת שטופס קביעת השיעור נשבר בשלוש אחר הצהריים. אתם מסננים לפי האימייל שלה, מדליקים Errors only, ומגיעים תוך שניות לאירוע הבודד שנכשל. פתיחת השורה חושפת את לשוניות Details עם המטא-דאטה המלא, Outputs עם מה שהאירוע החזיר, ו-Error עם הודעת הכשל, ויש אייקון העתקה שמושך את כל נתוני האירוע כמקשה אחת.
וכאן הנקודה הפרקטית ביותר: במקום לכתוב ל-AI "הטופס לא עובד", הדביקו לו את נתוני האירוע המלאים מההעתקה הזאת. הפער בין שתי הגישות הוא בדרך כלל ההבדל בין תיקון בניסיון אחד לבין שלושה סבבים של ניחושים. שים לב שביומן הזה מוצגים אירועים ברמת האפליקציה בלבד; אירועים ברמת ה-workspace דורשים את Audit Logs API, וזה נושא נפרד בהמשך השער.
שים לב: הטעות הנפוצה היא לתאר ל-AI את התקלה במילים שלכם במקום להדביק את נתוני האירוע המלאים מהלוג, וזה מוביל אותו לתקן את הקוד הלא נכון.
11.2 אנליטיקס
רמה: בסיס
אנליטיקס הוא ההבדל בין לדעת שהאפליקציה באוויר לבין לדעת שהיא מביאה כסף. Base44 כולל אנליטיקס מובנה שלא דורש מכם להתקין שום קוד מעקב, והוא מציג את התמונה בשתי חזיתות: תנועה ומכירות.
בתצוגת התנועה תראו Total visits (סך כניסות), Unique visitors (מבקרים ייחודיים), Visit duration (משך ביקור) ו-Live visitors (מבקרים ברגע זה). אפשר לבחור טווח תאריכים, לסנן לפי פלח, לשנות את סוג הגרף בכל כרטיס בנפרד ולסדר מחדש את הלוח. בתצוגת המכירות, אם חיברתם Stripe, תראו Total payments, Transactions, Customers ו-Refunds, כולל רשימת הלקוחות הגדולים, העסקאות האחרונות ותצוגה בכמה מטבעות.
החלק שבאמת משנה התנהגות הוא Custom Events, אירועים מותאמים. אלה פעולות שאתם מגדירים בעצמכם: לחיצה על כפתור, שליחת טופס, סיום תהליך. מגדירים אותם בשפה חופשית מול ה-AI, בלי לכתוב קוד מעקב ידנית, ואפשר לייצא את נתוני האירועים כקובץ CSV לניתוח באקסל. בתוכנית החינמית אפשר לעקוב אחרי שלושה אירועים; בתוכניות בתשלום המספר אינו מוגבל.
עסק ישראלי טיפוסי, נניח מרפאת שיניים ברעננה שבנתה אפליקציית זימון תורים, צריך בדיוק שלושה אירועים כאלה: "נפתח טופס זימון", "נבחר תאריך" ו-"תור אושר". ברגע שהם קיימים, הנתון המעניין הוא לא כמה אנשים נכנסו, אלא כמה אחוז מהנכנסים הגיעו מהשלב הראשון לשלישי. שיעור של שמונה אחוזים אומר שיש בעיה במסך בחירת התאריך, ולא בפרסום.
לגבי חיבור לכלי חיצוני: האנליטיקס המובנה מכסה את מה שקורה בתוך האפליקציה, אבל הוא לא יודע מאיזה קמפיין הגיע הגולש ולא מחבר בין מכשירים. אם אתם מריצים מדיה בתשלום, הוסיפו תגית של כלי חיצוני כמו Google Analytics 4 או פיקסל פרסומי לקובץ index.html דרך לשונית הקוד, ותייחסו את ההמרות שם. אל תנסו להשוות בין שתי המערכות מספר מול מספר – הן סופרות אחרת, ותמיד יהיה פער.
שימו לב לשמירת הנתונים: היא משתנה לפי התוכנית – שבעה ימים בחינמית, שלושים יום בתוכניות הבאות, ושנה בתוכנית הארגונית. אם אתם מנתחים עונתיות או משווים חודש לחודש, שבעה ימים לא יספיקו, וזה שיקול אמיתי. אפשר ולראות מה כל תוכנית פותחת. את הגישה ללוח אפשר להגביל בהרשאות, ואפשר גם לכבות את האנליטיקס לגמרי.
שים לב: הטעות הנפוצה היא להסתפק במספר הכניסות כמדד הצלחה, במקום להגדיר שניים או שלושה אירועים מותאמים שמודדים את הפעולה שבאמת מייצרת ערך לעסק.
11.3 הקלטות סשן
רמה: מתקדם
אנליטיקס אומר לכם שחמישים אחוז נוטשים בעמוד התשלום. הקלטות סשן מראות לכם למה. זו יכולת שמתעדת את המסך של משתמשים באפליקציה המפורסמת שלכם ומאפשרת לכם לצפות בהקלטה אחר כך, כולל סימון אוטומטי של נקודות חיכוך.
ההפעלה היא בארבעה שלבים: נכנסים ל-Dashboard, עוברים ל-App Settings, מאתרים את האזור Advanced Capabilities, מדליקים את המתג של Session recordings ומפרסמים מחדש את האפליקציה. הצפייה עצמה נמצאת ב-Dashboard תחת Analytics, בלשונית Session recordings. כל שורה ברשימה מציגה מזהה הקלטה, תאריך, משך, מיקום המשתמש, דפדפן, מערכת הפעלה וסוג מכשיר.
בנגן אפשר להאיץ את הקצב, לדלג על זמני חוסר פעילות, לקפוץ ישירות לנקודות החיכוך ולפתוח כלי פיתוח עם נתוני קונסול, רשת וביצועים. המערכת מסמנת לבד rage clicks (לחיצות זעם על אלמנט שלא מגיב), dead clicks (לחיצות על משהו שאינו לחיץ) ושגיאות, ואלה בדיוק שלוש הנקודות שצריך לחפש קודם. אפשר גם לבקש סיכום AI שמדרג את חומרת החיכוך ומציע תיקונים, עד חמישים סיכומים בחלון של שלושים יום.
אל תצפו בהקלטות אקראיות; זה בזבוז זמן. סננו לפי סוג תקלה, מכשיר, מדינה, דפדפן, מערכת הפעלה או עמוד ספציפי, וצפו רק בסשנים שנגעו במסך שאתם חוקרים. אפשר לחפש לפי מזהה או שם, לסמן הקלטות במועדפים, לשנות להן שם כדי לזהות אותן אחר כך, ולמחוק לצמיתות – מחיקה כזאת אינה הפיכה.
שימו לב למגבלות: עד חמש מאות סשנים לאפליקציה בחלון מתגלגל של שלושים יום, ושמירה של שלושים יום בלבד. מי שרוצה להשוות התנהגות לפני ואחרי שינוי צריך להוציא את המסקנות בתוך החלון הזה. היכולת דורשת תוכנית Builder ומעלה. אם אתם בתוכנית חינמית או Starter תצטרכו.
ועכשיו החלק שישראלים נוטים לפספס: האחריות המשפטית עליכם. הקלטת סשנים עשויה לחייב הסכמת מבקר באזורים כמו האיחוד האירופי, בריטניה וקליפורניה, ו-Base44 לא מספק באנר הסכמה – אתם צריכים לסדר את זה בעצמכם. חנות אונליין ישראלית שמוכרת גם ללקוחות באירופה נמצאת בדיוק בחשיפה הזאת. בנוסף, אל תקליטו מסכים שמציגים מספרי תעודת זהות, פרטי אשראי או מידע רפואי.
שים לב: הטעות הנפוצה היא להדליק הקלטות על כל האפליקציה ולשכוח מזה, במקום להחריג מראש מסכים עם נתונים רגישים ולהסדיר הסכמת מבקרים אם יש לכם לקוחות באירופה.
בתיעוד הרשמי: Session recordings
11.4 ביצועים
רמה: מתקדם
אפליקציה איטית היא אפליקציה שלא משתמשים בה, וגם אפליקציה שגוגל מדרג נמוך יותר. הביצועים נמדדים בשלושה מדדים סטנדרטיים שנקראים Core Web Vitals, ולכל אחד מהם סף ברור שכדאי לעמוד בו.
- LCP (Largest Contentful Paint): כמה זמן לוקח לאלמנט הגדול ביותר בחלק העליון של המסך להופיע. היעד: עד 2.5 שניות.
- CLS (Cumulative Layout Shift): כמה התוכן קופץ ומזיז את עצמו בזמן הטעינה. היעד: עד 0.1.
- INP (Interaction to Next Paint): כמה מהר האפליקציה מגיבה ללחיצה או להקלדה. היעד: עד 200 מילישניות.
סדר הפעולות חשוב: קודם מודדים, אחר כך מתקנים. את המדידה עושים עם כלי הפיתוח של Chrome, כולל לשונית Performance שמקליטה את הטעינה, או עם Google PageSpeed Insights שנותן אבחון מפורט. רק אחרי המדידה אתם יודעים מה באמת מאט, ובדרך כלל זה לא מה שחשבתם.
לשפר LCP פירושו להקל על החלק העליון של המסך: להזיז וידאו, iframes, גלריות ורשימות ארוכות מתחת לקו הגלילה, לדחוס תמונות ולהפעיל טעינה עצלה לתמונות שלא נראות. לשפר CLS פירושו לקבוע מידות קבועות לכל תמונה ווידאו, להשתמש ב-font-display: swap; בטעינת גופנים, לשריין מקום לתוכן שנטען מאוחר כמו פופ-אפים, ולצמצם עדכוני DOM אוטומטיים. לשפר INP פירושו למנוע סקריפטים כבדים שרצים בתגובה ללחיצה, לדחות סקריפטים לא קריטיים ולפשט אנימציות ופריסות מורכבות.
הדוגמה השכיחה בישראל: אתר של מסעדה בתל אביב שמעלה תמונת רקע ענקית במסך הפתיחה. בסיבים זה נראה מצוין, ברשת סלולרית זה שלוש שניות של מסך לבן, ורוב הגולשים שלה מגיעים מהנייד. דחיסת התמונה הזאת לבדה מחזירה יותר מכל שאר האופטימיזציות ביחד, והיא גם לוקחת חמש דקות. אחריה, ההחזר הגדול הבא הוא בדרך כלל הורדת רשימות ארוכות שנטענות מהנתונים אל מתחת לקו הגלילה.
לגבי מטמון: Base44 משתמש אוטומטית ברשת ה-CDN של Cloudflare. פרסום מחדש מרענן את הקבצים השמורים, ואין ניקוי מטמון ידני, כך שאם שיניתם נכס ואתם עדיין רואים את הישן, פרסום מחדש הוא הפתרון ולא עוד רענון בדפדפן.
שים לב: הטעות הנפוצה היא לבצע אופטימיזציה לפי תחושה ולפני מדידה, ואז להשקיע שעות בשיפור שלא משפיע. תמיד תריצו PageSpeed Insights קודם ותתקנו לפי מה שהוא מצביע עליו.
11.5 Activity Monitor
רמה: מפתחים
Activity Monitor הוא כלי פיתוח שמראה לכם כל קריאת רשת שהאפליקציה מבצעת בזמן אמת במצב תצוגה מקדימה. זה המקום לוודא שהאפליקציה פונה לנקודת הקצה הנכונה, מחזירה את קוד הסטטוס שציפיתם לו, ועושה את זה בזמן סביר.
מגיעים אליו מתוך עורך האפליקציה: לוחצים על אייקון שלוש הנקודות (More Actions) בפינה העליונה ובוחרים Activity Monitor. מה שנפתח הוא רשימה שבה כל שורה מציגה את שיטת ה-HTTP, את הנתיב, חותמת זמן וקוד סטטוס. בראש הרשימה יש שדה חיפוש שמסנן לפי שיטה, נתיב או כל טקסט אחר.
לחיצה על שורה פותחת חלונית פרטים עם שלוש לשוניות: General עם כתובת ה-URL המלאה, השיטה, קוד הסטטוס, זמן הבקשה הכולל וחותמת הזמן; Request עם מה שהאפליקציה שלחה, כולל כותרות, פרמטרים של שאילתה וגוף הבקשה; ו-Response עם מה שהשרת החזיר, כולל כותרות, גוף ההודעה או הודעת השגיאה.
הקריאה הנכונה מתחילה בקוד הסטטוס. קוד בטווח 4xx אומר שהאפליקציה שלחה משהו לא תקין, הרשאה חסרה, שדה שלא קיים או מזהה שגוי – ואז התשובה נמצאת בלשונית Request. קוד בטווח 5xx אומר שהצד השני נפל, ואז הלשונית Response היא זו שתסביר. כשאין בכלל שורה חדשה אחרי לחיצה, הבעיה אינה בשרת אלא בחיווט של הממשק: הכפתור פשוט לא קורא לשום דבר.
לזיהוי תהליך תקוע חפשו שתי תבניות. הראשונה היא בקשה בודדת עם זמן כולל חריג, סימן לשאילתה שסורקת יותר מדי רשומות. השנייה, והשכיחה יותר באפליקציות שנבנו בצ'אט, היא אותה קריאה בדיוק שחוזרת עשרות פעמים בטעינת עמוד אחת, בדרך כלל בגלל קומפוננטה שמושכת נתונים בתוך לולאת רינדור.
דוגמה מהשטח: כלי לניהול משמרות של רשת בתי קפה בירושלים נפתח בעצלתיים, וה-Activity Monitor הראה ארבעים קריאות זהות לישות העובדים בטעינה אחת. משיכה אחת בראש העמוד פתרה את זה. הערה שחוסכת אכזבה: הכלי מנטר בקשות רשת, לא צריכת מעבד וזיכרון, ואת השימוש במשאבים אתם מסיקים מכמות הקריאות ומזמני התגובה.
שים לב: הטעות הנפוצה היא להסיק שהאפליקציה איטית בלי לבדוק את מספר הקריאות בטעינת עמוד, בעוד שברוב המקרים הבעיה היא קריאות כפולות שאפשר לאחד לשאילתה אחת.
בתיעוד הרשמי: Activity Monitor
11.6 מתודולוגיית פתרון תקלות
רמה: בסיס
רוב הזמן שמתבזבז על תקלות לא נשרף בתיקון עצמו אלא בניחושים שלפניו. סדר פעולות קבוע חוסך את זה, והוא זהה בין אם אתם בונים בצ'אט או כותבים קוד.
התחילו תמיד בבדיקה החיצונית: היכנסו לעמוד הסטטוס של הפלטפורמה בכתובת status.base44.com. אם יש תקלה רוחבית, אין שום טעם לפרק את האפליקציה שלכם.
- לשחזר: שחזרו את התקלה בעצמכם, עם אותו משתמש, אותו דפדפן ואותה פעולה. תקלה שלא הצלחתם לשחזר – לא תדעו לאמת שתיקנתם.
- לבודד: צמצמו לשכבה אחת. אם הלוג מראה שגיאה בקריאת פונקציה, זה backend. אם הקריאה חוזרת תקינה וה-UI לא מתעדכן, זה frontend. אם אין קריאה בכלל, זה חיווט של הממשק.
- לתקן: שינוי אחד בכל פעם. שני תיקונים במקביל הופכים כל תוצאה לחסרת משמעות.
- לאמת: הריצו שוב את התרחיש המדויק מהשלב הראשון, וודאו בלוג שהאירוע עבר ללא שגיאה.
עץ ההחלטות לתקלות הנפוצות קצר. משתמש רואה מסך ריק במקום נתונים: בדקו הרשאות ברמת הרשומה לפני שאתם נוגעים בקוד. פעולה נכשלת רק למשתמש אחד: בדקו את התפקיד שלו ואת הרשומה הספציפית. הכל עבד אתמול ולא נגעתם: סננו את הלוג לקטגוריית Setup ותראו מי שינה סכימה או דומיין. אינטגרציה מפסיקה לעבוד: בדקו תוקף של מפתח או חיבור OAuth שפג.
יש תקלה אחת שחוזרת אצל כל מי שעובד גם מקומית: טוקן שנוצר בסביבת הפיתוח המקומית נדחה באפליקציה המפורסמת. הסיבה פשוטה: שרת הפיתוח המקומי חותם טוקנים עם סוד מקומי, והאפליקציה המפורסמת מצפה לסוד אחר ולכן דוחה אותם. הפתרון: להתנתק מקומית או לנקות את אחסון הדפדפן, ואז להתחבר דרך האפליקציה המפורסמת.
לתקלות בפונקציות backend יש שני מסלולים: להשתמש ב-skill בשם base44-troubleshooter מול סוכן קוד, שמושך ומנתח את הלוגים בשבילכם, או להריץ את פקודת logs ב-CLI ולסנן לפי שם הפונקציה, רמת חומרה וטווח זמן. ואם אחרי הבידוד ברור שזו התנהגות של הפלטפורמה ולא שלכם, תעדו את השחזור המדויק ופנו לקהילת המפתחים ב-GitHub Discussions של Base44. משרד רואי חשבון בראשון לציון שאיבד יומיים על "באג" שהיה טוקן מקומי הוא בדיוק המקרה שהסדר הזה מונע.
שים לב: הטעות הנפוצה היא לבקש מה-AI לתקן לפני שבודדתם את השכבה, וכך לקבל שינויים בשלושה קבצים שלא קשורים לבעיה. תמיד תבודדו קודם ותשנו דבר אחד בכל פעם.
11.7 Monitoring API ו-Audit Logs API
רמה: מפתחים
כשאפליקציה אחת הופכת לעשרים אפליקציות בארגון, לוח הבקרה של כל אפליקציה בנפרד כבר לא מספיק. לשם כך יש שני ממשקי API ברמת ה-workspace (סביבת העבודה הארגונית), ושניהם מיועדים ללקוחות Enterprise ודורשים מפתח API ברמת ה-workspace ותפקיד admin או owner. את מזהה ה-workspace מוצאים בהגדרות החשבון ב-app.base44.com, בתוך כתובת העמוד.
Audit Logs API עונה על השאלה מי עשה מה ומתי. הוא נועד לניטור אבטחה, לעמידה ברגולציה ולהזרמת אירועים ל-SIEM, והוא מחזיר אירועים מכל האפליקציות ב-workspace, בניגוד ליומן הלוגים של האפליקציה, שמוגבל לאפליקציה אחת. סוגי האירועים מקובצים לפי תחום: אימות (auth.login, auth.mfa, auth.password_changed), קריאות לפונקציות ועריכת קוד (api.function.call, api.code.editing), פעולות על רשומות (app.entity.created, app.entity.permanently_deleted), שינויי סכימה, חברי workspace והזמנות, הגדרות SSO, מפתחות API, דומיינים, מחזור חיי אפליקציה (app.published, app.unpublished) ואינטגרציות.
אירוע אחד שווה תשומת לב מיוחדת: app.security.check_run, שנרשם בסיום סריקת אבטחה. הוא כולל ספירה של ממצאים לפי חומרה (critical, high, medium ו-low) וגם ממצאים שאינם מדורגים, כמו המלצות הרשאות ברמת שורה וסודות שנכתבו קשיח בקוד. את הממצאים המלאים מושכים בבקשת GET לנתיב /api/v1/audit-logs/{workspace_id}/security-scan-runs/{run_id}, עם מפתח שיש לו הרשאת AUDIT_LOGS_READ. שימו לב לשדות הכיסוי: אם מקטע בסריקה נכשל או לא רץ, מספר הממצאים הוא רצפה ולא תמונה מלאה, והתשובה לא מחזירה קטעי קוד או סודות עצמם.
Monitoring API עונה על שאלה אחרת לגמרי: מי צורך מה. הוא חושף פעילות של חברי ה-workspace, צריכת קרדיטים מול מאגר הקרדיטים ומגבלות לכל חבר, רשימת האפליקציות של כל משתמש ודגלי תצורה ואבטחה ברמת אפליקציה. התגובות מחולקות לעמודים בשיטת cursor, עד חמישים פריטים בעמוד, ולשני הממשקים יש מגבלות קצב שצריך להביא בחשבון בתזמון המשיכות.
ההבחנה הפרקטית: Audit הוא פורנזיקה וביקורת, Monitoring הוא ממשל ועלויות. חברת ביטוח ישראלית שנדרשת לתקן ISO 27001 תזרים את הראשון ל-SIEM, ותשתמש בשני כדי לדעת אילו צוותים שורפים את הקרדיטים.
שים לב: הטעות הנפוצה היא לצפות שהממשקים האלה יחליפו את יומן הלוגים היומיומי של האפליקציה. הם נועדו לתמונה הארגונית, ולבדיקת תקלה נקודתית תמשיכו לעבוד מול Logs של האפליקציה.
בתיעוד הרשמי: Monitoring & Audit APIs
