Duplicate of Task - Bartek Krawczyk
The purpose of the memo is to propose a way to better integrate Experiments and Paywalls,
reducing the friction in common workflows in a way that’s shippable in one quarter.
Problem space
Customer intent
The primary customer goal is to maximize revenue through rapid experimentation.
Most frequent experiments focus on:
paywall design
messaging and framing
package presentation
Actual pricing and packaging tests tend to be a less frequent part of experimentation programs.
Customers want to test changes quickly with minimal operational overhead.
Assumption note: Based on prior experience and common industry patterns. To be validated with
RevenueCat insights.
Current state of the product
Offering is the primary unit of experimentation, with Paywalls tied to it on a 1:1 basis.
To test a Paywall, users must duplicate Offerings and Paywalls, keep them in sync, and configure
experiments between them — resulting in a high-friction, largely redundant workflow.
Problem statement
Offerings are a core infrastructure concept in RevenueCat, but they are not how most customers think
about monetization changes. Customers primarily iterate on paywalls — adjusting copy, layout, and
framing.
The mismatch between customer intent and experimentation workflow makes even simple paywall
experiments unnecessarily complex and error-prone.
Solution space
Proposed solution - experiments as the orchestration layer
The current Experiments entry point (intent-based types like Paywall design, Price point, etc.) already
reflects user intent, but the subsequent flow doesn’t carry it through.
The key idea is for RevenueCat to manage Offering duplication and mapping automatically, minimizing
steps and cognitive load required to start the experiment.
Instead of: “Prepare objects → experiment on them”
We move to: “Start with experiment intent → system prepares objects for you”
In the long run, RevenueCat evolves into a system where experimentation is driven by customer intent
rather than infrastructure abstractions.
MVP - simplified paywall UI experiment tests
If the client selects a UI experiment test, we’ll ask them to create or choose paywall variants only. The
underlying Offering will be duplicated automatically, maintaining system integrity while significantly
simplifying the workflow.
Because products and pricing remain unchanged, this duplication acts as a snapshot of the current
Offering rather than a mutation of its configuration, reducing risks.
This isn’t a dead-end optimization. By introducing an orchestration layer, we can reduce setup friction
now while keeping the door open to bigger changes in how Paywalls-Offerings-Experiments relate,
without forcing a large architectural decision upfront.
Other approaches were considered, including a setup wizard, multiple paywalls per Offering, or
runtime paywall resolution. While they reduce friction, they either preserve the core intent
mismatch or require architecture changes beyond a one-quarter scope.
Why is this the right move
1. Matches customer intent: quick experiments on messaging and layout.
2. Solves the biggest pain with minimal scope: significantly easier experimentation setup.
3. Preserves system integrity & backward compatibility: SDK remains unchanged, Offerings remain
the contract with SDKs, experimentation and targeting infrastructure stays intact. Existing
experiments continue to work. Heavy users are still able to use the old flow if needed.
Key risks
1. A mismatch between the UI and backend could create confusion about how Offerings are created,
owned, and used during experiments.
2. Attribution and reporting complexity from automatically created and named Offerings, especially for
customers using custom payment systems or third-party analytics.
3. A growing set of legacy Offerings over time from experiment-driven duplication.
4. Offerings are a fundamental primitive in the RevenueCat ecosystem, and reliability is our #1 priority.
Any automation for their creation must be introduced gradually and validated carefully.
Risks can be mitigated through explicit transparency: experiment-generated Offerings and Packages
should be clearly tagged and surfaced as first-class artifacts. Importantly, these challenges already
exist, as users manually manage experiment-related Offerings without automation support.
Measures of success
Primary outcome: revenue lift generated for our customers with experimentation
Adoption: %customers running experiments
Engagement: #avg experiments per customer
Guardrail: #avg lift per experiment
Operational: #support tickets volume related to experiment setup
Open questions & tradeoffs
1. Scope vs flexibility: The MVP focuses on UI-only experiments to reduce complexity, at the cost of
not supporting pricing experiments initially. Does it accurately reflect our customers' needs?
2. Short-term leverage vs long-term architecture: proposed solution mitigates the problem within a
realistically short time frame, but the fundamental challenge (Offering as experimentation unit tied 1:1
with paywall) remains. Does our existing architecture reflect current and future needs?
3. Automation vs clarity: Automatically creating Offerings removes manual setup work, but it also
means users need clear visibility into the source of those Offerings. Will they trust the system with
such a fundamental artifact, or will it cause discomfort?
Potential future steps
1. Extend automation to pricing experiments: By also automating mutating Offering params.
2. Revisit system architecture: Use the simplified UI layer as a signal to evaluate whether bigger
changes to the Offering–Paywall relationship should be considered.
3. Tighten product integration: Further integrate Experiments with the Paywall Builder (e.g., enabling
the paywall editor as an entry point for starting experiments).