Firebase Remote Config: vad det är, parametrar och hur man hanterar på distans

Vad är Firebase Remote Config och hur fungerar det

Firebase Remote Config är en tjänst som lagrar nyckel-värdepar på serversidan av Firebase och levererar dem till klientenheter på begäran eller enligt schema. Varje parameter har ett namn (sträng), ett värde (sträng, tal, boolean eller JSON) och kan kopplas till villkor — regler som avgör vilket värde en specifik användare får. Villkor kan kontrollera appversion, enhetsspråk, region, slumpmässig procentandel och många andra attribut.

Remote Configs arkitektur är baserad på push-pull-modellen med prioritet för pull. Klienten begär periodiskt aktuella värden från servern (som standard var 12:e timme). Utvecklaren kan dock initiera omedelbar synkronisering i kod eller via Firebase-konsolen (knappen “Publish changes”). Efter publicering av ändringar skickar servern ett push-meddelande via Firebase Cloud Messaging, och appen kan efter mottagning begära parametrarna igen.

Gratis prisplan Firebase Remote Config har inga begränsningar för antalet parametrar eller förfrågningar, vilket skiljer det från andra Firebase-tjänster. Den enda begränsningen är svarsstorleken, som inte får överstiga 800 KB (totalt för alla parametrar). Detta är mer än tillräckligt för ett typiskt scenario: de flesta projekt använder 10–50 parametrar, och deras totala volym överstiger sällan 100 KB.

Hur bestämmer Remote Config vilket värde som ska returneras till användaren

Mekanismen för val av värde baseras på villkorens prioritet. Varje villkor representerar en regel (t.ex. “iOS-version > 15.0”). Remote Config kontrollerar villkoren i prioritetsordning och returnerar värdet för det första matchande villkoret. Om inget villkor matchar används standardvärdet (default value). Denna mekanism gör det möjligt att skapa en hierarki av regler: från den mest specifika till den mest allmänna.

Viktigt: ordningen på villkoren i Firebase-konsolen har betydelse. Om två villkor kan matcha samma användare samtidigt vinner det som är högre upp i listan. Det rekommenderas att placera mer specifika villkor (t.ex. för en specifik appversion) ovanför allmänna villkor (t.ex. “Alla iOS-användare”). Felaktig ordning kan leda till att en riktad ändring aldrig tillämpas.

Caching och parametrars livslängd

Som standard cachas värden som tas emot från servern av Remote Config i 12 timmar. Detta innebär att efter publicering av ändringar i konsolen kommer appen att se dem tidigast 12 timmar senare (eller efter nästa explicita fetch-anrop). Minsta cachingtid kan ställas in via FirebaseRemoteConfigSettings(minimumFetchIntervalInSeconds: 3600) — för produktion rekommenderas minst 1 timme för att undvika överdrivna serverförfrågningar och användning av användarens data.

För testning av ändringar under utveckling, använd minimiintervallet 0 sekunder: FirebaseRemoteConfigSettings(minimumFetchIntervalInSeconds: 0). I detta läge kommer varje fetch-anrop att ladda aktuella värden från servern. Det är viktigt att inte glömma att återställa produktionsintervallet före lansering, annars kommer appen vid varje start att ansluta till servern, vilket ökar kostnaderna och batteriförbrukningen.

Parametrar, villkor och användargrupper

En Remote Config-parameter är en namngiven variabel som kan anta ett av flera värden beroende på villkor. Värdetyper: string, number (double), boolean, JSON object (serialiserad sträng). JSON-parametrar är praktiska för att överföra strukturerad data utan att skapa många separata parametrar: till exempel ett objekt med appens temainställningar (primaryColor, backgroundColor, fontSize).

Villkor (conditions) är logiska regler som kontrollerar attribut hos användaren eller enheten: OS-version (iOS, Android), appversion, land, språk, användargrupp (egenskap definierad i kod), slumpmässig procentandel (för A/B-tester). Villkor kan kombineras genom logiskt AND: till exempel “appversion >= 5.0” OCH “land = Ryssland”. Varje parameter kan ha ett obegränsat antal villkor, men i praktiken används 2–5.

För personalisering använder du användaregenskaper (user properties) — attribut som ställs in i appkoden via Firebase Analytics. Till exempel analytics.setUserProperty(“subscription_tier”, “premium”). Remote Config kan kontrollera denna egenskap och returnera värden som är specifika för premiumanvändare. Personalisering via Remote Config kräver inte att villkor skapas på klientsidan — all logik är koncentrerad till molnkonsolen.

Användargrupper och segmentering

Remote Config stöder två segmenteringsmodeller: baserad på attribut (conditions) och baserad på Firebase Analytics-egenskaper (user properties). Den första modellen är statisk: villkoret kontrollerar ett fast attribut som inte ändras inom sessionen eller appversionen. Den andra modellen är dynamisk: egenskapen kan ställas in när som helst under appens körning, vilket möjliggör flexibel segmentering av användare vid körning.

Viktigt: för att använda user properties i Remote Config krävs integration av Firebase Analytics. Detta krav beror på att Remote Config får användardata från Analytics SDK. Utan Analytics fungerar Remote Config endast med enhetsattribut (OS-version, appversion, land från IP). Personalisering baserad på användarbeteende (t.ex. “har gjort 5 köp”) är endast tillgänglig via Analytics.

Mallversionering

Remote Config-mallen (template) är den fullständiga uppsättningen av alla parametrar, villkor och deras värden. Firebase lagrar historiken över malländringar och gör det möjligt att återgå till vilken tidigare version som helst inom 90 dagar. Versionering är kritisk: om ett fel upptäcks efter publicering av ändringar (t.ex. ett felaktigt parametervärde förstör gränssnittet), kan mallen omedelbart återställas till en tidigare fungerande version via Firebase-konsolen.

Varje malländring (publicering) skapar en ny version med ett unikt nummer. I Firebase-konsolen finns en ändringslogg med angivelse av tid, användare och beskrivning (om ifylld). Det rekommenderas att alltid lägga till en beskrivning vid publicering: “Aktiverade det nya flödet för iOS 10% testgrupp”. Utan beskrivning är det omöjligt efter en månad att komma ihåg vad som exakt ändrades i version 42.

Hur man implementerar Remote Config i appen

Implementeringen av Remote Config består av tre steg: initialisering av SDK med inställningar (cachingtid), definiering av standardparametrar (värden om servern inte är tillgänglig) och logik för att tillämpa mottagna värden. Standardparametrar är en säkerhetsåtgärd om enheten inte kan ansluta till Firebase (inget internet, servern inte tillgänglig). Utan default values kommer appen att använda null, vilket kan leda till en krasch.

Definition av default values görs på två sätt: programmatiskt via anrop av setDefaultsAsync eller via en XML-fil. Det programmatiska sättet är bekvämt för små projekt: alla värden ställs in direkt i koden en gång vid appstart. Filbaserat sätt är att föredra för projekt med dussintals parametrar: värden lagras i resurser och kan enkelt redigeras utan omkompilering. Det rekommenderas att kombinera: grundinställningar i XML och specifika — programmatiskt.

Asynkronitet är en nyckelfunktion i Remote Config SDK. Metoden fetchAndActivate() utför begäran till servern i bakgrunden utan att blockera gränssnittet. Efter att laddningen är klar sker aktivering — parametervärdena uppdateras i appens minne. För att övervaka slutförande, använd lyssnare eller korutiner (i Android/Kotlin). Användaren ska inte se “hopp” i gränssnittet vid uppdatering av parametrar — alla ändringar ska tillämpas smidigt.

Initialisering med onComplete och lyssnare

Vid första start blockerar Remote Config SDK inte appens initialisering. Under synkroniseringen använder appen standardvärden. Detta innebär att användaren kan se en gammal version av gränssnittet vid första starten och efter fetch en ny version. För kritiska parametrar (t.ex. serverUrl som funktionaliteten beror på), använd synkron aktivering med väntan på resultat.

Rekommenderad praxis: visa en laddningsskärm med minimal fördröjning om appen kritiskt behöver få aktuella parametrar innan den första skärmen visas. På laddningsskärmen körs fetchAndActivate med en timeout på 5 sekunder. Om parametrarna inte laddas inom 5 sekunder startar appen med default values. Detta förhindrar oändlig väntan vid frånvaro av internet.

Arbeta med JSON-parametrar

JSON-parametrar i Remote Config gör det möjligt att överföra strukturerad data med ett värde. Till exempel ett objekt med temastilar: {“primaryColor”: “#6200EE”, “borderRadius”: 8, “fontFamily”: “Roboto”}. På klientsidan analyseras JSON och tillämpas på gränssnittet. Fördelar: en parameter istället för tre, atomicitet vid uppdatering (alla tre fält uppdateras samtidigt), ren konsol. Nackdel: svårt att läsa i Firebase-konsolen (JSON visas som en sträng).

Rekommendation: använd JSON-parametrar för grupper av logiskt relaterade värden som uppdateras tillsammans (teman, skärmkonfiguration, nätverksinställningar). För oberoende parametrar (feature toggle, serverUrl) använd separata sträng- eller boolean-parametrar — de är lättare att läsa i konsolen och lättare att spåra ändringar i mallens versionshistorik.

A/B-testning med Remote Config

A/B-testning är en inbyggd funktion i Firebase Remote Config som gör det möjligt att dela upp användare i grupper, ställa in olika parametervärden för varje grupp och mäta effekten av ändringar på valda mätvärden. Till skillnad från manuell uppdelning via villkor med random_percent, samlar integrationen med Firebase Analytics automatiskt in statistik för varje experimentgrupp och visar statistisk signifikans för skillnaderna.

Processen för A/B-test: utvecklaren skapar ett experiment i Firebase-konsolen (sektionen A/B Testing), väljer en Remote Config-parameter, ställer in värden för kontroll- och testgrupp och bestämmer målvärdet (t.ex. conversion rate eller revenue). Firebase distribuerar automatiskt användare till grupper, samlar in data och efter 2–4 veckor visar resultatet med p-värde. Experimentet kan stoppas i förtid om resultatet är tydligt.

Statistisk signifikans är det viktigaste kriteriet för att stoppa experimentet. Firebase A/B Testing använder frekventistisk metod (Frequentist) och visar p-värde för varje mätvärde. Standard signifikansnivå är 0,05 (95% konfidenssannolikhet). När denna nivå uppnås till förmån för en av grupperna rekommenderar Firebase att stoppa experimentet och tillämpa ändringarna för alla användare. Om signifikans inte uppnås efter 4 veckor anses experimentet vara ofullständigt.

Typer av experiment

Firebase A/B Testing stöder två typer av experiment: klassisk A/B (jämförelse av två värden för en parameter) och multivariat A/B/n (jämförelse av tre eller fler värden). För multivariata tester krävs fler användare för att uppnå statistisk signifikans. Det rekommenderas att endast använda A/B/n för parametrar med 3–5 varianter där varje variant skiljer sig radikalt från de andra.

Experimentets längd beror på trafikvolymen: för appar med 1000 aktiva användare per dag är minimitiden 2 veckor, för appar med 100 000 användare — 3–5 dagar. Firebase beräknar automatiskt den nödvändiga tiden och varnar om den aktuella trafiken inte är tillräcklig för att upptäcka signifikanta skillnader. Viktigt: stoppa inte experimentet före den beräknade tiden, även om resultatet verkar uppenbart — detta är det klassiska “peeking”-felet.

Mätvärden för A/B-testning

Målmätvärden i Firebase A/B Testing definieras baserat på Firebase Analytics-händelser. Standardmätvärden finns tillgängliga: daily active users, revenue, conversion rate, retention, user engagement. Ett anpassat mätvärde kan också skapas baserat på valfri Analytics-händelse med ytterligare parametrar. Till exempel skapas mätvärdet “Andel användare som nådde betalskärmen” från händelsen screen_view med parametern screen_name = “payment”.

Det rekommenderas att välja ett primärt mätvärde (primary metric) som ligger till grund för beslut om experimentets framgång, och 2–3 sekundära mätvärden för ytterligare analys. Att välja flera primära mätvärden ökar risken för falskt positivt resultat (multiple comparison problem). Om det valda primära mätvärdet inte visar en statistiskt signifikant förbättring anses experimentet misslyckat, även om sekundära mätvärden har förbättrats.

Kodexempel för Remote Config i Kotlin

Vi undersöker integrationen av Remote Config i en Android-app i Kotlin. Exemplen inkluderar initialisering av SDK med anpassad cachingtid, hämtning av parametrar av olika typer, implementering av ett A/B-villkor på klientsidan och felhantering vid otillgänglig server. All kod körs i main activity eller Application-klassen så att parametrar är tillgängliga från appens start.

Före användning, lägg till beroendet: implementation(“com.google.firebase:firebase-config”) via Firebase BOM. Se till att Firebase Analytics också är ansluten, eftersom Remote Config använder Analytics för att överföra användaregenskaper.

Initialisering och hämtning av parametrar

Första exemplet — grundläggande konfiguration av Remote Config med ett minimiintervall för fetch på 1 timme för produktion. SDK initieras i metoden onCreate i Application-klassen. Efter fetchAndActivate kontrolleras värdet för parametern welcome_message, som kan ändras på distans för välkomstskärmen.

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)
                }
            }
    }
}

I exemplet laddar setDefaultsAsync default values från XML-filen res/xml/remote_config_defaults.xml. Om fetch slutar med fel (inget nätverk, servern inte tillgänglig) kommer appen att använda dessa värden. XML-filen innehåller samma parameternamn som i Firebase-konsolen: <entry key=“welcome_message”>Välkommen!</entry>. Det rekommenderas att alltid ha default values för alla Remote Config-parametrar.

Feature toggle med Remote Config

Andra exemplet — feature toggle (flagga för funktionsaktivering). Parametern new_checkout_enabled är av typen boolean. Om värdet är true — visar appen den nya kassaskärmen, om false — den gamla. Feature toggle är det mest populära Remote Config-scenariot: ändringen påverkar endast en parameter, kräver ingen ändring av logik och kan omedelbart återkallas.

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

// Användning i activity
if (isFeatureEnabled("new_checkout_enabled")) {
    navigateToNewCheckout()
} else {
    navigateToLegacyCheckout()
}

Funktionen isFeatureEnabled inkapslar åtkomsten till Remote Config och kan enkelt testas via mock. För feature toggles rekommenderas en namnkonvention: prefix feature_, ff_ eller flag_ så att parameterns syfte omedelbart framgår i Firebase-konsolen. Exempel: feature_new_onboarding, ff_dark_mode, flag_v3_api. Använd inte flaggparametrar för att aktivera/inaktivera längre än 3 månader — ackumulering av döda flaggor försvårar underhållet.

Hämta JSON-temakonfiguration

Tredje exemplet — hämtning av en JSON-parameter med appens temainställningar. Parametern app_theme innehåller ett JSON-objekt med primaryColor, borderRadius och fontFamily. På klientsidan analyseras JSON med Gson eller kotlinx.serialization, och värdena tillämpas på gränssnittet. Detta tillvägagångssätt gör att designers kan ändra appens tema utan utvecklarens medverkan och utan release.

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)
}

Arbete med JSON kräver försiktighet: om JSON i Firebase-konsolen är ogiltig (t.ex. saknas ett kommatecken) misslyckas analysen och appen får default values istället för det aktuella temat. Det rekommenderas att validera JSON-strängar före publicering via en JSON-validerare. För produktion, lägg till try-catch vid analys och logga fel via Firebase Crashlytics.

Bästa praxis och begränsningar

Firebase Remote Config är ett kraftfullt verktyg, men felaktig användning kan leda till problem med prestanda, förutsägbarhet i beteende och säkerhet. Vi går igenom viktiga metoder som hjälper till att undvika typiska fel vid arbete med tjänsten och begränsningar som måste beaktas vid utformning av appens arkitektur.

Undvik känslig data — Remote Config är inte avsett för lagring av hemligheter (API-nycklar, token, lösenord). Alla parametervärden är tillgängliga för klientkod och kan extraheras från appens minne. För konfidentiell data, använd Cloud Functions med serververifiering eller Secret Manager. I Remote Config lagrar du endast offentliga parametrar: texter, flaggor, gränssnittsinställningar, URL:er för offentliga slutpunkter.

Testa varje ändring innan publicering för hela publiken. Använd ett A/B-test eller publicering till en liten andel (1–5% av användarna) för att kontrollera att det nya värdet inte orsakar en krasch eller förstör visningen. Remote Config har ingen staging-miljö — alla ändringar publiceras direkt i produktion. Det enda säkra sättet att publicera är gradvis utrullning.

Plattformsbegränsningar: maximalt antal parametrar — 2000 (för alla typer), maximal storlek för ett värde — 256 KB, total storlek på serversvar — 800 KB. Antalet användaregenskaper (user properties) som kan användas i Remote Config är begränsat till 25. Minsta fetch-intervall — 0 sekunder (för felsökning), men överdriven användning kan leda till att Cloud Functions-kvoten överskrids (30 000 förfrågningar per minut per projekt).