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