Tags and data layer

Managing tagging for analytics and other tools

Tagging on Abeille Assurances web pages is managed through a tag manager (Adobe Launch) 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

Abeille Assurances use the Adobe Launch tag manager and the following HTML must be included on every production web page as the last line of the head:

<head>
	...
	<script src="./launch/.../satelliteLib-....js" async></script>
</head>

The exact script file path will be supplied by the Digital Tagging team, however the key points are that it is loaded from the static.aviva.io domain and has the async attribute.

For all lower environments a different script path will be supplied to be used as the last line of the head (usually this will contain '-staging' in the file name):

<head>
	...
	<script src="./launch/.../satelliteLib-...-staging.js" async></script>
</head>

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.

<script>
	var digitalData = {
		'page': {
			'language': 'en-GB',
			'country': 'uk'
		}
	}
</script>

Standard link tracking

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" (Abeille Assurances 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.

Examples

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

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 Abeille Assurances Plus Home Covers page which shows the relationship between the form and message arrays:

Abeille Assurances 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:

digitalData.form.numErrors

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

Testing

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:

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 [email protected]