Dimensions in video data to analyze your video content

If you’re analyzing video performance without using dimensions, you're working blindfolded.

You might know your platform had 2M views last week. Cool. But was that spike driven by mobile users in Brazil? Were iOS devices buffering more than Android? Did a new experiment variant tank your playback success?

You’ll never know — unless you’re segmenting your metrics.

This post is about how to move from surface-level dashboards to actionable observability using dimensions in FastPix Video Data. We’ll show you how teams use them in production to debug faster, ship safer, and deliver better video experiences.

‍

What are dimensions, really?

In FastPix, dimensions are data fields attached to each video view session. They describe the context in which playback happened: device, browser, region, CDN, stream type, app version, and so on.

A “view” without dimensions is just a number. A view with dimensions is a story.

‍

Why dimensions are not just “filters”

Most platforms treat dimensions like a dropdown menu in a dashboard: nice to look at, easy to ignore.

But real-world debugging and optimization require **correlation and context**.

Take this case: A global news app sees a 7% increase in “Exits Before Video Start” last Tuesday.

You could:

- Blame the video CDN.

- Guess it’s a bad player build.

- Blame a network outage.

But when they sliced by:

- Browser: 94% of failures came from Chrome v122

- Device type: Mostly on mid-tier Androids

- Connection: Predominantly on 3G

Now they knew the issue: A regression bug affecting lazy-loaded players on flaky connections — fixable with preload changes and version-based targeting.

That’s the difference dimensions make.

‍

What FastPix gives you out of the box

‍

‍

FastPix provides around 60 dimensions you can segment on — everything from `device_model` to `view_session_id`, `cdn`, `country`, and `exit_before_video_start`.

It supports:

- Multi-dimensional filtering (up to 2 dimensions at once in starter plan)
- Custom dimensions for anything you want to pass: campaigns, customer tier, referrer, etc.
- Programmatic breakdowns using the API (e.g., group `playback_failure_percentage` by `browser_name`)

Think of them like log levels for your video pipeline. Without them, your metrics are flat averages — and flat averages lie. Hide problems.

See what all Video Data do we capture.
‍

How real teams use dimensions in production

Here are scenarios where dimensions became the difference between guessing and knowing:

1. Auto-play loops burning bandwidth

A platform noticed a 40% spike in watch time - but retention hadn’t changed. Segmenting by `page_context` showed it was their home page’s autoplay hero video looping silently for returning users.

They tuned logic to cap plays based on `viewer_id` and real interactions.

2. AB test degraded QoE — only on iOS

An experiment showed improved load time globally. But QoE scores dropped 12% only for `os_name=iOS` + `video_cdn=Cloudflare`.

The change was rolled back for that segment only. Without dimensions, it would've affected everyone for a week longer.

‍
3. Ads causing startup failures on low-end devices‍

By segmenting `video_startup_failure_percentage` by `device_model` + `video_has_ad=true`, they found a bug where ads were failing silently on entry-level Androids.

‍

How to actually use dimensions in your stack

1. Pass metadata at SDK level

Make sure you pass the relevant fields when initializing the FastPix Data SDK for your specific video player.
‍

1const trackingData = {
2  workspace_id: "WORKSPACE_KEY",
3  video_id: "ep123",
4  viewer_id: "anon-7890",
5  experiment_name: "latency_opt_test",
6  player_name: "MainPlayer",
7  player_version: "1.9.3",
8  custom_1: "prod-build-202404",
9  video_stream_type: "live",
10  video_language_code: "en",
11};
12

‍

This enables segmentation by all those fields later — in dashboards and APIs.

‍

2. Use the API for segmented analysis

Let’s say you want a breakdown of playback failures by browser. You can do this programmatically using the `List breakdown values` API:

Request

curl --request GET \
--url 'https://v1.fastpix.io/data/metrics/playback_failure_percentage/breakdown?groupBy=browser_name&timespan[]=7:days' \
--header 'accept: application/json' \
--user '{Access_Token}:{Secret_Key}'

‍

Output:

[
{ "browser_name": "Chrome", "value": 0.031 },
{ "browser_name": "Safari", "value": 0.012 },
{ "browser_name": "Firefox", "value": 0.004 }
]

‍

This isn't analytics fluff. This tells you where your video is failing — and where to look next.

‍

Pro tips for production teams

‍
- Always tag your videos with `viewer_id`, `video_id`, `experiment_name`, and `player_version`. You’ll thank yourself later.

- Use custom dimensions to track app build versions, user plans, campaign codes — anything you’d want to filter on.

- Treat views as sessions, not page loads. Tie them to `view_session_id` for upstream correlation with CDN logs or backend events.


TL;DR

High-level QoE scores and other metrics are useful for reporting. But they don’t tell you why something broke — or who experienced it.

Dimensions turn video metrics into a debugging surface, not just a reporting layer.

If your observability stack doesn’t support this kind of slicing, you’re not operating at scale. You’re flying with nice graphs and no instruments.

Want to see it in action?

You can:

• Explore FastPix Video Data
• Read the full Video Data docs
• Use the /dimensions API to discover what you can segment by

Or drop in the SDK, pass your metadata, and see what dimensions unlock in your observability stack.

Because debugging video performance without them? That’s guesswork.