In the world of publishing, understanding your audience is at the heart of writing the right stories, creating loyal readers, and improving the bottom line. Key to unlocking that information is access to tools that enable measuring your audience and understanding their behavior. We believe it’s important that AMP support those tools. However, we also think the state we’ve reached in this area on the web today is broken, and that AMP can provide a path to an improved approach.
An approach that improves performance
One pattern we often see in mobile web pages is that multiple analytics vendors’ tags are installed on the same page. While each analytics package provides a unique and insightful view of a publisher’s audience, this client-side duplication of effort has led to degraded performance, as each tracker independently performs many of the same measurements. These many little costs can add up to poor experiences that cause readers (and potential readers) to abandon pages.
We approached building AMP analytics with a “measure once, report to many” philosophy. What this means is that you can use amp-analytics to configure multiple endpoints and data sets. AMP then manages all of the instrumentation to come up with the data specified and shares it with all of your analytics providers. No matter how many analytics providers are configured, the AMP runtime will only ever do a single measurement to come up with a value. This improves performance by reducing duplication of effort, batching network requests, and streamlining code paths.
In this post we’d like to introduce to you the two components we’ve built to support analytics and measurement in AMP: amp-pixel and amp-analytics.
amp-pixel
A core built-in component, amp-pixel provides page view tracking that’s meant to emulate a tracking pixel. Here’s an example of amp-pixel markup:
<amp-pixel src="https://foo.com/pixel?RANDOM"></amp-pixel>
When amp-pixel is rendered, it sends a GET request to the specified URL such as https://foo.com/pixel?RANDOM. Note that this request can contain data values that the page author is interested in capturing. In the example above, “RANDOM” indicates that a substituted value should be used, so the request that’s actually sent might be something like https://foo.com/pixel?0.8390278471201.
Both amp-pixel and the next component I’ll discuss, amp-analytics, support several variable substitutions like “RANDOM”. These can be used to convey data like the document referrer, page title, screen size values, or a client identifier managed by AMP. You can learn more about the available substitutions by consulting the documentation.
amp-analytics
amp-analytics is a more complex but powerful solution that supports many types of event triggers to help publishers better understand their audiences. We received incredibly valuable feedback from our discussions with publishers and measurement companies while building analytics solutions for AMP. These conversations helped us learn about the many and varied data needs that publishers have and how they leverage the data to meet business and product goals.
Here’s an example of amp-analytics markup:
<amp-analytics> <script type="application/json"> { "requests": { "pageview": "https://example.com/analytics?url=${canonicalUrl}&title=${title}&acct=${account}", "event": "https://example.com/analytics?eid=${eventId}&elab=${eventLabel}&acct=${account}" }, "vars": { "account": "ABC123" }, "triggers": { "trackPageview": { "on": "visible", "request": "pageview" }, "trackAnchorClicks": { "on": "click", "selector": "a", "request": "event", "vars": { "eventId": "42", "eventLabel": "clicked on a link" } } } } </script> </amp-analytics>
Using amp-analytics, page authors can specify hit requests that will fire on events like the page becoming visible or on a click. Click events can be customized to apply to certain element IDs or classes by specifying a selector. In the example above, there are two triggers defined. One is intended to track pageviews and will fire the defined “pageview” request when the document becomes visible. The other trigger tracks anchor clicks by specifying that the “event” request should be fired, but only on “a” (or anchor) elements.
amp-analytics can be further customized to specify transport handling for requests and can be remotely configured by specifying a URL where some configuration JSON lives. As with amp-pixel, amp-analytics supports a number of variable substitutions so that AMP can provide data values that it’s aware of. You can learn more about these in the documentation.
Getting data to where it needs to go
Finally, once you’ve determined what data you want to collect and AMP has a way collect it, you need a place to send it.
We prioritized supporting integration with publishers’ in-house analytics systems as well as offering an integration path with third-party vendors. When using either amp-pixel or amp-analytics, the page author specifies where data should be sent, which could be to the publisher’s own server or to its vendor of choice.
We also wanted to enable a streamlined approach to configuring an amp-analytics tag that would transmit data to a vendor. The solution we came up with allows a publisher to specify the vendor they wish to use and to not have to worry about including the boilerplate configuration that would be specific to that vendor. To enable this, the vendor must supply configuration as open-source code in the AMP library, which causes this configuration to be applied consistently across all of their customers’ integrations.
Much more to come
When we unveiled the Developer Preview for AMP in October 2015, the only analytics support we had was amp-pixel. With the support and feedback of many in the publishing and analytics industries, we’ve come a long way from there, having built amp-analytics to meet more complex and challenging demands. We know the work’s not done yet and look forward to continuing our engagement with these communities to build the many exciting and useful features on our roadmap.
Please use the resources linked from this article to get your analytics integration in AMP started. For any feedback or new feature requests, please let us know by filing an issue in our GitHub repository.
Finally, if you’re a member of an analytics company that’s interested in providing default configuration values for your customers as described above, please read our contributing guidelines and get in touch through GitHub. We welcome your insight and expertise, and are grateful for your support.
Posted by Rudy Galfi, Product Manager for Accelerated Mobile Pages
Join us for a Hangout on Air covering AMP Analytics on February 5 at 9am PT, hosted by the Google News Lab.