Targeting by Checkpoint
Register moments in your app once, then decide from the dashboard what each customer sees there.
Targeting by Checkpoint is in private beta on iOS, Android, and React Native. Share feedback through the beta feedback form or with your RevenueCat contact. See Known limitations.
Targeting by Checkpoint allows you to deliver unique Flows and Paywalls to each audience for the exact moment they're in, and optimize them through experimentation. Checkpoints are an evolution of Placements to make your paywall orchestration through RevenueCat even more powerful.
A Checkpoint is a named moment in your app, like onboarding_completed. You add it once in code. From then on, you decide in the RevenueCat dashboard what happens at that moment through rules: serve a Flow or Paywall from RevenueCat, return an Offering to serve your own custom paywall, or do nothing.
To watch our demo from RevenueCat's App Growth Annual conference, click below.
Why use Checkpoints
- Change monetization without a release. Create or modify your rules at any time through the dashboard.
- Decide at that moment, not when the app is first launched. Rules are evaluated on the device when the customer reaches the Checkpoint, so they reflect what the customer just did.
- Serve new Paywalls without duplicating Offerings. One Offering can be re-used across many Paywalls, making it much easier to test simple design changes.
- Experiment at each Checkpoint individually. Run an experiment at one Checkpoint, or across several.
How it works
- Register a Checkpoint in your app. Call
checkpoint("onboarding_completed")where the moment happens. See Implementing Checkpoints. - Create a targeting rule. Define what happens when an audience reaches a Checkpoint, including which Flow or Offering they receive. See Creating rules.
- RevenueCat decides what to serve. When a customer reaches the Checkpoint, the RevenueCat SDK checks the rules in order and serves the first match. If nothing matches, the customer continues uninterrupted.
Key terms
| Term | Meaning |
|---|---|
| Checkpoint | A named moment in your app, identified by a string you choose. |
| Targeting rule | Instructions for what should happen: at these Checkpoints, this audience gets this Flow or Offering. Rules at a Checkpoint run in order; the first match wins. |
| Audience | Who a rule applies to, such as customers in the US without an active Entitlement. Pick a saved audience or define custom filters for one rule. |
| Flow | The RevenueCat UI a rule can serve, such as a Paywall, a multi-step Flow, or an experiment with different experiences per customer. A rule can serve an Offering instead of a Flow. See Flows and Paywalls. |
| Branch | A step in a Flow that sends each customer to the next step for the first audience they match, or to the step for everyone else. See Branch a Flow by audience. |
| Custom variables | Values you pass at the Checkpoint to change the behavior of the Flow that's served. Targeting rules on them is coming soon. |
Use cases
These examples show what Checkpoints make possible. Each one starts with a Checkpoint in your app and a rule in the dashboard.
Turn a Paywall on or off anywhere
Add Checkpoints at moments that might deserve a paywall, like settings_opened or export_tapped. Leave them without rules until you need them. For example, to run a Black Friday sale, create a scheduled rule with a start and end date. When the sale ends, the rule will become inactive, and customers will go back to matching whatever other rule(s) they're eligible for on the Checkpoints they reach.
React to what the customer just did
Pass a quiz answer as a custom variable, and serve a matching Paywall:
- Customer picks "Lose weight" in onboarding.
- Your app calls
checkpoint("onboarding_completed")withgoal = lose_weight. - A rule targeting
goal = lose_weightserves the weight-loss Paywall. Targeting custom variables in rules is coming soon. Until then, set the answer as a customer attribute and target that.
Custom attributes are attached to the customer profile and persist. Custom variables apply only to that one Checkpoint call. Use custom variables to change a Checkpoint and its Flow in isolation. Use custom attributes to store a lasting fact about the customer.
Send each audience down a different path in one Flow
Add a Branch step to a Flow to route customers by audience without creating a separate rule for each one. For example, an onboarding Flow can show a win-back screen to customers whose subscription has expired, and the standard Paywall to everyone else. Both paths can rejoin the same screens afterward. See Branch a Flow by audience.
Serve new Paywalls without new Offerings
A new Paywall no longer needs a new Offering. If you want to serve the same products on a new Paywall, just duplicate it and modify the design. New Offerings are only needed when you want to change the products being offered. See Flows and Paywalls.
Run experiments that are isolated to each Checkpoint
Experiments run from Targeting rules, so you control which Checkpoints they apply to. Test whole Flows against each other, or test variants inside a single Flow. You can even run separate experiments for the same audience at different Checkpoints. See Running experiments.
Example: rules at a home_screen Checkpoint
Rules run top to bottom. The first match wins.
| Order | Rule | Audience | Serves |
|---|---|---|---|
| 1 | Upgrade offer | Currently trialing is true | Upgrade Paywall |
| 2 | Win-back | Subscription status is Expired | Win-back Paywall |
| 3 | Weight-loss goal | Custom attribute goal is lose_weight | Weight-loss Paywall |
| 4 | Default | All customers (default audience) | Default Paywall |
Measure results
In Charts v3, filter or segment purchase charts by Checkpoint, Flow, and Paywall to compare revenue and conversions across the moments, Flows, and Paywalls that led to a purchase. Some charts only support filtering by these dimensions.
A Flow is the full sequence of steps a customer sees. The Paywall is the screen in that Flow that offers packages to purchase. If a Flow contains only one Paywall, the two dimensions show the same results.
How Checkpoints differ from legacy Targeting
Legacy Targeting lets you decide which Offering a customer gets when the SDK fetches Offerings. Targeting by Checkpoint decides what to serve at each moment, when that moment happens.
What changes
| Legacy Targeting | Targeting by Checkpoint | |
|---|---|---|
| When it decides | When Offerings are fetched, usually at launch | When the customer reaches the Checkpoint |
| What it serves | An Offering, along with its attached Paywall | A Flow or an Offering |
| Where it applies | All placements | Any Checkpoints you choose |
| No matching rules | Falls back to the Default Offering | Nothing is shown |
| Creating a new Paywall | Requires a new Offering | Can reuse existing Offerings |
| Experiments | Deliver unique Offerings to each variant, covering all placements; ordered separately from Targeting rules. | Deliver unique Flows or Offerings to each variant, covering only the Checkpoints you specify, within the same set of Targeting Rules. |
What stays the same
- Your existing targeting rules keep working. They appear as Legacy Targeting.
- Offerings,
getOfferings, and Paywall APIs are not deprecated.
Can I use Placements and Checkpoints together?
We recommend moving fully to Checkpoints. Mixing them means using two different systems to decide what a customer sees. See Migrate from Placements and Offerings.
Known limitations
- Platforms: iOS, Android, and React Native. Flutter, other hybrid SDKs, and Web are coming soon.
- Presentation: Flows open modally, either as a sheet or full screen. You can't yet embed them in your own views.
- Onboarding Flows: Some components like customer inputs & loaders that are designed for onboarding experiences and are supported in Funnels are not yet available in Flows, but will be coming in the future.
- Exit offers are not served for Flows shown at Checkpoints.
- Customer attributes in rules use values set on the current device. Values set from other devices or server-side are not accessible when rules are assessed.
- Frequency limits aren't available yet.
- Observer Mode (
purchasesAreCompletedByset to your app) isn't supported yet. - Hard Paywalls aren't available yet. To require an Entitlement, check it in the continuation.
Coming soon
- Hard Paywalls. Require an Entitlement before the customer can move past a Checkpoint. Until then, every Checkpoint is a soft gate: The customer can always close the Flow.
- Hybrid SDKs. Use Checkpoints from Flutter and other hybrid SDKs.
- Navigation stack presentation. Present Flows inside your app's navigation stack, not only modally.
- Checkpoint analytics on the Targeting page. See how often customers reach each Checkpoint, and the sessions and revenue each rule drives.
- Multiple Paywalls in one Flow. For example, show an abandonment offer after the first Paywall is closed.
- Frequency limits. Limit how often a customer can match a rule, like once per week.
- Custom variables in targeting rules. Target rules on the custom variables you pass to
checkpoint(), directly from the dashboard. - Observer Mode. Use Checkpoints when your app completes purchases itself.
- Standard Checkpoints, like app opened or paywall closed, fired automatically by the SDK.