We create our pages aiming to provide our audience some quality content in an appealing and fast way, get some clicks on the ads we modestly place here and there and hopefully – get it all together in a way the visitors will come back asking for more – that's a general idea. Aiming to provide a better user experience on mobiles and better Google ratings some of us will maybe try implementing copies of our pages following the AMP standard as well – at this point, this seems like an interesting opportunity nevertheless all the restrictions an HTML document has to meet in order to get verified as Accelerated Mobile Page.
However, how we keep track of what's actually going on with our work? Do somebody stops by or was it all in vain? As we discussed earlier – no other scripts, except for the native AMP one, are allowed on the AMP pages and this includes the tracking scripts we get from our favorite webmaster tools – so, what to do?
In order to try taking care of this the AMP dev team has created the so-called amp-analytics elements which purpose is measuring the activity on the AMP pages you create using AMP Portfolio Template as example and fetching the data wherever needed – like to the analytics platform you got used to or to a user-defined custom URL – in case you are using self-hosted analytics solutions like Piwik, for example.
In order to be able to include amp-analytics elements in your AMP pages with AMP Map you first need to include the script handling this component in your pages <head> wrapped in a <script> tag like this: <script async custom-element="amp-analytics" src="https://cdn.ampproject.org/v0/amp-analytics-0.1.js"></script>
Next, we need to include an <amp-analytics> tag in the <body> to specify some JSON configured objects describing the details which you need to be measured and the destination of the gathered along analytics data.
The amp-analytics element is pre-configured to work with quite a few activity trackers and the list will probably grow up in time so it might be a good idea checking it out from time to time over here: https://www.ampproject.org/docs/guides/analytics/analytics-vendors
where you can also get the appropriate value for the element's type attribute like type="baiduanalytics" for example, in case you need tracking your page's activity with China's most popular tracking service.
Next, you need to configure what data you need tracked and send to the vendors.
This can be done either inline or by providing a link to an external JSON file hosted somewhere on your server and fetched via https:// If you have chosen the second option the link to the JSON file should take place as a value to the tag's config attribute. In case you have decided defining what to track inline you need to wrap the definitions in a <script> with "application/json" attribute in which following the JSON syntax the appropriate parameters should be defined.
There are plenty of stuff you might want to be tracking and most probably for each item, there is an AMP variable and available options but this is far too vast for us to consider in our overview here. All the variables for configuring your amp-analitics script you can find over here:
https://github.com/ampproject/amphtml/blob/master/extensions/amp-analytics/analytics-vars.md
You can certainly operate the <amp-analytics> element to measure activity regarding an AMP file. Inside the <amp-analytics> feature, you specify a JSON settings item that holds the detailed information for exactly what to determine and just where to launch the analytics information. You can surely send the tracking records to an analytics vendor and/or to a WEBSITE ADDRESS. There are undoubtedly numerous analytics suppliers that are pre-configured for <amp-analytics>, notice Analytics Vendors on the official web site for detailed information.
Inside of the coming next good example, we give analytics details to https://example.com/analytics as soon as the AMP file is first launched, and each time an <a> tag is clicked on:
<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>type
Specifies the form of the vendor. For aspects, check the Analytics vendors page.
config
This is certainly an optional property that can be chosen to launch a structure from a specified distant URL. The URL indicated should apply the HTTPS scheme. See additionally the data-include-credentials<code> characteristic below. The WEBSITE ADDRESS may utilize AMP WEBSITE ADDRESS vars. The action must use the AMP CORS security guidelines.
Representation:
<code>
<amp-analytics config="https://example.com/analytics.config.json"></amp-analytics>
<amp-analytics type="googleanalytics" id="analytics1">
<script type="application/json">
"vars":
"account": "UA-12345-Y"
,
"triggers":
"trackPageview":
"on": "visible",
"request": "pageview"
</script>
</amp-analytics>
Arrangement data can be determined inline (as shown in the good example above) or fetched remotely by simply pointing out a URL inside the config feature. On top of that, the integrated configuration for popular analytical vendors can surely be chosen by utilizing the type feature.
If setup data from greater than one of these particular sources is applied, the setup materials (vars, requests, and triggers) will be combined altogether such that (i) distant settings get a lead over inline setup and (ii) inline configuration takes precedence over vendor configuration.
The <amp-analytics> settings material operates the following format :
"requests":
request-name: request-value,
...
,
"vars":
var-name: var-value,
...
,
"extraUrlParams":
extraurlparam-name: extraurlparam-value,
...
,
"triggers":
trigger-name: trigger-object,
...
,
"transport":
"beacon": *boolean*,
"xhrpost": *boolean*,
"image": *boolean*The requests settings object determines the web links applied to transfer details to an analytics platform. The request-name is operated within the trigger arrangement to point out exactly what demand needs to be delivered in answer to a special event. The request-value is an https URL. These types of values may possibly utilize placeholder tokens that can certainly reference additional asks or variables.
"requests":
"base": "https://example.com/analytics?a=$account&u=$canonicalUrl&t=$title",
"pageview": "$base&type=pageview",
"event": "$base&type=event&eventId=$eventId"The amp-analytics element determines a lot of helpful variables which can possibly be employed in requests. A listing of all such variables is certainly obtainable in the amp-analytics Variables Guide. In addition, each of the variables sustained by AMP HTML Substitutions Guide are also supported.
The vars settings item can be used to detail new key-value pairs or else override occurring variables which can possibly be related in request values. New variables are generally applied to define author particular data. Arrays can easily be used to identify a selection of values that ought to be URL inputted separately while preserving the comma delimiter.
"vars":
"account": "ABC123",
"countryCode": "tr",
"tags": ["Swift,Jonathan", "Gulliver's Travels"]The triggers configuration object defines when an analytics demand ought to be sent out. The triggers characteristic provides a key-value pair of trigger-name and trigger-configuration. A trigger-name can possibly be any string composed of alphanumeric characters (a-zA-Z0-9). Triggers created by a setup with lower precedence are certainly bypassed with triggers through the very same names from a setup with much higher precedence.
Like an illustration, the going next configuration can surely be operated to experience 50% of the inquiries based upon aimless input or at 1% based upon user id
'triggers':
'sampledOnRandom':
'on': 'visible',
'request': 'request',
'sampleSpec':
'sampleOn': '$random',
'threshold': 50,
,
,
'sampledOnClientId':
'on': 'visible',
'request': 'request',
'sampleSpec':
'sampleOn': '$clientId(cookieName)',
'threshold': 1,
,
,
,Certain triggers just like click and visible enable specifying an one element or a variety of features utilizing the selector properties. Various triggers are able to utilize different constraints and translations on selected components, for example, if a selector involves all matched components or else the first one, or what features can possibly be fit: everyone or else only AMP elements. Check out the documentation for each and every suited trigger intended for extra details.
The selector properties are:
- selector This kind of feature is employed to search for an element or a variety of elements working with CSS/DOM query. The semantics of just how the element is undoubtedly suit can be modified applying selectionMethod. The value of this attribute can possibly be one of:
* a correct CSS selector, e.g. #ad 1 or amp-ad.
* : root - a specialized selector which fit the document root.
- selectionMethod When defined, this feature can have one of two values: scope or closest. scope allows selection of element inside of the parent feature of amp-analytics tag. closest look for the closest ancestor of the amp-analytics tag that satisfies the supplied selector. The default value is scope.
AMP elements that implanted additional files inside iframes (e.g., adds) may possibly reveal a render beginning event (" on": " render-start"). This kind of happening is typically emitted as quickly as it's feasible to affirm that rendering of the planted record has launched. Seek advice from the documentation of a particular AMP feature to spot whether it produces this occasion.
The trigger for the embed feature should involve a selector that points to the embedding component:
"triggers":
"renderStart":
"on": "render-start",
"request": "request",
"selector": "#embed1"The render beginning event is additionally given off by document in itself and can possibly be managed as:
"triggers":
"renderStart":
"on": "render-start",
"request": "request"The initial load activity (" on": "ini-load") is triggered once the basic materials of an AMP feature or else an AMP document have been actually loaded.
The "initial load" is simply identified in relation to the container and its initial measurements. Even more specifically:
To a document: all of the features in the first viewport.
To an embed component: all of the content components inside of the inserted file that is installed just within the primary proportions of the embed component.
For a plain AMP element (e.g. amp-img): the resources itself, including an illustration or a video.
The trigger for an embed or an AMP element need to involve a selector which points to the component:
"triggers":
"iniLoad":
"on": "ini-load",
"request": "request",
"selector": "#embed1"The initial load occurrence is additionally produced by document itself and can be managed as:
"triggers":
"iniLoad":
"on": "ini-load",
"request": "request"Apply the page visibility trigger ("on": "visible") to fire a request as soon as the page gets obvious. The firing of this particular trigger can surely be built using visibilitySpec.
"triggers":
"defaultPageview":
"on": "visible",
"request": "pageview",The component visibility activator can possibly be configured for any sort of AMP web builder component or a document root applying selector. The trigger will certainly fire when the specified component suit the visibility parameters that can be customized utilizing the visibilitySpec.
"triggers":
"defaultPageview":
"on": "visible",
"request": "elementview",
"selector": "#ad1",
"visibilitySpec": /* optional visibility spec */The visibilitySpec is a group of states and attributes that can possibly be utilised to visible or else hidden causes to alter once they fire. If numerous properties are specified, they need to all be true usable for a inquiry to fire. Settings properties promoted in visibilitySpec are:
Apart from the states aforementioned, visibilitySpec also helps specific variables that are recorded here.
"triggers":
"defaultPageview":
"on": "visible",
"request": "pageview",
"selector": "#ad1",
"visibilitySpec":
"waitFor": "ini-load",
"visiblePercentageMin": 20,
"totalTimeMin": 500,
"continuousTimeMin": 200In addition to the variables presented as part of triggers, you are able to likewise establish additional/ overrides for variables just as data characteristic. If used, these data qualities ought to be part of feature identified just as the selector.
Apply the click activator ("on": "click") to start a request as soon as a determined element is clicked. Apply selector to deal with which elements will certainly cause this request to fire. The trigger will begin for all of the features matched by the identified selector.
"vars":
"id1": "#socialButtonId",
"id2": ".shareButtonClass"
,
"triggers":
"anchorClicks":
"on": "click",
"selector": "a, $id1, $id2",
"request": "event",
"vars":
"eventId": 128Operate the scroll activator (" on": "scroll") to fire a request with a number of states as soon as the page is scrolled. This trigger provides particular vars which indicate the limits that activated a request to be sent. Employ scrollSpec to regulate when this will start:
"triggers":
"scrollPings":
"on": "scroll",
"scrollSpec":
"verticalBoundaries": [25, 50, 90],
"horizontalBoundaries": [90]
,
"request": "event"Use the timer trigger (" on": "timer") to start a request on a standard time period . Utilize timerSpec to handle as soon as this will start:
- timerSpec Standards for triggers of type timer. The timer will certainly trigger swiftly (by default , can possibly be unset) and at a defined interval afterwards.
* interval Measure of the timer interval, in seconds .
* maxTimerLength Maximum interval for what the timer will launch, in seconds.
* immediate activate timer quickly or not. Boolean, defaults to true
"triggers":
"pageTimer":
"on": "timer",
"timerSpec":
"interval": 10,
"maxTimerLength": 600
,
"request": "pagetime"Operate the hidden trigger ("on": "hidden") to launch a request when the page becomes hidden.
"triggers":
"defaultPageview":
"on": "hidden",
"request": "pagehide",
"visibilitySpec":
"selector": "#anim-id",
"visiblePercentageMin": 20,
"totalTimeMin": 3000,A visibilitySpec can certainly be involved to make sure that an inquiry is only fired assuming that the visibility duration conditions are satisfied.
AMP Access system issues a number of events for other states in the access run. For details on access triggers ("on": "amp-access-*"), discover AMP Access and Analytics.
The transport configuration material indicates ways to send out a request. The value is actually an object with specialties which identity what transport techniques are suitable.
"transport":
"beacon": false,
"xhrpost": false,
"image": trueSo here is how you can keep track on what's going on your AMP pages – surely not the most convenient way around – especially compared to the conventional "Just include the generated script" approach and we suppose here comes the place to ask ourselves – Is it worth? The time will tell. Of course, we should also consider the AMP project is still in development mode so it theoretically possible this procedure to become a bit more lightweight in the future.