Do NOT embed your Server Secret Key in client-side applications, or expose it in any external-facing documents. However, if you accidentally expose it, you can create a new one in the Statsig console.
# Or, if you want to initialize with certain optionsoptions = StatsigOptions.new({'tier' => 'staging'}, network_timeout: 5)# And a callback when the initialization network request fails def error_callback(e) puts e end...Statsig.initialize('server-secret-key', options, method(:error_callback))
Initializing Statsig in a Rails application
If your application is using Rails, you should initialize Statsig in config/initializers/statsig.rb:
ruby
Statsig.initialize('server-secret-key', options)
Initializing Statsig when using Unicorn, Puma, Passenger, or Sidekiq
For Unicorn, you should initialize Statsig within an after_fork hook in your unicorn.rb config file:
ruby
after_fork do |server,worker| Statsig.initialize('server-secret-key', options)end
For Puma, you should initialize Statsig within an on_worker_boot hook in your puma.rb config file:
ruby
on_worker_boot do Statsig.initialize('server-secret-key', options)end
For Passenger, you should initialize Statsig in your config.ru config file:
ruby
if defined?(PhusionPassenger) PhusionPassenger.on_event(:starting_worker_process) do |forked| Statsig.initialize('server-secret-key', options) endend
For Sidekiq, you should initialize Statsig in your sidekiq.rb/server configuration file:
ruby
Sidekiq.configure_server do |config| config.on(:startup) do Statsig.initialize end config.on(:shutdown) do Statsig.shutdown endend
If you are using Rails in combination with any of the above, initialize using the specific process lifecycle hooks exposed by the respective tool. You can initialize in multiple places to ensure the SDK is fully usable, including all background processing.
initialize performs a network request. After initialize completes, virtually all SDK operations are synchronous (refer to Evaluating Feature Gates in the Statsig SDK). The SDK fetches updates from Statsig in the background, independently of API calls.
Working with the SDK
Checking a Feature Flag/Gate
After the SDK is initialized, you can check a Feature Gate. Feature Gates create logic branches in code that can be rolled out to different users from the Statsig Console. Gates are always CLOSED or OFF (return false;) by default.All APIs require you to specify the user (refer to Statsig user) associated with the request. For example, to check a gate for a user:
ruby
user = StatsigUser.new({'userID' => 'some_user_id'})if Statsig.check_gate(user, 'use_new_feature') # Gate is on, enable new featureelse # Gate is offend
Reading a Dynamic Config
Feature Gates work well for simple on/off switches with optional user targeting. To send a different set of values (strings, numbers, and so on) to clients based on specific user attributes such as country, use Dynamic Configs. The Dynamic Config API is similar to Feature Gates, but returns a full JSON object configured on the server, from which you can fetch typed parameters.
ruby
config = Statsig.get_config(user, 'awesome_product_details')# The 2nd parameter is the default value to be used in case the given parameter name does not exist on# the Dynamic Config object. This can happen when there is a typo, or when the user is offline and the# value has not been cached on the client.item_name = config.get('product_name', 'Awesome Product v1');price = config.get('price', 10.0);shouldDiscount = config.get('discount', false);# Or just get the whole json object backing this config if you preferjson = config.value
Getting a Layer/Experiment
Use Layers/Experiments to run A/B/n experiments. Two APIs are available, but Statsig recommends layers for faster iterations with parameter reuse.
ruby
# Values via getLayerlayer = Statsig.get_layer(user, "user_promo_experiments")title = layer.get("title", "Welcome to Statsig!")discount = layer.get("discount", 0.1)# or, via getExperimenttitle_exp = Statsig.get_experiment(user, "new_user_promo_title")price_exp = Statsig.get_experiment(user, "new_user_promo_price")title = title_exp.get("title", "Welcome to Statsig!")discount = price_exp.get("discount", 0.1)...price = msrp * (1 - discount)
Logging an Event
To track custom events and measure how features or experiment groups affect those events, call the Log Event API. Specify the user and event name to log, and optionally provide a value and metadata object:
For more about identifying users, group analytics, and best practices, go to the logging events guide.
Statsig User
When calling APIs that require a user, pass as much information as possible to take advantage of advanced gate and config conditions (like country or OS/browser level checks), and to correctly measure the impact of your experiments on your metrics/events. At least one identifier (userID or customID) is required to provide a consistent experience for a given user. Refer to userID requirements for more detail.
In addition to userID, email, ip, userAgent, country, locale, and appVersion are available as top-level fields on StatsigUser. You can also pass any key-value pairs in an object/dictionary to the custom field to create targeting based on them.
Typing on the StatsigUser object is lenient: you can pass numbers, strings, arrays, objects, and even enums or classes. However, evaluation operators only work on primitive types, mostly strings and numbers. The SDK attempts to cast custom field types to match the operator, but evaluation results for other types are not guaranteed. For example, an array set as a custom field is only compared as a string: there is no operator to match a value within that array.
Private Attributes
To keep sensitive user PII data out of logs, use the privateAttributes field on the StatsigUser object. This field accepts an object/dictionary of private user attributes. Any attribute set in privateAttributes is used only for evaluation/targeting and is removed from all logs before Statsig sends them to its servers.
For example, if a feature gate should only pass for users with emails ending in "@statsig.com", but you don't want to log email addresses to Statsig, add the key-value pair { email: "my_user@statsig.com" } to privateAttributes on the user.
Statsig Options
initialize() takes an optional options parameter in addition to the secret key to customize the Statsig client. Available options:
environment: Hash, default nil
a Hash you can use to set environment variables that apply to all your users in the same session, used for targeting purposes.
The most common usage is to set the "tier" (string), and have feature gates pass/fail for specific environments. The accepted values are "production", "staging" and "development", e.g. StatsigOptions.New({ 'tier' => 'staging' }).
The interval (in seconds) to poll for changes to your Statsig configuration
idlists_sync_interval: Number, default 60
The interval (in seconds) to poll for changes to id lists
disable_rulesets_sync: Boolean, default false
Disable background syncing for rulesets
disable_idlists_sync: Boolean, default false
Disable background syncing for id lists
logging_interval_seconds: Number, default 60
How often to flush logs to Statsig
logging_max_buffer_size: Number, default 1000, can be set lower but the server drops anything over 1000
The maximum number of events to batch before flushing logs to the server
local_mode: Boolean, default false
Restricts the SDK to not issue any network requests and only respond with default values (or local overrides)
bootstrap_values: String, default nil
A string that represents all rules for all feature gates, dynamic configs and experiments. It can be provided to bootstrap the Statsig server SDK at initialization in case your server runs into network issue or Statsig server is down temporarily.
rules_updated_callback: function, default nil
A callback function called whenever the rulesets update
data_store: IDataStore, default nil
A class that extends IDataStore. Can be used to provide values from a common data store (like Redis) to initialize the Statsig SDK.
idlist_threadpool_size: Number, default 3
The number of threads allocated to syncing IDLists
logger_threadpool_size: Number, default 3
The number of threads allocated to posting event logs
Statsig utilizes Sorbet (https://sorbet.org) to ensure type safety of the SDK. This includes logging to console when errors are detected. You can disable this logging by setting this flag to true.
network_timeout: Number, default nil
Maximum number of seconds to wait for a network call before timing out
post_logs_retry_limit: Number, default 3
Number of times to retry sending a batch of failed log events
The number of seconds, or a function that returns the number of seconds based on the number of retries remaining which overrides the default backoff time between retries
A storage adapter for persisted values. Can be used for sticky bucketing users in experiments. Implements Statsig::Interfaces::IUserPersistentStorage.
Shutdown
To gracefully shutdown the SDK and ensure all events are flushed:
ruby
Statsig.shutdown
Client SDK bootstrapping
The Statsig server SDK can generate the initialization values for a client SDK. This is useful for server-side rendering (SSR) or when you want to pre-fetch values for a client.
These only apply locally - they don't update definitions in the Statsig console or elsewhere.
The local override API isn't designed to be a full mock. It's only a convenient way to override the value of the gate/config/etc.
Manual Exposures
Statsig SDKs automatically log an exposure event every time a gate/experiment/config is checked. In some scenarios, you may want to control when to log an exposure.
Gates
ruby
result = Statsig.check_gate(user, 'a_gate_name', CheckGateOptions.new(disable_log_exposure: true))
User Persistent Storage is a storage adapter for running sticky experiments that persists user assignments across sessions.
Interface
ruby
class IUserPersistentStorage def load(key) nil end def save(key, data) endend
Example Implementation
ruby
class DummyPersistentStorageAdapter < Statsig::Interfaces::IUserPersistentStorage attr_accessor :store def initialize @store = {} end def load(key) return nil unless @store&.key?(key) @store[key] end def save(key, data) @store[key] = data endend
Multi-instance usage
To create multiple independent instances of the Statsig SDK (for example, to use different API keys or configurations), use the instance-based approach:
Starting in v1.12.0+, the Ruby SDK supports localMode and overrides. Refer to Local Overrides.
localMode is a boolean parameter in StatsigOptions when initializing the SDK. It restricts all network traffic, so the SDK operates offline and only returns default or override values.
Can I generate the initialize response for a client SDK using the Ruby server SDK?