Merge branch 'main' into brock-statsig-patch-6

docs/dynamic-config/introduction.md

@@ -6,13 +6,11 @@ slug: /dynamic-config
 
 ## What is a Dynamic Config?
 
-Dynamic config is a tool that replaces hard-coded values in your application with configuration parameters defined on the server. These configuration parameters can cover a wide range of properties in both your client-side and server-side code, such as button colors, feature toggles, or ranking configurations. This allows you to control the behavior of your application dynamically and in near real-time.
-
-However, it's important to note that the configuration will not automatically update on its own. You will need to manually refresh the config by calling `getConfig` again to apply any updates in your code.
+Dynamic configs replace hard-coded values in your application with JSON defined on the server. Statsig users leverage Dynamic Configs to avoid hard-coding configuration values of any kind in their code - and change it dynamically near real-time. You can also *target* Dynamic Configs, providing different experiences based on user attributes. These configuration parameters can include any property across your client-side or server-side application code, from button colors to ranking configurations.
 
 ## When to Use a Dynamic Config
 
-Dynamic config is especially useful when you want to make your server-side code the source of truth for application properties, allowing you to modify configurations without redeploying code. Many companies, like Spotify, leverage [Remote Configuration](https://engineering.atspotify.com/2020/10/29/spotifys-new-experimentation-platform-part-1/) to dynamically update client or backend service properties.
+Many technology companies use tools such as dynamic config to make their server-side code the source of truth for configurable application properties. For example, Spotify uses [Remote Configuration](https://engineering.atspotify.com/2020/10/29/spotifys-new-experimentation-platform-part-1/) to dynamically update properties of their clients or backend services.
 
 ### Examples of Use Cases:
 - **Feature Toggles**: Dynamically enable or disable features without code changes.

docs/guides/sidecar-experiments/introduction.mdx

@@ -1,6 +1,6 @@
 ---
 sidebar_label: Introduction
-title: Low-code (Sidecar) Experiments
+title: Sidecar Introduction (Low-code Experiments)
 ---
 
 A/B testing, or split testing, is a fundamental method in digital marketing for validating various strategies and website designs. It involves comparing two versions of a webpage to see which performs better with a target audience. 

docs/statsig-warehouse-native/introduction.mdx

@@ -1,5 +1,5 @@
 ---
-title: Getting Started with Statsig Warehouse Native
+title: Warehouse Native - Getting Started
 slug: /statsig-warehouse-native/introduction
 sidebar_label: Getting Started
 description: Set up your first Statsig Warehouse Native project
@@ -51,7 +51,7 @@ Warehouse Native shares core features with Statsig Cloud but focuses on specific
 
 If you’re unsure whether Statsig Warehouse Native or Statsig Cloud is a better fit for your experimentation needs, [reach out to our support team](mailto:[email protected]), and we'll help you decide.
 
-## How It All Works
+## How Warehouse Native Works
 
 Statsig Warehouse Native runs experimentation compute jobs directly in your data warehouse, using your existing datasets to calculate metrics and enrich experiment analysis based on your data.
 

sidebars.ts

@@ -649,7 +649,7 @@ const sidebars: SidebarsConfig = {
             },
             {
               type: "category",
-              label: "Low-code Experiments",
+              label: "Low-code (Sidecar)",
               items: [
                 "guides/sidecar-experiments/introduction",
                 "guides/sidecar-experiments/setup",