Solving The Challenges of SSAI Measurement
Many streaming operators, especially those offering live streaming and FAST services, are moving to server-side ad insertion (SSAI). There are a multitude of reasons for this. First, SSAI offers more of a broadcast-like ad experience as ads are “stitched” into the stream in real-time. Second, because ad insertion happens prior to the player, there is less impact on the client of fetching and integrating ads (which can require additional code). And finally, perhaps most important, ads served through SSAI are not addressable by client-side ad blockers. Despite these pros, there is a significant con of SSAI: measurement accuracy. Thankfully, there is a solution to filing the gaps in SSAI ad measurement.
Understanding the Measurement Issues with SSAI
The core measurement issue revolves around how SSAI is integrated into the ad tech stack. Ads delivered in this way require an Ad Decisioning Server, whose job is to supply the ad for insertion. Ads are supplied to an Ad Insertion Server which transcodes the ad to match the video’s bitrate ladder, packages the ad, produces a manifest for the ad, and then stitches the ad’s manifest to the video manifest.
The issue is the data upon which the operator has to ensure a view or impression. Data from the Ad Decisioning Server can only tell them that an ad was requested and it was sent to the Ad Insertion Server. The Ad Insertion Server can only tell them that the ad was received (or not received) and stitched into the manifest (or not). But there is nothing which indicates whether the ad actually played to the viewer.
The solution to this actually lies in the client!
Solving the Server Issues With a Player Solution
At the heart of understanding the ad experience, and, more importantly, determining ad playback and if it counts towards a contractual view or impression, is the client. Datazoom can already collect a variety of client-side data elements to help in ad tracking. But we have recently announced client-side data collection specifically for SSAI.
https://www.youtube.com/watch?v=JEyh5iklFmg
As you can see in the demo video, there are a number of ways this new capability can improve ad data for operators employing SSAI:
| Benefit | Description | Applicable Client-side Data Points |
|---|---|---|
| Visibility into ad delivery | See exactly where and when ads are being delivered, which can make it easier to optimize ad delivery and troubleshoot issues. | device_type, user_agent, OS, custom_metadata |
| Measuring viewability | Data gathered about what ads were actually viewed, can only be gathered at the client. When collected with Datazoom, this data can be married with the data from the server (using an ad ID), in a single dashboard (such as a Looker Block) to provide true measurement of ad views. | player_viewable, player_viewable_percent |
| Accurate ad impressions tracking | Instead of relying on tracking from the server, ad impressions and other key metrics can be tracked with parity to CSAI. | ad_impression, ad_id (coupled with enrichment) |
| End-to- end measurement | Client-side tracking removes limitations on the ability to measure the entire ad delivery process, from ad insertion to ad delivery on the client-side, which can make it easier to understand the full user experience. | Ad_session_id encompassing the entire event stream |
With Datazoom’s new beta release, our customers can capture verified impressions of users playing video ads embedded/inserted within a live or on-demand video stream from our SDKs and libraries.
Improving SSAI Targeting With More Client Data
Using client-side data to augment SSAI for better measurement also has another benefit: improving SSAI ad delivery. One of the main arguments for CSAI is for contextualization. There is a host of data which can be gathered from the client and used to better target ads. This can, ultimately, help increase the value of ad placement for the operator. This new feature from Datazoom provides a unique way to add that same value to ads delivered through SSAI. For example, device-level data, such as IP address and device type, can be fed from client to SSAI Decisioning Server, where SSAI occurs.
As you can see in the illustration above, by connecting SSAI and client-side ad data, operators can now see, in near real-time, a user event stream that shows exactly when an ad break starts, the ad request is made, the impression is recorded, and how long a user sticks around before click the ad_skip button. Each of those events are decorated with a number of dimensions for one to determine where ads are working and where they are not.
CSAI Is No Longer The Clear Winner
The decision of CSAI over SSAI has long been driven by the prospects of personalization and the increase in the value of each impression. But with this new Datazoom feature, that tradeoff no longer needs to happen. Streaming operators can choose SSAI to avoid ad-blockers, for example, but still get access to valuable client-side data which can be used to target ads before they are stitched into the final stream.
Interested in seeing this in action? Reach out to Datazoom today to schedule a demo.
So You Want To Personalize The Streaming Experience...
When it comes to the core difference between traditional broadcast and streaming, it’s all about data. Broadcast provides very little information about the viewer. Even for those with Nielsen boxes attached to their television sets, it’s only basic demographic information tied to what’s been watched. It’s near impossible to understand the relationship between those demographics and viewer behavior to everything else the viewer might be doing across the digital universe. But with streaming, it’s completely different. Viewing behavior within streaming content can be related to other digital activities to create comprehensive insights which can be used to recommend or suggest new content, tailor ads for greater impact, and more. Many would argue that personalization is not only the future of the streaming video experience, but a critical element that streaming operators must provide to improve engagement and reduce subscriber churn. Below, we’ve provided a step-by-step understanding of how you can find the data, collect it, and piece it together for a richer data picture of individual viewers which you can use to personalize the streaming video experience.
Why Personalization?
It’s not hard to understand why a personalized video experience might be better than a generic one. When a viewer feels that an app interface, or content recommendation, or the player experience is tailored for them, they are probably more likely to stay engaged longer (whether that’s in the streaming platform or with a specific piece of content). And for ad-supported models, that means more impressions because that viewer is going to watch more video for longer. There isn’t much data about the impact of personalization on viewer engagement and subscriber retention, but some early indicators, such as in a survey by Concentrix, indicate that, “over 70% of subscribers say they only engage with personalized messaging, and nearly 65% will stop buying from brands that use poor personalization tactics.”
The Many Opportunities of Personalization
Personalization, though, isn’t relegated to just one dimension of the video experience. One of those, of course, is content. Raviteja Dadda, a Forbes Council Member, identified a number of ways the content could be personalized to a viewer including curation, recommendations, and promotions. For FAST providers, curating content could mean a personalized channel for each viewer that includes both recommended and promoted assets. But there are other places to personalize as well including advertising, the interface itself (adding contextual menus to content categories the viewer often watches), and even commerce opportunities. For example, a streaming platform could blend third-party data, such as purchasing history at a major retailer, with first-party data about content watching, to suggest purchases during the video experience itself. In all of these cases, the personalized experience communicates to the viewer that the streaming brand (the platform operator) understands their wants and needs. This makes the subscription all the more valuable.
Convincing the streaming industry that personalization is the future, though, isn’t hard. What’s hard is understanding how to carry it out and getting the data you need to make it happen.
What’s The Data And Where Can You Find It
At the heart of personalizing the streaming experience is data. Data about what’s watched (and for how long), when a viewer abandons a video (and where in the video that was), how other people like the viewer are behaving (cohorts), and third-party data such as that from Google, Amazon, and other sources. Although it’s up to you from where to source any third-party data, there is quite a lot of first-party data that might already be available to pull from within your streaming video technology stack.
When we built the Streaming Video Datatecture, we tried to capture all of the various systems that throw off data which might be used to personalize the video experience.
As you can see, there are not only multiple categories of data but multiple providers within each category. Depending upon how your stack is put together, you may be looking at ten, 20, or even 30 sources of data which can be connected and correlated to provide a more in-depth picture of an individual user. The data is not just about what happens in the video player, though. It’s also about other metrics such as user behavior within the interface, abandonment, clicks, and even the bitrate ladder. For example, if a viewer often selects 4K videos but the data shows that bitrate is never reached, it might make more sense to suggest content to them that is 1080p HDR (which may also reveal a wider library of assets for the viewer).
To personalize the video experience, there are three key steps. First is to collect the data. Second is to correlate the data together. And, third is to connect the resulting data set to your video platform in real-time.
Step 1: Collecting the Data for Streaming Personalization
It might seem like an easy task, but it’s actually not. Although many components within the streaming video technology stack make their data available (often through APIs), some don’t. And even if you can gather the data easily, it’s not a one-off task. You’ll need to build a proper data pipeline with connectors to each data source. This can be quite resource intensive out of the gate. You’ll need developers to build those connectors and ensure that they can be maintained easily going forward in the event that an API call or end-point is changed by the component owner.
Step 2: Correlate the Data for Streaming Personalization
Once you have access to all of the data in a pipeline, you’ll need to send it somewhere for post-processing. Usually, that’s a visualization tool. And although such a tool may be useful for analytics purposes, it’s not necessarily useful for real-time personalization. Because of that, your data pipeline will need to feed a datalake against which business rules can act on the data to normalize it and stitch it together (imagine data cubes for each individual viewer). In some cases, this may require standardizing specific metrics, like a user ID. Because of the need to normalize, just like with Step 1, there’s some heavy lifting that needs to happen up-front. But, once you get your business logic set up, you probably won’t need to change it very often unless the data sources themselves change.
Streaming Personalization Won’t Succeed Without A Good Data Model
The business logic that you build around the individual viewers isn’t just about normalizing and processing. It’s also about thresholds, or indexes. For example, you’ll want to build a data model for personalization that includes scores for specific personalized elements. When thinking about personalizing the user interface, each dynamic menu item will need to have a score to appear. So if a specific viewer has an index of .33 for a given interface item, it won’t display. But a viewer with an index of .79 would see that interface element. To make this more concrete, imagine that your interface includes menu items for specific genres of video. If the index is above the threshold for a viewer in a specific genre, that genre menu item would appear helping them to discover content more easily that the data indicates they prefer to watch. This can also apply to recommended content as well. Just because a viewer has watched one content asset doesn’t mean they are immediately going to be interested in something related (either by actor or genre, or within their cohort). Each content asset should, for each viewer, eventually have an index that determines how it fits into individual cubes of viewer data. As you can imagine, this is no easy task but it pays off in the long run because those index scores become the knobs and switches that you can use to optimize personalization.
Step 3: Connecting The Personalized Data To Your Video Platform
It’s probably safe to say that your platform isn’t built with personalization in mind. Although some elements, such as a video asset reel, are probably dynamic and can be easily integrated with a personalized data set, your interface may not be. So you’ll invariably have to do some development work to enable personalization for other aspects of your platform. But, once this is done, you’ll be able to leverage those individual viewer datasets to truly create a customized experience.
Streaming Personalization Isn’t a One-And-Done Activity
Even if you follow those three steps, your work isn’t done. That’s because the underlying challenges aren’t just acquiring, normalizing, and integrating the data. There’s another obstacle that can actually undermine the whole effort: real-time. Personalization can’t happen once for each viewer. It must be continually updated. And, to make it truly impactful, it should be carried out even as the viewer is interacting with the platform. Think about it this way: each piece of content the viewer watches, each click, each ad viewer, adds to their cube and can affect recommended content or a changed interface element. For example, what if a viewer watching a horror movie finally tipped them past the threshold of displaying the “horror” category in their interface menu? You wouldn’t want them to wait until logging in again to see that. You would want to display it immediately, perhaps even with a “new” badge, so that they would jump right into the next piece of content without having to find it.
But getting data in real-time can be difficult. Most streaming operators aren’t staffed to create real-time pipelines. Yet if personalization is truly the next evolution of the streaming experience, no operator can afford to ignore the need to build out a data function within the organization, one that can create connectors, build business logic, define a data model, and integrate everything with the platform itself. It’s hard work, no doubt, but the benefits of improved engagement rates and less subscriber attrition, are well worth the efforts.
Datazoom specializes in enabling streaming operators to create data pipelines. If you’re interested in understanding more, and even seeking a resource to help you collect the data you need (and assist you in buildind a real-time data pipeline), contact us today!
Interested to learn more about how you can join data collection from end devices to the Chromecast? Contact Datazoom today.
When Viewers Chromecast, Are You Left In The Dark?
When Google Chromecast entered the market in 2013, it exploded in popularity as it represented a way for viewers to watch streaming video when there wasn’t an easy way to access some streaming services, like YouTube, on SmartTVs. And although the landscape has matured significantly over the subsequent 9 years, casting still remains a popular method of watching on the big screen. In fact, according to Conviva’s State of Streaming Q1 2022, Chromecast accounts for 4.3% of total streaming activity.
So casting is probably part of your streaming traffic. At least 4.3%. But what happens when the viewer initiates a content session on their mobile phone and elects to cast it to their SmartTV? Who knows, because you are now in the dark.
Understanding the technology of casting to Chromecast
When a viewer initiates a casting session (this is called the Sender: an application on a device in which the viewer has started a video and clicked or tapped on the “cast” button), it is basically slinging the video stream from the device to a player on the Chromecast. That player comes in one of three types:
Default Receiver. This is the basic player app hosted by Google
Styled Receiver. This is Google’s basic player app plus some customized user interface changes to make the player which appears on the TV better match the publisher’s brand.
Custom Receiver. This is a dedicated HTML5 page built & hosted by the publisher allowing them to have advanced control of the playback experience on the Chromecast device.
This would be very similar to a viewer opening up Chromecast on the TV and typing a URL into a player or selecting an app and launching a content title. But, of course, that’s not how Chromecast works.
What happens to the player data during a Chromecast session?
The challenge is when the user initiates a “cast” session, the burden of capturing behavioral data (like stopping, starting, pausing, fast forward, ads watched, etc.) is usually handed off to the Chromecast receiver as that is the player through which the viewer is actually interacting. It’s possible for the receiver to send some data to the sender (so Chromecast to the app from which the cast event started) but, depending on the implementation of this relationship, the sender may disconnect during playback which would stop even this data stream.And although you can capture the cast activity within the sending application (from which the user has initiated the “cast”), you can’t capture data after the cast unless you have some code on the Chromecast itself. It’s probably pretty clear that this can get complicated as you need to maintain collection code on multiple players.
That’s where the Datazoom SDK comes in.
The Datazoom SDK is a piece of JavaScript code you can install in a sender application and within a Chromecast custom receiver page. This will allow Datazoom to collect playback data during a user’s casting session.
How the Datazoom Chromecast collector system works
Whenever a Datazoom Collector SDK is instantiated, an app_session_id is generated to help tie all of the data together that belongs to that session. When media is requested, a content_session_id is also created to help identify events and data that belong to a specific media playback session. During casting both the Sender & Receiver will have active App & Content sessions.
When the user chooses to connect to a Chromecast and begin casting the content to the biggest available screen, the Datazoom SDKs on both the Sender & Receiver coordinate a data collection hand-off. This signals that the user has begun casting and that the casting application has the Datazoom SDK as well. This process tells you, during data analysis, that data about the viewing session will come from the Chromecast rather than the player application on the device.
We call this orchestration.
When the Sender Collector SDK & the Receiver Collector SDK have a successful orchestration handshake, they will fire an event to Datazoom called cast_transfer. This event is intended to signal that a handoff has taken place between a Sender Collector and the Receiver Collector. They will only fire if a Datazoom Collector SDK is present on both the Sender & Receiver applications.
So do you absolutely need the Datazoom SDK JavaScript on both the Chromecast and in your player? The short answer is yes…if you want visibility.
Three use cases for data collection during a Chromecast session
To understand the relationship between the sender and the Chromecast, think about these three use cases:
Datazoom SDK is only installed on the sender device
Datazoom SDK is installed on both Chromecast and sender device
Datazoom SDK is only installed on the Chromecast
#1: Datazoom SDK is only installed on the sender device.
Maybe you’ve elected to use the Default or Styled Chromecast receiver. Or maybe you don’t think you need any programmatic hooks on that device. Regardless, when casting begins, the Datazoom SDK on the sender fires but there is no orchestration so all you’ll see, in your data analysis, is the cast_start event followed by any data from the sender. If the sender disconnects from the Chromecast device, data collection will stop.
#2: Datazoom SDK is on both devices
You’ve decided that you want to collect viewer behavioral data on both your sending device and the Chromecast. When casting begins, the handshake is initiated and the following takes place:
The sender application sends its session identifiers to the Chromecast and the Chromecast sends its session identifiers to the sender
The sender application sends a cast_transfer event to Datazoom which contains the Chromecast’s identifiers which were provided during the handshake
The Chromecast sends a cast_transfer event to Datazoom which contains the sender’s session identifiers which were provided during the handshake
The sender application stops sending more events until after casting ends
The Chromecast sends all selected Collector data to Datazoom, including both the sender and Chromecast session identifiers (to facilitate data analysis)
#3: Datazoom SDK is only installed on the Chromecast
In this case, the Chromecast collector will function just like a normal video player collector, sending data back to the Datazoom platform. But with no cast_transfer event linking it to a playback session on a sending device, there’s no way to really attribute the behaviors during the Chromecast session to a specific user.
How the Chromecast collector allows you to see the big picture about casting viewership behavior
You’ve hopefully come to the conclusion that it doesn’t make sense to install the Datazoom SDK on just one end of this relationship. To understand the Chromecast viewing session in relation to the viewer who cast it, you’ll need the Datazoom SDK integrated both with the sender (your app or website video player) and the Chromecast (only via the Custom Receiver). So what does analysis look like?
The Sender & Receiver data are represented by unique app & content sessions. Although their data, including events, metadata, and timers, can be analyzed independently (treating them as separate users) it is possible to join the two datasets together and create a comprehensive view showing the user journey, QoE, and time spent viewing across both devices. You can then derive all sorts of interesting insights, such as the amount of time a user casts versus watching through the sender device, behavior while casting (as it differs from watching on the sender app), etc.
Don’t be in the dark about casting when your viewers cast to Chromecast. Let Datazoom light your way
Although casting may not be a dominant way that users watch streaming video, it’s not inconsequential. As such, you need to have that insight about behavior which happens after the user has cast a video from their device to the big screen. This will help you not only create a better picture of your viewers but also provide insight to advertisers and other business partners. And, it can even help inform you about content and recommend titles, which are commonly cast, to users who cast more often.
Interested to learn more about how you can join data collection from end devices to the Chromecast? Contact Datazoom today.