Andrei: Clarification of player behavior for clickthru (pause or not pause)

[mtumi]

Should players pause video in response to Clickthrough?

If player do not pause video on CT, should players describe this limitation to the ad at handshake (initAd)?

[pietermees]

Are there cases where the video can not be paused but you can open a clickthrough? On Wed, Jun 20, 2018 at 5:22 PM mtumi notifications@github.com wrote:

Should players pause video in response to Clickthrough?

If player do not pause video on CT, should players describe this limitation to the ad at handshake (initAd)?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/InteractiveAdvertisingBureau/SIVIC/issues/78, or mute the thread https://github.com/notifications/unsubscribe-auth/AG3lJUrSEiiv3i6gP0wjzWAzc8NI3SXaks5t-misgaJpZM4UvfKp .

[ftslo]

re: Are there cases where the video can not be paused but you can open a clickthrough?

Would an ad served with a live stream fall into this category?

I was also wondering if SSAI content would be unable to be paused on click thru, but I suppose the the entire video stream (content video plus ad video) are still able to be paused by the video player if the user clicks.

[pietermees]

Yeah, good point, I guess there are live streams that would fall into this ad category. I think that might still be solvable by treating it as a skip though? On Thu, Jun 21, 2018 at 6:54 PM ftslo notifications@github.com wrote:

re: Are there cases where the video can not be paused but you can open a clickthrough?

Would an ad served with a live stream fall into this category?

I was also wondering if SSAI content would be unable to be paused on click thru, but I suppose the the entire video stream (content video plus ad video) are still able to be paused by the video player if the user clicks.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/InteractiveAdvertisingBureau/SIVIC/issues/78#issuecomment-399172172, or mute the thread https://github.com/notifications/unsubscribe-auth/AG3lJRIgunXHjFi3fJhC8Z4bxvMfcN2wks5t-8_IgaJpZM4UvfKp .

[ryanthompson591]

We think the publisher should decide this and the spec should not tell the publisher how to manage this user experience.

[mtumi]

FYI - for SIVIC, I believe in most cases when there is a clickthru in the creative the video will already be paused, assuming SIVIC is not used to implement simple overlays. If that is true, this issue is moot.

[amitshetty]

Agreement - we should let the publisher handle this.

[mtumi]

andrei will add a clarifying sentence to the doc if needed

[andmig]

Re-reading this topic:

1. SSAI doesn't prevent player from pausing video per se in on-demand content servings. SSAI just means that there is no clear cut moment when ad video starts. Video stream remains continuous video stream no matter what - player is agnostic to the content. So, it is absolutely possible for client side to manipulate stream progress including pausing/resuming video.

IMPORTANT: we operate under this incorrect assumption when discussing other features - not CT related behavior only.

2. Neither there is an objective business restriction with SSAI approaches to allow user manage viewing experience at his/her leisure. Ad or no ad user is allowed to pause long content video in on-demand use cases. Ad presence doesn't negate this reality.

As a matter of fact, player refusal to pause on CT while it can makes user experience miserable. After all, user came to watch content. Panishing user for CT by risking user missing part of the content is unacceptable.

3. The only use case when player may not be able to pause the ad is live stream where allotted to ad time is strictly enforced. It doesn't matter whether SSAI is involved.

Hence, default behavior must be player pauses video when CT occurs. This must be default player behavior for both pure video ads and ads with interactive overlay.

Ideally player response to CT rules must be in best practices doc that governs video ad handling on a higher - independent of ad type - level.

From SIVIC perspective this means:

1. Creative notifies player of CT occurrence.
2. Player pauses video by default.
3. In cases player is no capable or not willing to pause the video - response to interactive should arrive with rejection. Player must state the reason for pause failure.

[andmig]

Also flagging it for VAST 4.2 group as a general issue.

[gasperk]

Just like in VAST, it's up to the player to either pause or not pause the main video on clickthrough, it's not in the scope of this spec. However, the creative may be playing some media on its own, and in order for it to be able to behave the same as the player (ie. pause or not pause), it needs to know what the player did.

I see two possibilities here:

• require an explicit response to "clickthru" message: player will/did or won't/didn't pause.
• rely on implicit "paused" message coming from the player. Downside is the pause may not be triggered by the clickthru.

Either way, I think it's worth putting something like this in the spec: If the creative is playing its own media, it's expected to behave the same way as the main media does. Therefore, it should pause (or not) depending on how the main player reacts on clickthru.

[ftslo]

@gasperk Would it make sense if the explicit response from the player include some of the player's video properties (or expected behavior), ie: muted / unmuted; playing / paused; fullscreen: true/false that the SIVIC creative is expected to apply to any in-creative media?

[gasperk]

@ftslo Yes, I think that's a good idea.

[gasperk]

See #102.

[andmig]

Before suggesting language for CT vs. pausing handling on player side - two things:

A. I am afraid we under impression that each time user is sent to landing page clickthrough occurs. This is absolutely not true.

There are at least two situations when user ending on other page doesn't constitute clickthrough:

1. User invokes clickthrough second (or Nth) time.
2. Ad has controls that send user to non-clickthrough pages. For instance, ad may have shopping link that is not recorded as a clickthrough.

From CT discussion in SIVIC context it means that clickthrough or not, once user is redirected - video pause is desirable. So, why load player with pausing on CT when CT is just a subset of user experiences that need video paused - not only when user find himself elsewhere on internet. Who but creative knows the best when to pause the video?

It feels like complete decoupling of CT and pause is the most elegant solution.

B. As a continuation of A. We should chew a bit on what happens in VPAID now under exactly the same circumstances.

In VPAID ads themselves pause video when CT occurs. In other words - it is not player's responsibility to bare CT related headaches.

We may want to consider bringing this paradigm into SIVIC. If we do, the following flow may be sufficient:

1. User invokes clickthrough.
2. Creative sends requestPause message - similar to ad hard pausing video in VPAID.
3. Player either responds with reject/resolve or creative would know that video is paused based on pause media event. This has no relation to clickthrough per se.
4. Creative sends user to landing page.
5. Creative sends clickThru message to player.

NOTE: role of clickThru message shrinks down to mere information purpose - essentially for player internal reporting objectives.

Such approach dramatically simplifies clickthrough related messaging (no need for player to respond with pause, audio or screen mode state). Neither player must jump through the hoops of CT related logic as a. player is not the instigator of CT invocation to begin with (unlike with non-interactive ads); b. player doesn't know anything about either circumstances that led to pause request or what clickthough entails.

The remaining nut to crack is the concern about still audible video in the situations when player cannot pause the video. Actually it may be a non-issue. If user still hears sound coming from the player - it is a good thing as user will know when ad is finished and content resumed.

As for the devices that allow for only media in view to proceed - neither pausing nor audio present any caveats as video will be paused by device.

[gasperk]

@andmig

Posits:

1) Navigation can be initiated by: creative, player, or externally (pub site, app) 2) Every navigation, no matter who initiated it, might result in media state change (pause, mute). Therefore the player needs to know about it. 3) Not every navigation is a clickthru. Examples: About player, page navigation, notall links in creative are necessarily clickthroughs.

Questions:

1) is every navigation, initiated by the creative, a clickthru?

• No. The creative decides whether a particular navigation attempt is also a clickthru. If it is, it needs to let the browser know about it.

2) is player able to detect navigation without being explicitly told?

• yes: player detects navigation or focus changes by some external API (eg. Page Visibility API) and notifies creative of any media status changes via existing events (paused, ...). Creative has to apply the same to any in-creative media. We have to document this expectation and flow somewhere.
• no: creative has to tell the player navigation has occurred. We need a new navigate message that gets sent separately from clickthru whenever navigation was initiated by the creative.

[amitshetty]

@gasperk to follow up on this -> pull request on this.

[gasperk]

Tempted to say this is the final analysis:

1) pausing/muting on navigation: player might adjust media playback status on any navigation in the window, not just navigation from the creative. Because of this, player has to detect navigation in the environment, not be told about it via an explicit message from the creative.

2) tracking: player has to track when clickthru happens. It should not adjust media playback status upon receiving the clickthru message, see 1 above.

3) in-creative media would ideally behave the same as the main media (1 above) in case of navigation. We could put some mechanism for that in the spec: the player sends a message that contains desired player status upon navigation, and the creative has to apply that to in-creative media. But I suggest we simplify to just some language somewhere in the spec: if creative plays any media, it should pause it when navigation occurs. We can suggest Page Visibility API for that.

Changes proposed:

• we remove response for clickthru and state explicitly that it should only be used for tracking. The player should detect navigation in some other way if it wants to adjust media status (https://github.com/InteractiveAdvertisingBureau/SIVIC/pull/129)
• we address 3 above in Guidelines / Best Practices: "creative should pause any in-creative media upon navigation". Again we can suggest Page Visibility API.

[ryanthompson591]

We had a discussion about clickthru, the consensus was:

1. There does not need to be a recommendation in the spec for pausing/muting in response to clickthru.
2. Clickthru message should only specify that tracking should happen.

[gasperk]

129 merged