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 and Android. 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. |
| 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. |
| 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.
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 |
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 and Android only. 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 hybrid SDKs like React Native and Flutter.
- Navigation stack presentation. Present Flows inside your app's navigation stack, not only modally.
- Checkpoint analytics. See how often customers reach each Checkpoint.
- Multiple Paywalls in one Flow. For example, show an abandonment offer after the first Paywall is closed, or based on other conditions.
- Frequency limits. Limit how often a customer can match a rule, like once per week.
- Branching in Flows. Add branches within Flows to deliver different screens to audiences you define within a Flow.
- Custom variables in targeting rules. Target rules on the custom variables you pass to
checkpoint(), directly from the dashboard. - Custom audiences in the rule editor. Define an audience directly while creating a targeting rule, instead of picking a saved one.
- Observer Mode. Use Checkpoints when your app completes purchases itself.
- Standard Checkpoints, like app opened or paywall closed, fired automatically by the SDK.