Docusaurus version bump to warn about broken anchors; other fixes (#2578

)

docs/docs/event-trackers/amplitude.mdx

@@ -6,7 +6,7 @@ slug: amplitude
 ---
 
 import DefaultInstructions from './_default-event-instructions.mdx'
-const { title, description, sidebar_label, slug } = frontMatter
+export const { title, description, sidebar_label, slug } = frontMatter
 
 # Amplitude Event Tracker Setup
 

docs/docs/event-trackers/clevertap.mdx

@@ -6,6 +6,6 @@ slug: clevertap
 ---
 
 import MissingEventTrackerDocs from './missing-event-tracker-docs.mdx'
-const { title, description, sidebar_label, slug } = frontMatter
+export const { title, description, sidebar_label, slug } = frontMatter
 
 <MissingEventTrackerDocs eventTracker="CleverTap" slug={slug} />

docs/docs/event-trackers/firebase.mdx

@@ -6,6 +6,6 @@ slug: firebase
 ---
 
 import MissingEventTrackerDocs from './missing-event-tracker-docs.mdx'
-const { title, description, sidebar_label, slug } = frontMatter
+export const { title, description, sidebar_label, slug } = frontMatter
 
 <MissingEventTrackerDocs eventTracker="Firebase" slug={slug} />

docs/docs/event-trackers/freshpaint.mdx

@@ -6,7 +6,7 @@ slug: freshpaint
 ---
 
 import DefaultInstructions from './_default-event-instructions.mdx'
-const { title, description, sidebar_label, slug } = frontMatter
+export const { title, description, sidebar_label, slug } = frontMatter
 
 # Freshpaint Event Tracker
 

docs/docs/event-trackers/fullstory.mdx

@@ -6,6 +6,6 @@ slug: fullstory
 ---
 
 import MissingEventTrackerDocs from './missing-event-tracker-docs.mdx'
-const { title, description, sidebar_label, slug } = frontMatter
+export const { title, description, sidebar_label, slug } = frontMatter
 
 <MissingEventTrackerDocs eventTracker="Fullstory" slug={slug} />

docs/docs/event-trackers/heap.mdx

@@ -6,6 +6,6 @@ slug: heap
 ---
 
 import MissingEventTrackerDocs from './missing-event-tracker-docs.mdx'
-const { title, description, sidebar_label, slug } = frontMatter
+export const { title, description, sidebar_label, slug } = frontMatter
 
 <MissingEventTrackerDocs eventTracker="Heap" slug={slug} />

docs/docs/event-trackers/jitsu.mdx

@@ -6,6 +6,6 @@ slug: jitsu
 ---
 
 import MissingEventTrackerDocs from './missing-event-tracker-docs.mdx'
-const { title, description, sidebar_label, slug } = frontMatter
+export const { title, description, sidebar_label, slug } = frontMatter
 
 <MissingEventTrackerDocs eventTracker="Jitsu" slug={slug} />

docs/docs/event-trackers/keenio.mdx

@@ -6,6 +6,6 @@ slug: keenio
 ---
 
 import MissingEventTrackerDocs from './missing-event-tracker-docs.mdx'
-const { title, description, sidebar_label, slug } = frontMatter
+export const { title, description, sidebar_label, slug } = frontMatter
 
 <MissingEventTrackerDocs eventTracker="KeenIO" slug={slug} />

docs/docs/event-trackers/mparticle.mdx

@@ -6,6 +6,6 @@ slug: mparticle
 ---
 
 import MissingEventTrackerDocs from './missing-event-tracker-docs.mdx'
-const { title, description, sidebar_label, slug } = frontMatter
+export const { title, description, sidebar_label, slug } = frontMatter
 
 <MissingEventTrackerDocs eventTracker="MParticle" slug={slug} />

docs/docs/event-trackers/snowplow.mdx

@@ -2,10 +2,10 @@
 title: Setting up Snowplow as an event tracker
 description: This document outlines the steps needed to add your Snowplow to GrowthBook.
 sidebar_label: Snowplow
-slug: Snowplow
+slug: snowplow
 ---
 
 import MissingEventTrackerDocs from './missing-event-tracker-docs.mdx'
-const { title, description, sidebar_label, slug } = frontMatter
+export const { title, description, sidebar_label, slug } = frontMatter
 
 <MissingEventTrackerDocs eventTracker="Snowplow" slug={slug} />

docs/docs/experimentation-analysis/data-source-configuration.mdx

@@ -5,6 +5,8 @@ sidebar_label: Data Source Configuration
 slug: /app/datasources
 ---
 
+import Anchor from '@site/src/components/Anchor'
+
 # Data Source Configuration
 
 ## Overview
@@ -100,7 +102,7 @@ SELECT user_id, device_id FROM logins
 
 #### SQL Templates
 
-We use {{[Handlebars](https://handlebarsjs.com/guide/#language-features)}} to compile the assignment sql, identity queries, etc. into what is actually called to your database.
+We use \{\{[Handlebars](https://handlebarsjs.com/guide/#language-features)\}\} to compile the assignment sql, identity queries, etc. into what is actually called to your database.
 
 You can use any of the in-built variables that Growthbook automatically sets:
 
@@ -120,7 +122,7 @@ You can also use any of the in-built helper functions:
 - **replace [str] [pattern] [replacement]** - Replace all occurences of a regular expression with something else. ex. `{{replace "My%%%Database!" "\[^a-zA-Z\]" ""}}` compiles to `MyDatabase`
 - **snakecase [str]** - ex. `{{pascalcase "My database"}}` compiles to `my_database`.
 - **uppercase [str]** - ex. `{{uppercase "My database"}}` compiles to `MY DATABASE`.
-  <a id="dateformat"/>
+  <Anchor id="dateformat"/>
 - **date [date]&nbsp;[format]** - Format an ISO date according to this [format](https://date-fns.org/v2.29.3/docs/format), being careful not to mix up months (MM) and minutes (mm). ex. `{{date startDateISO "yyyyMMdd"}}` might compile to `20230130`. The most common codes are:
 
 <ul>
@@ -156,7 +158,7 @@ WHERE
 
 :::note
 
-The inserted values do not have surrounding quotes, so you must add those yourself (e.g. use <code>'{{&nbsp;startDate&nbsp;}}'</code> instead of just <code>{{&nbsp;startDate&nbsp;}}</code>)
+The inserted values do not have surrounding quotes, so you must add those yourself (e.g. use `'{{&nbsp;startDate&nbsp;}}'` instead of just `{{&nbsp;startDate&nbsp;}}`)
 
 :::
 

docs/docs/experimentation-analysis/metrics.mdx

@@ -5,6 +5,8 @@ sidebar_label: Metrics
 slug: /app/metrics
 ---
 
+import Anchor from '@site/src/components/Anchor'
+
 # Metrics
 
 Metrics are what your experiments are trying to improve (or at least not hurt). GrowthBook has a very flexible and powerful way to define metrics.
@@ -81,7 +83,7 @@ When we go to conduct experiment analysis, any `user_id` that has a conversion i
 
 #### SQL Templates
 
-We use {{[Handlebars](https://handlebarsjs.com/guide/#language-features)}} to compile the sql into what is actually called to your database. This allows you to create template metrics that can be copied and reused by changing the variable values associate with the metrics.
+We use \{\{[Handlebars](https://handlebarsjs.com/guide/#language-features)\}\} to compile the sql into what is actually called to your database. This allows you to create template metrics that can be copied and reused by changing the variable values associate with the metrics.
 
 You can use the following user configurable variables within SQL templates:
 
@@ -106,7 +108,7 @@ You can also use any of the in-built helper functions:
 - **replace [str] [pattern] [replacement]** - Replace all occurences of a regular expression with something else. ex. `{{replace "My%%%Database!" "\[^a-zA-Z\]" ""}}` compiles to `MyDatabase`
 - **snakecase [str]** - ex. `{{pascalcase "My database"}}` compiles to `my_database`.
 - **uppercase [str]** - ex. `{{uppercase "My database"}}` compiles to `MY DATABASE`.
-  <a id="dateformat"/>
+  <Anchor id="dateformat"/>
 - **date [date]&nbsp;[format]** - Format an ISO date according to this [format](https://date-fns.org/v2.29.3/docs/format), being careful not to mix up months (MM) and minutes (mm). ex. `{{date startDateISO "yyyyMMdd"}}` might compile to `20230130`. The most common codes are:
 
 <ul>
@@ -138,7 +140,7 @@ WHERE
 
 :::note
 
-The inserted values do not have surrounding quotes, so you must add those yourself (e.g. use <code>'{{&nbsp;startDate&nbsp;}}'</code> instead of just <code>{{&nbsp;startDate&nbsp;}}</code>)
+The inserted values do not have surrounding quotes, so you must add those yourself (e.g. use `'{{&nbsp;startDate&nbsp;}}'` instead of just `{{&nbsp;startDate&nbsp;}}`
 
 :::
 

docs/docs/faq.mdx

@@ -77,7 +77,7 @@ So that means if you do 50 orders per week and that's the metric you are trying
 
 Yes! In fact, we recommend running many experiments in parallel in your application. Most A/B tests fail, so the more shots-on-goal you take, the more likely you are to get a winner. Running tests in parallel is a great way to increase your velocity.
 
-Now it's possible your experiments might have interaction effects, but these are actually pretty rare in practice. One example is if one test is changing the text color on a page and another test is changing the background color. Some users might see end up seeing black text on a black background, which is obviously not ideal. For these rare cases, you can use [Namespaces](/app/features#namespaces) to run mutually exclusive experiments.
+Now it's possible your experiments might have interaction effects, but these are actually pretty rare in practice. One example is if one test is changing the text color on a page and another test is changing the background color. Some users might see end up seeing black text on a black background, which is obviously not ideal. For these rare cases, you can use [Namespaces](/features/rules#namespaces) to run mutually exclusive experiments.
 
 As long as you apply a little common sense to avoid situations like the above, running multiple experiments has low risk and really high reward.
 

docs/docs/features/basics.mdx

@@ -53,7 +53,7 @@ There are three kinds of rules we support:
 
 - [**Forced Value**](/features/rules#forced-value) - use targeting attributes to assign a subset of users the same value
 - [**Percentage Rollout**](/features/rules#percentage-rollout) - use random sampling to roll out a feature to a percent of users
-- [**A/B Experiment**](/features/rules#experiment) - run a randomized A/B test between 2 or more feature values
+- [**A/B Experiment**](/features/rules#experiments) - run a randomized A/B test between 2 or more feature values
 
 For more information, see our page on [override rules](/features/rules).
 

docs/docs/kb/experiments/aa-tests.mdx

@@ -37,7 +37,7 @@ A/A tests are a low-risk approach to help ensure that your experiment is set up
 
 ### Problem: No traffic, incorrect metric values, or SRM errors (imbalanced traffic)
 
-For these errors, check our generic troubleshooting guide.
+For these errors, check our [troubleshooting guide](/kb/experiments/troubleshooting-experiments).
 
 ### Problem: Metrics show statistically significant lifts in the A/A test
 

docs/docs/kb/experiments/carryover-bias.mdx

@@ -44,7 +44,7 @@ In short, anything that causes users in an experiment analysis to not be randoml
 
 ### 1. Creating a new "Phase" to restart an experiment without re-randomizing
 
-In this case, carryover bias is best prevented by re-randomizing users whenever you restart an experiment — either by starting an entirely new experiment or choosing to "re-randomize", which is an option we provide in GrowthBook's SDKs. We provide specific guidance on when you should re-randomize users in GrowthBook as part of our ["Make Changes" flow](/app/experiment-configuration#making-changes-while-running).
+In this case, carryover bias is best prevented by re-randomizing users whenever you restart an experiment — either by starting an entirely new experiment or choosing to "re-randomize", which is an option we provide in GrowthBook's SDKs. We provide specific guidance on when you should re-randomize users in GrowthBook as part of our ["Make Changes" flow](/app/making-experiment-changes).
 
 ### 2. Manually restarting a new experiment with the same experiment key
 

docs/docs/kb/experiments/troubleshooting-experiments.mdx

@@ -68,19 +68,27 @@ If for some reason the Identifier in your data warehouse is different from your
 
 There are times where it might be beneficial to have the Hash Attribute differ from the Identifier Type. The consequence is that there may be minor traffic imbalance or Multiple Exposures, but you may be willing to accept some slippage in the 1:1 mapping between Identifier Type and Hash Attribute in order to more easily join experiment exposure data with metric data.
 
-For example, on client-side experiments with Google Analytics (GA4), you may wish to avoid flickering by hashing on some custom ID, like `gbuuid` as we suggest in our [docs](/guide/GA4-google-analytics#generating-your-own-id), and not wait for the IDs provided by GA4.
+For example, on client-side experiments with Google Analytics (GA4), you may wish to avoid flickering by hashing on some custom ID as we do in our [Script Tag SDK](https://docs.growthbook.io/lib/script-tag) and not wait for the IDs provided by GA4.
 
-While you could send this custom ID in your trackingCallback as we suggest in our [docs](/guide/GA4-google-analytics#generating-your-own-id), you may prefer to use GA4 identifiers as the Identifier Type instead, because they are already tracked with many of the other GA4 events that you are using as Metrics*.*
+While you could send this custom ID in your trackingCallback you may prefer to use GA4 identifiers as the Identifier Type instead, because they are already tracked with many of the other GA4 events that you are using as Metrics.
 
 ### Solution 4: Minimize Experiment targeting changes while running
 
 When you make changes to the targeting of an experiment or created a new phase without re-randomizing users, it's possible that the traffic to the experiment will become imbalanced. This is because the users who were already in the experiment may continue to be in the same variation at differing rates. Whenever creating a new phase, you should re-randomize traffic when possible, and only certain changes to an experiment's targeting conditions can be done without re-randomizing.
 
-You can read more about the [rules for changing experiment targeting](/app/experiment-configuration#making-changes-while-running) and [carryover bias](/kb/experiments/carryover-bias) in our documentation.
+You can read more about the [rules for changing experiment targeting](/app/making-experiment-changes) and [carryover bias](/kb/experiments/carryover-bias) in our documentation.
 
 If your experiment is suffering from these issues, unfortunately the only solution may be to restart the experiment (you can do this by creating a new phase and choosing to re-randomize traffic). Of course, some amount of bias and SRM may be preferable to throwing out your data, but this depends on the magnitude of the problem.
 
-## Problem 3: Metric averages don't look as expected
+## Problem 3: Multiple Exposures
+
+We default to allowing 1 percent of units (e.g. users) in an experiment have multiple exposures without raising a warning due to the fact that many experimenters have slight mismatches in hashing attributes and warehouse tracking that can cause minor errors. You can adjust this in your organization settings under Settings > General > Experiment Settings.
+
+If you have multiple exposure errors, the issue is fundamentally caused by a mismatch between the attribute that you are randomizing on (your "hash attribute") and the identifier being stored in your data warehouse. You can [read more about this problem and how to solve it here](#solution-3-ensure-the-hash-attribute-and-identifier-type-match).
+
+Another potential issue is that you made unsafe changes to your experiment targeting and randomization. We attempt to prevent this by having a curated flow for making changes, but we provide you with flexibility to make a whole host of changes that could result in multiple exposures if you choose to override our warnings. YOu can read more about our [rules for changing experiments while running here](/app/making-experiment-changes).
+
+## Problem 4: Metric averages don't look as expected
 
 It's important to ensure that the Metric values in the baseline and variation are what you would expect. This helps confirm that the Metrics are set up correctly and that they are joining properly to the Experiment Assignment Queries.
 

docs/docs/lib/java.mdx

@@ -106,7 +106,7 @@ For complete examples, see the [Examples](#code-examples) section below.
 The features JSON is equivalent to the `features` property that is returned from the SDK Connection endpoint.
 
 - You can read more [about features here](/app/features)
-- You can see an [example features JSON here](/app/api#the-sdk-endpoint)
+- You can see an [example features JSON here](/app/api#sdk-connection-endpoints)
 
 #### Attributes
 

docs/docs/overview.mdx

@@ -52,7 +52,7 @@ You can also change the value of a feature with **Override Rules**. The followin
 - **Percentage Rollout** - Use random sampling to roll out a new feature value to a percent of users
 - **A/B Experiment** - Run a controlled A/B test between 2 or more feature values
 
-All features for an environment are packaged together into a single JSON file. All you need to do is pass this into our [SDKs](/lib) along with [user targeting attributes](/app/features#targeting-attributes).
+All features for an environment are packaged together into a single JSON file. All you need to do is pass this into our [SDKs](/lib) along with [user targeting attributes](/features/targeting).
 
 Read more about [features here](/app/features).
 

docs/docs/running-experiments/url-redirects.mdx

@@ -5,6 +5,8 @@ sidebar_label: URL Redirects
 slug: /app/url-redirects
 ---
 
+import Pill from '@site/src/components/Pill';
+
 # URL Redirect Testing
 
 URL Redirect tests are an alternative to using the Visual Editor and are ideal for testing big changes or complete page redesigns.

docs/docs/statistics/overview.mdx

@@ -16,7 +16,7 @@ approaches based on your experimentation needs. You can choose between the two s
 Bayesian methods provides a few key advantages over frequentist approaches.
 
 First, they provide more intuitive results. Instead of p-values and confidence intervals, you get probabilities and distributions of likely outcomes.
-These values allow you to make staements like _"there’s a 95% chance this new button is better and a 5% chance it’s
+These values allow you to make statements like _"there’s a 95% chance this new button is better and a 5% chance it’s
 worse"_ while there is no direct analog in a frequentist framework.
 
 Second, Bayesian methods allow you to write down your prior knowledge about experiment effects to ensure that you do not

docs/docs/sticky-bucketing.mdx

@@ -45,7 +45,7 @@ Update your codebase to use a compatible SDK. Sticky Bucketing is currently supp
 
 You may use one of our built-in Sticky Bucketing Services or implement your own. We provide common drivers for browser-generated cookies, backend-generated cookies, browser LocalStorage, and Redis stores.
 
-For more information about setting up Sticky Bucketing at the SDK level, see the appropriate SDK documentation. For instance, see the [Javascript SDK - Sticky Bucketing documentation](/lib/js/#sticky-bucketing) for more information about setting up Sticky Bucketing in the Javascript SDK.
+For more information about setting up Sticky Bucketing at the SDK level, see the appropriate SDK documentation. For instance, see the [Javascript SDK - Sticky Bucketing documentation](/lib/js#sticky-bucketing) for more information about setting up Sticky Bucketing in the Javascript SDK.
 
 ### 3. Update your SDK Connections in the GrowthBook app
 

docs/docs/tools/cli.mdx

@@ -25,7 +25,7 @@ The GrowthBook CLI enables you to generate TypeScript types for working with the
 
 Run `growthbook features generate-types --help` for more info.
 
-See the [JavaScript SDK documentation → Strongly-typed feature definitions](/lib/js#strongly-typed-feature-definitions) for more information on working with typed features.
+See the [JavaScript SDK documentation](/lib/js#strict-typing) for more information on working with typed features.
 
 ### Profile management
 

docs/docs/warehouses/ms-sql-or-sql-server.mdx

@@ -6,6 +6,6 @@ slug: ms-sql-or-sql-server
 ---
 
 import MissingDatasourceDocs from './missing-datasource-docs.mdx'
-const { title, description, sidebar_label, slug } = frontMatter
+export const { title, description, sidebar_label, slug } = frontMatter
 
 <MissingDatasourceDocs datasource="MS SQL or SQL Server" slug={slug} />

docs/docs/warehouses/mysql-or-mariadb.mdx

@@ -6,6 +6,6 @@ slug: mysql-or-mariadb
 ---
 
 import MissingDatasourceDocs from './missing-datasource-docs.mdx'
-const { title, description, sidebar_label, slug } = frontMatter
+export const { title, description, sidebar_label, slug } = frontMatter
 
 <MissingDatasourceDocs datasource="MySQL or MariaDB" slug={slug} />

docs/docs/warehouses/postgres.mdx

@@ -6,6 +6,6 @@ slug: postgres
 ---
 
 import MissingDatasourceDocs from './missing-datasource-docs.mdx'
-const { title, description, sidebar_label, slug } = frontMatter
+export const { title, description, sidebar_label, slug } = frontMatter
 
 <MissingDatasourceDocs datasource="Postgres" slug={slug} />

docs/docs/warehouses/prestodb-or-trino.mdx

@@ -6,6 +6,6 @@ slug: prestodb-or-trino
 ---
 
 import MissingDatasourceDocs from './missing-datasource-docs.mdx'
-const { title, description, sidebar_label, slug } = frontMatter
+export const { title, description, sidebar_label, slug } = frontMatter
 
 <MissingDatasourceDocs datasource="Prestodb or Trino" slug={slug} />