Change "current" Offering to "default" Offering when referencing a Pr…

…oject (#542)

## Motivation / Description

Full background is
[here](https://revenuecat.slack.com/archives/CFU1JG9U6/p1700595848075709).
TL;DR version is:
1. When we release Targeting, the term current Offering will become even
less appropriate than it already is, so we're taking the opportunity to
change it default Offering when referencing "a Project's default
Offering."
2. In the context of getting Offerings, though, we'll continue to
describe the Offering that should be served for a customer as **their**
current Offering. So no SDK/API changes are needed, and in the docs and
Dashboard anytime we are referring to what an individual customer will
be served (e.g. in the Customer Profile) we will continue to call that
their current Offering.

## Changes introduced

I went through all of the places in our docs that need to be updated,
but definitely need a QA to make sure:
1. My changes make sense, and
2. I didn't miss any

## Linear ticket (if any)


https://linear.app/revenuecat/issue/PWL-426/update-docs-for-the-current-to-default-terminology-change

## Additional comments

---------

Co-authored-by: Josh Holtz <me@joshholtz.com>

docs_source/Dashboard & Metrics/customers-group/offering-override.md

@@ -1,7 +1,7 @@
 ---
 title: Offering Override
 slug: offering-override
-excerpt: Override the current offering that displays in your app
+excerpt: Override the default offering that displays in your app for a given customer
 hidden: false
 ---
 You can override the current offering that displays in your app on a per-user basis by selecting a different offering in the **Current Offering** card. This can be useful for:
@@ -42,4 +42,4 @@ Click on edit to choose a new offering:
     }
   ]
 }
-[/block]
+[/block]

docs_source/Getting Started/displaying-products.md

@@ -81,9 +81,13 @@ The `getOfferings` method will fetch the Offerings from RevenueCat. These are pr
 > 
 > You can find more info about trouble shooting this issue in our [Help Center](https://support.revenuecat.com/hc/en-us/articles/360041793174).
 
-You must choose one Offering that is the "Current Offering" - which can easily be accessed via the `current` property of the returned offerings.
+You must choose one Offering that is the "Default Offering" - which can easily be accessed via the `current` property of the returned offerings for a given customer.
 
-To change the current Offering, navigate to the Offerings tab for your project in the RevenueCat dashboard and click **Make current** next to the Offering you'd like to enable.
+> 📘 What's the difference between a current Offering and a default Offering?
+>
+> The current Offering for a given customer may change based on the experiment they're enrolled in, any targeting rules they match, or the default Offering of your Project. Your Project's default Offering is the Offering that will be served as "current" when no other conditions apply for that customer.
+
+To change the default Offering, navigate to the Offerings tab for your project in the RevenueCat dashboard and click **Make default** next to the Offering you'd like to enable.
 
 ![](https://files.readme.io/a6ff351-app.revenuecat.com_projects_85ff18c7_offerings_packages_pkge2ed0611690_attach_3.png "app.revenuecat.com_projects_85ff18c7_offerings_packages_pkge2ed0611690_attach (3).png")
 
@@ -93,7 +97,7 @@ Offerings can be updated at any time, and the changes will go into effect for al
 
 ## Custom Offering identifiers
 
-It's also possible to access other Offerings besides the "Current Offering" directly by its identifier.
+It's also possible to access other Offerings besides the Default Offering directly by its identifier.
 
 [block:file]
 [
@@ -356,4 +360,4 @@ This can be accomplished with custom Offering identifiers for each of these "coh
 # Next Steps
 
 - Now that you've shown the correct products to users, time to [make a purchase ](doc:making-purchases)
-- Check out our [sample apps ](doc:sample-apps) for examples of how to display products.
+- Check out our [sample apps ](doc:sample-apps) for examples of how to display products.

docs_source/Tools/experiments-v1/configuring-experiments-v1.md

@@ -3,7 +3,7 @@ title: Configuring Experiments
 slug: configuring-experiments-v1
 hidden: false
 ---
-Before setting up an experiment, make sure you've created the products and offerings that you want to test and added any new products to the appropriate entitlements in your project (more on this below). You should also test the offerings you've chosen on any platform your app supports.
+Before setting up an experiment, make sure you've created the products and Offerings that you want to test and added any new products to the appropriate entitlements in your project (more on this below). You should also test the Offerings you've chosen on any platform your app supports.
 
 # Setting up a new experiment
 
@@ -45,15 +45,15 @@ Then, enter the following details:
 - Experiment name
 - Enrollment criteria (optional)
 - Control variant
-  - The offering that will be used for your Control group
+  - The Offering that will be used for your Control group
 - Treatment variant
-  - The offering that will be used for your Treatment group (the variant in your experiment)
+  - The Offering that will be used for your Treatment group (the variant in your experiment)
 
-> 📘 Setting up an offering for your treatment
+> 📘 Setting up an Offering for your treatment
 > 
-> If you've not setup multiple offerings before, you'll be prompted to do so now, since you'll need at least 2 available offerings to run an experiment.
+> If you've not setup multiple Offerings before, you'll be prompted to do so now, since you'll need at least 2 available Offerings to run an experiment.
 > 
-> The treatment offering represents the hypothesis you're looking to test with your experiment (e.g. higher or lower priced products, products with trials, etc).
+> The treatment Offering represents the hypothesis you're looking to test with your experiment (e.g. higher or lower priced products, products with trials, etc).
 > 
 > For App Store apps, we recommend setting up new products to test as a new Subscription Group so that customers who are offered those products through Experiments will see only that same set of products to select from their subscription settings.
 
@@ -78,14 +78,14 @@ When viewing a new experiment, you can start, edit, or delete the experiment.
 
 
 - Start: Starts the experiment. Customer enrollment and data collection begins immediately, but results will take up to 24 hours to begin populating.
-- Edit: Change the name, enrollment criteria, or offerings in an experiment before it's been started. After it's been started, only the percent of new customers to enroll can be edited.
+- Edit: Change the name, enrollment criteria, or Offerings in an experiment before it's been started. After it's been started, only the percent of new customers to enroll can be edited.
 - Delete: Deletes the experiment.
 
 > 🚧 Sandbox
 > 
-> Test users will be placed into the experiment offering variants, but sandbox purchases won't be applied to your experiment.
+> Test users will be placed into the experiment Offering variants, but sandbox purchases won't be applied to your experiment.
 > 
-> If you want to test your paywall to make sure it can handle displaying the offerings in your experiment, you can use the [Offering Override](doc:offering-override) feature to choose a specific offering to display to a user.
+> If you want to test your paywall to make sure it can handle displaying the Offerings in your experiment, you can use the [Offering Override](doc:offering-override) feature to choose a specific Offering to display to a user.
 
 # FAQs
 
@@ -94,14 +94,14 @@ When viewing a new experiment, you can start, edit, or delete the experiment.
   "data": {
     "h-0": "Question",
     "h-1": "Answer",
-    "0-0": "Can I edit the offerings in a started experiment?",
-    "0-1": "Editing an offering for an active experiment would make the results unusable. Be sure to check before starting your experiment that your chosen offerings render correctly in your app(s). If you need to make a change to your offerings, stop the experiment and create a new one with the updated offerings.",
+    "0-0": "Can I edit the Offerings in a started experiment?",
+    "0-1": "Editing an Offering for an active experiment would make the results unusable. Be sure to check before starting your experiment that your chosen Offerings render correctly in your app(s). If you need to make a change to your Offerings, stop the experiment and create a new one with the updated Offerings.",
     "1-0": "Can I edit the enrollment criteria of a started experiment?",
     "1-1": "Before an experiment has been started, all aspects of enrollment criteria can be edited. However, once an experiment has been started, only new customers to enroll can be edited; since editing the apps or countries that an experiment is exposed to would alter the nature of the test.",
     "2-0": "Can I restart an experiment after it's been stopped?",
-    "2-1": "After you choose to stop an experiment, new customers will no longer be enrolled in it, and it cannot be restarted. If you want to continue a test, create a new experiment and choose the same offerings as the stopped experiment.  \n  \n(NOTE: Results for stopped experiments will continue to refresh for 28 days after the experiment has ended)",
+    "2-1": "After you choose to stop an experiment, new customers will no longer be enrolled in it, and it cannot be restarted. If you want to continue a test, create a new experiment and choose the same Offerings as the stopped experiment.  \n  \n(NOTE: Results for stopped experiments will continue to refresh for 28 days after the experiment has ended)",
     "3-0": "What happens to customers that were enrolled in an experiment after it's been stopped?",
-    "3-1": "New customers will no longer be enrolled in an experiment after it's been stopped, and customers who were already enrolled in the experiment will begin receiving the current offering if they reach a paywall again.  \n  \nSince we continually refresh results for 28 days after an experiment has been ended, you may see conversions from these customers in your results, since they were enrolled as part of the test while it was running."
+    "3-1": "New customers will no longer be enrolled in an experiment after it's been stopped, and customers who were already enrolled in the experiment will begin receiving the default Offering if they reach a paywall again.  \n  \nSince we continually refresh results for 28 days after an experiment has been ended, you may see conversions from these customers in your results, since they were enrolled as part of the test while it was running."
   },
   "cols": 2,
   "rows": 4,
@@ -110,4 +110,4 @@ When viewing a new experiment, you can start, edit, or delete the experiment.
     "left"
   ]
 }
-[/block]
+[/block]

docs_source/Tools/experiments-v1/experiments-overview-v1.md

@@ -3,29 +3,29 @@ title: Experiments Overview
 slug: experiments-overview-v1
 hidden: false
 ---
-Experiments allow you to answer questions about your users' behaviors and app's business by A/B testing two offerings in your app and analyzing the full subscription lifecycle to understand which variant is producing more value for your business.
+Experiments allow you to answer questions about your users' behaviors and app's business by A/B testing two Offerings in your app and analyzing the full subscription lifecycle to understand which variant is producing more value for your business.
 
 While price testing is one of the most common forms of A/B testing in mobile apps, Experiments are based on RevenueCat Offerings, allowing you A/B test more than just prices, including: trial length, subscription length, different groupings of products, etc.
 
-Plus, by attaching metadata to your offerings and programming your paywall to be responsive to it, you can remotely test any aspect of your paywall. [Learn more here](https://www.revenuecat.com/docs/offering-metadata).
+Plus, by attaching metadata to your Offerings and programming your paywall to be responsive to it, you can remotely test any aspect of your paywall. [Learn more here](https://www.revenuecat.com/docs/offering-metadata).
 
 > 📘 
 > 
 > Experiments is available to Pro & Enterprise customers. [Learn more about pricing here](https://www.revenuecat.com/pricing/).
 
 ## How does it work?
 
-After configuring the two Offerings you want and adding them to an Experiment, RevenueCat will randomly assign users to a cohort where they will only see one of the two Offerings. Everything is done server-side, so no changes to your app are required if you're already displaying the `current` offering in your app! 
+After configuring the two Offerings you want and adding them to an Experiment, RevenueCat will randomly assign users to a cohort where they will only see one of the two Offerings. Everything is done server-side, so no changes to your app are required if you're already displaying the `current` Offering for a given customer in your app! 
 
 > 🚧 
 > 
-> Programmatically displaying the `current` offering in your app when you fetch offerings is **required** to ensure customers are evenly split between variants.
+> Programmatically displaying the `current` Offering in your app when you fetch Offerings is **required** to ensure customers are evenly split between variants.
 
 If you need help making your paywall more dynamic, see [Displaying Products](doc:displaying-products). The [Swift sample app](https://github.com/RevenueCat/purchases-ios/tree/main/Examples) has an example of a [dynamic paywall](https://github.com/RevenueCat/purchases-ios/blob/main/Examples/MagicWeather/MagicWeather/Sources/Controllers/PaywallViewController.swift) that is Experiments-ready. Dynamic paywall examples in other languages can be found within our other [sample apps](https://www.revenuecat.com/docs/sample-apps) as well.
 
 > 📘 
 > 
-> To learn more about creating a new Offering to test, and some tips to keep in mind when creating new Products on the stores, [check out our guide here](doc:creating-offerings-to-test).
+> To learn more about creating a new Offering to test, and some tips to keep in mind when creating new Products on the stores, [check out our guide here](doc:creating-Offerings-to-test).
 
 ![](https://files.readme.io/34bba5f-ab-test.png "ab-test.png")
 
@@ -37,7 +37,7 @@ As soon as a customer is enrolled in an experiment, they'll be included in the "
 
 ## Implementation steps
 
-**Experiments requires you to use offerings and have a dynamic paywall in your app that displays the current offering.** While Experiments will work with iOS and Android SDKs 3.0.0+, it is recommended to use these versions:
+**Experiments requires you to use Offerings and have a dynamic paywall in your app that displays the current Offering for a given customer.** While Experiments will work with iOS and Android SDKs 3.0.0+, it is recommended to use these versions:
 
 | SDK          | Version |
 | :----------- | :------ |
@@ -52,10 +52,10 @@ If you meet these requirements, you can start using Experiments without any app
 
 **Implementation Overview**
 
-1. Create two offerings that you want to test (make sure your app displays the `current` offering.) You can skip this step if you already have the offerings you want to test.
-2. Create an Experiment and choose the two offerings to test.
+1. Create two Offerings that you want to test (make sure your app displays the `current` Offering.) You can skip this step if you already have the Offerings you want to test.
+2. Create an Experiment and choose the two Offerings to test.
 3. Run your experiment and monitor the results. There is no time limit on experiments, so stop it when you feel confident choosing an outcome. (Learn more about interpreting your results [here](doc:experiments-results-v1))
-4. Once you’re satisfied with the results you can set the winning offering, if any, as current manually.
+4. Once you’re satisfied with the results you can set the winning Offering, if any, as default manually.
 5. Then, you're ready to run a new experiment.
 
 ## Tips for Using Experiments
@@ -84,8 +84,8 @@ If you want to run another test, you must stop the one currently running. You ca
 
 ** Running a test with a control**
 
-Sometimes you want to compare a different offering to the one that is already current. If so, you can set one of the variants to the offering that is currently used in your app.
+Sometimes you want to compare a different Offering to the one that is already the default. If so, you can set one of the variants to the Offering that is currently used in your app.
 
 ** Run follow-up tests after completing one test**
 
-After you run a test and find that one offering won over the other, try running another test comparing the winning offering against another similar offering. This way, you can continually optimize for lifetime value (LTV). For example, if you were running a price test between a $5 product and a $7 product and the $7 offering won, try running another test between a $8 product and the $7 winner to find the optimal price for the product that results in the highest LTV.
+After you run a test and find that one Offering won over the other, try running another test comparing the winning Offering against another similar Offering. This way, you can continually optimize for lifetime value (LTV). For example, if you were running a price test between a $5 product and a $7 product and the $7 Offering won, try running another test between a $8 product and the $7 winner to find the optimal price for the product that results in the highest LTV.

docs_source/Tools/experiments-v1/experiments-results-v1.md

@@ -148,9 +148,9 @@ The results from your experiment can also be exported in this table format using
     "0-0": "What is included in the \"Other\" category in the product-level breakdown of my results?",
     "0-1": "If the customers enrolled in your experiment purchased any products that were not included in either the Control or Treatment Offering, then they will be listed in the \"Other\" category when reviewing the product-level breakdown of a metric.  \n  \nThis is to ensure that all conversions and revenue generated by these customers can be included when measuring the total revenue impact of one variant vs. another, even if that revenue was generated from other areas of the product experience (like a special offer triggered in your app).",
     "1-0": "Why do the results for one variant contain purchases of products not included in that variant's Offering?",
-    "1-1": "There are many potential reasons for this, but the two most common occur when (1) there are areas of your app that serve products outside of the Current Offering returned by RevenueCat, or (2) the offered Subscription Group on the App Store contains additional products outside of that variant's Offering.  \n  \nFor the first case, please check and confirm that all places where you serve Products in your app are relying on the Current Offering from RevenueCat to determiner what to display.  \n  \nFor the second case, we recommend creating new Subscription Groups on the App Store for each Offering so that a customer who purchases from that Offering will only have that same set of options to select from one when considering changing or canceling their subscription from Subscription Settings on iOS.",
+    "1-1": "There are many potential reasons for this, but the two most common occur when (1) there are areas of your app that serve products outside of the Current Offering returned by RevenueCat for a given customer, or (2) the offered Subscription Group on the App Store contains additional products outside of that variant's Offering.  \n  \nFor the first case, please check and confirm that all places where you serve Products in your app are relying on the Current Offering from RevenueCat to determiner what to display.  \n  \nFor the second case, we recommend creating new Subscription Groups on the App Store for each Offering so that a customer who purchases from that Offering will only have that same set of options to select from one when considering changing or canceling their subscription from Subscription Settings on iOS.",
     "2-0": "When I end an Experiment, what Offering will be served to the customers who were enrolled in that Experiment?",
-    "2-1": "When an Experiment is ended, all customers previously enrolled in it will be served the Current Offering the next time they reach a paywall in your app.",
+    "2-1": "When an Experiment is ended, all customers previously enrolled in it will be served the Default Offering the next time they reach a paywall in your app.",
     "3-0": "How can I review the individual transactions that have occurred in my experiment?",
     "3-1": "Our [Scheduled Data Exports](https://www.revenuecat.com/docs/scheduled-data-exports) include the experiment enrollment of each subscriber in the reported transactions, and by subscribing to them you can receive daily exports of all of your transactions to analyze the experiment results further."
   },