Video analytics for OTT platform: every report, and how it counts

When a viewer presses play, the player opens a session tied to the signed-in account and the device it is running on. As playback advances, the session accumulates watch time, tracks the furthest and current position, and, when the viewer stops, records the resume position. Completion rate is the watched portion measured against the title duration. A viewer who opens the same title twice creates two sessions; watch time sums across them, and the resume position is the latest.

The content analytics view groups sessions by title. For each video, episode or live event you see how many sessions it generated, the total watch time and the completion pattern. This is where a long documentary that everyone abandons at minute twelve shows itself, and where a short series with high completion argues for a second season. Read it alongside the revenue report, because the most-played title is not always the most-bought one.

Because every session carries the device and platform it ran on, the admin groups viewing by web, Android, iOS, Android TV, Fire TV and the add-on TV apps you ship. A session on a phone and a session on a TV from the same account count as one account and two devices in this view. The breakdown is by viewing, not by purchase; the revenue reports are organized by month rather than by device.

Separately from sessions, each account keeps a list of the devices it has signed in from. The admin shows this list against the subscriber, which is how support answers "which TV is my account on" and how you spot an account signed in from an implausible number of devices. This list is about sign-ins, not playback; a device that signed in but never played appears here and nowhere in the session reports.

The payment service writes a purchase record for every subscription charge and every pay-per-view or rental purchase it processes. The revenue reports sum those records by month, split between subscription revenue and pay-per-view revenue. Purchases recorded from the Apple and Google store-billed apps enter as purchases too, at the amounts the app reported. The report is a month grid, not a device or country grid, and it reflects what the platform recorded, not your bank statement.

The user watch-hours report sums session watch time per account over a period and lists accounts by hours watched. Underneath all of these, session and purchase records are written to warehouse tables built for reporting. Those tables are the raw material for any analysis the admin reports do not draw for you, such as joining purchases to viewing, and they are the place to point a reporting tool if your finance or content team wants its own views.

The revenue reports are organized by month and split between subscription and pay-per-view. The device and platform breakdown is organized by viewing sessions. There is no admin report that crosses the two to show revenue per device. The warehouse tables hold the purchase records and the session records a reporting tool would need to attempt that join, but the admin does not draw it for you.

A subscriber account can hold several viewer profiles, but the session record belongs to the account and the device. Watch time, completion and watch-hours are therefore per account. You can see that an account watched on a TV and a phone; you cannot see which profile was active. If per-person viewing inside a household matters to you, the multi-profile page explains why the platform cannot supply it.

The reports begin at the player and the checkout. Landing page views, campaign sources, sign-up funnel steps and search rankings are not measured here. A web analytics tag on the viewer site covers those, and the two data sets meet only at the account. Do not expect the admin to tell you which advertisement brought a subscriber; expect it to tell you what that subscriber watched and paid.

The admin shows the reports listed on this page; it does not include a drag-and-drop report designer or an ad hoc query screen. Any analysis beyond the built-in views happens against the warehouse tables with a reporting tool of your own. That is a deliberate split: the admin stays simple for daily use, and the tables carry the full detail for the people who need it.

Revenue figures are the purchase records the payment service wrote, at the amounts reported to it, and store purchases carry the amount the app reported. Refunds, chargebacks and payout timing live in each gateway and each store, not in the Flicknexs report. Reconcile the monthly revenue report against the gateway statements and, according to our pricing page, remember that store fees on Apple and Google purchases are set by those stores and will not appear in the platform figure.