Price Increase Experiment Guide #1208
Conversation
|
Preview this PR here: https://dev-docs.revenuecat.com/pr-1208/ |
ekurutepe
left a comment
ekurutepe
left a comment
There was a problem hiding this comment.
Overall, I love this. It is very detailed which is great to have as a recipe but I'd try to cut out the parts about how to create products in ASC and GPC and shorten how to set them up in RC: the guide already requires a live prod setup. We can assume that they already know the basics. Otherwise the important parts of this could get lost among the details. I'm sure we have other docs about those, maybe we can link those instead?
|
|
||
| - An active RevenueCat project with at least one app configured | ||
| - Existing subscription products set up and selling in your app | ||
| - A dynamic paywall that fetches and displays the current Offering (required for Experiments) |
There was a problem hiding this comment.
I'm not sure what's meant by a "dynamic paywall". Is this a term that people should know?
There was a problem hiding this comment.
I meant dynamic in the sense that the paywall isn't hardcoded with specific product IDs, but instead fetched dynamically via getOfferings. We refer to them as "dynamic paywalls" when we talk about how to manually implement paywalls in our docs (aka how to create a non-RC paywall that uses our SDK): https://www.revenuecat.com/docs/getting-started/displaying-products
That being said, it is already implied by the rest of the sentence so doesn't feel necessary here. I can just call it "paywall" instead of "dynamic paywall".
|
|
||
| If you haven't implemented a dynamic paywall yet, see [Displaying Products](https://www.revenuecat.com/docs/getting-started/displaying-products) for guidance, or try [RevenueCat Paywalls](https://www.revenuecat.com/docs/tools/paywalls). | ||
|
|
||
| ## Step 1: Create +10% products in the stores |
There was a problem hiding this comment.
I'm not sure about recommending 10% as their first experiment. I'd assume devs reading this doc would be small time developers with few conversions. It would take them forever to get enough data to reach statistical significance on LTV.
There was a problem hiding this comment.
I think we should solve that problem separately by giving customers an estimated time to significance when they're setting up the experiment, so they can decide if it's worth the amount of time it would take to run the experiment.
| Before you set up your products, make sure you have: | ||
| - The latest **Paid Applications Agreement** signed in the "Business" module in App Store Connect. You will not be able to test in-app purchases until this is signed. | ||
| - Completed the **Tax** and **Banking** tabs with all required forms signed | ||
| - A bank account linked to App Store Connect with status showing "Clear" | ||
|
|
||
| **You must complete all of these before you can test in-app purchases.** |
| - **Product IDs cannot be reused across any of your apps, even if the product is deleted** | ||
| - You'll need this exact ID later when importing to RevenueCat | ||
|
|
||
| :::info Tips for creating robust Product IDs |
|
|
||
| Before running your experiment, verify that both Offerings display correctly in your app: | ||
|
|
||
| 1. Use the [Offering Override](https://www.revenuecat.com/docs/offering-override) feature to preview each Offering |
There was a problem hiding this comment.
I'm not familiar with the linked document. Do we need to mention that they need to find the app user id for their test device/account first?
Corrected the enrollment logic
Co-authored-by: Engin Kurutepe <[email protected]>
Motivation / Description
Step-by-step instructions to set up a price experiment, to link to from the inspiration section of the Experiment empty state
Changes introduced
Linear ticket (if any)
Additional comments