Three ways the ad server can sit in your stack. They are not mutually exclusive — most platforms end up running two. This is how to work out which you need.
The decision is driven by what you control, not by preference.
| If this is true | Start here |
|---|---|
| You control your packaging or manifest layer, and you ship on smart TVs | Server-side insertion — the default for connected TV |
| You run a third-party packager you cannot change, or you need interactive formats | Client-side VAST |
| You already have an ad server and want to add competing demand to it | Server-side bidding |
| You run live channels with SCTE-35 in the transport stream | Server-side insertion, using your existing markers |
The ad server decides the pod and stitches it into the manifest, so the player receives one continuous stream. This is the path most connected-TV platforms take, for the reasons set out in server-side ad insertion.
You gain seamless playback, ad-block resistance and one integration across every device. You lose direct access to client-side signals and take on responsibility for a beaconing model — both covered in detail on the SSAI page.
Your player requests ads and receives a VAST document describing what to play and which events to fire. The player handles playback through its own ad module.
Client-side insertion introduces a transition at every break — the player tears down content playback and establishes ad playback. On smart TVs with limited processing headroom this is visible as a stall or a black frame, and it is the most common source of abandonment at the first break. If you ship primarily on TV devices, treat this path as a fallback rather than a default.
If you already run an ad server you are not ready to replace, GoGo CTV can participate as a demand source instead. Your existing server calls out, and the response competes in your auction like any other bidder.
This is also the lowest-risk way to evaluate us: incremental demand into an unchanged stack, with nothing to migrate. It is how most migrations start.
Server-side insertion is device-agnostic by construction — the stream is just a stream. These are the platforms our clients ship on today.
| Platform | Notes |
|---|---|
| Roku | Server-side recommended. Native player is strict about encoding profile changes at a discontinuity. |
| Amazon Fire TV | Server-side recommended. |
| Samsung Tizen | Server-side recommended. Limited runtime headroom for client-side ad logic. |
| LG webOS | Server-side recommended. As above. |
| Web | Either path. Client-side is viable where interactive formats matter. |
| Mobile | Either path. |
Player-version floors, certification status per platform, and any device-specific caveats are not published here. Ask for the current compatibility matrix at contact@gogoctv.com — device support moves faster than documentation.
A solutions engineer walks your delivery setup with you and picks the path. Bring the items in what you need before you start and this is one call rather than three.
A slice of your live traffic is mirrored through the ad server without affecting what viewers see. You get latency, fill and yield side by side against your current setup before changing anything.
A small percentage of real traffic serves through GoGo while the rest stays on your existing server. Both sets of numbers are visible throughout.
Traffic ramps over as the numbers hold. Because the previous path stays configured, rollback is a routing change rather than a re-integration.
The migration runbook covers each stage in detail, including what to measure and when to abort.
Base URLs, the authentication model, request and response schemas, error codes and rate limits are deliberately not documented on this site. A reference that does not exactly match what the service accepts costs an integrating engineer more time than no reference at all.
Request the current specification at contact@gogoctv.com.
Thirty minutes with a solutions engineer, working from your actual delivery setup rather than a generic diagram.