Where and when a script runs
Choose the context and trigger for a script, and see which values it can read about the current organisation and participant.
Choose when a script fires, so a conversion tag does not fire on a page view and an embed-only tag does not run where it makes no sense. Each script carries two settings, and getting them wrong is the most common reason a tag reports the wrong numbers.
Where: the context
| Context | Runs when | Use it for |
|---|---|---|
| All | Both standalone and embedded experiences | Most analytics and tag manager loads |
| Embedded only | The experience is inside your own site or app | A tag that would double-count because your own page already fires it |
| Standalone only | The experience is its own page | A cookie banner you only need when OmniLab is the whole page |
The embedded distinction matters more than it looks. When an experience runs inside your website, your page's own analytics is usually already counting the visit — a second tag inside the frame counts it again.
When: the trigger
| Trigger | Fires |
|---|---|
| Page load | On the normal page visit |
| Registration | At the registration stage |
Use a separate registration-triggered script for conversion events rather than overloading the page-view script with conditionals. It is easier to reason about, and easier to switch off if the conversion tag misfires.
What a script can read
Before your scripts run, OmniLab makes some values available on the page:
window.omnilab?.group?.uniqueKey
window.omnilab?.group?.configuration?.variables
window.omnilab?.contact?.externalId
window.omnilab?.contact?.email
window.location.pathnameContact values only exist when the participant is already known at that point in the flow. Reading them on a page-load script for an anonymous visitor returns nothing — which is correct, not a bug.
Only two values are guaranteed
window.omnilab.group.uniqueKey and window.location.pathname exist for every organisation. Everything under configuration.variables is a free-form store an admin created — no keys are seeded. Confirm which exist before you reference them, and always provide a fallback for one that might be missing.
Making one script serve several organisations
If you run several organisations — different regions, brands, or venues — use organisation variables so one script adapts instead of maintaining several near-identical copies:
country: window.omnilab?.group?.configuration?.variables?.country,
locale: window.omnilab?.group?.configuration?.variables?.locale || 'en_US',See Variables at organisation level.