Israel Streaming Project

FROM IMPLEMENTATION TO PUBLICATION - PROCESS

The process of verifying your stream implementation follows four big steps: Unit testing, Comms testing, Go-live acceptance testing, and Operational testing.

Unit Tests for Initial Implementation

By the time the broadcaster gets his hands on a library, the package has already run through unit tests that have been conducted by Kantar.

Communications Tests

In this phase the http-requests that are being sent from the Kantar library inside your player to the collection servers are tested and verified.

Desktop Player (“dotcom”) Streaming Measurement implementations:

For desktop player implementations, you will need to observe the log stream data and verify the content of the heartbeats. You do this by running a simple analysis of the http-requests sent from and to a browser whilst your webplayer is operating.

There are NO warnings or error messages produced using this method, it is a simple tracking of the http requests sent to the Kantar measurement systems.

You can observe an example of a correct webplayer implementation using an http analyser such as the "httpfox" plugin in Firefox or "developer tools" in Chrome.

Step-by-step instructions for running an http-request Analyser:

You can see an example of the heartbeats sent from the Kantar libraries here:
kantarmedia.atlassian.net/wiki/spaces/public/pages/159727225/BARB+TVPR+Test+Tool#BARBTVPRTestTool-Heartbeatssentfromthelibraries

Once verification is complete your implementation can move to the next QA stage.

Mobile App Streaming Measurement implementations:

For mobile streaming apps, a data verification test tool has been developed by Kantar for use by the Broadcaster development groups. It allows you to analyze and test the output records generated by the Kantar library app integrated within your player in real-time.

This document covers:

• The heartbeats sent from the Kantar libraries
• How to verify the accuracy of your implementation
• How to operate the Kantar Testing Tool

Once the log stream test tool verification is complete, your implementation can move to the next QA stage.

Go-Live Acceptance Tests

Before live release, your desktop or mobile app player integration must pass tailored acceptance tests to ensure it adheres to the desired project outcomes.

Every player works in subtly different ways and is often subject to customisation. Desired behaviours must be understood in the context of the functionality and user features specific to your player. The specific acceptance criteria will be determined as a result of discussions between developers and business analysts at both the Broadcaster and CSM/Kantar.

CSM/Kantar will support this process to assess desired behaviours, e.g. correct handling of stream interruptions. We will undertake acceptance testing of your desktop or mobile app player integration if you can make a staging/beta release available.
For mobile app streaming measurement implementations we recommend you share your build using the test flight platform:

https://testflightapp.com/

We will provide our device/account details. Other methods or products for providing access to a pre-release version of your implementation are of course also accepted.

The table below describes example test scenarios.

The table below describes example test scenarios for live streams.

We will provide written confirmation once acceptance tests have been successfully completed, signing off your implementation.

Publishing your player

With acceptance tests complete, you may now schedule your implementation for publication. 
Please:

1. Inform us in advance of the go-live date
2. Change your site-specific sitename from test value to live measurement, e.g. sitename "sampletest" must be changed to "sample". 

You will use your site-specific test sitename ("sampletest") for testing future upgrades in staging environments.

The Live Operational Calibration process is used to “calibrate” the project metrics in the weeks immediately after your player implementation goes live.

These are reviewed between the FSC and CSM/Kantar. At the end of the process, your data will be signed-off for publication on an ongoing basis. All calibration phase data and discussions are in the strictest confidence.

Managing Future Updates

Once your integration is live, library sensor code changes will be infrequent. Changes will largely be driven by software environment changes (e.g. introduction of Apple IDFA/IFV). When a new Kantar library becomes available, you will be notified whether the update is critical to the measurement and therefore mandatory, or whether an upgrade can be scheduled at your discretion.

Integration and testing of your player with the new Kantar library code must not take place on your live system – you must not use your live sitename at any point during the integration process. Your live service is protected during the testing stages by simply directing your test traffic to your alternative site-specific test sitename, e.g.

Test traffic directed to sitename: sampletest
Live traffic directed to sitename: sample

Once the upgrade implementation has been verified by all parties, you will be advised to switch to your standard sitename before publishing your upgraded player.

CUSTOMER DATA PRIVACY DOCUMENTATION

Here is an overview of all the types of data that is being collected and/or processed by Kantar in the context of the project.

1. Stream metadata that are explicitly defined in the video players by the broadcasters. See at:  General metadata tagging instructions.
2. Stream metadata that are not explicitly defined in the video players by the broadcasters, but are rather automatically transferred to and via the libraries' functionalities:
   
   1. Device identifiers:
      
      1. From web players: 
         cookie-ID
      2. From iOS devices: 
         Apple Advertising ID (IDFA) and the ID for Vendors (IFV) for iOS 6/7, mac address for iOS 5. All are MD5 hashed and truncated to 16 characters.
         NOTE: full unencrypted ID's are never sent to our systems!
      3. From Android devices: 
         Google Advertising ID, Android ID and Device ID (MD5 hashed and trunctated to 16 characters) 
         NOTE: full unencrypted ID's are never sent to our systems!
   2. Screen resolution (!= stream resolution)
   3. Viewtime, contact time with the player, including all buffering, pausing, advertisement. This is different from "playtime"!
3. Data that are inherent to internet traffic and the measurement process:
   
   1. IP-addresses are used for processing, but they are not saved. They are used for:
      
      1. Geo-location of users.
      2. Determining the ISP of users.
      3. When no cookie is accepted: creating a browser fingerprint based on IP+browser user agent.
   2. Browser user agent where applicable.
   3. Timestamps when heartbeats are received.

Informing Users

With regards to data privacy, there is an obligation to inform the user that the application monitors the user actions and transmits them to a measuring system. Furthermore, the user must be informed that he has the possibility to switch of the tracking in the application and how to do this.

For this purpose, you can use the following example text in an appropriate place in your app implementation:

Opt-Out on Mobile Applications

The library offers the following method to do this:

Opt-Out on Desktop Player

In the web-environment, the opt-out mechanism uses a specific cookie content to identify the client who does not want to be measured. Due to the fact that a direct and/or standardized way of recognition of the client is not provided, there is no other way to identify such clients.
A client is able to change his identity anytime (e.g. by cookie deletion). Such an identity change always leads to a loss of specific settings of the initial clients (causing them to appear in the system again from the moment of change).

Therefore it is necessary that the client who refuses measurement, communicates this setting to the system constantly. This means that the client may not delete his specific cookie.

The optout page for the project is located at http://optout.2cnt.net/. Any broadcaster can link to or embed that page on their own pages.

More information can be found at https://kantarmedia.atlassian.net/wiki/spaces/public/pages/159726816/OPT-OUT+and+Anonymization.

TBC...