Google announced at the AMP Conf 2019 (In Tokyo) that they will show a new dedicated space on the SERPs exclusively for AMP Stories. This may be a huge change for SEO, as to appear in this new block you will not only need to use AMP, but also to create content in the «Stories» format.

What are AMP Stories?

AMP Stories are just a specific format of displaying content using AMP. You probably know (and maybe even create or consume) stories from Snapchat, Instagram, Facebook… It’s a visual, vertical, mobile-first (and sometimes mobile-only) format of displaying content, with videos or images combined with small pieces of text.

AMP Stories are not new: they were launched early in 2018, as a way for publishers to create visual and more attractive content, focused on mobile. Some of the big publishers have been creating AMP Stories content since then, like the CNN. Here is an example of a published AMP Story: https://edition.cnn.com/ampstories/world/what-the-spring-equinox-means-for-you

AMP Stories in SERPs are not new neither, but until know, for non-branded queries, they just appeared as a «normal» search result with a thumbnail and an icon helping users identify it was a story format:

They also appeared inside the Top Stories box, among the rest of AMP articles:

When users click on it, they are taken to a «story» environment (exactly the same to the one Snapchat created and Instagram copied) where you can advance on the story by taping on the right side of the screen:

Where are AMP Stories hosted?

Contrary to what happens with Snapchat, Instagram or Facebook Stories, which you create with your phone through the corresponding apps and are uploaded to their platform (also, only for 24h, as after that they disappear), AMP Stories are «normal» pages hosted on your website, accessible through a URL.

For instance, the previous AMP Story from CNN can be found here: https://edition.cnn.com/ampstories/world/what-the-spring-equinox-means-for-you. It’s a «normal» AMP page, which is then cached by Google (just like any other AMP page of your website) and served directly by Google to the users through their AMP CDN.

Are AMP Stories good for SEO?

Until now, AMP Stories were just a format (you could try to create content like that with HTML 5, CSS and JS too) that would appear more visually appealing on the Top Stories box (only for big and medium publishers with newsworthy content) and also a small thumbnail with a stories icon on normal organic search results.

But with the new announcement made at the AMP Conf, this could be a game changer: Google will now include a specific «Visual Stories» box on mobile for some kind of searches, showing ONLY AMP Stories there, moving the normal organic results down (I mean, more than where they already are). They specifically announced that this new box will start appearing in the US for travel related queries (the example used on the presentation was «Things to do in Tokyo»), and later on, also for queries related to gaming, movies, tv shows, recipes and fashion:

This means that if you have a website that publishes content related to those areas, you will soon need to create AMP Stories if you want to try to rank on the first «content» area of the Search Results for some queries (we still don’t know when this box would be triggered)

You can watch the announcement here

How do I create AMP Stories?

All the information about how to create AMP Stories on your website can be found in this tutorial on the AMP official site: https://amp.dev/documentation/guides-and-tutorials/start/visual_story/

Basically, you will create a normal AMP page where you will include an AMP component (amp-story) which will contain the different «pages» (each of the «scenes», represented by the horizontal bars up on the screen), and also each page can contain different layers and elements (images, headings, etc.)

You can create stories on your own domain, each story on their own URL and following all the rest of SEO best practices: using a descriptive title and meta description, headings, etc. An AMP Story will be «a normal page», just more visual and interactive.

There are also some apps/tools appearing in order to simplify the creation of AMP Stories, like Make Stories, Unfold and also, the official AMP plugin for WordPress is going to include the functionality of creating AMP Stories

Can I make money with AMP Stories?

Yes! As AMP Stories are just a way of showing content, you can monetize them. By now, you can include Ads, affiliate links, as well as links to other pages of your site where you have other monetization methods. Google advises not to include lots of links inside the stories (as the purpose of the Stories is to be consumed without leaving them), and this will probably a grey area where SPAM will be applied and where Google will need to act.

How will Stories be selected and ranked?

We don’t know yet. We don’t know if authority will play a big role (like in the Top News box) or if any website big or small will have chances of appearing on the box. We also don’t know if the results will be evaluated and ranked based on the same criteria Google uses for normal results, or the ones they use for the Top Stories results, or if they will develop a new specific algorithm just for AMP Stories.

Will the new Visual Stories box appear on all the countries and languages?

For the moment it will only appear on the US, according to a tweet by Kenichi Suzuki. We don’t know if there are plans of expanding this worldwide, but seems logical to me they do.

Based on the presentation, Google will study how users use the new box (as they probably do with anything that appears on their SERPs)

Will Instagram (or other platforms) Stories appear in the Visual Stories box?

Based on Google’s announcement, Stories from other platforms will not appear on the Visual Stories box on Google’s SERPs. Also, I don’t know of any easy way to republish content from those platforms on your website as AMP Stories.

In my particular case, I have a travel blog in Spanish (Randomtrip.es) with Inês, my life partner, where we create lots of Stories on Instagram about the destinations we visit. We group those stories on Instagram by destination (so our followers can check them as a guide to each place) and for me this content has lots of potential but it’s really closed on Instagram. Recently Instagram developed the functionality to group and feature any of your stories on your profile, put them a name and link them externally, but you still need an Instagram account to visualized them

For example, in this link you can check our Stories about visiting «La Guajira», in Colombia. That content would be a good match to appear in these new «Visual Stories» box for people searching for «Things to do in La Guajira», but it will not as it’s closed inside the Instagram platform.

I would love that all that content we have created to be discoverable by users in search, but we would need to replicate all that content «by hand» on our website (or using some tool to make it easier). Hopefully tools to automatically create AMP Stories from Instagram Stories (or Snapchat, or Facebook…) should be created soon.

Is Google forcing us to use AMP, abusing their market position?

Well, in my opinion, kind of. There are also lots of misconceptions about how AMP works (you can read my previous posts about this subject here and here).

But essentially, when Google is forcing you to use a technology in order to appear on certain areas of their search results, they are prioritizing the tech over the functionality, and using this a way to promote the use of a certain technology (although AMP is an open-source project, Google is investing heavily on it and involved in it since the beginning)

AMP was born as a way to create really fast webpages for mobile easily, as speed is crucial on the mobile web and publishers were not fast enough. I appreciate that as a user, as I worked in a big media publisher and mobile speed was not the top priority nor something that was going to be fixed anytime soon; with AMP, we were forced to change that.

But, at the end, the benefits in terms of SEO of creating fast pages should be the same no matter what technology you use: speed should be measured in an objective way, and results that get below certain metrics should get the «lightning bolt» icon and/or whatever other mechanism of telling the user a result is fast Google may have. A fun example of this can be found in this article, where a publisher whose «normal website» is faster than their «AMP website» is forced to use AMP in order to appear on the Top Stories box.

Until now, having AMP does not offer you any «SEO benefits» on «normal» organic results (at least, that’s what Google says and there is no proof yet on the contrary). The only place where AMP was being rewarded, because it was almost mandatory, was on the Top Stories box, where not only most of the results are AMP pages, but also they get a more appealing visual aspect which makes it easier for users to notice them.

I also understand the the «Stories» format is becoming a huge thing on mobile, and that right now it is really closed (it can only be consumed inside the platforms, whether it is Instagram, Snapchat, Facebook…), while AMP Stories is the contrary: it is on the open web, crawlable, indexable, accesible by anyone with a browser without the need to register on any platform.

But forcing that on the SERPs is a different «story». With the new «Visual Stories» box, it is completely mandatory to create your content not only using AMP, but the specific format of AMP Stories. Besides, this new box is not created based on demand (like the Top Stories box which existed before AMP and that is used to present to the user relevant information that already existed and was demanded on the web, or like the «Videos» box); in this case, no Stories content exist on the open web and probably it is not demanded by users: Google is forcing us and asking us to create that content from scratch if we want to appear on the first position for the queries that will trigger this kind of result. The «Stories» that actually exist on the web (the ones from Instagram, Snapchat, Facebook…) will not appear there.

Conclusion and summary

• Google is launching a new box inside their search results that will ONLY show AMP Stories
• This box will appear for certain queries related to Travel, Gaming, Recipes, Movies, Tv Shows and Fashion
• Normal, organic results will appear lower on the search results because of that.
• Stories from other platforms will not appear in the box as Google cannot crawl them, nor they seem to have intention to include them
• AMP Stories can include and links to other URLs.
• Google is forcing webmasters to adopt their technology and format (AMP Stories) to appear in this new box.

This will be both a problem and an opportunity to many websites, but it will hugely depend on how results are selected and ranked. We will know soon!

La entrada Google is giving AMP Stories a VIP ticket on the SERPs. How is this going to impact SEO? aparece primero en Blog de Christian Oliveira.

1. What is a PWA and how it works
2. How search engines deal with Javascript (JS)
3. Rendering approaches for JS sites
4. Good practices for PWA and JS sites
5. Experiment: PWA without prerender (CSR)
6. Conclusion

Nowadays there are different solutions to solve mobile users’ needs. For example, at elmundo.es, if they want to offer a satisfactory experience to all the users that consume their news articles, they need to make sure that they serve each page currently in different ecosystems: mobile version and desktop version (with Dynamic Serving), APP (offline and more fluid navigation, and push notifications), AMP (as a requirement to appear on the Top Stories carrousel) and Facebook Instant Articles (Facebook’s AMP approach).

As you can see, those are a lot of ecosystems to be supported aside from the main website, and this is expensive and not very scalable for business.

If we talk about native APPs, these are the most common cons:

• They are normally more expensive than a normal website or web app. The price can vary from 25.000€ to 600.000€, being 150.000€ on average
• APP developers are scarce and highly demanded by startups, being offered very good salaries. In Barcelona, if you want to hire an APP developer, s/he probably is also on the recruitment process of Wallapop, Glovo, CornerJob or any other hot startup, and maybe you cannot compete with that.

• In a native APP, each step of the funnel costs you 20% of the users
• It’s another channel in which you will have to invest (aside from your normal website)

Another type of solution that exists nowadays, to solve more complex needs and heavier interactions on mobile, are the Mobile Web Apps (on a m. subdomain for example). These ones have some cons too:

• They do not allow offline navigation
• They are not indexable on APP stores.
• It’s more difficult to implement Responsive Web Design (RWD) with them
• It’s an extra technology you would need to develop and maintain for different browsers and devices.

Fortunately, nowadays there is a new development solution, initiated by Google, that has the best of both worlds, the Progressive Web Apps (PWA)

What is a PWA and how it works

A PWA is a web page that works for all users and all devices, but with the fluid experience of a native APP. This is a great advantage for websites with complex interactions. For example, if you navigate in your smartphone’s browser to Twitter and Instagram you will access their PWAs. There is no reason to use their native APPs, that consume lots of resources on the background, when you can just use their PWAs, install them on your home screen and be able to access Twitter and Instagram with most of their functionalities. Besides, it seems that Twitter is thinking about no longer maintaining their APP, as well as Starbucks. We suppose they will wait to get more users to add their PWA to their homescreen and to keep up the good numbers.

Some of the advantages of Progressive Web APPs are:

• They are APPs that can be indexed on search engines (bye bye APP indexing).
• They can also be indexed on APP stores
• They allow one-click purchases with the payment request api. This is one of the greatest advantages, taking into account that the abandon rate for card payments on mobile is 80%
• They allow push notifications
• They are progressive and responsive
• Easily shareable and likable (each content has its own URLs, same as on any website)
• Users do not need to install them on their smartphones
• We will see them on desktop soon (you can already “install” them on Chrome Os since almost one year ago)
• You can use them offline
• They enable faster transitions

We are not saying that PWAs are better than native APPs, but their advantages will probably influence developers into not choosing to develop a native APP.

PWA can have a First Contentful Pain faster than a normal website and faster and more fluid next interactions, like a native APP. It’s an important feature as load speed is the UX element that 75% of users care more about, according to this Google study. It seems that slow websites can be more stressful than watching an horror movie (according to this study from Ericsson ConsumerLab) and this means that you can lose up to 53% of your users if your mobile website takes more than 3 seconds to load, according to this other study from Google and SOASTA

Progressive Web Apps are developed using Javascript frameworks and libraries, which are becoming a standard as they make it easier for developers. This approach have the following advantages:

• It’s easier for developers to jump in PWA. They are modular, clean and facilitate core code reusability. Also, there is a big and collaborative community behind.
• Better performance and speed (for servers especially when using Client Side Rendering as we will see later).
• Cheaper, as they are open source and it’s easier to find developers. The are new and better frameworks appearing all the time (Vue JS for example is much easier to learn than React JS, one of the reasons why it’s overcoming it)
• They are a safer bet because of the big community and the big players involved (Google is behind Angular and Facebook is behind React JS)

For all these reasons, PWA are here to stay, so both SEOs and search engines need to deal with it, as their growth is unstoppable.

According to the Stack Overflow’s “2017 Developer Survey” (which 64000 developers answered), JavaScript is the most popular programming language and Node JS, Angular and React JS are in the top 5 most popular development technologies.

How Progressive Web Apps work

A PWA is a SPA/MPA (Single Page Application or Mutiple Page Application) which has two extra functionalities that makes it work: the service worker and the manifest

The service worker is the magic of PWA: it allows background synchronization, offline navigation and push notifications.

It works as a controller and in the middle of the client (the browser) and the server. It tells the browser cache to store files that have been already downloaded so, later on, the user is able to access the pages without downloading them again (that’s why it’s possible to navigate offline)

The manifest is a small JSON file included on the head of the HTML document. Among other things, the main functionality of this file is to allow a PWA to be installed in the home screen of the user’s smartphone so it can be used as an APP

With Microsoft’s PWA Builder you can easily create both a manifest and a service worker for your website. If you want to learn more about how to create a PWA, Google has a very useful tutorial

Nowadays all major browsers support PWA, but not all browsers support all the functionalities of PWA. Fortunately, this is changing fast as you can check on the “Can I use” website

How search engines deal with Javascript nowadays

Nowadays only Google and ASK render Javascript in a “decent” way. Baidu announced that they also do it, but after doing some tests, it seems that they don’t do it as well as Google or ASK. So, if your business is in USA, Russia or China, you cannot depend on Bing, Yahoo, Yandex or Baidu to render your JS website and you will have to make sure your content and links are working without JS.

Crawling != Rendering != Indexing != Ranking

When we talk about the abilities of a Search Engine to render JS, this kind of tests you see here are usually made. For example, doing a “site:” for a site that depends on JS to be visualised and crawled:

As you can see, the number of indexed pages varies in each of these search engines, but besides that, the fact that a search engine has a given number of URLs indexed doesn’t mean that they discovered them after rendering the page, nor that it is able to see 100% of what is in them (there may be external links pointing to different URLs of that site and the search engine just discover those URLs there, without being able to see what’s in them)

So if for example you try to search for some of the exact text strings of a JS site in different search engines, you will see that in some cases Google is the only one able to see and index that content.

Rendering a JS site costs a lot

So, if PWA are a trendy thing right now, and lots of websites are using JS, why not all search engines are already rendering JS? It’s simple: because it costs a lot (both resources and money)

According to a study made with the top 500 sites on archive.org, 50% of the websites take an average of 14s in allowing the user to interact on mobile, which is too much time.

Here it’s important to understand that a JS file of 170KB is not the same as an image of 170KB: although the browser will spend more or less the same time downloading both files, the image will be rendered and visible to the user very fast (in milliseconds), while the JS has to be parsed, compiled and executed by the browser, consuming more resources and time.

To get an idea of how much does it cost to render JS for a crawler, we have the numbers ahrefs shared. Each 24h:

• They crawl 6 billion pages
• They render 30 million pages
• For that, they use 400 servers.

If you do some maths, for each page they render, they crawl 200 pages. According to themselves, if they decide to crawl and render all the URLs they have on their index with this same pace, they estimate they would need between 10.000 and 15.000 extra servers (between 20 and 30 times more servers), so you can imagine the amount of money that would be (machines, electricity, maintenance…)

Google won’t wait indefinitely to render a page

Because of the high cost of rendering JS, we have another factor here: Google can’t wait indefinitely to render a page.

Although they already said on Twitter that there is not a pre-defined maximum time, according to several tests we have seen or done, the reference number to be on the safe side is 5 seconds.

This was discovered by chance by Natzir because a client wanted to hide a popup and a language selector modal so Google didn’t consider them intrusive. What he did was loading them after the “document ready” event so they didn’t appear on the DOM, and try with different amounts of seconds to see if Google was seeing them or not. Finally, he observed that with more than 5 seconds, the popup and the modal didn’t appear o the render nor on Google’s cache. But if you want to be sure, it’s better to make those elements load after the user interacts, so Google won’t execute it.

Warning! This a reference number, not a rule! It can vary between websites and also through time (Lino has checked that it can be more than 5 seconds). If you want to make sure Google is able to render and see all your content, besides checking it on the index, the best way is to check how your pages are rendering on the Mobile-Friendly Test Tool, and try to make your website to render as fast as possible.

Google renders JS in 2 phases

In the last Google I/O, Google confirmed what we have been noticing for some time: that JS sites are indexed in 2 phases

If you a geek like us, you will find curious to know that before Percolator (Natzir talked about it here), Google used MapReduce and Google File System (thanks to those, Hadoop was born). Simplifying a lot, before this new architecture, Google worked in batch, and now it works on the fly. This makes crawled pages to be indexed instantly.

The problem is with JS sites, as Google needs to render them to see the content and the links; if not, Google would be missing a big part of the web. As we have seen before, rendering costs a lot and cannot be done instantly as that would make Google spend way more resources easily. They need to index JS sites in two phases.

So they included a WRS subsystem in Caffeine, based on Chrome 41, which has serious implications that both SEOs and developers must take into account.

Update May 2019: Googlebot will use the latest version of Chromium from now on (74 at the time of this post), allowing it to use +1000 new features. This does not change anything regarding the 2 waves of indexing and the official SEO recommendations if you have a PWA or a site that depends on JS to display content.

One of the things that affect us and that we need to understand is that canonical and rel=amphtml tags, and HTTP status are read and processed only on the first wave (on the initial fetch of the page) and there is no second chance. We didn’t have any idea about the rel=amphtml until John Mueller said it, but it makes sense.

Regarding the canonical tag, it’s a difficult topic. Even if Google said that they only read the tag on the first fetch, and not after rendering the page, there has been cases where they actually did it. The amazing Eoghan Henn setted up a test where he demonstrated that Google was actually reading the canonical tags on the rendered version and applying them

Even if it works sometimes, that doesn’t mean is a good approach to have canonical tags only in the JS rendered version of the page, as serving it on the initial fetch is the only way to guarantee that Google will see the tag.

On the other side, Google said that if noindex, hreflang and rel=next/prev tags are not on the raw HTML, but on the JS rendered version of the page, it’s ok (as they will read the tags after rendering the page).

Same as with the canonical tag, even if Google is able to read and process these tags on the rendered version of the page, we would not recommend to depend on it and the best option is to serve those tags directly on the raw html, to make sure Google is able to read them on the first place. Given that Google delays JS rendering, if that delay is long (some days, for example), we would have pages with noindex, that should not be on the index, but that will be for those days until Google finally renders the page and see that tag.

So, as a good practice, it’s better to always give Google and other bots the meta tags directly on the raw HTML

Other consequence of Google using Chrome 41, is that it cannot render completely websites that use more advanced functionalities not supported by that version of Chrome. If we want to use any of those modern functionalities, we need to make sure that they work on Chrome 41, or find alternatives that do.

Types of events and links that Google follows

Knowing what types of JS events and links Google follows is important as the indexed URLs are the ones taken into account to evaluate the quality of a website.

We know that Google crawls, index and pass PageRank to HTML links (<a href=…) as they confirmed again on the Google I/O:

• <a href=»/this-link»> will be crawled </a>
• <a href=»/this-link» onclick=»cambioPagina(‘este-link’)»> will be crawled </a>
• <a onclick=»changePage(‘this-link’)»> *won’t be crawled </a>
• <span onclick=»changePage(‘this-link’)»> *won’t be crawled </span>

*Not being crawled doesn’t mean that if someone links to that URL it won’t get indexed by Google. Most of the errors of indexed filters come from problems like this.

We also know that Google crawls and index anything that seems like a URL, because they want to discover new URLs, but they won’t pass PageRank (doesn’t mean they won’t appear if you search):

• <a onclick=»changePage(‘/this-link’)»> will be crawled </a>
• <span onclick=»changePage(‘/this-link’)»> will be crawled </span>
• /this-link will be crawled

I believe it was 7 years ago, when in the Webmaster Tools (now Search Console) of a client, a lot of 404s started appearing, at the same time a Google Analytics virtual page implementation was made. Since then, I include anything that appears on the html and looks like a URL on the robots.txt, although the best approach is to modify the code so they don’t look like URLs.

There are also other type of events: onscroll and onmouseover. Onscroll events are executed sometimes, while onmouseover events are not executed

If you have a pagination implemented with onscroll, the first pages can get indexed. One of those things that you discover by chance and that later on Google confirms

Rendering approaches for JS sites

In order to understand the different rendering options for JS sites, the easiest way is to imagine PWA as the IKEA of internet:

• Traditionally, when we (clients) want to buy furniture, we go to a specialised shop (a company), buy the furniture and the company delivers to us the final product, ready to use.
• Later on IKEA appeared, where the client choose the furniture, but instead of receiving the final product, s/he receives different parts and some instructions on how to assemble it, so the client is the one that needs to perform the physical task of assembling the furniture in order to get the final product s/he bought. Besides, sometimes, in order to assemble the product, the client needs to buy extra things from the company (special screws, special tools, etc.). Everything comes on the instructions.
• After some time, IKEA noticed that some clients wanted their products, but didn’t want to assembly the products themselves: they wanted the final product directly. So IKEA launched a new service: you can buy furniture and get someone from IKEA to mount it for you, so you receive the final product.

With this analogy, the client would be our web browser, and IKEA would be the server. Based on that, we have 4 different scenarios when choosing a rendering system:

Client Side Rendering (CSR)

When we talk about pure Client Side Rendering, the client (the web browser), receives an almost blank html on the initial fetch, and the browser is the one that needs to work to “create” the final html based on the resources and JS (instructions) that receives from the server:

This is the option that PWA developers initially used (and in a lot of cases, they continue using), and it is the worst one in terms of SEO, as without executing the JS and rendering the page, there is nothing (no content, no links)

Server Side Rendering (SSR)

Due to the SEO problems with CSR, and the same way IKEA did, JS frameworks started developing new functionalities that solved the problem: without losing the PWA advantages, the server will execute and render the page itself and send the final html to the client:

This way, the client (the web browser) receives a final HTML with content and links, without needing to execute and render JavaScript. If JavaScript is enabled, it will then take control of the page and the user can navigate/interact on “PWA mode”. If not, s/he can navigate/interact as in a “normal” webpage, without the PWA advantages

Hybrid Rendering

The third rendering option is a combination of the two previous ones: part of the page is sent pre-rendered from the server, and the rest needs to be rendered on the client.

A really common case of Hybrid Rendering is pre-rendering those parts of the site that all pages on the PWA use (for example, a menu), and leave the specific parts (the main content) to be rendered by the client. In the next example, the “App Shell” (the top area, with blue background) would be sent by the server pre-rendered (SSR), while the area below (the main content) would not appear on the first fetch and would need to be rendered entirely by the client (CSR)

Dynamic Rendering (DR)

This is the option Google recommended officially on Google I/O, and it basically consists on… ¡cloaking!

Yes, you are reading it correctly. What they said is that if we have a PWA that depends on JS and rendering, and want to avoid problems with Googlebot (and other bots), we need to make sure that Googlebot (and other bots) receives a rendered version (SSR) and the rest of user-agents can receive whatever we consider better (CSR, or Hybrid Rendering). This way, Googlebot will be able to see all the content and links without having to render the page. Basically, the content that Google will see it’s the same one the users will see once the page is rendered on their browsers.

A clear example of a big website that is applying this method, and that belongs to Google itself, is Youtube. In the following screenshots (you can try it yourself with this tool) you can see that when visiting a video URL, if the User Agent is Googlebot, the server sends directly the final page with the content and links. If the user agent is a “normal user”, the server sends an empty html, with just the structure and with no content nor links:

SSR better for users, CSR better for servers

What strategy is the best for each case? For users, at least for the first interaction, the best option is SSR:

• Netflix, which is a PWA built with React, and that has invested a lot on working with this technology, saw a 50% performance improvement on their landing pages (those they use to acquire users) by moving from CSR to SSR
• Walmart got to the same conclusion, where now most of their pages work with SSR

Why? It’s simple. Let’s recap how both techniques work:

• With SSR, the server sends the “final” HTML, with all the content and links “ready to see”, without need of rendering on the client (the web browser)
• With CSR, the server sends an empty html, which needs then to be “completed” by the client (the web browser) executing the JS and rendering the page.

This implies that:

• With CSR, the server answers faster (so we can have a better TTFB), while with SSR the server has to use more resources to render and it takes more time to answer
• With SSR, the client (the web browser) receives a “final” HTML, that can be painted faster so the user can see the content faster. With CSR, on the other side, depending on the device of the client, it will take more or less time to render and paint the page.

As you can see on this image with the tests made by Walmart, with SSR the client starts seeing the content sooner, even if the server takes a bit more of time to answer:

So, if CSR is worse for SEO (because we depend on the search engines’ capacity of rendering the page), and SSR is faster for users, why would anyone use CSR? Because of the same reason IKEA sells furniture by pieces: it’s cheaper.

The biggest advantage of CSR is that it’s cheaper for the IT department: as all the rendering and execution of JS happens on the client, the server is less loaded. If we move to SSR, all that work will happen on the server, which can be very expensive as we have already seen.

Google’s official recommendation

As we said before, Google recommends Dynamic Rendering (that is, SSR at least for Googlebot), but they also announced that in some cases they feel capable of fully see and index small pure CSR sites.

They specifically talked about three factors:

• The size of the site (the number of URLs)
• How dynamic the site is (if it publish a lot or few times, if the content of the URLs is static or it changes a lot)
• Compatibility with Chrome 41

Based on that, these would be Google’s recommendations for each case:

Update May 2019: Googlebot will use the latest version of Chromium from now on (74 at the time of this post), allowing it to use +1000 new features. This does not change anything regarding the 2 waves of indexing and the official SEO recommendations if you have a PWA or a site that depends on JS to display content.

As you can see, the best option is to always use SSR (or Dynamic Rendering) except in smaller, static sites. Even in that case, a certain risk exist also for these sites, so if your project depends on SEO traffic, the best way is to use SSR/DR in all the scenarios.

Here you can clearly see what kind of problems CSR generate, in this tweet by Barry Adams

You can see a graph with the evolution of valid indexed pages in a PWA that was implemented with pure CSR and that eventually changed to SSR. After doing that, the number of indexed pages increased a lot (almost double), reflecting the bottleneck that Google has rendering JS, and the reason they don’t recommend depending on it for big sites.

Good practices for PWA and JS sites

Here we recommend some tools to check if Google has problems rendering our JS site.

PWA and performance audit

You can do this audit using  Lighthouse for Chrome and Sonar Whal.

With the Chrome plugin Service Worker Detector, you can easily check the service worker and the manifest on any PWA.

Mobile-Friendly Test

Nowadays, the Mobile-Friendly Test tool from Google is the best way to see how Google renders a page, as it is, in theory, the closest one to what Googlebot actually does. It’s better than the “Fetch and Render” tool on Search Console, as in SC there are more timeouts and the result is not 100% real. The Mobile-Friendly Test is not 100% real also, but it is closer to reality. The problem with the tool is that we cannot scroll down on the page.

Another great feature of the tool is that we can see the final HTML after rendering. and check if there is anything missing, or compare both HTML with tools like Diff Checker. We can also check JS errors blocked assets.

Fetch and Render

This tool from Google Search Console is also really useful, as we can compare how a user and Googlebot willl see our page, and if there is any difference.

We can also use this for any page of any domain, even if it is not ours. For example, you can see how Natzir is able to use the tool for a page from Trivago, thanks to the code shared by Screaming Frog (don’t forget to modify it as explained on the slides)

What this code does is to load any page on your domain through an iframe.

You can also use this functionality for staging sites. To do this, you need to add a noindex to all the URLs and only let Googlebot access them using Reverse DNS.

There are other tools you can use, like ScreamingFrog SEO Spider or this online tool developed by Merkle SEO. Thanks to these tools you can modify the amount of time to wait for the rendering and the User Agents. You should aim for getting the page rendered in less than 5 seconds.

Crawl and compare staging with production enviroments

If you are migrating your current site to a PWA using technologies like Angular or React, you can use crawlers like FandangoSEO to crawl your site on staging and also in production, and compare them. Most of the problems on migrations to a PWA happen because of layout changes and not just because of using JavaScript.

As in any migration, you need to check internal linking is the same in staging and production, maintaining the same levels of depth, as well as keeping the same content in both versions. This is a priority on any migration, even more than having redirects with 2 or more hops. It’s also a bad practice to migrate layout, CMS and URLs all at the same time; even if we maintain the links and the redirects are perfect, those are lots of changes at the same time and the site can suffer for 6 to 12 months until Google is able to reprocess and understand everything.

So if you migrate your site to a PWA, test it thoroughly on staging before going live, and minimize the amount of changes

Crawl emulating mobile and rendering JS

With the change to “mobile first indexing” from Google, we also need to check how Google sees our sites as a mobile user and revise the points commented before. With FandangoSEO we can also do this and compare the crawls to see if mobile and desktop are equal or not in terms of internal linking, title tags, etc.

Check meta tags with other User Agents

Although you can do this with crawlers, when you just want to check some specific pages you can use these plugins: meta seo inspector and user-agent switcher. In the last one, you can add User Agents for Googlebot, Googlebot Mobile and the ones from Facebook and Twitter (to check open graph and twitter cards data)

• Googlebot: User-Agent String: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
• Googlebot Mobile: Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.96 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
• Facebook: facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)
• Twitterbot: Twitterbot/1.0

You can also use the new Rich Results Test from Google to validate schema.org, which will also show you the rendered HTML. The backside is that it doesn’t allow as much types as the previous one

Browse without JS emulating other User Agents

When you want to check the same as in the previous point but also without executing Javascript, you can use the Web Developer plugin, where you can deactivate JS.

Check console errors and links on Chrome 41

It is a must to use Chrome 41 yourself and check if your PWA works there. You can check Javascript errors, API errors or CSS errors that you will see on the browser’s console. You will see that some of those errors do not appear on the latest versions of Chrome, so if they happen on Chrome 41, they will happen also on Google when trying to render your page.

Another thing to check on Chrome 41 is if the links and menus are accessible, as sometimes, because of unsupported features, they might not work. You can check here which features are supported and which ones are not

There are rumours saying that Google will update its WRS with a more modern version of Chrome in less than a year, but there is no confirmed date. So up to date, Chrome 41 is our reference.

To end with the good practices, here you have some checklist with things to take into account if you use pure CSR or SSR/DR

PWA SEO Checklist for CSR

1. Canonicals + metadata do not depend on CSR
2. Page renders in less than 5 seconds
3. Page loads and is functional with Chrome 41
4. Rendered links are <a> elements with their real href
5. HTML+design is the expected on Mobile Friendly Tool
6. HTML+design is the expected on Fetch and Render with Search Console
7. Pages appear on Google after searching for specific text strings
8. Content is not replicated in different pages
9. Fragments (!#) are not used and every page has its own URL

PWA SEO Checklist for Dynamic Rendering/SSR

1. SSR is served to Googlebot and other specific bots (FB, TW…)
2. Content Googlebot receives is the same a normal user sees
3. Http response codes are the same in both cases
4. Meta tags are the same in both cases
5. Server is able to manage the rendering under high pressure
6. SSR version includes all the content and links in a correct way
7. All pages have the expected behaviour in both cases
8. Fragments (!#)are not used and every page has its own URL

Apart from that, this checklist from google for PWAs regarding PWA and WPO is also really useful:

PWA Checklist UX & WPO

1. Site is served over HTTPS
2. Pages are responsive on tablets & mobile devices
3. All app URLs load while offline
4. Metadata provided for Add to Home screen
5. First load very fast even on 3G
6. Page transitions don’t feel like they block on the network
7. Site uses cache-first networking
8. Site appropriately informs the user when they’re offline
9. Content doesn’t jump as the page loads
10. Pressing back from a detail page retains scroll position on the previous list page
11. When tapped, inputs aren’t obscured by the on screen keyboard
12. Content is easily shareable from standalone or full screen mode
13. Any app install prompts are not used excessively

Experiment: PWA without prerender (CSR)

In order to try ourselves how Google deals with Javascript, we have sacrificed our blogs migrating them from a “normal” WordPress to a PWA that works only when having JS (CSR)

We did this using Worona (now Frontity), which is a platform that allows you to convert a WordPress site into a PWA for mobile users. In our case, we collaborated with them in order to make the PWA available in both mobile and desktop, and that when JS is not enabled, a blank page appears.

As you can see, if we deactivate JS, all the pages in this blog load only what you see in this screenshot: a blank page without the real content and links to crawl and index:

Once the PWA was enabled on production, we have done different tests.

Disclaimer: as you will see, these tests have been made on a small site, in a small period time and on small scale. We cannot guarantee that the results will be the same in other situations.

Test 1: rendering

The first test was to check if Google was, in fact, able to render and index the URLs from the blog, now that they only work with JavaScript.

In order to do that, we checked first on the Mobile-Friendly Test Tool and on the Fetch and Render Tool on Search Console, where we confirmed that Google was able to render the content.

We used the “Request indexing” option on Search Console to force Google to update the URL on their index, and in less than 15 minutes we were able to check what they did:

Observations:

• Google has been able to render and index the content
• The process has been relatively fast (15’)

Test 2: rankings

Once we validate that Google is able to render the blog and see our content, the next obvious question is if we are going to keep the rankings for that post. In order to check that, we choose a keyword for which the post has been ranking 1 or 2 for 6 months (so it’s a “stable” keyword)

And we check that, once their index has been updated for that URL, we keep the same ranking:

Besides, we also do a search combining the keyword with a piece of text that appears only on the PWA after rendering, to make sure Google is indeed ranking the page taking into account the content that loads after rendering it:

Observations:

• Rankings haven’t been lost after migrating to a PWA without SSR

Test 3: new content indexing

We also wanted to test how much time Google takes on finding, crawling and indexing a new post, so we publish a new one:

As we don’t want to force Google to crawl the new URL, what we do is a Fetch and Render of the blog homepage, and click on “Request Indexing”, where Google will find a link to this new post, to see if they index it and how much time it takes.

Even though we saw a visit from Googlebot to the new URL on the server logs, the page didn’t appeared on Google’s index until 5 days after publishing:

A small mistake when doing this test was that the post didn’t have a lot of content, and the plugin we used (Worona), loads the next post when you scroll to the end of the current post, so when Google was rendering it, was seeing also the content of the next post below:

So we will repeat this test.

Observations:

• If we don’t force the indexing, Google takes some time to index new content

Test 4: the two waves of indexing

Last, we wanted to try to see “live” the 2 waves indexing system that Google has confirmed. Same as in the previous case, because we did the test with a URL with not a lot of content, Google ended up loading the next post and indexing that content for this URL

This is what we did:

• In a page Google didn’t recrawl yet, we did a change to include a made up word only on the initial html version of the page, that disappears after loading the PWA
• We forced Google to Fetch (not Render) that page on Search Console, and we “Request Indexing”
• Minutes later, when we searched for the word Google was already showing the URL:

• On the other side, when we checked Google’s cache for this page, we found that even though Google indexed the new content, the cache was still showing the old version (the one without PWA that we had before):

• Also, when searching for specific text strings that appeared only on the old version of the page (before PWA), the page was still appearing:

• Days later, Google started showing the PWA version on the cache:

• And from that moment, the page no longer appears for the made up word that is only visible on the initial HTML before rendering:

• Although when checking the «Text-only» version Google’s cache, the word appears:

Observations:

• Before rendering the page Google has indexed the content on the page without JS (first wave)
• This new content has been associated to the previous version of the web (the one without PWA)
• Once rendered, the page only ranks for the content present on the rendered version (second wave indexing)

Conclusions

• Up to date very few websites have migrated directly to a CSR PWA (no pre-rendering) for all user-agents. Those who did and lost traffic, had also other technical problems (e.g. hulu.com)
• New websites which are created directly as CSR PWA can rank, but they have problems with indexing
• Up to date, and regarding Google, Dynamic Rendering is the solution that works without any problems

La entrada SEO for Progressive Web APPs (PWA) and JavaScript sites aparece primero en Blog de Christian Oliveira.

La entrada matujiloperubasedotino: prueba de indexación con PWA sin pre-render aparece primero en Blog de Christian Oliveira.

AMP es uno de los proyectos de Google más polémicos en las comunidades de SEO y de desarrollo. Todas las semanas aparece nueva información, con datos a favor o en contra del proyecto, que en la mayoría de los casos muestran una imagen incorrecta de AMP.

Decidir si implementar AMP o no puede tener un impacto muy grande para algunos negocios, por lo que es crucial saber si los pros y contras que se manejan son completamente ciertos.

La mayoría de los datos que se comparten están mal, no tienen valor o son medias verdades, así que en este post vas a encontrarte con una recopilación de las 5 suposiciones más comunes sobre AMP, y qué esconden.

¡Nota importante! Esto no es un artículo en contra ni a favor de AMP. Es simplemente un análisis de algunas suposiciones sobre AMP, tanto favorables como desfavorables.

ejemplo.com está recibiendo un XX% de tráfico móvil desde Google en AMP

Fuente: http://digiday.com/media/guardian-getting-60-percent-google-mobile-traffic-amp/

Esta noticia específica habla sobre The Guardian, pero puedes encontrar métricas similares para otras webs.

The Guadian fue una de las primeras webs de noticias en implementar AMP, trabajando mano a mano con Google, meses antes de que el proyecto fuese lanzado públicamente. Hicieron un «all-in» con AMP, creando versiones de AMP para todos sus artículos (de forma retroactiva)

¿Qué quiere decir esto? Que un gran porcentaje de sus URLs, tienen versión AMP.

¿Por qué no todas? Bueno, porque AMP fue diseñado en primer lugar para noticias, no para cualquier tipo de página y/o contenido. Algunos ejemplos de páginas de The Guardian que no tienen versión AMP:

• Su homapage: http://www.theguardian.com/
• Sus categorías / tags: http://www.theguardian.com/football,  http://www.theguardian.com/books/stieg-larsson
• Contenidos más complejos y/o interactivos: http://www.theguardian.com/world/ng-interactive/2017/may/07/french-presidential-election-results-latest

Cuando implementas AMP en tu web, Google (en su versión mobile) reemplazará aquellas URLs «normales» por su versión AMP en sus resultados de búsqueda, enviando tráfico directamente a tus páginas AMP en vez de a tus páginas «normales».

Así que, decir que «The Guardian is getting 60 percent of its Google mobile traffic from AMP», sólo quiere decir que The Guardian ha implementado AMP correctamente y que los resultados son los esperados, si sabes el % de tráfico SEO que tenían esas páginas antes de AMP.

Si implementas AMP en el 100% de tus páginas, esas páginas eventualmente recibirán el 100% del tráfico desde Google Mobile, sin decir nada sobre la calidad o beneficios de usar AMP. Es, simplemente, parte de la implementación. Podrías estar incluso recibiendo menos tráfico SEO mobile que antes, pero llegando el 100% de él a páginas AMP de cualquier forma.

Este dato no dice si The Guardian está recibiendo más o menos tráfico SEO desde Google Mobile, ya que el tráfico ha dejado de llegara a páginas «normales» para llegar a páginas AMP. E, incluso si el tráfico SEO desde Google mobile ha crecido después de implementar AMP, podría ser por un montón de factores, y será difícil determinar cuál es la razón exacta (especialmente en webs como The Guardian, cuyo tráfico varia enormemente en función de la actualidad)

El artículo continúa diciendo: «AMP has gradually been taking over the Guardian’s mobile traffic; today, 60 percent of its Google mobile traffic is AMP, well above the 10 to 15 percent that publishers have been getting from AMP«. Que, otra vez, no quiere decir nada, ya que el % de tráfico que acaba en páginas AMP desde Google Mobile depende de tu implementación de AMP y no tanto de lo bien que lo estés haciendo en SEO.

El porcentaje de rebote en las páginas AMP es muy alto

Fuentes: http://productforums.google.com/forum/#!topic/webmasters/AHU52vd02Mg, http://www.blackhatworld.com/seo/amp-pages-high-bounce-rate.897599/

Si buscas en blogs y foros, encontrarás multitud de comentarios sobre esto, dando multitud de razones que explican por qué el porcentaje de rebote de tus páginas AMP es tan alto. Esas razones, pueden de hecho ser parte de la causa, pero la causa principal es simplemente que lo más probable es que ese porcentaje de rebote esté siendo mal calculado.

Como expliqué aquí, la forma en que AMP funciona provoca una inflación de sesiones y usuarios en nuestras herramientas de analítica, que en consecuencia provoca que el porcentaje de rebote se calcule de forma errónea.

Esto es un problema de sobra conocido por Google, difícil de resolver, y aunque están trabajando en ello y ya han hecho mejoras, el problema persiste para el caso de uso principal (gente que llega a tus páginas AMP a través de Google Mobile)

Así que, si quieres analizar el comportamiento de la gente en tus páginas AMP, no cuentes con el porcentaje de rebote salvo que hayas implementado alguna solución a este problema.

Las páginas AMP posiciona mejor en los resultados móviles de Google

Aquí, tenemos que considerar dos escenarios diferentes:

• La cajita de «Noticias destacadas», que aparece para algunas búsquedas.
• Los resultados orgánicos

Caja de «Noticias destacadas» (AMP article rich results)

Esta caja de resultados no es nueva, ni ha sido creada por AMP. Desde que Google lanzó «Universal», intenta mostrar diferentes tipos de resultados en función de la búsqueda.

Así, si buscas «Despacito», el primer resultado es un vídeo gigante de youtube con la canción:

Y, si Google considera que la búsqueda está de alguna forma relacionada con «noticias», mostrará la caja con resultados de noticias:

Que, en mobile, ahora saca resultados AMP:

Aunque, a veces, también aparece algún resultado no-AMP:

Esta caja era inicialmente exclusiva para los medios que estaban en una white-list (a la que podías optar si cumplías los requisitos), y más tarde empezó a incluir también de forma esporádica, resultados de webs que no estaban en esa lista (incluso tweets y vídeos de youtube).

Con el lanzamiento de AMP, Google «forzó» a los medios a adoptar su plataforma si querían seguir apareciendo en esa caja en Mobile. A pesar de que a veces se cuela algún resultado no-AMP, no es la norma.

Así que, cuando alguien comenta que AMP es un factor de posicionamiento justificándolo con esta caja: no lo es. Al menos, no uno nuevo, o no uno generado a raiz de AMP. La caja de noticias existe desde antes de AMP, e incluso aunque implementes AMP en tus páginas, probablemente no aparecerás ahí, ya que la mayoría de resultados son de medios grandes.

La razón que Google utiliza para justificar el favoritismo hacia AMP dentro de esta caja es «AMP is the format that currently delivers the best possible user experience on the mobile web. That is because AMP allows for consistent speed, caching, pre-rendering, and enables swiping between full-length pages. This is a big deal for topics where there isn’t “that one best result” that a user might want to look at.» (fuente: Malte Ubl, creador y responsable de tecnología en el proyecto AMP, en Hacker News).

Puedes leer mi opinión sobre esto al final del post.

Resultados orgánicos (AMP non-rich results)

Para los resultados orgánicos «normales», Google dice que AMP todavía no es un factor de posicionamiento. Puedes creerlo o no, pero de momento no hay datos (al menos, no los he encontrado) que demuestren lo contrario.

Así que ahora mismo, si implementas AMP en tus páginas, y alguna de ellas posiciona en 2º lugar para una búsqueda, con su URL «normal», tan pronto como Google detecto que esa URL tiene una versión AMP, será la versión AMP la que aparezca en su lugar, en la misma 2ª posición.

Pero, ¿y qué pasa con estos datos? Aquí se puede ver claramente que los rankings y CTR de las páginas AMP es mucho mejor:

Parece mejor, pero los datos están comparando cosas diferentes.

La única forma de intentar (no puedes estar 100% seguro, ya que no puedes hacer test A/B sobre un mismo resultado) conseguir datos reales sobre CTR y rankings para comparar resultados AMP vs no-AMP sería:

• Tener varias URLs posicionando para algunas keywords de forma muy estable durante un largo periodo de tiempo (en términos de posición, tráfico y CTR)
• Crear versión AMP para algunas de esas URLs, dejando otras sin versión AMP como grupo de control.
• Monitorizar si Google indexa correctamente las versiones AMP (con el mismo título y descripción)
• Monitorizar los rankings en mobile para las keywords y páginas elegidas
• Monitorizar el CTR y posición media en Search console, tanto para las páginas del grupo de control como para las que han cambiado a AMP.

De esa forma, se puede ver si una keyword para la cual has tenido posicionando la misma URL en la misma posición durante un largo periodo de tiempo, con un CTR estable, mejora o empeora una vez empieza a aparecer su versión AMP. Por supuesto, incluso si cambia, puede haber otros factores influenciando estos valores, por lo que nunca puedes tener 100% de seguridad.

Si comparamos, simplemente, los datos de las páginas AMP con las páginas no-AMP en Search Console, probablemente lo estaremos haciendo mal.

Estos son los datos, de Search Console, para mi blog de viajes Randomtrip.es, tanto para páginas AMP como no-AMP desde móvil.

Páginas AMP:

Páginas no-AMP:

Entonces, con estos datos, las páginas AMP ganan, ¿no? Mejor CTR (8.82% vs 5.01%) y mejor posición media (7 vs 7.7).

Bueno, no exactamente. Estos no son datos sobre las mismas páginas con diferente output; son datos de páginas complemente diferentes (las URLs que tienen versión AMP, no aparecen con su versión no-AMP en mobile), así que la comparación no tiene sentido. Lo que estamos comparando aquí es el rendimiento de dos grupos de páginas diferentes (homepage y categorías por un lado, posts por otro), que pueden tener, de por sí, diferente rendimiento SEO en las SERPs, por multitud de motivos.

El CTR es mejor para los resultados de AMP

Fuentes: http://searchenginewatch.com/2016/10/13/accelerated-mobile-pages-amp-one-year-on-stats-and-infographic/ y http://speakerdeck.com/natalialkb/amp-in-the-wild?slide=37

Esto puede ser verdad, bajo la suposición de que la gente ha aprendido que el símbolo del rayo con las letras AMP indican que esa página carga muy rápido, y por lo tanto tienda a clickar más ahí, pero es poco probable (pregunta a cualquier persona que no esté en el mundillo qué cree que significa la etiqueta)

Y, no está demostrado con datos. Puede ser verdad, pero también puede no serlo, así que si quieres utilizar esto como un argumento a favor de AMP, necesitarás probarlo u obtener datos reales de alguien que lo haya hecho.

Hay datos acompañando a ambos tipos de suposiciones: que el CTR aumenta y que el CTR disminuye, pero por la explicación dada en el punto anterior, ninguna de las dos suposiciones está correctamente demostrada.

Google robará mi tráfico SEO

Fuente: http://www.alexkras.com/google-may-be-stealing-your-mobile-traffic/ (el autor, Alex Kras, rectificó sobre el titular al principio del artículo, diciendo que es «poco preciso»)

Este artículo fue uno de los primeros polémicos que caló hondo en comunidades como Hacker News, en contra de AMP, y es una lectura bastante interesante porque refleja lo poco que se conoce / se entiende de AMP en las comunidades de desarrollo, e incluso en comunidades SEO.

Entonces, ¿robará mi tráfico SEO Google, si implemento AMP? No exactamente.

AMP es un proyecto complejo, puedes aprender más sobre su funcionamiento aquí. Básicamente, hace que tus páginas carguen más rápido gracias a dos factores principales:

1. Hay un montón de restricciones respecto a CSS, JS y anuncios, así que te fuerzan a crear páginas sin toda esa «morralla» que hace que tus páginas «normales» cargue más lentas, y que no estás dispuesto a sacar. Así que tus páginas AMP cargarán (o al menos deberían cargar) más rápido que tus páginas mobile
2. En lugar de enviar el tráfico a tus páginas AMP, Google las cachea en sus servidores y las sirve él mismo. De esta forma se aseguran de que determinadas optimizaciones del lado del servidor estén implementadas.

El punto 2 es el controvertido aquí: ya no eres tú el que sirve esas páginas, Google lo hace, y por eso parece que Google te está robando el tráfico.

En realidad, el tráfico contará igualmente en tus herramientas de analítica, y tú mantienes el control de los contenidos, menús, anuncios, links, etc. que se muestran ahí (con algunos problemas en cuanto a analítica que mostré en este post)

PERO, los usuario no abandonan Google complemente cuando pinchan en un resultado AMP; pueden hacer swipe horizontal de una noticia a otra en la cajita de «Noticias destacadas», y la URL que se les muestra en el navegador no es la tuya, si no que es una URL de Google.

Así que, el tráfico cuenta como tuyo, pero es Google el que lo está recibiendo, y es Google el que controla el entorno en el que los usuarios ven tu contenido.

Otra queja del autor del artículo (Alex Kras), es que AMP no es «opcional» para los usuarios que buscan. Al contrario de lo que sucede con App indexing, donde si el usuario tiene instalada la app correspondiente al dominio del resultado, y Google sabe que el contenido se puede consumir en la app, envía al usuario directamente a la app, pero ofrece un link como alternativa por si el usuario quiere ver el contenido en la web.

Entonces, ¿debería implementar AMP en mi web?

Bueno, como toda decisión de negocio, y como los gallegos siempre decimos: ¡depende!

Necesitarás evaluar los pros y contras, y tener un cuidado extra con las métricas que utilizas para evaluar tu decisión.

Si tu web depende del tráfico desde Google News, probablemente ya hayas implementado AMP. Si no, estás en desventaja con tus competidores, ya que la mayoría de resultados dentro de la caja de Noticias Destacadas en mobile, son AMP.

Ahora mismo, no está demostrado que usar AMP te ayude a posicionar mejor ni a obtener más CTR, así que si tu web móvil es lo suficientemente rápida, probablemente puedas vivir sin AMP.

Si Google empieza a dar ese empujón en rankings a los resultados orgánicos AMP (porque quieran promover la tecnología abusando de su posición, o porque empiecen de dar más peso a la velocidad en móviles, entre otros motivos), entonces tendrás que reevaluar tu decisión.

Si tu web móvil es lenta, ¡arréglala! Independientemente de que implementes AMP o no, la velocidad debería ser una prioridad, especialmente en mobile.

Mi opinión sobre AMP

Mi forma de ver todo esto es que Google no está tratando de engañar a negocios y webs con AMP, y que los aspectos negativos resultado de utilizar AMP son más consecuencias y/o limitaciones de la plataforma bajo la que funciona, y no tanto un objetivo de Google en sí mismo.

En general, si implementas AMP en tu web, verás que tus páginas cargan más rápido, lo cual es bueno para tu audiencia. Además, la adopción de AMP esta trayendo consigo una serie de buenas prácticas en web performance que deberías seguir en tu web, y no sólo en tus páginas AMP.

Ahora bien, espero que Google deje de usar su posición de poder para forzar a las webs a adoptar su propio ecosistema. Debería ser posible implementar AMP sin utilizar la caché de Google, obteniendo el mismo beneficio que cualquier otra página AMP.

Además, como probablemente el 99.9% de los usuarios ni siquiera entienden que significa AMP, deberían testar otro tipo de etiquetas en sus resultados para resaltar aquellos resultados «optimizados» para móviles, y la etiqueta debería depender más en la velocidad y la usabilidad en sí de cada resultado, y no del uso de su ecosistema AMP.

¿Tienes datos para probar alguna de las suposiciones? Si es así, dímelo y mejoramos el artículo

Test: huyijovobonomo

La entrada ¿Debería implementar AMP? 5 suposiciones no demostradas o no probadas que pueden llevarte a la decisión equivocada aparece primero en Blog de Christian Oliveira.

AMP is one of the most polemic projects from Google inside the DEV and SEO communities. Every week new information appears with data both in favour and against the project, which in most of the cases shows an incorrect picture about it.

Deciding whether to implement AMP or not can have a huge impact for some businesses, so it’s crucial to know what the pros and cons are and if they are completely true.

Most of that data is usually flawed, meaningless or half-true, so in this post you will found a compilation of some of the most common assumptions, and what they hide.

Important note! This is not an article in favour nor against AMP. It’s just an analysis of some assumptions, both favourable and not so favourable about it.

example.com is getting XX% of its Google mobile traffic from AMP

Source: http://digiday.com/media/guardian-getting-60-percent-google-mobile-traffic-amp/

This specific news piece refers to The Guardian, but you can find similar metrics from other websites.

The Guardian was one of the first news website to implement AMP, working side by side with Google, months before the project was publicly launched. They went «all-in» with AMP, creating an AMP version of all their articles (retroactively)

What does this mean? That a huge percentage of their URLs, have an AMP version. Why not all? Well, because AMP was designed in the first place for news articles, not for any kind of page. Some examples of pages in The Guardian that do not have an AMP version are:

• Their homepage: http://www.theguardian.com/
• Their categories / topics: http://www.theguardian.com/football,  http://www.theguardian.com/books/stieg-larsson
• Interactive / more complex pieces of content: http://www.theguardian.com/world/ng-interactive/2017/may/07/french-presidential-election-results-latest

When implementing AMP on your site, Google (on mobile) will replace your normal URLs by your AMP URLs on their SERPs, sending traffic to your AMP pages instead of to your normal pages.

So, saying that «The Guardian is getting 60 percent of its Google mobile traffic from AMP», just means that they implemented AMP correctly and that results are what you would expect, if you knew the % of mobile SEO traffic those pages had before AMP.

If you implement AMP on 100% of your pages, those pages will eventually get 100% of Google Mobile traffic, saying nothing about the quality or success of using AMP. It’s just part of the implementation. You could be getting less SEO traffic than before, but having 100% of it landing on AMP pages anyway.

It doesn’t tell if the Guardian is getting more or less traffic from Google Mobile, as the traffic has stopped landing on the normal pages, and started landing on the AMP pages. And even if Google Mobile traffic grew post-AMP implementation, it could be from a lot of factors and it will be difficult to know the exact reason (specially in huge sites like The Guardian, where traffic varies heavily depending on the news)

The article goes on saying: «AMP has gradually been taking over the Guardian’s mobile traffic; today, 60 percent of its Google mobile traffic is AMP, well above the 10 to 15 percent that publishers have been getting from AMP«. Which is again, meaningless, as the % of traffic AMP pages get from Google mobile depends on your AMP implementation and not from your SEO performance itself.

Bounce rate on AMP pages is really high

Sources: http://productforums.google.com/forum/#!topic/webmasters/AHU52vd02Mg, http://www.blackhatworld.com/seo/amp-pages-high-bounce-rate.897599/

If you search inside forums and blogs, you can find lots of comments about this, stating lots of reasons why the bounce rate of our AMP is so high. Those reasons can indeed be affecting, but the main cause of that high bounce rate is that it is probably wrongly calculated.

As I explained here, the way AMP works causes an inflation of sessions and users on your Analytics tool, which then causes an incorrectly calculated high bounce rate.

This is a well-known problem by Google, which is tricky to solve, and although they are working on it and have already improved it, the problem still remains for the main use scenario (people reaching your AMP pages through Google search on mobile).

So, if you want to analyse the behaviour of your AMP pages, don’t count on the bounce rate metric unless you have implemented any kind of solution to solve it.

AMP pages rank higher on Google’s Mobile SERP results

Here, we need to consider two different scenarios:

• The «Top Stories» box results, which appear for some queries in the SERPs
• The organic results.

Top Stories box results (AMP article rich results)

This box of results is not new, nor created because of AMP. Since Google launched «Universal», they try to show different types of results depending on the query.

That way, if you for example search for «Despacito», the first result is a giant youtube video with the song:

And if Google consider that the query is somehow related to «news» it will also show a box with news results:

Which in mobile now highlights AMP results:

Although sometimes there are non-AMP results inside:

That box was initially exclusive for white-listed publishers (you could opt-in if you comply with the requisites), and later on started to show, sometimes, results from websites outside that list (even tweets and youtube videos).

With the launch AMP, Google «forced» publishers to adopt its platform in order to appear in that box in mobile. Although sometimes non-AMP results appear there, it’s not the norm.

So, when some people say that AMP is a ranking factor because of this box: it’s not. Or at least not a new one, or not because of AMP. The news box existed before AMP, and even if you implement AMP on your pages, your results won’t probably appear there, as most of them are from big publishers.

The reason Google uses to justify favouring AMP in the Top Stories box is that «AMP is the format that currently delivers the best possible user experience on the mobile web. That is because AMP allows for consistent speed, caching, pre-rendering, and enables swiping between full-length pages. This is a big deal for topics where there isn’t “that one best result” that a user might want to look at.» (source: Malte Ubl, Creator and Tech Lead of AMP, on HN).

You can read my take on this at the end of this post.

Organic results (AMP non-rich results)

For the organic, «normal» results, Google says AMP is not a ranking factor yet. Believe it or not, there is no data (at least I couldn’t find it) which demonstrate the opposite.

So right now, if you implement AMP on your pages, and you rank 2nd for a query, with your «normal» URL, as soon as Google detects the AMP version of that URL, the AMP result will appear instead, in the same 2nd position.

So what about this data? It says it’s clear that rankings and CTR are better on AMP pages:

It seems better, but that data is comparing different things.

The only way to try (you cannot be 100% sure as you cannot A/B test AMP results) to get real stats about rankings and CTR for AMP vs non-AMP results would be:

• To have several URLs rankings for several keywords, really stable for a long time (in terms of traffic and CTR)
• Create the AMP version for some of those URLs, leaving some of them without AMP as a control group
• Check if Google index the AMP versions properly
• Monitor mobile rankings for both AMP and non-AMP URLs after they get indexed
• Monitor CTR for both in Search Console

That way, you can see if a keyword for which you have been ranking in the same position for long time, with a stable CTR, gets any improvement right after implementing AMP. Of course there is the possibility that lots of other factors influence this, so you can’t be 100% sure.

If you just compare, in Search Console, the performance of your AMP pages with your non-AMP pages, you are probably doing it wrong.

These are the stats, from Search Console, for my travel blog RandomTrip.es, both for Mobile AMP pages and Mobile non-AMP pages.

AMP pages:

Non-AMP pages:

So with these stats, AMP Mobile pages win: better CTR (8.82% vs 5.01%) and better average position (7 vs 7.7), right?

Well, not exactly. These are not stats about the same pages with different output, they are about different pages (pages that have AMP version always appear with their AMP version on mobile), so the comparison makes no sense. What we are comparing here is different kind of pages (the homepage and categories/tags vs posts), which may have, by themselves, different SEO performance for lots of different reasons.

CTR on SERPs is higher for AMP results

Sources: http://searchenginewatch.com/2016/10/13/accelerated-mobile-pages-amp-one-year-on-stats-and-infographic/ and http://speakerdeck.com/natalialkb/amp-in-the-wild?slide=37

This can be true, under the assumption that users have learned that the AMP symbol means pages load faster and so they tend to click more on those kinds of results, but it’s unlikely (ask any of your non-tech friends what they think it is)

And, it’s not demonstrated with data. It can be true, but it also cannot, so if you want to use it as an argument to implement AMP, you will need to test it yourself or get real data from someone who already tested it.

There is data both assuring that CTR improves and also that it decreases, but because of the explanation and examples given in the previous point, none of the assumptions are really demonstrated.

Google will steal my SEO traffic

Source: http://www.alexkras.com/google-may-be-stealing-your-mobile-traffic/ (the author, Alex Kras, rectified about the headline and says at the beginning of the article that it is inaccurate)

This article was one of the first polemic ones that took of in communities like Hacker News against AMP, and it is an interesting read as it reflects how little people know/understand about AMP (even inside the dev community).

So, will google steal your SEO traffic if you implement AMP? Not exactly

AMP is a complex project, you can learn more about how it works here. Basically, it makes your pages load fast thanks to these two main factors:

1. There are a lot of restrictions regarding CSS, JS and Ads, so they force you to create pages without all the «stuff» that makes your «normal» pages slow and that you are not willing to take out of them. So your AMP pages will (or at least should) be faster than your «normal» mobile pages.
2. Instead of sending the visitors to your AMP pages, Google is actually caching your AMP pages on its servers and serving them itself. This assures some server side optimizations their infrastructure already have.

Point 2 is the controversial here: you are no longer serving these pages, Google does, and that’s why it seems Google is stealing your traffic.

In reality, traffic will still count on your web analytics tools, and you still control the content, menus, ads and links you are showing there (with some problems carried along as I demonstrate in this post)

BUT, users don’t completely leave Google when they click on AMP results, they can swipe from one news piece to another between different websites when using the «Top Stories» box, and the URL showed on the user’s browser is a Google one, not yours.

So the traffic is counted as yours, but it’s Google serving it, and it’s Google the one controlling the environment in which the users are seeing your content.

Another complaint the author of the article (Alex Kras) does, is that AMP is not optional for the user. Contrary to what happens with App indexing, where if you have the app from the result’s domain installed and Google know that you can check the content there, it will direct you there, but offers another link to just check the content on the website.

So, should you implement AMP on your website?

Well, as with every business decision, and as we Galicians always say: it depends!

You need to evaluate the pros and cons, and take extra care with the metrics you use to evaluate your decision.

If you rely on Google News traffic, then you probably are already using AMP. If not, you are at disadvantage as most of the results in the «Top Stories» box are AMP ones.

Right now it is not demonstrated that using AMP will give you a rank nor a CTR boost, so if your mobile website is fast enough, you can probably live without AMP.

If Google starts giving AMP results (because they want to promote the technology or because they give speed more weight in their new mobile index), then you need to take that into account as well.

If your mobile website is slow, fix it! Whether you implement AMP or not, speed should be a priority, specially on mobile.

My take about AMP

My take here is that Google is not trying to fool websites and business with AMP and that the negative aspects of how AMP works right now are more of consequences / limitations of the platform than their goal itself.

In general, if you implement AMP on your website you will see your pages loading faster, which is a good thing. Also, the adoption of AMP is bringing to the table some best practices in terms of web performance that you should follow on your own website too, and not only on the AMP version.

On the other side, I hope Google stop using its power to make websites to adopt their whole ecosystem. It should be possible to implement AMP without using Google’s cache, getting the «AMP» label anyway.

Actually, as probably 99,9% of the users don’t even know what «AMP» means, they should test other kind of labels if they want to highlight «mobile optimized» results, and it should rely on the speed and UX of the destination page, not on AMP.

Do you have data to prove any of the assumptions? If so, let me know!

La entrada Should I implement AMP? 5 meaningless, not proven or misleading assumptions that may lead you to the wrong decision aparece primero en Blog de Christian Oliveira.

Update: Since October 2017, there is a partial solution to this developed and announced by Google. Learn more about it here.

Also, Google announced in November 2018 that they had developed a new technology that allows browsers to show the original URL when serving AMP pages from Google’s cache, called «signed exchanges». This is not live yet but would potentially solve the problems detailed in this post

If you have jumped in the AMP wagon and took a look at the metrics, you may be asking yourself why your AMP pages have a higher than normal bounce rate.

Take a look at this example, comparing SEO traffic to blog posts, both AMP and non-AMP (it is in both cases organic traffic, this website does not appear in the «Top News» carrousel). As you can see, the behaviour metrics are much worse in the AMP pages:

Weird, isn’t it? We could try and say that a possible explanation for this is that non-AMP traffic gets more recurring visitors, so the quality of their visits is better. But that’s not the case:

What’s happening is waaaay simpler (and complex, at the same time). Google Analytics (or the analytics tool you are using) is giving you incorrect data: inflation of unique visitors and sessions, higher than normal bounce rates, increase in referral traffic…

AMP carries with it an ecosystem where you are no longer the one serving the content, with a lot of implications in terms of measuring it. In this post, I explain you, with the highest level of detail, what the problem is, what is it caused by and how can it be solved.

How AMP works, inside Google

What is AMP?

Before going deeper, let’s understand what AMP is all about.

AMP (Accelerated Mobile Pages) is an open-source project, led by Google but supported by other partners (Pinterest, Twitter, Linkedin…) that is trying to define a standard to create faster pages for mobile devices.

It was, in part, an answer to Facebook’s Instant Articles (which is not open-source) and both of the projects have the same goal: when a user clicks on a link, inside their platforms, the content is loaded instantly

As, even with the resources, companies (in general) haven’t really tried to create faster mobile web pages, and the main cause of the slow load speeds are ads and the use of JS, Google (and Facebook) have decided to define new standards with lots of restrictions so, whatever you do, pages will load really fast.

In both cases, besides limiting the html tags and elements that you can include (JS, CSS, ads…), both platforms save a copy of your AMP/Instant Article content so they can serve it directly from their servers.

How are AMP pages served, after performing a search on Google?

In Google’s specific case, when a user clicks on any of the AMP results (those with the icon and the AMP label), the content is loaded inmediatly, without leaving Google’s SERP.

What Google does, is:

• Once the crawler detects in the «common» URL the amphtml tag, it crawls the AMP URL and validate if it complies with the AMP guidelines.
• If that’s the case, then  the AMP page is cached and asigned to the «common» URL.
• Besides that, as the AMP URL has (or should has) the canonical tag pointing to the «common» URL, it shouldn’t be indexed separately.

When a user performs a search from a mobile device, if a result doesn’t have AMP version, clicking the result will open the «common» URL in the browser. The domain server is contacted and the client’s browser receives the page (this is the common behaviour for any web page).

If a result has indeed an AMP version, Google highlights that in the result (with the icon and AMP label). When the user clicks on the result, instead of opening the URL in the browser, this is what happens:

1. The SERP’s html already contains a div element that will display the content of any AMP result.

2. After clicking on an AMP result, several elements are loaded inside that div. One of them is an iFrame. This entire layer will load the content directly inside it, without leaving the SERP.

3. That iFrame points to the specific Google’s AMP cache URL for that page (e.g., http://cdn.ampproject.org/v/s/randomtrip.es/tarjeta-sim-portugal-internet-smartphone/amp/?amp_js_v=6 ). Same happens with the elements of the «Top News» carrousel

4. If the user, after opening an AMP result, closes the article using the X up left, the layer is closed and he/she can continue navigating through the results.

5. In the specific case of the «Top News» carrousel, if the user use the swipe function, the next article is loaded (next li with the corresponding iFrame)

6. If the user clicks on any link inside the content of an AMP result, he/she leaves this environment and the «common» URL is loaded inside the browser, as always (the non-AMP URLs are the ones loaded, even if the link has a corresponding AMP version)

How AMP works, regarding Analytics?

Now that we understand how Google serves the AMP pages inside their SERPs, there are two main consequences that we need to explore, in terms of Analytics:

• AMP pages are served by Google, not by our server. Our server doesn’t even know that a page has been served to a user.
• The domain that serves the AMP page is cdn.ampproject.org, whose content is loaded inside an iFrame, in Google’s corresponding domain (e.g., www.google.es)

AMP pages are served by Google, not by our server

If we perform a log analysis filtering AMP URLs in our server, we’ll probably see that the traffic pattern has nothing to do to what Google Analytics shows (or your Analytics tool). In fact, most of the hits will be from Googlebot.

The only ways (right now) to reach an AMP page are (unless you don’t have a responsive / mobile version and you are sending all mobile traffic to your AMP pages):

• Through Google (or other 3rd parties adopting the technology, like LinkedIn, Pinterest…)
• Accessing directly to an AMP URL in your broswer.
• Through links that shouldn’t be out there, pointing to AMP pages (email, social networks, 3rd party websites…)

The first case is the most common (at least by now). In that case, the visit never reachs our server. Google serves the page directly, along with the images and other resources, through cdn.ampproject.org and its static domains:

AMP pages are served from a different domain

As Google is the one serving the pages, from his servers, the domain serving the pages is not our original domain, but one he decides. Right now Google is using cdn.ampproject.org (sometimes also yourwebsite.cdn.ampproject.org), using an iFrame loaded directly inside the SERPs.

This has a lot of implications regarding analytics, as the analytics code is being executed in a different domain and so, it can’t read the cookies of the original domain.

Some issues that happen regarding analytics, creating unrealiable data:

• A user that visits one of our AMP pages through Google, and a non-AMP page through any method, is counted as two visitors.
• A visit that starts in an AMP page through Google and continues with an internal link to a non-AMP page, is counted as two visits.
• The bounce rate (measured by default) of an AMP page is 100% unless there are several AMP results from our domain in the SERP and the user visit several of them in the same session.
• A visit coming from an AMP page through Google to our website (through internal links) is considered «Referral traffic» from cdn.ampproject.org

Below, all of these cases are  reproduced and investigated step by step.

Why AMP analytics data lies?

The term «unique visitor» is getting more and more false day by day. Users using different browsers, different devices and private/incognito options (or manually deleting the cookies) makes identifying a real user through a cookie impossible.

This means that, even without AMP, we are suffering «duplication» of unique visitors constantly

So what happens with AMP? There are different cases, depending on where the content is loaded, and, in some cases, the order of visiting each of the scenarios (all of the cases explained here refer to the use of a mobile device).

1. User access our website through his mobile browser. This is the most typical use-case for accesing our website: someone wants to check our website, and types our URL directly in the browser (or through favorites, or through Google Search).

To decide if a user is new or not, Google Analytics checks the «_ga» cookie. If it exists, the JS obtains the «clientID» value from it and send it to GA servers. If not, it creates the cookie along a new «clientID» in order to identify the user in the future interactions.

In this case, while doing the test, we are using a new «user» in Chrome so we don’t have any cookie set yet, and so a new one is created.

Our clientID for this domain:

2. User access directly to an AMP page: this case, generally, will not be common (unless we share/link our AMP URLs, or implement our mobile website directly with AMP).

We are still in our domain (randomtrip.es), and so, the GA code should be able to access the previous cookie (_ga) and know that we are still the same user, right?

Well, and here «the party starts», that’s not the case:

What happens here is that Google Analytics’ AMP JS uses a cookie indeed, but the one it uses (AMP_ECID_GOOGLE) is different than the cookie GA uses in non-AMP pages (_ga).

So, clientID is different in this case, and this two sequential interactions would result in two unique visitors with two individual sessions.

3. User performs a search on Google and clicks an AMP result: This is the most common use-case for AMP

Content is loaded through Google’s AMP Cache, inside Google’s domain (let’s say google.es) through an iFrame that points to cdn.ampproject.org, and the user identification information (the clientID) is saved in the LocalStorage for the google.es domain, instead of in a cookie (it doesn’t use _ga cookie, nor the _AMP_ECID_GOOGLE cookie). The value stored there is unique and, of course, different from the previous values in the cases 1 and 2.

Funny, uh? :D (notice the sarcasm here). So that would be our third interaction with this website, andthis is our third clientID:

So, we (I) are already three unique visitors, with three different sessions!

4. User access directly the Google AMP’s cache URL: this case is starting to be a common one for third party apps adopting AMP (LinkedIn, Pinterest…), or could happen in the strange case a user access directly one of those URLs through any other method. The URL is like this: http://cdn.ampproject.org/v/s/randomtrip.es/barco-flores-lombok-komodo/amp/?amp_js_v=6

In this case, the method used by GA is the same than in the previous case (the LocalStorage, not the cookie) but it uses instead the LocalStorage for the subdomain cdn.ampproject.org, so the value stored for the clientID is, again, a new one, different from all the other cases.

We have our forth clientID, for the same website, using the same browser and without deleting cookies.

5. User access directly to the URL Google shows when clicking an AMP result: this case is common as it happens when a user gets to an AMP page through Google and, when deciding to share it (by email, social networks, etc.) copies the visible URL in their browser or using the native «sent to» option.

Google is trying to avoid this behaviour, but IMO in a ineffective way. The visible URL is still their own ;)

The URL would be like http://www.google.es/amp/s/randomtrip.es/barco-flores-lombok-komodo/amp/ (you can’t access this kind of URL from desktop – you will be redirected to the original one. You can access it from a mobile device).

In this case, we are in the google.es domain, and the clientID value is saved in the LocalStorage.

Now something interesting happens.

If different values for the clientID exist in both the LocalStorage of google.es (or the corresponding Google domain) and cdn.ampproject.org, the second one is the one sent. So, once we access cdn.ampproject.org, cases 3, 4 and this one (5) should send the same clientID value (not bad :D)

In this case, this is the clientID sent to GA servers (same as in case 4):

So: the clientID generated in the case 3, will never be used again, because now the one generated in the case 4 will be the chosen one for both cases. Depending in the order of interaction of the user with our website, both will be generated or not, and we will have more or less duplication of «unique visitors» and visits.

6. User access AMP version through a third party app: There is one last case, that is starting to appear now, which is third party apps.

LinkedIn, Pinterest, Flipboard… are already including AMP version on the links shared by anyone inside their platform instead of the «common» ones, directing the traffic directly to the Google AMP’s cache URL (cdn.ampproject.org or yourwebsite.ampproject.org), which would be same as case 4.

I couldn’t try yet, but as these apps open the link in a html viewer inside the apps themselves, it is possible that each one of them could generate a new clientID. Anyway, some of them use the Chrome engine, so this may not be the case. If you happen to test it, please say so in the comments so we can complete the information for this case! :)

So, we have 6+ scenarios, 4 of which (at least) generate a different clientID, which means that what before AMP was (ideally) one unique visitor, now can be counted as up to 4 unique visitors:

All of this is also explained here by Google itself, and confirmed by the creator and tech lead of AMP as a known issue

Impacted Metrics

As you can imagine, the consequences of this «errors» regarding analytics are that lots of metrics inaccurate, so we need to be careful when we analyze data if AMP traffic is involved.

• Unique visitors: as we have just checked, a user accessing from the same device, using the same browser and withouth deleting cookies, can be counted as up to 4 unique visitors depending on how he/she access our AMP pages.
• Sessions: if a user visits an AMP page, in any of the environments and leaves, there is no problem in terms of sessions. But, if he continue navigating our website, from the AMP page to any other non-AMP page on our website, apart from being counted as a new Unique Visitor, a new session is started, so it is counted as two sessions.
• Bounce rate: due to the previous reasons, when a session is divided in two, the first session would have only one pageview (so it will be counted as a bounce). The second session, if it only checks one page, would also be considered a bounce. So, the bounce rate will be increased incorrectly (the complete session should not be considered a bounce, but it ends being two bounce sessions). And this happens both for AMP and non-AMP pages.
• Pageviews per session: also in consequence of the previous reasons, instead of having 2 pageviews/session, we would have 1 pageview/session.
• Traffic sources: traffic coming from our AMP pages to our non-AMP pages from 3rd parties, will be counted as entry traffic (new sessions) and its source would be «Referral Traffic», from cdn.ampproject.org (or yourwebsite.cdn.ampproject.org)

These are the most common metrics directly affected. As you can imagine, as these ones are affected, so are most of the rest, as most of them depend on these ones to be calculated.

For example: in an e-commerce, if a user enters our website through an AMP page in Google and ends buying something in the same session, the sale would be attributed to the «second user», and the source of that visit would be «Referral Traffic», instead of «Search Engines».

How to avoid Analytics duplicating users with AMP?

Luckily, a solution exists, to avoid clientIDs to be different in any of these cases. The solution is technically complex, but feasible. It is only valid for the data collected after its implementation, not for the already collected data.

It’s unbelievable that Google hasn’t done anything yet to fix this situation (neither they did with the Spam problem in Google Analytics), when AMP has been live on the SERPs for year.

The solution, which I haven’t tested yet, can be found in this post from Simo Ahava:

http://www.simoahava.com/analytics/google-analytics-client-id-amp-pages/

Basically it consists on creating a proxy in our own domain (we need http, at least in the proxy URL)

In the amp-analytics component configuration, you can define that before sending the data to Google Analytics servers, more configuration information should be obtained from an external URL.

Contrary to most of the AMP resources (which Google cache on their servers and serve them directly), this petition to this URL is not cached, and it is performed every time the page finishes loading, from the client, while the page keeps the focus.

As the petition is to a URL from our own domain, cookies from our domain are sent, so the proxy just checks if the _ga cookie exists, and if that’s the case, gets the clientID value from it to return it to the client. The client receives the «correct» clientID and sends the information to GA servers.

Besides that, the _ga cookie must be updated the same way Google Analytics normally does.

Problems:

• Not a trivial implementation.
• You need http in your server (at least for the proxy URL)
• It’s not an official solution, so this can lead to problems in the future.
• If you implement it wrong, the results can be worse
• Doesn’t work on Safari, when accessing the content through Google’s AMP cache.

UPDATE (02/03/2017): Malte Ubl, creator and tech lead of the AMP Project, just said on Twitter that Simo’s solution is indeed a good one, with the caveat that won’t work when using Safari and accessing the content through Google’s AMP cache (as Safari blocks 3rd party cookies)

What happens with historical data?

If you manage to implement the previous solution, it will just fix the problem after the implementation is done. The data you already have in your Google Analytics would still be wrong.

What can you do? Not a lot, but if you really need to try and fix the data (at least the basic metrics), you can try with the following, finding an aproximation of how the data should be:

• As sessions who navigate inside an AMP page end on our website, we have them controlled: they all are under the «Referral Traffic» section, from cdn.ampproject.org.
• If you want to correct the bounce rate, you can get from one side the AMP pages visits, on the other side the visits from cdn.ampproject.org and try co re-calculate the value. E.g., if you have 1000 visits to AMP pages, with a 89% bounce rate, and then 200 visits from cdn.ampproject.org, you would have:
  • 110 visits (11%) were not bounces, as they visited several AMP pages in the same session.
  • 200 visits have been considered bounces, but they are not, as they come from your AMP pages.
  • So, you have 310 visits which were not bounces.
  • Aprox. of real bounce rate, corrected: 690 bounces (1000-310) out of 1000 (69% instead of 89%)

Based on this, you can try to do the same with other metrics.

How to (partially) solve the problem with the solution provided by Google

Google developed a partial solution to this problem available to all google domains since October 2017. You can read about it here and you can also check my talk about it at Searchmetrics Summit 2017:

It’s important to note that this solution is not included «by default», so if you are using AMP in any of your websites, you need to to the following in order to get this solution working:

1. On all your non-AMP pages, set the value of the parameter ‘useAMPclientID’ to «true»

2. On all your AMP pages, include this tag on the head:

<meta name="amp-google-client-id-api" content="googleanalytics">

3. Use referral exclusion on GA: you need to set up referral exclusion with this domain cdn.ampproject.org

More info about how to implement and debug the solution: https://support.google.com/analytics/answer/7486764?hl=en

Appart from this, Google announced that, using a new technology called Signed Exchanges, they soon will be able to serve AMP pages from Google’s AMP cache showing your original URL, which would potentially solve the problems stated in this post.

TL/DR

We’ve just checked that the same «unique visitor» ends up being counted as up to 4 unique visitors due to how AMP works, generating wrong metrics in our Analytics tool.

Worst thing is that maybe you didn’t even realize, and you may have been worried about the high bounce rate on your AMP pages.

By now, unless you manage to try the solution indicated in this post, there is not much else to do. But it’s important to take this into account before jumping into conclusions with our data, when AMP traffic is involved

Ideally, Google will provide an official solution. By now, there is a task in AMP’s Github, but it’s been there for some months without any specific plans of being implemented. Besides that, if AMP adoption by 3rd parties continue growing, the number of unique visitors generated by the same device can grow even more.

UPDATE (02/03/2017): Google’s completely aware of this problem and trying to find a solution (although no easy)

Additional reads:

• Accelerated Mobile Pages via Google Tag Manager
• What’s Going On With AMP Analytics?
• How To Set Up Adjusted Bounce Rate on Accelerated Mobile Pages (AMP) Using Google Tag Manager

Hope the post has been useful. If that’s the case, share it! :)

La entrada Why the bounce rate of my AMP pages is so high? aparece primero en Blog de Christian Oliveira.

Actualización: Desde Octubre de 2017, Google desarrolló y anunció una solución parcial al problema descrito en este post. Puedes leer más sobre ello aquí.

Además, Google anunció en Noviembre de 2018 que ha desarrollado una nueva tecnología que permitirá a los navegadores mostrar la URL original cuando sirvan la versión AMP desde la caché de Google, llamada «Signed Exchanges». Todavía no está implementado en las versiones más recientes de los navegadores pero solucionaría potencialmente los problemas detallados en este artículo.

Si te has subido al carro de AMP, y has indagado un poco en las métricas puede que te estés preguntando por qué tus nuevas páginas tienen un porcentaje de rebote tan alto (muchas veces mayor que las versiones «normales» de las mismas páginas).

Aquí tenéis un ejemplo, comparando el tráfico de un blog a posts (no categorías, ni home) AMP y NO AMP (tráfico orgánico a AMP, la web no sale en el carrusel de Noticias Destacadas). Como podéis ver, las métricas de comportamiento son mucho peores en el caso de AMP.

Es raro, ¿no? Podríamos decir que una posible explicación es que el tráfico no AMP tiene más usuarios recurrentes, y que por eso tiene mejor calidad. Pero no es el caso:

Lo que está pasando es mucho más simple (y a la vez complejo): Google Analytics (o la herramienta de medición que utilices) te está dando datos incorrectos: inflación de usuarios únicos y sesiones, porcentajes de rebote más altos de lo habitual, aumento del tráfico de referencia…

AMP trae «de regalo» un ecosistema en el que tú ya no eres el que sirve el contenido, con todo lo que eso conlleva de cara a la medición del uso de estas páginas. En este artículo, te explico con todo nivel de detalle cuál es el problema con las métricas en AMP, a qué se debe, y cómo se puede solucionar.

Cómo funciona AMP, en Google

Qué es AMP

Antes de profundizar en sus entresijos, conviene entender en qué consiste AMP.

AMP (Accelerated Mobile Pages) es un proyecto open source, liderado por Google pero secundado por otros partners (Pinterest, Twitter, Linkedin…), que pretende definir un estándar para realizar páginas para dispositivos móviles más rápidas.

Apareció, en parte, como respuesta a Instant Articles de Facebook (que no es open source) y ambos proyectos tienen el mismo objetivo: que cuando el usuario pinche en un link, dentro de sus plataformas, pueda visualizar el contenido de forma inmediata.

Como, a pesar de tener los recursos, las empresas (en general) no han creado webs móviles muy rápidas, y la causa de su lentitud suelen ser principalmente la publi y el uso de JS, Google (y Facebook) han decidido definir unos estándares con muchas restricciones para que sí o sí, tu web cargue muy rápido.

Para ello, en ambos casos, además de limitar el número de etiquetas html y elementos que se pueden incluir (JS, CSS, anuncios y demás), ambas plataformas cachean una copia de tu contenido en versión AMP/Instant Article para servirla directamente desde sus servidores.

¿Cómo se sirven las páginas AMP cuando realizas una búsqueda en Google?

En el caso concreto de Google, al clickar en cualquier resultado que muestre el símbolo del rayo y «AMP» al lado, cargará, sin salir del SERP de Google, la página correspondiente, de forma prácticamente inmediata.

Esto es así porque lo que Google hace es:

• Una vez detecta en una URL «común» la etiqueta que indica su versión AMP, la rastrea, valida que el html cumpla los estándares AMP
• Si es así, se guarda una copia en caché y marca que la URL «normal» tiene versión AMP, asociando la una a la otra.
• Además, como la URL tiene (o debería) tener una canonical apuntando a la normal, no se debería indexar por separado en el índice de Gogle.

Cuando alguien hace una búsqueda en mobile, si un resultado no tiene versión AMP, al pinchar en el link se abre esa URL en el navegador, se contacta al servidor del dominio en cuestión y se obtiene el contenido de la página (como toda la vida, vamos!)

Si un resultado sí tiene versión AMP, Google muestra el símbolo del rayo y las letras AMP. Al pinchar, en lugar de abrir la URL original del resultado en el navegador (ya sea la URL AMP o la «común»), lo que pasa es lo siguiente:

1. En el html mobile, Google tiene un div ya preparado para albergar el contenido de cualquier resultado AMP.

2. Al pinchar en el resultado, dentro de ese div se cargan una serie de elementos, entre ellos un iFrame. Esta capa carga el contenido del resultado correspondiente, sin salir de la página de resultados el la que el usuario está.

3. Ese iFrame, apunta a la URL de la caché de Google para la URL de AMP del resultado correspondiente (ej: http://cdn.ampproject.org/v/s/randomtrip.es/tarjeta-sim-portugal-internet-smartphone/amp/?amp_js_v=6 ). Lo mismo ocurre en el carrusel de «Noticias destacadas»

4. Si el usuario cierra con el aspa superior izquierda, se cierra la capa y sigue donde estaba (en el SERP)

5. Si el usuario hace «swipe» (en el caso del carrusel de «Top News») se pasa al siguiente elemento de la lista (otro iFrame con la URL de la caché de Google que corresponda)

6. Si el usuario pincha en algún link o elemento dentro del contenido de cualquiera de los artículos AMP, se va fuera y ahora sí se abre con el navegador la URL correspondiente (versión NO-AMP, aunque la URL la tenga)

¿Cómo funciona AMP a nivel de analítica?

Una vez hemos entendido cómo sirve Google las páginas AMP dentro de sus resultados de búsqueda, hay dos puntos fundamentales que afectan a nivel de analítica:

• Las páginas las sirve Google, no nuestro servidor. Nuestro servidor ni siquiera sabe que se ha servido una página.
• El dominio que sirve la página es cdn.ampproject.org, cuyo contenido se carga con un iFrame dentro del dominio de Google en el que se realizase la búsqueda (por ejemplo www.google.es)

Las páginas las sirve Google, no nuestro servidor

Si hacemos un análisis de logs en nuestro servidor de las URLs AMP que tengamos, veremos que probablemente el patrón de tráfico no tenga nada que ver con lo que nos muestra Google Analytics (o la herramienta de analítica que usemos). De hecho, puede que sólo tengamos peticiones de Googlebot.

Esto es así porque, a día de hoy, salvo que no tengamos versión móvil o web responsive y derivemos el tráfico móvil a AMP, las únicas formas de llegar a una página AMP son:

• A través de Google (u otros terceros que están adoptando la tecnología)
• Accediendo a la URL de alguna página AMP directamente desde nuestro navegador
• Que se haya escapado algún link a una URL AMP por algún lado (email, redes sociales, webs de terceros que nos enlacen…).

Si se llega a través de Google, la visita nunca llega a nuestro servidor: Google sirve directamente la página, las imágenes, etc., desde cdn.ampproject.org

Las páginas se sirven desde un dominio diferente

Al servir las páginas Google, desde sus servidores, el dominio que las sirve no es el nuestro, si no el que él elija. En este caso y actualmente, el dominio que está utilizando es cdn.ampproject.org (a veces aparece un subdominio de este, tipo tuweb.cdn.ampproject.org), mediante un iFrame insertado en google.es (o el dominio regional de Google que corresponda)

Esto a nivel de analítica tiene muchas implicaciones, ya que el código de analítica se está ejecutando desde un dominio diferente, y por lo tanto no puede acceder a la cookie del dominio original.

Algunas cosas que pasan a nivel de analítica, y que generan datos no fiables:

• Un usuario que visite una página nuestra en AMP desde Google, y otra no-AMP, son dos usuarios.
• Una visita que empiece en una página nuestra en AMP desde Google y pinche en algún enlace interno, son dos visitas.
• El rebote (medido por defecto) de una página AMP es 100% salvo que tengamos varios elementos en el carrusel de «Top News» y el usuario pase por varios de ellos en la misma sesión, o salvo que tengamos varios resultados del mismo dominio en un SERP y el usuario pinche en varios de ellos en la misma sesión.
• Una visita que viene a la web «común» después de pinchar en un enlace interno en la versión AMP servida por Google, tiene como fuente «Tráfico de Referencia» desde cdn.ampproject.org

A continuación, reproduzco paso a paso cada una de estas anomalías.

¿Por qué los datos de analítica de AMP mienten?

El término «usuarios» cada vez es más falso en el mundo de la analítica web. Diferentes navegadores, diferentes dispositivos y el uso de los modos incógnito (o borrado manual de cookies) hacen que prácticamente ningún usuario pueda ser identificado de forma unívoca con una cookie.

Esto quiere decir que, incluso sin AMP, estamos sufriendo «duplicidad» de usuarios constantemente.

¿Qué pasa con AMP? Hay diferentes casos, según desde dónde se cargue el contenido, y en algún caso, según el orden (en todos los casos hablo del uso desde un dispositivo móvil):

1. Usuario accede a la web desde su navegador móvil. Este es el caso típico de uso de nuestra web: alguien quiere acceder a ella, e introduce directamente la dirección en su navegador (o accede desde favoritos).

Para determinar si es un usuario nuevo o no, Google Analytics comprueba la cookie «_ga». Si existe, obtiene de ella el valor del «clientID» y lo envía. Si no es así, la genera, con un nuevo «clientId» para poder identificar al usuario en las próximas sesiones.

En este caso, al hacer las pruebas en un navegador desde 0, todavía no hay ninguna cookie y somos un usuario nuevo, por lo que se genera la cookie y el «clientID».

Nuestro clientID para este dominio:

2. Usuario accede directamente a página AMP: este caso, en general, no será común, salvo que compartamos o enlacemos nuestras URLs AMP (o hagamos nuestra versión móvil en AMP directamente).

Seguimos estando en nuestro dominio (randomtrip.es), y por lo tanto, al acceder a una página la cookie generada en el paso anterior nos debería identificar y, por lo tanto, seríamos el mismo usuario, ¿no?

Pues no es así (empieza la fiesta):

Lo que pasa aquí es que el JS de Analytics que se utiliza en AMP sí utiliza una cookie, pero la cookie que utiliza (AMP_ECID_GOOGLE) es distinta de la cookie que utiliza Analytics en las páginas no AMP (_ga).

Por lo tanto, la información del clientID es distinta para este caso, y para estas dos interacciones secuenciales, somos dos usuarios y dos visitas diferentes.

3. Usuario hace búsqueda en google y pincha en resultado AMP. Este es el caso más típico de uso de AMP.

El contenido se carga desde la caché de Google, en el dominio de google (pongamos google.es) a través de un iFrame que apunta a cdn.ampproject.org, y la información de identificación del usuario (clientID) se guarda en LocalStorage para el dominio google.es, no en una cookie (ni _ga, ni AMP_ECID_GOOGLE). El valor que guarda ahí es único y diferente al valor del clientID de la cookie del dominio real del contenido.

¿Divertido, eh? :D (Nótese el sarcasmo). Pues esta, que sería la tercera interacción secuencial, envía la siguiente información a Analytics:

Por lo tanto, ya somos tres usuarios y tres sesiones diferentes!

4. Usuario accede directamente a la caché: Este caso empieza a ser común para terceros diferentes a Google (LinkedIn, Pinterest…), o se podría dar en el extraño caso de que el usuario accediese directamente a la fuente del iFrame (a la caché de Google para AMP), accediendo por ejemplo a una URL como esta: http://cdn.ampproject.org/v/s/randomtrip.es/barco-flores-lombok-komodo/amp/?amp_js_v=6

En este caso, se utiliza el mismo sistema que en el caso anterior (el LocalStorage, y no la cookie) pero para el subdominio cdn.ampproject.org, con lo cual el valor que se almacena para el clientID es distinto del anterior. Ya tenemos nuestro cuarto clienId distinto, todo para la misma web, desde el mismo navegador y sin borrar cookies.

En este caso, el clientID que nos asigna es el siguiente:

5. Usuario accede directamente a la URL de Google que muestra el iFrame desde la caché: este caso es común ya que se da cuando un usuario hace una búsqueda en Google, pincha en un resultado de AMP, y al ver el contenido decide compartirlo bien copiando y pegando la URL tal cual, bien a través de las funciones nativas del navegador (enviar a…).

Google está intentando evitar este comportamiento, pero creo que de una manera poco efectiva. La URL visible sigue siendo la suya propia ;)

La URL sería de este estilo: http://www.google.es/amp/s/randomtrip.es/barco-flores-lombok-komodo/amp/ (no se puede acceder desde Desktop, ya que hace redirección a la URL original. Sí se puede acceder desde móvil).

En este caso, estamos en dominio google.es, y el valor del clientID también se guarda en el LocalStorage.

Y aquí pasa una cosa interesante.

Si existen dos valores diferentes para el clientID en los LocalStorage de google.es (o el dominio que corresponda) y cdn.ampproject.org, prima el del segundo. Por lo tanto, una vez que hayamos accedido alguna vez a «cdn.ampproject.org», los casos 3, 4 y este mismo (5), deberían devolver el mismo valor para clientID (menos mal! :D)

En este caso, el clientID que nos asigna es el siguiente (el mismo que en el caso 4):

Es decir: el clientID generado en el paso 3, ya nunca más se va a utilizar, porque ahora prevalece el del paso 4. Dependiendo de la secuencia de interacción del usuario, se generarán ambos o no, y tendremos mayor o menor inflación de usuarios y visitas.

6. Usuarios que acceder a versión AMP a través de apps de terceros: hay un último caso, que está empezando a despegar todavía ahora, y son las apps de terceros.

LinkedIn, Pinterest, Flipboard… ya están incluyendo la versión AMP de los links en vez de la normal en sus aplicaciones móviles, dirigiendo el tráfico directamente a la URL de la caché de Google (cdn.ampproject.org o tuweb.cdn.ampproject.org), que sería el caso 4.

No he podido comprobarlo todavía, pero al abrir estas apps los links en un viewer html dentro de la propia app, es posible que para cada una de ellas se genera un nuevo usuario (aunque algunas usan el motor de Chrome, así que puede que no sea así). Si lo compruebas, avisa en los comentarios para completar la info! :)

Por lo tanto, tenemos 6+ escenarios, de los cuales 4, al menos, generan un clientID distinto, lo cual quiere decir que lo que antes de tener implementado AMP contaba idealmente como un usuario único (en el mismo navegador, en mobile), ahora puede llegar a contar como hasta 4 usuarios únicos:

Todo esto lo tenéis aquí explicado también por el propio Google y confirmado por el creador y líder tecnológico de AMP, Malte Ubl, en Twitter

Métricas afectadas

Como te podrás imaginar, las consecuencias de estas discrepancias a la hora de medir hacen que muchas de las métricas no representen la realidad tal y como la imaginamos, por lo que hay que tener mucho cuidado a la hora de analizar e interpretar los datos si hay tráfico AMP de por medio

• Usuarios únicos: como acabamos de comprobar, un usuario desde un mismo dispositivo, con un mismo navegador y sin borrar cookies puede llegar a contar como 4 usuarios diferentes en función de cómo visite nuestras páginas AMP.
• Visitas/Sesiones: si un usuario visita una página en AMP, en cualquiera de los entornos, y se va, no hay problema (desde un punto de vista de medición). El problema viene si el usuario navega. En ese caso, al pinchar en cualquier link o elemento que le lleve a otra página de nuestra web (normalmente, a páginas no AMP), al igual que se cambia de usuario, se inicia una nueva sesión, partiendo una única sesión en dos.
• Porcentaje de rebote: debido a lo anterior, al partir una sesión en dos, la primera sesión tendrá una sola página vista y por lo tanto contará como un rebote, cuando en realidad no lo es. La segunda visita, si solo ve una página y se va, también contará como rebote. Entonces, está aumentando el porcentaje de rebote de forma totalmente ficticia (una sesión que no sería considerada rebote – el usuario ve dos páginas –  se convierte en dos sesiones, ambas consideradas rebotes). Tanto para AMP como para las páginas no AMP visitadas desde la versión AMP.
• Páginas vistas por sesión: totalmente ligada a los dos puntos anteriores, en lugar de tener 2 páginas vistas por sesión pasaríamos a tener 1.
• Fuentes de tráfico: el tráfico que navega hacia otras URLs de nuestra web desde los escenarios en los que el contenido lo sirve Google (o un tercero), cuenta como tráfico de entrada (sesiones nuevas) y su Fuente de tráfico pasa a ser Tráfico de referencia desde cnd.ampproject.org (o tuweb.cdn.ampproject.org)

Estas son las métricas más comunes directamente afectadas. Como os podéis imaginar, a raíz de estas, prácticamente todo el resto de métricas se ven afectadas, al depender la gran mayoría de estas para su cálculo.

Por ejemplo, en un e-commerce, si un usuario accede a través de AMP y termina comprando en esa misma sesión, la venta se atribuiría al usuario de la web, no al de AMP, y tendría fuente de tráfico «Referencia» en vez de «Buscadores».

Cómo evitar que Analytics duplique usuarios con AMP

Por suerte, existe una solución para evitar que los clientID sean diferentes en todos estos casos, técnicamente compleja, pero factible. Sirve para los datos recogidos a raíz de su implementación, pero no para los datos que ya tengamos recogidos en Google Analytics.

Es increíble que Google no haya hecho todavía para arreglar esta situación (igual que no ha hecho nada por solucionar el tema del Spam en Google Analytics), cuando AMP lleva ya casi un año implementado en las SERPs.

ACTUALIZACIÓN (07/03/2017): Eduardo Garolera me ha pasado este linkazo en el que Google explica de forma muy específica y detallada el «approach» que recomienda seguir para minimizar el impacto de la duplicación de cookies de usuario. Viene a explicar lo que ha hecho Simo, y que cuento aquí abajo, pero con una solución también para el caso en el que el usuario que visita alguno de los escenarios AMP sin haber visitado antes nuestra propia web.

La solución, aunque no la he probado todavía, la podéis encontrar en este post de Simo Ahava:

http://www.simoahava.com/analytics/google-analytics-client-id-amp-pages/

Básicamente consiste en crear un proxy en nuestro dominio (se necesita http sí o sí).

En la configuración del componente amp-analytics, en AMP, se puede indicar que antes de enviar los datos a Google Analytics, se obtenga información de configuración extra desde una URL externa.

A diferencia de la mayoría de recursos en AMP (que los cachea Google y los sirve desde sus propios servidores), esta petición a la URL externa no se cachea y se realiza siempre desde el cliente, en el momento en que la página se termina de cargar y el foco está puesto en ella.

Al ser una petición a una URL de nuestro dominio, se envían las cookies de ese dominio al servidor, por lo que el proxy lo que hace es comprobar si recibe la cookie _ga, y si es así, extraer el valor del clientID para devolverlo al cliente y que se incluya ese clientID en la petición a Analytics, en vez del que ha generado el propio Google Analytics.

Además, hay que actualizar la cookie de la misma manera en que Google Analytics lo haría, para reproducir el comportamiento por defecto de GA.

Problemas:

• No es una implementación tan trivial
• Necesitas tener http en tu servidor (al menos para la URL del proxy)
• No es algo oficial, por lo que si la forma de medir de Google Analytics cambia es probable que tengamos que actualizar nuestro «workaround»
• Si lo hacemos mal, la podemos liar todavía más.
• No funciona si el usuario no visita primero en AMP y luego en nuestra web
• No funciona en Safari cuando se accede al contenido a través de la caché de Google AMP.

ACTUALIZACIÓN (02/03/2017): Malte Ubl, creador y responsable tecnológico del proyecto AMP, acaba de decir en Twitter que la solución de Simo es, de hecho, buena, con la salvedad de que no funcionaría en el caso de Safari, al acceder al contenido a través de la caché de Google (ya que Safari bloquea las cookies de terceros)

¿Y qué pasa con los datos históricos?

Si te atreves a implementar la solución anterior, obviamente sólo se arreglará el problema a partir del momento en que pongas la solución en producción, por lo que los datos recogidos hasta ese momento seguirán estando mal.

¿Qué puedes hacer? No mucho, pero si de verdad necesitas intentar darle un vuelvo a los datos (al menos a los más básicos) de lo que tengas hasta ahora, puedes intentar utilizar la siguiente información para obtener una aproximación.

• Como las sesiones que hayan consumido más de una página acaban irremediablemente en tu web, las tenemos controladas: están bajo «Tráfico de referencia» desde el subdominio cdn.ampproject.org.
• Si quieres corregir el rebote, puedes sacar por un lado las visitas a AMP, por otro las visitas desde cnd.ampproject.org y recalcular el dato. Ej: si tienes 1000 visitas a páginas AMP, con un 89% de rebote, y 200 visitas desde cnd.ampproject.org, tendrías:
  • 110 visitas (11%) no fueron rebotes, porque visitaron varios resultados en los SERPs de AMP de tu dominio
  • 200 visitas se han considerado rebote, pero en realidad no lo fueron, porque accedieron a tu web desde AMP y se han categorizado como tráfico de refencia
  • Por lo tanto, 310 visitas no han sido rebotes.
  • Aproximación de rebote corregido: 690 (1000-310) de 1000 (69% en vez de 89%)

Partiendo de esto, puedes hacer lo mismo con otras métricas (para descontar usuarios y sesiones, reajustar páginas vistas, etc.)

Cómo solucionar (parcialmente) este problema con la solución propuesta por Google

Google desarrolló una solución parcial a este problema funcional en todos los dominios de Google desde 2017. Puedes leer sobre ello aquí y también echar un ojo a la presentación sobre el tema que hice en el Searchmetrics Summit 2017:

Es importante destacar que está solución no viene incluida «por defecto» en AMP, así que si usas AMP en alguna de tus webs, necesitas hacer lo siguiente para tener la solución funcionando:

1. En todas tus páginas no-AMP, setear el volumen del parámetro ‘useAMPclientID’ a «true»

2. En todas tus páginas AMP, incluir el siguiente tag en el head:

<meta name="amp-google-client-id-api" content="googleanalytics">

3. Usar exclusiones de referencia en GA: necesitas dar de alta exclusiones de referencia para el dominio cdn.ampproject.org

Más información sobre cómo implementar y comprobar que está funcionando esta solución en https://support.google.com/analytics/answer/7486764?hl=es

Aparte de esto, Google anunció que gracias al uso de una nueva tecnología, Signed Exchanges, los navegadores podrán servir páginas AMP desde la caché de Google mostrando la URL original del contenido, que potencialmente solucionaría los problemas detallados en este post.

Conclusión (TL/DR)

Acabamos de ver y demostrar cómo un mismo «usuario» (mismo navegador con cookies habilitadas en un mismo dispositivo móvil) puede multiplicarse por 4 por culpa de AMP en las herramientas de Analítica, arrastrando consigo un aumento de visitas, un descenso de páginas vistas por visita y un aumento del rebote, todo totalmente «ficticio».

Y lo peor de todo, es que seguramente ni te habías dado cuenta. Y puede que hasta te hayas preocupado con el alto rebote de tus páginas en AMP.

De momento, salvo que te atrevas a probar la solución que he señalado en este post, no hay mucho que hacer. Pero por lo menos, es importante tenerlo en cuenta a la hora de analizar, y evitar sacar conclusiones precipitadas cuando haya tráfico AMP de por medio.

Lo ideal es que Google proponga una solución «oficial». De momento hay una tarea en el Github de AMP, pero lleva ahí unos meses sin mucho movimiento. Además, si la adopción de AMP en apps de terceros sigue, el número de usuarios por dispositivo móvil puede crecer todavía más.

ACTUALIZACIÓN (02/03/2017): Google es completamente consciente del problema y está tratando de encontrar una solución (aunque no es fácil)

Lecturas adicionales (en inglés):

• Accelerated Mobile Pages via Google Tag Manager
• What’s Going On With AMP Analytics?
• How To Set Up Adjusted Bounce Rate on Accelerated Mobile Pages (AMP) Using Google Tag Manager

Espero que el post te haya sido útil. Si es así, compártelo! :)

La entrada ¿Por qué mis páginas de AMP tienen un porcentaje de rebote tan alto? aparece primero en Blog de Christian Oliveira.

1. El SEO en medios

Si algo caracteriza al SEO en grandes medios de comunicación es la inmediatez, el poco tiempo disponible para recolectar datos y decidir qué keywords elegir para nuestras noticias. El tiempo de vida de una noticia suele ser bastante limitado (por norma general uno o dos días como máximo) y el volumen de demanda generado no es lineal, sino que hay uno o varios picos dentro de esas 24-48h. Por lo tanto, si no conseguimos posicionar nuestro contenido durante esos picos, hemos perdido nuestra oportunidad.

Lo malo, que tenemos poco tiempo para actuar.

Lo bueno, que las noticias tienen un pase VIP a las SERP de Google: Google News.

Si lo hacemos bien y mejor que la competencia, nuestras noticias tardan minutos en aparecer en las primeras posiciones, listas para ser clickadas por, en ocasiones, enormes cantidades de personas.

Para entenderlo mejor, es más fácil echar un vistazo al siguiente ejemplo:

La línea azul representa las búsquedas desde España para la keyword “hoteles en madrid” en Marzo de 2014. Esta keyword tiene un volumen mensual de búsquedas más o menos constante, una media de 27000 búsquedas al mes (según la herramienta Keyword Planner de Google Adwords).

En la siguiente gráfica, pintamos la información anterior junto a la misma información para las búsquedas “cambio de hora” y “Adolfo Suárez”, representadas con las líneas roja y amarilla respectivamente:

Como se puede apreciar en la gráfica, la línea azul ni siquiera se distingue, mientras que las otras dos búsquedas tienen solamente algunos picos, pero de muchísimo volumen. Tanto, que ese mes representan mucho más en volumen que la keyword anterior (“hoteles en madrid)

El contenido que generemos relacionado con esas dos keywords, es muy probable que no vuelva a recibir cantidades significantes de tráfico. Si sucede algo más de interés respecto al tema se cubrirá con nuevas noticias. En algunos casos, sabremos cuándo volverá a suceder (cambio de hora), mientras que en otras no lo podremos afirmar a ciencia cierta.

¿Cómo sabemos qué keywords utilizará la gente para buscar?

En el caso de algo que haya sucedido en el pasado, tenemos dos “grandes” fuentes:

• Los datos de Google: sólo si el suceso aconteció en la ‘era Google’ – concretamente, desde 2004 en Google Trends. Tenemos datos más detallados en la herramienta keyword planner; concretamente y desde hace pocas semanas, de los dos últimos años.
• Los datos de nuestra web: sólo si tenemos las keywords por las que llegaron a nuestra web los usuarios anteriormente, o datos de las búsquedas que realizaron en el buscador de nuestra web. También tenemos datos de impresiones y clicks en Google en su herramienta Webmaster Tools (solo de los últimos 90 días a no ser que nos hayamos dedicado a guardar los datos en el pasado).

Si lo que sucede es un hecho completamente nuevo, tendremos solamente los datos de nuestra web en tiempo real, según vaya transcurriendo el tiempo de vida de la noticia y podamos observar el comportamiento del usuario (principalmente keywords de entrada o búsquedas en nuestro buscador), y con unas horas de retraso, puede que algún dato también de Google Trends.

En ambos casos, es esencial “escuchar” en tiempo real y adaptarnos o ampliar información sobre la marcha para poder “hablar el idioma del usuario”.

Como podéis ver, elegir keywords a contrarreloj no es tarea sencilla, más aún sabiendo que, una vez elegida la keyword, tenemos que convencer a los periodistas (que en pleno breaking news tienen muchos frentes y no podrán dedicarnos mucho tiempo) de que lo mejor es utilizar esa keyword y no cualquier otra que ellos hayan pensado o vean más correcta periodísticamente. No hay que perder de vista que existe una línea editorial que seguir y muchas veces no es equivalente a cómo busca la gran masa.

Necesitamos pues, elegir rápido y elegir bien, y para eso precisamos de información.

Veamos un caso real sucedido en elmundo.es:

Benedicto XVI (el Papa por ese entonces)renuncia, y por lo tanto sabemos que se va a proceder a elegir un nuevo Papa.

Por suerte para nosotros, el anterior Papa se eligió en la era Google, por lo que podíamos ir hacia atrás y saber qué fue lo que se buscó cuando eligieron a Benedicto XVI. En este caso, al ser en 2005, teníamos que irnos a Google Trends, la única herramienta que nos da datos de hace tanto tiempo (a no ser que tuviésemos por aquel entonces las keywords por las que habían accedido los usuarios a elmundo.es, que no era el caso).

¿Qué se buscaba más? ¿Fumata blanca? ¿Nuevo Papa? ¿Habemus papa?¿El nombre original del nuevo Papa? ¿O el nuevo nombre al convertirse en papa? Simplemente nos vamos a Google Trends y lo sacamos:

Como se aprecia claramente, los nombres del antes y el después son lo más buscado (ratzinger, benedicto XVI), después nuevo papa y ya muy por debajo “habemus Papa” y “fumata blanca”. Con estos datos ya sabíamos en base a qué keywords teníamos que optimizar titulares de las noticias si queríamos maximizar el tráfico conseguido a través de buscadores.

Además de esto, al revisar la lista de keywords por las que estaban entrando los usuarios ese día, apareció en la lista “quién es el nuevo papa”, sin buscarlo intencionadamente. Se pidió a redacción redactar una noticia con este titular. Esa noticia terminó siendo una de las más leídas de ese día, y no sólo por tráfico obtenido a partir de buscadores, si no también por usuarios accediendo a la noticia desde el propio periódico. Básicamente, si había búsquedas en Google, había interés.

Un claro ejemplo de cómo el SEO realmente nos puede ayudar más allá de traer tráfico del propio buscador.

¿Qué pasaría si nos enfrentásemos a este mismo suceso un año más tarde? Pues que, con el aumento del (not provided) por parte de Google, tendríamos mucha menos muestra de keywords por las que entran los usuarios a nuestra web (o incluso ninguna si el ritmo de crecimiento de (not provided) sigue así) y puede que no llegásemos a ese tipo de casos. Además, no podríamos ratificar si la optimización SEO realmente dió sus frutos de la misma forma que antes.

2. ¿Cómo ha afectado el tráfico Not Provided a los medios?

Parece mentira que dentro de no mucho tiempo habrán pasado tres años desde que se hizo oficial por parte de Google la encriptación de las palabras clave de búsqueda Google, con la intención de proteger la confidencialidad y los datos de los usuarios logueados con sus cuentas. Abróchense los cinturones, manos en la nuca y la cabeza debajo del asiento delantero.

Si bien es cierto que este hecho impactó tremendamente en la industria del search y la analítica, hizo mella de una forma quizás más notable en los grandes medios de comunicación, o portales con contenido de carácter noticioso y más inmediato, sobre los que recaía la responsabilidad de buscar una alternativa factible a la pérdida de gran parte de las “pistas” que les permitían reconocer de qué forma definían sus lectores el contenido que consumían de sus noticias y en definitiva “aprender y descubrir” los temas que suscitaban un mayor interés.

Para los grandes medios la pérdida de este suculento dato ha supuesto un cambio de mentalidad, y, desde mi punto de vista supuso una obligación de “apertura de mente” para los especialistas en search y analítica, ya que poco a poco, mientras el porcentaje de tráfico Not Provided nos iba dejando ciegos, pequeños rayos de luz aparecían en forma de: sinergias más intensas con campañas de pago, colaboración con otros medios, desarrollo de estrategias en Real Time, y en definitiva, quizás se produce un mayor enfoque en el “aquí y ahora”, más que en saber “cómo mi lector ha encontrado mi noticia”.

3. ¿Qué alternativas se proponen para reducir su impacto en la operativa?

Y si algún día el tráfico Not Provided llega al 100%, ¿qué hacemos? Sin duda ésta fue una de las primeras preguntas que aparecieron en los pensamientos de muchos de nosotros.

Pues bien, a día de hoy, después de casi tres años podemos decir con la cabeza bien alta que superamos como podemos este bache del camino y hemos aprendido que existen alternativas bastante buenas para orientarnos en la búsqueda de las keywords utilizadas por los usuarios

Sinergias SEO y campañas de pago por click

No es ningún secreto. Prácticamente desde que se define el SEO se ha hablado del gran apoyo que suponen las campañas de PPC para descubrir y entender mejor el comportamiento que tienen los usuarios en los buscadores, siendo en este momento una sinergia totalmente fundamental.

Para quién no lo sepa, Google le pareció buena idea “esconder” la información de la palabra clave referida del buscador únicamente de los usuarios que accedieran a nuestro sitio web mediante resultados orgánicos, tomando la decisión de no aplicar el mismo castigo a los accesos desde campañas de PPC. Desde entonces surgió una gran controversia por parte de los especialistas en search e incluso de parte de los propios usuarios del buscador, que llegaron a tacharlos incluso con adjetivos de carácter hipócrita.

Por supuesto, Google ha estado muy al tanto de estas inquietudes y por este motivo, en el último congreso Search Marketing Expo (SMX West), uno de los máximos responsables y quizás actualmente el mejor conocedor del desarrollo del algoritmo de ordenación de resultados de búsqueda, Amit Singhal, se pronunció al respecto reconociendo la importancia de las opiniones de los usuarios sobre al respecto, y de alguna forma llegó a otorgar la razón y a comprender esa cierta “desconfianza”, e incluso comentó que en los próximos meses se verían cambios al respecto. Las preguntas eran claras, ¿volverán a ofrecer la palabra clave referida para los resultados orgánicos? ¿aplicarán la misma medida de encriptación del dato para los usuarios que vienen de anuncios de pago? Pues bien, finalmente parece ser que símplemente eliminarán la palabra clave de las URL referidas desde el buscador, por lo que quedarán afectadas principalmente las herramientas de analítica, pero podrán seguir viéndose a través de las campañas de Adwords o de cualquier herramienta que haga uso de su API.

El caso es que, aun así,  los grandes medios de comunicación siguen viendo clara la oportunidad de potenciar sus campañas de pago en buscadores para recuperar de alguna forma esa visibilidad.

Las ventajas ofrecidas por las campañas conjuntas de SEO y PPC aportan gran cantidad de beneficios. Además de la adquisición de tráfico, la campaña de PPC puede ser usada para mejorar la estrategia SEO gracias a los datos que nos reporta. Algunos de los beneficios que nos puede aportar incluyen:

• Testeo de la conversión de las palabras clave (Keyword Research): Las campañas de PPC ofrecen una mayor agilidad a la hora de descubrir y testear palabras clave, obteniendo información en minutos en vez de en meses, algo que en el mundo de los medios de comunicación es totalmente imprescindible. Puede ser usado para identificar qué palabras clave funcionan mejor, evitando tener que invertir grandes esfuerzos durante largos periodos de tiempo en la optimización de páginas por términos que realmente no podemos estimar de forma precisa si llegarán a obtener los resultados esperados.

• Testeo de de Landing Pages: Suele decirse que gracias al testeo A/B de diferentes páginas podemos determinar qué clase de presentación on site es más efectiva acorde con nuestro objetivo, para posteriormente hacer uso de la misma dentro de nuestra campaña SEO.

Si bien es cierto que existen algunas excepciones, generalmente esto no puede ser del todo fácil, ya que generalmente las páginas orientadas a SEO suelen ser mucho más largas, con grandes contenidos orientados a una o varias palabras clave y en caso de existir un funnel de conversión, se suele tratar de promover el “autodescubrimiento” por parte del usuario en el transcurso del proceso que le llevará a su objetivo. Sin embargo, las landing pages para PPC suelen tener una clara orientación a la acción inmediata, por lo que excepto en casos muy puntuales es raro ver sinergias claramente aplicables en este aspecto, al menos en medios de prensa.

• Obtener tráfico y conversiones por palabras de alta competencia: Prácticamente en cualquier sector existen algunos términos o frases que son muy competitivos, lo cual supone un gran desafío posicionar nuestras landing pages de forma orgánica, teniendo que pasar en algunos casos varios meses e incluso años. Una campaña de PPC te permite capturar ese tráfico de forma inmediata mientras que el trabajo SEO se construye y va haciendo efecto más lentamente.

• Visibilidad: Y es que en esto del marketing para buscadores, 1+1=3.Una campaña de PPC también puede ayudar a incrementar el tráfico y la visibilidad incluso cuando tenemos buen posicionamiento en resultados orgánicos por una palabra clave. Si tenemos en cuenta que generalmente los anuncios aparecerán en la parte más privilegiada de la página de resultados de búsqueda, capturar la posición primera o segunda  PPC y la primera en resultados orgánicos aumenta la visibilidad y en muchos casos mejora la confianza del usuario que busca, viéndolo desde su filtro como “el resultado que busco”.

Sin embargo, no es oro todo lo que reluce, y este punto tiene muchos matices, ya que también hay que prestar atención a la posible canibalización de clicks, sobre todo a nivel de marca. Pongamos sobre la mesa dos casos diferenciados:

1. Nadie está pujando por una palabra clave para la que posicionamos en orgánico en #1. Si únicamente nos anunciamos nosotros es posible que ese 1+1=3 se convierta en 1+1=1,5, o lo que es lo mismo, donde antes el 100% de los usuarios que entraban a nuestra web por ese término lo hacían “sin coste” para nosotros, ahora ese porcentaje se reparte, reduciendo nuestro retorno de la inversión.
2. Muchos anunciantes pujan por la misma palabra clave, y nosotros tenemos el resultado #1 en orgánico. En este caso posiblemente sea una gran oportunidad de canibalizar más a nuestros competidores que a nosotros.

¿Google Webmaster Tools como alternativa real para los grandes medios?

Si ahora mismo nuestro (not provided) estuviese al 100% y no tuviésemos ninguna información sobre las keywords que han utilizado los usuarios para llegar a nuestra web, la principal alternativa que tendríamos para ver esta información sería Webmaster Tools. Esta herramienta de Google nos da una lista de keywords por las que ha aparecido nuestra web en los resultados orgánicos del buscador y los clicks que ha recibido.

Aunque para la mayoría de webs pueda suponer una alternativa hasta cierto punto, en los medios la realidad es bastante distinta:

• • No hay tiempo real, ni siquiera tenemos los datos con unas horas de retraso. A día de hoy, los datos tardan un par de días en aparecer, por lo que para breaking news no nos van a ser de utilidad
  • No son precisos. Esto es un defecto de cara a cualquier web. Hay varios estudios demostrando que los datos en muchas ocasiones no se corresponden con la realidad de la web.
  • El módulo de Google News no se contabiliza: desgraciadamente, y por las comparaciones que he hecho, los clicks e impresiones de las noticias que aparecen en el módulo de Google News no se contabilizan aquí, por lo que de cara a breaking news nos limita un montón incluso a la hora de analizar a posteriori el impacto de nuestras acciones.

Sólo nos queda esperar que, si el (not provided) no es revertido en ningún momento, Google al menos mejore su herramienta.

El uso de herramientas y software de terceros como (SEMRush)

Siendo sinceros, a los que nos dedicamos al marketing online nos encantan las herramientas. A estas alturas posiblemente incluso sea imposible tan siquiera estimar la cantidad de recursos que existen para facilitar la gestión de nuestras campañas. Si, están muy bien, y en muchos casos nos ayudan con la pérdida de información de “datos reales” de los que disponíamos antes de la llegada del Not provided, pero debemos tener claro cuál es su uso en cada caso, ya que existe una gran diferencia.

Una de las alternativas que se plantearon como ayuda al Not Provided es el uso de herramientas de Rank Tracking o lo que es lo mismo, software que monitoriza de forma constante los resultados de búsqueda para distintos términos y nos ofrece información sobre sus movimientos en el tiempo y su volumen de búsquedas para que podamos “estimar” qué palabras clave pueden ser nuestro objetivo.

Este tipo de herramientas tienen una especial aplicación en portales muy grandes, ya que debido a la limitación de infraestructura por parte de las empresas que desarrollan este tipo de software, la frecuencia de rastreo y monitorización es mucho más real y constante en portales que atraen más usuarios. Por este motivo, la mayoría de los medios pueden obtener datos realmente suculentos de herramientas como SEMRush.

Este tipo de herramientas puede suponer una fuente de información muy relevante para los medios, ya que no sólo nos da una idea de qué términos nos están trayendo una mayor cantidad de tráfico actualmente, si no que podemos ver, mediante histórico, cómo fue el comportamiento de los usuarios y los rankings en una determinada fecha para así poder mejorar nuestra estrategia y orientación de keywords sobre las que vamos a trabajar.

Por ejemplo, en la imagen anterior, podemos ver como la herramienta nos permite “estimar” cuál será el comportamiento de los usuarios a la hora de buscar temas relacionados con las elecciones en 2015.

Otra de las funcionalidades que ofrecen estas herramientas suele ser el análisis de nuestros competidores.

Gracias a la gran capacidad de rastreo e indexación que tienen, podemos crear informes que comparan nuestras palabras clave orgánicas y las de nuestros competidores.

Con un poco de picardía, podemos filtrar los resultados ofrecidos por la herramienta de tal forma que obtengamos en pocos minutos, información tan valiosa sobre por ejemplo, por qué términos de gran volumen está posicionando la competencia y nosotros no, y así poder elaborar una estrategia para cambiar esto.

Si sumamos esto a la capacidad de “retroceder en el tiempo” podemos incluso ver cómo se desarrolló, en términos de competencia una determinada campaña o noticia de última hora.

4. Futuro del (not provided) en los medios

A pesar de todas estas alternativas, los datos con los que contamos siguen siendo mucho menos completos que cuando teníamos todas nuestras keywords directamente en la herramienta de anal´ (podemos obtener las keywords de otra fuentes, pero si necesitamos conocer también el comportamiento del usuario por keyword las cosas se complican). Y además, en relación al impacto en los medios del real-time, las herramientas nos limitan mucho más.

Lo que es seguro es que seguiremos buscando la forma de obtener la mayor cantidad de información posible para tratar de maximizar el tráfico SEO. Una de las fuentes que creemos que nos puede dar pistas sobre la terminología de los usuarios son las redes sociales. Por ejemplo, si conseguimos analizar en tiempo real los tweets respecto a una temática o acontecimiento X, podemos comparar cuáles son los términos que más se están utilizando y estar un poco menos “ciegos” en nuestra optimización.

O quizás Google da marcha atrás y nos devuelve esta jugosa información :) Ojalá!

La entrada Cómo afecta el (not provided) al SEO en medios de comunicación aparece primero en Blog de Christian Oliveira.

Por cierto, han salido ya las entradas para la edición 2013, que se hará en Valladolid, puedes comprarlas aquí)

Si te interesa el tema de la eXperiencia de Usuario (UX), probablemente este no sea el primer post que lees acerca del Uxspain 2012, por lo que más que volcar aquí el contenido resumido de los dos días de ponencias, dejo mis impresiones desde un punto de vista de alguien que “no se dedica” al UX y que asistió al evento.

 Lo positivo

• Público multidisciplinar: normalmente los eventos grandes que se hacen centrados en un sector o disciplina concretos, acaban teniendo un público también únicamente de ese sector. En cambio, en UXSpain había público de todo tipo (negocio, marketing, desarrollo, diseño…).
• Algunas charlas multidisciplinares: se habló de UX+Negocio, se habló de UX+Desarrollo Ágil y como trabajar con los desarrolladores, se habló de UX+Emprendimiento… Me parece esencial que se haga esto en cualquier evento sea del sector que sea. Hay que ver “the whole picture” y no cerrarse sólo en nuestra área de trabajo.
• Organización: de 10! El wifi, los horarios, la comida, el pack de bienvenida, … Nos trataron como reyes, lo cual siempre se agradece. Mención especial a las “rubias de las camisetas verdes” :D
• Juntar a tanta gente: es difícil organizar un evento en una ciudad que no sea Madrid o Barcelona y atraer a tanta gente durante un fin de semana. Esto me ha permitido conocer gente nueva y ver a otra que hacía tiempo que no veía.

Lo no tan positivo

• La falta de casos prácticos: me hubiera gustado ver casos reales de trabajos de UX, qué problema se tenía qué solucionar, qué tipo de investigación y planteamiento del problema se hizo y en qué resultó (éxito o fracaso, y por qué). Durante la mesa redonda del primer día salió el tema de compartir información, y al parecer había gente a favor del secretismo, lo cuál me parece bastante grave; creo que internet es lo que es y estamos dónde estamos gracias al espíritu de compartir. La cantidad de recursos gratuitos que nos podemos encontrar online es enorme, y creo que a cambio todos tenemos que intentar aportar algo de vuelta.
• La falta de una cultura de medición en el sector UX: parece que se va hablando cada vez más de que hay que medir pero que poca gente lo hace. Creo que es algo esencial, para evaluar correctamente el éxito/fracaso y para poder basar las decisiones en datos. (Como dice la tarjeta de los chicos de Ducksboard: http://awe.sm/5q4ak)
• El “desprecio” de algunos ponentes/participantes hacia otras áreas (ya sea desarrollo, negocio, seo…). Bueno, más que despreciar, digamos subestimar. Todas las áreas aportan su granito de arena a cada proyecto y hay que saber respetar el trabajo de los demás, saber entenderse/comunicarse y tener muy claro el objetivo final del proyecto para que todas las áreas remen en la misma dirección.

Con todo lo bueno y lo “no tan bueno”, creo que es un punto de partida genial para el sector y que el año que viene, con todo este feedback que están recibiendo, harán un eventazo.

Estaría genial que más gente de UX se acercase a eventos como Betabeers para compartir conocimiento, puntos de vista, y dar tips :)

La entrada Resumen del UXSpain 2012 en Salamanca aparece primero en Blog de Christian Oliveira.

En la versión antigua, existía un pequeño «truco» para poder exportar hasta un máximo de 50.000 20.000 filas (gracias Soraya por notificarlo en los comentarios. Antes eran 50.000). Este consistía en añadir, a mano, el parámetro «limit» en la URL indicando el número de filas máximo que queremos exportar (por ejemplo, para exportar 20.000 filas, añadíamos a la URL “&limit=20000”), click en la tecla «Enter» y aunque nada pasaba en la interfaz, clickando luego en «Exportar -> CSV» obteníamos un fichero .csv con los 20.000 resultados (ninguno de los otros formatos lo permitía).

Sin embargo, en la nueva versión de Analytics esto ha cambiado. Sigue existiendo una forma de exportar hasta 20.000 resultados pero ha cambiado el parámetro a utilizar. Ahora el procedimiento es el siguiente:

1. Accedemos al informe del cuál queremos exportar más de 500 filas
2. Cambiamos el número de filas a mostrar de 10 al número que nos de la gana entre los disponibles (esto hará que en la URL aparezca el parámetro que define el número de resultados a mostrar) :
3. En la URL, buscamos el parámetro explorer-table.rowCount%3Dx (dónde ‘x’ es el número que hemos elegido en el menú desplegable de «Mostrar filas: «, en este caso, 25):  
4. Modificamos ‘x’ por el número de filas que queramos exportar. Por ejemplo, para 20.000 quedaría explorer-table.rowCount%3D20000. En el ejemplo, tenemos un total de 558 filas así que, como las queremos exportar todas, quedaría así: 
5. Presionamos la tecla «Enter». El problema de este método, es que, a diferencia de la anterior versión de Google Analytics, carga en pantalla (en el informe) el número de filas que ahí pongamos. Esto quiere decir que si ponemos 20.000, va a tardar un rato y dependiendo de la potencia de nuestro ordenador, nos dejará el navegador prácticamente «muerto» durante un rato más o menos largo (el firefox por ejemplo con un pc no muy potente se queda frito durante este tiempo). Una vez que termine, veremos que se han cargado todas esas filas directamente en el informe:   
6. Sólo nos queda ir a «Exportar» y seleccionar cualquiera de los formatos (en la nueva versión de google analytics, a diferencia de la anterior, sí nos vale cualquiera de ellos):

Cómo puedes ver, el método sigue siendo bastante similar al de la versión anterior, pero en mi opinión sigue siendo un engorro; no les costaba nada añadir una opción a la hora de exportar en la que especificar el número de resultados que queremos, así nos evitaríamos todo este proceso y el hecho de tener que esperar a que el navegador cargue todos esos datos para mostrar por pantalla (algo inútil ya que lo que queremos es exportarlos para verlos en una hoja de cálculo, no en pantalla). También echo en falta (tanto aquí como en cualquier de los servicios de Google que permite exportar datos – Webmasters Tools, Adwords Keyword Tool, etc.) una opción de «Abrir en una hoja de cálculo de Google Docs».

Más información:

• Para la nueva versión de Analytics: Documentación oficial de Google sobre exportación y mailing de informes – click en «To export more than 500 Rows of Data:» (basado en mis intentos está mal la documentación, los pasos 4 y 5 no son ciertos; eso pasaba en la versión antigua – tiene toda la pinta de ser un copy+paste…)
• Para la anterior versión de Analytics: ¿Cómo exporta más de 500 filas de datos de un informe?

La entrada Cómo exportar más de 500 filas en el nuevo Google Analytics aparece primero en Blog de Christian Oliveira.