Overview
Collecting, reporting and auditing a dataLayer is a complex process. J+Track reporting UI is designed to obfuscate this complex functionality and present simple and effective reports. While the UI will have some limitations in its approach, the data collected is vast and stored within BigQuery and as such more advanced reporting can be achieved by working with the J+Track team.
This guide looks at the reporting UI within J+Track the exportable sheets, detailing the options, terminology and some further ideas how to utilise the assets.
Reporting UI
The reporting UI is designed to achieve the following use cases:
Compare collected dataLayer events to the tracking plan
Reduce and improve manual testing
Current state of implementation/quality of dataLayer
Identify missing events
Identify missing variables
dataLayer rollout progress (checking over data ranges)
Collect unknown dataLayer events and allow these to be quickly added to a tracking plan / create a tracking plan based on the bespoke dataLayer
Conduct audits of a clients dataLayer (bespoke/legacy/new clients)
Interface
The interface is around the collected dataLayer events. The accordions are grouped under the tracking modules set in the tracking plan or will be grouped under “Unknown” for unmatched events. The top right of the reports will provide export and other monitoring options.
Each Module once opened will list the associated events.
Each event rows will show:
Event name
Warning Icon next to event name if that events variables are not 100% match
The status e.g. Matched
The count of sampled collected events found
The last received date of the event
The last received url of the event
Event rows can be expanded to see all the variables collected under that event name.
The variable rows will show:
Variable name
The status e.g. Matched
The count of sampled collected variables found for that event
The last received date of the variable
The last received url of the variable
What to look for
When using the reports ideally you would like to see all events and variables matched. This would indicate that the dataLayer compared to the J+Track plan is likely in a very completed state.
Missing events will be the first major flag to identify. This may be a result of J+Track still processing the monitoring data or that the event has not yet been implanted.
Unknown events are another area to investigate. These could be mistakes in the dataLayer in respect to event names, legacy dataLayer on the website or dataLayer created by 3rd party services. It may also indicate events that should have been added to the tracking plan.
Events with the exclamation icon indicate that while the event is tracking, it is missing variables as required by the tracking plan. As the reporting UI combines all dataLayers of the same event, it's possible that this is not an issue. Variables that are missing, unknown, or empty may be acceptable issues. If an event is missing the majority of its variables, or clearly very important variables e.g. add_to_cart missing items, then it's likely an issue with the dataLayer implementation.
These reports should be used as a guide to help target testing and provide feedback in the early stages of dataLayer implementation. For example, with monitoring setup prior to dataLayer coding being performed, these reports can be used to gauge the progress. Until a certain level of matched events occurs manual testing could be delayed.
Using unplanned tracking events
If the monitoring has been used to audit or collect the existing dataLayer, then the unplanned events can be automatically added to the tracking plan. This is done by selecting the unplanned events and clicking the “Create indicators” button in the top right of the reports.
Please note unplanned events will likely have their own dataLayer design that is not compliant with the J+Track modules and events. As such, while these are value to hold in a tracking plan for a client as a “source of truth” and take advantage of the documentation and monitoring features, they will be unable to make full use of the GTM Export.
The main issue will be the design of the GA4 Tags and the event names. They will inherit the dataLayer event and in most cases this will not be desired and not compliant with the required GA4 event taxonomy. Manual work will likely be needed to rename these manually in GTM is the export is used.
Filtering Options
Type | Details |
Date Filter | Date range will show all dataLayer events collected in that time period. Default is set to show the past week. |
Status | Filter the dataLayer events and variables by the assigned status |
Search | Search the dataLayer events and variables for the entered term and only show those results. |
Event and Variable Status
Status | Details |
Matched | The event/variable has been found |
Missing | The event/variable is missing and was not present in the collection. |
Unplanned | An event/variable has been collected, but was not planned or present in the tracking plan. |
Empty | The variable on the event did not have a value. |
Report Actions
Type | Details |
Add Users | Add a user to allow access to the client and tracking plan. |
Export | Export the monitoring data to a Google Sheet |
Monitoring Sheet doc | A link to the exported monitoring Google Sheet |
Refresh monitoring events | Refresh the current reports to get the latest processed data. |
Send Approval request | Open up the Approval request email form to allow the client to authorise the monitoring. |
Send revocation request | Approval requests can be revoked by using this option. |
Sheets Export
The google sheets export will take a snapshot of the monitoring data, and include the summary you see in the reporting UI as well as a sample of the raw collected dataLayer events. This export can also be shared with clients and developers to aid in testing and rollout of a dataLayer in combination with other testing assets.
Compliance sheet
The Compliance Sheet is a re-creation of the UI report and the same explanations apply. Being in sheet format, filters can be applied as well as other features of using google sheets.
Importantly the export contains an overall summary of the event and variable match. This provides a quick indication of the current state of the dataLayer.
Collected dataLayer raw events sheet
The raw dataLayer can be very useful to see a sample of the dataLayer collected and can be used to assess the dataLayer in more detail than the aggregated form. This sheet also indicates what is available via a BigQuery export request.
The raw dataLayer JSON is in a compressed format and this will reduce its use. However it is possible using 3rd party services/tools to beautiful these snippets to make them more user friendly. There are also App Scripts developed by Jellyfish that can do this as well.
Limitations
Tag Data
While GTM Tag data is collected, detailing the Tag Id, execution time and status, it is currently not available within the reporting UI and sheets export. Upon request this data can be provided by the J+Track team. Long term this information will also be surfaced within J+Track like the dataLayer.
Client Access
Currently J+Track is available to the internal team only. This is also true for the J+Track monitoring reports.
You can use the export option in monitoring to create a client shareable asset
dataLayer Aggregation
The reporting UI is designed to assess the current state of a tracking plan, and the overall dataLayer structures(design) that is present on a website.
The reporting groups all dataLayer events under the “event” and merges all the possible variables under that event. This is very effective for comparing the tracking plan and seeing the overall dataLayer design. However, we appreciate this is not necessarily the complete picture of how dataLayer is used on a website, for example you may have the same event, with different keys present and this may be important for audit and qa purposes etc. The reporting UI will not show this.
The export will contain a sample of recent dataLayer per events, however this will not guarantee that you will see all combinations of events and its keys.
The raw data in BigQuery will have this granularity, it is possible to get an extract of this data in its raw format by discussing with the J+Track team.
Domain Aggregation
The reporting will be an aggregation of all events collected across different domains. This will not pose an issue for a single monitored domains, however in practice a GTM container can be shared across many different domains, or the monitoring tag may be implemented across many GTM Containers. In these scenarios the reporting will be showing the combined dataLayer and its keys across all domains. Currently filtering by domain or GTM container is not possible in the UI or export, but is available in BigQuery.
Limits
Monitoring will present sampled data depending on varying factors. In most cases this should not be an issue as the collected events will be more than enough to compare to the tracking plan. It's important to note the event counts do not represent the true events on the website and therefore should not be used to benchmark or compare vs other services and analytics tools.
In case you need further assistance please reach out to the J+ Track team on slack channel #help-jplus-track