Demo mode — how it works under the hood

Demo mode turns an installation into a self-guided trial: visitors sign up, land in a real account pre-loaded with read-only example data, watch ads serve on a live page, and see a lock screen when their window runs out. What demo users experience is covered in Demo accounts; this page explains the machinery for the network administrator running it.

The configuration knobs

Demo behaviour is configured at server level by Epom support, in the ad-serving configuration (not in the admin UI). Seven settings define the whole feature:

Setting	What it does	Default
Demo mode switch	Master toggle. Off = none of the behaviour below exists.	off
Demo role	The role whose members are treated as demo accounts. Detection is purely role membership — nothing is stamped on the user.	—
Active days	Trial length, counted from the user’s creation date.	15
Demo advertisers and demo sites (two settings)	Entity IDs shared read-only with every user who registers through the signed REST registration call.	—
Demo page URL	The live example page opened by the ribbon’s See live button.	—
Demo page allowed domains	Allowlist of request-origin domains for ad requests; empty = allow all.	empty

Lifecycle mechanics

Signup. A demo user is an ordinary user whose role is the demo role — the role comes from the registration request, so it has to be a role with the Sign-up permission. When demo mode is on, the signed REST registration call (POST /rest-api/register-user/{key}/{hash}/{timestamp}) adds Can View shares from the new user to each configured demo advertiser and demo site, for every user it registers, whatever their role. The built-in sign-up form (/signUp.do) and the network sign-up call (/user-sign-up) create no demo shares, so a demo installation needs its sign-up page to go through the signed call. Those shares are ordinary entity shares; nothing else marks the account as demo.

Consequences worth knowing:

• Changing the demo entity list later affects new signups only — existing demo users keep the shares created for them at registration.
• Deleting a demo advertiser/site leaves existing demo accounts without example data.
• Because demo users are regular users, everything else about them (feature depth, cards, tabs) is governed by the demo role’s permission matrix like any other role.

Expiry. There is no stored expiry date. On every check, the platform computes creation date + active days and compares with now. Three effects worth knowing:

• Raising the active-days setting retroactively re-opens accounts that had already expired; lowering it can expire currently active accounts immediately.
• Moving a user out of the demo role lifts all demo behaviour at once — that is the standard “convert this prospect to a real client” action.
• Moving a user into the demo role applies the window against their original creation date, which for an old account usually means instantly expired.

Expired accounts can still authenticate, and the account UI then covers the screen with an overlay that cannot be dismissed and whose links (contact sales, book a call) end the session. The lock is a feature of the account UI only: the server reports the account as inactive but refuses nothing, so an expired user’s REST calls (where the role allows them) and entity shares keep working until an administrator deactivates the user.

The chrome. While demo mode is on and the user is in the demo role, every page shows the demo ribbon (Demo badge, Quick Start Guide and API Reference links, See live, Get full access) and the support chat. The welcome overlay with the remaining-days counter needs only the demo role: it reappears once per browser session, and the day counter comes from the live computation above. The expiry lock shows every time the app loads, not once per session.

The live demo page

See live opens the configured demo page URL in a new tab — a real page carrying real ad tags from the demo setup, so a prospect can watch the whole chain serve end to end. The button simply doesn’t render when no demo page URL is configured.

The same URL changes what a placement’s Preview button does. While demo mode is on and a demo page URL is set, Preview on a Site, Native or Video placement redirects to the demo page with that placement’s tag appended (bannerCode, nativeApiUrl or videoVastTag) instead of opening the ad server’s own preview page, for every user of the installation rather than only demo users.

The allowed domains list protects the demo installation’s serving capacity: when demo mode is on and the list is non-empty, the ad server answers the ad-request endpoints (banner, iframe, API, native, VAST, VMAP, async retrieve and the header-bidding bid endpoint) only when the domain of the request’s Origin header is on the list — anything else gets a 403 with no body. The match is on the exact host, case-sensitive and without the port, so a subdomain needs its own entry. Keep the demo page’s own domain (and any other page you embed demo tags on) in the list.

Corner case: a request that carries no Origin header is refused too. Browsers send that header on cross-origin fetch/XHR calls but not on plain <script src> or <img> loads, and players and server-to-server callers often omit it, so an allowlist can block demo tags that load that way even from a listed domain.

Warning: the origin allowlist is enforced by the demo installation’s ad serving globally, not per demo user. Demo mode with an allowlist belongs on a dedicated demo installation — on a production network it would reject legitimate traffic from every publisher domain not on the list.

Corner cases and gotchas

Corner case: the countdown starts at account creation, not first login. The welcome overlay’s “days left” can already be well below the configured maximum on a user’s very first session.

Corner case: each signup gets its own fresh window. A prospect whose demo expired can simply register again with another email — prevent that at the signup level if it matters to you. The Hide sign-up box in white-label settings does not do it on the new sign-in page, which ignores that setting; route sign-up through your own page with Sign-up URL.

Corner case: demo entities are protected only by the Can View share level. If the demo role’s matrix grants create rights, demo users can build their own test entities next to the read-only examples — that is intended sandbox behaviour, but it means the demo account accumulates junk; clean it periodically.

Setup checklist for a demo installation

1. Create the demo role and trim its permission matrix to the feature set you want to show (Users and roles).
2. Build the example advertisers/campaigns/banners and sites/zones/placements, link them, and confirm they serve.
3. Ask Epom support or your account manager to configure the demo settings above (role ID, entity IDs, days, demo page, allowlist).
4. Host the demo page with tags from the example placements; verify See live shows ads.
5. Register a test account through the signed REST call and walk the full journey — welcome overlay, the shared demo entities (with edit controls disabled), See live, and (after shortening the window) the expiry overlay.

Related

• Demo accounts — the user’s view
• Sharing and permission model
• White-label and multi-tenancy
• Share sites and advertisers