Surprise viewing stats for Stream (on SharePoint) video

[Ray Harrison]

On our homepage we shared a Stream (On SharePoint) embed video.

In looking at the document library and the file statistics we were surprised to see very very large numbers. Fantastic, we thought...

We believe the views figure being shown is the page load, with the Stream buffer not actual plays of the video.

The figure, we believe, is misleading - where do we get the actual proper having pressed play stats from?

This has also provided misleading data to within site usage too. A jump from ~5,000 to ~120,000

I've tested further by adding a different video to a new page and refreshed the page. No plays have been triggered but the video file is showing as having been viewed multiple times. 

[#2 · Accepted solution]

@Ray Harrison - I believe this is happening because the view counts from ODB/SPO that we leverage are all based on when the action of "file accessed" happens. But the problem is that when we load our player to get it ready for a user to click play we are having to "access the file" to fetch info about it, metadata, etc. Thus you are seeing that just loading the player without playing causes a view count increment.  We are aware of this and building a plan to address it. I don't have a timeline to share but we are starting to put changes in place so that you don't get a view count for videos unless you actually play it. 

[#3]

@Marc Mroz Thanks for the confirmation. Is there a formula to use viewer retention % against the "fake" viewer count to get the actual view count? Or anything else that is possible in the interim?

[#4]

There isn't anything I can think of yet. I'm asking the analytics team for more details on how the "incorrect" view count works and in what cases. (Sorry for the delay I was out of the office most of December).

[#5]

@Marc Mroz  Happy New Year - thanks for checking in Marc and for continuing to consider the issue. 

[#6]

@Ray Harrison - It looks like we count a view in the current code anytime...

1.  The manifest for the video is fetched when the player is going to do adaptive streaming
2. The video is downloaded for progressive playback

So, the overcounting of views isn't quite as bad as maybe we thought. 

#2 means the user is actually playing the video so that's fine to count as a view.

#1 Means the player has loaded the video and could be waiting for the user to hit play. However, in most cases this will only happen if...

• The user has navigated directly to the player page for a video
• The user hovered over an embeded video and it removed the fake play button and loaded the player. In most embed cases we first render a fake play button and depending on the service that integrated the iFrame the user needs to click to load the player (and have the manifest fetched) or hover over it. 

So... I don't think this info really helps other than to say I don't think the over counting is quite that bad but it's still inconsistent from what we want. We think that we'll begin coding on a fix for this to only count views for videos when someone actually hits play in Q1 CY2023 and hopefully ready to ship to you some time in Q2 CY2023.