About Barry Adams

Barry is an award-winning SEO consultant specialising in technical and editorial SEO for news publishers across the globe. He’s been building and ranking websites since 1998, and has worked with a wide range of clients from micro-businesses to the world’s largest media brands.

Show Notes

Barry Adams – Bonus Episode – AMP Webinar

[00:00:05] Stewart: So we’ll get started. Again, thank you everyone that’s joined us today. It’s great. Great to have you with us. My name’s Stewart Richie, I’m founder cto, lead developer, whatever you wanna call me. At Powererd by Coffee, we are a specialist software and web development agency dealing with publishers and media organizations solving problems as they come up mostly with open source solutions.

Today our guest is Barry Adams. Barry, the owner of polemic Digital and an overall expert in STO four publishers news. Anyone with a ton of content, particularly fast moving content. Barry, is there anything else you wanna say, say, about yourself in terms of an introduction that I’ve missed there?

[00:00:40] Barry: Not really, except that I have no social filter left. Therefore there might be the odd f form on square word and I apologize in advance. Especially when it comes to the topic of today. I. Have strong opinions and tend to vocalize those in in profane ways.

[00:00:56] Stewart: Absolutely fine.

I’m sure everyone will be fine with that.

I certainly am. But that’ll be fine. I’m sure. So today our, our topic is Google AMP for publishers in 2023. Is it a useful tool or is it an ongoing headache?

[00:01:14] Stewart: So, Those that don’t know you know, always get to start at the basics . What is Google Amp? Can you tell us about that?

[00:01:20] Barry: Yeah. Originally introduced in 2015 AMP was accelerated mobile pages. That’s how they originally had the acronym.

And it was a web framework that Google introduced specifically to allow for fast loading mobile friendly webpages. That sounds fairly innocuous. You know, it’s, it’s a framework that developers can use to build very fast mobile-friendly web experiences. The issue was with amp, when Google inter use it, they decided to make it a requirement for top stories.

Visibility on mobile search results was basically meant that news publishers. Did not have a choice. They had to adopt AMP for their article pages. Create amp versions of their article pages to get any visibility in mobile search results on the top stories boxes. Now those top stories boxes in case you don’t know for most news publishers, the majority of the Google traffic.

Back then, and to a large extent still now will come from clicks from those top stories boxes. The top stories box is basically a news carousel on Google’s regular search results. Roughly one in 10 Google search results will have a news box of some description. And of course the majority of users will use Google on a mobile device.

I think 60% of mobile 60% of Google users use Google on a mobile. So if you’re not visible as a news publisher in those mobile top stories boxes, you lose quite a hefty chunk of your potential traffic from Google. So that was the, the stick that Google used to force adoption of amp basically. And the carrot was, Hey, you can use this to, to make very easy mobile-friendly search experiences.

And the stick was you have to use amp or you lose mostly your mobile traffic. I think that was probably the wrong foot for Google to start on because it didn’t really give Publicis a choice. It was was basically blackmail use, use Apple or, or fuck you. And that combined with the fact that when AMP was originally introduced in 2015 and then the requirement came in 2016, it didn’t have all of bells and whistles, didn’t have all the features that publishers actually needed to create coherent mobile experiences.

Launch AMP only accepted Google Analytics as a web analytics platform. Plus, at launch you needed a separate Google Analytics profile, Google Analytics property for amp. You couldn’t just use your existing Google Analytics property for that, which meant there was a huge disconnect to measurement between AMP and your regular articles.

A also didn’t support a lot of other things like videos initially. Very limited adoption for advertising platforms. So advertising opportunities in AMP were very limited and at launch, again, very prohibited by only Google approved ad platforms. And there were a lot of other things that just didn’t work.

You couldn’t do paywalls with, with AMP and a lot of other things. So it was basically Not even an MVP when it launched. And Google immediately forced publishers to use this very lackluster, underdeveloped standard. Of course, Google developed app very quickly after that and enabled a lot more features of functionality, but by then the, the seeds of discontent were already owed and publishers were already like, really, we have to do this?

And for a lot of publishers, amp just became a massive burden because it was. A separate development trajectory they had to do for just to have an AMP valid set of articles so that they could keep getting mobile traffic from Google. And then they had their regular webpages that they also needed to maintain and improve.

I think Google intended for AMP to become sort of a defecto standard that, you know, they went what they called the canonical. Especially in the first few years, they really tried to emphasize that, which basically meant Google wanted you to build all your web pages in the AMP standard, not just separate amp development track so that you built your whole website basically an app.

And, you know, eventually the standard got to that level where you could feasibly do that, that it had all the bells and whistles as a, as a framework where you could actually build an entire website in amp. But that took several years for the amp to, yeah. Sorry.

[00:05:36] Stewart: We’ve actually come across a few websites when we’ve been looked at, when asked to look at why things aren’t performing or when there’s problems that have been built entirely in amage, tml.

And so like, I wanna come back to that thought then of like being such a, a burden on, on publishers to do, cuz it was or still is. It’s not still around. You know, an entirely. Framework Par, not apparently an entirely separate framework. In reality, with its own syntax, its own kind of HTML markup, it wasn’t as simple like, oh, we just threw this tag on here and it’s fine.

You actually had to go out and redevelop your pages again as if it was an entirely separate channel. You were publishing content into all of a sudden you would have your. Your normal standard website, you had an API that like was able to push that content off to services and then AMP that you were running off as well.

So it’s actually a huge, huge development burden for a lot of publishers to maintain and yeah, very much not a simple thing to implement. But yeah. Sorry, I interrupted.

[00:06:41] Barry: No, no, that’s exactly it. It was, it’s not e it wasn’t easy cuz they had to basically rebuild their entire. Article template in amp and initially especially the, the limitations of AMP meant that it didn’t have the same look and feel as your own regular articles.

Plus of course, the main advantage that Google proclaimed that AMP had, which is faster load speed. Was a bit of a lie because that fast below speed experience was enabled because Google hosts amp articles in their own AMPcast and does a lot of preloading and speed optimizations in that AMPcast. Which basically meant, you know, Google hosts your AMP articles for you.

Rather than, you know, people visiting your app articles on your own website. Whenever an AMP article is shown even today in Google search results, and you click on that, you’re not actually going to the publisher’s website, you’re going to Google’s acast, which is of course one of the reasons. It’s one of

[00:07:32] Stewart: my, yeah, so this is one of my kind of primary problems with that.

It’s that it centralizes so much of the web within the control of a central organiz. I know there’s a lot of talk kind of with Web three and stuff and going decentralization of the web and stuff like that, but the web was inherently decentralized, like Web three and decentralization was is not a new thing.

The web is a decentralized platform at its core. We decentralized it a bit with the move to Facebook and stuff like that where everything kind of coalesced around primary social networks, but I like, this is my real bug. Bear with AMP at the time was like, you’re giving up so much control and putting it to a single entity.

That you are opposed to, your incentives are not aligned here. Yeah.

[00:08:20] Barry: Sorry. Go on. Yeah, I, I’ll tell you exactly when, for me, really crystallized that amp was a bad thing was when Google really started hammering home, the fact that your AMP articles needed to be perfectly equivalent to your regular non AMP articles.

They started sending out notifications via Google Search Console if Google detected differences between your AMP articles and irregular. For example, your regular articles have comments or videos and your AMP articles did not, and Google would show that as a warning in search consultant actively notify you and tell you that you needed to create perfect equivalence.

And that for me was when my patients with AMP were stretched beyond breaking point. And I wrote my, I suppose, fairly infamous article, Google App can go to hell. Because for me, that was the moment when I really understood what Google wanted to do with. Instead of Google adapting themselves to the decentralized, chaotic web and trying to build better mechanisms to cope with the chaos that is the web, Google forced to do web to adopt to them.

Google wanted to do web to become Google compliant, and to a large extent, they still do. They have other mechanisms that Google uses to make their own life easier, that have no direct. Websites themselves. For example, XML Sitemaps is a Google mechanism, schema.org structure. Your data is a Google mechanism that helps Google come to grips with your website.

They have no benefit for your users or for your website in terms of user experience and all that. It’s purely for Googles benefit. And AMP for me was again, an attempt by Google to make the web conform to them rather than them conforming to the. And that really got off my nose to such a level where I was like, nah, we, we shouldn’t be doing this.

Fuck you Google. We need to really, really push back. I was the only one on that. Of course, there’s, there’s been hundreds of articles written about how amp it goes against the decentralized nature of the web and how publishers should go against it. The problem is, of course, that publishers didn’t really have a choice because of the requirement for app articles to be present, to be shown in mobile top stories.

There was a bit of a hallmark moment as well when Google dropped that requirement. And we already had a bit of indication that Google was sort of abandoning AMP as a standard. They introduced a new set of load speed metrics, core web vitals, which sort of, you know, were derived from AMP to a certain extent.

But they gave developers and publishers very clear metrics. Terms of load speed and usability to optimize their articles for. And the people who were on the AMP advisory committee and part of the AMP engineering team at Google sort of started becoming less active, going on to different projects.

And then when Google dropped the requirement for top stories for amp, I think there was in 2020 that for me really was the moment like Google is, is letting this go. They, they, they’ve been fighting this for more than five. And they decided that, you know, amper is probably not going to be the future of, of mobile technology anymore.

[00:11:28] Stewart: So with that requirement removed to be part of using the top stories, they’re still notionally the advantage of, of it, you know, being fat. And a lot of people start like from an SEO perspective, do what Google wants and you’ll run well. Google wants Put amp pages in place and you’ll rank well in general.

Does that, does that still feel like the nature of the game when it comes to amp?

[00:11:57] Barry: Oh, I’ll tell you this. The moment Google dropped that top stories requirement, that AMP requirements for top stories, we saw a huge uplift in the number of publishers that did not have amp pages show up and top stories. You can point it down to the day when Google dropped that.

This also makes me a bit angry. Give a bit of background on there, because those publishers that suddenly started showing in top stories, which are Norm Amp articles, they’d never had AMP or they deleted AMP before Google Top the requirement. They take all the other boxes that Google asks the publishers, high quality content, reputable publishers, strong topical authority, good journalism, but they did not show in mobile top stories because they didn’t have Amber.

And from one day to the next, they started showing in top stories because they had had amp articles and I suppose to a certain extent that we should make the publishers happy. Like, Hey, we’re suddenly subject showing that. But for me, it showed the power that Google has that just because those publishers didn’t have AMP articles, but they had quality journalism and great content, they did not show in top stories for nearly five.

They didn’t get traffic from mobile versions from Google for nearly five years, despite the fact they were perfectly valid, legitimate news publishers producing quality journalism. But Google throttled their traffic, throttled their visibility because they failed to adapt Google’s own web standard, and that really pissed me off.

And I was happy at the time that Google dropped the requirement, but at the same time it made me so angry because it made it so viscerally clear the power that Google has, cuz these, some, these publishers were struggling. They were struggling to get traffic and struggling to get advertising. Now you’re struggling to get subscribers because they didn’t get mobile traffic from Google.

Now moving on, the top stories requirement was dropped and there is a case to be made on, Hey, aper still exists as a framework. Still exists as a platform. You can still build AMP pages and you get that speed advantage. But you know, you still have all the other issues with AMP reduced monetization because of the limitation that AMP has for advertising.

The lack of integration with your payrolls. There’s a lot of other things that are difficult or challenging or impossible to do an app. And of course, you know, the stuff being hosted in Google’s app, cash. On the other hand, we now have core vitals which is fairly decent as, as a set of metrics that you can optimize your website for, to measure subjective, low speed experiences that your users have.

And I think, you know, AMP as a standard basically being dead in the water, especially now that Google has gone entirely quiet on amp, they even removed AMP from all the pertinent documentation. When it comes to article structure data, for example, there’s no banks of a anymore in Google documentation.

They’re basically just letting it go. All the Google engineers who used to work on app have moved onto other projects. There hasn’t been a proper update to the AMP standard in, in months, if not years. So the thing is that in the water, the, it’s basically been abandoned. So for me, it makes no sense as a publisher to keep investing in AMP and creating AMP pages.

What you should be doing is investing in your core, but vital. Making sure your website tick. Web vitals is mainly green for your norm. A pages and core web vitals. Make your website load as fast as you can and, and, you know, with good lcp, good c Ls all those things. And then just get rid of amp. Just delete it and, and get rid of it and pretend it never happened, basically.

[00:15:29] Stewart: I think that’s very fair. I think. You know, any ranking advantage that it seems like Amad, you know, is replaced. You know, not that apparently not that AKI have a specific advantage beyond the news placement that it provided, the speed boost that the algorithm used as that ranking or ranking metric, but positioning metric and if Google have now moved to entirely replace that with what your core vitals and other Chrome user experience research metrics.

Then what is the point of keeping Amp around continuing to invest in it? Particularly if at this point it seems not like an if Google will discontinue it and drop it as a product, but when. A company that has already

[00:16:13] Barry: more or less, yeah, it’s already more or less that in the water. It’s just Google hasn’t pulled the plug entirely yet because a lot of publishers still have a pages now.

I think the effort that publisher currently puts into maintaining and hosting those A pages, you should probably put that into your core vitals, improve those co vitals, get those as screen as you can get them, and then just delete your app articles. And you can do that in phases as well. You know, if you want to be safe about that, you.

Start publishing articles without the amp html reference link in the HTML source code. So Google doesn’t know that there’s an AMP version and so won’t call an index the AMP version. So, and then see what the impact is. You know? Do you lose any traffic? I mean, in the last year and a half, we’ve had major publishers kill off their AMP articles like Reuters killed off their AMP articles.

The Future Publishing Kilda Amp articles, Tribune Publishing in the US killed of AMP for all the publications in stages and none of them saw any detrimental impact. Some of ’em even saw a bit, a bit of an uplift in traffic, and definitely an uplift in. Modernization for, for the non app articles because of the freedom that he got in terms of advertising placements.

So,

[00:17:16] Stewart: I think you can go further than that. You never mind just pure advertising, but access to first party data, you know that user is now heading your server or at least your own cashes. You can load whatever you want within, you know, legal requirements for data protection. You know, do whatever analytics generate first party data you actually derive.

Revenue value to create revenue in the future. Whether that’s through improving your products, better analytics, integration with your primary analytics accounts, rather than having to use whatever Google said and whatever advertisers you feel like, rather than just whatever Google has okayed to be in, in.

I mean, the other thing is too, you suddenly free up a lot of resource that would’ve gone into developing, maintaining, managing your versions that can go into core and. By the sign of it. If Amp Amp standard isn’t gonna change soon, if your setup works, you can just ignore it while you funnel all that work into your core vitals.

Improvements until such a time is you’re confident that it’s not gonna be an issue and turn it off in pieces as you said. Does that make sense? Absolutely.

[00:18:23] Barry: You know, you can just delete amp entirely if you’re comfortable enough about that. And then three, one, redirect your amp URLs through your regular URLs.

You can also ping Google’s app cash to flush your articles from that cache, in which case you’ve been entirely migrated off amp and then all your traffic for mobile or D. Otherwise, we go directly to your own webpages. And like, like you said, you, you get all the first party data. You’re not breaking GDPR rules anymore.

You’re ac actively legal in the e. Unless you use Google Analytics, in which case you will still be illegal in the EU cause you’re sending Data to America servers. But that’s a different discussion for a different webinar. I suppose.

[00:18:59] Stewart: That’s a different webinar host and analytics if possible, these days.

Absolutely awesome. I think then if possible, I mean, it’d be really great if we had some insight into your groups that have turned it off. I remember reading quite a lot about, I think it was Search engine journal when they turned off. I think Land turned it off. Search engine land. Yeah, that’s the one.

About like, they, nice, they were gonna turn it off. They turned it off and then they kind of reported on, on what they actually saw happen. And it was all the things that you. Reported from your own experience of like, we were able to get better first party data. We were able to make, you know, better decisions.

We didn’t see a drop in, in Clickthroughs. Because we invested in our core vitals, we invested in like structured data on pages to communicate all the same things which are not necessarily easy things to do, but they’re things that are within, within your

[00:19:51] Q&A

[00:19:51] Stewart: control.

[00:19:53] Stewart: If anyone has any questions you wanna ask we will do our best to answer them. I can see we’ve got two popped up in q a. Unfortunately this was never an unbiased conversation. It said nothing positive you can say about amp. I think if something positive, but Amp Amp was a great idea at the time.

If it had become a neutral web standard, so if it had gone on to like become under the management of the W three C as like a stripped down version of the web that we could use, like there would actually have been a lot of value to that. A lot of the problems with I feel to me were about it being controlled by a single organization.

What do you think, Barry?

[00:20:33] Barry: Yeah, I agree with that. I. AMP in 2019 is a very different beast from AMP in 2015. When AMP launched in 2015, it just wasn’t ready for the big stage yet. But Google forced adoption on it AMP in 2019 is actually pretty robust framework, and that’s the framework we still have today.

You know, you can do a lot of cool things with amp. I think. For example, AMP has a live blogging component, which some publishers use to build their own live blogging technology. Which is really, really powerful and really mobile. It’s mobile friendly and very useful. And there’s a lot of other components of the amp framework that are actually really good that developers can use to fairly rapidly build mobile friendly, fast loading web experiences with like web stories, for example, is based on the AMP standard as well.

Just the resentment that app has created by forcing, by Google, forcing it down our throat, and by all the, the problems it has in terms of monetization, third party data, paywall structures, et cetera, has created such a negative overarching experience that is hard to talk about AMP in a positive light.

You know, it’s just, it’s, they did more things wrong than they did right when it came to, to using AMP and, and launching amp, and I hope Google has learned from that. But it’s not a bad web, standard web framework. You can take an app framework now and build a website on that. No problem. You, you know, it’s, it’s a pretty decent way to build a website.

In fact, I’d probably prefer that over using a, a, a JavaScript framework like Reactor or Angular, because an app framework is much more SEO-friendly out of the box than all that bloated JavaScript crap that we have to deal with as well from other frameworks. So I don’t, I don’t, I’m not inherently against using AMP in that way.

I’m just. I have a lot of problems with how Google forced the down our throats and how Google used it to basically make the web conform to their vision of what the web should be like. Plus of course, you know, publishers are cash trapped enough as it is. Publishers aren’t and shouldn’t be technology companies, so they shouldn’t be forced into certain technological straight jackets including amp.

And they’re better off just trying to improve the whatever framework and standards they have at their own in their own scenario, rather than try to adopt something else entirely, which may not align with what the internal skills and capabilities are about. So, you know, app App isn’t terrible now, but it was terrible when it launched and the way Google used Amp to basically hammer it home for publishers created so much bad feeling that it’s, it’s hard to see the positives.

[00:23:00] Stewart: Yeah, just to give credit that, that question was by Roberto and Eddie. And just to like double down kind of on that, like, I think if there was a version of AMP that you could run from like a JavaScript task runner where you handed it your kind of amp html and got out your optimized html, like in the AM standard back that you could host somewhere else.

I think it would be a very different story of how I, how we kind of felt. Next question, and I’m sorry if I’ve mispronounced your name, but Maha what would you recommend removing AMPERS from your website when you have a page experience? Mobile and desktop, 99% and AM traffic is around 3% from GSE ds, Google Search Console.

Second part, still in using the AMP article. Google is still using the AMP article because I have two different logos on the same article, on AMP versions and on AMP version, some articles and top stories on desktop. I’m seeing that that there is the AMP logo from Schema. Even if the page experiences at 99%, it still uses the amp version of some articles.

I would this affect my visibility.

[00:24:07] Barry: Don’t take this as gospel, but I suspect there would be no impact on your visibility when you delete app. If your corporate vitals and page experience is very good, Google will always use an ampers or mobile if there is an ampers, or always, nearly always if, if you can index your ampers and, and use that, it’ll show that in mobile.

If there isn’t an ampers, then Google will just use your regular version. So in in your scenario, I would feel pretty confident that you would not see any negative impact from turning off amp. I’d say you can, if you can do it, maybe do it in a, on a per section basis, like, stop publishing amp or remove the amp html reference from a specific section of your news website and see how that impacts on traffic and visibility for articles in that section.

But yeah, I’d think it’s, it’s pretty safe for you to start deleting app.

[00:24:54] Stewart: Think, I mean, there is a, like Barry mentioned, there’s URL you can ping to decaf a particular page. So working out if YouCash that page to kind of work out where those differences are coming from might be like a short term solution to trying to fix that.

Next app. Question from Raphael Rubio. Do you recommend turning off Amp when the site is really slow? Slash core vitals are really bad.

[00:25:19] Barry: No, that’s the one scenario where I think you need to be very, very careful with because APP does give you a huge low speed advantage because of the, the, the benefits of the standard itself, plus the fact that Google does extra optimization and preloading and pre rendering from the app cash.

If your core vitals are really, really bad on your non AMP article. You will need to improve those. Cobra vitals are actually a quite a strong ranking signal in Google’s news, carousels and top stories, especially on mobile. So you’ll need to make sure that your Cobra vitals are mainly green and orange and not red before you even consider turning off app.

If your Cobra vitals are very, very bad, you will probably need a for the foreseeable future until you find that improvement somewhere, because otherwise I think you will see a drop in your visibility when you turn.

[00:26:12] Stewart: I think that that is kind of site specific and specific to your audience. If you’re like a news organization, then yeah, you need to work on getting the score of titles up.

But if you’re maybe more of a trip application that has a dedicated readership with a lot of kind of return returning views and people are searching for your brand and to me and to get your content, then maybe you can look at it turning off. It depends kind of where, where your audience is, but you should definitely put some time and effort into the core of vitals regardless.

Then Roberto and Eddie has come back to us with, I agree with everything you’ve both mentioned about how Google Track for Sam, let me ask you this, if you need to remember about him. And imagine a technology called X. They force you to minimize your CSS, limits your JavaScript, and catches your pages.

Doesn’t that make sense? The problem is that doing that as hard, so we developed rob wamp.com and we’d love for you to try it. We make automatic app conversions with just one line of code. Thank you for this conversation and thank you for your input.

[00:27:10] Barry: Roberto I’m gonna have to caveat that and say no, that doesn’t necessarily make sense because what does that mean in terms of limited JavaScript?

What functionality is being removed there? What do you lose? Off the back of that. Plus we cannot separate amp from the amp ca, we cannot just say, oh, you have an AMP version. Therefore, it’s, it’s better, it loads faster. Google will host it in the AMPcast and that brings all kinds of other problems with third party tracking.

And the fact that it’s not your web server that’s get the traffic is Google’s web server and, and amp link links will be hosted from the app. So it’s not just a simple O Amp amp as a framework on its own. It’s better because Amp. only exists in the context of our Google users app at the moment. You know, if Google ever retires the amp cash, we have a d.

Context for app in which places say, yeah, maybe, you know, you can use the AMP framework in certain ways to make better versions of your mobile pages. At the moment, we don’t have that context, and therefore I would be very hesitant to adopt a technology that turns my pages into AMP pages because of the way Google will then treat those app pages.

So I, I would admire you for, for trying that. Robert, I think it’s, it’s probably a, a very interesting technology. There are inherent problems with that in that you’re basically giving your pages to Google for Google to do well with as they please rather than, you know, how you having full control over how your content is being displayed and how your content is being shown and how visitors interact with your content.

Plus, of course, the limitations that app still has in terms of monetization and advertising, which haven’t disappeared. They’ve, they’ve been, it’s been better, but it’s still not, not perfect by any strikes, and therefore, you know, will, you will still lose something if you change your pages into end pages.

[00:28:54] Stewart: Raphael has also come back with an update to say that they also have AMP on their tag pages. So I imagine that’s their kind of categories, you know, their pillars and, and things like that. Since this implant, those pages, they’ve started ranking better. Do you think it makes sense to keep amp there?

The non amp version is also very slow.

[00:29:11] Barry: Well, you sort of answered your question there, Rafael. The version is slow. The end version is fast. Google will show the end version in mobile search results cause it’s the faster version. And therefore you get better traffic to them. I would say maybe try to make your non-lab version faster.

But at the other end, you know, I, if you’re happy enough to maintain AMP and keep that effort there and for you, that makes financial sense to keep doing that. Because I suppose for your tag pages, that’s not a huge amount of monetization opportunities in terms of advertising then. Yeah, there’s no, there’s no inhabit reason for you not to keep app.

Just a lot of publishers. Have limited monetization on their app articles and especially publishers that have paywalls have a huge disconnect between the AMP experience and the regular web experience because users just who hit an app article are not logged into the paywall, even if they are logged in to the paywall on your regular articles.

So that might be a huge experience problem that you have. But you know, if you think Right, we we’re keeping AMP for now because we’ll be seeing more benefits than than downsides, then hey, by all means, knock yourself.

[00:30:12] Stewart: I think it’s important to remember there too, that amp is effectively acting as a bandied over a problem.

It’s not fixing the cause of why the site isn’t ranking well on those pages, and that if Amp goes away, which it may well do, like there’s a perfectly reasonable chance that a press release came out today while we were doing this. It says it’s being discontinued. It’s unlikely, but it’s not impossible.

So you kind of have to think about preparing for a world where that isn’t there to help in that situation. And also, you know, there are other browsers than Google. How does it impact them? Maybe they’re not very well used. Maybe it’s not a factor for you, but just a thing to consider. And Roberto came back once again just to, to hammer home and appointed that you can separate from the amp cash with signed exchanges.

And he’s given us a link to. Documentation on the amp site that we’ll fire into a tweet or part of an email or something just so that we can, like, make sure everyone knows everything. Exchanges

[00:31:12] Barry: have problem. By the way, I remember folks at Mozilla going on the record as being very antis exchanges because again, it’s a Google and not a, a a open web standard.

So, there are huge website exchanges as. Basically are almost the same issues that we have with app.

[00:31:33] Stewart: Awesome. Cool. And that’s, that’s the end of the, the q and A. We’ve got, thank you everyone who submitted a question. That was really good and I hope it was, it was helpful for everyone. Just to reiterate again this has been recorded.

We’ll send it out if you wanna have her listen again in your own, your own time. And if you would like to, oh, should’ve pushed that on. you’d like to get in touch with either me or Barry we’re both on Twitter either particularly active in this day and age but it’s still the easiest, most public quiz to get hold of us.

And Barry is also on Amadon. Barry, I just wanna thank you for taking the time out of your day. I know you’re busy. But I really enjoyed it. It’s really been great to talk about it. So thank you very much and have a lovely day. For everyone that is stuck around to listen to the q and a. Thank you again and I look forward to seeing you at another event.

I think we’re gonna have it’s not confirmed yet, but it’s looking like our next kind of event is gonna be around understanding programmatic advertising kind of at the basic level. Cuz I know it’s a huge deep topic and it’s confining even, even to me especially to me. So we’re gonna get someone to talk about that.

Thanks again, everyone. Have a lovely rest of your day and hopefully speak soon.

Links

You can find and follow Barry on Twitter @badams or @polemicdigital, and you can also find him on Mastodon @badams@mastodon.social