TVOD vs SVOD vs AVOD vs W2E: Monetization Models Compared

These four get talked about as if they're just different pricing plans, subscribe, rent, watch ads, or in AIOZ Stream's case, get paid to watch. They're actually different technically, not just commercially, each one requires genuinely different infrastructure to implement correctly, and AVOD in particular splits into two real, mutually exclusive engineering approaches most comparisons never mention.

TL;DR:

• TVOD (pay-per-view) and SVOD (subscription) both require checking whether a viewer is entitled to watch before serving content, TVOD with an expiring rental window, SVOD with a continuously valid subscription status.
• AVOD (ad-supported) splits into two real technical approaches: server-side ad insertion (SSAI), which stitches ads directly into the manifest, and client-side ad insertion (CSAI), which triggers a separate ad player at cue points. They behave very differently, not just cosmetically.
• SSAI is largely invisible to ad blockers since the ads become part of the stream itself; CSAI is more flexible and interactive but blockable, since it depends on the player making a separate, detectable request to an ad server.
• Watch-to-Earn (W2E) is structurally different from the other three, it pays the viewer instead of charging them, covered in full in its own dedicated article.
• AIOZ Stream's own documentation lists AVOD and TVOD as available monetization options but doesn't specify which ad-insertion approach or entitlement-checking mechanism it actually implements.

TVOD: pay-per-view and the entitlement problem

Transactional Video on Demand charges per title, either a time-limited rental or a permanent purchase, and the real engineering problem underneath it is entitlement checking: verifying, on every playback request, whether this specific viewer paid for this specific title, and for a rental, whether the paid window has actually expired yet. That's a real state machine, not a one-time charge, a rental typically starts a countdown from first play rather than from purchase, common in the industry as a 48-hour viewing window once started, which means the system has to track not just "did they pay" but "have they started watching, and if so, when." Real TVOD platforms actually run two separate timers, not one: an availability window, commonly 30 days from purchase, answering "has this rental expired before the viewer even pressed play," and a separate viewing window, the 48 hours Apple's own iTunes rental policy settled on after extending it from a shorter period in 2017, answering "are they still inside the countdown that started the moment they actually began watching." A rental entitlement check has to evaluate both timers independently, a title can fail the first check without ever triggering the second.

SVOD: continuous entitlement, not a one-time check

Subscription Video on Demand solves a related but distinct problem: instead of checking entitlement per title, it checks one broader entitlement, an active subscription, that has to stay valid continuously, not just at signup. A lapsed payment method, a canceled plan, or a downgraded tier all have to actually revoke access promptly, not just stop future billing, which is why SVOD platforms check subscription status against a live source of truth on or near every playback request rather than caching a one-time "yes" from months ago. The technical shape is simpler than TVOD's per-title, per-rental-window tracking, one status check instead of a title-by-title ledger, which is part of why SVOD scales more predictably to a large content library than TVOD does. There's also a real caching implication that follows from this difference: because SVOD's access decision doesn't depend on which specific title is being requested, the video segments themselves can be cached and served identically to every entitled subscriber, whereas TVOD's per-title, per-rental-window check means the entitlement decision has to happen freshly for that specific title and that specific viewer every time, even if the underlying video bytes being served are otherwise perfectly cacheable.

AVOD: two genuinely different technical approaches

This is where "just show ads" hides a real engineering fork. Server-side ad insertion (SSAI) stitches ads directly into the video stream before it ever reaches the player: an ad-insertion server transcodes the selected ad to match the content's own bitrate ladder, packages it, and splices its manifest directly into the video's manifest at positions marked by SCTE-35 cues, the same manifest structure this series covered in the M3U8 article. To the player, and to an ad blocker, the result looks like one continuous stream, there's no separate request to an ad server to intercept. Client-side ad insertion (CSAI) works the opposite way: the player itself detects a cue point in the manifest, pauses content playback, makes an explicit request to an ad server, plays the returned ad in a separate ad player, then resumes. That extra, detectable round trip is exactly what ad-blocking software can intercept, which is why CSAI is meaningfully more blockable than SSAI, not just slightly. The tradeoff runs the other way too: CSAI supports richer, more interactive ad formats and per-viewer targeting more easily, while SSAI's ads have to actually match the stream's own bitrate ladder to splice in cleanly, covered in the bitrate ladder article, real production complexity SSAI carries that CSAI mostly avoids.

W2E: the odd one out

Watch-to-Earn doesn't fit the same frame as the other three at all, it's the only one of the four that pays the viewer rather than charging them in some form. The dedicated W2E article covers what's actually documented about it in depth, confirmed real and live on AIOZ Stream, but with no published payout formula, funding source, or eligibility trigger, worth reading in full rather than summarized here. The short version for this comparison: it's real, it's structurally unlike TVOD, SVOD, or AVOD, and its actual mechanics remain the least documented of the four.

What AIOZ Stream actually documents for each

Checked directly against AIOZ's concepts and payment documentation: AVOD and TVOD are both named as available monetization options, but neither has a specified implementation. AIOZ's docs don't state whether its AVOD approach is SSAI, CSAI, or something else, they don't describe a rental-expiration mechanism for TVOD, and pricing tiers published for storage, delivery, and transcoding don't extend to any ad-serving or entitlement infrastructure cost. The one adjacent detail that is documented mentions feeding "player-level QoE and engagement into the ad-selection layer to balance revenue vs experience," confirming an ad-selection layer exists in some form without specifying which insertion approach it's built on. That's a real, specific gap worth verifying directly rather than assuming either implementation before building around it, especially since SSAI and CSAI place genuinely different demands on a player integration and picking the wrong assumption means rebuilding ad-handling logic later.

Combining models isn't unusual

Real platforms rarely commit to exactly one of these. A title can run an initial TVOD rental window before moving to SVOD-only access once exclusivity value drops, and hybrid SVOD-plus-AVOD tiers, a cheaper subscription with ads alongside a pricier ad-free one, have become common enough in the industry, both Netflix and Disney+ added exactly this kind of ad-supported tier alongside their existing ad-free subscriptions, that treating these four as mutually exclusive categories undersells how platforms actually mix them in practice. Nothing about the underlying entitlement-checking or ad-insertion mechanics changes when models get combined, a hybrid tier still needs the same subscription-status check as pure SVOD, plus the same ad-insertion approach as pure AVOD, running together rather than replacing each other.

Frequently Asked Questions

What's the core technical difference between TVOD and SVOD?
TVOD tracks entitlement per title, often with an expiring rental window that starts on first play. SVOD checks one broader, continuously-valid subscription status instead of a per-title ledger.

What's the actual difference between SSAI and CSAI?
SSAI stitches ads directly into the video manifest server-side, making the stream look continuous. CSAI has the player make a separate, detectable request to an ad server at a cue point, which is why it's more vulnerable to ad blockers.

Why is SSAI harder for ad blockers to stop?
Because there's no separate client-side request to intercept, the ad is already part of the stitched stream by the time it reaches the player, indistinguishable from regular content.

Does AIOZ Stream use SSAI or CSAI for its AVOD option?
Not specified. AIOZ's documentation confirms an ad-selection layer exists but doesn't state which insertion approach it's built on.

Is Watch-to-Earn a monetization model in the same sense as the other three?
Structurally, no, it pays the viewer rather than charging them. See the dedicated W2E article for what's actually documented about how it works.

Can a platform use more than one of these models at once?
Yes, and it's common in practice, TVOD-then-SVOD release windows and SVOD-with-ads tiers both combine models rather than picking one exclusively.

Related Reading

• What Is Video on Demand (VOD) and How It Actually Works: the delivery mechanics underneath the monetization models compared here
• AIOZ Stream for Creators: Ownership and Monetization: how these monetization models translate into what a creator actually earns
• Watch-to-Earn (W2E) on AIOZ Stream: What's Documented: the fourth model, covered in full depth
• How Video Segmentation and M3U8 Manifests Actually Work: the manifest structure SSAI splices ads into
• How to Build a Video Bitrate Ladder: A Practical Guide: what an SSAI-inserted ad actually has to match to splice in cleanly

References

• OTTVerse: CSAI vs SSAI: the SCTE-35/manifest-stitching mechanics and ad-blocker-resistance explanation cited above
• AppleInsider: Apple Extends iTunes Movie Rental Viewing Window to 48 Hours: the viewing-window figure cited above