Requirements
The Ruby SDK requires Ruby version 2.5.0 or higher.Installation
Install the gem:Quick start
Tracking
Track experiment impressions
When a feature’s value is determined by an experiment (A/B test), you typically want to track that assignment event for later analysis. There are two ways to do this. First is by accessing all impressions at the end of a request:Track feature usage
GrowthBook can fire a callback whenever a feature is evaluated for a user. This can be useful to update 3rd party tools like NewRelic or DataDog. Provide a receiver that can receivedef on_feature_usage: (String _feature_key, FeatureResult _result) -> void. There’s a convenience class FeatureUsageCallback with a method you can override but you can provide your own.
Using with Rails
You can use the providedGrowthbook::FeatureRepository class along with the Rails cache to fetch features periodically within your usage limits. Here is a controller concern you can use:
ApplicationController:
growthbook: an instance of the GrowthBook SDK for the requestinit_feature_flags: a method intended to be used as abefore_actionhook, e.g.before_action :init_feature_flags
current_user that returns the currently-authenticated user, and that it responds to as_json to return a hash of the targeting attributes.
How this works:
- With each request, the
init_feature_flagsmethod is called. This creates a new instance ofGrowthbook::Context - When creating the context for the first time, features are fetched and cached in the Rails cache. Subsequent calls use the cached version until the cache expires.
- Developers can call methods on
growthbookin their controllers to use the GrowthBook SDK, e.g.growthbook.on?(:dark_mode).
Dev and QA helpers
For dev/QA it’s often useful to force specific feature values.Sticky Bucketing
Available starting in version 1.3.0 By default GrowthBook does not persist assigned experiment variations for a user. We rely on deterministic hashing to ensure that the same user attributes always map to the same experiment variation. However, there are cases where this isn’t good enough. For example, if you change targeting conditions in the middle of an experiment, users may stop being shown a variation even if they were previously bucketed into it. Sticky Bucketing is a solution to these issues. You can provide a Sticky Bucket Service to the GrowthBook instance to persist previously seen variations and ensure that the user experience remains consistent for your users. A sampleInMemoryStickyBucketService implementation is provided for reference, but in production you will definitely want to implement your own version using a database, cookies, or similar for persistence.
Sticky Bucket documents contain three fields
attributeName- The name of the attribute used to identify the user (e.g.id,cookie_id, etc.)attributeValue- The value of the attribute (e.g.123)assignments- A hash of persisted experiment assignments. For example:{"exp1__0":"control"}
db object:
Inline experiments
It’s also possible to directly run an experiment directly in code without going through a feature flag.Working with Encrypted features
You can learn more about SDK Connection Endpoint Encryption. Create aGrowthBook::Context with an encrypted payload and a decryption key:
encryptedFeatures instead of plain text on the property features. Here’s an example with networking:

