To initialize the client SDK in a way that doesn't retrieve unneeded configuration data for metrics only, you can use the statsig.initializeAsync
method. This method should be called with your user object, client key, and options. The important option to pass here is “initializeValues.” You should pass an empty object {}
to this option. This will instruct the SDK not to make a network request for values, and just to serve them from that empty object. You don't need to await the call, but if you did it should return immediately anyway. All the event logging APIs should work just fine, but you won't have values for any feature gate or experiment.
If you want a subset of data, that's definitely possible. We have something called “target apps” which allows you to associate a subset of your configs with a specific target app, and then associate an SDK key with a target app. That key will only fetch those configs with the same target app. More information on this can be found in the Target Apps documentation.
To manage rules for a dynamic config in Statsig, the Python SDK does not offer the functionality to set up these rules directly.
Instead, the management of dynamic config rules should be performed through the Statsig Console API. The Console API provides the capability to programmatically create and modify Dynamic configs, tests, and feature gates.
This allows for the automation of configurations and the integration of Statsig features into your development workflow. For detailed instructions on how to use the Console API, please refer to the official Statsig Console API documentation.
The Ruby Server SDK for Statsig is designed with an in-memory local cache to store configurations for gates and experiments. This cache enables the SDK to evaluate rules even in the event of Statsig service disruptions. The cache is updated by polling the Statsig server at a default interval of 10 seconds, which is configurable through the rulesets_sync_interval
initialization option.
The memory footprint of the cache is typically small, as it consists of a JSON string representing the configurations. However, developers should be cautious when using large ID lists for targeting, as this can significantly increase the size of the cached data and is generally not recommended.
It is important to note that the SDK does not cache user-specific assignments and parameters, but rather the configuration specifications. Monitoring application memory usage is always advisable to ensure efficient operation. For more detailed guidance on managing large ID lists and memory usage, refer to the official documentation.
In the Statsig React SDK, the useLayer
hook is utilized to obtain a Statsig Experiment, which is represented as a Layer. The allocatedExperimentName
is a property of this Layer object.
The allocatedExperimentName
is set as a hash of various display names for client-sdks. This is an expected behavior and not a bug in the SDK.
It's important to note that you should not need to access any of the properties on the Layer object directly. Instead, you should use the useLayer
and useExperiment
methods. You can refer to the Statsig documentation for more details on how to use these methods.
If you observe any unexpected behavior, it's recommended to review the experiment setup in the Statsig console. If everything appears correct there, the issue could be more technical in nature.
When using the Ruby SDK, the Statsig.initialize
method is the only operation that makes a network request. Once the initialization is complete, all other SDK operations, including checking gate values, are synchronous and do not make additional network requests.
The SDK fetches updates from Statsig in the background, independently of your API calls. This means that checking multiple gate values in your worker will not result in multiple API calls. Instead, gate and experiment checks trigger a lazy, batched exposure log, but nothing synchronous.
For more information about the server SDK approach, you can refer to this article about SDKs.
Yes, it is possible to check if a user was exposed to an experiment using the JavaScript SDK. However, it's important to note that the SDK methods will only show how users would be or have been allocated, not if they have actually been exposed to the experiment.
To get a list of users who have actually been exposed to an experiment, you can use the Daily Reports feature of the Statsig console API. This feature allows you to download lists of users that have been exposed to the experiment.
Additionally, you can navigate to the users page and type in a specific user ID. This will show the list of recent exposures. You can click on any of them, and it will show all the associated metadata, including the SDK type that was used for assignment.
For more detailed information, you can refer to the following documentation: Daily Reports | Statsig Docs.
In the Statsig PHP SDK, the dependency mockery/mockery
was initially included as a core dependency, which was not ideal for production environments.
To address this, the Statsig PHP SDK has been updated to move mockery/mockery
to a dev-dependency.
This change ensures that mockery/mockery
is not installed in production environments, adhering to best practices for dependency management. The update has been made in version 2.3.0 of the Statsig PHP SDK.
Developers looking to integrate this change can do so by updating their version of the Statsig PHP SDK to v2.3.0.
For more details on the release and the changes included, refer to the official release notes provided by Statsig at the following link: Statsig PHP SDK Release 2.3.0.
The error_callback
is a parameter in the initialize
method of the Ruby SDK that is triggered with an error message if the network request to initialize the SDK fails. This can be used for basic error handling.
Here is an example of how to use the error_callback
:
ruby Statsig.initialize(api_key, { data_adapter: Statsig::InMemoryDataAdapter.new, error_callback: lambda { |error| puts "Error: #{error}" } })
In this example, if the SDK fails to initialize due to a network request failure, the error_callback
will be triggered and the error message will be printed to the console.
You can also refer to the test case that verifies this behavior in the Ruby SDK's GitHub repository here.
Please note that the documentation is being updated to include this information for future reference.
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. It 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:
javascript 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.
Currently, there is no admin Command Line Interface (CLI) or Software Development Kit (SDK) specifically designed for creating and configuring gates and experiments in Statsig. However, you can use the Statsig Console API for these tasks.
The Console API documentation provides detailed instructions and examples on how to use it. You can find the introduction to the Console API. For specific information on creating and configuring gates, refer to this link.
While there are no immediate plans to build a CLI for these tasks, the Console API documentation includes curl command examples that might be helpful for developers looking to automate these tasks.
Please note that the Statsig SDKs are primarily used for checking the status of gates and experiments, not for creating or configuring them.
When multiple Node.js processes initialize the Statsig SDK simultaneously, they might all try to write to the file at the same time, which could lead to race conditions or other issues. To mitigate this, you can use a locking mechanism to ensure that only one process writes to the file at a time. This could be a file-based lock, a database lock, or another type of lock depending on your application's architecture and requirements.
Another approach could be to have a single process responsible for writing to the file. This could be a separate service or a designated process among your existing ones. This process would be the only one to initialize Statsig with the rulesUpdatedCallback
, while the others would initialize it with just the bootstrapValues
.Remember to handle any errors that might occur during the file writing process to ensure your application's robustness.
If you're using a distributed system, you might want to consider using something like Redis, which is designed to handle consumers across a distributed system. Statsig's Data Adapter is designed to handle this so you don't need to build this manually. You can find more information about the Data Adapter in the Data Adapter overview and the Node Redis data adapter.
However, for these types of cases, it's recommended to only have a single data adapter that is enabled for writes, so you don't run into concurrent write issues.If your company doesn't currently use Redis for anything else and you use GCP buckets for file storage, there's no need to adopt Redis. The data adapter is the latest supported way to accomplish what you're trying to do.
In terms of performance, startup time is the primary concern here. And write() performance to an extent, though if you limit that to a single instance that issues writes, they should be infrequent.
In the case of using both the front end and the back end SDKs in tandem, this is common. You can even use the server SDKs to bootstrap the client SDKs (so that there’s no asynchronous request back to statsig to get assignments). For more notes on resilience and best practices, you can refer to the Statsig reliability FAQs.
When using the useGate
hook in the React SDK, if the provider does not wait for initialization and useGate
is called before the initialization completes, it will return false on the initial read. However, once the client eventually initializes, it will cause a re-render of the component that is using the useGate
hook.
This re-render is triggered because the useGate
hook updates its state with the actual value of the gate once initialization is complete. It's important to note that this re-render will occur regardless of whether the gate value is true or false. The key point is that the state of the gate has updated, which triggers the re-render.
For handling loading states while the Statsig client initializes, you can use the isLoading
value. Once the Statsig client state changes, your component will be called again and you can handle the true/false gate state as desired. For more details, refer to the Statsig React SDK documentation.
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.
This error is likely to be thrown when we log internal used performance logging events. It's not related to events your service logged with log_event. A patch will be released to fix this issue.