Common patterns and what to avoid

Use these to decide whether a script belongs in your experiences at all, and to stop the ones that do from taking a campaign down with them.

Patterns that work

Load a tag manager, and manage tags inside it. One script in Studio, and everything else managed where your team already works. This is the right default if you already run a container.

Keep page views and conversions in separate scripts. See When: the Trigger Event.

Limit a script to one organisation or to selected campaigns when it shouldn't run everywhere, or turn every script off for one campaign. See Turn scripts off for one campaign.

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

Automate from your own systems, not from a script. When something should happen as a participant acts, such as updating a CRM or starting a workflow, use webhooks. They reach your server, are retried on failure, and can't 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, and some participants leave before it appears.
• Rewriting the experience's own markup. Scripts that depend on class names or layout break silently at the next release, and it shows up as a broken campaign, not a broken script.
• Overriding the experience's behaviour. If you need different behaviour, set it up in the campaign rather than patching it from outside.
• Collecting extra personal data because you can. Anything you capture here follows the same rules as the rest of your site, and you own the justification.
• Large libraries that aren't essential. Everything you load competes with the experience for a participant's patience.
• Firing tags regardless of consent. See About tags and scripts.

Test before it goes live

Test every script on one campaign first, in staging if you have it, through the whole participant journey: see Test it. Forms, games and the reward step are where a bad script shows up.

Have a rollback plan

Before a script reaches live campaigns, know who can switch it off, whether they have Admin access out of hours, and which campaigns need publishing again afterwards. A script problem during a live campaign is a timed incident. Working that out under pressure is what makes it a long one.

Next steps

• Script examples
• Add a script
• Sync contacts to your systems