What your page must handle
The four things your page is responsible for once an OmniLab experience is embedded in it: height, panels, headers, and permissions.
Handle the four things your page owns once an experience is embedded, so the result looks deliberate rather than boxed-in. This page is for your web developer.
Everything inside the frame is OmniLab's. Everything about how the frame behaves in your page is yours.
Height
The experience does not have a fixed height. A form is short, a game fills the screen, a reward panel is somewhere in between — and the frame has to follow, or the visitor gets a scrollbar inside the page and your footer ends up floating halfway up it.
The experience tells your page how it wants to be sized, and the answer differs by page type:
| It announces | What your page should do |
|---|---|
| Content sizing | Follow the height the experience reports as it changes |
| Viewport sizing | Give the frame a height from your own layout, and ignore what it reports |
Games use viewport sizing, because they fill whatever space they are given. Landing pages and lists use content sizing.
Do not size a game from what it reports
A game measures the space it was handed, so feeding that measurement back as the frame's height creates a loop with no outside input and the frame freezes at its starting size. OmniLab stops reporting a height at all in that mode for exactly this reason — so a page that waits for one before showing the game waits forever. Give the frame a real height up front.
The reusable tag handles both modes for you. If you are writing the page by hand, your developer needs the technical detail.
Panels that open inside the experience
Experiences open panels — a reward, a form, a sign-in step. A panel lives inside the frame, so it can only appear where the frame is. On a long page, that can be far from where the visitor is looking.
The reusable tag solves this: it tells the experience which part of the frame is actually on screen, so the panel opens there. Written by hand, panels still open, but they fall back to a plain full-height presentation.
Sticky headers
If your site has a header fixed to the top of the screen, a panel can open underneath it. The reusable tag finds a standard header on its own and keeps panels clear of it. Point it at yours explicitly if your header is unusual — see JavaScript tag reference.
Letting the browser load it at all
If your site sends a content security policy — most do — it has to allow two things, or the embed is blocked with nothing visible to explain it:
- the address the OmniLab script loads from
- the address the experience itself is served from
Your web team gets the exact values from JavaScript tag reference. Raise it early: on many sites the policy is owned by a different team than the page, and that approval takes longer than the work.
This is the most common reason an embed that worked in a quick test page fails on the real site — the test page had no policy and the real one does.
Browser permissions
Permissions are granted to your page, not to OmniLab. If the experience uses the camera — a scan-based game, a receipt upload — your page has to allow it on the frame, and your site has to be served over a secure connection. Nothing prompts the visitor if the page never allows it, and the failure looks like a broken game rather than a missing permission.
Before you call it done
- Open the page on a phone, not just a narrow desktop window.
- Open a panel and scroll: the page behind should stay still.
- If the experience uses the camera, test the permission prompt on a real device.
- Watch the frame as the experience moves between steps — it should resize smoothly rather than jumping or leaving a gap.