What does the NPO tag measure?

Broadly speaking, the NPO Tag measures the supply (content/pages/views) and demand (visits/streams/clicks) in the NPO Start/Plus environment. This encompases:

  1. Pages (web) / ContentViews (App) : how many users see a specific page / screen?
  2. Streams : how many users watch which videos for how long?
  3. Recommendations : what pieces of content we show on a page, at the end of a video or as a search result, do people click on?
  4. Clicks : which buttons draw people to a page, view or other piece of functionality

and uses three types of information to contextualize these events:

  1. Context information (NPOLabels)
  2. user-information
  3. Event-level information

The first two pieces of information are set globally, whereas the third is set for specific events, such as offers, choices or clicks.

Contex & user information

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

Page / content View

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

merkwhether this is an NPO or standalone contextnpoportal
merkIdinteger associated with the brand, 4 for NPO4
niveau1the top-level context, null for the home pageprogrammas
niveau2a narrower context, such as profile for profile related pages, the program-name for a program-related pageop1
niveau3most specific context, often null, but sometime the name of the particular episode or fragment on this pageop1-30 juni 2020
paginathe page or view that is displayed, or the media Id on an episode/fragment pageVPWON_1256937
platformsite for website, app for iOS/Android, tvapp for SmartTVssite
programmathe name of the program/series if relevant, else nullop1
merkTypegenerally inferred, but set to portal on iOSportal
noboEventTypethe event type for the NOBO panel, unavailable to MIT, index, article or homeindex
noboMediaTypethe content type for the NOBO panel, unavailable to MIT, general, videostream, or similargeneral

In addition, user information can be provided, the exact method differs per codebase. This information is only send to MIT.

party idthe device/cookie identifier, should generally be handled by the NPO Tag SDK itself0:k9jqzrvu:BoWFHEsV9~OYIwr8vGfERU1U1LQoKty9
profile idthe active profile of the user or null if no profile is active9c8102b7-a470-4abc-93ce-7eab091218e5
subscriptionWhat type of profile is active, anonymous for non-logged in, free or premium otherwisepremium

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

Stream (player) measurements

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 TypeDescription
streamLoadThe stream recorder will register a streamLoad when a player is loaded.
streamAdStartWhen 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.
streamAdCompleteA streamAdComplete is triggered when an advertisement is completed.
streamStartA streamStart is triggered when the actual requested stream (MID) starts playing.
streamWaypointWith continuous playing of a stream, a waypoint is triggered for every 30 seconds of playtime.
streamCompleteA streamComplete is triggered when the stream is completed.
streamSeekA 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.
streamPauseA streamPause is triggered when the stream is paused.
streamResumeA streamResume is triggered when the stream is resumed after the stream was paused.
streamFullscreenWhen the user decides to access the player in fullscreen mode a streamFullscreen event is triggered.
streamWindowedWhen 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:

  1. When this item is displayed, the offer event
  2. When this item is clicked, the choice event

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:

algorithmrecommendation algorithmrecommendations that are user (profileId) or media item (mid) specific. These recommendations are offered by our personal API endpoint (see the documentation).
searchSearch Algorithmusers 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)
editorialCuration Teamrecommendations 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:

typesearch, algorithm or editorialin some SDKs this is manually specified, in others choosing the recommender object to generate offers implicitly sets this
panelThe context in which a set of offers is shownthe 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)
sourcecontent-context in which the offer is placedthe media ID of the stream in the player where related video offers are shown, such as POW_03870345
recommenderthe provider of the offerthe lane name or recommendation algorithm that determined what to offer, such as vooruitkijken or ps-lightfm-collab-v1-pv-simple-0.1
destinationthe MID to which the offer leadsexample: POW_04697955
positionWithin this lane/offer set, what position does this particular offer have0 (index starts at 0)
totalhow many offers are present in this lane/offer-set4


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.

niveau1top level position in platform, most often the page / view typeaflevering
niveau2second level position, such as a lane name or the specifc showop1
niveau3most specific indicator, if necessaryseizoen
clickthe description of the click<name of the season>
clicktypenavigation, action or exit (leaving app/site)action