More about AMP

Building up on the recent post about Basic Tracking on AMP Pages, I want to riff some more on a couple of aspects today.

Also, my colleague Susan Vertrees happened to sit next to me a couple of weeks ago, and since she knows what she is talking about, she was able to point out a bunch of “optimisations” (read: she showed me how to make this work), and so this article is really her article, I guess.

AMP may or may not become bigger over time, who knows. Those pages are fundamentally different from what you usually meet on the web, putting speed at the top of the wish list, and everything else in second place.

The biggest difference for us in Analytics is that there will be no tag management on AMP pages. Instead, we either use the <amp-analytics> tag, or we make do with the <amp-iframe> component.

<amp-analytics>

<amp-analytics> is the recommended way of doing analytics, recommended by the AMP team.

If you haven’t read the previous article: it allows you to relatively easily specify data in a JSON-style notation, which will then become a tracking call to the tool of your choice. You’re pretty much putting data straight onto that URL.

In my world, that automatically means we should use Context Data and Processing Rules, in order to be as abstract and flexible as possible.

The example from last time can easily be amended to use Context Data, like so:

<amp-analytics type="adobeanalytics">
  <script type="application/json">
    {
      "requests": {
        "pageview": "https://${host}${requestPath}/AQB=1&${basePrefix}&events=${events}&c.&ags055.&pageName=${pageName}&channel=${channel}&topic=${topic}&author=${author}&postDate=${postDate}&url=${canonicalUrl}&.ags055&.c&AQE=1"
      },
      "vars": {
        "host": "ags055.sc.omtrdc.net",
        "reportSuites": "ags055jeampdev",
        "pageName": "Blog:b2:Basic Tagging with AMP 3",
        "events": "event1,event21",
        "channel": "blog",
        "topic": "amp", 
        "postDate": "180717", 
        "author": "Jan Exner"
      },
      "triggers": {
        "trackPageview": {
          "on": "visible",
          "request": "pageview"
        }
      }
    }
  </script>
</amp-analytics>

There are two things to note in this new code:

1. the c. and ags055. URL parameters, and their corresponding .ags055 and .c parameters introduce, and close up Context Data. Everything between those will eventually turn up in the Processing Rules UI later, and
2. Susan told me to add AQB=1 at the beginning and AQE=1 at the end of the URL parameters, just like the Javascript tracking would do, too.

You can see in the Processing Rules UI how the ags055./.ags055 pair ended up being a namespace, meaning all my custom Context Data is prefixed with “ags055”.

This is just an example of how you can use name spaces with your Context Data. Highly recommended!

<amp-iframe>

<amp-iframe>, on the other hand, allows us to load pretty much anything into the AMP page, including Launch, by Adobe, or any other tag manager.

There are two advantages, and one huge drawback to this technique:

• Good — can use a tag manager
• Good — visitor identification works as usual, and you can even use the Experience Cloud ID Service
• Bad — it is entirely possible that the iFrame won’t load at all

Since AMP is built for speed, things like an iFrame will be loaded when time permits, so potentially pretty late.

In situations where your AMP site consists of short story pages, I can easily see how users could navigate so quickly that tracking essentially drops by the way side.

But the two advantages are important enough that using <amp-iframe> might make sense for you.

You also still have to pass data into the iFrame if you want to trigger anything custom. There are two ways to do so, one bad, one better.

• Use the URL that you load into the iFrame: add URL parameters into it. Then, in Launch, build Data Elements that read those URL parameters.
• In Launch, build Data Elements that read the HTTP Referrer (which, inside the iFrame, is actually the URL of the page that loads the iFrame).

I’ll let you guess which one’s the bad one.

One last thing to know is that if you do use <amp-iframe>, make sure your tracking does all it needs to do within 5 seconds. A so-called “Tracking/analytics iframe” will be loaded, then killed after 5 seconds.