Common patterns and what to avoid

Use these to decide whether a script belongs here at all, and to keep the ones that do from taking a campaign down with them.

Patterns that work

Load a tag manager, manage tags inside it. One script in OmniLab, everything else managed where your team already works. This is the right default for anyone who already runs a container.

Separate the page-view script from the conversion script. Put conversions on the registration trigger instead of adding conditionals to a page-view tag. Easier to reason about, and you can switch off a misfiring conversion tag without losing all your analytics.

Scope a script to selected campaigns when it should not run everywhere. Match on something in the address rather than adding the script and hoping. See the campaign-scoped example in Script examples.

Use organisation variables instead of duplicating scripts. One script that reads a country or locale variable beats five near-identical scripts that drift apart.

Automate around campaigns from your own backend, not from a script. If something should happen when a participant acts — updating a CRM, starting a workflow — use webhooks, which run on your server, retry on failure, and cannot break the participant's page. See Sync contacts to your systems.

What to avoid

• Blocking work on page load. A synchronous script that waits on a slow third party delays the experience appearing, and some participants will leave before it does.
• Rewriting the experience's own markup. Scripts that depend on class names or layout break silently at the next release, and the breakage shows up as a broken campaign rather than a broken script.
• Overriding OmniLab's own behaviour. If you need different behaviour, configure it in the campaign rather than patching it from outside.
• Collecting extra personal data because you can. Anything you capture here is subject to the same rules as the rest of your site, and you own the justification for it.
• Large libraries that are not essential. Everything you load competes with the experience for a participant's patience.
• Firing tags regardless of consent. See About tags and scripts.

How to test one safely

1. Add it in staging first, enabled on one campaign nobody is using.
2. Run the full participant journey — not just the landing page. Forms, games, and the reward step are where a bad script surfaces.
3. Open the browser console and check for errors the script introduced.
4. Confirm the tag actually fired, in the destination tool rather than in OmniLab.
5. Test the refuse path if consent is involved.
6. Only then enable it more widely, and republish the campaigns that need it.

Have a rollback plan

Before you enable a script on live campaigns, know: who can disable it, whether they have Admin access out of hours, and which campaigns need republishing afterwards. A script problem during a live campaign is a timed incident, and working that out under pressure is what turns it into a long one.

Related