Key takeaways
- IMA SDK runs in the browser or app web view, not on your server.
- It parses VAST XML to find ad creatives and tracking events.
- You control ad timing and frequency through player configuration.
- Latency and buffering depend on the user's network and ad server response.
How IMA SDK works
The IMA SDK attaches to your video player instance. When playback reaches a designated ad point, the SDK sends a request to your ad server. The server returns a VAST XML document. The SDK parses this document to identify the ad creative type, such as a video file or an image with a click-through link. It then renders the creative in the player interface, replacing the main video content.
The SDK manages the lifecycle of the ad. It tracks start, quarter, midpoint, and complete events. It handles user interactions like mute, skip, or click. If the ad creative is a video, the SDK loads and plays it. If it is an image, it displays the image with a timer. Once the ad duration ends or the user skips, the SDK returns control to the main video content.
Because this happens on the client side, the ad server must respond quickly. If the VAST tag is slow to load, the player may show a fallback or skip the ad slot entirely. You configure the ad points in your player code, specifying which timestamps trigger ad requests.
Why IMA SDK matters for a streaming business
Using a client-side SDK like IMA gives you direct control over ad presentation. You decide when ads appear, how long they run, and what happens if a user tries to skip. This flexibility is useful for premium content where you want to protect the viewing experience while generating revenue.
However, client-side insertion adds complexity. You must manage the relationship between your player code and the ad SDK. You need to handle edge cases, such as ad server timeouts or malformed VAST tags. If the ad fails to load, the player must react gracefully to avoid breaking the main video playback.
For operators, IMA SDK is a standard choice for web-based streaming. It supports a wide range of ad formats and tracking requirements. It integrates with most major ad servers. The trade-off is that ad latency is visible to the user. If the ad server is slow, the user sees a delay before the content starts. This can impact engagement and completion rates.
Common mistakes with IMA SDK
- Ignoring VAST timeout settings. If the ad server takes too long to respond, the player may hang. Set a reasonable timeout and define a fallback behavior.
- Not testing ad skip logic. Users expect to skip ads after a certain period. If your player does not honor the skip button, you risk user frustration and complaints.
- Mixing up ad point timing. Make sure your ad points align with natural breaks in the content. Placing an ad in the middle of a critical scene can disrupt the narrative and annoy viewers.
- Failing to track ad errors. If an ad fails to load, log the error. This helps you identify issues with specific ad creatives or server responses.
How Flicknexs handles IMA SDK
Flicknexs supports SSAI (server-side ad insertion) as its primary ad delivery method. This approach stitches ads into the video stream at the delivery layer, reducing client-side complexity. While IMA SDK is a client-side solution, Flicknexs focuses on server-side integration to handle ad timing and creative selection before the video reaches the player. This reduces latency and keeps a consistent playback experience across all devices. For operators who require client-side ad insertion for specific use cases, the platform's video player SDK allows for custom integration. However, the standard deployment relies on server-side ad management to simplify operations and improve performance. See the Video player SDK page for details on player integration options.
Done reading about IMA SDK?
Flicknexs ships it as part of a white-label streaming platform: web, mobile and TV apps, billing, ads, DRM and playout, on your own domain.