מילון אירועים לאפליקציה: איך מתכננים שמות, פרמטרים ומאפייני משתמש

נכתב על ידי דני צ'רניאק, DigiKnowledge. נבדק לאחרונה: 10.11.2026

למה צריך מילון אירועים לפני שכותבים קוד?

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

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

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

אילו כללי שמות Firebase ו-GA4 אוכפים?

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

בנוסף יש שמות וקידומות שמורים. אירוע מותאם לא יכול לקבל שם של אירוע שהמערכת שולחת בעצמה, למשל first_open, session_start, user_engagement או app_update. שם של פרמטר או של מאפיין משתמש לא יכול להתחיל בקו תחתון או באחת מהקידומות firebase_‎, ga_‎ או google_‎ (בפרמטרים שמורה גם הקידומת gtag עם נקודה אחריה). התיעוד כולל גם רשימה של שמות פרמטרים ומאפייני משתמש שמורים, שכדאי לעבור עליה פעם אחת לפני שסוגרים את המילון.

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

איך בוחרים שם לאירוע?

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

קודם בודקים אם השם כבר קיים. אירועים כמו first_open, session_start ו-screen_view נאספים אוטומטית, כך שאין סיבה לשלוח אירוע משלכם על פתיחה ראשונה או על תחילת סשן. לפעולות נפוצות Google מגדירה אירועים מומלצים עם שמות ופרמטרים קבועים: אם הפעולה שלכם היא הרשמה, השם הוא sign_up ולא registration_done. לפי התיעוד, שליחה שלהם עם הפרמטרים שנקבעו להם נותנת את הפירוט המלא בדוחות ומאפשרת ליהנות מיכולות שיתווספו בעתיד.

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

ערך שמשתנה שייך לפרמטר ולא לשם. במקום שלושה אירועים בשם faq_open_shipping, faq_open_returns ו-faq_open_payment שולחים אירוע אחד בשם faq_open עם פרמטר faq_topic. הסיבה אינה רק סדר: לפי התיעוד של Firebase אפליקציה יכולה לתעד עד 500 סוגי אירועים שונים. שמות שנוצרים מתוך ערכים דינמיים מגיעים לתקרה הזאת מהר.

איך מתכננים פרמטרים?

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

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

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

השלישי הוא רישום. לפי התיעוד של Firebase פרמטר מותאם צריך להירשם כמימד או כמדד מותאם כדי להופיע בדוחות. לפי התיעוד של GA4 המכסה בנכס רגיל היא 50 מימדים מותאמים ברמת האירוע, 25 ברמת המשתמש ו-50 מדדים מותאמים. אחרי הרישום עוברות 24 עד 48 שעות עד שאפשר לדווח לפיו, לכן במילון יש עמודה שאומרת אם הפרמטר נרשם או רק נשלח. Google ממליצה לא ליצור שלא לצורך מימדים עם קרדינליות גבוהה וגם לא לרשום פרמטר שכבר קיים כמימד מובנה, כי הרישום הזה צורך מקום במכסה בלי להוסיף דבר.

לפרמטרים שצריכים ללוות את כל האירועים יש ב-SDK מנגנון ייעודי. לפי התיעוד setDefaultEventParameters מצמיד פרמטרים לכל האירועים שיתועדו מאותו רגע. במילון מסמנים את הפרמטרים האלה בנפרד, כדי שלא יוגדרו שוב ושוב בכל שורה.

מתי משתמשים במאפיין משתמש ולא בפרמטר?

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

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

מה אסור שייכנס למילון?

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

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

איך נראית שורה במילון?

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

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

איך מתחזקים את המילון בין גרסאות?

1. ממנים בעלים אחד. אדם אחד מאשר כל שורה חדשה. בלי זה כל צוות מוסיף אירועים בסגנון שלו.
2. מעדכנים את המילון לפני הקוד. אירוע חדש נכנס קודם לגיליון, עם שם, פרמטרים ורגע שליחה. רק אחר כך נפתחת משימת פיתוח.
3. שומרים על זהות בין הפלטפורמות. אותו שם ואותם פרמטרים ב-iOS, ב-Android ובאתר. בגלל הרגישות לאותיות, הבדל של אות גדולה אחת מפצל את האירוע.
4. בודקים מול המילון לפני שחרור. כל אירוע נבדק במכשיר בדיקה: שם, פרמטרים וערכים. את התהליך פירטנו בבדיקת אירועים ב-DebugView.
5. רושמים מימדים באותו יום. פרמטר שסומן לרישום נרשם בנכס עם השחרור, כי הנתונים זמינים לדיווח רק 24 עד 48 שעות אחרי הרישום.
6. לא משנים שם קיים. אם חייבים להחליף, מוסיפים אירוע חדש ומסמנים את הישן כמופסק עם מספר הגרסה. כך ברור מאיזה תאריך להשוות.

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

שאלות נפוצות

מה השורה התחתונה?

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

מקורות

Google Analytics Help: Event naming rules, Google Analytics Help: Event collection limits, Firebase: Log events, Firebase: Set user properties, Google Analytics Help: [GA4] About custom dimensions and metrics, Google Analytics Help: [GA4] Recommended events

דני צ'רניאק
יועץ אנליטיקה דיגיטלית ומייסד DigiKnowledge. מרצה לאנליטיקה דיגיטלית באוניברסיטת תל אביב, באוניברסיטה הפתוחה ובאוניברסיטת אריאל. לעמוד האישי