Website developers have seen some problems with analytics in AMP pages where bounce rate is high and there are artificially higher user and session counts. Now these problems have been solved, as Google has developed AMP Linker to help developers get accurate traffic reports.
In this episode of the award-winning Here’s Why digital marketing video series, we welcome Google’s Ben Morss to explain the new AMP Linker and how it solves analytics issues for AMP pages.
Don’t miss a single episode of Here’s Why. Click the subscribe button below to be notified via email each time a new video is published.
Resources
Transcript
Eric: Hi, everybody, Eric Enge here, really pleased to tell you that today we’ve got Ben Morss from Google. He is a Developer Advocate who works on things like AMP and page speed and all kinds of really cool stuff.
Ben: Thank you.
Eric: And we are doing an indie style video today, just to get a little raw, but we’re going to talk a little bit about the client ID API in AMP and how it came about to exist and what it was for.
Ben: That is awesome. My indie camera’s shaking over there. This indicates authenticity.
Eric: There you go. Excellent.
Ben: The audience appreciated that, although I went out of frame for a second, which made it even worse. Anyway, back to your question. This came about because of a problem introduced by AMP caches. So, as you may know, one of the things that makes AMP fast is the idea of AMP caches. Web spiders like Google’s and Microsoft Bing’s are looking for pages that meet the AMP validation rules that are valid AMP pages. When they find these things, they go ahead and stick these web pages into caches, which will then store your HTML, optimize your images, and make things extra fast. Not only do Google and Microsoft and other companies have data centers around the world that can serve pages quickly, but even more importantly, if you load up an AMP page from Google Search, for example, it will in some cases actually preload the HTML in an invisible area called iframe that can’t be seen. So, Google Search results appear over there, and your page might get preloaded in the background secretly. Then the user actually taps or clicks on it, then your page appears really fast.
This is possible because Google Search knows that AMP can control how much JavaScript is on the page, other things about the page, and it controls what images load. So, it knows that the user isn’t paying for extra battery life or data, loading all this stuff that it actually wants. Also, I didn’t mention this before, but it’s also privacy-preserving. So, it ensures that no data about the user gets sent to other sites until the user wants it to.
Anyway, that’s a lot of stuff about that. So, the client ID you’re asking me about. The problem with this is that analytics packages would be confused because – let’s say that you go to a site like eric.com, but you go there on the AMP cache instead. So, perhaps you’re actually at google.com, looking at the eric.com page, as shown by google.com. You click on a link somewhere on eric.com, you end up on eric.com itself. So, you actually have traveled from google.com to eric.com and analytics packages think you’re a new user, and they don’t know who you are. And so, they think it’s a totally different user, and that’s why you have these horrible bounce rates.
Eric: Yes. And it’s really interesting because that would often result in situations where the analytics you would have running in the Google cache version of your page would show very high bounce rates, like you said, very short times per session, very few page views per session. But there were some limitations in the client ID API that caused you to invent a new thing called AMP Linker. What’s that?
Ben: True. Well, back to the client ID for a minute. So, I have indeed, as you’ve said, seen people say, “I got a 95% bounce rate from AMP, why is this?” And I say, “Did you use client ID or Amp Linker?” And they say, “What are those things?” So, the client ID API with that is a way to track users essentially using cookies, which is how people usually get tracked across the web. So, analytic packages can know if you see the page first on google.com. then on eric.com it’s still you because those cookies will actually track who the person is. But the problem is that some browsers are blocking what’s called third-party cookies. So, if I’m on google.com and request cookies from eric.com, some browsers may block that request for security reasons, which is totally reasonable. This is why AMP Linker was invented. The AMP Linker uses URL query parameters instead. So, it adds query parameters to the URL, also standard practice in the world of analytics and ads. And that will let the user be identified from domain to domain, from google.com to eric.com without using cookies at all.
Eric: So, the official recommendation then is to use AMP Linker now, because it solves this third-party cookies/browser blocking problem.
Ben: Exactly. AMP Linker is just more reliable in all cases. Now, an even better solution that’s harder to do for most people and is being done right now is called signed exchanges. This is the new technology that Chrome supports, and other browsers are also considering supporting. Essentially what this is, it’s a way where you can say, as an owner of eric.com, google.com serves my page, and I know that this is an AMP cache. So, I’m going say that actually, this really is my content. I’m going to provide a cryptographic signature which says, this is my content, wherever it’s served from – google.com or eric.com. And then Chrome, and soon more browsers, will use eric.com instead of google.com. So, your page is always eric.com whether it’s on AMP cache or eric.com. If it’s eric.com all the time, then this problem goes away completely. So, with luck, if browsers support this in the near future, this whole analytics problem will no longer exist.
Eric: So, this is a very, very cool solution. Because, as I understand it, as long as the browser supports the signed exchange, then you’re independent of doing anything specific in any analytics package. It resolves this for everyone.
Ben: It solves a lot of different problems actually, one of which is that you don’t want to have your page necessarily showing somewhere at the top – google.com or some other domain up there – you want to have your domain up there. This makes that possible even if the cache of some sort is making it faster.
About Ben Morss
Ben is a Developer Advocate at Google, where he’s working to help the Web be faster and more beautiful. Prior to Google, he worked at the New York Times and AOL, and before that he was a full-time musician. He earned a BA in Computer Science at Harvard and a PhD in Music at the University of California. Rumor is that he still runs a band called Ancient Babies.
Don’t miss a single episode of Here’s Why. Click the subscribe button below to be notified via email each time a new video is published.
See all of our Here’s Why Videos | Subscribe to our YouTube Channel
