Firebase Remote Config: cos'è, parametri e come gestire da remoto

Cos'è Firebase Remote Config e come funziona

Firebase Remote Config è un servizio che memorizza coppie chiave-valore sul lato server di Firebase e le consegna ai dispositivi client su richiesta o secondo una pianificazione. Ogni parametro ha un nome (stringa), un valore (stringa, numero, booleano o JSON) e può essere associato a condizioni — regole che determinano quale valore riceve un determinato utente. Le condizioni possono verificare la versione dell'app, la lingua del dispositivo, la regione, una percentuale casuale e molti altri attributi.

L'architettura di Remote Config è basata su un modello push-pull con priorità pull. Il client richiede periodicamente i valori aggiornati dal server (per impostazione predefinita ogni 12 ore). Tuttavia, lo sviluppatore può avviare una sincronizzazione immediata nel codice o tramite la console Firebase (pulsante “Publish changes”). Dopo aver pubblicato le modifiche, il server invia una notifica push tramite Firebase Cloud Messaging e l'app, ricevendola, può richiedere nuovamente i parametri.

Il piano gratuito di Firebase Remote Config non ha limiti sul numero di parametri o richieste, il che lo distingue dagli altri servizi Firebase. L'unica limitazione è che la dimensione della risposta non deve superare 800 KB (totale per tutti i parametri). Ciò è più che sufficiente per uno scenario tipico: la maggior parte dei progetti utilizza 10–50 parametri e il loro volume totale raramente supera i 100 KB.

Come Remote Config determina quale valore assegnare a un utente

Il meccanismo di selezione del valore si basa sulla priorità delle condizioni. Ogni condizione rappresenta una regola (ad esempio, “versione iOS > 15.0”). Remote Config verifica le condizioni in ordine di priorità e restituisce il valore della prima condizione corrispondente. Se nessuna condizione corrisponde, viene utilizzato il valore predefinito. Questo meccanismo consente di creare una gerarchia di regole: dalla più specifica alla più generale.

Importante: l'ordine delle condizioni nella console Firebase è importante. Se due condizioni possono corrispondere contemporaneamente a un utente, vince quella più in alto nell'elenco. Si consiglia di posizionare le condizioni più specifiche (ad esempio, per una versione specifica dell'app) al di sopra di quelle generali (ad esempio, “Tutti gli utenti iOS”). Un ordine errato può impedire l'applicazione di una modifica mirata.

Memorizzazione nella cache e durata dei parametri

Per impostazione predefinita, Remote Config memorizza nella cache i valori ricevuti dal server per 12 ore. Ciò significa che dopo aver pubblicato le modifiche nella console, l'app le vedrà non prima di 12 ore (o dopo la successiva chiamata fetch esplicita). Il tempo minimo di cache può essere impostato tramite FirebaseRemoteConfigSettings(minimumFetchIntervalInSeconds: 3600) — per la produzione si consiglia almeno 1 ora per evitare richieste eccessive al server e consumo di dati dell'utente.

Per testare le modifiche durante lo sviluppo, utilizzare un intervallo minimo di 0 secondi: FirebaseRemoteConfigSettings(minimumFetchIntervalInSeconds: 0). In questa modalità, ogni chiamata fetch caricherà i valori aggiornati dal server. È importante non dimenticare di tornare all'intervallo di produzione prima del rilascio, altrimenti ogni avvio dell'app contatterà il server, aumentando i costi e il consumo della batteria.

Parametri, condizioni e gruppi di utenti

Un parametro Remote Config è una variabile nominata che può assumere uno dei diversi valori in base alle condizioni. Tipi di valore: stringa, numero (double), booleano, oggetto JSON (stringa serializzata). I parametri JSON sono comodi per trasmettere dati strutturati senza creare molti parametri separati: ad esempio, un oggetto con le impostazioni del tema dell'app (primaryColor, backgroundColor, fontSize).

Le condizioni sono regole logiche che verificano gli attributi dell'utente o del dispositivo: versione del sistema operativo (iOS, Android), versione dell'app, paese, lingua, pubblico utente (proprietà definita nel codice), percentuale casuale (per test A/B). Le condizioni possono essere combinate tramite AND logico: ad esempio, “versione app >= 5.0” AND “paese = Russia”. Ogni parametro può avere un numero illimitato di condizioni, ma in pratica se ne usano 2–5.

Per la personalizzazione, utilizzare le proprietà utente (user properties) — attributi impostati nel codice dell'applicazione tramite Firebase Analytics. Ad esempio, analytics.setUserProperty(“subscription_tier”, “premium”). Remote Config può verificare questa proprietà e fornire valori specifici per gli utenti premium. La personalizzazione tramite Remote Config non richiede la creazione di condizioni lato client — tutta la logica è concentrata nella console cloud.

Gruppi di utenti e segmentazione

Remote Config supporta due modelli di segmentazione: basato sugli attributi (condizioni) e basato sulle proprietà di Firebase Analytics (proprietà utente). Il primo modello è statico: una condizione verifica un attributo fisso che non cambia all'interno di una sessione o versione dell'app. Il secondo modello è dinamico: una proprietà può essere impostata in qualsiasi momento durante l'esecuzione dell'app, consentendo una segmentazione flessibile degli utenti in fase di esecuzione.

Importante: per utilizzare le proprietà utente in Remote Config, è necessario integrare Firebase Analytics. Questo requisito deriva dal fatto che Remote Config riceve i dati utente dall'SDK Analytics. Senza Analytics, Remote Config funziona solo con gli attributi del dispositivo (versione OS, versione dell'app, paese dall'IP). La personalizzazione basata sul comportamento dell'utente (ad esempio, “ha effettuato 5 acquisti”) è disponibile solo tramite Analytics.

Versionamento del template

Il template Remote Config è l'insieme completo di tutti i parametri, le condizioni e i loro valori. Firebase memorizza la cronologia delle modifiche del template e consente di tornare a qualsiasi versione precedente entro 90 giorni. Il versionamento è di fondamentale importanza: se dopo aver pubblicato le modifiche viene scoperto un errore (ad esempio, un valore di parametro errato rompe l'interfaccia), è possibile ripristinare immediatamente il template a una versione funzionante precedente tramite la console Firebase.

Ogni modifica del template (pubblicazione) crea una nuova versione con un numero univoco. La console Firebase fornisce un registro delle modifiche con ora, utente e descrizione (se compilata). Si consiglia di aggiungere sempre una descrizione alle pubblicazioni: “Attivato nuovo feed per il gruppo di test iOS 10%”. Senza descrizione, dopo un mese sarà impossibile ricordare cosa sia stato esattamente modificato nella versione 42.

Come implementare Remote Config in un'applicazione

Implementare Remote Config si compone di tre passaggi: inizializzare l'SDK con le impostazioni (tempo di cache), definire i parametri predefiniti (valori in caso di indisponibilità del server) e la logica per applicare i valori ottenuti. I parametri predefiniti sono una rete di sicurezza nel caso in cui il dispositivo non riesca a connettersi a Firebase (nessuna connessione Internet, server non disponibile). Senza valori predefiniti, l'app utilizzerà null, che può causare arresti anomali.

La definizione dei valori predefiniti viene effettuata in due modi: a livello di programmazione tramite setDefaultsAsync o tramite un file XML. L'approccio programmatico è conveniente per progetti piccoli: tutti i valori vengono impostati direttamente nel codice una volta all'avvio dell'app. L'approccio tramite file è preferibile per progetti con decine di parametri: i valori vengono memorizzati nelle risorse e possono essere facilmente modificati senza ricompilazione. Si consiglia di combinare: impostazioni di base in XML e impostazioni specifiche a livello di programmazione.

L'asincronicità è una caratteristica chiave dell'SDK Remote Config. Il metodo fetchAndActivate() invia una richiesta al server in un thread in background senza bloccare l'interfaccia utente. Una volta completato il caricamento, si verifica l'attivazione — i valori dei parametri vengono aggiornati nella memoria dell'app. Utilizzare listener o coroutine (in Android/Kotlin) per monitorare il completamento. L'utente non deve vedere “salti” nell'interfaccia durante l'aggiornamento dei parametri — tutte le modifiche devono essere applicate in modo fluido.

Inizializzazione con onComplete e listener

Al primo avvio, l'SDK Remote Config non blocca l'inizializzazione dell'applicazione. Mentre avviene la sincronizzazione, l'app utilizza i valori predefiniti. Ciò significa che l'utente potrebbe vedere la versione precedente dell'interfaccia al primo avvio e, dopo il completamento del fetch, quella nuova. Per i parametri critici (ad esempio, serverUrl, da cui dipende l'operatività), utilizzare l'attivazione sincrona con attesa del risultato.

Pratica consigliata: mostrare una schermata di caricamento con un ritardo minimo se l'app necessita in modo critico di ottenere i parametri aggiornati prima di visualizzare la prima schermata. Nella schermata di caricamento, eseguire fetchAndActivate con un timeout di 5 secondi. Se i parametri non vengono caricati entro 5 secondi, l'app si avvia con i valori predefiniti. Ciò impedisce l'attesa infinita in assenza di connessione Internet.

Lavorare con parametri JSON

I parametri JSON in Remote Config consentono di trasmettere dati strutturati come un unico valore. Ad esempio, un oggetto con stili del tema: {“primaryColor”: “#6200EE”, “borderRadius”: 8, “fontFamily”: “Roboto”}. Sul client, il JSON viene analizzato e applicato all'interfaccia. Vantaggi: un parametro invece di tre, aggiornamento atomico (tutti e tre i campi vengono aggiornati simultaneamente), console pulita. Svantaggio: difficoltà di lettura nella console Firebase (il JSON viene visualizzato come stringa).

Raccomandazione: utilizzare parametri JSON per gruppi di valori logicamente correlati che vengono aggiornati insieme (temi, configurazione dello schermo, impostazioni di rete). Per parametri indipendenti (feature toggle, serverUrl), utilizzare parametri stringa o booleani separati — sono più facili da leggere nella console e più facili da tracciare nella cronologia delle versioni del template.

Test A/B con Remote Config

I test A/B sono una funzionalità integrata di Firebase Remote Config che consente di dividere gli utenti in gruppi, impostare diversi valori dei parametri per ciascun gruppo e misurare l'impatto delle modifiche sulle metriche selezionate. A differenza della divisione manuale tramite condizioni con random_percent, l'integrazione con Firebase Analytics raccoglie automaticamente le statistiche per ciascun gruppo sperimentale e mostra la significatività statistica delle differenze.

Il processo del test A/B: lo sviluppatore crea un esperimento nella console Firebase (sezione A/B Testing), seleziona un parametro Remote Config, imposta i valori per i gruppi di controllo e test e definisce la metrica target (ad esempio, tasso di conversione o entrate). Firebase distribuisce automaticamente gli utenti nei gruppi, raccoglie i dati e dopo 2–4 settimane mostra il risultato con il valore p. L'esperimento può essere interrotto anticipatamente se il risultato è conclusivo.

La significatività statistica è il criterio chiave per interrompere un esperimento. Firebase A/B Testing utilizza l'approccio frequentista e mostra il valore p per ciascuna metrica. La soglia di significatività standard è 0,05 (probabilità di confidenza del 95%). Quando questa soglia viene raggiunta a favore di uno dei gruppi, Firebase raccomanda di interrompere l'esperimento e applicare le modifiche a tutti gli utenti. Se la significatività non viene raggiunta dopo 4 settimane, l'esperimento è considerato inconcludente.

Tipi di esperimenti

Firebase A/B Testing supporta due tipi di esperimenti: A/B classico (confronto di due valori di un parametro) e A/B/n multivariato (confronto di tre o più valori). I test multivariati richiedono più utenti per raggiungere la significatività statistica. Si consiglia di utilizzare A/B/n solo per parametri con 3–5 varianti, dove ogni variante è fondamentalmente diversa dalle altre.

La durata dell'esperimento dipende dal volume di traffico: per le app con 1.000 utenti attivi giornalieri, la durata minima è di 2 settimane; per le app con 100.000 utenti, di 3–5 giorni. Firebase calcola automaticamente il tempo necessario e avvisa se il traffico attuale è insufficiente per rilevare differenze significative. Importante: non interrompere l'esperimento prima del tempo stimato, anche se il risultato sembra ovvio — questo è il classico errore di “peeking”.

Metriche per i test A/B

Le metriche target in Firebase A/B Testing vengono definite in base agli eventi di Firebase Analytics. Le metriche standard sono disponibili: utenti attivi giornalieri, entrate, tasso di conversione, retention, coinvolgimento utente. È anche possibile creare una metrica personalizzata basata su qualsiasi evento Analytics con parametri aggiuntivi. Ad esempio, la metrica “Percentuale di utenti che hanno raggiunto la schermata di pagamento” viene creata dall'evento screen_view con il parametro screen_name = “payment”.

Si consiglia di selezionare una metrica primaria su cui basare la decisione del successo dell'esperimento e 2–3 metriche secondarie per analisi aggiuntive. La selezione di più metriche primarie aumenta il rischio di falsi positivi (problema del confronto multiplo). Se la metrica primaria selezionata non mostra un miglioramento statisticamente significativo, l'esperimento è considerato non riuscito, anche se le metriche secondarie sono migliorate.

Esempi di codice per Remote Config in Kotlin

Consideriamo l'integrazione di Remote Config in un'applicazione Android in Kotlin. Gli esempi includono l'inizializzazione dell'SDK con tempo di cache personalizzato, il recupero di parametri di diversi tipi, l'implementazione di una condizione A/B lato client e la gestione degli errori quando il server non è disponibile. Tutto il codice viene eseguito nell'attività principale o nella classe Application in modo che i parametri siano disponibili dall'avvio dell'applicazione.

Prima dell'uso, aggiungere la dipendenza: implementation(“com.google.firebase:firebase-config”) tramite Firebase BOM. Assicurarsi che Firebase Analytics sia anche connesso, poiché Remote Config utilizza Analytics per passare le proprietà utente.

Inizializzazione e recupero dei parametri

Il primo esempio è la configurazione di base di Remote Config con un intervallo minimo di fetch di 1 ora per la produzione. L'SDK viene inizializzato nel metodo onCreate della classe Application. Dopo fetchAndActivate, viene verificato il valore del parametro welcome_message, che può essere modificato da remoto per la schermata di benvenuto.

class MainApp : Application() {

    override fun onCreate() {
        super.onCreate()
        val remoteConfig = Firebase.remoteConfig
        val settings = FirebaseRemoteConfigSettings.Builder()
            .setMinimumFetchIntervalInSeconds(3600)
            .build()

        remoteConfig.setConfigSettingsAsync(settings)
        remoteConfig.setDefaultsAsync(
            R.xml.remote_config_defaults
        )

        remoteConfig.fetchAndActivate()
            .addOnCompleteListener { task ->
                if (task.isSuccessful) {
                    val welcomeMsg = remoteConfig
                        .getString("welcome_message")
                    Log.d("RemoteConfig", welcomeMsg)
                }
            }
    }
}

Nell'esempio, setDefaultsAsync carica i valori predefiniti dal file XML res/xml/remote_config_defaults.xml. Se il fetch fallisce (nessuna rete, server non disponibile), l'app utilizzerà questi valori. Il file XML contiene gli stessi nomi di parametri della console Firebase: <entry key=“welcome_message”>Benvenuto!</entry>. Si consiglia di avere sempre valori predefiniti per tutti i parametri Remote Config.

Feature toggle con Remote Config

Il secondo esempio è un feature toggle (interruttore di funzionalità). Il parametro new_checkout_enabled è di tipo booleano. Se true, l'app mostra la nuova schermata di pagamento; se false, quella vecchia. Il feature toggle è lo scenario Remote Config più popolare: la modifica riguarda un solo parametro, non richiede modifiche alla logica e può essere annullata istantaneamente.

fun isFeatureEnabled(paramName: String): Boolean {
    return Firebase.remoteConfig
        .getBoolean(paramName)
}

// Utilizzo in activity
if (isFeatureEnabled("new_checkout_enabled")) {
    navigateToNewCheckout()
} else {
    navigateToLegacyCheckout()
}

La funzione isFeatureEnabled incapsula l'accesso a Remote Config e può essere facilmente testata tramite mock. Per i feature toggle, si consiglia di utilizzare una convenzione di denominazione: prefisso feature_, ff_ o flag_ in modo che lo scopo del parametro sia immediatamente chiaro nella console Firebase. Esempio: feature_new_onboarding, ff_dark_mode, flag_v3_api. Non utilizzare parametri flag per attivare/disattivare per più di 3 mesi — l'accumulo di flag morti complica la manutenzione.

Recupero della configurazione JSON del tema

Il terzo esempio è il recupero di un parametro JSON con le impostazioni del tema dell'app. Il parametro app_theme contiene un oggetto JSON con primaryColor, borderRadius e fontFamily. Sul client, il JSON viene analizzato con Gson o kotlinx.serialization e i valori vengono applicati all'interfaccia. Questo approccio consente ai designer di modificare il tema dell'app senza il coinvolgimento dello sviluppatore e senza un rilascio.

data class AppTheme(
    val primaryColor: String = "#6200EE",
    val borderRadius: Int = 8,
    val fontFamily: String = "Roboto"
)

fun getAppTheme(): AppTheme {
    val json = Firebase.remoteConfig
        .getString("app_theme")
    return Gson().fromJson(json, AppTheme::class.java)
}

Lavorare con JSON richiede attenzione: se il JSON nella console Firebase è errato (ad esempio, manca una virgola), l'analisi fallirà e l'app riceverà valori predefiniti invece del tema corrente. Si consiglia di validare le stringhe JSON prima della pubblicazione tramite un validatore JSON. Per la produzione, aggiungere try-catch durante l'analisi e registrare gli errori tramite Firebase Crashlytics.

Best practice e limitazioni

Firebase Remote Config è uno strumento potente, ma se utilizzato in modo errato può portare a problemi di prestazioni, prevedibilità del comportamento e sicurezza. Esaminiamo le pratiche chiave che aiuteranno a evitare errori comuni durante il lavoro con il servizio e le limitazioni da considerare durante la progettazione dell'architettura dell'applicazione.

Evitare dati sensibili — Remote Config non è progettato per memorizzare segreti (chiavi API, token, password). Tutti i valori dei parametri sono accessibili al codice client e possono essere estratti dalla memoria dell'applicazione. Per i dati riservati, utilizzare Cloud Functions con verifica lato server o Secret Manager. Memorizzare solo parametri pubblici in Remote Config: testi, flag, impostazioni dell'interfaccia, URL degli endpoint pubblici.

Testare ogni modifica prima di pubblicarla per l'intero pubblico. Utilizzare un test A/B o una pubblicazione su una piccola percentuale (1–5% degli utenti) per verificare che il nuovo valore non causi arresti anomali o rompa la visualizzazione. Remote Config non ha un ambiente di staging — tutte le modifiche vengono pubblicate immediatamente in produzione. L'unico modo per pubblicare in sicurezza è un'implementazione graduale.

Limitazioni della piattaforma: numero massimo di parametri — 2000 (per tutti i tipi), dimensione massima di un valore — 256 KB, dimensione totale della risposta del server — 800 KB. Il numero di proprietà utente che possono essere utilizzate in Remote Config è limitato a 25. L'intervallo minimo di fetch è di 0 secondi (per il debug), ma un uso eccessivo può portare al superamento della quota di Cloud Functions (30.000 richieste al minuto per progetto).