מה זה Remote Config ואיך הוא עובד?
לפי התיעוד של Firebase פרמטרים של Remote Config הם זוגות של מפתח וערך שמגדירים בקונסולה של Firebase או דרך ה-API. האפליקציה קוראת את הערך ומתנהגת לפיו: מציגה או מסתירה פיצ'ר, משנה טקסט של כפתור, קובעת סדר של מסכים.
המנגנון בנוי מארבעה שלבים. המפתח מגדיר בקוד ערכי ברירת מחדל, כך שהאפליקציה עובדת גם בלי חיבור לשרת. בקונסולה מגדירים לאותם פרמטרים ערכים חדשים. ספריית הלקוח של Remote Config מושכת את הערכים ושומרת אותם במטמון. בסוף האפליקציה מפעילה אותם. השלב האחרון נפרד בכוונה: לפי התיעוד אתם שולטים במועד שבו הערכים החדשים מופעלים ומשפיעים על חוויית המשתמש.
מחזור החיים של פרמטר
מהקוד ועד שהמשתמש רואה את השינוי
לכל פרמטר אפשר להגדיר גם ערכים מותנים. תנאי הוא קבוצה של כלל אחד או יותר, שכולם צריכים להתקיים. לפי התיעוד אפשר להתנות לפי גרסת האפליקציה, מערכת ההפעלה, שפת המכשיר, מדינה, קהלים ומאפייני משתמש של Google Analytics, אחוז אקראי של משתמשים ועוד. כשכמה תנאים מתקיימים יחד, התנאי בעדיפות הגבוהה ביותר בקונסולה קובע.
מה אפשר לשנות בלי גרסה חדשה ומה לא?
זאת הנקודה שהכי חשוב להבין לפני שמבטיחים משהו להנהלה. Remote Config לא מוסיף קוד לאפליקציה אלא רק בוחר בין אפשרויות שכבר קיימות בה. כפתור בצבע אחר, סדר שונה של שלבי הרשמה או מחיר שמוצג במסך יכולים להשתנות מרחוק רק אם המפתח קרא את הערך שלהם מפרמטר. מסך חדש לגמרי דורש גרסה.
המשמעות המעשית היא שניסויים מתכננים גרסה אחת קדימה: מחליטים מה רוצים לבדוק, המפתחים עוטפים את האפשרויות בפרמטרים ומשחררים. רק אז אפשר להפעיל ניסוי מהקונסולה.
התיעוד של Firebase מגדיר גם שלושה דברים שאסור לעשות עם Remote Config: לא לבצע דרכו עדכונים שצריכים לדרוש אישור של המשתמש, לא לשמור מידע סודי במפתחות או בערכים של פרמטרים ולא לנסות לעקוף דרכו את הדרישות של פלטפורמת היעד של האפליקציה.
מתי הערך החדש מגיע למשתמש?
לא מיד, אלא אם תכננתם את זה. לפי התיעוד מרווח המשיכה המינימלי של Remote Config הוא 12 שעות כברירת מחדל. אפליקציה שמנסה למשוך יותר מדי פעמים בזמן קצר נתקלת בהגבלת קצב (throttling). בזמן פיתוח אפשר להגדיר מרווח נמוך, אבל התיעוד מדגיש שההגדרה הזאת מיועדת לפיתוח בלבד ולא לאפליקציה בייצור.
מעבר למרווח, יש החלטה על אסטרטגיית הטעינה. התיעוד מתאר שלוש:
| אסטרטגיה | איך היא עובדת | מתי היא מתאימה |
|---|---|---|
| Fetch and activate on load | מושכים ומפעילים עם עליית האפליקציה | שינויים שלא גורמים לקפיצה חזותית בממשק |
| Activate behind loading screen | מציגים מסך טעינה עד שהערכים הגיעו, עם מגבלת זמן משלכם | שינויים שחייבים להופיע כבר במסך הראשון |
| Load new values for next startup | מפעילים את מה שנמשך בפעם הקודמת ומושכים ברקע לפעם הבאה | כשמהירות העלייה חשובה יותר מעדכניות הערך |
יש גם עדכונים בזמן אמת: האפליקציה רושמת מאזין, השרת מודיע לה כשפורסמה גרסה חדשה של התצורה והיא מושכת אותה מיד. לפי התיעוד המשיכה הזאת עוקפת את מרווח המשיכה המינימלי. החיבור לשרת נשמר כל עוד האפליקציה בחזית. ההמלצה של Firebase היא למשוך פעם אחת בעלייה ואז להאזין לעדכונים.
כלל אחד מהתיעוד שנוגע ישירות לניסויים: לא משנים רכיב בממשק בזמן שהמשתמש צופה בו או משתמש בו. ערך שמתחלף באמצע סשן גם פוגע בחוויה וגם מלכלך את המדידה.
מה ההבדל בין תנאי, rollout וניסוי A/B?
שלושתם משתמשים באותם פרמטרים, אבל עונים על שאלות שונות.
| המנגנון | מה הוא עושה | השאלה שהוא עונה עליה |
|---|---|---|
| ערך מותנה | נותן ערך אחר לקבוצה שהגדרתם, למשל מדינה או גרסה | מי צריך לקבל מה |
| Rollout | משחרר פיצ'ר בהדרגה ומשווה יציבות ומדדים מול קבוצת ביקורת | האם בטוח להרחיב את השחרור |
| ניסוי A/B | מחלק משתמשים אקראית בין baseline ל-variants ומודד מול מדד יעד | איזו גרסה טובה יותר |
לפי התיעוד rollout מנוטר באמצעות Crashlytics ו-Google Analytics, כולל השוואת יציבות בין קבוצת השחרור לקבוצת הביקורת. את הצד של ניטור הקריסות פירטנו בניטור קריסות עם Firebase Crashlytics. ניסויי A/B ו-rollouts חולקים את אותה מכסה של תהליכים פעילים.
איך מקימים ניסוי A/B על Remote Config?
- מוודאים ש-Google Analytics מופעל בפרויקט. לפי התיעוד הניסוי צריך גישה לנתוני Analytics. בלי זה אין מדדי יעד.
- כותבים היפותזה ומדד יעד לפני שפותחים את הקונסולה. מה משנים, למי ואיזה מדד אמור לזוז. את השיטה פירטנו בכתיבת היפותזה ותיעדוף ניסויים.
- יוצרים ניסוי. בקונסולה של Firebase נכנסים ל-A/B Testing, לוחצים Create experiment ובוחרים Remote Config.
- מגדירים טירגוט וחשיפה. בוחרים את האפליקציה ואת התנאים, למשל גרסה, שפה או מאפיין משתמש. קובעים איזה אחוז מקהל היעד ייכנס לניסוי. אפשר להתחיל באחוז קטן ולהגדיל.
- שוקלים אירוע הפעלה. Activation event מגביל את המדידה למשתמשים שביצעו אירוע מסוים. המשתמשים האחרים עדיין מקבלים את הערכים, אבל לא נספרים בתוצאות. זה שימושי כשהשינוי נמצא במסך שרק חלק מהמשתמשים מגיעים אליו.
- בוחרים מדד יעד ומדדים נוספים. מדד היעד קובע מי מוביל. לפי התיעוד אפשר לעקוב אחרי עד חמישה מדדים נוספים, למשל הכנסות מרכישות, שימור או אחוז המשתמשים ללא קריסות.
- מגדירים variants. baseline ולפחות variant אחד. לכל variant קובעים ערכים לפרמטרים. המשקלים שווים כברירת מחדל. לפי התיעוד משקלים לא שווים עלולים להאריך את זמן איסוף הנתונים. אי אפשר לשנות אותם אחרי שהניסוי התחיל.
- בודקים על מכשיר לפני שמתחילים. אפשר לטרגט מכשירי בדיקה מסוימים לפי Firebase Installation ID ולוודא שכל variant נראה כמו שצריך. את אירועי המדידה עצמם בודקים כפי שתיארנו בבדיקת אירועים ב-DebugView.
לפי התיעוד השיוך ל-variant נקבע לפי המשקלים ולפי hash של מזהה הניסוי ומזהה ההתקנה של Firebase. משתמש שנכנס לניסוי נשאר באותו variant כל עוד הניסוי פעיל, גם אם המאפיינים שלו השתנו.
איך Firebase קובע מי מוביל וכמה זמן מריצים?
לפי התיעוד Firebase A/B Testing משתמש בהסקה סטטיסטית מסוג frequentist. רמת המובהקות היא 0.05, כלומר p-value נמוך מ-0.05 נחשב הבדל מובהק. המבחן הוא חד צדדי: למדדים רציפים משמש מבחן t עם שונויות לא שוות ולמדדי המרה מבחן z לפרופורציות. לצד התוצאה מוצג רווח סמך של 95 אחוז.
variant מוגדר כמוביל כשיש לו הבדל מובהק מה-baseline במדד היעד. אם כמה עומדים בתנאי, נבחר זה עם ה-p-value הנמוך ביותר. הקביעה נשענת על מדד היעד בלבד, לכן התיעוד ממליץ לעבור על המדדים הנוספים לפני שמשחררים לכולם. variant שמעלה רכישות ומוריד שימור הוא לא מנצח.
לגבי משך: לפי התיעוד שבועיים הם זמן הריצה המינימלי המומלץ לניסוי Remote Config טיפוסי. הנתונים מעובדים עד 90 יום מתחילת הניסוי, שאחריהם הוא נעצר אוטומטית. Firebase לא דורש לקבוע גודל מדגם מינימלי מראש, אבל זה לא אומר שכל אפליקציה יכולה להגיע למובהקות: כשמספר המשתמשים קטן או שההבדל הצפוי קטן, הניסוי פשוט לא יכריע. איך מעריכים את זה מראש הסברנו במחשבון גודל מדגם לניסוי A/B ובמתי אין מספיק נתונים לניסוי A/B.
אילו מגבלות צריך להכיר?
| המגבלה | הערך לפי התיעוד של Firebase |
|---|---|
| ניסויים ו-rollouts פעילים במקביל | עד 24 יחד |
| סך הניסויים בפרויקט, כולל rollouts | עד 300 |
| variants בניסוי, כולל ה-baseline | עד 8 |
| פרמטרים לכל variant | עד 25 |
| פרמטרים של Remote Config בפרויקט | עד 3,000 לכל סוג תבנית |
| תנאים בפרויקט | עד 2,000 |
| אורך מפתח של פרמטר | עד 256 תווים |
| משך עיבוד נתוני ניסוי | עד 90 יום מתחילתו |
שתי מגבלות נוספות אינן מספרים. הראשונה: אירוע ההפעלה לא יכול להיות app_install, app_remove או app_update. הוא גם לא יכול לשמש באותו ניסוי כמדד יעד או כמדד נוסף. השנייה נוגעת לטירגוט לפי קהלים של Google Analytics. לפי התיעוד לקהלים יש השהיה, כך שמשתמש חדש עשוי להיכנס לקהל רק אחרי 24 עד 48 שעות. משתמש שעוד לא בקהל ברגע שהאפליקציה מושכת ומפעילה את הערכים לא ייכלל בניסוי. לכן ניסוי על משתמשים חדשים עדיף לטרגט בתנאי אחר ולא בקהל.
מה עושים כשהניסוי מסתיים?
מהקונסולה אפשר לשחרר variant לכלל המשתמשים. לפי התיעוד אפשר לעשות את זה גם כשאין מנצח ברור. במקרה כזה ההחלטה היא שלכם ולא של הנתונים. כדאי לתעד אותה כך.
מי שרוצה לבדוק את התוצאה בעצמו יכול לעשות זאת ב-BigQuery. לפי התיעוד ל-A/B Testing אין טבלה נפרדת. השיוך לניסוי נשמר על אירועי Analytics כמאפיין משתמש בשם firebase_exp ואחריו מספר הניסוי. הערך הוא האינדקס של ה-variant, שמתחיל באפס. כך אפשר לחשב כל מדד לפי variant, גם מדד שלא הוגדר בניסוי. את הקמת הייצוא פירטנו בייצוא GA4 ל-BigQuery.
השלב שרוב הצוותים שוכחים הוא ניקיון. פרמטר שהניסוי שלו הסתיים נשאר בקוד ובקונסולה, כך שאחרי כמה חודשים אף אחד לא זוכר אילו ערכים עדיין בשימוש. אני ממליץ לנהל רשימה של פרמטרים פעילים ולהסיר מהקוד את האפשרות שהפסידה בגרסה הבאה.
שאלות נפוצות
מה זה Firebase Remote Config?
Remote Config הוא שירות ענן של Firebase שמאפשר לשנות את ההתנהגות ואת המראה של אפליקציה דרך פרמטרים של מפתח וערך. האפליקציה מגדירה ערכי ברירת מחדל בקוד, מושכת ערכים מעודכנים מהשרת ומפעילה אותם במועד שהמפתח קבע. אפשר לשנות כך רק דברים שכבר נכתבו בקוד מאחורי פרמטר. מסך או פיצ'ר חדש לגמרי עדיין דורש גרסה.
כל כמה זמן האפליקציה מושכת ערכים חדשים מ-Remote Config?
לפי התיעוד של Firebase מרווח המשיכה המינימלי הוא 12 שעות כברירת מחדל. בזמן פיתוח אפשר להגדיר מרווח נמוך יותר, אבל ההגדרה הזאת מיועדת לפיתוח בלבד. עדכונים בזמן אמת, שפועלים דרך מאזין שהאפליקציה רושמת, עוקפים את המרווח המינימלי כל עוד האפליקציה בחזית.
כמה ניסויי A/B אפשר להריץ במקביל ב-Firebase?
לפי התיעוד של Firebase אפשר להריץ עד 24 ניסויי A/B ו-rollouts של Remote Config יחד באותו זמן. סך הניסויים בפרויקט מוגבל ל-300, כולל rollouts. כל ניסוי יכול לכלול עד 8 variants כולל ה-baseline ועד 25 פרמטרים לכל variant.
כמה זמן צריך להריץ ניסוי A/B ב-Firebase?
לפי התיעוד של Firebase שבועיים הם זמן הריצה המינימלי המומלץ לניסוי Remote Config טיפוסי. נתוני הניסוי מעובדים עד 90 יום מתחילתו. אחרי זה הניסוי נעצר אוטומטית. Firebase לא דורש לקבוע גודל מדגם מראש, אבל ניסוי עם מעט משתמשים או הבדל צפוי קטן עלול לא להגיע להכרעה.
מה ההבדל בין rollout לניסוי A/B ב-Remote Config?
Rollout משחרר פיצ'ר בהדרגה לקבוצה גדלה של משתמשים ומנטר אותו באמצעות Crashlytics ו-Google Analytics מול קבוצת ביקורת. המטרה היא לוודא שבטוח להרחיב את השחרור. ניסוי A/B מחלק משתמשים אקראית בין baseline ל-variants ובודק במבחן סטטיסטי איזו גרסה טובה יותר במדד היעד. שניהם חולקים מכסה של 24 תהליכים פעילים.
האם אפשר לנתח את תוצאות ניסוי Firebase ב-BigQuery?
כן. לפי התיעוד של Firebase ל-A/B Testing אין טבלה נפרדת ב-BigQuery. השיוך לניסוי נשמר על אירועי Analytics כמאפיין משתמש בשם firebase_exp ואחריו מספר הניסוי. הערך הוא האינדקס של ה-variant, שמתחיל באפס. צריך להפעיל את הייצוא ל-BigQuery בהגדרות הפרויקט.
מה השורה התחתונה?
Remote Config ו-A/B Testing נותנים לאפליקציה את מה שלאתר יש מזמן: היכולת לבדוק שינוי על חלק מהמשתמשים ולהחליט לפי נתונים. המחיר הוא תכנון מראש: השינוי חייב להיכתב בקוד מאחורי פרמטר, מדד היעד חייב להיות אירוע שנמדד נכון והניסוי צריך מספיק משתמשים וזמן כדי להכריע. כשאחד מהשלושה חסר מקבלים תוצאה שאי אפשר לסמוך עליה. אנחנו מתכננים את המדידה לניסויים, בודקים את האירועים ומנתחים את התוצאות כחלק משירות אנליטיקס וניטור אפליקציות, לצד בחירת כלי המדידה שתיארנו בAppsFlyer מול Firebase. אם אתם רוצים להתחיל להריץ ניסויים באפליקציה ולא בטוחים שהתשתית מוכנה, כתבו לנו.
מקורות
Firebase: Firebase Remote Config, Firebase: Remote Config parameters and conditions, Firebase: Firebase Remote Config loading strategies, Firebase: Get started with Remote Config on Android, Firebase: Create Firebase Remote Config Experiments with A/B Testing, Firebase: About Firebase A/B tests
יועץ אנליטיקה דיגיטלית ומייסד DigiKnowledge. מרצה לאנליטיקה דיגיטלית באוניברסיטת תל אביב, באוניברסיטה הפתוחה ובאוניברסיטת אריאל. לעמוד האישי