...
Content and Advertising
How do I manage pre- and mid-rolls?
In most cases, it is enough to connect the Kantar library to only the content object in your player, and not connect it to advertisement objects. The library will automatically keep track of the content when it is being paused for mid-rolls. You should not try to micro-manage what the library is doing. The play head position reported via the main content won't change whilst commercials are playing (it's paused during this time).
What is the lifecycle of a Stream object returned in the Stream *stream = [spring track:adapter atts:atts] call? Should we retain it or is a weak pointer enough? If we retain, when should we release? After [stream stop]?
The object itself should be retained and only released after the stream stop. It can be changed mid-stream if the content itself has changed. For example where mid-roll commercials are served you will need to pause the program content stream and retain that variable in order to return to it after the commercials have been delivered and the same program stream recommences, e.g. player reports to the sensor.
Our media player uses a different net stream for every piece of content. For example, a typical playlist could include:
Sting -> Sting → Pre-roll adverts (2/3 adverts) -> → Content part 1 / program -> program → Mid roll adverts (2/3 adverts) -> → Content part 2/ program -> program →
Post-roll adverts (2/3 adverts)
In total we could potentially have up to 11 net streams created in one session. If we were to start measuring from the first advert, the net stream created and passed to SpringStream would not be the same net stream that would be used for the actual content. We can call "stream.stop()" and then call "track()" again with new meta data and net stream, but would this be classed as the same user session? Using the above example we would be calling the "stop()" "track()" combination quite a few times. Is this correct?
Unless commercials are being specifically tracked, you’ll need to pause the polling to our systems when there is an ad running, and this is done by triggering the stop() and start() functions as you see in the doc. This will all be the same user session. Importantly you will need to be careful not to use the unload() function, because then you will lose the UID, and the same stream will in fact become another view.
...
Mobile App Streaming
What happens if my app is sent to the background by the user?
A Stop event is called when the app goes to background causing a new measurement session to start when user returns and resumes.
Device type information is not visible to our player – we don't drill down to device versions. Instead we can report the device string constant exposed by Apple's APIs, which could then be converted to a 'human' string outside of the player environment.
Is this suitable?
In this case the device string should be reported. This approach means if new devices are released, or Apple were to change the device strings, there is no need to update the App as the logic resides externally.
It is mentioned that the 'unload' call in SpringStreams is executed when the App is backgrounded. We currently close our player down on a background event. Is there any implication to be aware of if we need to release Stream instances?
When the player is sent to the background it closes down and any stream is canceled. When the user restarts the app and it is brought to the foreground, the previously viewed content will not resume and must be selected once again, either by standard scroll or by browsing the “Last Watched” items. In any case a brand new stream is started with a new session ID. This should present no issues for the measurement.
...