Google Analytics vs. Adobe Analytics - Data Collection

Standardized Data Collection

• Primary method for data collection is a client-side (JavaScript) library which natively identifies visitors/cookies and captures meta data about individual pages and interactions. 

• The data gets transmitted from the client/browser to the collection endpoint through a 1x1 transparent image request that contains the analytics payload. The beacon call is sent as a GET or a POST depending on the length of the request.

• Various different generations of libraries ("s_code", "AppMeasurement", and most recently "alloy.js") have evolved throughout the years. 

• Google Analytics also relies on JavaScript for its primary method of data collection, identifying visitors, and capturing standardized data elements (URLs, page titles, referrers, etc).

• The data gets transmitted via the same mechanism of requesting a transparent gif. 

• The Google Analytics tracking libraries have also gone through several generations ("urchin.js", "ga.js", "analytics.js", "gtag.js")

Tag Management System

• Adobe's recommended approach for tag deployment and management is through Adobe Launch - its latest generation Tag Management System. 

• Launch makes it possible to customize data collection and deploy different technologies through a centralized management system that allows marketers to define highly-customizable data rules and elements and leverage them across a catalog of dozens of different MarTech vendors. 

• Prior to Launch, Adobe's evolution of tag management systems included Dynamic Tag Management (DTM) and before that Adobe Tag Manager (ATM). 

• While Adobe has iterated over three different tag management systems, resulting in a wide range of Adobe Analytics implementations (anywhere from Adobe Analytics tags being hardcoded on sites through to deployments using DTM or Launch), Google Tag Manager (GTM) is, and has been, the de-facto standard for Google Analytics enablement for at least five years.

• An exception to the above trend are deployments using the gtag.js methodology which also allows the deployment of different Google technologies/javaScript libraries through a single javaScript file. 

• GTM offers a flexible approach to tag management, with a variety of features to support enterprise-wide implementations.

Tag Validation

• A variety of proxy/debugging tools (Charles, Fiddler) and browser plugins (Adobe Experience Cloud Debugger, Omnibug) to name a few can be used to assist with tag validation.

• A standard and "out-of-the-box" way for verifying Adobe Analytics tags includes filtering network requests in your browser for the keyword "b/ss".

• Lower level debugging can be performed directly in the browser console usually by inspecting the _satellite object for implementations that use Adobe DTM/Launch. 

• Standard network proxy tools and various browser plugins (GTM/GA Debug, Tag Assistant, etc)  be used to perform validation of Google Analytics dataLayer variables and tags.

• Google Analytics tags can be also easily inspected by filtering network requests for the keyword "collect" and lower-level validation can be performed by reviewing the dataLayer object in the browser console.

• Google Tag Manager (GTM) enables a special "preview mode" which allows more detailed inspection of browser events along with dataLayer elements and GTM variables.

Native Data Layer

• While Adobe DTM and Launch support the use of a data layer, Adobe has not established an official standard or guidelines for an Adobe-native data layer. 

• Multiple data layer approaches have emerged over the past years. Direct Call Rules (DCR), Launch-native methods monitoring pages for changes to different data layer elements, integration with custom JavaScript events, and finally, third-party extensions (Launch Only) often providing data layers that are remarkably close to what GTM offers.

• Recently information has emerged about an Adobe Client Data Layer which seems to be in pre-production state as of the time of this writing.

• Google Analytics has a well documented dataLayer object that natively integrates with Google Tag Manager (GTM). 

• The dataLayer.push() method is automatically recognized by GTM libraries and this provides a standardized method for capturing of custom data based on changes in the data layer.

Custom Events and Attributes

• Data points and their attributes can be captured inside a wide array of reserved variable namespaces (s.props, eVars, s.list, s.products, s.events) as well as passed directly as query parameters for downstream processing. 

• There are different tiers for the number of allowed eVars, s.props, s.events and s.list indexes. A standard implementation usually has 250 eVars, 75 s.props, 1000 events, and three s.list slots available.

• Data elements inside a vendor-agnostic data layer object need to be mapped to these reserved namespace variables.

• Google Analytics also allows the use of custom variables for capturing custom dimensions, custom metrics, content groups, enhanced e-commerce tracking, onsite search, and campaign-related information. 

• The free GA version allows 20 indexes for custom metrics and 20 for custom dimensions.

• The paid GA 360 version has 200 indexes available for custom metrics and 200 for custom dimensions. 

• Google Analytics Web+App allows to capture events along with event attributes. As of the time of this writing, there are differences in how many attributes are available for reporting in the user interface vs. the collection limits. This article explains some of the differences in more detail.

Native Apps

• Adobe Analytics provides mobile SDKs for the capturing of data generated inside Native Apps (iOS and Android).

• Data Validation for Native Apps can be cumbersome due to difficulties associated with testing devices, build management, and proxy configurations.

• Specialized tools such as Adobe's Project Griffon (in beta) and QA2L's Native App validation automation can result in significant time savings and improved data quality.

• Adobe also offers a data insertion API that can be used for tracking Native Apps usage in cases where adding the Adobe-made SDKs is not an option.

• As of 2020, there are three different options for capturing Native App data in Google Analytics (sending data to GA classic/web properties, sending data to Android/iOS App properties (Firebase), sending data to GA App + Web properties/Firebase).

• The primary way for capturing of native app data takes place through the inclusion of FireBase SDK.

• The Google Analytics Measurement Protocol can be also used to send data in a server-to-server type of setup and be configured to capture Native App usage. 

• Adobe Analytics supports a well-documented data insertion API that can be used for collection of different types of data that cannot be captured client-side. Examples include various IoT devices that may not support JavaScript or the iOS/Android SDKs.

• The batch insertion API expands on the same idea with advanced  capabilities for batch file insertion. 

• Google Analytics has a Measurement Protocol which supports data transmissions using GET and POST. 

• The protocol supports both hit-based and batched data transmissions. 

Import of Log level Data

• Log data (in standard CSV or tab-delimited format) can be imported using Adobe's Data Sources capabilities. 

• This type of import can be configured to work retroactively and insert data for a period of time in the past. 

• Adobe also supports the configuration of  timestamped requests which also make it possible to retroactively inject data. 

• Google Analytics does not support ingestion of log-like data and cannot be "injected" with data that is older than 4 hours.  

• Adobe Analytics has a supported and documented method for enabling data collection in a first party context with the setup of CNAMEs. 

• Google Analytics does not have an official recommendation on CNAME usage. 

• In March 2020 Adobe announced plans for a new project termed alloy.js which would allow for data to be collected in a first party context and transmitted server-side. 

• In August 2020 Google Analytics released a beta version for GTM containers that can be configured to collect data server-side. 

• Adobe's recommended method for cross-domain tracking includes the decoration of URLs through the use of a specialized JavaScript function that passes the visitor identifier to the target domain. 

• To enable cross-domain tracking Google Analytics has similar functionality which appends the _ga query string parameter.

• Both Adobe and Google have been progressively developing their offerings with an emphasis on migrating from a fairly rigid legacy of how data is to be collected (eVars, events, cd, cm, etc) to a completely open name-value pair structure for the assignment of meta data. 

• On Adobe's side, the idea was first introduced through contextData variables that were aimed at providing friendlier naming conventions for the meta data, through the evolutions of DTM and Launch where the naming of data layer elements can be completely independent from downstream Adobe nomenclatures, through to alloy.js which promises a fully customizable set of meta data to be passed in the HTTP tracking requests all the way to the edge servers before it gets remapped for consumption in downstream applications. 

• Google's answer has been the introduction of Web+App styled properties where users get to fully define what variable names they want to use. 

• With all of these improvements, the quality of data collection continues to be a universal issue, regardless of the tool of choice. The dynamics of software development cycles, paired with growing complexity, often-seen lack of prioritization for analytics efforts, distributed team arrangements, rapidly changing technologies, and limited/lacking processes around automated data governance are all contributing factors.

 About QA2L

QA2L is a data governance platform specializing in the automated validation of tracking tags/pixels. We focus on making it easy to automate even the most complicated user journeys / flows and to QA all your KPIs in a robust set of tests that is a breeze to maintain.

We take a smart, targeted approach to issue discovery via auto-selective site audits and scans and can help your organization on the path of improved data governance and data quality.

Contact Us