Commanders Act analytics open questions

[defagos]

As a Pillarbox developer I need to have some Commanders Act-related questions answered so that I can provide a compliant implementation.

Acceptance criteria

• The questions listed below have been answered.
• Corresponding issues have been created for any necessary implementation work.
• Obsolete Confluence documentation has been reported.

Tasks

• Get an answer for the questions below.
• Create issues if needed on relevant Pillarbox repositories.
• Browse through Confluence documentation and report outdated pages to ADI.

General questions

1. ✅ The distinction between phones and tablets does not really make sense anymore on Android. Should we change the device list to reduce it? What about iOS devices?
2. ✅ Are user_is_logged and user_id still useful?
3. ✅ Is source_id still useful?

Page view questions

1. ✅ Is navigation_app_site_name (site, whatever this means) still useful nowadays? If yes, which common name could we use for navigation_app_site_name so that communication with our users is easy? (we can then use this name in our analytics configuration API).
2. ✅ Can / should we count again a view when it is again revealed by returning from a view pushed after it?
3. ✅ Shouldn't we send data with proper types (int, float, string) instead of wrapping everything into strings as we do today? (we should check with @pyby as well)
4. ✅ How should screens arranged in a split view be measured? Are two page views acceptable or should we ensure only the parent screen is measured?
5. ✅ Is the push notification flag for page views still useful?
6. ✅ Are we interested in measuring CarPlay navigation? (Mediapulse isn't)
7. ℹ️ Screen rotation or configuration changes on Android would send additional page views. Is this an issue?

Streaming questions

1. ✅ Is the media_segment event still relevant?
2. ✅ Is media_volume still useful?
3. ✅ Is media_bandwidth still useful? If yes, is it the actual device observed bandwidth or the advertised bandwidth for the currently played stream (or the selected variant thereof)?
4. ✅ Is media_playback_rate still useful? 🍎 remark: With our Commanders Act stream tracking implementation we still need an API to notify about rate changes. The desired nominal rate can then be used to extrapolate the position / playback duration when the last known state is playing.
5. ✅ Do we have to update labels with metadata updates, e.g. to account for current program changes on livestreams? Is it really meaningful for measurements, as the metadata contains data for the program currently on air, even if playing a DVR stream in the past?
6. ✅ When seeking with a playing player we send a seek followed by a play when resuming. What is the situation if the player was paused before the seek? Should we send a seek followed by a pause? If yes is there any reason to do it if what matters is how long a content was played?
7. ✅ Should we still use a threshold for the DVR timeshift value we send, below which the value is rounded to 0? If yes to what purpose?
8. ✅ Can you confirm that media_position is the same for livestreams, no matter which playback speed is applied?
9. ✅ For Commanders Act livestream analytics could we send the first uptime after 60 seconds, not after 30 seconds? The specifications require it but Letterbox Apple does not implement it, while Android Letterbox does. Is this really necessary and, if yes, why?
10. ✅ Are we interested in measuring video streaming consumption in background?
11. ✅ Are both subtitle-related fields mandatory or could media_subtitle_selection possibly be enough?
12. ✅ Play Suisse is displaying forced subtitles, i.e. subtitles which are not meant to be selected by the user but are present as a way to transcribe dialogs in a foreign language (e.g. if you watch a movie with German audio and the characters are in a US town, dialogs heard in English will be translated in German as forced subtitles, but standard German dialogue won’t). Forced subtitles should be considered as being part of the video directly, though they aren’t to spare encoding / storage costs. They are therefore never meant to be selected manually and must rather be enabled automatically depending on the current audio track. Thus our question: Should we treat forced subtitles like any other subtitles or should we ignore them entirely in streaming analytics?

[StaehliJ]

Android:
Seek while playing -> play -> seek -> play
Seek while pause -> pause -> seek -> pause

[defagos]

Mediapulse is not interested in measuring CarPlay user experiences (see #25). For the moment the Apple implementation does not check about app state anymore so background page views are again possible.

Two possible outcomes:

• This situation is fine and we document that CarPlay interface controllers should not be tracked by apps.
• The SRG wants to track such experiences, in which case we again need to restore app state tests when using the Analytics public API. We still need to have an internal mode as before to allow background page views to be emitted by automatic page view measurements, as viewDidAppear(animated:) is called in background when returning from background. We should also update our documentation accordingly. This mode should only be applied for comScore measurements then, not for Commanders Act, so that we still obtain the behavior Mediapulse desires.

[GoetzMar]

General questions

1. Distinction between phones and tablets is needed by RTS. Can we provide it through another way?
2. Were used for logged in users. Is this replaced by user_sub and user_profile id? If not, RTS wants to keep it.
3. Not used by the BUs. Is it linked with the origin of the visits? If yes, RTS wants to keep it.

Page view questions

4. Two page requests are ok. Can it happen that media tracking happens at the same time? This would cause troubles for calculation KPIs.
5. What is it exactly?

[defagos]

Answers from our analytics teams

• Bandwidth: Not used, dropped.
• Playback speed: SRF interested for feature usage but recommendation is to use events for that purpose. Sending in streaming events is more useful if consumption durations are affected and this is currently not used for this purpose.
• Current program: SRF interested but likely not the way to obtain this information (as we support DVR). Probably not useful for Pillarbox, not the way to know what is currently being played. We could discuss with SRF what they want and if we can help.
• Seek / pause events: We can avoid inhibiting some transitions to make our code simpler, will not affect results.
• No threshold needed for timeshift, round to the nearest value only.
• Media position for livestreams not affected by playback speed.
• Time of the first heartbeat: There is maybe Mapp documentation which could help. If we don't find anything we can keep things simpler in Pillarbox.
• Background video playback consumption: Probably needs to be sorted out. Are people not interested but not bothered by events sent in this case or do we have to remove them because they don't want them? Can we then have the same logic than comScore?

Other feedbacks from BUs have been provided in an internal document.

Additional question for SWI (David)

Can it happen that media tracking happens at the same time? This would cause troubles for calculation KPIs.

The Pillarbox team will contact David directly to understand this potential issue better.

[defagos]

Here are the answers to our questions, consolidated from discussions and documents listed above.

General questions

Question 1

The distinction between phones and tablets does not really make sense anymore on Android. Should we change the device list to reduce it? What about iOS devices?

Context: Android uses screen size to determine the device type, which is not reliable anymore (split screen, foldable devices, etc.), except for TV apps. We can keep the current Letterbox, though, as this is not a problem (we had to discuss the matter a bit further with RTS but there is no problem with the current Letterbox approach, see #33).

Question 2

Are user_is_logged and user_id still useful?

The user_is_logged and user_id fields are specific to maRTS and not used by other BUs, they should therefore not be official Pillarbox fields (we could provide a way to send custom labels, see #31). Play Suisse, though, uses the official SRG SSR login and sends user_sub (name in Mapp: URM - Custom Visitor Id) and user_profile_id (profile associated with an account, currently not used). Since the SRG SSR login might be extended to all SRG SSR apps (e.g. Tippspiel, Zerovero, Play will likely implement it) Pillarbox should likely provide official support for these fields, see #32.

Question 3

Is source_id still useful?

Specific to RTS recommendation engine only, which is a legacy product. Not used by RTS analytics team either, see #33. So no need for an official field in Pillarbox and, if the need arises when some RTS product implements Pillarbox, we will find another way.

Page view questions

Question 1

Is navigation_app_site_name (site, whatever this means) still useful nowadays? If yes, which common name could we use for navigation_app_site_name so that communication with our users is easy? (we can then use this name in our analytics configuration API).

This parameter is still widely used, we keep it. We can figure out a friendly name later (one proposal was e.g. product).

Question 2

Can / should we count again a view when it is again revealed by returning from a view pushed after it?

We agree we can measure back navigation.

Question 3

Shouldn't we send data with proper types (int, float, string) instead of wrapping everything into strings as we do today? (we should check with @pyby as well)

Not discussed together but likely not needed at the moment. Let us see if the need arises in the future, for the moment we won't do anything.

Question 4

How should screens arranged in a split view be measured? Are two page views acceptable or should we ensure only the parent screen is measured?

The GD would not go into this kind of detail but asked BUs to know what they do. Two page views are fine but we still need to figure out whether SWI KPIs are not affected negatively, see #34.

Question 5

Is the push notification flag for page views still useful?

People weren't aware of what this flag or do not use it so we can drop it.

Question 6

Are we interested in measuring CarPlay navigation? (Mediapulse isn't)

No answer provided yet, let us wait until there is an identified need. For the moment no task created.

Question 7

Screen rotation or configuration changes on Android would send additional page views. Is this an issue?

Discussed within the team: Best handled by the application itself if really a problem. Let us wait for the validation phase to see if this is actually reported as an issue.

Streaming questions

Question 1

Is the media_segment event still relevant?

For the moment Pillarbox does not implement segments anymore. In case this event were still needed (which requires further investigation) we could provide an official event in the Pillarbox SDK, see #35.

Question 2

Is media_volume still useful?

In Commanders Act a media_muted is generated from this value. Not used at the GD but need to ask the BUs. @amtins thinks that this is a standard field we should not remove, though.

Question 3

Is media_bandwidth still useful? If yes, is it the actual device observed bandwidth or the advertised bandwidth for the currently played stream (or the selected variant thereof)?

media_bandwidth is not used. We can drop it, see SRGSSR/pillarbox-apple#444.

Question 4

Is media_playback_rate still useful? 🍎 remark: With our Commanders Act stream tracking implementation we still need an API to notify about rate changes. The desired nominal rate can then be used to extrapolate the position / playback duration when the last known state is playing.

SRF could be interested in tracking playback speed as a feature. This is not the purpose of media_playback_rate, though, as feature-tracking is better achieved with a dedicated button for apps interested in it. So in the end not used yet and can be dropped, see SRGSSR/pillarbox-apple#445.

Question 5

Do we have to update labels with metadata updates, e.g. to account for current program changes on livestreams? Is it really meaningful for measurements, as the metadata contains data for the program currently on air, even if playing a DVR stream in the past?

SRF could be interested in having program metadata when playing livestreams but at the moment we are sending live metadata only, even if we are playing something in the past with DVR support. So this is likely not possible at the moment with the metadata we have. We should therefore wait until there is really an identified need we can better understand before we implement anything.

Question 6

When seeking with a playing player we send a seek followed by a play when resuming. What is the situation if the player was paused before the seek? Should we send a seek followed by a pause? If yes is there any reason to do it if what matters is how long a content was played?

These transitions do not affect measurements, we can therefore apply the approach that leads to less code being written if it makes sense.

Question 7

Should we still use a threshold for the DVR timeshift value we send, below which the value is rounded to 0? If yes to what purpose?

No threshold needed for timeshift, round to the nearest value only.

Question 8

Can you confirm that media_position is the same for livestreams, no matter which playback speed is applied?

media_position is not affected by playback speed for livestreams.

Question 9

For Commanders Act livestream analytics could we send the first uptime after 60 seconds, not after 30 seconds? The specifications require it but Letterbox Apple does not implement it, while Android Letterbox does. Is this really necessary and, if yes, why?

More investigation work was done, see #39. Specifications are clear.

Question 10

Are we interested in measuring video streaming consumption in background?

Streaming in background is relevant according to the feedback we got but this would likely require new API capabilities, see #38.

Question 11

Are both subtitle-related fields mandatory or could media_subtitle_selection possibly be enough?

Yes, both mandatory.

Question 12

Play Suisse is displaying forced subtitles, i.e. subtitles which are not meant to be selected by the user but are present as a way to transcribe dialogs in a foreign language (e.g. if you watch a movie with German audio and the characters are in a US town, dialogs heard in English will be translated in German as forced subtitles, but standard German dialogue won’t). Forced subtitles should be considered as being part of the video directly, though they aren’t to spare encoding / storage costs. They are therefore never meant to be selected manually and must rather be enabled automatically depending on the current audio track. Thus our question: Should we treat forced subtitles like any other subtitles or should we ignore them entirely in streaming analytics?

They should be ignored since they are not the usual type of subtitles a user switches on. If this is tracked it would compromise the data of the real subtitles. This is to be done as long as it does not mess up the rest of the media_subtitle_selection of normal Play Suisse subtitles.

[defagos]

Given the answer we got from ADI:

• Since media_subtitles_on is mandatory and not derived from media_subtitle_selection, it is very likely that media_subtitle_selection must be omitted when media_subtitles_on is false, as implemented nowadays in Letterbox players. It would namely not make any sense to send that subtitles are off with language set as UND.
• By extension, since media_audio_track has no media_audio_track_on counterpart, we can assume that the absence of media_audio_track_on means that audio is always expected to be on. We thus can safely assume we must always send a value for media_audio_track, with UND if none (which should never occur for SRG SSR content).