Google is bringing new ad types to AMP | Hacker News Reader

Google is bringing new ad types to AMP

techcrunch.com

35 pointsconfiscate32 comments

If anyone else had trouble finding an example of the flying carpet ads, see https://github.com/ampproject/amphtml/issues/3126

What's the benefit of flying carpet over just having the ad in the content?

Judging from the gif in the article it is basically just and image added in-line of the article, except it has a bit if parallex scrolling effects.

Seems less annoying than a sticky ad.

The benefit is that you can show a larger ad in a smaller space. Since screens are super small on mobile, advertisers need a way to show you big eye-catching ads without disturbing the content too much.

Maybe it just catches the eye more, because it doesn't move with the rest of the content as you scroll. It's harder to just scroll past without noticing it...

AMP always was such an obvious way to end run adblockers. How are carpet ads less annoying than a popup? On mobile I dread accidentally tapping almost anything so this is a troubling development.

I wouldn't compare it to a pop-up (at least not from the animation in the article) but it looks very much like a big in-line ad only the content has a gap that reveals the ad, instead of the ad being placed in the same, scrolling column as the content.

So how is this more troubling than an in-line ad?

I'd consider it more of a mobile interstitial. Interstitials in general are regarded as pretty invasive. But frankly the Google mobile SERP has turned into a big interstitial these days with ads taking up the entire first screen in may cases, requiring you to scroll to see any actual organic results.

since amp is normal html, ad blockers still work

- Greater visibility (since you can take up most of the screen)

- Likely a much higher chance of accidental clicks (not a good thing for advertisers, but that won't stop people from claiming this format has a higher CTR)

- Focuses your attention way more on the ad. Instead of something that just scrolls by super quickly with the flick of a thumb, until you get to the next block of content, the image itself is static, so your brain can parse it even in the couple of seconds it is on the screen because it is not actually moving.

We spent a lot of time making accidental clicks unlikely (and making sure that scrolling on the ad scrolls the page)

One other benefit is that because the ad is on a parallax pane, it can resize itself without disrupting the page flow (which AMP does not allow).

Are you on the team that made these new formats?

I'd love to know what sorts of things you do to avoid accidental clicks. I assume click location relative to the frame of the unit is part of it, and possible pausing to wait for swipe activity to confirm a click, but would really be interested in knowing more (I'm a buy-side ad guy).

Unfortunately, Google isn't the only one with this format, and on many pages I've had false clicks when scrolling through this format. To most users, they will have no clue whether this is a Google ad or not, and I'd be shocked if they didn't equate bad experiences with every network, regardless of whose ad was actually misbehaving.

I'm the tech lead of the AMP project.

Our work was mostly related to ensuring that native scrolling of the main page works as expected when the finger touches the ad iframe. This is non-trivial and most implementations do it by forwarding touch events from the ad up to the page, which then feels laggy and leads to touches that are interpreted as clicks.

Interesting--thanks for the insights.

Overall, I'm curious to see what happens with this. I have my own thoughts on the business side of AMP as it relates to advertisers, publishers, exchanges, DMPs, etc., but from a technical standpoint it is pretty cool what you guys are doing.

What's the reason for having the ad be an iframe at all? If this is intended to be a low-bandwidth experience, and the ads aren't going to animate or contain Javascript, then why not just mandate that the ad format be a plain image in PNG/SVG (or in AMP HTML, but with the proviso that it will be baked from an offscreen DOM fragment into a static image blob before being displayed) and then just display it as the background-image of a really long div, with fixed attachment and no repeat?

- It doesn't have greater visibility than an inline picture. They have the same size.

- I'm not seeing how this is easier to accidentally click than a large, inline picture.

- the static part is a really good point.

Depending on the size of the inline picture (not just with Google) it could be larger. I've definitely seen some shorter native formats in the wild.

The accidental click comes in since you can't just scroll past this with one swipe. I haven't tested this particular one, but every single other flying carpet I've seen restricts flicking motions to get past it in one fell swoop. They require multiple clicks to inch it up the screen, and that requirement alone increases the risk for accidental clicks by the mere fact that it requires more touches on the ad to get past it (despite said touches being paired with a swipe motion).

I really hope this new format is aggressive against accidental clicks, but on older devices where those actions might take longer to process (ie. my beautiful old Nexus 4), or where people are clumsy, or don't have strong screen contact (gloves), I could see it registering as accidental clicks.

Per my other response in this thread, I would hope there is logic around things like waiting to see if a swipe motion immediately follows the touch, looking at how close the touch is to the perimeter of the unit, etc. But I just don't know at this point so I'm going to err on the side of more accidental clicks based on past experiences with this format on other networks/publishers.

So the implementation breaks the inertia scrolling we all come to expect from our touch devices. That wasn't clear from the gif (I have actually never seen these in the wild).

I hope that is just a result of bad implementation rather than being a design feature.

Thank you for deeper insight.

This format is not exclusive to Google, so it could be that individual publishers/networks have different behavior (which is in itself an issue as it confuses users on their expectations).

But yes, just got one this morning (presumedly not Google) where it took me about five flicking motions from bottom to top of screen to clear the ad. Super annoying as the brain expects one behavior and then to see the sluggish movement.

By the screenshot it looks like AMP might do Flying Carpet Ads in a way I won't hate.

ASSUMING the necessity of advertising and high profile ads - the type of flying carpet ad in the screenshot, where it looks like it's just a position:fixed; background for a large div that can be clicked - I will be more than happy to scroll past.

Right now, what I really hate are the flying carpet ads where you're swiping up and the ad comes up OVER the content and gets in the way, slowing down the site, etc. Those are terrible.

As long as the page is not adjusting itself on load and the ad doesn't get in the way, I don't see this being a bad thing at all - and I think the AMP team is probably on that same wavelength.

That is exactly what we are doing. We spent roughly 4 weeks of pure research to get the scroll UX to 100% perfect (Turns out making a fixed positioned background element scroll the main scroller and be clickable is hard. Which is also why many implementations of flying carpet suck).

The goal is absolutely to make this not annoying at all.

[M]ore than 90 percent [of publishers] say they are getting higher click-through rates and most also see better earnings.

On mobile, this is alarming as I suspect it is due to more accidental clicks. A good ad platform will actually see the click-throughs go down as the platform renormalizes to clicks that reflect authentic interest.

EDIT: s/do/go/

The primary (but not only) reason is increase in so called viewability of ads (AMP renders fewer ads that nobody ever sees). Because click-through-rate is calculated as percentage of "renders", rather than "views", the CTR goes up when you have less "renders" that don't turn into a "view", because nobody can click on an ad that they have never seen.

This sounds like an excellent step in the right direction. I guess that's why the article implied that not all of the pages that saw greater CTR increased revenue.

Half the AMP articles I try to read don't let me scroll on iOS 8 Safari. I like using Google News but AMP has seriously hurt my experience. I would much rather just use Safari's built in Reader View, but of course this removes the ads they want me to see.

Would you mind filing an issue with an example article: https://github.com/ampproject/amphtml/issues/new

This is definitely not a known issue.

Edit: We can repro and filed https://github.com/ampproject/amphtml/issues/3481 It might be a bug in Google News (Because Google Search is fine), but we'll track it in AMP.

Which ad blockers can block all of these?

That is the point

Yuk.

The title cut out "to AMP", which is fairly relevant here.

We've restored that and taken out the baity bit.

What are ads again? I went ad blind in 1996 and popup blockers just cemented it. I don't go to Cinemas as I don't like paying for ads. I also would never watch any program interrupted with ads. I also would not pay for any cable or satellite service that also contains ads. As a result of all the above, I don't watch any film or television and my life is fine.

That's rather impressive but I don't see the point re: this article

Reply on news.ycombinator.com