How to count video watch time and build creator payouts

If your platform pays creators or content owners for video, you first have to decide what counts as watching. This guide covers the definitions, the payout formulas, and how to build them so every payment holds up.

Any platform that pays for video runs into the same wall: to turn watching into money, you have to say precisely what "watched" means. A creator revenue share, a per-view licensing royalty, an ad payout, all of them need a number, and you have to define that number yourself, because there is no standard one to read off. This guide is for teams at creator platforms and OTT or media services who have to set that number and defend it. It covers what a view and watch time actually are, why video makes them slippery, the formulas that turn them into payouts, and how to build the whole thing on data you can audit.

Why counting a video view is harder than counting a click

A click is binary: it happened or it did not. A video view is a spectrum. One viewer watches three seconds and swipes away; another watches half and pauses for a day; another finishes at double speed. The same "view" can mean four seconds or four minutes, and the watching is spread across phones, TVs, and laptops, interrupted by pauses, seeks, and buffering. So "did they watch it" has no single answer, and the moment you attach money to the answer, you have to choose a threshold and apply it consistently.

There is no universal definition of a view, and that is correct

Every platform sets the bar to suit its own purpose, so the same play counts differently depending on who is measuring. This is not sloppiness; a discovery feed and a subscription service want different things from the word "view." Here is where the major platforms draw the line, as of 2026.

So there is no standard "view" to inherit. If you run your own platform, you are effectively picking one of these rows, and the day you pay against it, that choice becomes a payout formula.

The building blocks, defined

Before any payout math, four terms need to be exact, because teams routinely mix them up and pay on the wrong one.

View

An attempt to play, successful or not. A viewer taps play and it loads, or fails, or plays: that is one view. A pause and resume within the same session stays one view. It is the widest possible count, and on its own it says nothing about whether anyone watched.

Watch time versus playing time

Watch time is the wall-clock time a viewer spent on a video, including startup and rebuffering. Playing time is the subset actually spent playing. The distinction matters for payouts: if a viewer watches a 2-minute video at 2x speed, watch time is about 1 minute, because it measures elapsed time, not how much of the video was covered. Decide which one your formula pays on, and say so.

Completion, or percent watched

How much of the runtime a viewer actually reached, as a percentage. A 45-second stretch of a 90-second episode is 50 percent complete. This is the fairest single measure of "did they really watch," and the one OTT and media teams lean on.

Qualified or engaged view

A view that cleared a higher bar than a raw play, usually a number of seconds watched or an action taken. It is the metric most platforms actually gate money on, because a raw first-frame count includes plays nobody really watched.

Two more you will see in any analytics tool, useful for context but rarely the payout basis: unique viewers (distinct people, not plays), and concurrent viewers (how many are watching at once, the number that matters for live). For the full metric set, see the video metrics guide and the glossary.

Start using FastPix for free. $25 credit, no credit card required. FastPix Video Data records watch time on every view. Create your workspace ->

The formulas that turn watching into payouts

Once "watched" is defined, a payout is arithmetic. These are the models creator and OTT platforms actually use, each with a worked example.

Which model you pick changes who earns the most. A per-view rate rewards whoever generates the most starts, which favors shallow, swipe-away content, while a per-minute or watch-time pool rewards whoever holds an audience. On a sample of 260 views, moving a $10,000 pool from a first-frame view count to a 30-second view shifted about 26 percent of the pool between creators, on the same viewers and the same month (the code at the end reproduces this on a downloadable sample). The definition you pick, not the amount of content made, sets each creator's share.

How real platforms turn watch into payouts

Every model above is running somewhere in the wild. Four current examples, and the rule each one counts on.

YouTube: ad-revenue share, gated on engaged views

Creators earn 55 percent of the ad revenue on their long-form videos, and 45 percent for Shorts from a pooled allocation, while the YouTube Premium pool is split among creators by member watch time. The public view count moved to first-frame counting in 2026, but payouts still run on engaged views, plays that got past the first few seconds, not the raw number.

Spotify: a revenue pool split by consumption

Spotify pays each rightsholder its "streamshare": your streams divided by total streams, times the revenue pool. By Spotify's own example, 0.1 percent of all streams earns 0.1 percent of a $10 million pool, which is $10,000. This is the exact shape of a creator revenue share by watch time, with watched minutes standing in for streams.

TikTok Creator Rewards: paid per qualified view

TikTok pays qualified views divided by 1,000, times an RPM of roughly $0.50 to $2.00. A qualified view needs original content over a minute long, and by creator-reported figures only about half of a video's views qualify, so how you define the view matters as much as the RPM.

ReelShort: a coin unlock per episode

Microdrama apps like ReelShort monetize at the paywall. The first episodes are free, then viewers spend coins, bought for a few dollars or earned by watching ads, to unlock each next episode at roughly 30 to 50 cents. Here a view of a locked episode is a purchase, and by reported figures about 71 percent of the platform's revenue comes from those single-episode unlocks, so the metric that matters is not minutes watched but which locked episode got played.

Notice the range: YouTube and Spotify pay for attention delivered, TikTok pays for qualified views, and ReelShort charges at the unlock. Your platform is usually one of these, most often the Spotify shape, a pool split by watched minutes. The exception is course platforms like Kajabi and Thinkific, which take no cut and pay no watch-based royalty at all; their version of this problem is gating a certificate on completion, not computing a payout.

How to build it on data you can defend

The mechanism is the same whether you pay creators or license content: capture the watching, keep the raw record, and compute payouts from it rather than from a bucketed count.

1. Capture watch time on every view

Playback happens in your player. FastPix Video Data captures every interaction from inside it and records the seconds watched on each view, across web, iOS and Android, enriched with device and geo and quality scores. That per-view watch record is the raw material a payout needs.

2. Store the seconds, not a verdict

Export one row per view (Views -> Export CSV, or the export API) and keep the seconds watched, tagged with the viewer and the creator or content owner. Do not collapse it to "counted or not counted," because once you do, you can never recount it under a different rule or answer a dispute.

3. Define the rule, then compute

Apply your chosen definition and model to the stored seconds. Because the seconds are on record, the definition is a query you run, not a counter wired into the player, so revenue share is arithmetic you own.

4. Recompute and prove

When the policy changes, recompute any past month exactly, and when a creator or advertiser asks, answer from the row: this viewer watched 33 seconds of a 75-second episode on this date. The payment holds up because the evidence is still there.

Where the money actually moves, this pays off differently for each ICP. Creator and UGC platforms use it to run a revenue-share pool and hand each creator a per-view breakdown. OTT, media and microdrama syndicators use it to reconcile a per-view or per-hour licensing royalty against a partner whose "view" is defined differently, and to satisfy royalty reporting and rights compliance; the same watch data powers the microdrama funnel and retention views. Course platforms, worth noting, are the exception: they rarely pay royalties, so their version of this is completion gating certificates, not a payout.

None of this sets your rate or your split; that is a business decision, and a fair split can still feel unfair to a creator who earned less. What the per-view record removes is the disputes you cannot answer. With the seconds stored, you can pick a definition on purpose, change it and recompute the past, and show any single view. The revenue pool, the coins, and the payments live in your billing system, joined to this data on the viewer and creator IDs; FastPix provides the watch time and you run the payout math.

Build it yourself, in code

Here is what the whole thing produces: a payout view a PM or founder can read at a glance, and the code below builds it from one export. Every number here is the output of the code that follows, run on the sample file.

The whole calculation runs on one export: one row per view, with the seconds watched. Here it is end to end on that sample, using chdb (embedded ClickHouse) and pandas. The comments show what the code prints.

watch-time-sample-synthetic.csv: illustrative synthetic data, 260 views across 6 creators, one row per view with the seconds watched. Columns mirror a FastPix Video Data export.
Download the sample CSV ->

1. Load the per-view watch record

import chdb, pandas as pd
POOL = 10000.0   # your monthly revenue pool

v = chdb.query("""
  SELECT creator,
         CAST(video_duration AS Int64)/1000.0 AS dur_s,
         CAST(view_total_content_playback_time AS Int64)/1000.0 AS watch_s
  FROM file('watch-time-sample-synthetic.csv', CSVWithNames)""", "DataFrame")
# 260 views, 6 creators, 158 total minutes watched

2. Split the pool by watch time

mins   = v.groupby("creator").watch_s.sum() / 60
payout = (mins / mins.sum() * POOL).round()
# Marisol Vega $2,367 | Kest $1,841 | Dana $1,779 | Lumen $1,681 | Rio $1,467 | Nova $864

Each creator earns in proportion to the minutes their content actually held. That is the Spotify streamshare model, applied to watch time.

3. Or pay per qualified 30-second view

q30    = v[v.watch_s >= 30].groupby("creator").size()
pay_30 = (q30 / q30.sum() * POOL).round()
# Nova Reels collapses to $350; Marisol Vega rises to $2,378

Same pool, same month, a different definition, and the split moves. Nova's many shallow plays are worth far less once a view has to clear 30 seconds.

4. Change the rule and recompute the past

ff    = v.groupby("creator").size()          # a view = first frame
by_ff = (ff / ff.sum() * POOL).round()
moved = (pay_30 - by_ff).clip(lower=0).sum()
# $2,597 moves between creators, about 26% of the pool, on the same views

Because the seconds are stored, not a verdict, switching the definition is one line and the payouts recompute exactly. That is the whole reason to keep the raw watch record: you can change the rule, rerun any past month, and show a creator precisely why their number moved.