RevenueCat Experiments vs flow-level testing: when to use each

If you run subscriptions on mobile, you probably already use RevenueCat for entitlements, offerings, and paywall presentation. RevenueCat Experiments adds controlled tests on those paywall configurations. Rheo adds controlled tests on everything that happens before and around the paywall: onboarding beats, permission timing, stories sequences, and branch logic.

The tools overlap in one place (the paywall moment) but solve different problems everywhere else. This guide explains what RevenueCat Experiments does well, what flow-level testing covers, how to choose between them, and how to combine both in a single growth stack without conflicting assignments or muddy metrics.

What RevenueCat Experiments is built for

RevenueCat Experiments lets you test variations of offerings and paywalls presented through RevenueCat's paywall UI. Typical use cases:

• Two paywall templates with different pricing emphasis
• Offering A vs Offering B for new subscribers
• Introductory offer copy and package layout tests

Strengths:

• Tight coupling to purchase events RevenueCat already records
• Familiar paywall authoring in the RC dashboard or Paywalls product
• Statistical framing oriented to subscription outcomes

Documented constraints (check current RC docs for updates) commonly include limits such as two variants per experiment and targeting oriented toward new customers rather than arbitrary journey states. Those constraints are appropriate for paywall science but insufficient when your hypothesis is "screen three of onboarding should come before ATT."

RevenueCat owns what the paywall sells and how it looks. Rheo owns how users arrive at that paywall.

What flow-level testing covers

Flow-level testing optimizes the journey: sequences, branches, permissions, and non-paywall surfaces. In Rheo, an experiment might vary:

• Number and order of onboarding screens
• Copy and creative on any step
• Branch rules based on traits or attribution
• Whether the paywall appears on day zero or after activation
• Win-back or cancellation flows unrelated to initial purchase

Strengths:

• Step-level funnel analytics tied to each screen
• Native rendering across the whole journey, not only the paywall modal
• Rapid iteration without App Store review for flow changes
• Context-aware branching using SDK attributes (including RevenueCat outcomes)

Rheo integrates RevenueCat as a node inside a flow: the paywall presents, outcomes normalize to purchase_completed, restore_completed, dismissed, or failed, and edges route users accordingly. That integration is complementary. Rheo does not replace RevenueCat billing or Experiments on the paywall product itself.

Decision matrix

Use this matrix when planning your next test.

Question	Prefer RevenueCat Experiments	Prefer Rheo flow experiments
Are we testing price, package mix, or paywall template?	Yes	No
Are we testing onboarding length or order?	No	Yes
Are we testing ATT or push placement?	No	Yes
Are we testing post-paywall activation steps?	No	Yes
Is the hypothesis only about paywall UI?	Yes	Rarely
Do we need attribution-based paths?	Limited	Yes
Do we need win-back or cancel flows?	No	Yes

When both columns seem relevant, split the hypothesis: journey test in Rheo, paywall test in RevenueCat, never both on the same user without a design doc.

Combined workflow

A clean combined workflow keeps one owner per layer and one primary metric per experiment.

Layer responsibilities

Layer	Owner tool	Examples
Entitlements and products	RevenueCat	Products, offerings, trials
Paywall presentation test	RevenueCat Experiments	Template A vs B
Journey to paywall	Rheo	Stories beats, permissions, timing
Lifecycle after churn	Rheo	Win-back, cancel survey

Suggested sequencing for new apps

1. Stabilize baseline onboarding in Rheo until step drop-offs are understood.
2. Insert RevenueCat paywall node with explicit fallback edges for dismiss and failure paths.
3. Run journey experiments that move paywall placement or pre-paywall value props.
4. Run RC Experiments on paywall template and offering once traffic reaches the paywall reliably.
5. Document interaction: if Rheo routes only high-intent users to the paywall, RC Experiments see a biased sample. Note that in readouts.

Avoid double exposure

Do not run a Rheo experiment that changes paywall offering IDs and a RevenueCat Experiment on the same surface simultaneously unless you have a factorial design and enough traffic. Most mobile teams do not. Serialize tests instead.

Metrics mapping

Align metrics so readouts stay legible:

Stage	Rheo metrics	RevenueCat metrics
Onboarding	Step completion, branch rates	(optional) trial start if fired from flow
Paywall	Surface presented, surface outcome	Experiment conversion, revenue
Post-purchase	Downstream activation steps	Active subscriptions, churn

Rheo emits surface_presented, surface_outcome, and iap_purchase on paywall nodes. RevenueCat remains authoritative for subscription state. For journey tests, prioritize trial start rate per onboarding variant. For RC Experiments, prioritize conversion among paywall viewers.

Example scenario

Hypothesis: "Users who see two value screens before the paywall start trials at a higher rate than users who see the paywall immediately."

Tool choice: Rheo flow experiment only. RevenueCat offering stays constant.

Setup:

• Control channel: install → paywall → activation
• Variant channel: install → value beat 1 → value beat 2 → paywall → activation
• Holdout: 10% if traffic allows
• Primary metric: trial starts per install
• Guardrail: paywall dismiss rate (watch for annoyance)

Follow-up hypothesis: "Among users who reach the paywall, annual emphasis converts better than monthly emphasis."

Tool choice: RevenueCat Experiment on paywall template. Rheo journey frozen to the winning variant from the first test.

This sequencing isolates causality and respects each tool's strength.

Common pitfalls

Testing paywall color in Rheo while RC tests pricing. Pick one layer.

Ignoring fallback edges. RevenueCat paywall nodes require fallback wiring. Failed presentations should not dead-end the user.

Reading RC experiment results when Rheo changed who reaches the paywall mid-test. Freeze journey changes during paywall experiments.

Assuming RC Experiments replace onboarding tests. They do not. New user targeting does not solve mid-funnel sequencing.

Platform notes for React Native and Expo

Most Rheo customers integrate RevenueCat through react-native-purchases and react-native-purchases-ui. Rheo paywall nodes lazy-load the UI module; if it is missing (for example stock Expo Go), the step resolves as failed and your fallback edge must carry users forward.

Practical guidance:

• Use a custom dev client or prebuild for paywall testing, not Expo Go alone.
• Keep Purchases.configure in app startup; Rheo never configures billing for you.
• Wire fallback edges on every paywall node before publishing experiments.
• When running RC Experiments, freeze Rheo channel changes that alter who reaches the paywall.

SwiftUI and Flutter teams follow the same split: billing SDK owned by the host app, journey owned by Rheo channels, experiments assigned to the layer that matches the hypothesis.

Experiment documentation template

Before launching any test that touches both systems, write a short doc:

1. Hypothesis (one sentence)
2. Layer (Rheo journey / RC paywall / both sequential)
3. Primary metric and guardrail
4. Traffic allocation and minimum runtime
5. Freeze rules (what must not change mid-test)

This sounds bureaucratic until a paywall test coincides with an onboarding reorder and nobody can explain the result. One page prevents that confusion.

When teams outgrow RC Experiments alone

RevenueCat Experiments is the right tool when your paywall is stable and traffic is sufficient for two-variant tests on subscription outcomes. Teams typically add Rheo flow experiments when:

• Onboarding changes weekly while paywall stays fixed
• Attribution-aware paths are required for paid campaigns
• Permission and education screens dominate drop-off before the paywall
• Lifecycle flows (cancel, win-back, feedback) need the same experimentation velocity

Neither tool replaces the other. The maturity path is: stabilize billing in RevenueCat, map the journey in Rheo, then assign hypotheses to the layer they actually touch.

Quick reference card

I want to test...	Tool
Offering layout	RevenueCat Experiments
Package prices	RevenueCat Experiments
Onboarding length	Rheo
ATT timing	Rheo
Cancel survey path	Rheo
Paywall after story beat 3 vs 5	Rheo
Win-back offer presentation	Rheo (paywall node if resubscribe)

Print this table in your growth wiki. It ends most "which dashboard do I use?" debates in one glance.

Respect the billing stack

RevenueCat is the right system of record for subscriptions. Rheo's public positioning is explicit: complement, not replacement. Cite RevenueCat documentation when configuring offerings, and keep Purchases.configure in your app as today.

When both tools are active, your stack looks like:

• RevenueCat SDK configured at app launch
• Rheo SDK presenting flows that include RC paywall surfaces
• RC Experiments on paywall when appropriate
• Rheo experiments on everything upstream and lifecycle flows downstream

Summary

RevenueCat Experiments answers "which paywall wins?" Flow-level testing answers "which path gets users to that paywall ready to buy?" Use the decision matrix to assign each hypothesis, run journey tests before or between paywall tests, and map metrics so readouts stay honest.

Start for free and pair Rheo journey experiments with your existing RevenueCat setup.