To initialize the client SDK in a way that doesn't retrieve unneeded configuration data for metrics only, you can use the statsig.initializeSync
method. This method should be called with your user object, client key, and options. All the event logging APIs should work just fine, but you won't have the most up to date values for any feature gate or experiment.
If you want a subset of your gates/experiments, you'll still want to await the asynchonrous initialization, but you will need to add a “target app” to your configs and to the SDK key in question. That key will only fetch those configs with the same target app. More information on this can be found in the Target Apps documentation.
If you want to use both the javascript client and react SDK, we recommend the new @statsig
/js-client
and @statsig/react-bindings
libraries
These libraries ensure separation between multiple instances of a StatsigClient, and allow you to use both the react hooks syntax and core javascript sdk.
See https://docs.statsig.com/client/javascript-sdk/react for more.
You can use the JavaScript SDK to determine which group a user is assigned to by using the getExperiment
API (or getExperimentWithExposureLoggingDisabled
if you need to check without triggering an exposure that would enroll the user into the experiment).
If you are trying to determine if a user has been exposed in the past, our SDKs are not able to return that information. While the SDKs deterministically can return an allocation result that is stable for the user and experiment, they are not historically aware of evaluation results.
For more information, read how bucketing works in Statsig SDKs.
Alternatively, there is an API that returns this information in the form of a daily report. Our data pipelines are aware of historical user assignments, so you can download that information via the Daily Reports Console API endpoint.
In the Statsig React SDK, you can use the initCompletionCallback
option during the SDK initialization to verify if the initialization was successful within a specified timeframe. This callback is invoked when the initialization process is completed, but before the provider re-renders the app. Therefore, it is useful for metadata collection on timing and success rates, but it is not a hook for triggering checks to gates or other entities. The initCompletionCallback
provides three parameters: initDurationMs
, success
, and message
.
If the initialization was not successful within the specified timeframe, the success
parameter would be false
and the message
parameter would provide additional information.
Here's an example of how to use it:
statsig.initialize('<CLIENT_SDK_KEY>', user, {
initCompletionCallback: (initDurationMs, success, message) => {
if (success) {
console.log('Statsig has been initialized successfully.');
} else {
console.log('Statsig initialization failed:', message);
}
},
});
Please note that this option is supported in v4.13.0+ of the JavaScript SDK. For more information, you can refer to the Statsig JavaScript SDK documentation under Options.
Typically, the latency for handling initialize
calls is in the range of 200 milliseconds to 1 second.
It is important to note that project size can influence initialization time, particularly when using large ID list based segments, which require downloading during the initialization phase. The quoted initialization time does not include any large ID list segments.
To reduce latency and improve redundancy, you can implement a Data Store (Data Adapter)
When you encounter the error statsigSDK> Event metadata is too large (max 4096). Some attributes may be stripped.
in your logs, it indicates that the size of the metadata for a particular event has exceeded the maximum limit of 4096 characters when stringified. This limit is set by Statsig to ensure efficient data handling.
To resolve this issue, you should review the events you're logging and the associated metadata. You might be logging more information than necessary or there could be large data structures being included unintentionally. If you're unsure about what metadata is being sent, you can add debugging statements in your code to print out the metadata before it's sent to Statsig. This will help you identify any unusually large pieces of data. Once you've identified the cause, you can then modify your logging to reduce the size of the metadata. The goal is to log only the information that is necessary for your metrics and analyses.
Event metadata is usually included to filter your Metrics during analysis and define more contextual metrics. The topic of event-metadata and this limit are covered in the Statsig documentation.
When deploying to an environment in Statsig, if you encounter an issue where the RULE
is always Default
and the REASON
is Unrecognized
, it typically means that the SDK was initialized, but the config or feature gate you're trying to evaluate did not exist in the set of values. This could be due to a few reasons:
1. The feature gate or dynamic config you're trying to evaluate does not exist or is not correctly spelled in your code. Please double-check the spelling and case-sensitivity.
2. The SDK might not have been able to fetch the latest rules from the Statsig server. This could be due to a transient network issue. If so, restarting the client or server should fix it, or waiting for a server SDK to poll for updates (by default, every 10 seconds).
3. The Target App you added to the SDK key you are initializing with may not be set on the gate/config/experiment/layer you are checking in your application. If you are using target apps, be double check that the target application on the entity you are checking matches the target application on the SDK key.
4. The gate has no rules in it. Gates return false by default, so a gate with no rules always returns false. Checking a gate that does not exist also returns false. As an optimization, we've removed gates which do not exist from the payload to sdks. So you may see an "Unrecognized" check if the gate has no rules (and therefore returns false anyway)
If you're still having trouble, please provide more details about your setup and the issue, and ask in the Statsig Slack Community.
In the event of encountering unexpected diagnostic results when evaluating a gate on React Native, despite the gate being set to 100% pass and Statsig being initialized, there are several potential causes to consider.
The "Uninitialized" status in evaluationDetails.reason
can occur even after calling .initialize()
and awaiting the result. This issue can be due to several reasons:
1. **Ad Blockers**: Ad blockers can interfere with the initialization network request, causing it to fail.
2. **Network Failures**: Any network issues that prevent the initialization network request from completing successfully can result in an "Uninitialized" status.
3. **Timeouts**: The statsig-js SDK applies a default 3-second timeout on the initialize request. This can lead to more frequent initialization timeouts on mobile clients where users may have slower connections.
If you encounter this issue, it's recommended to investigate the potential causes listed above. Check for the presence of ad blockers, network issues, and timeouts. This will help you identify the root cause and implement the appropriate solution.
If you're still experiencing issues, you can check the diagnostics tab for higher-level pass/fail/bucketing population sizes over time. For debugging specific checks, the logstream at the bottom is useful and shows both production and non-production exposures in near real-time. You can also use the Users tab to see historical evaluation results for a given ID.
One potential solution to this issue is to use the waitForInitialization
option. When you don’t use this option, any of your components will be called immediately, regardless of if Statsig has initialized. This can result in 'Uninitialized' exposures. By setting waitForInitialization=true
, you can defer the rendering of those components until after statsig has already initialized. This will guarantee the components aren’t called until initialize has completed, and you won’t see any of those ‘Uninitialized’ exposures being logged. You can find more details in the SDK documentation.
You can also verify the initialization by checking the value of isLoading
from useGate
and useConfig
and also initialized
and initStarted
from StatsigContext
. If the issue persists, please reach out to the Statsig team for further assistance.