Adobe Experience Platform Tags Extension for Google Data Layers
Co-author: Steve Pelhan, Adobe Customer Success Services
Steve and I are pleased to introduce a new Adobe Experience Platform Tags extension that simplifies client-side data collection in any web implementation that uses a hybrid of Google and Adobe products.
This blog post discusses use cases, deployment scenarios, challenges, and technical details related to the Adobe Google Data Layer Extension and how it helps our customers use both Google and Adobe products.
Summary
A common problem using Google and Adobe products on the same webpage is the use of multiple vendor-specific data layers. The result can be unreliable data collection, duplicate code, complex data layer synchronization, slow vendor migration, and excessive maintenance costs.
The illustration shows one such construct.
To address these issues Adobe recently released the Adobe Google Data Layer extension for Tags (previously Adobe Launch). The extension provides Tags with the logic needed to interact with a Google Data Layer simultaneously with Google Marketing Platform solutions, such as Google Analytics, and Adobe solutions.
The resulting change in approach is illustrated below.
Assumptions
The blog assumes a knowledge of Adobe Experience Platform systems such as the Platform Edge network, Web SDK or alloy.js, and the role of tag managers and data layers in a web analytics environment. When discussing Google solutions it is assumed that an existing implementation is modern and using the Google event-driven data layer.
Adobe Google Data Layer Extension use cases
The Google Data Layer Extension grew from a requirement for rapid MVP-level AEP web data collection, as part of the introduction of the Adobe Experience Cloud solutions into an existing Google Marketing Platform web ecosystem.
This environment had the following characteristics:
- A large amount of momentum behind the existing Google Marketing Platform implementation
- Evolving Google data collection implementation in the website front-end
- Customer management pressure to demonstrate value from Adobe technology
- Complex Google Tag Manager ownership at tenant level making tagging changes problematic
The Google Data Layer Extension was built to accelerate the introduction of Adobe solutions into this environment while allowing the Google solutions to continue untouched. As the extension will benefit many customers and use cases we decided to ‘productize’ the extension and to make the code open source.
The Adobe Google Data Layer Extension streamlines the following use cases:
- Long-term support for both Google and Adobe stacks, avoiding the need to use and synchronize vendor-specific data layers
- Google to Adobe migration projects, for example, Google Analytics to Adobe Analytics
- Quick prototyping of using Adobe products for customers that have a Google data layer
Extension Components
The Adobe Google Data Layer Extension provides the following functions and UI elements:
- Configuration of data layer name
- Instantiation of the Google Data Layer Helper object
- A data element to fetch event, computed state, or raw data layer values
- A rule event to catch different types of data layer activity
- An action for pushing JSON to the data layer
- An action to reset the data layer to the computed state
Links to documentation and resources are given at the end of the blog post.
Deployment Considerations
In this section we consider the environment being supported by the Adobe Google Data Layer Extension; primarily the associated tag manager deployment and the interaction with Google solutions.
Google Product Deployment and Migration
The Adobe Google Data Layer Extension will support the shared use of a Google Data Layer in a variety of Google deployment scenarios, including direct code inclusion, use of an Adobe Tags extension such as Acronym’s GTag extension, or using Google Tag Manager. This allows the Google Data Layer Extension to support a staged migration between tag managers and data layers.
A migration from Google Tag Manager/Google Analytics to Adobe Tags/Analytics/Platform could look like this:
- Deploy Tags and the Adobe Google Data Layer Extension
- Introduce Adobe solutions
- Google Tag Manager permanent integrations migrated to Tags
- Google Analytics sundown or migration to Tags
- Google Tag Manager sundown
The Adobe Google Data Layer Extension makes this process easier by removing the need to duplicate or replace the data layer.
Double Tagged Tag Managers
The illustration below shows a Google Data Layer shared by Adobe and Google solutions. To implement this, two client-side tag managers are deployed; commonly referred to as double-tagging. This construct may be advantageous for a POC, demo, or as a temporary step in a migration process, but is normally considered a poor practice that should be avoided.
Compared with an implementation using only Google Tag Manager, the technical cost of the double tagging (Tags plus the Adobe Google Data Layer Extension) is small: approximately 20kB of additional JavaScript, a DNS lookup, and an additional network request. Of more concern is the increased process and governance complexity of running two tagging systems and the need to have either interaction between them or duplicated code and effort.
Ideally, a single tag manager will be used to embed all required tags. If Tags and the Google Data Layer Extension are deployed before any Google products are added to a page, the use of Tags alone is straightforward and there is no need to use the second tag manager.
Avoiding the use of double-tagging in a mature and complex Google Tag Manager environment is however not always so simple. This may require either the migration of Google Tag Manager managed implementations to Tags or the implementation of Adobe data collection in Google Tag Manager. A third option; server-side event forwarding, is briefly discussed below.
Server-Side Event Forwarding
Server-side event forwarding is an option for reducing duplication and streamlining the performance of web data collection. This forwarding can be from either Google to Adobe or Adobe to Google and might be considered the Holy Grail of mixed vendor data collection architecture.
Shown below is one possible server-side event forwarding architecture, making use of Adobe’s Edge network as the endpoint for client-side data collection and Web SDK as the single client-side data collection library.
This has at least the following advantages over the multi-vendor client-side system discussed so far:
- Only one data collection library needed on the webpage (alloy.js)
- Reduced network traffic — all events go to a single endpoint
- Data enrichment can take place in the Edge network
The server-side approach is however a large topic, reaching well beyond the initial data collection mechanism supported by Tags and a data layer. It will therefore not be discussed in more detail. The important point for this post is that the Google Data Layer and the Adobe Google Data Layer Extension can be used to implement the client-side data collection in what is otherwise an Adobe-based system.
Google Tag Manager or Adobe Tags
The Adobe Experience Cloud solutions and the Platform Edge network and its server-side functionality discussed above are not dependent on the use of Tags. For example Platform XDM data that has been created and posted using Google Tag Manager and alloy.js is no better or worse than XDM delivered by Tags using the Google Data Layer and Web SDK extensions.
This technical parity means that it would be possible to avoid double-tagging and retain Google Tag Manager even after the migration of other Google Marketing Platform solutions to Adobe. The more extensive and complex the Google Tag Manager and Google Marketing Platform implementation and ownership is, the higher the cost of a migration away from Google Tag Manager would be.
The benefits of using Tags for the deployment of Adobe solutions will however outweigh the cost of migration from Google Tag Manager to Tags in most migration situations. Advantages of Tags over Google Tag Manager include:
- Administration and development of Tags client-side data collection and Edge network management functionality is done using a single portal, experience.adobe.com
- The Tags Web SDK extension and the older client-side integration extensions for Analytics, Target, etc., add functionality to Tags that would require manual custom development work in Google Tag Manager
- These extensions provide Tags GUI features which make configuration and management of the Adobe implementations more accessible to non-technical users
- Developers and consultants are normally aligned to a vendor. Those involved in the integration of Adobe solutions will normally be more proficient in the use of Tags than Google Tag Manager
- Future-proofing. Adobe marketing technology is evolving rapidly and Tags development will be aligned with this. Google Tag Manager will develop in line with Google Marketing Platform solutions
Note that this list is not intended to be a complete product comparison and considers only issues related to the introduction of Adobe products.
Deep Dive into the Google Data Layer and Extension
Having looked at why and how the Adobe Google Data Layer extension can be used, we will now take a much closer look at what the extension does, and how it works together with the Google data layer code to deliver a powerful, event-driven data collection implementation. As the Adobe Client Data Layer (ACDL) is the Adobe standard for use with Adobe solutions, this will be used as a baseline reference when discussing functionality.
The EDDL magic sauce: Internal model and the computed state
The Google Data Layer is an Event-Driven Data Layer, or EDDL, similar to the Adobe Client Data Layer (ACDL). A good starting point and an important concept for a deep dive is EDDL computed state, also referred to by Google as the abstract model.
The fundamental technical task of the Adobe Google Data Layer Extension is to provide access to the computed state of the data layer in code implemented using the Tags rules, data elements, and actions.
The computed state is a representation of the current values of all data held in the data layer at a given point in the series of data/event pushes to the data layer.
The illustration below shows a series of four push events and the resulting data layer computed states being caught and handled in Tags rules, using logic provided by the Adobe Google Data Layer Extension, represented by the green box. Each rule is triggered by and has access to the abstract model (the computed state) at the moment of the event push to the data layer, in addition to a copy of the event object containing the event information.
The Google code used by the extension is the Google Data Layer Helper, represented in grey.
To understand the contents of the computed state models, consider the push sequence below:
dataLayer.push({
"event": "userProfileEvent",
"profile": {
"nickname":"bob",
"firstname":"Robert"
}
});dataLayer.push({
"event": "userProfileEvent",
"profile": {
"nickname":"bobby"
}
});dataLayer.push({
"event": "userProfileEvent",
"profile": {
"nickname":"Rob"
}
});
the data layer would look like this:
1: {event: 'userProfileEvent', profile: {nickname: 'bob', firstname: Robert}}
2: {event: 'userProfileEvent', profile: {nickname: 'bobby'}}
3: {event: 'userProfileEvent', profile: {nickname: 'Rob'}}while the computed state / abstract model would hold the most recent values of all properties and be a ‘condensed’ object:
event: "userProfileEvent"
profile:
firstname: "Robert"
nickname: "Rob"This computed state is frozen in time during the processing of a Tags event, so further changes to the data layer that occur during event processing do not have any effect; they would only be visible in later computed states, processed in later rules.
The computed state of the Google Data Layer can be accessed in the Tags extension by using the provided data element.
Events and data
Both the Adobe Client Data Layer and Google Data Layer use a special type of data push marked with the keyword ‘event’, for example:
dataLayer.push({"event":"scroll"});Google Tag Manager can catch this in a trigger, while Tags can match the value of the event using the Adobe Google Data Layer Extension event listener dialog in a rule. A push of data without the event keyword can still be caught but without the possibility of matching the value of the event key.
The use of an event in a push to the data layer is in effect signaling to a consumer that something significant has happened.
Multiple consumers, multiple vendors, consistent behaviour
As multiple Google Data Layer Helpers can use the same data layer without interaction, the computed state of each is independent. This allows multiple Adobe and Google consumers to both push to, and consume data from, the same Google Data Layer, with a high degree of certainty that there will be no interaction.
Additionally, since both the Adobe Google Data Layer Extension and Google solutions are using the same Google Helper code under the hood, the behaviour of the data layer is consistent across solutions and vendors.
Adobe vs Google Data Structure
A perceived difference between the Adobe Client Data Layer and Google Data Layer is the data structure used with each.
Discussion of the Adobe Client Data Layer often shows highly structured data, particularly in the context of AEM Core Components or Experience Platform XDM. Google Data Layer documentation and discussion normally show flatter data structures and are unlikely to mention Adobe XDM.
The difference in documentation can lead to an assumption that there is a fundamental difference between Adobe and Google data layers. This is not the case and both data layers will accept almost any data format.
In a migration scenario it is likely that an existing front-end tracking implementation can remain untouched when introducing Adobe solutions. An exception is if you want to add more data to what is being collected.
The Adobe / Google structural difference shown in documentation may look like this:
‘Google Style’ relatively flat event push. This event information could be mapped in to an Adobe XDM structure using Tags, to then be sent as XDM to the Edge network.
dataLayer.push({
"event": "analyticsEvent",
"event_name": "navigation",
"navigation": {
"event_category": "main navigation",
"event_action": "link click",
"event_label": "Home",
"navigation_item": "link"
}
});Similar information in an XDM structure in an ‘Adobe Style’ data layer push might look like this. Here we have a raw piece of XDM that could be sent (with additional context XDM) to the Edge network with little or no modification.
dataLayer.push({
"event": "analyticsEvent",
"eventName": "navigation",
"xdm": {
"web": {
"webInteraction": {
"name": "navigation"
"event: {
"category": "navigation",
"action": "link click"
"label": "Home"
"navigationItem": "link"
}
}
},
"eventType": "web.webinteraction.linkClicks"
}
});The web SDK will accept either format and has tools for mapping existing data into XDM format. Data architects and developers will define the appropriate data structures, and this is unrelated to whether a Google Data Layer or Adobe Client Data Layer is used. Additionally, both the Adobe Client Data Layer and Google Data Layer Tags extensions include data elements which can return individual nested values or complete JSON objects, for example the entire data layer.
In a mature Google Analytics environment it is likely that mapping to XDM would be implemented in the client-side tag manager; Google Tag Manager and/or Tags. In a clean Adobe-focused environment it may be more attractive to push pure XDM to the data layer and minimise a mapping implementation in Tags. In this case the computed state of the data layer is an XDM object resulting from the merge of pushes such as that shown in the second data layer example above.
More on Data Collection in Tags
The blog posts of my Adobe Consulting Services colleagues Benedikt Wedenik and Julien Piccini are a great source of information about data collection using Adobe Tags, and while the focus is on the Adobe Client Data Layer, they are equally relevant for users of the Google Data Layer. See Related Blog Posts in the resources section at the end of the page.
More on the Google Data Layer
The Google Data Layer Helper project README provides fine-grained detail about the use and behaviour of the Data Layer itself.
Google vs Adobe Data Layers
There are minor functional differences between the Google Data Layer and the data layer more commonly associated with Adobe solutions, the Adobe Client Data Layer. A developer working with both must be aware of these, but for the purposes of this post, in which an existing Google Data Layer is assumed, this low-level detail will not be discussed.
The key point is that the data layer vendor need not be a consideration in a Google to Adobe migration process. A Google Data Layer can continue to be used even in a pure Adobe, post-Google environment.
About
The Adobe Google Data Layer extension is the result of work by Adobe and Valtech Switzerland’s Adobe practice.
Particular thanks to the following for the enthusiasm and support needed to develop, test, and release the extension:
David Schneider and Andreas Kaufmann at Valtech Switzerland who helped give birth to the project.
Jeff Chasin, Justin Grover, Brent Hosie, Kevin Jemison, Paul van Oosterhout, Brandon Pack, Steve Pelhan, Serban Andrei Stancu, and Jon Viray at Adobe all of whom contributed to pushing the project through to release.
Extension Maturity
At the time of writing the Adobe Google Data Layer Extension v1.0.6 has had limited production use and should be considered a beta.
We encourage feedback and welcome contributions via the open-source Github repository.
Resources
Related Blog Posts
https://webanalyticsfordevelopers.com/2020/11/17/lean-analytics-with-acdl/
https://www.datanalyst.info/web_analytics/the-event-driven-data-layer-revolution/
Google Data Layer
Data Layer Helper in Github. Detailed information about data layer usage.
Google Data Layer Extension
Exchange Listing. Contains screenshots of UI elements and a functional overview.
Product Documentation. Simple usage instructions.
