Embedding the Creative Simulator in your media owner portal
Published · 4 min read
When a media owner decides to put a creative preview into its own portal, the task usually lands with the web team. There it often gets planned like a project: ticket, estimate, sprint. For the first step, that is thinking too big.
A creative simulator can be embedded with an iframe. The core is a single HTML tag. What takes time beyond that is mostly decisions. Below are the steps in the order they come up in practice, each with a way to check it in half a minute.
1. Allow the domain
A simulator should not show up on any random website, and the browser enforces that itself. The
Content-Security-Policy header with the frame-ancestors directive controls which pages may
embed a page. MDN puts it this way: it “specifies valid parents that may embed a page”. The older
X-Frame-Options: ALLOW-FROM is obsolete according to MDN, and modern browsers ignore it.
For you, this means every domain where the simulator should appear has to be on the list. If you have access to VirtualCampaign, you add them yourself under Settings → Creative Simulator, one address per line, wildcards allowed. Changes apply within a minute. Everyone else sends us the domains.
30-second test: If the iframe stays white, open the browser console (F12). If it says
“Refused to frame” together with “frame-ancestors”, the domain is missing from the list. Check
protocol and subdomain: https://www. and https:// without www are two entries.
2. Add the iframe tag
The embed itself is one tag with four attributes, and each has a job. title names the frame.
According to MDN, people using a screen reader rely on the title attribute to label an iframe’s
content. loading="lazy" defers the frame until it gets close to the visible area.
allow="fullscreen" permits fullscreen mode.
You do not need an API key in the browser. Authentication against the platform happens on the
server. The tenant follows from the subdomain, and for testing there is the public sandbox at
demo.kreativsimulator.com.
30-second test: Load the portal page and watch the network tab in the developer tools. If the
simulator starts loading before you scroll to it, loading="lazy" is missing, and every visitor
downloads video even if they never get that far.
3. Don’t guess the height
The most common problem after embedding is a frame that is too short. The simulator always fills exactly its frame. If the frame is too flat, the page stays the same length. Instead, an inner panel gets a scrollbar. That looks like a bug although everything works.
On phones the view needs more height than on desktop, because the controls stack vertically. With
the ?fit=1 parameter the canvas fits both width and height, and the open sidebar does not cover
the image.
30-second test: Open the page in the developer tools’ device mode at phone width. If a second scrollbar shows up anywhere inside the simulator, give the frame more height.
4. Apply your own design
The preview lives in your portal, so it should look like your portal. Colours, fonts and
placeholders come from your own CSS file, passed with ?theme=. Language (?lang=), start
product (?product=) and background (?bg=) also go into the address. With ?logo=0 the
exported image or video carries no tenant logo.
URL parameters always take precedence over the settings in VirtualCampaign. That is handy when a campaign page should look different from the main portal.
30-second test: Put a screenshot of your portal next to a screenshot of the simulator. If the border between the two jumps out at you, the theme is not there yet.
5. Optional: control it from your page
Many portals already have their own site list with filters. Then the simulator should load, on
click, exactly the site the customer picked there. That is what window.postMessage is for: your
page sends commands such as setProduct or setCreative, and the simulator reports events such
as ready and productChanged.
Two rules from MDN belong in every implementation. When sending, specify an exact target origin,
“not *”. When receiving, check where each message comes from via origin. That is two lines of
code, and it keeps other windows out of the conversation.
30-second test: Search your own code for postMessage( and for "*". If both sit on the
same line, replace the asterisk with the address of your simulator.
6. Optional: logged-in customers only
By default, anyone can open the simulator address. If the preview should only appear behind your login, switch the subdomain to “token only”. Your server then fetches a token for each page view and passes only that token to the iframe. The API key stays on the server.
A token is valid for five minutes and only once. It sits behind a # in the address, so it never
reaches servers, logs or the referrer. A copied iframe address stops working afterwards.
30-second test: Copy the iframe address from a logged-in session and open it in a private window. If it shows products there, the protection is not active.
Why this fits into an afternoon
Steps 1 to 4 are configuration. Our estimate from projects: a web team gets them done in an afternoon, including a test on a phone. Your own controls via postMessage and the token request behind the login are real development work and come as a second step.
The manual part is the sites themselves. The simulator shows creatives on your real locations, which takes good photos. We take over existing photo products for new customers free of charge. The full guide with code and a live demo is at virtualcampaign.dev/en/embed.