Question

Distinct iOS Subscription Groups for Experiment

  • 3 March 2023
  • 1 reply
  • 69 views

Badge +3

According to the docs (https://www.revenuecat.com/docs/creating-offerings-to-test) it’s best to “use distinct Subscription Groups on the App Store for each RevenueCat Offering when testing”.

This seems like things would get out of hand? Here are the issues I see:

  • Each subscription in a subscription group has a unique product_id. RevenueCat suggests we use the following format: rc_2999_1y_1w0.
    • These ids can’t be duplicated across subscription groups. So you would never be able to test the same setup in a new group.
    • Should I be adding a new annotation to product ids if I want to use experiments? Something like: rc_2999_1y_1w0_exp1
  • Apple doesn’t seem too keen on you offering multiple Subscription Groups as there is a warning that pops up. I guess RC makes sure that a single user never sees multiple offerings… but what if that person were to sign out and back in with a new email? And they see the other offering? Couldn’t they end up purchasing a subscription from the other group at that point?

TLDR: I don’t understand why RevenueCat suggests we use distinct Subscription Groups. It seems like it leads to more problems than it solves. Can someone explain to me why this is a good idea?


1 reply

Userlevel 1
Badge +2

Hi Zach, thanks for reaching out! First, if I recall correctly, you’re designing an experiment to modify paywall content, and not the nature of the offer, right? Because of that, using additional subscription groups is not necessary. We recently modified those docs to clarify that it’s specifically when testing new prices that this recommendation applies, but I’ll do another pass there.

But for clarity, let me also address your questions:

  • First, regarding product IDs, we recommend that format as a sample to make sure all critical information about a product is stored in the ID so that you can quickly scan a list of products and understand the nature of the offer associated with them.
    • For some types of experiments, that may still work fine. For example, if you were changing the price of that product to $34.99, then the product ID would be rc_3499_1y_1w0. For others, if that product’s offer is not changing, then yeah adding some kind of other identifier would be necessary. The prefix of _exp1 you proposed would work fine, but you could also keep it broad and identify subsequent products as _b_c, etc.
    • In other words, that naming convention is purely a recommendation to make it easy to track your products over time.
  • Then on the point regarding the App Store setup, the intention with creating separate Subscription Groups is to ensure that a customer does not receive a cluttered and undesired list of products to select from in their subscription settings on iOS that do not reflect the offer that was made to them on the paywall.
    • Additionally, because purchase receipts are associated with an Apple ID, as long as a customer is signed into the same Apple ID, when their purchases are restored they’d regain access to the same active subscription and subscription group they were previously offered.
    • In theory if a single person signed into a new Apple ID and used your app, they might see a different subscription group, but that risk would still be present if you only used a single subscription group as well; since each Apple ID would be eligible to subscribe to the same product.

If you’ve got any other questions, please let me know. Thanks!

Reply