Prezzi di Remote Config

A partire dal 1° settembre 2026, Remote Config offrirà una struttura di prezzi flessibile progettata per adattarsi a progetti di tutte le dimensioni, con un piano senza costi e un livello scalabile con pagamento a consumo in base all'utilizzo giornaliero.

Solo le richieste di recupero richiamate direttamente dal servizio Remote Config (tramite SDK client o API REST) contribuiscono all'utilizzo fatturato. Le operazioni di recupero, le chiamate di rete o le metriche generate internamente da altri servizi Firebase non vengono conteggiate ai fini delle quote o della fatturazione di Remote Config.

La seguente tabella mostra l'utilizzo per progetto per i piani Spark e Blaze:

Dettagli Senza costi (piano Spark) Pagamento a consumo (piano Blaze)
Richieste di recupero Fino a 100.000 al giorno Senza costi fino a 100.000 al giorno.

Quindi:

  • 0,000006 $ per richiesta (0,06 $ per 10.000 richieste) per un utilizzo compreso tra 100.001 e 10.000.000 al giorno.
  • 0,000001 $ per richiesta (0,01 $ per 10.000 richieste) per un utilizzo superiore a 10.000.000 al giorno.
Tutte le funzionalità Include personalizzazione, implementazioni e integrazione di A/B Testing Include personalizzazione, implementazioni e integrazione di A/B Testing
Quote e limiti Consulta Quote e limiti. Consulta Quote e limiti.

Periodi di tolleranza per la transizione per i progetti esistenti

Questo periodo di transizione è pertinente per i progetti che hanno Remote Config abilitato prima del 1° settembre 2026. Per garantire una transizione senza problemi ai prezzi con pagamento a consumo, ai progetti esistenti vengono concessi i seguenti periodi di tolleranza estesi prima dell'inizio dell'applicazione della fatturazione:

Piano di fatturazione attuale Periodo di tolleranza per la transizione Inizio della fatturazione standard Azione / note richieste
Piano Spark (senza costi) 3 mesi 1° dicembre 2026 Azione consigliata: configura la fatturazione Cloud ed esegui l'upgrade a Blaze.

Bonus: se esegui l'upgrade prima del 15 novembre 2026, il periodo di tolleranza viene esteso a 5 mesi (la fatturazione inizia il 1° febbraio 2027).

Piano Blaze (pagamento a consumo) 5 mesi 1° febbraio 2027 Nessuna azione richiesta. I progetti passeranno automaticamente ai prezzi standard il giorno 1° febbraio 2027.

Periodi di tolleranza standard

Questo periodo di tolleranza è pertinente per i progetti in cui è stato attivato Remote Config a partire dal 1° settembre 2026. Sono inclusi i progetti Remote Config abilitati esistenti (creati prima del 1° settembre 2026) in cui è scaduto il periodo di tolleranza per la transizione. Se un progetto supera l'utilizzo di 100.000 richieste di recupero al giorno, è necessario rispettare le seguenti azioni:

Piano / Condizione Periodo di tolleranza Esito dopo il periodo di tolleranza Azione / note richieste
Piano Spark (senza costi) 30 giorni (valido quando il progetto supera per la prima volta il limite giornaliero) La limitazione inizia il 31° giorno I progetti usufruiscono di un servizio ininterrotto per 30 giorni dopo il primo superamento del limite giornaliero. Per evitare la limitazione il giorno 31 o oltre, devi eseguire l'upgrade al piano Blaze.
Piano Blaze (pagamento a consumo) N/A (nessuna limitazione) Fatturazione per richiesta di recupero L'utilizzo superiore a 100.000 recuperi viene addebitato. Non viene applicata alcuna limitazione.

Best practice per ottimizzare l'utilizzo

Per ottimizzare l'utilizzo, esegui una delle seguenti operazioni:

  • Intervalli di recupero del client: evita di impostare intervalli di recupero minimi molto bassi (ad esempio, setMinimumFetchIntervalInSeconds) nelle build di produzione. L'intervallo predefinito consigliato è 12 ore.
  • Memorizzazione nella cache per parametri non critici: per i valori di configurazione stabili che cambiano raramente, valuta la possibilità di aumentare setMinimumFetchIntervalInSeconds da 12 ore predefinite a 24 o 48 ore.
  • Cicli di recupero all'avvio dell'app: assicurati che l'app non attivi un recupero remoto a ogni transizione dello schermo, ripresa dell'attività o rendering del componente. Utilizza strategie di caricamento come Recupera e attiva al caricamento o Attiva dietro la schermata di caricamento in modo responsabile.
  • Controlla i recuperi in background e inattivi: esamina i job, i servizi o i moduli delle app legacy dei worker in background per rimuovere le chiamate di recupero ridondanti ("recuperi fantasma") che vengono attivate quando l'app è in background o inattiva.
  • Monitoraggio: utilizza i dashboard dei prezzi e dell'utilizzo della console Google Cloud e della console Firebase per configurare avvisi di fatturazione automatici quando i volumi di recupero giornalieri si avvicinano a 100.000 richieste.

Domande frequenti e risoluzione dei problemi