Overview
J+Track Monitoring is a service that is deployed via Google Tag Manager that enables the active collection of:
The dataLayer currently implemented across a clients website
Tags that are being triggered in Google Tag Manager
This collected data can then be compared to the J+Track Tracking plan for auditing and quality assurance.
Monitoring is designed for websites only and requires Google Tag Manager to be installed.
What is required for J+Track Monitoring?
Google Tag Manager containers deployed on the target websites
Access to these containers with the required permissions to edit
A tracking plan in J+Track
The plan can be empty
Client approval from an automated email sent from J+Track
Client has to click approve on the email sent
You cannot do this on behalf of the client
The GTM Monitoring Export from J+Track
This includes a set of required variables and a Custom Tag Template
The Monitoring Tag will need to be unpaused when approved to do so.
Other triggering/exclusions may need to be applied in GTM
Why do we need a monitoring service client side?
Testing/validating the dataLayer manually is very resource intensive
Testing manually will not necessarily discover all the possible dataLayer occurrences
Users interact with the website in unplanned ways and therefore monitoring is more likely to return a complete picture of the current state of the dataLayer
Collection occurs like other marketing pixels, asynchronous and is not expected to have notable performance impact
Monitoring is done via GTM, generally no code updates are required for the website
Content Security Policy (CSP) is a consideration
Key Terminology
Terminology | Detail |
Google Tag Manager (GTM) |
|
dataLayer |
|
BigQuery |
|
J+Track |
|
Content Security Policy (CSP) |
|
Use cases
J+Track Monitoring was designed and setup to address and enable the following:
Primary:
dataLayer QA process
Tag Audit
Secondary:
dataLayer Audit
Quick Plan Creation
Primary: dataLayer QA process:
Compare the current dataLayer implemented to the tracking plan created.
In an effort to reduce unnecessary testing time, the monitoring system is designed to collect the dataLayer from the target website. J+Track will ingest this information (dataLayer structure only e.g. no values) and compare it to the plan that was created in J+Track.
This process was not designed to replace manual testing, rather be a complementary process as a way to gauge the following:
Current state of implementation
How many events and parameters have been implemented by the development team
Is the current state worth while to commence manual testing
Identify issues and missing events/parameters
Help focus testing on areas of concern
The UI for monitoring can be used by practitioners and project managers alike. By exporting you can get a quick gauge of the current progress, as well as a resource that can be shared with development teams to help them resolve implementation issues.
Primary: Tag Audit:
Collect the Tags in Google Tag Manager that are currently being triggered.
With every dataLayer push, the monitoring tag will also collect every tag triggered by the dataLayer event. When active this can help identify potential Tagging issues in Google Tag Manager while ensuring the clients key marketing tags and activities are tracking.
Tag data collected:
Tag Id (Can be mapped to GTM API exports for additional Tag configurations)
Execution time
Performance of Tag script
Tag status
Success/Failure
Tag Monitoring will report on all triggered Tags within Google Tag Manager, allowing important insight outside of just analytics purposes.
Using the Tag Id as the key and exports of the Google Tag Manager container via the GTM API, the data can be blended with the Tag configuration data, such as “tag name”, “paused state”. This can be accomplished using Google Sheets and API connections and further improves analysis of this data.
Currently while this is collected it is not available within the UI or exports. It does exist within the BigQuery tables and can be accessed/exported upon request.
Future developments will see this data available in the export an UI.
Secondary: dataLayer Audit:
Perform an audit of a client's current dataLayer to determine its current state.
When onboarding new or revamping existing clients we will often be working with pre-existing dataLayer implementations. Over time these dataLayers diverge from their original specifications and will often lead to inconsistent implementations. Without a clear understanding of what is actually in the dataLayer can lead to tagging complications as well as data quality issues.
It is advantageous when engaging with these clients to perform a dataLayer audit to get a clear picture of the true state in order to plan the best path forward for the client.
The Monitoring tag can be implemented without configuring a full tracking plan. Essentially an empty plan is created and the Monitoring tag exported and set up in GTM.
The Tag will then collect the dataLayer across the website. As the collection is done passively by users, it will build a fairly robust state of the dataLayer.
After a few weeks (depending on user volume) the collection can be exported and reviewed. These events will be considered “unplanned” if they don’t match events setup in J+Track or as mentioned above if it's an empty plan.
During this process, accepted/approved dataLayer events can then be imported directly into the J+Track plan. E.g. “Quick Plan Creation”
Secondary: Quick Plan Creation:
Enable the collected dataLayer to be pushed into J+Track as a tracking plan.
J+Track strength is in providing a robust tracking plan setup based on best practice and predominantly GA4 requirements. The design as such is reflected both in the dataLayer design and GA4 tracking specifications and can be very quick and efficient to execute.
While this approach is fantastic for new dataLayer implementations, the team often has to work with existing clients' dataLayer implementations.
In these cases adding the bespoke dataLayer designs into J+Track is time consuming depending on the complexity of the dataLayer design. E.g. consider nested objects, 100’s of data keys etc.
It is still advantageous to add a clients bespoke dataLayer into J+Track for the following reasons, despite some of the drawbacks and limitations:
Source of truth
Having dataLayer specification in one location, in platform will create a source of truth that can be referenced in the future.
Will enable monitoring comparison
Can activate monitoring for client at key stages, such as new feature or website releases
Having the plan in J+Track will provide future opportunities and services
J+Track is under active development, future releases will enable more options based around tracking plans that can be taken advantage off for existing plans.
Quick plan creation occurs in two locations:
UI Plan management via add new event, import from dataLayer
UI Monitoring of unplanned events
When monitoring has collected the dataLayer, any unplanned events can be selected to import to plan. These will interpret the current dataLayer and automatically add them to the plan. Saving the manual effort in creating these configurations from scratch.
Please note that attempting to export for GA4 (via GTM export) will very likely yield unexpected results for bespoke dataLayers. In this situation it will be best to avoid using J+Track GTM export.
Technical Setup
How to setup monitoring:
Decide and choose your use case for monitoring
Setup a client meeting to discuss monitoring and make them aware of the setup and requirements
A deck like the following can help the client understand what is involved
Ensure the client is aware of the approval email
Raise the potential of Content Security Policy (CSP) impact
Clients may need to adjust their CSP for Monitoring to work, this is often a blocker to the service.
Access the clients plan in J+Track
Create a client if required
Create a new “empty” plan if one does not exist for the client
Send the approval email to the client
Jellyfish will then setup the Monitoring feature
Export the GTM Monitoring JSON form J+track and import into Google Tag Manager
Ensure that you merge and not override with the import
Unpause the tag and make other adjustments to the triggering as required.
Jellyfish will inform the client if a CSP update is required
CSP update is complete by client if required
Monitoring is deployed live per the duration required/discussed
Monitoring is used during UAT and results shared with client when appropriate
How the monitoring collection process works:
All configurations are completed/imported in GTM
The website loads the GTM script (Diagram 1&2)
When the website adds data to the dataLayer via “dataLayer.push()” (Diagram 3) it triggers the Monitoring Tag (Diagram 4)
The Monitoring Tags call a Google Cloud Platform Jellyfish owned and designed API (Diagram 5) to pass the collected data to a Jellyfish owned BigQuery data base (Diagram 6)
How does the monitoring work technically:
Monitoring collection for via key systems:
A HTTP server that receives all the http requests sent by the website.
The goal is to publish the payload of every request into the bus
Note, this is where requests are filtered to check if the data can be accepted based on the approval of the client.
A databus Pubsub
Time to leave set at 10 hours
A consumer
The goal is to pull messages from pubsub and push them into BigQuery
The consumer pulls messages every minute.
Note that pulling messages are random
What data is collected:
We primarily store the datalayer raw events meaning what is inside a datalayer.push(). Examples of it can be found inside the spreadsheet export from the monitoring. Other supporting data is also collected as mentioned below:
dataLayer
Structure only
Event names
Keys
Values are obfuscated
GTM Tags
Tag Id
Execution Time
Execution Status
Triggering dataLayer event
Other
Browser URL (obfuscated as required)
Browser User Agent
Timestamp
GTM Container ID
GTM Container Version
J+Track Related Plan ID (Internal Ids for J+Track)
What configurations are required in Google Tag Manager:
Name | Type | Detail |
Template - JF - Tag Monitoring | Custom Tag Template | The custom template holds all the logic required to parse and send the monitoring data. It runs in Sandbox Javascript, significantly limiting the script's abilities and functionality. Templates provide an interface to create “Tags” that allow for user inputs. |
JF - Tag Monitoring - TM | Tag | The Tag uses the Custom Tag Template and configures the Tag for the clients website. It passes important variables that will enable the functionality of the monitoring Tag. Triggers can be applied to the tag to control the firing of the monitoring as required. By default this Tag is paused and will need to be unpaused in order to track. |
JSV - dataLayer | Variable | Passes the targeted dataLayer (e.g. window.dataLayer) into the monitoring script to be able to extract the required data. As Custom Templates don’t have direct access to the dataLayer, this has to be passed in via a variable. Custom Templates only allow access to the dataLayer by its model, having to approve individual keys in a white list, this is simply not feasible to setup for each dataLayer, considering the exact structure is also likely unknown in most situations. |
CJS - XHR - Send | Variable | This custom JavaScript variable passes back an executable function that uses XMLHttpRequest to perform a POST Request. Given the potential size of each hit, POST is required. However Custom Templates only enable GET Requests. Therefore this functionality as to be passed in as a variable. This also prevents the need for a J+Track JavaScript Library to be loaded on page that would otherwise be required to perform this action. |
JSV - navigator.userAgent | Variable | Provide the current browsers userAgent. |
CSP Considerations:
If the setup is approved then the current website Content Security Policy (CSP) may need to be temporarily updated to allow the GCP J+Track API end point to collect the data.
The CSP will need to allow a url like the below to be whitelisted/approved.
You can find this url for your client in the Monitoring Tag created in your GTM account. It will be one of the input fields in the Tag.
Risk Assessment and Mitigation
While the setup has been thoroughly tested and deployed across a range of clients, with every custom tracking pixel deployment (tracking) it is possible to have unexpected issues. This is due to the custom nature of both a website's programming and its own bespoke dataLayer.
To reduce the risk:
Setup can and should be deployed on UAT first
Setup may only need to be deployed on UAT
Setup can be sampled, only targeting a x% of users
Requires custom configuration and setup in GTM
It uses Custom Templates in GTM
This runs in a sandbox JS, which limits JS functionality
The custom code performs checks to prevent uncaught errors
The nature of collecting the dataLayer (edge cases and bespoke/unusual design) can lead to possible unexpected errors
This needs to be an accepted risk as it's not feasible to determine this before it's deployed.
Any uncaught errors will unlikely impact the website, except in exceptional circumstances
If any errors or issues are identified or suspected, the changes can be rolled back immediately (via GTM) until an investigation can be done.
Key Actions if suspected monitoring issues:
In the unlikely event issues are raised after monitoring has been deployed, either internally or by client the following steps should be undertaken.
Pause Monitoring Tag in GTM Immediately
Publish these changes as priority
Investigate the issue
After pausing the Monitoring and deploying has the issue been resolved?
You will need to first attempt to eliminate the Monitoring Tag as the cause
Attempt to replicate the issue
Run in GTM preview mode and determine the steps that cause the issue
Look for JavaScript errors in the Chrome Developer tools console
Please note clients website often have many errors that you may need to sort though
Look for errors in the Chrome Developer tools network tab
Reach out to the J+Track team with your findings and issues
We may be able to help pinpoint the issue, rule out monitoring or provide a solution.
Document the issue
Detail the sequence of events
Detail the nature of the issue
Details the steps taken to remediate the issues
Share this with the J+Track Team
Discuss with Client Project Team
FAQ
Is complete tracking required for Monitoring to work?
No. Monitoring does require a tracking plan to be created but it can be empty. All events collected will be considered “unplanned” in this scenario
Does a client need to approve the Monitoring?
Yes. As monitoring is effectively a 3rd party tracking script, the client must be aware of its usage. In rare cases it may have an unintended impact on the functionality of the website and this risk must be acknowledged by the client however unlikely. The client might also need to work with their website development team to update the website's CSP.
How long does it take to see the monitoring data?
While the Monitoring data is updated every minute, the process is random and depending on current volume events will be viewable in the reports anywhere between 1 minute and 24 hours
I don’t see any monitoring data
Monitoring requires a series of actions to be taken in order to track as intended. You can check the following:
Has the client approval been sent and accept from J+Track
Has the correct GTM Monitoring JSON export been imported into the correct GTM
Check if the GTM monitoring Tag is paused.
Check if the clients website is preventing the Monitoring script from working due to CSP (check chrome developers console and or network requests)
Check the date range set in the Monitoring UI
Reach out to the J+Track team to investigate after trying the above.
How long should the website be monitored before reviewing the UI/Exports?
It depends. Are you self testing on UAT? What is the intention e.g. dataLayer audit or implementation status?
Generally if you are collecting the dataLayer of the website for auditing and or Tag monitoring purposes it will generally be around 1-2 weeks. This of course depends if custom sampling is applied and the overall user volume and traffic on the website.
If you are self testing then you can check the reports after 1-5 minutes.
Is there a risk of collecting user personal identifying information (PII)?
All tracking scripts have the potential to collect unintentional PII. J+Track Monitoring has been designed to obfuscate all values in the dataLayer and urls before it is sent to J+Track. Server logs have also been disabled which aims to prevent IP and all sorts of metadata coming from requests being tracked. This is done to reduce the risk significantly and collection of PII should be considered extremely rare.
Can monitoring data be deleted?
Upon request the J+Track team can delete the monitoring data collected that is stored in BigQuery. The data collected is automatically deleted after 13 months, but this data range can be customised for the client as required.
How accurate are the collection counts reported in the Monitoring results?
Monitoring collection is based on google specifications when it comes to high volumetry, so if a certain amount of data is received, we will only take a portion of it.
For example, if 1 Million events are received, around 10% or less will be saved.
Therefore the numbers displayed into the monitoring UI are not indication of real traffic and the numbers should be used as a guide only and not compared to other services such as GA4.
Which GCP services are used to ingest the payload?
Cloud Run is used to ingest payload. Note that technical logs have been disabled to be compliant with GDPR. Bigquery is used to store the data.
How is the data transformed and extracted for use in monitoring?
Data is transformed on the client side (the website of the client applies modification so it is compliant with GDPR). All the values are uglified following the rules : letter --> a / number 0, special characters such as / - _ & are kept to still give the practitioner a way of validating the data structure. For monitoring we only compare data from datalayer raw events to our indicators to apply a status : MATCHED, MISSING, EMPTY, UNPLANNED
In case you need further assistance please reach out to the J+ Track team on slack channel #help-jplus-track