Merge branch 'main' into update-mfa-in-docs

statsig-io · Nov 29, 2024 · 7b4d0db · 7b4d0db
2 parents bc5e679 + 579fd9e
commit 7b4d0db
Show file tree

Hide file tree

Showing 33 changed files with 268 additions and 110 deletions.
diff --git a/docs/azureai/capturing-metrics.mdx b/docs/azureai/capturing-metrics.mdx
@@ -6,7 +6,7 @@ import Tabs from "@theme/Tabs";
 import TabItem from "@theme/TabItem";
 
 
-AzureAI SDK automatically captures relevant invocation and usage metrics from each API call and logs them to Statsig.  You can see these events streaming in real-time in the console at: https://console.statsig.com/metrics/events.
+Azure AI SDK automatically captures relevant invocation and usage metrics from each API call and logs them to Statsig.  You can see these events streaming in real-time in the console at: https://console.statsig.com/metrics/events.
 
 ![image](https://github.com/user-attachments/assets/cb4136eb-6ae9-4ffa-b560-333f332eaa75)
 

diff --git a/docs/azureai/introduction.md b/docs/azureai/introduction.md
@@ -2,7 +2,11 @@
 title: Azure AI
 ---
 
-Statsig offers SDKs for integrating Azure AI models into server applications. These SDKs simplify the implementation of features like completions and embeddings in your server application. They provide easy-to-use APIs and automatically track metrics such as latency, token length, and model details, which you can use for optimization and experimentation.
+Statsig offers SDKs for integrating Azure AI models into server applications. These SDKs simplify the implementation of features like completions and embeddings in your server application. They provide easy-to-use APIs and automatically track metrics such as latency, token length, and model details, which you can use for optimization and experimentation. Use cases include:
+* Implement Azure AI Models in your code with a [single lightweight framework](/azureai/model-client)
+* [Stream completions](/azureai/completions) and [generate embeddings](/azureai/embeddings)
+* [Capture invocation and usage metrics](/azureai/capturing-metrics/) with no extra work
+* [Run A/B tests on parameters](/azureai/running-experiments) like model, prompt, temperature and more
 
 ![image](https://github.com/user-attachments/assets/b23c79c3-8501-4390-a3f3-3496970eb272)
 

diff --git a/docs/azureai/running-experiments.mdx b/docs/azureai/running-experiments.mdx
@@ -6,7 +6,7 @@ import Tabs from "@theme/Tabs";
 import TabItem from "@theme/TabItem";
 
 
-AzureAI SDK helps you easily and quickly run A/B tests to measure the effectiveness of different models and related parameters.  By leveraging Statsig's powerful stats engine, you can gain real-time insights into model performance, optimizing for metrics like cost, accuracy, and latency. This integration enables you to experiment with various configurations, such as model type, prompt settings, or response parameters, and make data-driven decisions to enhance your application's efficiency and user experience.
+Azure AI SDK helps you easily and quickly run A/B tests to measure the effectiveness of different models and related parameters.  By leveraging Statsig's powerful stats engine, you can gain real-time insights into model performance, optimizing for metrics like cost, accuracy, and latency. This integration enables you to experiment with various configurations, such as model type, prompt settings, or response parameters, and make data-driven decisions to enhance your application's efficiency and user experience.
 
 ## Example: Test GPT4o vs. GPT4o-mini
 

diff --git a/docs/client/deprecated/jsClientSDK.mdx b/docs/client/deprecated/jsClientSDK.mdx
@@ -1,6 +1,6 @@
 ---
-sidebar_label: JavaScript
-title: JavaScript Client SDK
+sidebar_label: (deprecated) statsig-js
+title: (deprecated) statsig-js client sdk
 slug: /client/deprecated/jsClientSDK
 ---
 

diff --git a/docs/client/deprecated/reactNativeExpoSDK.mdx b/docs/client/deprecated/reactNativeExpoSDK.mdx
@@ -1,6 +1,6 @@
 ---
-sidebar_label: React Native (Expo)
-title: React Native Expo Client SDK
+sidebar_label: (deprecated) statsig-react-native-expo
+title: (deprecated) statsig-react-native-expo client sdk
 slug: /client/deprecated/reactNativeExpoSDK
 ---
 

diff --git a/docs/client/deprecated/reactNativeSDK.mdx b/docs/client/deprecated/reactNativeSDK.mdx
@@ -1,9 +1,10 @@
 ---
-sidebar_label: React Native
-title: React Native Client SDK
+sidebar_label: (deprecated) statsig-react-native
+title: (deprecated) statsig-react-native client sdk
 slug: /client/deprecated/reactNativeSDK
 ---
 
+
 import Tabs from "@theme/Tabs";
 import TabItem from "@theme/TabItem";
 

diff --git a/docs/client/deprecated/reactSDK.mdx b/docs/client/deprecated/reactSDK.mdx
@@ -1,6 +1,6 @@
 ---
-sidebar_label: React
-title: React Client SDK
+sidebar_label: (deprecated) statsig-react
+title: (deprecated) statsig-react client sdk
 slug: /client/deprecated/reactSDK
 ---
 

diff --git a/docs/client/html-snippet.mdx b/docs/client/html-snippet.mdx
@@ -0,0 +1,38 @@
+---
+sidebar_label: HTML Snippet
+title: HTML Snippet SDK
+---
+
+import {
+  SDKDocsBuilder,
+  HOOK__SDKDocUpdate,
+} from "../sdks/_SDKDocsBuilder.mdx";
+
+import {
+  Repository,
+  FAQ,
+  StatsigUser,
+  StatsigOptions,
+} from "./Templates/index.mdx";
+
+import Install from "./html/_install.mdx";
+import Initialize from "./html/_initialize.mdx";
+import MoreFAQs from "./html/_faqs.mdx";
+
+export const Builder = SDKDocsBuilder({
+  sections: [
+    [
+      Repository,
+      {
+        repo: "https://github.com/statsig-io/js-client-monorepo",
+      },
+    ],
+  ]
+})
+
+export const toc = Builder.toc
+
+<>{Builder.result}</>
+<Install />
+<Initialize />
+
diff --git a/docs/client/html/_faqs.mdx b/docs/client/html/_faqs.mdx
@@ -0,0 +1,11 @@
+import GitHubEmbed from "@site/src/components/GitHubEmbed";
+
+#### I want to customize the initialization logic, can I do that?
+
+Yes, you can remove the client API key from the url and see the [Javascript SDK Getting Started Guide](https://docs.statsig.com/client/javascript-sdk#getting-started) for more information.  The HTML snippet is just our javascript SDK - providing an api key in the url will auto initialize an instance for you, but if you don't want that, you can use it just like the javascript SDK.
+
+You will need to create your own instance differently than if you were installing the sdk via npm:
+
+```js
+const client = new window.__STATSIG__.StatsigClient("client-test", { userID: "123"}, {});
+```
diff --git a/docs/client/html/_initialize.mdx b/docs/client/html/_initialize.mdx
@@ -0,0 +1,31 @@
+import GitHubEmbed from "@site/src/components/GitHubEmbed";
+
+### Initialize the SDK
+
+The HTML snippet we provide wraps an instance of the statsig javascript sdk.  Simply providing your client API key in the url is enough to auto initialize the SDK, as the installation step recommends.
+
+However, you should likely move to a manual initialization if you need any of the following:
+
+- custom user properties
+- custom initialization options
+- check gates, configs, experiments, or log events
+
+To manually initialize an instance of the sdk, remove the key parameter from the script tag, and do the following:
+
+
+```js
+const client = new window.__STATSIG__.StatsigClient(
+    "client-test",
+    { userID: "123"},  // StatsigUser
+    {},                // StatsigOptions
+);
+
+await client.initializeAsync();
+
+// check gates, configs, experiments, or log events
+```
+
+The `StatsigClient` instance you create is also available via `window.Statsig`, so you can reference it globally.
+
+At this point, you have access to all of the methods available in the [Javascript SDK](/client/javascript-sdk) via your instance of the `StatsigClient`.  Refer to that documentation for initialization details and core methods.
+
diff --git a/docs/client/html/_install.mdx b/docs/client/html/_install.mdx
@@ -0,0 +1,13 @@
+import Tabs from "@theme/Tabs";
+import TabItem from "@theme/TabItem";
+
+## Install the SDK
+
+You can install the Statsig SDK by putting a script tag in the head of your HTML file:
+
+```js
+<script src="https://cdn.jsdelivr.net/npm/@statsig/js-client@3/build/statsig-js-client+session-replay+web-analytics.min.js?apikey=YOUR_CLIENT_API_KEY">
+</script>
+```
+
+Note that you need to replace `YOUR_CLIENT_API_KEY` with your actual client API key from the [Project Settings > API Keys](https://console.statsig.com/api_keys).
diff --git a/docs/client/javascript-mono/MigrationFromOldJsClient.mdx b/docs/client/javascript-mono/MigrationFromOldJsClient.mdx
@@ -9,11 +9,20 @@ import TabItem from "@theme/TabItem";
 import GitHubEmbed from "@site/src/components/GitHubEmbed";
 
 The architecture and majority of the APIs in the updated SDK have been retained; however,
- modifications have been made to address common pitfalls, resolve existing issues, and streamline the SDK logic.
-
-Below is a list of identified breaking changes that will require manual refactoring:
-
-### Initialization
+ modifications have been made to address common pitfalls, resolve existing issues, and streamline the SDK logic, resulting in some breaking changes.
+
+## Breaking Changes
+* The SDK now offers both a synchronous and asynchronous [initialization](/client/javascript-sdk/migrating-from-statsig-js#initialization) and [updateUser](/client/javascript-sdk/migrating-from-statsig-js#updating-the-user) methods.
+* The "getConfig" method has [changed to "getDynamicConfig"](/client/javascript-sdk/migrating-from-statsig-js#getconfig-is-now-getdynamicconfig)
+* When Bootstrapping, you'll now have to [pass the hash parameter as 'djb2'](/client/javascript-sdk/migrating-from-statsig-js#bootstrapping)
+* The top-level static instance has moved to a static method, [StatsigClient.instance()](/client/javascript-sdk/migrating-from-statsig-js#static-instance)
+* Overrides have moved into their own package: [js-local-overrides](/client/javascript-sdk/migrating-from-statsig-js#overrides)
+* Parameters for GDPR compliance have [changed and been centralized](/client/javascript-sdk/migrating-from-statsig-js#gdpr)
+* The method to retrieve a stableID [has changed](/client/javascript-sdk/migrating-from-statsig-js#stableid-and-getstableid)
+* The structure of [cached values has changed](/client/javascript-sdk/migrating-from-statsig-js#cached-values), with implications on first-run experience
+* Several StatsigOptions [have changed](/client/javascript-sdk/migrating-from-statsig-js#legacy-statsigoptions)
+
+### Initialization 
 
 Previously, the SDK employed a single method for initialization. However, we have recognized that waiting for a method call during app startup can be impractical. Consequently, we have introduced two distinct initialization approaches: one synchronous and one asynchronous.
 

diff --git a/docs/client/javascript-mono/MigrationFromOldReact.mdx b/docs/client/javascript-mono/MigrationFromOldReact.mdx
@@ -8,6 +8,16 @@ import Tabs from "@theme/Tabs";
 import TabItem from "@theme/TabItem";
 import GitHubEmbed from "@site/src/components/GitHubEmbed";
 
+:::note
+
+Also refer to our [migration from js-client guide](/client/javascript-sdk/migrating-from-statsig-js), which lists other impacts on statsig-react installations.
+
+:::
+
+Breaking Changes:
+* Our [initialization pattern](/client/javascript-sdk/migrating-from-statsig-react#initialize) has changed, along with [waitForInitialization and initializeComponent](/client/javascript-sdk/migrating-from-statsig-react#waitforinitialization-and-initializingcomponent)
+* Bootstrapping has changed, now requiring a new hashing parameter: [Bootstrapping the StatsigClient](/client/javascript-sdk/migrating-from-statsig-react#bootstrapping-the-statsigclient)
+
 
 ### Initialize
 

diff --git a/docs/client/javascript-mono/_GettingStartedFastImpl.mdx b/docs/client/javascript-mono/_GettingStartedFastImpl.mdx
@@ -37,6 +37,12 @@ export const OptionalDepsToggle = () => {
     }
 }
 
+<br/>
+:::note
+
+Transitioning from our legacy Javascript SDKs? See migrating to [js-client](/client/javascript-sdk/migrating-from-statsig-js/) and [react-bindings](/client/javascript-sdk/migrating-from-statsig-react) for a list of breaking changes and recommended solutions.
+
+:::
 
 ## Getting Started
 

diff --git a/docs/data-warehouse-ingestion/data_mapping.mdx b/docs/data-warehouse-ingestion/data_mapping.mdx
@@ -30,7 +30,7 @@ Events that are emitted by your application to measure the ongoing impact of you
 
 
 #### Optional
-`
+
 | Column         | Description                      | Rules                                                                                                            |
 | -------------- | -------------------------------- | ---------------------------------------------------------------------------------------------------------------- |
 | event_value    | The value of the event           | STRING/VARCHAR. Length < 128 characters. Statsig will detect numeric values                                      |

diff --git a/docs/infrastructure/api_proxy/custom_proxy.md b/docs/infrastructure/api_proxy/custom_proxy.md
@@ -56,7 +56,7 @@ On your [AWS CloudFront console](https://console.aws.amazon.com/cloudfront/),
 You can use the following javascript code snippet in your Lambda@Edge function:
 
 ```javascript
-exports.handler = (event, context, callback) => {
+export const handler = async (event, context, callback) => {
   const request = event.Records[0].cf.request;
   request.headers.host[0].value = "api.statsig.com";
   return callback(null, request);

diff --git a/docs/pulse/export.md b/docs/pulse/export.md
@@ -26,6 +26,8 @@ There are three types of export:
    1. `<experiment\>_first_exposures.csv` - contains a list of users and their first exposure to the experiment. If this is the only file you are interested in, you can get this by exporting an "Exposures" report which will be much smaller in size.
    2. `<experiment\>_user_metrics.csv` - contains a list of experimental users, and their calculated metrics for each day they were enrolled in the experiment.
 
+The availability of these exports are subject to our retention policy.  We hold exposures data for up-to 90 days after an experiment is concluded.  We hold raw user-level metrics data for 90 days.
+
 ### Pulse Summary File Description - For Feature Gates
 
 

diff --git a/docs/server/concepts/monitoring.mdx b/docs/server/concepts/monitoring.mdx
@@ -42,8 +42,6 @@ The following interface methods are provided by the Statsig SDK to track various
 ### List of Metrics
 
 Below is a list of the primary metrics currently available in the SDK:
-All metrics are prefixed with `statsig.sdk`
-
 
 | **Metric Name**               | **Type**       | **Tags**                                          | **Description**                                                                                   |
 |-------------------------------|----------------|---------------------------------------------------|---------------------------------------------------------------------------------------------------|

diff --git a/docs/server/java/_install.mdx b/docs/server/java/_install.mdx
@@ -2,16 +2,20 @@
 
 To install the SDK, set the Maven Central repository in your `build.gradle`. You probably already have this for other dependencies.
 
-```swift
+```java
 repositories {
     mavenCentral()
 }
 ```
 
 Then add the dependency:
 
-```swift
+```java
 implementation 'com.statsig:serversdk:1.X.X' // replace with the most up to date version
+// For >v1.24.0 If you are not using streaming and want to reduce the package size you can:
+implementation 'com.statsig:serversdk:1.X.X' {
+    exclude(group = "io.grpc", module = "*") 
+}
 ```
 
 You can find the versions in the github releases of the [open source sdk repository](https://github.com/statsig-io/java-server-sdk/releases), or from the [maven central repository](https://mvnrepository.com/artifact/com.statsig/serversdk).

diff --git a/docs/server/node/upgrade_guide/v5ToV6UpgradeGuide.mdx b/docs/server/node/upgrade_guide/v5ToV6UpgradeGuide.mdx
@@ -58,11 +58,11 @@ We also embedded the compress encoding format we are using, right now we are onl
 **Changes**
 - Change cache key for config_specs from `statsig.cache` to 
 
- `statsig|v1/download_config_specs|{compressEncoding // plain text for now}|{SHA256HashedBase64(secretkey)}`
+ `statsig|/v1/download_config_specs|{compressEncoding // plain text for now}|{SHA256HashedBase64(secretkey)}`
 
 - Change cache key for get_id_list_sources from `statsig.id_lists` to be:
 
-`statsig|get_id_lists|{compressEncoding // plain text for now}|{SHA256HashedBase64(secretkey)}`
+`statsig|/v1/get_id_lists|{compressEncoding // plain text for now}|{SHA256HashedBase64(secretkey)}`
 
 - Change cache key for individual id list to be 
 
@@ -92,7 +92,7 @@ If you need SHA256 for specific reasons, set `ClientInitializeResponseOptions.ha
 **Context**
 We have seen many confusions over environment tier 
 **Changes**
-If no environment tier is being set, e.g `StatsigOptions.environment.tier`, SDK will be auto-set to be production.
+If no environment tier is being set, e.g `StatsigOptions.environment.tier`, SDK now has a default value assigned to it. Default value will be your sdk key if it's being set. Otherwise default to production
 
 **Migration**
 Notes: If you have call-site which does not set environment tier, for rules which have non-production env tier, it will be failing now.

diff --git a/docs/stats-engine/methodologies/winsorization_variants/warehouse.mdx b/docs/stats-engine/methodologies/winsorization_variants/warehouse.mdx
@@ -1,4 +1,4 @@
 Statsig Warehouse Native lets you configure this per metric - and choose explicitly the upper and/or lower bounds to apply.
 ![image](https://github.com/statsig-io/docs/assets/31516123/6d058842-27f7-4b6b-9bd8-245a5f894f90)
 
-Winsorization is applied to to sum and event count metrics. Winsorization will not be applied to Mean, Ratio, Funnel or Participation.
+Winsorization is applied to to sum, event count, mean and ratio metrics. 
diff --git a/docs/stats-engine/variance-reduction.md b/docs/stats-engine/variance-reduction.md
@@ -30,15 +30,15 @@ Extending this observation, the more correlated the pre-experiment information i
 ### Where CUPED is less effective
 
 - CUPED does not work on new users, because there is not pre-exposure data to leverage
-- CUPED will not be applied historically for newly created metrics, or metrics that were added to Key Metrics partway through an experiment, but will be calculated for exposed users after the metric is added
 - CUPED is less effective if a user's metric value is uncorrelated with historical behavior
+- On Statsig Cloud : CUPED will not be applied historically for newly created metrics, or metrics that were added to Key Metrics partway through an experiment, but will be calculated for exposed users after the metric is added.
 - CUPED is applied to common metric types, but not all. Today, funnel metrics, ratio metrics, and "event user" metrics (# users who had an event 1+ time in a given time window) are CUPED-ineligible. We're working on rolling CUPED out to more metric types. 
 
 ## Winsorization
 
 Another common technique for reducing noise is Winsorization, which is a way to manage the influence of outliers.
 
-Winsorization refers to the practice of measuring the percentile _P<sub>x</sub>_ of a metric and setting all values over _P<sub>x</sub>_ to _P<sub>x</sub>_. At Statsig, the default percentile for winsorization is 99.9%. This reduces the influence of extreme outliers caused by factors such as logging errors or bad actors.
+Winsorization refers to the practice of measuring the percentile _P<sub>x</sub>_ of a metric and setting all values over _P<sub>x</sub>_ to _P<sub>x</sub>_. At Statsig, the default percentile for winsorization is 99.9%. This reduces the influence of extreme outliers caused by factors such as logging errors or bad actors. ([learn more](https://docs.statsig.com/stats-engine/methodologies/winsorization/))
 
 ## Literature