Context app embed
Enable the app embed
Setting up Context is easy. After installation, enable the app embed to swap content variations in real-time.
Don’t forget to hit save!
Clicking “Install app embed” redirects you to your theme with the app embed enabled. Remember to hit “Save”!
Loading Strategy
The Loading Strategy controls when Context applies variations during page load and how those variations are introduced to the rest of the page.
When a webpage loads, it makes an important announcement called DOMContentLoaded. This announcement tells every interactive element on the page – menus, dropdowns, sliders, scripts – that it’s time to wake up and start working.
Context needs to make sure your variations are present before those elements start reacting. The Loading Strategy determines how Context handles that announcement so everything stays in sync.
There are three options
- Redispatch - (current default) Think of it like a school assembly. The principal makes the "morning announcements" before Context arrives. Context then asks the principal to repeat the announcements so our new students (the variations) hear them too. The problem? All the original students hear the announcements twice and some of them react twice - like the kid who's been told to stand up when their name is called, and now stands up, sits down, and stands up again.
- Intercept and queue - (recommended solution) Context arrives early and asks the principal to wait before making announcements. Once our new students are seated, the principal makes the announcements once, and everyone hears them together. No double-reactions.
- Disabled - Context doesn't interfere with announcements at all. Great for compatibility, but our new students might miss important information they needed to hear.
Choosing the Right Strategy
If you’re unsure which option to use:
- Start with Intercept and Queue for the safest, most consistent behaviour
- Use Redispatch only if your site depends on the default browser behaviour
- Use Disabled when diagnosing issues or working with highly constrained environments
Rule Caching
Rule Caching controls how often Context reevaluates recipe rules for returning visitors. When a visitor first matches a recipe, their rule results are cached to ensure a consistent experience and improve performance.
You can configure how long these results are cached, from 1 to 24 hours. During this time, returning visitors will continue to see the same personalized experience, even if the underlying rules change, unless their context changes.
Once the cache duration expires, Context reevaluates the visitor’s rules using their latest context and applies any new matching variations.
This setting is useful when you want to balance personalization accuracy with stability, such as avoiding frequent experience changes during short return visits.
Important: Time-based rules are only considered if they exist when a visitor’s rules are first evaluated. If a new time-based rule is added during the cache window, returning visitors will not see it until their cache expires, while new visitors will.
Allow multiple recipes to apply
This setting determines whether one or multiple personalization recipes can apply to a single visitor.
When enabled, every recipe that matches a visitor will apply, based on recipe priority. If two or more recipes attempt to personalize the same section, any conflicts are resolved using the recipe order, with higher-priority recipes taking precedence. By default this setting is set to enabled.
When disabled, personalization is limited to a single recipe per visitor. Only the first matching recipe will apply, and all other matching recipes will be ignored.