Amphtml: Change amp-sticky-ad trigger to end of first scroll.

[jpettitt]

Currently "the sticky ad will display after scroll one viewport height from top provided there is at least one more viewport of content available". We'd like to see that change to trigger at the end of the first scroll regardless of length and regardless of additional available content.

Reasoning: We've been running an a/b with a 320x50 top banner and a 320x50 amp-sticky. The top banner (ugly) is generating twice the revenue, mostly due to the sticky not being seen. We'd like to have the sticky appear earlier to try and bring revenue parity with removing top banner.

[zhouyx]

to @jasti

[jasti]

I'm supportive of the suggestion to start request after scroll ends. @zhouyx do you see any issues from a performance stand point?
Regarding article length - @jpettitt Do you have many articles shorter than 2 viewports? The reason we added the requirement is to avoid the high ad density for a relatively short article, assuming the article will most probably have a banner or two.

[jpettitt]

@jasti very few. That said as I read the current doc it's 2 view ports + and additional viewpoint of content. I think length limitation in general are problematic becasue you get situations where an iphone 4 turned landscape gets an ad and a 6+ in portrait doesn't. This is the same complaint I have about amp-iframe where it has an arbitrary limitation that is impossible to know at page design time. My take - if it's enough content to scroll then show the ad at the end of the first scroll.

[jasti]

That's fair. I think we should experiment unless @zhouyx has any performance concerns.
CC @lannka

[zhouyx]

Can't think of any performance issue. Yup we can experiment with this. May add an experiment tag for this? Or simply include the change and experiment in canary?

[jpettitt]

Canary works for me. The sooner we get this the better.

[zhouyx]

just checked our code. we only check if doc's height is greater than 2 viewport height, and if user is one viewport away from top. So the requesting feature is in from the beginning.

should update the doc to make it clearer.

[jpettitt]

So all that needs to change is trigger on the 1st scroll regardless of length?

[jasti]

Yup. Thanks @zhouyx. Let us know when this lands as an experiment.

[jasti]

Hey @zhouyx, checking in on the status for launching as an experiment.

[zhouyx]

Ah! Sorry this has been stalled so long. I just sent out a PR for this.

[zhouyx]

PR is merged.

[jasti]

@jpettitt Would you please test this in canary and let us know if you have any feedback? Thx.

[jpettitt]

I'm not seeing this change in dev-channel yet.

[jasti]

You will after this Thursday's release.

[jpettitt]

I'm not seeing this in the current dev channel version 1484265443309 - did it go out?

[jasti]

I don't see it. @aghassemi, do you know why this didn't go out with last week's cut?

[aghassemi]

The code is definitely in but I don't think #6907 is addressing the issue.
There is still the requirement that user needs to scroll equivalent of 1 viewport height before sticky ad shows up, that by itself enforces the fact that page needs to have 2 viewports (otherwise user can never scroll 1 viewport height) #6907 is removing the two viewpoint check, but in reality that has no effect for the reason above.

My test page: https://output.jsbin.com/muyivof works the same in prod and dev channel.

If we want sticky ad to always show up regardless of page height and still provide a good UX, maybe we can do user should scroll min(1 viewport, 50% of page height) as the restriction? @jasti @cramforce thoughts?

[aghassemi]

(To clarify we still want #6907, it handles the case where viewport size changes after load due to device rotation, etc.. but #6907 is not relaxing any requirements in regards to amp-sticky-ad requiring 2 viewports of content)

[jasti]

Thanks. I think doing user should scroll min(1 viewport) as the restriction might be good enough (which implies that there is at least 1 viewport). Any reason why you suggest 50% of page heigh min?

[aghassemi]

"user should scroll min 1 viewport" implies "that there is at least 2 viewports of content" which is the current behaviour. If there is only 1 viewport of content, user can not scroll at all (since all content fits the screen and there is no need for scrolling).

My suggestion relaxes this 2 viewport requirement a bit but not by much. Maybe a better approach is:

• If page <= 1vh (viewport height): no sticky ad, ever.
• if page >= 1vh but < 1.5vh: any scroll would bring up the sticky ad.
• if page >= 1.5vh but < 2vh: user needs to scroll 0.5vh to see the ad.
• if page > 2vh: user needs to scroll 1vh to see the ad. (current behaviour)

This would ensure sticky ad shows up in all cases except when user can not scroll at all (which is when height <= 1vh and in these cases we don't want to show sticky ad anyway since it implies showing the ad at load time without a user interaction).

[jpettitt]

Can we just make it "if the user scrolls any amount the sticky ad comes up"? I was in meeting last week where Google ad sales were heavily pushing the amp-sticky. I had to rain on their parade by pointing out how badly it performs. Our a/b study of sticky vs 320x50 top banner showed a 58% revenue drop switching from top banner to sticky. A lot of that was reduced impression count hence the request to make it appear after any scroll. Study attached.

AMP Case Study Top Banner vs. Adhesion Ad.pdf

[zhouyx]

We'd like to see that change to trigger at the end of the first scroll regardless of length and regardless of additional available content.

Now I get it, what you mean by first scroll is there's no requirement to scroll length. @jpettitt I think I understand you wrong. thanks to @aghassemi for explaining the issue, I will leave the decision to UX.

[cramforce]

I could get behind "user scrolled and has stopped scrolling". @jasti Do we have data about user preference based on when the ad loads?

[jasti]

@cramforce We didn't test the reverse case, but we did test the sticky to appear as soon as possible and it ranked really high.
As long as the ad itself doesn't cause screen jank, we should definitely try this.
@aghassemi would you be able to take a stab? (Request ad after first scroll stops immaterial of page length).

[aghassemi]

Alright, let's put it behind an experiment flag and take it from there. This is definitely a balancing act between UX and revenue. Needless to say, we care about both.

[jasti]

@aghassemi - wanted to confirm if you were looking this implementation or did you want @lannka to take over?

[aghassemi]

@jasti I only managed to look into it but didn't get a chance to implement before leaving for vacation. @lannka @zhouyx could you take over? resources-impl already has some logic for detecting scroll stop, it would be nice to refactor that into a common helper to use here as well. One way would be runtime dispatching an amp-scrolling-stopped DOM event that we can listen to using normal event helpers like listenOnce.

[zhouyx]

will take over.

[zhouyx]

With the proposal display sticky-ad after scroll stops. It is possible that user scroll slowly while consuming content. What's our idea on that?

[jasti]

As discussed, we shouldn't have any restrictions on scroll. Any user interaction with the document should trigger loading the ad.

[zhouyx]

Thanks @jasti

As we went back and forth on deciding when to display sticky-ad. I want to explain our discussion conclusions more here. The discussion is based on that we already take care of resources scheduling, and achieving good UX is the only concern.

The bad UX is we display sticky-ad to user before then even start to consume a page. (that's mostly like when users are swiping between amp viewer carousel)

As long as user start to consume an article, it is OK to display the ad to them as soon as possible (it's also best to revenue). Display before scrolling stops is also acceptable as long as it doesn't cause screen jank (we will still need to wait for scroll to slows down). This requires us to detect first user interaction with the document to trigger sticky ad loading. The interaction most likely is viewport scrolling, but maybe we should also consider user clicking contents in first viewport.

As we agreed, will put an experiment flag to compare current and proposed approach.

[zhouyx]

update on this issue:

This requires us to detect first user interaction with the document to trigger sticky ad loading. The interaction most likely is viewport scrolling, but maybe we should also consider user clicking contents in first viewport.

After discussion, we agree in most cases viewport scrolling will be the first user interaction. And we decide to only listen to that to balance between display rate and performance.
PR: #7478

[zhouyx]

The PR is in. I am using an experiment flag sticky-ad-early-load. How do we test with the new behavior. Should I enable this feature in 1% canary, aka set the flag to true for all canary version.

[lannka]

Yep, we can do 1% canary (to catch any errors/bugs).
Meantime, everyone can opt-in and play with the new experience and give feedback.

[zhouyx]

FYI: Already turned on the experiment flag in canary #7586
Should be able to see in next week's 1% canary

[zhouyx]

@jasti This has been in 1% canary for two weeks. Should we go ahead and push the change to prod?

[jasti]

@jpettitt have you had a chance to measure revenue impact for this?

[jasti]

Ping @jpettitt.

[jpettitt]

@jasti hard to measure when it's in canary. Given the date it goes to prod I'll be able to give you before/after data.

[jasti]

Thanks. @zhouyx would you be able to push it to prod in the upcoming release?

[jasti]

This has launched.