Skip to main content
  • Community
  • Get Help
  • SDKs
  • best practice for adding additional service tier when using experiments with multiple App Store subscription groups?

Our app has had great success using RevenueCat experiments to optimize subscription pricing for an iOS app. We are looking at adding an additional higher service tier, and would like to know if there are best practices given that we have users on multiple subscription groups.

In order to prevent users of our main (“plus”) subscription tier from cross-grading to a lower price point offered in a pricing experiment, our experimental price points have all been confined to their own subscription groups. We understand this to be RevenueCat’s recommended best practice.

Additionally, in order to avoid negative user reviews, we have not consolidated our users from low-price experiments onto the final higher price. We have subscribers active at several price points in several subscription groups.

We now want to add a “pro” service tier at a higher price point. What is the best way to do this without risking users being subscribed to both the “plus” and new “pro” tier at the same time? It seems that we shouldn’t continue with the previous approach of creating pro subscription groups at different price points because that guarantees users can subscribe to both tiers at once.

If we add a pro product to each existing subscription group, is there a way to use the RC SDK to extract only the highest service tier option from a subscribed user’s subscription group, or otherwise offer them the Pro subscription corresponding to their current Plus subscription?

Thank you!

Hi @RKH,

This seems a complicated set up but I think that you could accomplish what you are thinking by using targeting. You’d need to identify which users are in each group and then show them the offering that you want.

Said that, experiments are only shown to new users to avoid the issue of previous users to see lower prices for the same subscription. By only putting new users into the experiments we are sure that they’ve never seen any other price before.

Bear in mind that with the set up that you mention, a user can still change to a lower one and even be double-subscribed via Settings > Account > Subscriptions where they can manage the subscription and change their plan.

Let me know if this works!

Hi @joan-cardona 

Thanks for the response. We are using (and like!) the targeting feature now, which helps us a lot with the placements feature.

Thank you for reminding me that experiments do not apply to existing users. That had been a concern since I believe that experiments overwrite any targeting. But since it applies only to new users that shouldn’t be a problem.

I believe that the way to use targeting to solve this problem would be to have a customer attribute for their active App Store subscription group, and then create a targeting condition for each subscription group so the placement “pro_upgrade” shows the correct offering for that user. Is that what you imagine?

I took a look at extracting the App Store product granting the customer’s current service tier and came up with this:

if let entitlementInfo = customerInfo.entitlementsi"plus"] {
    let productIdentifier = entitlementInfo.productIdentifier
    let products = await Purchases.shared.products(pproductIdentifier])
    let subscriptionGroup = products.first?.sk1Product?.subscriptionGroupIdentifier ?? "unknown"
   print("subscriptionGroupID enabling plus \(subscriptionGroup)"
}

It looks like this will work. I can create custom targeting for each active subscription group and show them an offering for the “pro_upgrade” placement corresponding to their subscription group.

We haven’t used customer attributes before. The naive approach seems to be that every time we get a new CustomerInfo we can parse that to get their active subscription group entitling the user to the top service tier and set the customer attributes in the RC SDK. I don’t see anything in your docs indicating not to do this other than that you rate limit syncAttributesAndOfferingsIfNeeded() to 5/min. Does it seem reasonable to sync their subscription group to a customer attribute any time CustomerInfo changes?

Reply


Terms & ConditionsCookie settings