Using the Adobe Client Data Layer to streamline both Google Analytics and Adobe Analytics

The Adobe Client Data Layer (ACDL) presents a new approach in digital web data collection for organizations that leverage the Adobe Experience Cloud stack and Experience Platform Data Collection (Adobe Launch). It comes with useful features not seen in previous data layers, such as the reserved hit-level eventInfo object, and the getState() method. However, the excitement for many comes from ACDL being an event-driven data layer supported by Launch through a simple and easy-to-use Extension.

My excitement? From the opportunities ACDL affords to streamline implementing both Adobe Analytics and Google Analytics.

Possibilities

As an avid Google Analytics user, when I first heard about ACDL I thought to myself, “oh its just like a GTM dataLayer.push” and didn’t make much of it. Over time however, the brain doing what the brain does, these curious questions started popping into my head…

• Does this mean I can implement Google Analytics through Launch without relying on huge blocks of custom code?
• Does this simplify implementing both GA and AA through Launch?
• Would migrating from GA to AA be a lot simpler now? What about vice-versa?
• Can clients with both Launch and GTM leverage the same data layer to send data to Adobe Analytics and Google Analytics?

While my more technically savvy friends would immediately know the answer to that last question is “NO”, I still wanted to explore it because the prospect of a single data layer for cross tag management/cross analytics solutions sounds too good to be true. Being lucky enough to work with a world-class team at Softcrylic, in this post I will lay out why, with a simple innovation, the real answer is “YES”.

GA to AA migrations pre-ACDL

We’ve previously written about why ACDL is the right data layer for website, but the ACDL introduces a lot more than a new event-driven data layer for Launch. It also does make migrating from Google Analytics to Adobe Analytics, or from GTM to Launch, a much more straightforward process than ever before.

Traditionally, migrating from GA/GTM to AA/Launch involves re-creating the data layer that a tech team has painstakingly taken many years to build for GTM. At its core, this is because GA and GTM have been essentially incompatible to AA and Launch. GTM leverages an event-driven dataLayer.push model, while Launch leveraged a W3C standard model that relied on DOM Page Load events to track page views and Launch Direct Calls (or custom event listeners) to track clicks. Launch did not support event-driven data layers.

This meant a large effort from the tech team to re-implement a W3C standard data layer on the site, a learning curve for Direct Calls, making sure the position on the page relative to the Launch embed is correct, ensuring all data layer variables are loaded before Launch, and many other “best-practice” nuances… all to re-calibrate the existing event-driven GTM data layer in a language that Launch could understand.

Moreover, if the business wanted to keep Google Analytics alongside Adobe Analytics for a period of time during migration, this meant maintaining two data layers side by side on the site. If you were crafty, you would do that translation in Launch with custom code although that introduces large swaths of custom code in your TMS (making it more complex to maintain long term). Ideally, support for one data layer would eventually be abandoned after migration is complete, but what if the business wants to keep GA in parallel to AA perpetually? The costs and complexity keep piling up!

With ACDL in the picture there is probably a better way, and there is.

Why am I making a big deal out of this?

If you saw our webinar on The Great Migration: ACDL + Launch + Web SDK + XDM, you will know the Softcrylic-preferred approach to new implementations on the Adobe stack involves ACDL. What I’m saying in this post is this approach extends to implementing Google Analytics as well. Whether you are implementing GA server-side or client-side, the adobe client data layer is the key to maintain both solutions neatly organized and non-dev-friendly in a single tag manager.

I like to approach implementations for clients through a lens of risk reduction. New Adobe implementations can often mean migrating from Google Analytics to Adobe Analytics. But for those situations, how do you mitigate migration risk? Do you really need your tech team to invest a lot of time and effort on the data layer? Migrations are already difficult and time-consuming as it is, any time-saving solution is welcome, especially one that can save time for a tech team. I also bet that clients would appreciate either budget savings, or more budget going towards extended discovery, better solution design, or thorough validation if we can offset on implementation.

Back to my questions in the introduction, ACDL by itself does not solve for this, but with a little bit of Softcrylic magic, it can.

The solution

Softcrylic devised a solution for clients to help reduce total cost and risk of maintaining both Google Analytics and Adobe Analytics side by side. Certainly, a common scenario is clients migrating from GA to AA, but it also helps clients that perpetually keep GA with GTM for media analytics/agencies, and AA with Launch for deeper and richer ecommerce analytics. The latter is a scenario we believe may become more prevalent as the demise of 3^rd party cookies becomes a reality and Google closes its ecosystem more and more.

In short, the solution leverages the existing event-driven data layer organizations have implemented for GTM, clones and cleans it for Launch using the new Adobe Client Data Layer format. As a result, any data previously available to GTM for capture by GA, is now also available to Launch for capture by AA. This benefits implementors in a few key ways:

• There is no additional overhead for tech teams
• Tech teams keep working the same way they previously had
• No steep learning curve for W3C data layers/direct calls
• Teams can implement Adobe Analytics within days, although could immediately POC AA with GA within minutes using Switchboard
• Streamlines eventual consolidation of all GA and AA tags into a single Launch property

How much time exactly does this solution save tech teams? To quote a client we worked with to prove this out “This has saved us A LOT OF TIME”. To put a number on it, I conservatively estimate about 8 weeks of a web architect, developer, and a QA analyst that can be repurposed to other tasks. Approximately $40k (according to salary.com) in direct implementation and additional ongoing costs for tech teams maintaining two data layers on the site. Plus, the opportunity cost of tech teams investing time in other high-value tasks, which is difficult to calculate. So, take the $40k as a baseline savings which goes up or down with the size of your implementation and organization.

Who it’s for:

• Currently, aimed at organizations that already have an established Google Analytics implementation and are looking to also implement Adobe Analytics.
• Both solutions must be implemented in their respective tag managers; GA in GTM, AA in Launch, a common scenario during migrations that keeps reporting live and well.
• If an organization is looking to migrate GA alongside AA, both within Launch, then this solution is not required.
• We would never recommend implementing both GA and AA within GTM, so this solution does not support that scenario.

What it does:

• Clones and cleans the GTM dataLayer into an adobeDataLayer object on every event.
• All future updates tech teams do on dataLayer will be automatically cloned into adobeDataLayer.
• Tech teams do have to implement a single direct call as soon as dataLayer is ready, mostly aimed at supporting first-page personalized experiences.
• End result is you have two data layers on the site, one dataLayer used by GTM and one adobeDataLayer used by Launch, without your tech teams investing any implementation time.
• Once GA is implemented in Launch, it’s a simple object re-naming exercise within the ACDL Launch extension so both AA and GA leverage a single common data layer.

Why this solution exists:

Our goal is for tech teams to not invest time in re-creating an entirely new data layer to support a new Adobe Analytics solution if they already have a functioning event-driven data layer. That seems redundant. Instead, we are looking to leverage rich data layers in Adobe Analytics that tech teams have implemented for Google Analytics. We want to eliminate the additional overhead for tech teams and allow them to go on business-as-usual making updates to their existing dataLayer. Ideally, the solution should be temporary in nature as eventually you want to have all tags implemented in a single tag management solution.

The solution is for organizations that already have an established event-driven data layer powering a robust Google Analytics implementation and are looking to also implement Adobe Analytics. If your organization is in the reverse scenario, already leverages Adobe Analytics and wants to implement Google Analytics in parallel, this solution is not for you. However, Softcrylic has preferred-practices that help streamline those implementation as well, although we will leave that for another day as this post is too long already.

We are excited to announce this solution and would love the opportunity to collaborate with you in your migration efforts, whichever direction you are going on. Contact us to exchange ideas. We love this stuff.