תמחור של הגדרת תצורה מרחוק
קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
החל מ-1 בספטמבר 2026, Remote Config יציע מבנה תמחור גמיש שמתאים לפרויקטים בכל הגדלים, עם תוכנית ללא עלות ורמת שימוש בתשלום לפי שימוש, על סמך השימוש היומי.
רק בקשות אחזור שהופעלו ישירות על ידי שירות Remote Config (באמצעות ערכות SDK ללקוח או ממשקי API ל-REST) נכללות בחיוב על השימוש. פעולות אחזור, שיחות רשת או מדדים שנוצרו באופן פנימי על ידי שירותים אחרים של 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 Testing
כולל התאמה אישית, השקות הדרגתיות ושילוב של A/B Testing
תקופת המעבר הזו רלוונטית לפרויקטים שבהם 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 או אחרי התאריך הזה. ההגדרה הזו כוללת פרויקטים קיימים Remote Configשהופעלו (נוצרו לפני 1 בספטמבר 2026) ושתקופת המעבר שלהם הסתיימה. אם בפרויקט חורגים מהשימוש של 100,000 בקשות אחזור ביום, צריך לפעול לפי ההנחיות הבאות:
תוכנית / תנאי
תקופת חסד
מה קורה אחרי תקופת החסד
הפעולה הנדרשת / הערות
מינוי Spark(ללא עלות)
30 ימים(רלוונטי כשהפרויקט חורג מהמגבלה היומית בפעם הראשונה)
ההגבלה מתחילה ביום ה-31
השירות בפרויקטים לא יופסק למשך 30 ימים אחרי הפעם הראשונה שבה חרגתם מהמגבלה היומית. כדי למנוע הגבלת מהירות ביום ה-31 ואילך, צריך לשדרג לתוכנית Blaze.
מינוי Blaze(תשלום לפי שימוש)
לא רלוונטי (ללא הגבלת רוחב פס)
חיוב על כל בקשת אחזור
אם מספר האחזורים גבוה מ-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 Testing
) נשארות כלולות בתוכניות 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 של הלקוח, או אחזור של תבניות באמצעות ערכות ה-SDK של REST/Admin). רק בקשות אחזור שהופעלו ישירות על ידי שירות Remote Config (באמצעות ערכות SDK ללקוח או ממשקי API ל-REST) נכללות בשימוש שמחויב. פעולות אחזור, קריאות לרשת או מדדים שנוצרו באופן פנימי על ידי שירותים אחרים של 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 בקשות, מה שעלול למנוע מהלקוחות לקבל עדכונים של ההגדרות.
המשתמשים לא מקבלים ערכים חדשים של הפרמטר Remote Config. יכול להיות שזה קשור לתמחור או למכסות?
כן. אם הפרויקט שלכם בתוכנית Spark חרג מהמגבלה של 100,000 בקשות ביום, ותקופת החסד של 30 יום הסתיימה, השרת יבצע ויסות לבקשות נכנסות שחורגות מהסף היומי. כדאי לבדוק את מדדי השימוש במסוף Firebase ולשדרג לתוכנית Blaze אם מספר המשתמשים הפעילים ביום מחייב יותר מ-100,000 אחזורים ביום.
איך אפשר לראות את השימוש הנוכחי כדי להעריך את סכום החיוב?
במסוף Firebase:
תוכנית Spark: אפשר לעקוב אחרי השימוש היומי באחזור בלוח הבקרה 'שימוש וחיוב'.
בכרטיס 'התקדמות לניצול המכסה' שבקטע הגדרת תצורה מרחוק מוצגת ספירת האחזור היומית ביחס למגבלה היומית של 100,000 אחזורים ללא עלות.
תוכנית Blaze: בלוח הבקרה Usage and billing מוצג תרשים עמודות של שימוש מדורג,שבו אפשר לראות את מספר האחזורים היומי בחלוקה לרמות תמחור (רמה ללא עלות עד 100, 000,רמה של 100,001 עד 10,000, 000 ורמה של מעל 10,000,000).
במסוף Google Cloud:
דוחות החיוב ב-Cloud (תוכנית Blaze): אתם יכולים לראות את ניהול העלויות ודוחות שימוש מפורטים בחיוב ב-Cloud. פרטים נוספים מופיעים במאמר הצגת דוחות החיוב ב-Cloud ומגמות של עלויות.
כשמסננים לפי מק"ט, בוחרים את המק"ט לפי התאריך שבו הפרויקט נוצר:
פרויקטים שנוצרו ב-1 בספטמבר 2026 או אחרי התאריך הזה:
מזהה המק"ט: 37B1-4623-6F54
שם המק"ט: בקשות אחזור
פרויקטים שנוצרו לפני 1 בספטמבר 2026:
מזהה המק"ט: 598C-0184-404A
שם המק"ט: בקשות אחזור
Quotas & System Limits (Spark and Blaze plans): בדף Quotas & System Limits אפשר לעקוב אחרי השימוש הנוכחי ומגבלות המערכת הפעילות. פרטים נוספים מופיעים במאמר בנושא איך רואים ומנהלים את המכסות. כשמסננים דוחות,
חשוב לבחור את Firebase API הספציפי שרוצים לבדוק את המכסות שלו
(לדוגמה, firebaseremoteconfig.googleapis.com).
[[["התוכן קל להבנה","easyToUnderstand","thumb-up"],["התוכן עזר לי לפתור בעיה","solvedMyProblem","thumb-up"],["סיבה אחרת","otherUp","thumb-up"]],[["חסרים לי מידע או פרטים","missingTheInformationINeed","thumb-down"],["התוכן מורכב מדי או עם יותר מדי שלבים","tooComplicatedTooManySteps","thumb-down"],["התוכן לא עדכני","outOfDate","thumb-down"],["בעיה בתרגום","translationIssue","thumb-down"],["בעיה בדוגמאות/בקוד","samplesCodeIssue","thumb-down"],["סיבה אחרת","otherDown","thumb-down"]],["עדכון אחרון: 2026-10-11 (שעון UTC)."],[],[]]
