Context Factors
User and session attributes that enable personalized variant selection with contextual multi-armed bandits.
Context factors are attributes about the user or their session that the model uses to personalize variant selection. They describe who the user is, not what they see -- that is the job of design factors.
Context factors are only relevant when using a CMAB (contextual bandit) model. A standard MAB ignores context and treats all users the same.
How context factors work
With a CMAB, the model learns the relationship:
P(reward | context, variant)In plain terms: given what we know about this user (context), which variant is most likely to produce a reward?
For example, if country is a context factor and headline is a design factor, the model might learn:
- Users where
country = "DE"convert best withheadline = "Kostenlos starten" - Users where
country = "US"convert best withheadline = "Boost your revenue"
This personalization emerges from the data. You define the factors; the model discovers the patterns.
Defining context factors
Each context factor has:
- A name -- a descriptive identifier like
country,device_type, ortraffic_source. - A data type -- either
strorbool. - Predefined levels -- the set of values the factor can take. Unlike design factors, these represent the user segments you expect to see in your data.
| Context Factor | Type | Levels |
|---|---|---|
country | str | "US", "DE", "UK", "FR" |
device_type | str | "desktop", "mobile", "tablet" |
is_returning_user | bool | true, false |
When requesting a variant from the SDK or API, you pass the current user's context values. The model uses them to pick the best variant for that specific user.
When to use context factors
Use context factors when you believe the optimal variant differs across user segments. Common examples:
- Geography -- different markets respond to different messaging.
- Device type -- mobile users may prefer shorter headlines or different layouts.
- Traffic source -- users from paid ads may have different intent than organic visitors.
- User segment -- new vs returning users, free vs paid tier.
If you do not expect meaningful variation across user segments, use a standard MAB model without context factors. It will converge faster.
Practical considerations
- More context factors require more data. Each context factor subdivides your user base. With
country(4 levels) anddevice_type(3 levels), the model is effectively learning across 12 segments. Each segment needs enough observations to produce reliable estimates. - Keep factors meaningful. Only include context factors where you have a genuine hypothesis that the optimal variant differs across segments. Adding noise dimensions slows convergence without improving results.
- Levels must be predefined. The model needs to know the possible values upfront. High-cardinality fields (like user ID or session ID) are not suitable as context factors. Bucket them into meaningful categories first.
- Missing context is handled gracefully. If a context value is not provided at serving time, the model falls back to its overall best estimate, similar to what a MAB would do.
Context factors vs design factors
| Design Factors | Context Factors | |
|---|---|---|
| What they represent | What the user sees (the variant) | Who the user is (their attributes) |
| Controlled by | Levered (assigns the variant) | The environment (observed, not assigned) |
| Used in | MAB and CMAB | CMAB only |
| Example | headline, cta_text, layout | country, device_type, is_new_user |