Provide support for Sticky ad units in AMP #2472

Closed
kashyapnitin opened this Issue Mar 7, 2016 · 13 comments
@kashyapnitin
Collaborator

Have support for ad units that always take a fixed place in the viewport.
See IAB mobile rising star - Adhesion for example: http://www.iab.com/guidelines/mobile-rising-stars-ad-units/
or
https://support.google.com/adxseller/answer/6068103?hl=en

The rational for doing these would be that when done properly (& with appropriate checks & choices) they have higher viewability while being minimally disruptive for user experience

Issues to discuss and agree would involve things like (not exhaustive)

  • What should be the allowed size? What should be the behaviour on orientation changes?
  • What should be the impact on click / tap?
  • When should the ad show into view & how should it be closed / dismissed?
  • Should these ad units only be allowed when other in-line ad units are not present on the page?
  • Should it be allowed to refresh these ad units? If so how many times, how often?
    etc.
@dvoytenko dvoytenko assigned cramforce and unassigned dvoytenko Mar 9, 2016
@dvoytenko
Collaborator

I think most of these questions should be first reconciled with @cramforce , especially w.r.t. constraints. I can then advise on the best way to proceed with implementation since stickiness is always a sticky issue across platforms.

@Wes-Kargo

Hi @kashyapnitin and @cramforce

I'm so glad to hear you are exploring this new ad feature. Nearly all of our publisher clients have asked about this and are eager to expand on the advertising options allowed in AMP’s current iteration. I completely agree with Nitin, that adhesive ad units, with the proper limitations in place, can provide a non-intrusive, high-engagement alternative to in-stream banners that will immediately boost publisher’s revenue-per-page ceiling.

I've provided Kargo's POV on the issues you brought up. Happy to continue this conversation via email, you can reach me at wes@kargo.com

  1. We've tested all of our adhesion units across multiple device (iOS and Android... iPhone 5 being the smallest) and found that our least intrusive units ie. those that don't expand or take over the page generally stay under 10% of the device viewport area. We recommend adhesion units be full-width responsive, so they adapt to different screen sizes. When orientation is changed, these units (if width responsive) switch to a fixed size in the landscape orientation (ie 320x50) but centered in the viewport.
  2. When clicked, we recommend opening in a new browser window.
  3. When the page is loaded, you could have the ad show up based on a number of events. We've found ads that load based on user's "first page scroll" have performed the best but you could also have it show immediately upon page load, have a timer and load after X seconds, or load when the user gets a certain pixel distance down the page. An X button on the top corner of the ad unit is the most intuitive way to convey to the user they can dismiss an ad. It's generally good UX practice to make the hotspot for the button larger than the icon, we use 24x24.
  4. This is a great point, we don't allow multiple units in view at a time, and believe it greatly contributes to a positive UX. We will generally have an adhesion unit look out for in-stream units and hide itself when the in-stream ad enters the viewport. This would, however, require the ad slots on the page to be aware of each other.
  5. When you say refresh, do you mean load up an entirely different ad/creative without a user initiated refresh/navigation? If so, then we recommend this not happen if a user has dismissed an ad - if a user dismisses an ad, they should not see another one for the remainder of their session until they refresh. If units load without a user-initiated refresh, we would also recommend a countdown timer of some kind to signify to users the time elapsed, and also would want to test the correlation between time on the page and brand recall/ favorability. Our clients (both pubs and advertisers) are happy with a single ad per page load.
@rudygalfi rudygalfi added this to the Pending Sprint Slotting milestone Mar 24, 2016
@jasti
Collaborator
jasti commented May 2, 2016

Hey @Wes-Kargo we are getting close on this.
One question, do you see demand other than 320x50's flowing to this slot. My guess is a lot of advertisers want to advertise in 320x50s on mWeb and this would translate well?

@cramforce cramforce assigned zhouyx and unassigned cramforce May 3, 2016
@kashyapnitin
Collaborator

Thanks for the inputs tea Kargo... for a V1 we are going ahead with the following implementation.

Allow for a way to specify only for amp-ad elements (not other amp-elements) to be shown in a sticky position at the bottom of an amp page such that

  1. The width is always the viewport
  2. The height can be specified as long as it is less than 1/6th of the viewport (in portrait mode) or 100 pixels (whichever is smaller)
  3. On orientation changes the creative doesn't stretch (but can resize itself if it is smart and can handle changes in slot size), though the slot can expand to take the new width while retaining the original height.
  4. The ad shows up only when the user has scrolled through at least 1 viewport and there is at-least one more viewport of content still available (so minimum 2 viewport restriction)
  5. The ad can be dismissed using a swipe gesture on a specific "Swipe to dismiss" UI element overlaid on the ad, or shown in the border for the ad - exact decision TBD. (UX input needed here)
  6. There is no swipe to expand feature for this format (because I believe users can achieve exactly the same once AMP enables AMP landing pages for Ads)
  7. Showing up of the sticky ad is not related to any other ads on the page (so there can be more regular inline ads if the publisher so decided) - Weather this unit should be hidden when an inline unit shows up is TBD - depending on its effect on jank and UX impact of dynamic content overlay and hiding.
  8. For the V1 we will not allow these to be refreshed nut in V2 users could be allowed to refresh the ad in the sticky slot once every TBD (5, 10, 30) seconds (as long as the ad has not been dismissed by the user)

Moving to an intent to Implement.

@Wes-Kargo
Wes-Kargo commented May 5, 2016 edited

Hey @jasti Yes that size is most popular throughout the industry, though we do other sticky sizes such as 280x280 that runs out of the corner of the page.

@kashyapnitin Thanks for vetting this and sharing the intended behaviors. I have a few questions:

Re. 4 - do you expect the ad call to be made upon page load, or could we have a way to only make the request once the user hits the scroll threshold (or is approaching it)?
Re. 5 - would this swipe gesture cause the user to accidentally navigate away from the article? Will we still be able to include an "X" button to dismiss the ad?

Unrelated to these points, but will the sticky unit area be transparent behind/around the ad, or are you planning on attaching a 100 pixel iframe to the bottom of the viewport. If it will be an iframe, would we be able to make the background transparent?

Appreciate any info you can provide, thanks again.

@erwinmombay
Member

@zhouyx please link to this in the spec section

@erwinmombay erwinmombay added a commit that referenced this issue May 9, 2016
@zhouyx @erwinmombay zhouyx + erwinmombay Provide support for Sticky ad units in AMP #2472 (#3119)
* Provide support for sticky ad units, initial implementation

* delete EXPERIMENT tag

* change layout type to NODISPLAY

* add .md file
98129cf
@zhouyx
Collaborator
zhouyx commented May 17, 2016 edited

@kashyapnitin
Do we have to recompute a maximum height every time on orientation change? 1/6vh will be smaller than 100px in landscape mode (for cellphones).

The height can be specified as long as it is less than 1/6th of the viewport (in portrait mode) or 100 pixels (whichever is smaller).

@jasti
Collaborator
jasti commented May 17, 2016

@zhouyx If performance is not a problem, we should initiate a fresh amp-ad request when user switches orientation and adhere to these calcs but restrict the width to max 320 px (this is the most common sticky size). Does that make sense?
QQ: What will happen if the returned ad is greater than 1/6th of the vh?

@zhouyx zhouyx added a commit that referenced this issue May 17, 2016
@zhouyx zhouyx Add support for Sticky ad units in AMP #2472 (#3167)
* Add feature display after scrolling
d90cfc8
@kul3r4 kul3r4 referenced this issue in ampproject/amp-by-example May 17, 2016
Merged

Added sticky ad to amp-ad example #165

@cramforce
Member

This is fine for orientationchange, but is a reload also OK for resize
events (rare on mobile, but happens on desktop)? Might need to be heavily
throttled then.

On Tue, May 17, 2016 at 2:46 PM, Vamsee Jasti notifications@github.com
wrote:

@zhouyx https://github.com/zhouyx If performance is not a problem, we
should initiate a fresh amp-ad request when user switches orientation and
adhere to these calcs but restrict the width to max 320 px (this is the
most common sticky size). Does that make sense?
QQ: What will happen if the returned ad is greater than 1/6th of the vh?


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#2472 (comment)

@jasti
Collaborator
jasti commented May 18, 2016 edited

yup, this can get out of control if we allow reload on resize. We should restrict to reload only on orientation change. There are AdX (and other ad server) policies which don't allow triggering an ad refresh without user action. (People could take advantage of constantly resizing a number of times BTF which trigger fake impressions in the ad server).

@jasti
Collaborator
jasti commented Jun 7, 2016 edited

A few outstanding items:

  1. Read me needs updating for all the supported parameters for background colors
  2. Swipe to dismiss
  3. Edge case testing
    a. What happens when more than a single element is wrapped inside of the amp-sticky element
    b. What happens when more than a single amp-sticky element is on the page
  4. #3473 . @jridgewell's thoughts needed for a workaround.
@jasti
Collaborator
jasti commented Jun 14, 2016

For those interested in an early look at sticky ads in AMP, please see : https://ampbyexample.com/components/amp-sticky-ad/
Suggestions and feedback welcome while we finish up some more essential enhancements like 'swipe to dismiss' and #3473

@jasti
Collaborator
jasti commented Sep 3, 2016

amp-sticky-ad live and in production. Please open a new issue for enhancements.

@jasti jasti closed this Sep 3, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment