Whenever I’m talking to people about AMP I generally get two clear responses, either they love it or hate it. As a brit I would normally refer to AMP as very much like Marmite, but I understand this doesn’t always translate globally. If you don’t know what Marmite is then give it a try and you will learn exactly what I mean.
Moving back to the subject of AMP, I’m keen to dispel some myths and comments that I hear daily once and for all. I write “once and for all” like the myths will magically disappear after writing this, but sadly they won’t. My real reason to put pen to digital paper is to help spread the knowledge within the industry, as it seems like the haters write more than the lovers.
So what are the myths I hear all the time?
– Isn’t AMP owned by Google?
– Google is killing AMP off
– Advertising revenues are lower on AMP than Mobile Web
– Core Web Vitals changes don’t favor AMP anymore
– Speed of a mobile web can be faster, so why use AMP?
Before I jump in and give you my opinion on this subject, let me tell you why you should hear me out.
– 17 years in digital publishing and advertising
– 2 times IAB council chairman. (IASH and Audio councils)
– Previous board member of Prebid
– Trained software engineer
I personally believe you should never take any advice/knowledge from someone that isn’t qualified to give it. I read plenty of articles on AMP and why it’s dying or isn’t relevant and 99% of the time they are written by folks that only say this because they are Google haters or just simply would benefit from AMP not being a thing.
So here’s my confession —
– I run a digital advertising business called Triple13 (recently acquired by Freestar) which specializes in creating revenues from AMP content.
– Triple13 is a Google Advertising Partner.
– I personally think that AMP HTML is the best choice for most publishers to ensure their content is optimized for mobile users.
Onto the myths…
1. Isn’t AMP owned by Google?
AMP (originally an acronym for Accelerated Mobile Pages) is an open source HTML framework developed by the AMP Open Source Project. It was originally created by Google as a competitor to Facebook Instant Articles and Apple News. AMP is optimized for mobile web browsing and intended to help webpages load faster.AMP pages may be cached by a CDN, such as Microsoft Bing or Cloudflare’s AMP caches, which allows pages to be served more quickly.
AMP was first announced on October 7, 2015. After a technical preview period, AMP pages began appearing in Google mobile search results in February 2016. AMP has been criticized for potentially giving further control over the web to Google and other concerns. The AMP Project announced it would move to an open governance model on September 18, 2018
Wikipedia
The key point here is that Google did start the project, but it’s 100% open source and Google doesn’t own it. If you interrogate the exact developers working on the project in Github, you will see there is still a good volume of work being done by Google employees. It’s definitely a community project which has a large range of companies/individual’s actively involved.
2. Isn’t Google killing AMP off?
I believe the critical answer here is that it’s not Googles to kill off, with that said they could simply stop AMP showing up in search results and that would kill it by default. The next question here is why would they ever do that? I have personally sat in numerous Google events virtually and also in their Dublin offices and there is a very constant theme, user experience and speed. There are loads of studies showing user bounce rates on slow mobile pages and without cannibalising other information in this post, AMP generally is the best and fastest option for most publishers to adopt enabling them to have a great user experience.
3. Advertising revenues are lower on AMP than Mobile Web
If I was going to be on Mastermind this would very likely be my specialist subject. Without a doubt, revenues from AMP content can definitely beat mobile web content page for page. The main issue here is that virtually every publisher I speak to don’t have the correct knowledge to make this a reality. More broadly speaking the level of AMP advertising knowledge in the industry is extremely low or more like nonexistent. If you do know what you are doing you can create the perfect storm, the fastest user-friendly content and also the best revenues. I’m missing out on a small but critical factor here… advertising campaigns perform extremely well in AMP, again when the advertising placements are set up correctly.
Most publishers code that I inspect generally are running with stock Google AdManager (still named doubleclick in the world of AMP) setup and this will only yield mediocre results. I would suggest any publisher wanting to optimize their AMP setup need to focus on these three key areas.
– The configuration on the AMP-AD code on the page. There are loads of tweaks and areas for optimization here, but I will save that for my next posts.
– The right demand mix. Each AMP-AD on the page has the option to add extra technology into the stack and this uses something called the rtc-config. Using the rtc-config you can add technologies like DMP’s and Server-Side bidding.
– Floor price optimization. The correct floor pricing set-up in Google AdManager can yield great results. I personally prefer using dynamic floor pricing technology, as doing this process manually can be very complex and time-consuming.
4. Core web vitals changes don’t favor AMP anymore
Last year Google released Core Web Vitals, and with this released stopped favoring .amphmtl over a standard mobile web .html. I believe this change is a great update to level the playing field, but when you look at the stats it’s extremely likely that AMP will remain on top. The Core Web Vitals update is part of the Page Experience algorithm update, as that’s its clear focus or with the move to everything being mobile-first maybe Mobile Page Experience Update.
Several of my favorite stats, these speak for themselves.
– AMP domains are 5 x more likely to pass Core Web Vitals than non-AMP
– 60% of AMP domains pass verses 12% non-AMP
The conclusion is like most superhero films, the superhero (being AMP in the case) will always come out on top. With that said.. we won’t talk about Avengers: Endgame, RIP Ironman & Tony Stark.
5. Speed of a mobile web can be faster, so why use AMP?
This is one of my favorite myths, as it’s not really a myth as it’s true. You can definitely optimize mobile web pages to be super fast, but in my option for most publishers that’s not a reality they should be opting for.
AMP out of the box is extremely fast and should be used where possible, unless the publisher has the resources and budget to continually invest in mobile web development. AMP is amazing for user page experience, it is backed by a large community and can perform financially for publishers and advertisers alike.
The analogy I always use here is always the same. In Fast and Furious you don’t see Dom (Vin Diesel) modifying a family SUV to be the fastest vehicle on the street, he always opts for a fast car and makes it faster. AMP is that fast car.
If you are interested in optimizing AMP then you should check out this on the amp.dev blog.
Conclusion
Publishers should start loving AMP as much as the readers of the content clearly do. The readers of the content should come first and the return on investment will come back to the publishers.
I will leave you will an extra thought.
What if the publisher was to run a 100% AMP website?
– Amazing user experience on all devices
– Extremely fast
– Single code base to manage
– Easy to maintain for high Core Web Vital results
– Very likely more visitors through organic search
– Increased revenues
Spoiler alert: This is happening and the results are wonderful.
