Targeting allows you to create rules for serving distinct audiences their own Offering. Instead of having a single Default Offering that all customers receive, you can instead create a cascading sequence of rules to deliver different Offerings to each audience that you define.
This allows you to create paywall experiences that are tailored to each of your audiences so you can make an effective pitch for your product and maximize lifetime value.
Targeting is available on Pro, Scale, and Enterprise plans. Click here to review your plan and consider upgrading.
|The set of Packages, metadata, and an optional paywall UI you can create to remotely control your paywall experience.
|The Offering that is set as "Default" in the RevenueCat Dashboard for your Project. We recommend designing your app so that the paywall always shows a customer's Current Offering, which will be your Project's Default Offering if no other conditions apply.
|The ability to assign a distinct Offering to a distinct audience of customers based on Targeting Rules you create.
|A collection of conditions that, when they are true for a given customer, will result in that customer matching the rule and being served the corresponding Offering.
|The filters such as App, Country, and App Version that can be used to construct a Targeting Rule.
|The customers who would be included in a Targeting Rule due to matching its conditions.
|The Targeting Rules that are actively being used to determine which customers which receive Offerings, as determined by their conditions, assessed in order from top to bottom.
|The Targeting Rules that are not actively being used. These may be drafts, rules you previously used, rules you intend to set live in the future, etc.
Before you setup any Targeting Rules, if you use Offerings, here's how they're returned in your app:
- RevenueCat is initialized
- Offerings are fetched
- Your list of Offerings is returned, along with the identifier of the Current Offering for a given customer
As long as your app is setup to display a customer's Current Offering on your paywall, then you can change the Default Offering that gets provided for a customer at any time from our Dashboard, or run an Experiment to serve two different Offerings to specific audiences.
Once you setup Targeting Rules, you unlock an additional level of customization, because the Current Offering that gets returned for each customer will be based on the Rule they qualify for. For example:
- RevenueCat is initialized
- Offerings are fetched
- Your list of Offerings is returned, along with the identifier of the Offering for the first rule that the customer matched as the Current Offering for that customer
- If the customer does not match any specified rules, they'll receive the Default Offering for your Project.
In December 2023 we began referring to a Project's current Offering as it's default Offering. Learn more here.
When determining which (if any) Targeting Rule a customer matches, we'll assess them from top to bottom as you've ordered them in the Dashboard.
First, navigate to "Targeting" in the "Monetization tools" section of your Project Settings. Then click on "Create a New Rule" to begin.
Then, create your rule by:
- Entering a Display name
- Selecting your desired conditions (learn more about conditions here)
- Selecting an Offering to display when those conditions are met
- Selecting your desired State for the rule
Once you've entered all of the required fields for your rule, click "Save" and it will be added to the list of rules in State you've selected.
When a rule is newly set Live (either when it's created or when an Inactive rule is set Live), it'll be ordered at the bottom of that list so that if its targeted audience has any overlap with other Live rules, the existing Live rules will "outrank" the new rule when determining what a customer receives.
Live rules can be reordered at any time.
- Click "Order rules" to enter the ordering mode
- Drag the rules you wish to reorder to their correct location in the list
- Click "Save order" when you've set them in the order you'd like them to be evaluated in
Ordering only applies to cases where 1 customer may match multiple Live rules. If your Live rules are mutually exclusive, their order will have no impact on how customers are assigned to them.
Rules can also be edited, deleted, or made inactive at any time if you need to modify how Offerings are being served to your customers.
In addition, if you're looking to add a new rule that's similar to an existing one, you can start by duplicating that rule and then making the desired modifications to the rule conditions.
|The storefront a customer is currently using on supported SDK versions*, or their geolocation otherwise.
*Available on iOS SDK Versions >= 4.30.4 with support on other SDKs coming soon
|The App that your customer is currently using. Commonly used to target by platform.
|The App Version of a specified App that your customer is currently using. When assessing App Versions using more than or less than operators, we apply semantic versioning logic.
|RC SDK Version
|The RC SDK Version of a specified SDK flavor of the App Versions that your customer is currently using. Commonly used to target RevenueCat Paywalls only to RC SDK Versions that explicitly support them.
- Dimensions like Country and App which have a defined set of possible values can be added with an "is any of" or "is not any of" to select individual values or sets of values to include/exclude
- Dimensions like App Version and RC SDK Version which have an ever expanding set of possible values can be added with is/is not or more than/less than operators.
- Multiple conditions can be added for each dimension with an AND relationship, to create rules such as:
- App version is more than or equal to 1.1.0
- App version is less than 1.2.0
- App Version and RC SDK Version must always have a specified App or SDK (respectively), since the intended version to target may be different between the App or RC SDK flavor you're targeting.
|How do Targeting and Experiments interact?
|TL;DR Experiment enrollment is checked before Targeting Rules are assessed
When any Experiment is running, customer enrollment will occur before Offerings are fetched. When Offerings are fetched, we'll first check to see if a customer is enrolled in a running Experiment. If they are, their variant's Offering will be returned. If they are not, then any existing Targeting Rules will be assessed.
|How can I test Targeting in my app?
|The easiest way to test Targeting is to create a Targeting Rule for an app version that has not yet been released (e.g. only available in TestFlight), and serve a unique Offering to that Targeting Rule. Then, check to confirm whether your app in production displays a different Offering than your app version in TestFlight does.
Updated 8 days ago