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
Accelerated Mobile Pages Project 