Question 1

Are these parameters safe to use on a production site?

Accepted Answer

Yes. Visitors who don't know about them can't accidentally trigger them, and the SDK strips most of these from the URL after applying them so they don't show up in analytics or get shared by accident. ?optimo-debug only affects what's logged in the console, which is normally invisible to visitors.

Question 2

How is ?optimo-optout different from declining consent?

Accepted Answer

?optimo-optout bypasses the SDK for one page load only — nothing is stored, no cookie is set, the visitor's existing assignments stay intact for future visits. optimo.grantConsent(false) is a persistent opt-out: it clears storage, halts tracking, and stays in effect until consent is granted again. Use optout for one-off QA; use grantConsent for proper consent management.

Question 3

What does ?optimo-refresh actually clear?

Accepted Answer

Everything client-side that identifies the visitor: the UUID cookie, cached test configuration, cached variant assignments, queued events. It then asks the server to delete the visitor record on our side too. The next page load behaves as if a brand-new visitor arrived — useful for testing fresh-visitor flows without opening incognito.

Question 4

Will ?optimo-debug slow my site down?

Accepted Answer

Negligibly. It enables console.log calls inside the SDK; logging itself is essentially free in modern browsers. The only difference a visitor might notice is that their DevTools console has Otter A/B output — which they'd only see if they had DevTools open in the first place.

Question 5

Why is ?optimo-verify project-specific?

Accepted Answer

Because the SDK is loaded once per page but a single site might have multiple projects (different keys for different sub-properties). The verify parameter sends a confirmation ping using the key you specify, so the dashboard's installation checker can mark that specific project as verified.

Question 6

Do these parameters persist across page loads?

Accepted Answer

No. Each parameter applies to a single page load. ?optimo-debug stays on as long as the parameter is in the URL — reload without it and logging stops. ?optimo-refresh runs once, then the URL is rewritten to remove the parameter. ?optimo-optout and ?optimo-verify behave similarly.

Question 7

Are there other undocumented parameters?

Accepted Answer

These four are the supported, documented set. Internal flags exist for engineering use but they're not part of the public API and can change without notice. If you have a debugging need that isn't covered, reach out and we'll either add a documented parameter or surface what you need in the dashboard.

Parameter	What it does
?optimo-optout https://your-site.com/page?optimo-optout	Bypass the SDK on this page load. No tests run, no events fire, the anti-flicker style is removed immediately. Useful for excluding your own browsing or for support agents reproducing issues without entering tests.
?optimo-verify=YOUR_API_KEY https://your-site.com/?optimo-verify=YOUR_API_KEY	Confirms the SDK loaded with your key by sending a verification ping back to Otter A/B. The dashboard's installation checker uses this to mark a project as verified.
?optimo-debug https://your-site.com/page?optimo-debug	Enables verbose [Optimo] logging in the browser console. Shows every test evaluated, why each variant was assigned or skipped, and any targeting / trigger gates that ran.
?optimo-refresh https://your-site.com/page?optimo-refresh	Wipes the visitor UUID, cached test config, cached variants, and any queued events from this browser, then asks the server to clear the visitor record. Use when QAing a fresh-visitor experience without opening an incognito window. The page reloads with the parameter stripped.

URL Parameters

URL Parameters

Frequently asked questions