We consider concurrency based on the viewer actually playing within the same minute as another viewers. A basic example would be someone starts playing at 5:02:55pm the user would be counted as 1 concurrent viewer for 5:02pm (similarly if she stops watching at 5:02:01pm the user will still be counted as 1 concurrent viewer at 5:02pm.
There is no timeout etc going to determine if a session is still "concurrent" or not. We base this distinction specifically on the actual beacon events being sent. So if a viewer hits pause stopping playback, the viewer will no longer be counted against the concurrent plays. Once she resumes playback she will continue contributing to the concurrent plays.
Examples: Let's assume we have one person (Alice) starting to watch at 5:03pm and another one (Bob) at 5:05pm. Alice then hits the pause button at 5:06pm and resumes playback at 5:10pm. The concurrency numbers would look like this:
If we had a timeout mechanism, sessions would carry over into minutes where no playback happened for a certain amount of time thus making the numbers less accurate.
Note, the metric shown in the dashboard is also the maximum concurrent viewers, which means unless you are looking at minute resolution you are looking at the maximum per-minute concurrency within an hour. So the concurrency value for the hour 5-6pm would be 2 in our above example.
Another example for this with more users:
As you can see during the 5pm hour of our example at 5:10, 5:11 and 5:13 we had 3 users concurrently watching the stream so the maximum concurrent viewers in the 5pm hour was 3.
We also offer the average concurrency throughout the hour, which is interesting in cases where multiple peaks happen:
As you can see, the values in the beginning and end of the hour drag down the average concurrent viewers to 1.9 whereas the max concurrent viewers is 4.
Updated 7 months ago