החל מ-1 בספטמבר 2026, Remote Config יציע מבנה תמחור גמיש שמתאים לפרויקטים בכל הגדלים, עם תוכנית ללא עלות ורמת שימוש בתשלום לפי שימוש שניתנת להתאמה לפי השימוש היומי.
רק בקשות אחזור שהופעלו ישירות על ידי שירות Remote Config (באמצעות ערכות SDK ללקוח או ממשקי REST API) נכללות בשימוש שמחויב. פעולות אחזור, שיחות רשת או מדדים שנוצרים באופן פנימי על ידי שירותים אחרים של Firebase לא נכללים במכסות או בחיוב של Remote Config.
בטבלה הבאה מוצג השימוש בכל פרויקט בתוכניות Spark ו-Blaze:
| לפרטים
|
ללא עלות (תוכנית Spark)
|
תשלום לפי שימוש (תוכנית Blaze)
|
| בקשות אחזור
|
עד 100,000 ביום
|
ללא עלות עד 100,000 ביום.
לאחר מכן:
- 0.000006$ לכל בקשה (0.06$ / 10,000 בקשות) לשימוש בין 100,001 ל-10,000,000 בקשות ביום.
- 0.000001$ לכל בקשה (0.01$ / 10,000 בקשות) לשימוש מעל 10,000,000 ביום.
|
| כל התכונות
|
כולל התאמה אישית, השקות, שילוב של בדיקות A/B
|
כולל התאמה אישית, השקות, שילוב של בדיקות A/B
|
| מכסות ומגבלות
|
מכסות ומגבלות
|
מכסות ומגבלות
|
תקופות מעבר לפרויקטים קיימים
תקופת המעבר הזו רלוונטית לפרויקטים שבהם Remote Config הופעלה לפני 1 בספטמבר 2026. כדי להבטיח מעבר חלק למודל התמחור 'משלמים לפי השימוש', לפרויקטים קיימים ניתנים תקופות חסד מורחבות לפני תחילת אכיפת החיוב:
| תוכנית החיוב הנוכחית
|
תקופת מעבר
|
תחילת החיוב הרגיל
|
פעולה נדרשת / הערות
|
| מינוי Spark (ללא עלות)
|
3 חודשים
|
1 בדצמבר 2026
|
פעולה מומלצת: כדאי להגדיר חיוב ב-Cloud ולשדרג לתוכנית Blaze.
בונוס: אם תשדרגו לפני 15 בנובמבר 2026, תקופת החסד תוארך ל-5 חודשים (החיוב יתחיל ב-1 בפברואר 2027).
|
| תוכנית Blaze (תשלום לפי שימוש)
|
5 חודשים
|
1 בפברואר 2027
|
לא נדרשת שום פעולה. הפרויקטים יעברו אוטומטית למחיר הסטנדרטי ב-1 בפברואר 2027.
|
תקופות חסד רגילות
תקופת החסד הזו רלוונטית לפרויקטים שבהם Remote Configהופעלה
ב-1 בספטמבר 2026 או אחרי התאריך הזה. הדבר כולל פרויקטים קיימים שהופעלו (נוצרו לפני 1 בספטמבר 2026) ושתקופת המעבר שלהם הסתיימה.Remote Config אם בפרויקט מסוים חורגים ממגבלת השימוש של 100,000 בקשות אחזור ביום, צריך לפעול לפי ההנחיות הבאות:
| תוכנית / תנאי
|
תקופת חסד
|
מה קורה אחרי תקופת החסד
|
פעולה נדרשת / הערות
|
| מינוי Spark (ללא עלות)
|
30 יום (רלוונטי כשהפרויקט חורג מהמגבלה היומית בפעם הראשונה)
|
ההגבלה מתחילה ביום ה-31
|
השירות בפרויקטים לא מופסק למשך 30 ימים אחרי הפעם הראשונה שבה חרגתם מהמגבלה היומית. כדי למנוע הגבלת קצב העברת הנתונים ביום ה-31 ואילך, צריך לשדרג לתוכנית Blaze.
|
| תוכנית Blaze (תשלום לפי שימוש)
|
N/A (ללא הגבלת רוחב פס)
|
חיוב לכל בקשת אחזור
|
השימוש מעל 100,000 אחזורים כרוך בחיוב. לא מופעל ויסות נתונים (throttle).
|
שיטות מומלצות לאופטימיזציה של השימוש
כדי לייעל את השימוש, אפשר לבצע כל אחת מהפעולות הבאות:
- מרווחי אחזור נתונים של לקוח: מומלץ להימנע מהגדרת מרווחי אחזור מינימליים נמוכים מאוד (לדוגמה,
setMinimumFetchIntervalInSeconds) בגרסאות ייצור. מרווח הזמן המומלץ שמוגדר כברירת מחדל הוא 12 שעות.
- שמירת נתונים במטמון של פרמטרים לא קריטיים: אם יש לכם ערכי הגדרה יציבים שלא משתנים לעיתים קרובות, כדאי להגדיל את הערך של
setMinimumFetchIntervalInSeconds מ-12 שעות (ברירת המחדל) ל-24 או ל-48 שעות.
- לולאות אחזור בהפעלת האפליקציה: מוודאים שהאפליקציה לא מפעילה אחזור מרחוק בכל מעבר בין מסכים, בכל חידוש של פעילות או בכל עיבוד של רכיב. חשוב להשתמש באסטרטגיות טעינה כמו Fetch and activate on load או Activate behind loading screen בצורה אחראית.
- ביקורת על אחזור נתונים ברקע ואחזור נתונים לא פעיל: כדאי לבדוק משימות של עובדים ברקע, שירותים או מודולים של אפליקציות מדור קודם כדי להסיר קריאות מיותרות לאחזור נתונים ("אחזורי רפאים") שמופעלות כשהאפליקציה ברקע או לא פעילה.
- מעקב: אפשר להשתמש במסוף Google Cloud ובמסוף Firebase כדי להגדיר התראות אוטומטיות על חיוב כשנפחי האחזור היומיים מתקרבים ל-100,000 בקשות.
שאלות נפוצות ופתרון בעיות
מהו מודל התמחור החדש שייכנס לתוקף ב-Remote Config1 בספטמבר 2026?
Remote Config עובר למבנה תמחור לפי שימוש עם רמה ללא עלות:
- תוכנית Spark (ללא עלות): עד 100,000 בקשות אחזור ביום ללא עלות.
- תוכנית Blaze (תשלום לפי שימוש): ללא עלות על 100,000 בקשות אחזור יומיות ראשונות, ואז:
- 0.06$ לכל 10,000 בקשות (0.000006$ לכל בקשה) בין 100,001 ל-10,000,000 בקשות ביום.
- 0.01$ לכל 10,000 בקשות (0.000001$ לכל בקשה) על שימוש מעל 10,000,000 בקשות ביום.
- תכונות: כל התכונות המתקדמות (התאמה אישית, השקות הדרגתיות ושילוב של בדיקות A/B) נכללות גם בתוכניות Spark וגם בתוכניות Blaze ללא עלות נוספת.
האם צריך חשבון לחיוב כדי להתחיל להשתמש ב-Remote Config?
לא. לא צריך חשבון לחיוב כדי להתחיל להשתמש ב-Remote Config. אתם יכולים להשתמש בתוכנית Spark כדי להתחיל ללא עלות. חשבון לחיוב נדרש רק כשמשדרגים את הפרויקט לתוכנית Blaze כדי לתמוך ביותר מ-100,000 בקשות אחזור יומיות.
האם צריך לעדכן את הקוד או לשדרג את ה-SDK של הגדרת התצורה מרחוק?
לא. לא צריך לשנות את הקוד או לעדכן את Remote Config
client SDK כשעוברים בין תוכניות Spark ו-Blaze. המעבר בין הרמות ומדידת הבקשות מתבצעים באופן אוטומטי על ידי Remote Config backend.
מה בדיוק נחשב לבקשת אחזור שניתן לחייב עליה?
בקשת אחזור מתרחשת בכל פעם שאפליקציית הלקוח או שרת הקצה העורפי שלכם
קוראים לשרת Remote Config כדי לבדוק אם יש ערכי פרמטרים מעודכנים
(לדוגמה, הפעלה של fetch() או של
fetchAndActivate() בערכות ה-SDK של הלקוח, או אחזור של
תבניות באמצעות REST/Admin SDKs). רק בקשות אחזור שהופעלו ישירות על ידי שירות Remote Config (באמצעות ערכות SDK ללקוח או ממשקי REST API) נכללות בשימוש שמחויב. פעולות אחזור, שיחות רשת או מדדים שנוצרו באופן פנימי על ידי שירותים אחרים של Firebase לא נכללים במכסות או בחיוב שלכם ב-Remote Config.
- בזמן אמת Remote Config: פתיחת חיבור בזמן אמת לא יוצרת בקשות אחזור רציפות של נתונים בנפרד. עם זאת, כששרת שולח הודעה על ביטול תוקף, הקריאה ללקוח שמתקבלת להורדת ההגדרה המעודכנת נחשבת כבקשת אחזור.
- ערכים שנשמרו במטמון: שימוש בערכים שנשמרו במטמון במכשיר (קריאה מדיסק או מזיכרון באמצעות
activate() או getString()) לא יוצר קריאה לרשת ולא נחשב כבקשת אחזור.
מה קורה אם הפרויקט שלי נמצא בתוכנית Spark וחורג מ-100,000 בקשות אחזור יומיות? איך משדרגים?
- תקופת חסד של 30 יום: כשפרויקט Spark חורג לראשונה ממגבלת 100,000 בקשות אחזור יומיות, Firebase מעניק תקופת חסד של 30 יום. במהלך התקופה הזו, Remote Config הבקשות שלכם ימשיכו להיות מטופלות ללא הפרעה.
- המשך הספירה לאחור: תקופת החסד של 30 יום מתחילה בפעם הראשונה שבה הפרויקט חורג ממגבלת 100,000 בקשות אחזור יומיות. הספירה לאחור של 30 הימים לא מושהית או מתאפסת, גם אם השימוש היומי שלכם יורד באופן זמני מתחת למגבלה של 100,000 בקשות במהלך פרק הזמן הזה.
- התראות על מכסה: כשהנפח היומי של האחזור מתקרב למכסה של 100,000 או מגיע אליה, האדמינים של הפרויקט מקבלים התראות אוטומטיות באימייל והתראות בבאנר במסוף.
- סיכון לוויסות: אם לא תשדרגו לתוכנית Blaze עד סוף תקופת החסד של 30 יום, יתחיל ויסות של שירות Remote Config לבקשות שחורגות מהמכסה היומית של 100,000 בקשות, מה שעלול למנוע מהלקוחות לקבל עדכונים של ההגדרות.
- איך משדרגים: אפשר לשדרג לתוכנית Blaze במסוף Firebase כדי להבטיח שהשירות לא יופרע. כשמשדרגים לתוכנית Blaze, הפרויקט מקושר לחשבון לחיוב ב-Google Cloud.
המשתמשים לא מקבלים ערכים חדשים של הפרמטר Remote Config. יכול להיות שזה קשור לתמחור או למכסות?
כן. אם הפרויקט שלכם מנוי לתוכנית Spark, חרגתם מהמגבלה של 100,000 בקשות ביום ותקופת החסד של 30 יום הסתיימה, השרת יבצע ויסות לבקשות נכנסות שחורגות מהסף היומי. כדאי לבדוק את מדדי השימוש במסוף Firebase ולשדרג לתוכנית Blaze אם מספר המשתמשים הפעילים ביום מחייב יותר מ-100,000 אחזורים ביום.
איך אפשר לראות את השימוש הנוכחי כדי להעריך את סכום החשבון?
אם אתם משתמשים בתוכנית Blaze, אתם יכולים לראות את דוחות ניהול העלויות והשימוש בGoogle Cloud Console. מידע נוסף מופיע במאמר הצגת דוחות החיוב ב-Cloud ומגמות של עלויות.
כשמסננים לפי מק"ט, בוחרים במק"ט הבא:
- מזהה המק"ט:
37B1-4623-6F54
- שם המק"ט: בקשות אחזור
בדף Quotas & System Limits במסוף Google Cloud אפשר לעקוב אחרי השימוש הנוכחי ומגבלות המערכת הפעילות. פרטים נוספים מופיעים במאמר בנושא איך רואים ומנהלים את המכסות. כשמסננים דוחות, חשוב לבחור את ה-API הספציפי של Firebase שרוצים לבדוק את המכסות שלו (לדוגמה, firebaseremoteconfig.googleapis.com).
