Broadly speaking, the NPO Tag measures the supply (content/pages/views) and demand (visits/streams/clicks) in the NPO Start/Plus environment. This encompases:
and uses three types of information to contextualize these events:
The first two pieces of information are set globally, whereas the third is set for specific events, such as offers, choices or clicks.
A lot of information about the page and user are shared over many events. For instance, the user will be the same for all offers shown on a page, and all stream waypoints. The NPO Tag SDK allows you to set these across events by passing them to the tracker object. This information is critical for NPO to determine what and where users experience things on our platform. It is critical that this information is provided before sending events so that all required information is present. On web, this is done using the NPOLabels object, on Android the PageLabels property of Topspin must be updated before calling init, on iOS the pageLabels setter methods must be called before sending events.
In some contexts, such as Web, user information can be set as part of the labels update or by calling the setUser method. In others, such as iOS, the profileId and subscription-type must be set by calling the login method of the tracker object.
Context information MUST be provided before sending any events
The most simple measurement is the pageView. The event equivalent for non-WEB platforms is contentView. It is a simple event with information about the page that is being visited by the user. This provides us with information about the ease of navigation through our platform and relative impact of changes. Apart from platform-wide fields such as the brand, brandid and environment, key fields for pageview events are the niveau1…3 fields, that provide information on where in the sitemap the page is located. For example. a collectionpage, of collection X. Please refer to your platforms tagplan for details what values to provide for every specific page.
A pageViews/contentViews should be send any time the screen is filled with a new layout
| Field | Description | Example |
|---|---|---|
| merk | whether this is an NPO or standalone context | npoportal |
| merkId | integer associated with the brand, 4 for NPO | 4 |
| niveau1 | the top-level context, null for the home page | programmas |
| niveau2 | a narrower context, such as profile for profile related pages, the program-name for a program-related page | op1 |
| niveau3 | most specific context, often null, but sometime the name of the particular episode or fragment on this page | op1-30 juni 2020 |
| pagina | the page or view that is displayed, or the media Id on an episode/fragment page | VPWON_1256937 |
| platform | site for website, app for iOS/Android, tvapp for SmartTVs | site |
| programma | the name of the program/series if relevant, else null | op1 |
| merkType | generally inferred, but set to portal on iOS | portal |
| noboEventType | the event type for the NOBO panel, unavailable to MIT, index, article or home | index |
| noboMediaType | the content type for the NOBO panel, unavailable to MIT, general, videostream, or similar | general |
In addition, user information can be provided, the exact method differs per codebase. This information is only send to MIT.
| Field | Description | Example |
|---|---|---|
| party id | the device/cookie identifier, should generally be handled by the NPO Tag SDK itself | 0:k9jqzrvu:BoWFHEsV9~OYIwr8vGfERU1U1LQoKty9 |
| profile id | the active profile of the user or null if no profile is active | 9c8102b7-a470-4abc-93ce-7eab091218e5 |
| subscription | What type of profile is active, anonymous for non-logged in, free or premium otherwise | premium |
Note: Although the user context is generally supplied to the trackers via the context, mutations (login/logout/profile-switch) should use platform-specific methods (e.g. NPO.setUser(), NPO.clearUser() on web).
When content is being consumed inside a player, these events can also be tracked by the Topspin tracker. In general this means the player behaviour is tracked. This is done through several distinct events which will be described briefly below. When a player is loaded and properly instantiated with the Topspin tracker we’d expect events to come in in a certain order. Let’s follow that order in the description. For every instantiation of a player, a unique playerId will be triggered in order to unambiguously identify events coming from a specific player. The MID that is actually being played needs to be passed to the Topspin tracker as well.
Note: Additional information for these events is drawn from the context provided in the labels.
| Stream event Type | Description |
|---|---|
| streamLoad | The stream recorder will register a streamLoad when a player is loaded. |
| streamAdStart | When ads are being played prior to the actual requested stream, a streamAdStart event is triggered. No information on what advertisement is registered, only the fact that an ad is being played. |
| streamAdComplete | A streamAdComplete is triggered when an advertisement is completed. |
| streamStart | A streamStart is triggered when the actual requested stream (MID) starts playing. |
| streamWaypoint | With continuous playing of a stream, a waypoint is triggered for every 30 seconds of playtime. |
| streamComplete | A streamComplete is triggered when the stream is completed. |
| streamSeek | A user can also decide to skip part of the stream. The Topspin tracker will register a streamSeek event that needs to register from where in the stream the user starts seeking and where it ends. |
| streamPause | A streamPause is triggered when the stream is paused. |
| streamResume | A streamResume is triggered when the stream is resumed after the stream was paused. |
| streamFullscreen | When the user decides to access the player in fullscreen mode a streamFullscreen event is triggered. |
| streamWindowed | When the user leaves fullscreen mode a streamWindowed event is triggered. |
Stream measurements should be used any time a user is shown a stream (e.g. starting with streamLoad)
Recommendation are any content items that are displayed to the user. For these items, such as the streams shown in a ribbon on the homepage, as part of the search results or on episode pages, we measure two things:
note: Additional contextual information is drawn from the context provided in the labels.
We measure offers & choices to assess the effictiveness of our content offers. This is how we calculate click-through rates, decide which algorithms work best and what lanes need editorial attention.
There three types of recommendations, based on what source they have:
| Type | Source | Description |
|---|---|---|
| algorithm | recommendation algorithm | recommendations that are user (profileId) or media item (mid) specific. These recommendations are offered by our personal API endpoint (see the documentation). |
| search | Search Algorithm | users can use search functionality to navigate the platform. Depending on the search implementation, content will be offered based on the query the user executes. (see the search documentation) |
| editorial | Curation Team | recommendations on the homepage, collection pages etcetera are often created manually by the curation team. They have editorial control over the platform. To allow them to prioritize and assess the quality of these offers, they are measured seperately. |
An offer should be send when an individual item is displayed to the user (e.g. not when an item needs to be scrolled to), choices should be send every time an offer is clicked
Key values for offers/choices are:
| Key | Description | Example |
|---|---|---|
| type | search, algorithm or editorial | in some SDKs this is manually specified, in others choosing the recommender object to generate offers implicitly sets this |
| panel | The context in which a set of offers is shown | the display page (home, series, collection or live), type (regular or 5grid) and position, e.g. home.spotlight or home.regular.0 for search: auto-suggest-base(quick search), search-franchise-base(‘programmas’ section of search result page), search-episode-base (the afleveringen section of the search result page) |
| source | content-context in which the offer is placed | the media ID of the stream in the player where related video offers are shown, such as POW_03870345 |
| recommender | the provider of the offer | the lane name or recommendation algorithm that determined what to offer, such as vooruitkijken or ps-lightfm-collab-v1-pv-simple-0.1 |
| destination | the MID to which the offer leads | example: POW_04697955 |
| position | Within this lane/offer set, what position does this particular offer have | 0 (index starts at 0) |
| total | how many offers are present in this lane/offer-set | 4 |
Outside of clicks on our recommendations, NPO is interested in the use of buttons across the website. These events generally carry information such as the context (nivea1…3), the type (action, navigation or exit) and the name of the thing clicked on, as specified in the tagplan. Depending on the platform, a method supports these calls. The levels (niveau1…3 fields) are generally drawn from the context provided in the labels.
| Field | Description | Example |
|---|---|---|
| niveau1 | top level position in platform, most often the page / view type | aflevering |
| niveau2 | second level position, such as a lane name or the specifc show | op1 |
| niveau3 | most specific indicator, if necessary | seizoen |
| click | the description of the click | <name of the season> |
| clicktype | navigation, action or exit (leaving app/site) | action |