Frequently Asked Questions

The checkGateWithExposureLoggingDisabled api will return a gate evaluation without logging an exposure event. This is useful when you don't want to log exposures for users who may not reach the feature you're testing, but need to know their evaluation sooner to set things up.

Later, when the user reaches the feature, calling checkGate will return the same result and log an exposure event. Both checkGate and checkGateWithExposureLoggingDisabled will return the same result for a given user and gate.

Note that statsig sdks handle exposure logging by default because manual exposure logging can lead to an imbalance in exposure events. For example, only triggering exposures for users in the Test group of an experiment could imbalance the experiment.

Date of slack thread: 4/12/24

Anonymous:

Hi Statsig team, After adding `statsig-js: 4.52.0` in `package.json` for an Angular application, the unit tests started failing with: ```

Jest encountered an unexpected token Jest failed to parse a file. This happens e.g. when your code or its dependencies use non-standard JavaScript syntax, or when Jest is not configured to support such syntax. Out of the box Jest supports Babel, which will be used to transform your files into valid JS based on your Babel configuration. By default "node_modules" folder is ignored by transformers.

Here's what you can do:

• If you are trying to use ECMAScript Modules, see <https://jestjs.io/docs/ecmascript-modules> for how to enable it.

• If you are trying to use TypeScript, see <https://jestjs.io/docs/getting-started#using-typescript>

• To have some of your "node_modules" files transformed, you can specify a custom "transformIgnorePatterns" in your config.

• If you need a custom transformation specify a "transform" option in your config.

• If you simply want to mock your non-JS modules (e.g. binary assets) you can stub them out with the "moduleNameMapper" config option.

You'll find more details and examples of these config options in the docs: <https://jestjs.io/docs/configuration> For information about custom transformations, see: <https://jestjs.io/docs/code-transformation>

Details: /home/jferreira/git/omsurvey/aapps-ui-service/app/node_modules/statsig-js/node_modules/uuid/dist/esm-browser/index.js:1 ({"Object.&lt;anonymous&gt;":function(module,exports,require,__dirname,__filename,jest){export { default as v1 } from './v1.js'; ^^^^^^ SyntaxError: Unexpected token 'export' at Runtime.createScriptFromCode (node_modules/jest-runtime/build/index.js:1796:14) at Object.require (node_modules/statsig-js/dist/ErrorBoundary.js:43:14) ```

Statbot: It appears that Jest is having trouble parsing the `statsig-js` module because it contains ECMAScript Modules (ESM) syntax, which Jest may not be configured to handle by default. Here are some steps you can take to resolve this issue:

1. Transform ESM Modules: Ensure that your Jest configuration is set up to transform ESM modules. You may need to adjust the `transformIgnorePatterns` option to include the `statsig-js` package or use a custom transformer for ESM.

2. Babel Configuration: If you're using Babel, make sure that it is configured to transpile the ESM syntax. You might need to include the appropriate Babel plugins or presets that handle ESM.

3. Mocking: If the module does not need to be transformed for your tests to run, you can mock the `statsig-js` module using Jest's `moduleNameMapper` configuration option.

4. Check Jest Documentation: Refer to the Jest documentation for more details on how to handle ECMAScript Modules, TypeScript, and custom transformations (<https://jestjs.io/docs/configuration> and <https://jestjs.io/docs/code-transformation>).

If you've tried these steps and are still encountering issues, it might be helpful to look into the specific Jest and Babel configurations for your project. Since the error is related to Jest's handling of module syntax, the solution will involve configuring Jest and possibly Babel to properly handle the syntax used by the `statsig-js` package.

To create your own StableID for server-side experiments, follow these steps:

1. Generate a unique identifier on your server. This could be a UUID or any other form of unique ID that you prefer.

2. Store this ID in a cookie. You'll have access to this for future requests from the same device, and your client app can use this identifier as well

3. For every request, lookup this cookie value. Do steps (1) and (2) if it does not already exist.

4. Get that ID from the cookie, and set it as the customID on the StatsigUser object, so all event data and exposure checks tie back to the same user.

const userObj = {      customIDs: {          stableID: '<generated in your code or passed via cookie or via db lookup>'      }   }

If you want to use this identifier on the client side and override the auto generated stableID, you need to read the cookie value you set in (2), and override the stableID on the client SDK.

- Override the stableID in the client SDK by getting the value from the cookie and setting the overrideStableID parameter in StatsigOptions. If you are using a server SDK to bootstrap your client sdk:

- Set the stableID field on the StatsigUser object in the customIDs map when generating the initialize response from the SDK.

To retrieve currently active experiments using JavaScript in the browser console, you can use the Statsig.getExperiment or Statsig.getLayer methods. However, these methods require you to know the name of the experiment or layer. There is no documented method to retrieve all active experiments without knowing their names.

For group overrides, there is no documented method to retrieve group IDs directly. However, you can use the Statsig.overrideConfig method to override the value of a specific experiment for a specific user. Note that this override only applies locally and will not persist across sessions. Here is an example:

Statsig.overrideConfig("a_config_or_experiment_name", { key: "value" }, "a_user_id"); In this case, { key: "value" } should match the structure of the parameters for the experiment you're trying to override. There is no way to override groups directly using the name or ID of a group.

The Pro tier is structured on a usage-based pricing model, specifically focusing on the volume of events. It is not a flat rate per user but rather a cost that is determined by the number of events generated. The Pro tier is priced at $150 per month for up to 5 million events.

Beyond this threshold, additional events are billed at a rate of $50 per million events. Metered events are the key factor in this pricing structure and include any instance where a user is assigned to a feature gate or experiment, which is recorded as an 'exposure event.' These exposure events are deduplicated within certain time windows to ensure accurate billing For client-side SDKs, the deduplication window is one hour, and for server-side SDKs, it is one minute.

Additionally, custom events logged through the SDK, inbound integrations, or data warehouse rows are also counted as metered events.

The waitForInitialization option in the statsig-react sdk is used to delay the rendering of your application until the SDK has finished initializing. This ensures that the correct feature gate values are available when your components are rendered. If you're seeing users in the "uninitialized" group, it could mean that the SDK initialization is not yet complete when your application checks a feature gate, experiment, dynamic config, or layer.

If you set waitForInitialization false, you should get an uninitialized check, and then once SDK initialization completes, you should get another check with the actual value (assuming the network request was successful for initialization).

Alternatively, you can choose to bootstrap the statsig-react sdk and render a StatsigSynchronousProvider. This requires you to integrate a statsig server SDK on your backend to generate the values via the getClientInitializeResponse method, and then pass them to the client side so they are immediately available. Refer to the bootstrapping documentation for more information: https://docs.statsig.com/client/concepts/bootstrapping

When you make a change in the Statsig Console, such as updating a targeting rule, it is expected that the new rule may take around 10 seconds to propagate. This is in line with our Service Level Objective (SLO). While an instant update might be desirable, it's important to note that this slight delay typically has no real impact on key metrics and user experience.

In the context of feature gates, for example, if you open a feature for Mac users and later remove access for Mac users and make it available for Windows users, there will be a slight delay before the change is reflected for Mac users. This is due to the Time To Live (TTL) associated with any type of hosted service.

Note that these propagation times do not apply to large ID lists. ID list propagation time is 1 hour.