Tags and data layer

Managing tagging for analytics and other tools

Tagging on Aviva web pages is managed through a tag manager (Adobe Launch/DTM) with data provided to it through a data layer. Legacy methods are in place on some pages but they are no longer supported by the Digital Tagging team. Legacy pages will require migration to the approach outlined here.

Tag management

Aviva use the Adobe Dynamic Tag Manager (DTM). The following HTML must be included on every web page:

For staging and production as the last line of the head:

	<script src="https://www.aviva.co.uk/launch/564c74edf9ea/2ab40e37dedf/launch-f32c60317c46.min.js"></script>

Or for all lower environments as the last line of the head (the only difference is the apending of '-staging' to the file name):

	<script src="https://www.aviva.co.uk/launch/564c74edf9ea/2ab40e37dedf/launch-d9401db4a2a9-staging.min.js"></script>

And on all pages in all environments as the final line before the closing body tag:


Data layer

The data layer is a JavaScript object, which we have called 'digitalData', containing multiple nested variables in a hierarchical structure. The data layer is dynamic, and the number of variables will change depending on the page being viewed. It is designed to capture key information about the page/customer which the analytics and marketing teams can harness. With the benefit of reducing the need for developer's time working on hard coded tagging.

	var digitalData = {
		'page': {
			'language': 'en-GB',
			'country': 'uk'

In order to track visitor interactions with HTML elements, the Adobe implementation is reliant on the existence of standardised attribute pairings contained within the elements. Each attribute is designed to give a level of context to the link: 'page', 'area of page', and 'name of link'.

The tag manager is set-up to recognise a click on any on-page element that contains these specific attributes and will send a tracking beacon back to Adobe to record what has been clicked on. These attributes can be applied to any element, but are most commonly included in buttons, arias, radios, and textboxes.

Apart from the class, none of the values for these attributes are specifically set down by the tagging team. Developers/POs/BAs should use the approach detailed below to apply a value to each attribute that is meaningful and descriptive enough that it can be easily interpreted within Analytics, without someone having to visit the page itself to understand the context of the link. If creating a new link on a page where there are already tracked links, then existing convention should be followed and reapplied for any new link tracking (for example, the MyAviva homepage uses "data-dd-group=myavivaHomePage", which would be reused for any new links on that page).

Link tracking is recorded in Adobe Analytics in prop37 ("Button Click Value").

Standard attribute pairings

Attribute name Link context Attribute value
class Site-wide, always "dd-data-link" This top-tier attribute acts as the conditional anchor which fires the tagging event rule. It is always "dd-data-link".
data-dd-group The page the link is on The secondary tier should indicate the page that the link is hosted on. There is no defined format for this, but if there are existing tagged links on the page/journey/platform, then the convention those use should be reapplied to maintain a level of consistency. Examples include "myavivaHomepage" (MyAviva home page), "Motor Cover" (Aviva Plus covers page), "lifeCalculator" (Life Insurance Calculator start page), "retirement-forecaster" (Retirement Forecaster tool).
data-dd-link Actual name or purpose of link A completely unique value which indicates the specific purpose of the link, such as the text (in the case of a button or toggle), or some other specific identifier to understand the CTA of the link.
data-dd-loc Location within the page The tertiary tier should indicate whereabouts in the page the link is hosted. Given the sheer number of potential variations, there is no standardised format for what this value might be. Examples might include: the h2/h3 text if it's in sectioned body of the page; the name of the banner it it's in a banner; the text of a question if it's in a user form; the name of a modal if it's in a modal. Existing conventions should be reused, if present, on any page where link tracking is already in place.


Standard format

<a href="https://www.aviva.co.uk/" class="dd-data-link" data-dd-group="page" data-dd-loc="area of page" data-dd-link="button 1">Button 1</a>

Inspector examples

Aviva Plus banner
Featured content
Life calculator from with AEM

Form error tracking

Form errors without page load

Increasingly, we are using single-page and React architecture to create our online journeys. In these scenarios, when a user submits a form which contains errors, there is no page reload. This creates a problem for form error tagging as there is no natural call to the tag manager for it to check the updated tagging in the data layer which records whether a form error has occurred. In these scenarios, we need to send a beacon or 'satellite call' to the tag manager to manually tell it to check the updated data layer. This satellite call, "_satellite.track('form_errors')", is fired when the data layer has been updated and subsequently records how many errors have been generated and what they are. This satellite call should not be confused with the embed code, which is placed in the header of the HTML to allow the tag manager to work, and also contain the term "satellite".

Deployment details

When form is submitted with errors populate following dataLayer fields as arrays, then send _satellite.track('form_errors'). It is critical that the dataLayer is updated before the satellite call is made to Adobe tag manager to pick up the new dataLayer values. Once the dataLayer values have been updated accordingly, send _satellite.track('form_errors').

The number of errorField and errorMessage fields populated should reflect the number of errors that have been presented to the user. They are in an array format, so the value for errorField.0 should relate to the value of errorMessage.0. See below for an example from the Aviva Plus Home Covers page which shows the relationship between the form and message arrays:

Aviva Plus Home Covers page form errors example

In addition, set the value of the following field to indicate the number of unique errors that have been generated:


and update the form.name field with "|error" appended:

digitalData.form.name = 'life-covers|error';

Please note: it's critical that the value of errorField, errorMessage, and numError fields are wiped and either repopulated or set to null when a user re-submits the form. This is to prevent us attributing form error data to the wrong pages, and also prevents us from simply creating a long string of errors that are no longer relevant. Please use the following scenarios as a guide of when to reset the fields:

Scenario Action
User resubmits form with the same errors All fields remain the same, send 'form_errors' satellite call
User resubmits the form with new errors (less, more, different) Wipe the previous value of the fields, repopulate with new form error status, send 'form_errors' satellite call
User submits form with no errors Set the value of fields to null, progress to next page


Omibug Chrome extension is the easiest way to verify the analytics tags firing on your page. Once downloaded from the Chrome store, the Omnibug tab will appear in the developer console window. Then you will be presented with a view like this:

Omibug Chrome extension

By expanding the 'Page View' or 'Click Event' Adobe Analytics section you will be able to see the analytics variables captured on that page.

If you have any queries on how to apply these, what values to use, or how to access the output data, then please contact digitaltagging@aviva.com