# Preview Bar

A bottom toolbar that lets you view your live site as any test → variant, emulate devices, and watch your goals fire in real time — drafts included, results untouched.

Browse your real site as any test → variant from a bar pinned to the bottom of the page. Emulate devices, watch your goals fire in real time, and never touch your results.

The Preview Bar is a thin toolbar — Shopify-admin style — fixed to the bottom of your own website. Pick a **test**, pick a **variant**, and the page instantly shows you what a visitor in that variant would see. It's how you sanity-check a variant on real content, on real pages, before a single visitor is enrolled.

It does three jobs at once: it **switches variants** on the live page (drafts included), it **emulates mobile and tablet** so you can check layout at every width, and it **validates your goals** — lighting up a checklist as each goal fires so you can confirm your tracking works *before* you launch. Because drafts are never served to your real traffic, the signed Preview Bar session is the only way to see a draft variant on your live site.

## How it works

1. **Launch "Preview on site"** — From the test wizard's Variants step, a test's page, or the edit screen, click **Preview on site**. Otter checks your project's snippet is verified and that the URL belongs to your project's domain, then issues a short-lived signed session.
2. **Your site opens in a new tab** — Unlike the visual editor's popup, the Preview Bar opens a normal new tab so you can browse freely. The bar appears at the bottom, pre-loaded with every test in the project, each badged **Draft**, **Running**, or **Paused**.
3. **Pick a test, then a variant** — Choosing a variant applies it live: visual and personalization variants apply their DOM changes in place, custom CSS and custom JavaScript are injected exactly as the live runtime would, and redirect variants navigate to the variant's URL. Pick **Original (control)** to drop back to the unmodified page. Switching tests always resets the variant to Original first — no surprise mutations.
4. **Browse — the bar follows you** — As you click around your site the session rides along in the tab, so the bar re-appears on each new page and re-applies your current selection. Hit **✕** to exit and return to the clean page.

## Validate your goals before launch

A test only earns you data if its goals actually fire. The Preview Bar's **Goals** panel lets you confirm that — live, on your real site, before you launch. Open it and you get a checklist of every goal on the selected test. Trigger each one the way a visitor would and it lights up **✓ Fired** the instant Otter sees it, with a toast to confirm and a progress bar as you complete the set.

It's a genuine dry run: goal validation **observes** the trigger and updates the checklist, but it never records a conversion. Trigger anything as many times as you like — your results stay clean.

| Goal type | How to trigger it |
| --- | --- |
| Click | Click any element matching the goal's CSS selector. |
| Page visit | Navigate to the goal's target URL — the check follows SPA route changes too. |
| Custom event | Fire `optimo.track('event_name')` from your own code. |
| Revenue | Call `optimo.revenue({…})` or track a Purchase event. |

GA4-event goals aren't shown here — they're populated server-side from GA4, so there's no in-browser trigger to watch. Every other goal type validates live.

## Emulate mobile and tablet

The device toggle on the right of the bar switches between **Desktop**, **Tablet**, and **Mobile**. Pick a size and your site renders inside a true-to-size device frame with the selected variant applied — a fast way to check a variant's layout at phone and tablet widths without resizing your browser. Goal validation runs on the desktop view (the detector watches the live page, not the device frame), so the Goals panel pauses in device mode and points you back to Desktop to validate.

> **Good to know:**
>
> - **It never touches your results.** The bar forces the variant you pick for your browser only — it bypasses normal assignment and fires no conversion or assignment tracking. Switch variants as much as you like; nothing is recorded against the experiment.
> - **Goal validation is a dry run.** The Goals panel confirms each goal fires by watching for its trigger, but it never POSTs a conversion. Use it freely to prove your tracking works before launch — nothing you trigger in preview reaches your results.
> - **Viewers can preview too.** Because previewing is read-only, every role — including viewers — can launch the Preview Bar. (The visual editor, which mutates variants, stays owner/admin/member only.)
> - **Signed, scoped, and time-limited.** Each session is signed, bound to your verified project's domain, and valid for 30 minutes. When it expires, relaunch from anywhere you see **Preview on site**.
> - **One test at a time.** The bar previews a single test → variant at once. Switching tests tears down the previous variant cleanly before applying the next.
> - **Custom JavaScript previews reload on switch.** Injected CSS can be removed cleanly, but executed JavaScript can't be un-run — so after previewing a variant with custom JS, switching to another selection reloads the page once and applies the new selection fresh. Your test and variant choice survives the reload.

## Frequently asked questions

### Can I check my goals actually fire before I launch?

Yes — this is the Preview Bar's goal validation mode. Open the Goals panel from the bar and it lists every goal on the selected test. As you use your site — clicking the tracked element, reaching a pageview URL, or firing a custom event or revenue event from your code — each goal lights up '✓ Fired' in real time, with a toast to confirm. It's a dry run: nothing is recorded against the experiment, so it's a safe way to confirm your tracking is wired up correctly before a single visitor is enrolled.

### Does validating a goal in preview record a conversion?

No. Goal validation is purely an observation layer — it watches for each goal's trigger and lights up the checklist, but it never POSTs a conversion. The whole Preview Bar bypasses assignment and conversion tracking, so you can trigger every goal as many times as you like without affecting your results. GA4-event goals are the one type that can't be validated this way, because they're populated server-side from GA4 rather than fired in the browser.

### The Goals panel says to switch to Desktop — why?

Goal detection watches the live page you're browsing. When you switch the bar to mobile or tablet emulation, the variant renders inside a device frame (a separate page), which the detector can't watch — so it pauses and prompts you to return to Desktop to validate goals. Variant preview still works in every device size; it's only the live goal-firing check that needs the desktop view.

### Can I preview how a variant looks on mobile or tablet?

Yes. The bar has a device toggle — Desktop, Tablet, and Mobile. Pick a size and your site renders inside a true-to-size device frame with the selected variant applied, so you can check a variant's layout at phone and tablet widths without leaving your desk or resizing your window.

### Who can use the Preview Bar?

Anyone on your account, including viewers. Previewing is read-only — it never edits a variant or writes a conversion — so unlike the visual editor (which blocks viewers) the Preview Bar is open to every role. The project does need a verified Otter snippet first, because the bar runs on top of the installed SDK.

### Where do I launch the Preview Bar from?

From a 'Preview on site' button in three places in the dashboard: (1) on a live test's page (Show), in the top-right header next to Share and History — the main one for a running or paused test; (2) in the test creation wizard, on the Variants step, as a 'Preview on your site' panel so you can preview a draft variant while you build it; and (3) on the test edit screen, in the header next to Start Test. Each one opens your real site in a new tab with the bar active.

### The 'Preview on site' button is greyed out — why?

The button needs two things before it will launch, exactly like the visual editor: (1) a verified snippet on the project — install and verify it from Project Settings → Installation; and (2) a concrete target URL for the test. Exact, simple, and single trailing-wildcard URLs (like https://example.com/pricing*) resolve to a page the bar can open; a URL that's only a pattern won't, and the button stays disabled with a hint to add a target URL. Fix the snippet or the URL and the button enables.

### What's the difference between previewing a draft and a live test?

None, from your side — the bar lists every test in the project (drafts, running, and paused) and you pick any one. The difference is who else can see it: drafts are invisible to your real visitors and are never served by the public SDK, so the signed Preview Bar session is the only way to see a draft variant on your live site. Live tests are already running for a slice of visitors; the bar just lets you force a specific variant for yourself.

### Does previewing affect my experiment results?

No. The Preview Bar forces the variant you choose for your browser only — it bypasses normal assignment and fires no conversion or assignment tracking. Nothing you do in preview mode is recorded against the experiment, so you can switch variants freely without polluting your data.

### Why does the Preview Bar open in a new tab instead of a popup?

Because it's a full browsing session, not a constrained editing surface. The visual editor uses a small popup because it's a focused tool for building one variant. The Preview Bar, by contrast, is for clicking around your whole site as a visitor would — so it opens a normal new tab and the bar rides along at the bottom as you navigate.

### Does it work for redirect (split URL) tests?

Yes. For visual and personalization tests the bar applies the variant's DOM changes in place. For redirect/split tests, selecting a variant navigates to that variant's URL — carrying the preview session along so the bar stays active on the destination.

### Does it show variants built with custom CSS or custom JavaScript?

Yes. Selecting a variant injects its custom CSS and runs its custom JavaScript (variant-level and test-level) exactly as the live runtime would for an assigned visitor. One behavioral note: injected CSS is removed cleanly when you switch, but JavaScript that has already executed can't be un-run — so after previewing a variant with custom JS, switching to another variant or back to Original reloads the page once and applies the new selection fresh. Your selection survives the reload.

### Does the Preview Bar stay active as I click around my site?

Yes. The signed session lives in your tab's sessionStorage, so as you navigate from page to page the bar re-appears and re-applies your current selection. It lasts 30 minutes; after that, relaunch it from the test wizard, the test page, or the edit screen.

### I added ?optimo-preview to my live URL and the draft didn't show — why?

Drafts are deliberately never served to public traffic, and a bare URL parameter isn't trusted. The only way to view a draft on your live site is the signed Preview Bar session, which you launch from inside Otter (Preview on site). That session is signed, scoped to your verified project's domain, and time-limited.

---

Canonical page: https://www.otterab.com/docs/building-tests/preview-bar