Closed defagos closed 11 months ago
Android: Seek while playing -> play -> seek -> play Seek while pause -> pause -> seek -> pause
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:
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.Other feedbacks from BUs have been provided in an internal document.
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.
Here are the answers to our questions, consolidated from discussions and documents listed above.
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).
Are
user_is_logged
anduser_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.
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.
Is
navigation_app_site_name
(site, whatever this means) still useful nowadays? If yes, which common name could we use fornavigation_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).
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.
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.
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.
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.
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.
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.
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.
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.
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 https://github.com/SRGSSR/pillarbox-apple/issues/444.
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 https://github.com/SRGSSR/pillarbox-apple/issues/445.
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.
When seeking with a playing player we send a
seek
followed by aplay
when resuming. What is the situation if the player was paused before theseek
? Should we send aseek
followed by apause
? 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.
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.
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.
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.
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.
Are both subtitle-related fields mandatory or could
media_subtitle_selection
possibly be enough?
Yes, both mandatory.
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.
Given the answer we got from ADI:
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
.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).
As a Pillarbox developer I need to have some Commanders Act-related questions answered so that I can provide a compliant implementation.
Acceptance criteria
Tasks
General questions
user_is_logged
anduser_id
still useful?source_id
still useful?Page view questions
navigation_app_site_name
(site, whatever this means) still useful nowadays? If yes, which common name could we use fornavigation_app_site_name
so that communication with our users is easy? (we can then use this name in our analytics configuration API).Streaming questions
media_segment
event still relevant?media_volume
still useful?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_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.seek
followed by aplay
when resuming. What is the situation if the player was paused before theseek
? Should we send aseek
followed by apause
? If yes is there any reason to do it if what matters is how long a content was played?media_position
is the same for livestreams, no matter which playback speed is applied?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?media_subtitle_selection
possibly be enough?