This article was born out of sheer frustration. I had a) never implemented on AMP pages before, b) had to do it very urgently, and c) learned the hard way that the documentation wasn’t brilliant.
The documentation not being brilliant is a side effect of how AMP develops at a pretty fast pace, nothing like HTML, which has essentially been stable for a bunch of years.
If you look at the help pages, it links to a github repository, but in there you’ll see outdated information (as of July 2018). Much better to rely on the <amp-analytics> documentation hosted by the AMP Project.
Let’s presume you have one or more AMP pages, and let’s build some tracking into them using Adobe Analytics and the <amp-analytics> tag.
Basic Tracking
As usual, we start with the minimum, which for AMP has two parts.
You need to load the “amp-analytics” component by placing this line into the <head> of your page:
<script async custom-element="amp-analytics" src="https://cdn.ampproject.org/v0/amp-analytics-0.1.js"></script>
And you need the actual tracking somewhere inside the <body>:
<amp-analytics type="adobeanalytics">
<script type=application/json>
{
"requests": {
"pageview": "https://ags055.sc.omtrdc.net/b/ss/ags055jedev/0/amp-1.0/s{random}?pageName=Testpage"
},
"triggers": {
"trackPageview": {
"on": "visible",
"request": "pageview"
}
},
"transport": {
"beacon": false,
"image": true
}
}
</script>
</amp-analytics>
The important parts of this tag are the following:
- The <amp-analytics> tag — this is how you use the amp-analytics component. Both, the tag and its behaviour, are defined when you load the script in the
<head> - The type attribute — set to “adobeanalytics” in our case. This sort of “loads a configuration” for Adobe Analytics.
- The JSON configuration inside the
<script>tag — this is how we configure our tracking.
Inside the configuration, there are currently three parts:
- transport — defines how the tracking data is transferred. There are currently three ways (maybe four): beacon, xhrpost, and image. The latter is our standard
GETrequest, the other two arePOST. If you set more than one totrue, then the precedence is beacon > xhrpost > image - triggers — defined when data is transferred, and using which request. In our example, the request called “pageview” is used to transfer data when the page is visible. You can obviously have multiple triggers.
- requests — defines what is sent in what form. You can have multiple requests, usually to react to multiple triggers.
It is technically not necessary to declare “transport”, because the declaration of type="adobeanalytics" does it for us, but I wanted to show it, as it is important. The actual minimal code, taking into account everything pre-defined looks like this:
<amp-analytics type="adobeanalytics">
<script type=application/json>
{
"vars": {
"host": "ags055.sc.pmtrdc.net",
"reportSuites": "ags055jedev",
"pageName": "Testpage"
},
"triggers": {
"trackPageview": {
"on": "visible",
"request": "pageview"
}
}
}
</script>
</amp-analytics>
That code actually tracks more than the first installment, as the “adobeanalytics” type defines a bunch of variables for you, such as screen size.
If you want to read more about this, I can recommend the Deep dive into AMP analytics article, or search for “adobeanalytics” in the actual code in vendor.js.
![[screenshot]](https://webanalyticsfordevelopers.files.wordpress.com/2018/06/180717-amp-adobeanalytics.png)
"triggers": {
"storyPageVisible": {
"on": "story-page-visible",
"request": "pageview"
}
}
It triggers or fires in <amp-story> every time a new part of the story is visible, i.e. on a phone when a user swipes to the next “page” of the story.
Note: there are two ways in AMP to track pages when they load: “amp-pixel” and “amp-analytics”. I would opt for “amp-analytics”, see Use amp-pixel or amp-analytics?
Minimum Useful Code
The above example is equivalent to the “(Better) Minimal Code” example in the Basic Tracking article all the way back from 2013.
And like in 2013, we can make this a lot better!
Basic tracking only gives you the “Pages” report, or the “Page” dimension in Analysis Workspace, but you obviously want and can do more.
In the tradition of the “Basic Tracking” article from 2013, we shall add some data to the minimal call above, pretending we are tagging a blog article AMP page.
Here is a better version:
<amp-analytics type="adobeanalytics">
<script type=application/json>
{
"requests": {
"pageview": "https://${host}${requestPath}?${basePrefix}&events=${events}&ch=${channel}&v6=${topic}&v7=${postDate}&v8=${author}"
},
"vars": {
"host": "ags055.sc.omtrdc.net",
"reportSuites": "ags055jedev",
"pageName": "Blog:b2:Basic Tagging",
"events": "event1,event21",
"channel": "blog",
"topic": "amp",
"postDate": "180717",
"author": "Jan Exner",
},
"triggers": {
"trackPageview": {
"on": "visible",
"request": "pageview"
}
}
}
</script>
</amp-analytics>
Under “vars”, the “pageName” is different, of course. And then we have added a whole bunch of variables to that block, and to round it all off, I have re-defined the “pageview” request to use those variables.
![[screenshot]](https://webanalyticsfordevelopers.files.wordpress.com/2018/07/180717-amp-request-no-context-data.png)
I want to point out one important thing: there is a “vid” parameter on the call, and as I’m sure you know, that carries a visitor ID.
There is no Marketing Cloud ID here! No way to create or get one, either! And that has two important consequences:
First: do track AMP pages into a separate Report Suite!
Second: there is currently no way I know of to use Audience Manager or Target with Analytics on AMP pages.
Always more after that
What is cool about “amp-analytics” is that you can have more than just a single trigger and request. The list of pre-defined triggers is “visible”, “click”, “scroll”, and “time”, see When data gets sent: triggers attribute.
The example they give is:
"trackAnchorClicks": {
"on": "click",
"selector": "a",
"request": "event",
"vars": {
"eventId": "42",
"eventLabel": "clicked on a link"
}
}
To make that work, we have to add a request to the “requests” block, called “event”. Or, you could use the “click” request that is pre-defined by the “adobeanalytics” type.
Some other components also define triggers, such as for video interactions. AMP allows for some pretty flexible, if somewhat manual, tracking configurations.
There is a cool amp-analytics examples page that can get you started pretty quickly.
Have fun!
Web Analytics for Developers 
Hi Jan. It was good meeting you in Vegas this spring.
Another, and in many ways better, option is to use the adobeanalytics_nativeConfig option in your amp-analytics tag. In short, this method uses a iframe to load another html file you specify. The data you want to include in your analytics tracking is passed as parameters on the iframe URL. Inside the iframe you can load Launch, set up the visitor ID service and build your analytics beacons.
The adobeanalytics option does not let you load the visitor ID service so your visits are separate from the rest of your site, which is why if you go this way you should use a separate report suite (as you suggest above).
Another reason I used the nativeConfig is that I needed to track both to Adobe and Google Analytics. It was a simple task to add the GA extension to my Launch property and fire it off right after the Adobe beacon.
One downside of the iframe method is that you cannot track on-page click events. You are restricted to just page view tracking.
After doing an AMP implementation a) in a hurry and b) without much guidance I discovered there is a Launch Reference Architecture for AMP document on the Adobe site at https://helpx.adobe.com/experience-manager/kt/integration/using/launch-reference-architecture-guides.html (scroll all the way to the bottom).
The heartening part is that what I developed on my own turned out to be exactly what was suggested in the reference architecture!
Jim Bradley
Evolytics, Inc.
LikeLike
Hi Jim,
Thanks for the comment. I agree that nativeConfig is sort of easier and more powerful at the same time, but I wanted (and indeed had to) work with the standard amp-analytics tag.
Regarding the tracking of on-page actions – would it not be possible to track those by reloading the iFrame content? With a different URL, maybe?
Just thinking…
Jan
LikeLike
Hi Jan,
Does AMP identify a repeat visitor. If yes, does it have a cache or an identifier (a cookie).
What implications does GDPR have on amp-analytics?
Best Regards,
Fahad
LikeLike
Hi Fahad,
AMP is complicated with visitors. Pages do not necessarily always come from the same server / CDN. If a visitor looks at a page twice, and the page is loaded from the same origin both times, then yes, that’ll be one visitor. But if one of the pages is loaded from a different CDN, it would come with a different visitor ID, hence two visitors in Analytics.
No advice from me on GDPR, I’m afraid. Can of worms. You might want to look at the amp-consent component: https://www.ampproject.org/docs/reference/components/amp-consent
HTH,
Jan
LikeLike