One pre-roll tag, and everything that is not built yet
This is the shortest page in this section, and the length is the message. Advertising on the platform today is a single platform-wide VAST tag played before the video, client-side. Everything a media buyer would ask for next is a build.
What actually happens when a viewer presses play
One VAST tag is configured for the platform. The player's ad SDK requests it before playback begins, renders whatever comes back, and then starts the content. That is the entire ad path, and it is executed in the client rather than stitched into the stream.
The tag is yours. It is set during onboarding against your own ad server or network account, which means the demand, the reporting and the money are on your side of the relationship rather than intermediated by us.
Reporting stays where the truth is. There is no ad-reporting endpoint in the console and this is a decision rather than a gap: the numbers that matter to a media buyer are the ad server's, and keeping a second set here would produce two figures that disagree. The console links out to the ad server instead.
The honest inventory
What an ad ops team asks for, and where each item stands.
| Capability | Status | Detail |
|---|---|---|
| Pre-roll, one platform-wide tag | Connected at onboarding | Client-side, via the player's ad SDK |
| Your own ad server or network | Connected at onboarding | Your account, your demand, your reporting |
| Mid-roll and post-roll | Not built | Requires cue points, which do not exist |
| Cue points and VMAP | Not built | The first prerequisite for everything below |
| Per-placement or per-title tags | Not built | One tag, platform-wide, is the whole model today |
| Server-side ad insertion (SSAI) | Not built | Would change the packaging path, not only the player |
| Frequency capping and waterfall | Not built | Belongs to the ad server once cue points exist |
| Ad reporting inside the console | Not built — by decision | The ad server's figures are the ones that count |
Why client-side and server-side are a different order of work
Client-side insertion asks the player to fetch and render an ad around the content. Server-side insertion stitches the ad into the same stream as the content, so the viewer receives one continuous manifest and an ad blocker has nothing separate to block. The second is what large ad-funded services run, and it is worth being plain that the platform does not do it today.
The distance between the two is not a setting. Server-side insertion touches the packager, the manifest, the tracking beacons and the way an edge caches a stream that is now personalised per viewer. It is a real project with a real estimate, and an engagement can scope it — but it is not a switch we are hiding from you.
Ordering matters if you are planning for it. Cue points come first, because mid-roll, VMAP, capping and any per-break rule all read from them. A platform that can mark a break can then sell one.
Questions
Can I run an ad-funded free tier today?
You can run one pre-roll before every video, with your own tag, and you can charge nothing for the tier. What you cannot do today is sell breaks inside the content, cap frequency per viewer, or vary the tag by title — those need cue points, which are not built.
Do you support SSAI?
No. Insertion is client-side through the player's ad SDK. Server-side insertion is a build that touches the packager and the manifest rather than a configuration flag, and calling it supported would be the kind of claim that is discovered during an integration.
Where do I see ad revenue?
In your ad server. There is no ad-reporting endpoint in the console, deliberately — a second set of figures maintained here would drift from the set that actually pays you.
Planning an ad-funded tier?
The gap between one pre-roll and a sellable inventory is specific and estimable. Tell us what your ad ops team needs to run and we will scope it against what is there.