A Context ties all SDK actions to a specific visitor. A unique visitor ID is required for deterministic bucketing -- as long as the ID stays the same, bucketing is consistent. On new experiments, ramping total traffic up or down keeps everyone in place too (see Bucketing Algorithm); a persistent DataStore preserves assignments across the config changes that do move visitors, such as re-weighting variations.

# visitor_attributes are copied defensively — later caller mutations don't leak in:
context = core.create_context(
    "user-unique-id",
    visitor_attributes={"country": "US", "language": "en"},
)

The first argument is the visitor's unique ID. The second is an optional object of initial visitor properties used for audience and segment evaluation.

Every context method that runs experiences or features accepts an optional attributes object. This table lists all supported properties:

# Per-call overlays are keyword-only and ephemeral. Visitor audiences via
# attributes=, location rules via location_attributes=. enable_tracking (default
# True) is also keyword-only — set it False to bucket without reporting the
# bucketing event. There is no inline updateVisitorProperties or typeCasting flag —
# use set_attributes() to persist visitor properties:
variation = context.run_experience(
    "experience-key",
    attributes={"plan": "pro"},
    location_attributes={"url": "/pricing"},
    enable_tracking=True,
)

Visitor properties are key-value pairs used in audience evaluation and segment matching. They can be set at context creation, updated later, or passed inline with any experience/feature call.

Permanently merges new properties into the visitor's existing properties.

Visitor properties can also be updated inline when calling any experience or feature method by setting updateVisitorProperties to true in the attributes:

The Ruby SDK has no inline updateVisitorProperties flag — pass per-call visitor properties for matching only, and call update_visitor_properties (above) when you want them persisted.

The iOS SDK has no mutable visitor-property API — attributes are fixed when the context is created (immutable for its lifetime). To change them, create a new context with the new attributes.

Custom segments represent audiences of type segmentation. Use runCustomSegments to evaluate segment rules against the current visitor context.

Parameters:

In Fullstack projects, segments do not persist unless you provide a DataStore. See the segments concept for more detail on how segmentation works.

Default segments are used for Convert reporting. Use setDefaultSegments to permanently update the visitor's default segments. Only the following properties are included in Convert Reports:

• browser
• devices
• source
• campaign
• visitorType
• country

# The method is set_segments(); each call shallow-merges into the stored default
# segments, kept strictly separate from visitor attributes:
context.set_segments({
    "country": "US",
    "browser": "chrome",
    "devices": "desktop",
})

Parameters:

You can look up any entity in the project configuration by its key or numeric ID.

# entity_type comes FIRST (opposite of the JS/PHP/Ruby order) and is a plain
# string — one of "experiences", "features", "goals", "audiences", "segments".
# Returns the entity mapping, or None on a normal miss (never raises):
experience = context.get_config_entity("experiences", "experience-key")

Parameters:

# get_config_entity_by_id also takes entity_type first, then the id. Returns the
# entity mapping, or None on a normal miss (never raises):
feature = context.get_config_entity_by_id("features", "feature-id")

Parameters:

Both methods return the matching entity object (or array in PHP), or null if not found.

The Ruby SDK resolves config entities by key only (get_config_entity(key, entity_type) with entity_type one of :experience, :feature, :goal); it has no by-ID variant.