SOLVED

Surprise viewing stats for Stream (on SharePoint) video

Iron Contributor

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. 


11 Replies

@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. 

@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?

 

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).

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

@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. 

@Marc Mroz 

 

Are there any updates on the analytics issues set for Q2 delivery? We are currently looking for other platforms because of this issue and would like to stay with Stream if possible.  Thanks!

@2020FD A fix is in development. We are estimating deployment in January 2024.

As Brian said we have a fix for this now, it’s under final testing and deployment. Hopefully we don’t hit any new issues and it can be deployed in January or sooner.
Will this retroactively change the view count as well, or only future view counts? We're seeing massive view counts on videos that are embedded on the intranet homepage which is loaded by default on opening Edge. So each video gets almost the maximum unique viewers based on employee count in the company. Everybody is happy with that of course but we lose the insight on actual video consumption. I would also expect to get a count of views who completely watch the video or at least X percentage. Is that coming as well @Marcmroz?
@BrianLarsen24,
Is there any update on this fix?
best response confirmed by Marc Mroz (Microsoft)
Solution

@JWiersem1925  & @prossum123 - The change was made and deployed toward the end of November. It doesn't retrospectively fix past view counts but changes how views are tracked for new views going forward. Instead of relying on if we fetched information about the video from ODSP it increments a view only when the player actually gets the signal that the user played the video for a few seconds. 

 

This puts us back much closer to the way view counts were tracked for Stream (Classic). We do not have plans at this time to change the view counts to only happen when a user watches for X percent or to the end. 

1 best response

Accepted Solutions
best response confirmed by Marc Mroz (Microsoft)
Solution

@JWiersem1925  & @prossum123 - The change was made and deployed toward the end of November. It doesn't retrospectively fix past view counts but changes how views are tracked for new views going forward. Instead of relying on if we fetched information about the video from ODSP it increments a view only when the player actually gets the signal that the user played the video for a few seconds. 

 

This puts us back much closer to the way view counts were tracked for Stream (Classic). We do not have plans at this time to change the view counts to only happen when a user watches for X percent or to the end. 

View solution in original post