Rolling Out the Red Carpet for Interactives in AMP

As the AMP Project grows we’d like to shine a spotlight on how people use AMP HTML to tell rich interactive stories on the mobile web. Over time, we’ll start sharing some of our favorites on this blog.

Today the team at Google Trends takes the stage to share a new Oscars Trends editorial built using AMP.

horserace_amp

In the editorial, Simon Rogers, a data editor at Google News Lab, takes readers into Google Trends data showcasing what the most frequently searched Oscar-related terms are and which nominees they think will win based on search popularity.

“When we set out to build our first AMP article, we honestly thought it was going to be pretty difficult to get our data-heavy visualizations into the AMP format. But we were pleasantly surprised – they “just worked” inside the iframe. We had some questions along the way and the help pages walked us through it with sample code to test. Half an hour later our AMP page was looking great and our graphics fully interactive.” – Lisa Creed (Product Manager on Google Trends)

We hope you get to take a look at the Oscars editorial and are looking forward to continuing to showcase our favorite stories built using AMP.

Posted by Rudy Galfi, Product Manager for Accelerated Mobile Pages

Rolling Out the Red Carpet for Interactives in AMP

AMPing Up in Google Search

Access to information is at the heart of Google’s mission. Unfortunately, today, the mobile web isn’t living up to the expectations people have for getting the information they need, particularly when it comes to speed. In fact, data shows that people abandon websites after just three seconds if the content doesn’t load quickly—which is bad not just for people trying to get what they want online, but for the publishers who want those readers to enjoy the content they’ve created for them. That’s why, last October, we joined others across the industry on the Accelerated Mobile Pages Project(AMP for short), an open source initiative to make the mobile web as fast as possible.

In just over four months, AMP has come a long way, with hundreds of publishers, scores of technology companies and ad-tech businesses all taking part in this joint mission to improve the mobile web for everyone. And starting today, we’ll make it easy to find AMP webpages in relevant mobile search results, giving you a lightning-fast reading experience for top stories.

Now when you search for a story or topic on Google from a mobile device, webpages created using AMP will appear when relevant in the Top Stories section of the search results page. Any story you choose to read will load blazingly fast—and it’s easy to scroll through the article without it taking forever to load or jumping all around as you read. It’s also easy to quickly flip through the search results just by swiping from one full-page AMP story to the next.

AMP is great for browsing the web on mobile devices, because webpages built with AMP load an average of four times faster and use 10 times less data than equivalent non-AMP pages. In many cases, they’ll load instantly. It’s how reading on the mobile web should be—fast, responsive and fun.

While helping people find fast AMP content through Google Search is a significant step, there’s still a lot of work ahead for the open source AMP Project. Still, it’s been thrilling to see how the industry has come together to work on this common goal of making the mobile web great for everyone. And given the potential AMP holds for other types of content, we’re excited about what the future holds.

AMPing Up in Google Search

Adobe Analytics for the Accelerated Mobile Pages Project

If you haven’t yet heard about the Accelerated Mobile Pages (AMP) Project, it is a really ambitious initiative focused on one goal: creating a better, faster mobile web for publishers.  Naturally, when we heard the announcement, we were excited to participate in the project since we know that for publishers, Adobe Analytics has become a fundamental part of understanding audiences, creating loyal viewers, and monetizing content.  We’re committed to making sure that our publishers have access to the best data possible, and we wanted to be sure AMPs were no exception.

As of today, we’re pleased to announce that we have a great strategy to implement Adobe Analytics on AMPs that provides blazing speed to end users, and great Adobe Analytics capabilities for publishers.

How it works

To start, AMPs basically work by having specially tagged HTML pages cached all around the web on many different content delivery networks (CDNs) of participating technology partners and publishers. By doing this, AMP content is delivered from the closest possible source with the lowest possible latency.  This creates an analytics challenge because you can never be 100% sure where a publisher’s content will be loaded from, and third party cookies are troublesome for visitor identification.

In addition, in order to dramatically reduce page weight and speed up page load time, AMPs heavily restrict the use of JavaScript and cookies.  While this is awesome for your mobile device because it reduces the amount of processing it has to do, it introduces challenges to accurately measuring unique visitors and understanding user acquisition and retention

To solve these problems, we’ve collaborated with AMP partners and publishers on two options that a publisher can choose from to best suit their business needs using the <amp-analytics> tag or the <amp-iframe> tag.  This table should give you an idea of the pros and cons of each approach.

<amp-analytics> <amp-iframe>
Visitor/visit counts (in existing report suite) High inflation Minimal inflation
Using a separate report suite Recommended Not necessary
New vs. return visitors Not supported Supported
Visitor ID Service Not supported Supported
Video & link tracking Partial support Not yet supported
Difficulty of implementation Relatively hard Relatively easy
Marketing Cloud integrations Not supported Supported with caveats

Read on for details and an explanation of each tradeoff. 

Using the <amp-analytics> tag

The amp-analytics tag is the AMP Project’s cookie cutter approach to installing analytics on AMPs.  Using amp-analytics, you can specify hit requests that will fire on specific page events like the page becoming visible or on a click (and in the future video views and more).  Click events can be customized to apply to certain element IDs or classes by specifying a selector.  In the example below, there are two triggers defined – “pageLoad” and “click”.  The “pageLoad” trigger will fire when the document becomes visible and will include the pageName variable as defined in the “vars” section.  The second trigger “click” will fire when a button is clicked.  eVar 1 will be set for this event with the value “button clicked”. 

  <amp-analytics>

  {
    “transport”: {“xhrpost”: false, “beacon”: true},
    “requests”: {
      “base”: “https://${trackingServer}/b/ss/${accounts}/1/AMP-0.1/s${random}”,
      “pageView”: “${base}?AQB=1&vid=CLIENT_ID(adobe_amp_id)&pageName=${pageName}&j=amp&AQE=1”,
      “buttonClick”: “${base}?AQB=1&vid=CLIENT_ID(adobe_amp_id)&pageName=${pageName}&j=amp&pe=lnk_o&v1=${eVar1}&AQE=1”
  },
  “vars”: {
      “trackingServer”: “metrics.example.com”,
      “accounts”: “reportSuiteID”,
      “pageName”: “Adobe Analytics Using amp-analytics tag”
  },
    “triggers”: {
      “pageLoad”: {
        “on”: “visible”,
        “request”: “pageView”
      },
      “click”: {
        “on”: “click”,
        “selector”: “button”,
        “request”: “buttonClick”,
        “vars”: {
          “eVar1”: “button clicked”
        }
      }
    }
  }

  </amp-analytics> 

Notice that inside the “click” trigger you can specify a selector to make sure that whenever the button is pressed, the “buttonClick” request is fired and the “pe=lnk_o” query string parameter is set to denote this hit as a non-page event (i.e. trackLink call).  Additionally, amp-analytics supports a number of variable substitutions so that AMP can provide data values that it’s aware of.  You can learn all about those and more by visiting the amp-analytics documentation.  Be aware that if you want to incorporate any technology or DOM variables (such as browser, screen size, device, referrer, etc.) you will have to explicitly add them to any request yourself as they are not automatically generated for you.  Documentation on each of our available query string parameters used for tracking can be found here.  Also make sure that the query string end marker, or “AQE” parameter is the last one in the URL.  It tells our tracking servers that the hit is complete, so you don’t want that query string parameter to show up too early in the URL or the rest of the data will get truncated.

Finally, notice that in each request, we’ve included “vid=CLIENT_ID(adobe_amp_id)”.   This is a built in AMP function we use to set a custom Analytics cookie ID named “adobe_amp_id”.  The value passed into CLIENT_ID can be anything you want, however, it is critically important that you do not set this to any Analytics-specific cookie name (like “s_vi” for example) because it could potentially corrupt your regular tracking.

There are a few caveats to be aware of.  It’s important to note that when using the amp-analytics tag, visitors will be totally independent of your normal tracking, and because the AMP can be loaded from any content delivery network, you will get a unique visitor for each and every CDN a visitor sees this AMP on, hence the visitor inflation mentioned earlier.  For this reason, we recommend that if you use amp-analytics, you put your data into a separate report suite specific to AMP.  Also, the Visitor ID Service is obviously not supported using this method, so if your business requires additional marketing cloud integrations or will in the future, this is probably not the option for you.

Finally, and perhaps most importantly, this amp-analytics solution requires that the tracking server you specify in the “vars” section matches the tracking server on your main site so that your existing privacy policy controls will be respected.  Otherwise, you’ll need to create an entirely separate privacy policy just for AMPs.

Using the <amp-iframe> tag

The amp-iframe tag is much easier to implement, but does require you to host a lightweight utility page and a 1 by 1 transparent gif on your existing server that will be referenced by the amp-iframe tag.  To accomplish this, simply add the following to the top of your AMP body, substituting the example path with the path to your utility page:

<amp-iframe width=1 height=1
src=”https://ampmetrics.publishersite.com/stats.html?pageName=Adobe+Analytics+Example+2″
sandbox=”allow-scripts allow-same-origin”
layout=”fixed”
frameborder=”0″>
<amp-img src=”https://ampmetrics.publishersite.com/pixel.gif” height=1 width=1 layout=”fill” placeholder></amp-img>
</amp-iframe>

Notice that on the src attribute of the amp-iframe, we’ve included a query string parameter “pageName”.  This query string parameter can be named whatever you like and is used to pass the applicable tracking data to the utility page.  The utility page (named “stats.html” in our example) looks like this:

Stats Test
http://”VisitorAPI.js”
http://”AppMeasurement.js”

var v_orgId = “1234567@AdobeOrg”;

var s_account = “reportSuite”;
var s_trackingServer = “metrics.publisher.com”;
var s_visitorNamespace = “publisherNamespace”;

var visitor = Visitor.getInstance(v_orgId);
visitor.trackingServer = s_trackingServer;

var s = s_gi(s_account);
s.account = s_account;
s.trackingServer = s_trackingServer;
s.visitorNamespace = s_visitorNamespace;
s.visitor = Visitor.getInstance(s_visitorNamespace);
s.pagename = s.Util.getQueryParam(“pageName”);
s.prop10= “AMP”; //designate AMPs in some variable for segmentation and reporting
s.t();

As shown above, simply link to your existing VisitorAPI.js and/or AppMeasurement.js, add the correct configuration parameters, and you’re all setup.  To capture the correct values into the correct variables, you can use the provided s.Util.getQueryParam function to grab the value that you passed in from the amp-iframe src attribute and set the appropriate variables just as you would on a typical page.  In this case, s.pageName is set to the value we passed in the query string parameter “pageName”.  Here, the page name would be set to “Adobe Analytics Example 2”.  Easy right?

Because the utility page is hosted on your original site, no additional work is needed to support your existing privacy policy across all AMPs.  This means if an end user has opted out of tracking on your primary site, they will also be opted out of tracking on all your AMPs, no additional steps required.  Using this utility page also means that we’re able to support Adobe’s Visitor ID Service so that you can integrate the measurement captured on your AMPs with the rest of the marketing cloud (for targeted advertising using Adobe Audience Manager for example).

As a side note, if your organization is not yet using the Visitor ID Service (or has tag management software you love like Adobe’s Dynamic Tag Manager), you can tag the stats.html page however you want, just use your existing implementation as a reference point.  The only difference from your standard implementation is that you’ll grab the applicable data points from the amp-iframe page URL (or document.URL) for each of the variables you want to set.

As flexible as this solution is, there are caveats to be aware of.  Due to inherent restrictions in the amp-iframe, it can only be loaded on a page load once.  This means you won’t be able to do link tracking or video tracking with the amp-iframe solution.  Moreover, some DOM values that are typically only accessible via JavaScript on the AMP such as referrer (which impacts the search engine keyword reports, referrer and referrer type reports, or may include a marketing campaign tracking code) will not be possible to pass into the amp-iframe for tracking.  For this reason, we recommend setting a custom variable with the value “AMP” so that you can segment out AMP traffic when viewing the aforementioned reports.  That said, standard technology reports such as browser, device, screen size or resolution should work fine and the AMP pageURL can be obtained by referencing document.referrer from your utility page.

Finally, because the iframe will load as a separate page and will fully execute the JavaScript on that page, the AMP will not be as lightweight as the AMP standard intended.  To be very clear, this will not affect page load time (the iframe loads after the page is done loading), but the CPU and network will be doing slightly more than they would have to otherwise, which might impact scrolling smoothness, at least in theory.  In practice we have not seen a huge impact, but we’re working with Google to minimize the user experience impact of this approach.

Conclusion

In review, if you need click tracking and don’t mind visitors being counted as entirely new visitors separate from your site, use the amp-analytics solution with our recommendation that you should put the data into a separate report suite.  If you need the Visitor ID Service, do not want visitor/visit inflation, and are ok with only firing Analytics on page load we recommend using the amp-iframe solution.

Adobe Analytics is excited to partner with Google and our publishers to bring industry leading analytics capabilities to publishers on the mobile web in a blazing fast user experience.  Although these two solutions currently offer their own tradeoffs, we are committed to building the best long term solution to answer the evolving analytics needs our customers have.

The AMP Project is moving fast and changes are happening all the time, so check back here frequently for updates to our examples!  What we’ve shown you here should be enough to get started, but expect changes as we improve our integrations further and as more publishers adopt AMP over time.

If you have questions or problems, please reach out to your Adobe Consultant or Customer Care.  Happy AMPing!

Frequently Asked Questions 

Q: Is video tracking available to either the amp-analytics or amp-iframe approach?

A: Unfortunately, not yet.  The AMP standard only supports triggers for “visible”, “click”, and “timer”, and does not yet support explicit triggers for video tracking that can be listened to by the amp-analytics tag.  Also, because the amp-iframe tag can only be loaded once, it’s not compatible with video viewing which occurs after the AMP has loaded.

Q: You mention that visitor inflation is “lower” for the amp-iframe solution in your comparison.  What does that mean?  What would cause visitor inflation in the amp-iframe solution?

A: There is only one scenario where visitor/visit inflation will occur: A visitor using Safari that has never been to publisher.com’s site visits an AMP page for the first time, then later visits publisher.com’s normal (non-AMP) site.  In this scenario, the visitor would be counted as two visitors in Analytics assuming the AMP and the main site are in the same report suite.  However, if the visitor had been to publisher.com’s main site before visiting the AMP, it will still count as only one visitor in reporting.

Q: Should I use a separate report suite for AMPs?

A: We recommend using a separate report suite for AMPs if you use the amp-analytics approach because of the visitor/visit inflation issue.  However, we will also set the javascript version to “AMP vX.X” from the amp-analytics tag so that you can segment that traffic out of a combined report suite if necessary.

Q: What is the Visitor ID Service?  Do I need it?

A: The Visitor ID Service is what allows integrations between different Adobe Marketing Cloud solutions.  If you have integrations with Adobe Audience Manager or Adobe Target, you are likely using the Visitor ID Service.  The Visitor ID Service is also the foundation for many cool upcoming Analytics features.  If you need Visitor ID Service support or will need it in the future, we recommend using the amp-iframe solution.

Q: For the amp-iframe solution, where should I host my utility page?

A: The AMP standard does not allow for iframes to load from the exact domain and subdomain of the AMP itself.  Due to this, we recommend that you host the utility page on a separate subdomain from your main site, especially if your company has their own CDN that plans on caching AMPs. For maximum compatibility, pick a subdomain such as “ampmetrics.publisher.com” that is apart from where the actual AMP content will reside.

Q: Isn’t this similar to Facebook Instant Articles?  How do I setup Adobe Analytics with Facebook Instant Articles?

A: We’re still working on this one, so stay tuned.  Currently Facebook supports a similar solution to the amp-iframe as outlined above.  We’re working to thoroughly test the solution, but with a little work, you should be able to leverage the work you do here using the amp-iframe solution with Facebook Instant.

Posted by Trevor Paulsen, Product Manager, Adobe

Adobe Analytics for the Accelerated Mobile Pages Project

AMP: Supporting Paywalls and Subscriptions

The AMP Project is about making the mobile web great for users, content publishers, and technology players to create a better ecosystem. A key aspect of that is to ensure publishers producing high quality content can leverage their existing business models with AMP. For many, this means supporting logged-in subscriber access while allowing anonymous users to get a taste of premium content. This could be as simple as a user being able to access a few articles for free each month, or something a lot more complex like having a user go from sampling a few stories to signing up and subscribing to paid content. Enabling these business models in a world where content can be distributed widely and is expected to render instantly is critical to the AMP Project’s success.

Since the announcement four months ago, the publisher and technology community has been busy working together to find creative, extensible solutions that support publisher business models of today, as well as enable innovation, experimentation, and flexibility to try out new approaches to content distribution and subscription-supported publishing of the future.

The challenge: Every paywall is unique

One of the great challenges to designing a paywall solution is the wide range of strategies that publishers employ to control access to their content. There are different identity and authentication systems and many approaches to user management and access control. In addition there are a host of different payment options, subscription product offerings, single sign-on solutions, geo restrictions, etc. With AMP, pages need to be able to load on any domain (e.g. a publisher.com AMP page can load on google.com) in a secure manner while preserving user privacy. The lack of commonality in how various publishers achieve these objectives today meant that it was very hard to build a unified system within AMP for addressing all of these needs.

The solution: AMP proposes, Publisher disposes

Working with publishers was critical to the Project’s efforts, and the past 3 months have seen some amazing collaboration between publishers and technologists from all over the world.

“Paywalls are one of the most complicated experiences to build in digital media today, especially on mobile. At The Post, we built out our own system so we could easily tweak and optimize our model and experience based on what we learned from readers. It was great to work with the AMP team and broader publishing community to coalesce around a flexible system that would allow us to implement the rules we need to for our business and retain the ability to change them as we need.”

– Julia Beizer, Director of Product, The Washington Post

For many, this was new territory, and the open exchange of ideas and discussion of issues helped arrive at a set of principles to guide the solution:

  • Users should be able to access content instantly, anywhere. When needed, they should be able to log in securely to a trusted source. The user experience on AMP should be seamless.
  • Publishers should be able to decide how their content is distributed – in particular, at the very granular level of which user sees which article based on which conditions. Publishers already have complex systems to address these variations, so re-using these systems would be both effective and efficient.
  • Surfaces that display AMPs (websites, apps, platforms) should not have to deal with additional complexity arising from subscriptions and paywalls. In fact, the surface should have little knowledge of the fact that the page is paywalled or subscription controlled.
  • The solution should be open-source, in keeping with the philosophy of AMP.

With these principles in mind, we designed a solution based on an orchestration between the publisher, the document, and the AMP Runtime:

  • Paywalled and subscription documents have special AMP markup to indicate sections that are visible to different types of users, such as anonymous vs. subscribers.
  • When the AMP document loads, the AMP Runtime asks the Publisher for instructions on how to show the document, which the publisher typically bases on the user type.
  • The AMP Runtime puts together the publisher instructions with the document markup to show the user exactly what the publisher intended. For instance, this could mean showing full content to a subscriber, a metering message to an anonymous user, or a snippet followed by a subscription upsell message to a user who has exhausted their metered quota.
  • In cases where the document asks the user to log in or sign up, the user is taken to the publisher’s website to complete this process. This keeps the publisher in control of its  users’ data and any related financial transactions.

We spent many hours with the Google AMP team trading ideas about how to design a sustainable subscription model that worked within the AMP experience. Our months of collaborative and creative work have ensured a great experience for our readers on AMP pages and at the same time support our business goals by directly integrating AMP with our metered subscription model.

– Kate Harris, Product Director, Mobile at the New York Times

This solution is now available as part of the AMP project, with documentation and examples on GitHub to help publishers get started.

“AMP’s paywall implementation is crucial for publishers of quality contents. Google’s AMP team has come up with a system able to address most of the configurations, from metered paywall to freemium models. From the parameters of the conversion mechanism to the rendering of a page served to a subscriber, the whole system can be fine-tuned in multiple ways. This should vastly improve the potential for  monetization as roughly half of the audiences have now shifted to mobile.”

– Frederic Filloux, editor of Monday Note and part of the DNI Publishers’ Working Group on behalf Groupe Les Echos (France)  

Going Forward: : Continuing to enhance access and discoverability for subscription content

While the AMP Project collaboration has resulted in a strong foundational approach, there is still a lot of work ahead to move premium monetization beyond the status quo. We believe the AMP Project will fundamentally change how users discover and consume content, and we’re hard at work as an industry to  make subscription content a first-class citizen in this journey.

Posted by Ashwin Limaye, Product Manager for Accelerated Mobile Pages

Join us for a Hangout on Air covering AMP Paywalls on February 12 at 9am PT, hosted by the Google News Lab.

AMP: Supporting Paywalls and Subscriptions

All You Ever Wanted to Know about AMP

Ask Product Managers & Engineers your AMP questions live

Accelerated Mobile Pages (AMP) is a global, industry-wide initiative, with publishers large and small all focused on the same goal: a better, faster mobile web. The project launched just five months ago, but from the level of interest, we know that many people have questions to help get them up to speed.

That’s why we’ve planned a series of Hangouts on Air that invites everyone all over the world to learn about AMP. Product Managers and Engineers from Google will answer your questions every Friday until AMP launches in Search in late February.

We kicked off the “Office Hours” with Richard Gingras, Head of News @ Google, on January 19. Publications like The Guardian joined the Hangouts to discuss their implementation of AMP files, and technology companies like WordPress joined to announce their support of AMP with a WordPress plug-in.

Over the next few weeks, we will subsequently dive into the technical specs and various components of AMP including Analytics, Paywalls, Ads, and Format Innovation. Check out the lineup of the next Friday hangouts:

  • Feb 5- Analytics in AMP; Rudy Galfi, Product Manager [Event | Blog post]
  • Feb 12- Paywalls in AMP; Ashwin Limaye, Product Manager [Event]
  • Feb 19- Ads in AMP; Craig DiNatali, Director of Ads; [Event | Blog post]
  • Feb 26- Format Innovation in AMP; Rudy Galfi, Product Manager [Event]

You can watch recordings of the previous Hangouts:

  • AMP- the Vision; Richard Gingras, Head of News @ Google [Recording]
  • What is AMP?; Emeric Studer, Technology Manager [Recording]
  • AMP’s Anatomy; Malte Ubl, AMP Technical Lead [Recording | Blog post]

What are publishers asking?

Hundreds have watched the Hangouts live, and we’ve received dozens of questions from publishers from India to Italy and Sweden to Singapore:

“How can AMP integrate with already responsive designed sites? How “open” is AMP, and how can our developers stay up-to-date on changes to AMP specs?” Stephan Fowler, The Guardian

“What ad networks are going to support AMP? Is there a list that will be published soon?” Julie Westfall, Los Angeles Times

“How can smaller sites leverage AMP with fewer sources and use AMP to generate more revenue?” Scott Leadingham, Society of Professional Journalists

Join the conversation and ask your question in the comments section of the Hangout on Air, and the Product Manager or Engineer will answer your question live.

We hope to see you at the next AMP Hangout on Air!

Posted by Stacie Chan (Search Partnerships Manager) and Nicholas Whitaker (Media Outreach Manager @ Google News Lab)

All You Ever Wanted to Know about AMP