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?
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:
If you’ve got any other questions, please let me know. Thanks!