Firebase Remote Config for paywall A/B testing: where it works and where it breaks

Firebase Remote Config is the first tool many mobile teams reach for when someone says "let's A/B test the paywall." It is already in the project. It fetches JSON at runtime. It supports percentage rollouts. For a single flag toggling headline copy on a home screen, that instinct is fine. For subscription paywalls tied to store products, trial eligibility, and multi-step onboarding, Remote Config alone creates fragile glue code and blurry experiment readouts.

This guide explains firebase remote config paywall setups that work, patterns that break in production, and where journey orchestration belongs when the hypothesis is bigger than one key-value pair.

What Remote Config actually controls

Remote Config returns parameters to your app. Your app must map parameters to UI, offerings, and analytics events.

Remote Config provides	Your app must provide
String / JSON values	Paywall renderer
Rollout percentages	Experiment exposure logging
Audience conditions	Link to RevenueCat offering IDs
Defaults in binary	Fallback when fetch fails

Firebase does not render paywalls. Firebase does not process IAP. Firebase does not know your onboarding screen order unless you encode it in JSON and interpret it in navigation code.

Setup that works: single-surface toggles

Remote Config fits narrow paywall-adjacent tests when billing UI lives in RevenueCat Paywalls or Superwall and you only toggle which template or offering ID to present.

Example parameter schema

Key	Type	Example values
paywall_template_id	string	default, annual_focus
rc_offering_id	string	default, promo_summer
show_trial_badge	boolean	true, false
paywall_headline	string	Localized copy

Client flow

1. Fetch Remote Config on launch (or before paywall)
2. Read rc_offering_id
3. Call RevenueCat getOfferings or present Paywall with that identifier
4. Log exposure event to Firebase Analytics with parameter snapshot

Why this works

• One responsibility per key
• Paywall compliance stays in RevenueCat store-linked products
• Rollback is a Config publish, not an app release
• Clear mapping from flag to billing layer

Where it breaks: paywall as a pile of keys

Teams often grow parameters until the paywall is undebuggable:

Smell	Symptom
15+ keys for one paywall	No one knows production state
JSON blob without schema	Silent parse failures show default paywall
Duplicate experiments in RC and Analytics	Conflicting assignments
Copy in Remote Config, layout in code	"Test" requires code change anyway
No link between RC variant and purchase events	Cannot compute conversion

firebase remote config paywall tutorials often stop at toggling a color. Subscription apps need purchase conversion per variant. That requires disciplined exposure logging and RevenueCat experiment alignment.

Firebase A/B Testing vs Remote Config alone

Google integrates Remote Config with Firebase A/B Testing (verify current console UX). The flow:

1. Create experiment in Firebase console
2. Variants set parameter values
3. Analytics tracks goal events
4. Console declares winner

Strength	Limitation
Familiar if on Firebase	Goals tied to Analytics events you instrument
No extra vendor	Weaker than dedicated experiment platforms for advanced stats
Works for simple tests	Multi-step funnels need custom funnel definitions
	Paywall still your code / RC

For a single paywall template ID test, Firebase A/B Testing can suffice. For "path A shows paywall on screen 3, path B on screen 6," Remote Config is the wrong abstraction.

Journey-level experiments: the breaking point

Paywall conversion is a function of everything before the paywall:

Upstream factor	Remote Config pain
Onboarding length	Multiple keys or JSON graph
Permission order	Separate navigators per variant
Campaign personalization	Audience rules multiply
Cancel then return paywall	No lifecycle model
Step drop-off diagnosis	Manual events per screen

Remote Config is configuration, not authoring. Growth teams want a canvas, not a growing JSON file engineers fear to touch.

Remote Config only:
  paywall_variant = "B"
  + onboarding_variant = "short"
  + att_timing = "late"
  → combinatorial explosion in app code

Flow platform:
  manifest defines screens, branches, paywall node
  → one publish, per-step analytics

Rheo sits in the second column. Rheo routes users through native screens and invokes RevenueCat or Superwall at the paywall node. Rheo does not replace Remote Config for app-wide kill switches. Rheo replaces encoding entire journeys in Config JSON.

Comparison table: who owns what

Layer	Remote Config	RevenueCat Experiments	Rheo
Paywall template	Can pass ID	Native experiments	Paywall node only
Offering / price test	Pass offering ID	Primary owner	Journey to paywall
Onboarding order	Poor fit	Not applicable	Primary owner
Step funnel	Manual	Purchase focused	Built-in
Publish speed	Fast	Fast for paywall	Fast for flows
Store compliance	Your responsibility	RC-linked products	Orchestration only

Rule: If the hypothesis is only paywall UI or package mix, use RevenueCat Experiments (or Superwall). If the hypothesis is path to paywall, use Rheo. Remote Config optional for global kills.

Anti-patterns in production

Anti-pattern 1: Remote Config drives layout

Storing layout trees in Config without a versioned schema. One bad publish breaks paywall rendering for all users.

Fix: Billing SDK templates or Rheo manifest with schema validation.

Anti-pattern 2: Concurrent uncoordinated tests

Remote Config paywall test + Rheo onboarding test + RC offering test on the same users.

Fix: Experiment calendar, mutual exclusion, or layered ownership doc.

Anti-pattern 3: Stale defaults in binary

Fetch fails, users see year-old default prices.

Fix: Safe defaults matching current production, monitor fetch success rate.

Anti-pattern 4: Ignoring cold start

Config fetch async; first session shows default paywall.

Fix: fetchAndActivate timing, or activate on previous session data with ETag discipline.

Anti-pattern 5: Paywall test without purchase denominator

Clicks logged, purchases not joined to variant.

Fix: RevenueCat customer attributes or events with variant ID at presentation time.

Recommended architecture

Use Remote Config for	Use RevenueCat / Superwall for	Use Rheo for
Global feature kills	Paywall templates and offerings	Onboarding sequences
Emergency offering ID override	Paywall A/B tests	Campaign branches
Non-paywall flags	Restore and purchase UI	Cancel and win-back flows
Default fetch for non-funnel flags		ATT and permission timing

Wire Remote Config offering ID into Rheo only when the paywall node needs a campaign-specific offering passed from a global flag. Prefer offering logic on traits in Rheo resolve when the path is campaign-specific.

Instrumentation checklist

Before calling a Remote Config paywall test valid:

• Exposure event logged with paywall_template_id (or equivalent)
• Same ID attached to RevenueCat paywall presentation
• Primary metric: trial start or purchase, not button tap
• Secondary: dismiss rate, restore rate
• Sample size calculated from baseline conversion
• Fetch failures monitored separately
• No overlapping RC paywall test on same surface

When to migrate off Remote Config for paywalls

Signals:

Signal	Action
Engineers spend more time on Config JSON than growth on hypotheses	Move journeys to Rheo
Paywall tests work but onboarding tests never ship	Split layers
Analytics cannot explain step drop-off	Add flow analytics
RC Experiments available and paywall-only	Consolidate paywall tests there

Remote Config remains useful. It should not be the only experimentation layer for subscription funnels.

Policy and honesty

Remote Config does not exempt paywalls from App Store or Play rules. Price, trial terms, and subscription management links must match store metadata. OTA and Config changes that alter subscription terms without review risk rejection and user complaints.

Firebase also does not manage paywalls visually. Neither does Rheo. Paywall UI stays in billing integrations. Rheo orchestrates when users reach that surface and where they go after dismiss or purchase.

Example decision tree

1. Testing two RC paywall templates? → RevenueCat Experiments (Remote Config optional for kill switch)
2. Testing headline only with same offering? → RC template test or Superwall
3. Testing paywall timing in onboarding? → Rheo flow experiment
4. Testing onboarding for TikTok campaign? → Rheo traits, not Remote Config audiences alone
5. Global "disable promo paywall"? → Remote Config boolean

Summary

Firebase Remote Config for paywall A/B testing works when parameters are few, billing UI lives in RevenueCat or Superwall, and analytics tie exposure to purchase outcomes. It breaks when teams use Config as a flow engine, when keys multiply without schema, or when journey hypotheses need step-level funnels.

Use Remote Config for toggles and kills. Use RevenueCat or Superwall for paywall science. Use Rheo when the experiment is the path to the paywall and everything after.

Start for free and run journey experiments that complement your Firebase and RevenueCat setup.