פרמטרים ותנאים של הגדרת תצורה מרחוק בתבניות של לקוחות

בחירת סוג התבנית:

תבניות בצד הלקוח תבניות בצד השרת

אתם יכולים להציג פרמטרים וערכים של Remote Config מתבניות לקוח לכל מופע של אפליקציה שמטמיע את ערכות ה-SDK של לקוח Firebase ל-Remote Config, כולל אפליקציות ל-Apple, ל-Android, לאינטרנט, ל-Flutter, ל-Unity ול-C++‎.

כשמשתמשים במסוף Firebase או בממשקי ה-API לקצה העורפי של Remote Config, מגדירים פרמטר אחד או יותר (צמדי מפתח/ערך) ומספקים ערכי ברירת מחדל באפליקציה לפרמטרים האלה. אפשר לשנות את ערכי ברירת המחדל באפליקציה על ידי הגדרת ערכי פרמטרים. מפתחות וערכים של פרמטרים הם מחרוזות, אבל אפשר להמיר ערכי פרמטרים לסוגי נתונים אחרים כשמשתמשים בערכים האלה באפליקציה.

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

באמצעות מסוף Firebase, Admin SDK או Remote Config API בארכיטקטורת REST, אתם יכולים ליצור ערכי ברירת מחדל חדשים לפרמטרים, וגם ערכים מותנים שמשמשים לטירגוט קבוצות של מופעי אפליקציה. בכל פעם שמעדכנים את ההגדרות במסוף Firebase, מערכת Firebase יוצרת ומפרסמת גרסה חדשה של התבנית של Remote Config. הגרסה הקודמת נשמרת, ואפשר לאחזר אותה או לחזור אליה לפי הצורך. הפעולות האלה זמינות במסוף Firebase, ב-Firebase Admin SDK וב-API בארכיטקטורת REST, והן מתוארות בהרחבה במאמר ניהול גרסאות של תבניות Remote Config.

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

תנאים, כללים וערכים מותנים

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

לדוגמה, פרמטר שמגדיר את דף הפתיחה של אפליקציה יכול להציג תמונות שונות בהתאם לסוג מערכת ההפעלה באמצעות הכלל if device_os = Android:

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

לפרמטר יכולים להיות כמה ערכים מותנים שמשתמשים בתנאים שונים, ופרמטרים יכולים לחלוק תנאים בתוך פרויקט. במסוף Firebase, נכנסים לדף DevOps & Engagement (DevOps ומעורבות) > Remote Config (הגדרת תצורה מרחוק) > Parameters (פרמטרים) כדי לראות את אחוז השליפה של הערכים המותנים של כל פרמטר. המדד הזה מציין את אחוז הבקשות ב-24 השעות האחרונות שקיבלו כל ערך.

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

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

1. במסוף Firebase, עוברים אל DevOps & Engagement (פיתוח ותפעול ומעורבות) > Remote Config (הגדרת תצורה מרחוק) > הדף Conditions (תנאים) (או בוחרים באפשרות Manage conditions (ניהול תנאים) בדף Parameters (פרמטרים)).
2. הוספת תנאי: לוחצים על הוספת תנאי (או על יצירת התנאי הראשון), מזינים שם שמגדיר את יעד הטירגוט ובוחרים כלל טירגוט אחד או יותר.
3. עריכת תנאי: לוחצים על שם התנאי או על סמל העריכה, משנים את הכללים לפי הצורך ולוחצים על שמירה.
4. שינוי העדיפות של התנאים: בדף Conditions, גוררים את התנאים באמצעות נקודת האחיזה שלהם כדי לשנות את הסדר שלהם. לתנאים שמופיעים גבוה יותר ברשימה יש עדיפות על פני תנאים שמופיעים נמוך יותר ברשימה.
5. מחיקת תנאי: לוחצים על סמל המחיקה לצד התנאי שרוצים להסיר. אם התנאי מקושר לפרמטר כלשהו, הסרת התנאי תסיר גם את הערכים המותנים המשויכים.

אחרי ששומרים את השינויים בתנאים, מפרסמים את התבנית באמצעות Publish changes (פרסום השינויים).

מגבלת IPv6 עם בקרת גישה מבוססת-IP

ל-Remote Config יש תמיכה מוגבלת ב-IPv6 כשמשתמשים בו עם כללי מדיניות גישה שמבוססים על IP. אם הארגון שלכם מגביל את הגישה לטווחי כתובות IP ציבוריות ספציפיות, התחברות דרך רשת IPv6 עלולה לגרום לבעיות הבאות:

• גישה למסוף: יכול להיות שלא תוכלו להשתמש בתכונות מסוימות של Remote Config במסוף Firebase, כמו טעינת נתונים או הגדרת טירגוט.
• גישת לקוח: יכול להיות שבאפליקציות לקוח יופיעו שגיאות PERMISSION_DENIED.

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

עדיפות של ערך הפרמטר

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

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

2. אם אין ערכים מותנים עם תנאים שמוערכים כ-true, ערך ברירת המחדל של Remote Config מסופק כשאפליקציה מאחזרת ערכים מה-backend. אם פרמטר לא קיים בקצה העורפי, או אם ערך ברירת המחדל מוגדר כ-Use in-app default, לא יסופק ערך לפרמטר הזה כשהאפליקציה תאחזר ערכים.

   הערה: כשמשתמשים בפרמטר Remote Config בניסוי פעיל ב-Firebase A/B Testing, ערכי הניסוי מקבלים קדימות על פני כל ערך מותנה של Remote Config.

באפליקציה, ערכי הפרמטרים מוחזרים על ידי שיטות get לפי רשימת העדיפויות הבאה

1. אם ערך אוחזר מה-backend ואז הופעל, האפליקציה משתמשת בערך שאוחזר. ערכי הפרמטרים שהופעלו נשמרים.

2. אם לא אוחזר ערך מה-backend, או אם הערכים שאוחזרו מה-backend של Remote Config לא הופעלו, האפליקציה משתמשת בערך ברירת המחדל שמוגדר בה.

   למידע נוסף על קבלת ערכי ברירת מחדל והגדרתם, ראו הורדת ערכי ברירת המחדל של התבנית Remote Config.

3. אם לא הוגדר ערך ברירת מחדל באפליקציה, האפליקציה משתמשת בערך מסוג סטטי (כמו 0 עבור int ו-false עבור boolean).

התרשים הבא מסכם את סדר העדיפויות של ערכי הפרמטרים בקצה העורפי של Remote Config ובאפליקציה:

סוגי נתונים של ערכי פרמטרים

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

סוגי הנתונים הנתמכים הם:

• String
• Boolean
• Number
• JSON

בממשק המשתמש של מסוף Firebase, אפשר לבחור את סוג הנתונים בתפריט נפתח לצד מפתח הפרמטר. ב-API בארכיטקטורת REST, אפשר להגדיר סוגים באמצעות השדה value_type באובייקט הפרמטר.

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

קבוצות של פרמטרים

בעזרת Remote Config אפשר לקבץ פרמטרים כדי לשפר את הארגון של ממשק המשתמש ואת נוחות השימוש.

לדוגמה, נניח שאתם צריכים להפעיל או להשבית שלושה סוגים שונים של אימות בזמן שאתם משיקים תכונה חדשה של התחברות. ב-Remote Config, אתם יכולים ליצור את שלושת הפרמטרים כדי להפעיל את הסוגים שאתם רוצים, ואז לארגן אותם בקבוצה בשם "New login", בלי להוסיף קידומות או מיון מיוחד.

הערה: קבוצות של פרמטרים מאפשרות לארגן את הפרמטרים במסוף Firebase וב-API בארכיטקטורת REST של Remote Config. עם זאת, הם לא משנים את האופן שבו ערכת ה-SDK מפנה לפרמטרים.

אפשר ליצור קבוצות פרמטרים באמצעות מסוף Firebase או ה-API בארכיטקטורת REST של Remote Config. לכל קבוצת פרמטרים שיוצרים יש שם ייחודי בתבנית Remote Config. כשיוצרים קבוצות של פרמטרים, חשוב לזכור את הנקודות הבאות:

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

יצירה או שינוי של קבוצות פרמטרים באמצעות מסוף Firebase

אפשר לקבץ פרמטרים במסוף Firebase. כך יוצרים או משנים קבוצה:

1. במסוף Firebase, נכנסים לדף DevOps & Engagement ‏> הגדרת תצורה מרחוק ‏> Parameters.
2. לוחצים על ניהול קבוצות.
3. מסמנים את התיבות של הפרמטרים שרוצים להוסיף ולוחצים על העברה לקבוצה.
4. בוחרים קבוצה קיימת או יוצרים קבוצה חדשה: נותנים לה שם ומוסיפים תיאור, ולוחצים על יצירת קבוצה חדשה. אחרי ששומרים קבוצה, אפשר לפרסם אותה באמצעות הלחצן פרסום השינויים.

יצירת קבוצות באופן פרוגרמטי

Remote Config API בארכיטקטורת REST מספק דרך אוטומטית ליצור ולפרסם קבוצות של פרמטרים. אם אתם מכירים את REST ויש לכם הרשאה לשלוח בקשות ל-API, אתם יכולים לבצע את השלבים הבאים כדי לנהל קבוצות באופן פרוגרמטי:

1. מאחזרים את התבנית הנוכחית.
2. מוסיפים אובייקטים מסוג JSON כדי לייצג את קבוצות הפרמטרים.
3. מפרסמים את קבוצות הפרמטרים באמצעות בקשת HTTP PUT.

האובייקט parameterGroups מכיל מפתחות של קבוצות, עם תיאור ורשימה של פרמטרים מקובצים. שימו לב שכל מפתח קבוצה חייב להיות ייחודי באופן גלובלי.

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

{
  "parameters": {},
  "version": {
    "versionNumber": "1",

    …

  },
  "parameterGroups": {
    "new menu": {
      "description": "New Menu",
      "parameters": {
        "pumpkin_spice_season": {
          "defaultValue": {
            "value": "true"
          },
          "description": "Whether it's pumpkin spice season."
        }
      }
    }
  }
}

תנאים של אותות בהתאמה אישית

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

תנאים של אותות בהתאמה אישית זמינים בסביבות הלקוח הבאות:

• ‫iOS: גרסה 11.8.0 ואילך
• ‫Android: גרסה 22.1.0 ואילך (Firebase BoM גרסה 33.8.0 ואילך)
• אינטרנט: גרסה 11.2.0 ואילך
• ‫Flutter: גרסת Flutter BoM‏ 3.6.0 ומעלה

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

1. מוסיפים את banner_image_url ו-banner_link לתבנית הלקוח של Remote Config. הם מייצגים את התמונה של הבאנר ואת דף האירוע שמשויך לתמונה הזו.
2. מגדירים אותות בהתאמה אישית מהאפליקציה עם הערכים city ו-preferred_event_category.
3. מוסיפים ערכי ברירת מחדל לתבנית Remote Config הספציפית ללקוח ויוצרים ערכים מותנים על סמך האותות המותאמים אישית שהגדרתם בשלב הקודם.
4. מוסיפים ערכי ברירת מחדל לתבנית Remote Config הספציפית ללקוח, וערכים מותנים לכל תנאי שהגדרתם.
5. מעדכנים את קוד האפליקציה כדי להגדיר את התנאים של האותות בהתאמה אישית ולהשתמש בהם.

עכשיו האפליקציה יכולה להוריד את banner_image_url ו-banner_link המתאימים כשהיא מאחזרת את הפרמטרים האלה משרת Remote Config.

מגבלות

כשיוצרים תנאים לאותות בהתאמה אישית, צריך לפעול בהתאם למגבלות הבאות:

• מספר האותות בהתאמה אישית: אפשר ליצור עד 100 אותות בהתאמה אישית לכל מופע של אפליקציה. כדי לבטל אות מותאם אישית, צריך להגדיר את הערך שלו כ-null.
• שם האות המותאם אישית: כל שם של אות מותאם אישית יכול להכיל עד 250 תווים.
• ערך של אות מותאם אישית: כל ערך של אות מותאם אישית יכול להכיל עד 500 תווים. כשמשתמשים בביטויים רגולריים, המגבלה היא 250 תווים.

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

סוגי כללי תנאים

במסוף Firebase יש תמיכה בסוגי הכללים הבאים. תכונות מקבילות זמינות ב-API בארכיטקטורת REST של Remote Config, כפי שמפורט בהפניה לביטויים מותנים.

סוג הכלל	מפעילים	ערכים	הערה
אפליקציה	==	בוחרים מזהה אפליקציה מרשימת מזהי האפליקציות שמשויכות לפרויקט ב-Firebase.	כשמוסיפים אפליקציה ל-Firebase, מזינים מזהה חבילה או שם חבילה של Android שמגדירים מאפיין שמוצג בתור מזהה אפליקציה בכללי Remote Config. כך משתמשים במאפיין הזה: בפלטפורמות של אפל: משתמשים ב-CFBundleIdentifier של האפליקציה. מזהה החבילה נמצא בכרטיסייה General (כללי) של יעד האפליקציה הראשי ב-Xcode. ב-Android: משתמשים ב-applicationId של האפליקציה. אפשר למצוא את applicationId בקובץ build.gradle(.kts) ברמת האפליקציה.
גרסת אפליקציה	לערכי מחרוזת: התאמה מדויקת, מכיל, לא מכיל, מכיל ביטוי רגולרי לערכים מספריים: <, <=, =, !=, >, >=	מציינים את הגרסאות של האפליקציה שרוצים לטרגט. לפני שמשתמשים בכלל הזה, צריך להשתמש בכלל מזהה אפליקציה כדי לבחור אפליקציה ל-Android או ל-Apple שמשויכת לפרויקט Firebase.	בפלטפורמות של אפל: משתמשים ב-CFBundleShortVersionString של האפליקציה. הערה: ודאו שבאפליקציה שלכם ל-Apple מותקנת גרסה 6.24.0 ומעלה של Firebase Apple platforms SDK, כי CFBundleShortVersionString לא נשלח בגרסאות קודמות (ראו הערות המוצר). ב-Android: משתמשים ב-versionName של האפליקציה. הערה: אופרטורים להשוואה מספרית (<, <=, =, !=, >, >=) תומכים רק בגרסאות סמנטיות מספריות (כמו 1.2.3). הם לא תומכים בסיומות או במקפים של טרום-השקה (כמו -beta או -rc). במחרוזות של גרסאות עם סיומות או מקפים לא מספריים (כמו 1.5-beta), צריך להשתמש באופרטורים של מחרוזות (כמו מכיל ביטוי רגולרי, מכיל או תואם בדיוק). השוואות של מחרוזות בכלל הזה הן תלויות אותיות רישיות. כשמשתמשים באופרטור תואם בדיוק, מכיל, לא מכיל או מכיל ביטוי רגולרי, אפשר לבחור כמה ערכים. כשמשתמשים באופרטור מכיל ביטוי רגולרי, אפשר ליצור ביטויים רגולריים בפורמט RE2. הביטוי הרגולרי יכול להתאים לכל מחרוזת גרסת היעד או לחלק ממנה. אפשר גם להשתמש בעוגנים ^ ו-$ כדי להתאים את ההתחלה, הסוף או כל מחרוזת היעד.
מספר Build	לערכי מחרוזת: התאמה מדויקת, מכיל, לא מכיל, ביטוי רגולרי לערכים מספריים: =, ≠, >, ≥, <, ≤	מציינים את גרסאות ה-build של האפליקציה שרוצים לטרגט. לפני שמשתמשים בכלל הזה, צריך להשתמש בכלל מזהה אפליקציה כדי לבחור אפליקציה ל-Apple או ל-Android שמשויכת לפרויקט Firebase.	האופרטור הזה זמין רק לאפליקציות ל-Apple ול-Android. הוא תואם ל-CFBundleVersion של האפליקציה ב-Apple ול-versionCode ב-Android. השוואות של מחרוזות בכלל הזה הן תלויות אותיות רישיות. כשמשתמשים באופרטורים תואם בדיוק, מכיל, לא מכיל או מכיל ביטוי רגולרי, אפשר לבחור כמה ערכים. כשמשתמשים באופרטור מכיל ביטוי רגולרי, אפשר ליצור ביטויים רגולריים בפורמט RE2. הביטוי הרגולרי יכול להתאים לכל המחרוזת של גרסת היעד או לחלק ממנה. אפשר גם להשתמש בעוגנים ^ ו-$ כדי להתאים את ההתחלה, הסוף או כל מחרוזת היעד.
פלטפורמה	==	iOS Android אינטרנט
מערכת הפעלה	==	מציינים את מערכות ההפעלה שרוצים לטרגט. לפני שמשתמשים בכלל הזה, צריך להשתמש בכלל מזהה אפליקציה כדי לבחור אפליקציית אינטרנט שמשויכת לפרויקט Firebase.	הכלל הזה מקבל את הערך true במופע נתון של אפליקציית אינטרנט אם מערכת ההפעלה והגרסה שלה תואמות לערך יעד ברשימה שצוינה.
דפדפן	==	מציינים את הדפדפנים שרוצים לטרגט. לפני שמשתמשים בכלל הזה, צריך להשתמש בכלל מזהה אפליקציה כדי לבחור אפליקציית אינטרנט שמשויכת לפרויקט Firebase.	הכלל הזה מקבל את הערך true במופע נתון של אפליקציית אינטרנט אם הדפדפן והגרסה שלו תואמים לערך יעד ברשימה שצוינה.
קטגוריית מכשיר	הוא, הוא לא	נייד	הכלל הזה בודק אם המכשיר שניגש לאפליקציית האינטרנט הוא נייד או לא נייד (מחשב או קונסולה). סוג הכלל הזה זמין רק לאפליקציות אינטרנט.
שפות	נמצא ב-	בוחרים שפה אחת או יותר.	הכלל הזה מקבל את הערך true במופע נתון של אפליקציה אם המופע הזה מותקן במכשיר שמשתמש באחת מהשפות שברשימה.
ארץ/אזור	נמצא ב-	בוחרים אזור אחד או יותר או מדינה אחת או יותר.	הכלל הזה מקבל את הערך true במופע נתון של אפליקציה אם המופע נמצא באחד מהאזורים או באחת מהמדינות שברשימה. קוד המדינה של המכשיר נקבע לפי כתובת ה-IP של המכשיר בבקשה, או לפי קוד המדינה שנקבע על ידי Firebase Analytics (אם נתוני Analytics משותפים עם Firebase).
קהל או קהלים של משתמשים	כולל לפחות אחד מהבאים	בוחרים קהל אחד או יותר מתוך רשימה של Google Analytics קהלים שהגדרתם לפרויקט.	כדי להשתמש בכלל הזה, צריך להגדיר כלל של מזהה אפליקציה כדי לבחור אפליקציה שמשויכת לפרויקט ב-Firebase. הערה: מכיוון שקהלים רבים ב-Analytics מוגדרים לפי אירועים או מאפייני משתמשים, שיכולים להתבסס על הפעולות של משתמשי האפליקציה, יכול להיות שיחלוף זמן מה עד שהכלל משתמש בקהל ייכנס לתוקף במופע נתון של האפליקציה. כלומר, גם אם משתמש עומד בתנאים של קהל מסוים, אם Analytics עדיין לא הוסיף את המשתמש לקהל כש-fetchAndActivate() מופעל, המשתמש לא יעמוד בתנאי.
מאפיין משתמש	לערכי מחרוזת: contains, does not contain, exactly matches, contains regular expression לערכים מספריים: =, ≠, >, ≥, <, ≤ הערה: בצד הלקוח, אפשר להגדיר רק ערכי מחרוזת למאפייני משתמשים. בתנאים שמשתמשים באופרטורים מספריים, Remote Config ממיר את הערך של מאפיין המשתמש התואם למספר שלם או למספר עם נקודה צפה (float).	בוחרים מתוך רשימה של מאפייני משתמשים זמינים ב-Google Analytics.	כדי ללמוד איך להשתמש במאפייני משתמשים כדי להתאים אישית את האפליקציה לפלחים ספציפיים מאוד של בסיס המשתמשים, קראו את המאמר Remote Config ומאפייני משתמשים. מידע נוסף על מאפייני משתמשים זמין במדריכים הבאים: הגדרה של מאפייני משתמשים ב-Apple הגדרה של מאפייני משתמשים ב-Android כשמשתמשים באופרטור התאמה מדויקת, מכיל, לא מכיל או מכיל ביטוי רגולרי, אפשר לבחור כמה ערכים. כשמשתמשים באופרטור מכיל ביטוי רגולרי, אפשר ליצור ביטויים רגולריים בפורמט RE2. הביטוי הרגולרי יכול להתאים לכל המחרוזת של גרסת היעד או לחלק ממנה. אפשר גם להשתמש בעוגנים ^ ו-$ כדי להתאים את ההתחלה, הסוף או כל מחרוזת היעד. הערה: מאפייני משתמשים שנאספים באופן אוטומטי לא זמינים כשיוצרים תנאים ב-Remote Config.
משתמש באחוז אקראי	סליידר (במסוף Firebase). ב-API בארכיטקטורת REST משתמשים באופרטורים <=,‏ > ו-between.	0-100	אפשר להשתמש בשדה הזה כדי להחיל שינוי על מדגם אקראי של מופעי אפליקציה (עם גודלי מדגם קטנים עד 0 .0001%), באמצעות ווידג'ט של פס הזזה כדי לפלח משתמשים (מופעי אפליקציה) שסודרו באופן אקראי לקבוצות. כל מופע של אפליקציה ממופה באופן קבוע למספר שלם או שבר אקראי, בהתאם לseed שמוגדר בפרויקט. ערכי בסיס יכולים להכיל בין תו אחד ל-32 תווים, כולל ערכים אלפאנומריים, נקודות, מקפים ו/או קווים תחתונים. הכלל ישתמש במפתח ברירת המחדל (שמוצג בתור Edit seed במסוף Firebase), אלא אם תשנו את ערך הבסיס. כדי להחזיר כלל לשימוש במפתח ברירת המחדל, צריך לנקות את השדה Seed. כדי לטרגט באופן עקבי את אותם מופעי אפליקציה בטווחי אחוזים נתונים, צריך להשתמש באותו ערך בסיס בכל התנאים. אפשר גם לבחור קבוצה חדשה של מופעי אפליקציה שמוקצים באופן אקראי לטווח אחוזים נתון, על ידי ציון ערך seed חדש. לדוגמה, כדי ליצור שני תנאים קשורים שכל אחד מהם חל על 5% ממשתמשי האפליקציה ללא חפיפה, אפשר להגדיר תנאי אחד שיתאים לאחוזים שבין 0% ל-5%, ולהגדיר תנאי אחר שיתאים לטווח שבין 5% ל-10%. כדי לאפשר למשתמשים מסוימים להופיע באופן אקראי בשתי הקבוצות, צריך להשתמש בערכי בסיס שונים לכללים בכל תנאי.
פלח מיובא	נמצא ב-	בוחרים פלח מיובא אחד או יותר.	כדי להשתמש בכלל הזה, צריך להגדיר פלחים מיובאים בהתאמה אישית.
תאריך/שעה	לפני, אחרי	תאריך ושעה ספציפיים, לפי אזור הזמן של המכשיר או לפי אזור זמן ספציפי, כמו "(GMT+11) שעון סידני".	השוואה בין השעה הנוכחית לבין שעת האחזור של המכשיר.
פתיחה ראשונה	לפני, אחרי	טירגוט משתמשים על סמך הפעם הראשונה שהם פותחים את האפליקציה: בוחרים באפשרות משתמשים חדשים כדי לטרגט משתמשים שפתחו את האפליקציה בפעם הראשונה אחרי תאריך ושעה עתידיים מסוימים. בוחרים באפשרות טווח תאריכים כדי לטרגט משתמשים שפתחו את האפליקציה בפעם הראשונה בטווח התאריכים שלפני או אחרי התאריך והשעה שציינתם. כדי לטרגט משתמשים בטווח תאריכים ספציפי, משלבים את התנאים לפני ואחרי.	אפשר לטרגט משתמשים לפי פתיחה ראשונה אחרי שבוחרים אפליקציה ל-Android, ל-iOS או לאינטרנט. נדרשות ערכות ה-SDK הבאות: Firebase SDK ל-Google Analytics ‫Apple platforms SDK בגרסה 9.0.0 ומעלה או Android SDK בגרסה 21.1.1 ומעלה (Firebase BoM בגרסה 30.3.0 ומעלה), ו-JavaScript SDK בגרסה 12.8.0 ומעלה. בנוסף, צריך להפעיל את Analytics באפליקציית הלקוח במהלך אירוע הפתיחה הראשונה.
מזהה ההתקנה	נמצא ב-	מציינים מזהה התקנה אחד או יותר (עד 50) לטירגוט.	הכלל הזה מקבל את הערך true בהתקנה נתונה אם המזהה של ההתקנה הזו נמצא ברשימת הערכים שמופרדים בפסיקים. במאמר אחזור מזהי לקוחות מוסבר איך מקבלים מזהי התקנה.
המשתמש קיים	(ללא אופרטור)	מטרגט את כל המשתמשים בכל האפליקציות בפרויקט הנוכחי.	אפשר להשתמש בכלל התנאי הזה כדי להתאים לכל המשתמשים בפרויקט, בלי קשר לאפליקציה או לפלטפורמה. כשמשתמשים בהתאמה אישית של Remote Config, אפשר להשתמש באופרטור הזה כדי לוודא שכל המשתמשים בפרויקט מקבלים ערכים בהתאמה אישית.
אות בהתאמה אישית	לערכי מחרוזת: מכיל, לא מכיל, התאמה מדויקת, מכיל ביטוי רגולרי לערכים מספריים: =, ≠, >, ≥, <, ≤ לערכי גרסה: =, ≠, >, ≥, <, ≤	השוואות של מחרוזות בכלל הזה הן תלויות אותיות רישיות. כשמשתמשים באופרטורים "תואם בדיוק", "מכיל", "לא מכיל" או "מכיל ביטוי רגולרי", אפשר לבחור כמה ערכים. כשמשתמשים באופרטור "מכיל ביטוי רגולרי", אפשר ליצור ביטויים רגולריים בפורמט RE2. הביטוי הרגולרי יכול להתאים לכל מחרוזת גרסת היעד או לחלק ממנה. אפשר גם להשתמש בתווי העיגון ^ ו-$ כדי להתאים את ההתחלה, הסוף או כל מחרוזת היעד. אלה סוגי הנתונים שנתמכים בסביבות לקוח: ‫iOS: ‏int, ‏double ‫Android: ‏int, ‏ long, ‏ double אינטרנט: מספר מספר שמייצג את מספרי הגרסאות שצריך להתאים (לדוגמה, 2.1.0).	מידע נוסף על תנאים של אותות בהתאמה אישית וביטויים מותנים זמין במאמרים תנאים של אותות בהתאמה אישית ורכיבים שמשמשים ליצירת תנאים.

פרמטרים ותנאים של חיפוש

אתם יכולים לחפש את מפתחות הפרמטרים, ערכי הפרמטרים והתנאים של הפרויקט במסוף Firebase באמצעות תיבת החיפוש שבחלק העליון של הדף DevOps & Engagement (DevOps ומעורבות) > Remote Config (הגדרת תצורה מרחוק) > Parameters (פרמטרים).

מגבלות על פרמטרים ותנאים

בפרויקט Firebase, אפשר להגדיר עד 3,000 פרמטרים ועד 2,000 תנאים. מפתחות הפרמטרים יכולים להיות באורך של עד 256 תווים, חייבים להתחיל בקו תחתון או באות באנגלית (A-Z,‏ a-z) ויכולים לכלול גם מספרים. האורך הכולל של מחרוזות ערכי הפרמטרים בפרויקט לא יכול להיות יותר ממיליון תווים. בנוסף, כללי תנאים שמבוססים על מאפייני משתמשים יכולים לכלול עד 100 ערכים של מאפייני משתמשים. לרשימה המלאה של המגבלות, ראו מכסות ומגבלות.

הצגת השינויים בפרמטרים ובתנאים

אפשר לראות את השינויים האחרונים בתבניות של Remote Config במסוף Firebase. לכל פרמטר ותנאי בנפרד, אתם יכולים:

• הצגת השם של המשתמש ששינה לאחרונה את הפרמטר או התנאי.

• אם השינוי בוצע באותו יום, מוצג מספר הדקות או השעות שחלפו מאז שהשינוי פורסם בתבנית הפעילה של Remote Config.

• אם השינוי בוצע לפני יום אחד או יותר, צריך לבדוק את התאריך שבו השינוי פורסם בתבנית הפעילה של Remote Config.

היסטוריית השינויים של הפרמטרים

במסוף Firebase, נכנסים לדף DevOps & Engagement ‏> הגדרת תצורה מרחוק ‏> Parameters. בעמודה Last published מוצג המשתמש האחרון ששינה כל פרמטר ותאריך הפרסום האחרון של השינוי:

• כדי לראות את המטא-נתונים של השינויים בפרמטרים מקובצים, מרחיבים את קבוצת הפרמטרים.

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

היסטוריית השינויים של התנאים

במסוף Firebase, נכנסים לדף DevOps & Engagement ‏> הגדרת תצורה מרחוק ‏> תנאים. ליד השינוי האחרון מתחת לכל תנאי, אפשר לראות את המשתמש האחרון ששינה את התנאי ואת התאריך שבו הוא שינה אותו.

השלבים הבאים

כדי להגדיר את הפרויקט והאפליקציה ב-Firebase לשימוש ב-Remote Config, עיינו במאמר תחילת העבודה עם Firebase Remote Config.