Nepomuk Seiler
highfivve / Head of Engineering
AMP was a good concept for the wrong problem
Accelerated Mobile Pages, or short AMP, are standard, mainly developed by Google. The idea to reduce features and flexibility in order to improve execution speed, in this case website performance, is a common practice in software development. It is a lot easier to implement, test, and optimise if you have a defined set of features.
The AMP website states its goal:
“AMP is a web component framework to easily create user-first experiences for the web”
Unfortunately, I’ve learned over the last few years that this has been, at best, a promise. The homepage lists four categories: websites, stories, emails, and ads. Yes, ads are a user-first experience for the AMP project, hinting at the bigger intentions behind this standard. What did AMP mean for publishers, for us implementing it? It meant the following:
- developing the same website twice – regular web and AMP
- monetizing the same website twice with two completely different ad tech stacks – regular web and AMP. AMP cannot execute arbitrary javascript. This means you cannot run prebid.js, but instead you have to use a prebid server or use bidders that support AMP RTC
- dealing with caching issues, because Google would cache the content and take control away from publishers
No publisher would use AMP, if the reason was to build “user-first experiences”, because you can optimise your regular page with the time you don’t spend on building your AMP page. However, Google had a convincing argument: you’ll appear only in the news carousell if you support AMP.
Why did Google do this? Look at the developers.google.com/amp
- Google Search – We give you better rankings
- Google Cache – We take your content
- Google Analytics – We take your data
- Google Ads – We monetize everything for your
It’s not about the users, but rather about you handing everything over to Google. I’m glad that AMP is slowly dying.
Website performance does matter!
The publishers are not the issue here. A good user experience is or should be a main focus for all publishers. Developers are more than happy and capable of building a performant and responsive website.
However, developers, journalists, content creators, and other employees still want to get paid for their work. A fast website doesn’t pay the bills on its own. The most common and easiest way to monetize a website is still advertising. Users have a very low willingness to pay for content because so much of it is available for free. And companies rarely want to pay for it, as the shameful crawling by AI companies demonstrates, where they steal content and commit copyright infringements on an unprecedented scale.
So, advertising it is.
What has this to do with AMP? Instead of just forcing the AMP standard onto publishers, there needs to be a similar standard for creatives.
AMP for Creatives
In the following, I’ll focus on classic display ads, though this might also apply to rich media and video ads. The truth is, most display creatives consist of a simple image, some text, and a call to action. Yet, today, with tools like ChatGPT, a creative might load an entire JavaScript frontend library—designed for complex applications like our reporting dashboard—just to display a button. But remember, your creative could be built with technology that’s been around for over twenty years. For instance, I’m writing this in Google Docs. By hand.
A little bit of CSS and done. Gareth describes this in his blog post Rethinking Programmatic and The Open Internet under Fix Inventory Itself pretty well. Advertisers should have full transparency and deserve to know what formats they are buying and where they are delivered. And while I think a common page layout is a bit too much, a creative standard that extends beyond sizes, would be great. I still have hopes in Prebid Native as it is the technical basis. DSPs send assets and the publisher can render the creative according to the spec.
Verification Vendors
I understand that DSPs give control to the publishers. But how can advertisers ensure that publishers have correctly implemented the creative specifications? Who is responsible for continuously monitoring this? On the other hand, publishers ask themselves similar questions: How can I ensure that advertiser creatives don’t break my website? How do I initially test if everything works correctly? And how do I continuously monitor this?”
Instead of include lists based on intransparent constraints, we should have public lists of publishers that are compliant with creative specifications. Independent companies can monitor and watch publishers. Adalytics and check my ads already do this. As an advertiser you might work with sincera to obtain a list of publishers that support certain creative specifications, allowing you to prioritise those partners.
Suddenly, the discussion shifts from whether a website is made for arbitrage, advertising, or has a high ad load to whether it implements the required specifications, doesn’t implement them, or falsely claims to while attempting to deceive you (fraud).
And maybe users won’t install so many ad blockers if half of the internet weren’t plagued by broken creatives.
Give publishers control over their page
It’s their platform, and they’re the ones dealing with poor-quality creatives being deployed. They lose users, and even your brand suffers. Do you really want to be the ad that freezes a user’s favourite cooking website? Specifications are like contracts—clear and enforceable by both parties, and they should align with reality. Ad Tech is no longer the wild west.
View the original article here