גילוי נאות: המדריך כולל קישורי שותפים ל-Base44. הרשמה דרכם אינה מייקרת לך דבר. חלק מהקישורים למטה יוחלפו בקישורי Impact כשיהיו מוכנים.
[התחל ב-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 דרך לשונית הקוד, ותייחס את ההמרות שם. אל תנסה להשוות בין שתי המערכות מספר מול מספר, הן סופרות אחרת, ותמיד יהיה פער.
שים לב לשמירת הנתונים: היא משתנה לפי התוכנית, שבעה ימים בחינמית, שלושים יום בתוכניות הבאות, ושנה בתוכנית הארגונית. אם אתה מנתח עונתיות או משווה חודש לחודש, שבעה ימים לא יספיקו, וזה שיקול אמיתי. אפשר [בדוק תוכניות Base44, יוחלף בקישור Impact] ולראות מה כל תוכנית פותחת. את הגישה ללוח אפשר להגביל בהרשאות, ואפשר גם לכבות את האנליטיקס לגמרי.
שים לב: הטעות הנפוצה היא להסתפק במספר הכניסות כמדד הצלחה, במקום להגדיר שניים או שלושה אירועים מותאמים שמודדים את הפעולה שבאמת מייצרת ערך לעסק.
11.3 הקלטות סשן
רמה: מתקדם
אנליטיקס אומר לך שחמישים אחוז נוטשים בעמוד התשלום. הקלטות סשן מראות לך למה. זו יכולת שמתעדת את המסך של משתמשים באפליקציה המפורסמת שלך ומאפשרת לך לצפות בהקלטה אחר כך, כולל סימון אוטומטי של נקודות חיכוך.
ההפעלה היא בארבעה שלבים: נכנסים ל־Dashboard, עוברים ל־App Settings, מאתרים את האזור Advanced Capabilities, מדליקים את המתג של Session recordings ומפרסמים מחדש את האפליקציה. הצפייה עצמה נמצאת ב־Dashboard תחת Analytics, בלשונית Session recordings. כל שורה ברשימה מציגה מזהה הקלטה, תאריך, משך, מיקום המשתמש, דפדפן, מערכת הפעלה וסוג מכשיר.
בנגן אפשר להאיץ את הקצב, לדלג על זמני חוסר פעילות, לקפוץ ישירות לנקודות החיכוך ולפתוח כלי פיתוח עם נתוני קונסול, רשת וביצועים. המערכת מסמנת לבד rage clicks (לחיצות זעם על אלמנט שלא מגיב), dead clicks (לחיצות על משהו שאינו לחיץ) ושגיאות, ואלה בדיוק שלוש הנקודות שצריך לחפש קודם. אפשר גם לבקש סיכום AI שמדרג את חומרת החיכוך ומציע תיקונים, עד חמישים סיכומים בחלון של שלושים יום.
אל תצפה בהקלטות אקראיות; זה בזבוז זמן. סנן לפי סוג תקלה, מכשיר, מדינה, דפדפן, מערכת הפעלה או עמוד ספציפי, וצפה רק בסשנים שנגעו במסך שאתה חוקר. אפשר לחפש לפי מזהה או שם, לסמן הקלטות במועדפים, לשנות להן שם כדי לזהות אותן אחר כך, ולמחוק לצמיתות, מחיקה כזאת אינה הפיכה.
שים לב למגבלות: עד חמש מאות סשנים לאפליקציה בחלון מתגלגל של שלושים יום, ושמירה של שלושים יום בלבד. מי שרוצה להשוות התנהגות לפני ואחרי שינוי צריך להוציא את המסקנות בתוך החלון הזה. היכולת דורשת תוכנית Builder ומעלה, אם אתה בתוכנית חינמית או Starter תצטרך [בדוק תוכניות Base44, יוחלף בקישור Impact].
ועכשיו החלק שישראלים נוטים לפספס: האחריות המשפטית עליך. הקלטת סשנים עשויה לחייב הסכמת מבקר באזורים כמו האיחוד האירופי, בריטניה וקליפורניה, ו־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
[התחל ב-Base44, יוחלף בקישור Impact]
