About website integration
Give an OmniLab experience its own page on your site, framed by your header and footer, and pick how the page loads it.
Give an OmniLab experience its own page on your site so visitors take part without leaving your domain. This page explains the shape to aim for and helps you pick the loading method before you brief anyone.
Give the experience a page of its own on your site: your header at the top, your footer at the bottom, and the whole space between them is the experience. Visitors stay on your domain, inside your navigation, and never see a handover.
That is the shape to aim for. The experience is not a widget to slot between two paragraphs — it is a screen that needs room, and it changes height as a participant moves from a form to a game to a reward.
- 1Your header and navigation, unchanged
- 2The OmniLab experience fills the page between them
- 3It grows and shrinks as the participant moves through it
- 4Your footer, unchanged
Your header and footer stay yours. Everything between them is the experience.
The experience needs an address on your own domain
Embedding only works properly when the experience is served from a subdomain of the site it appears on — experience.yourbrand.com inside www.yourbrand.com. The default OmniLab address is fine for links and QR codes, but inside your page the browser treats it as a third-party frame and blocks the cookies the experience needs, so participants cannot stay signed in.
Set up Custom domain before you build the page.
Choose how the page loads the experience
Both methods put the same experience on the page. They differ in who decides which experience.
| Method | The page loads | Choose it when |
|---|---|---|
| Direct embed | One specific experience, fixed in the page's code | You know which experience belongs on which page, and that rarely changes |
| Reusable tag | Whichever experience the page's own address names | One template page has to show different campaigns over time, or across many pages |
The reusable tag is a small script that also handles the fiddly parts for you — sizing the frame as the experience changes, keeping pop-out panels clear of a sticky header, and stopping the page behind from scrolling while one is open.
Prefer the tag unless something prevents you using it. It is the path OmniLab builds and tests against, and choosing the direct embed means your team takes on the frame's height and the placement of every panel, then maintains both as experiences change. See JavaScript tag reference.
Your web team does the implementation
Both methods mean adding code to your website. Decide the method and gather the details below, then hand the section to whoever maintains the site.
Who owns what
| Responsibility | Owner |
|---|---|
| The page the experience appears on | You |
| Loading the experience and sizing its frame | The tag, or your own code if you embed directly |
| Allowing both OmniLab hosts in your content security policy | You |
| Browser permissions the experience needs, such as camera | You, on your page |
| The experience itself: game, form, branding, reward | OmniLab |
| Campaign configuration and rewards | You, in OmniLab Studio |
What to give your web team
- The experience address from OmniLab Studio.
- Whether visitors should land on a campaign page that offers several experiences, or go straight into one.
- The branded address the experience will be served from. This is required, not optional: it has to be a subdomain of the site you are embedding on, or sign-in inside the experience will not work. Set it up first. See Custom domain.
- Any permission the experience needs, such as camera access for a scan-based game.