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 di pagamento a consumo scalabile 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 tabella seguente 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 dei progetti esistenti

Questo periodo di tolleranza per la transizione è pertinente per i progetti in cui Remote Config è stato 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 richiesta / Note
Piano Spark (senza costi) 3 Months 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 1° febbraio 2027.

Periodi di tolleranza standard

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

Piano / Condizione Periodo di tolleranza Risultato dopo il periodo di tolleranza Azione richiesta / Note
Piano Spark (senza costi) 30 giorni (applicabile quando il progetto supera il limite giornaliero per la prima volta) 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 dal giorno 31 in poi, 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 è a pagamento. 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 i parametri non critici: per i valori di configurazione stabili che cambiano raramente, valuta la possibilità di aumentare setMinimumFetchIntervalInSeconds dalle 12 ore predefinite a 24 o 48 ore.
  • Loop 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 dei componenti. Utilizza in modo responsabile strategie di caricamento come Recupera e attiva al caricamento o Attiva dietro la schermata di caricamento.
  • Controlla i recuperi in background e inattivi: esamina i job dei worker in background, i servizi o i moduli delle app legacy per rimuovere le chiamate di recupero ridondanti ("recuperi fantasma") che vengono attivate quando l'app è in background o inattiva.
  • Monitoraggio: utilizza le dashboard dei prezzi e di utilizzo della console Google Cloud e della console Firebase per configurare avvisi di fatturazione automatici quando i volumi di recupero giornalieri si avvicinano alle 100.000 richieste.

Domande frequenti e risoluzione dei problemi