Page Comparison

...

Then Select the operating system of your app: Android, iOS …
Click the button "Start test!"

Step 1

...

Image Added
Illustration 1: Initial main screen

Now start the app to be tested on the test device or emulator identified in Field 2 above.
Begin your testing by starting the stream..

Understanding the test output

The live results of this test will be displayed on the main Output screen (see below).

Image Added
Illustration 2: Example main output screen

In the Events section of this page you will see:

• A counter with the analyzed requests. The screenshot example above contains a “12” in this box, indicating that “12” requests have been generated up to that point.
• Any messages generated by the 'validator'. The validator assesses specific TV Player Report project variables such as the library version being used, content ID, and the stream variable. The full list of items that are validated is held at the following link:
  BARB TVPR Project#Playermonitoringrequirements

The stream requests are split out on screen within the large bars. The screenshot shows these in red and yellow. The status of each section is colour coded to highlight specific warnings when something is incorrect:

•  Red: Error
• Yellow: Warning

Once all parts of the request are correct, the app will return no error messages, indicating that your implementation is correct.

Important additional information about the on-screen interface

Below the main bars in the Events section of the page, the tool also contains 4 greyed out round ‘traffic lights’. These indicators are used to highlight the following standard mobile app actions:

• STARTED
• FOREGROUND
• BACKGROUND
• CLOSED

You may see these traffic lights “go green” during your test as each action is positively verified. This is purely documentary and does not indicate whether your TV Player Report project implementation is correct.

‘Warning’ or ‘Error’ messages

Should you encounter ‘Warning’ or ‘Error’ messages then:

1. Verify and check your implementation – you can view the log stream requests to help you further understand the error (see below for more information)
   or
2. Contact the Spring technical group at support@spring.de. Please ensure that you copy our main UK TV Player support team at TVPlayerSupport@kantarmedia.com.

Viewing your log stream requests

Press the "View Request" button to view all the information in a JSON object which contains all messages from the Validator.

This output can only be viewed on screen – it cannot be output to a file.

Example of a correct implementation

Below we demonstrate use of the tool by providing a UK example.

Setting up the test tool

Image Added

We left the first field (app name) blank because it is optional.

In the second field we put the Advertising ID of our Apple device.

In the third field we put the sitename (c4ios).

Last but not least, don’t forget to highlight the proper OS!

(In this case we are testing the 4oD iOS app).

After clicking “Start test!” and a stream has been running

Image Added

After starting the test tool and then starting the player, you will see the event counter counting through the number of requests as they are processed.

Here we see we have a green round from a successful “app-start” event.

When clicking the “Viewrequests”

Part 1

Image Added

In the above screen shot, we scrolled down through the list of all the heartbeats sent during the test.

In order, you will find:

• The number of the heartbeat sent: 34,
• The time when the server received the heartbeat,
• The app name: 4oD. (This value is obtained from the library app installed in the player and is populated if you have not entered this value in the first screen)
• The Apple Advertising ID after the Kantar Spring library hashed and truncated it and sent it to the measurement systems
• Then follows either a list of the errors and warnings, or as in this case: an “OK” message.

Part 2

Image Added

In next part of the test the heartbeat data is broken down and parsed into a readable format.

See TVPR Test Tool for an explanation of the content.

Metadata:

• “v” = the version of the Kantar Spring library used
• “app” = appname as defined by the broadcaster
• “ai” = the hashed and truncated device identifier. (here: Apple Ad ID after hashing and truncated)
• “pl” = the player name as defined by the broadcaster
• “sy” = horizontal screen resolution
• “plv” = the player version as defined by the broadcaster
• “sx” = vertical screen resolutionU
  

Usage data:

•  “uid” = the viewing session ID; generated at random by the library when it is started
• “stream” = stream identifier as defined by the broadcaster.
• “pst” = the playstates, i.e. the content playhead position(s). The position of the playhead at the time this heartbeat was sent, was at 1204 seconds.
• “vt” = viewtime.
• “cq” = The content ID, used to uniquely identify the content of the stream.
• “sy” = horizontal video resolution (as opposed to the same variable in the metadata)
• “sx” = vertical video resolution (as opposed to the same variable in the metadata)
• The other variables are additional and optional info that the broadcaster defined via the “desc”-variable.

Conclusion

This implementation is correct from a format point of view and the output can be correctly pro-cessed by the Kantar Spring systems.

The app can now be considered “ready” for the BARB TV Player Report project!