Google Analytics Premium vs Adobe Analytics Comparison

Over the years, most analysts, especially most analysts dealing with the operations of websites and/or mobile apps will find themselves in one of two situations. Some will be faced with the dilemma of which web analytics tool should they choose.  The others will simply wish they had they had the ability to make their own choice.  In my career which spans years of using different tools for a number of different purposes, I’d rather have the issue of having to make choice rather than not having one.  This is especially true for choosing analytics tools.  My aim in this post is not to catalog every difference between Adobe Analytics and Google Analytics.  There are scores of blog posts that aim to tackle that very task.  For example, EDUCBA’s blog post on Adobe Analytics vs Google Analytics is a comprehensive and up to date comparison that should be referred to when making a choice.  The EDUCBA blog post also improves on most comparisons I’ve read as most other posts seem to have been biased in some way.  For instance, most the comparisons that tend to lean favorable toward Google were written by agencies that happen to be analytics partners for Google (providing services such as Google Analytics Premium implementation, training or sales), while comparisons that lean favorable toward Adobe seem to be simply outdated or based on edge cases that most large organizations will not be exposed to.  My aim in this post is to touch on some of the topics that are usually not covered in most comparisons including such as Tag Management, Raw Data Export and Default Metrics from an outside perspective.

Before moving forward, please note that I currently nor have I ever worked for either Adobe, Google or any company that is compensated by either company. This is my own personal opinion and not the views of either organization. Now that that’s out of the way let’s begin.

Tag Management

So, you may be thinking, Tag Management is a topic that most comparison posts cover.  If you did, you’d be right, however, I don’t think most of those posts take into account the sheer importance an analyst should place on Tag Management.  Most of these posts put the same emphasis on Tag Management that they do on Reporting or Cost.  This is poor analysis as a web analytics engagement will only perform as well as its implementation.  Issues such as poor pageview tagging, inconsistent marketing parameters and spotty success metrics will sink an analysis in no time.  Tag Management should be weighted higher than most topics when weighing analytics providers.

When to choose Adobe over Google

  1. Adobe should be considered if you have an extremely hard to track website like a Flash website.  With that said, if you have a flash website in 2019, you probably have other issues.
  2. You need a good deal of dimensions (like greater than 200) and you are representing one of the unicorn organizations with the time, resources and sanity to actually maintain over 200 dimensions.

When to choose Google over Adobe

If you don’t fit into the 2 categories listed above, I find it hard to not advise using Google.  Google’s Tag Manager has the rare combination of being intuitive and powerful while also looking pretty slick.  The interface is easy to navigate and features like Lookup Tables make working with large amounts of tags easy.  One of the other major differences between Google Tag Manager and Adobe DTM / Launch is the addition of third party tags.  With GTM, you can place tags for other tools such as Clicktale, CrazyEgg and LinkedIn Insight directly in the container without the need to trouble your IT resources with a request to add more JavaScript.  I haven’t worked with an organization that didn’t use Google Tag Manager (even the organizations that had Adobe Analytics installed).

Export of Raw Data

This is another topic that I’ve never seen covered in other comparisons.  Today, marketing organizations must be able to join their web analytics data with other sources such as CRM data to create the ever starved for Omni-channel view of the customer. I haven’t worked for an organization that didn’t warehouse and report on raw data, especially web analytics data.  One example of this type of analysis would be clickstream data including both User and Session IDs.  Neither Google nor Adobe Analytics provide this type of data in the interface (at least not for every session).  For this type of analysis, web analytics providers must export data at a level more granular than what they provide in the interface.

API

Adobe provides an API for accessing data from the interface and a number of dimensions and metrics including all user generated Props and eVars are available in the API.  With that said, (at the time of this blog post) not all dimensions are available and some absolute must have dimensions such as visit start timestamp and hit timestamps are not available in the API.  This has been a deal breaker for many of the organizations I’ve worked for.  I also find the documentation to be pretty underwhelming.

On the other hand, Google has multiple APIs for solving multiple tasks involving Google Analytics data.  Their reporting API deals with most general data requests, the Multi-Channel Funnel API exports data dealing with marketing attribution reporting, a Realtime Reporting API exports data at a real-time pace and they even have a Management API for easy granting and termination of data access (very helpful for large organizations).  The documentation for each of these APIs is extensive, always seems to be up to date and the APIs perform well.

Large Data Export

Not all data export issues can be solved with an API.  Very large exports will need dedicated tools to work expediently.  Adobe has the Data Feeds Export which allows users to schedule data feeds from the interface.  Feeds can be sent to either an FTP account or to an S3 bucket for convenient loading into any of the AWS data warehousing tools such as Redshift or Athena.  All dimensions available in the interface are available in Data Feeds including some dimensions not seen in the API like visit start timestamp and hit timestamp.  Data is exported at the hit level to ensure the most granular view of activity as possible.  Now, to list the bad points.  There is almost no data cleaning done before data is received and data is received in over 8 different files for each individual day (a data file and various “lookup“ files).  Any organization that would like to use this data will have to spend resources on a round of data cleaning, manipulation and merging before data is usable.  After moving from an organization that deals with Google data to one that dealt with Adobe, this was one of the most frustrating “surprises” I had to deal with.  Also, the export jobs are painfully slow.  If a job is scheduled to export historical data, each daily file sends only once every 30 minutes!!!  This means pulling 1 year’s worth of data will take over 7 days!!! Adobe has recently released a new feature for querying Adobe Analytics data called Query Service. With that said, when I inquired about using the service, I was told that my company would have to incur extra fees in order to gain access. This was…disappointing.

Google provides a solution for exporting data to Google Data Cloud which is part of the service if you are paying for Google Analytics premium.  Google Analytics BigQuery Export can be configured directly in the Google Analytics interface. 

Google Analytics BigQuery Export Interface

Once configured up to 13 months of historical data pre-populates in your BigQuery account and future data is populated daily as it comes.  Also, the daily data is all contained in concise single daily tables.  There is no need to join to lookup tables to select other attributes.  Lastly, the data is contained in single session arrays and (while the query structure has a bit a learning curve) breaking down reports based on user, session or hit level is pretty straight-forward.  This can’t be said for Adobe Analytics Data Feed data which is so raw, it’s difficult to know how to correctly query.  In my opinion, data export is a huge issue for Adobe Analytics.

Default Reports, Metrics and Dimensions

As previously mentioned, the behavior of the Data Feeds in Adobe Analytics was a frustrating surprise once I moved from an organization using Google Analytics to an organization using Adobe Analytics. Another frustrating surprise was the lack of canned metrics and dimensions. Adobe prides itself as being highly customizable and having the ability to apply to any type of website. While this cannot be refuted, this is also one of Adobe’s biggest flaws. Because of this level of freedom, Adobe lacks a good framework for tagging that can be applied to the majority of websites. Google, on the other hand, has some frameworks, developed by their engineers, that work well with most sites. Some of these include the utm marketing parameter framework for populating marketing reporting, their event tagging structure, their site search structure and their ecommerce tagging structure. They’ve done the dirty work of finding frameworks that have worked for other companies in the past and posted those frameworks directly in their documentation. This also applies to the reporting, metrics and dimensions themselves. Here’s a short breakdown of some very useful features that are “out of the box” in Google Analytics (Free or Premium) after only implementing the pageview tag as well as tagging marketing initiatives with simple utm parameters:

FeatureTypeGoogleAdobe
Multi-Session AttributionReportYesPrime
New vs RepeatDimensionYesNo
Campaign Cost Reporting (Google Ads)MetricYesNo
Site Speed Reporting ReportYesNo
Demographics (Google Ad Based)ReportYesNo

Custom Reporting and Dashboards

Custom reporting is another topic that is normal glossed over when it comes to comparison articles and blog posts. Historically, Adobe has not provided much by the way of dashboards other than the rather simple “reportlets” displayed on the homepage once logging into the interface. These widgets provide some simple data in a table format but no graphs for understanding trends or differences visually. This changed recently with Adobe release of Analysis Workspaces. Analysis Workspaces allows users to create dashboards with a number of different visualization types such as tables, line graphs, bar charts, scatter plots and maps. While the addition of this functionality is a welcome sight for any analysis looking for a good high-level view of their site performance, there are some features in the reporting that make me scratch my head. I can’t think of a day in my career as an analyst where I didn’t do some sort of comparison. This is especially true when trying to evaluate the performance of a site over a particular time period. Therefore, I was more than miffed when I noticed the number of steps I have to use to compare date ranges in Analysis Workspaces. To do a comparison, I have to select a date range that includes both of the date ranges I’m comparing (strange especially when comparing year over year data), create 2 separate date ranges for the ranges being compared (much like creating segments), then create a table report listing both of the date ranges.

Date Range Builder is part of the multi-step process for comparing dates in Adobe

Also, as far as I know, the comparison is limited to the table report view and not available for other visualizations such as bar chart and line graph. This process is more cumbersome than I’d expect which leads me to discuss dashboarding in Google. Google provides some useful visualizations on the homepage of the reporting interface as well as their custom dashboard functionality. Here, I’m able to create a dashboard with up to 12 widgets with visualizations such as tables, line graphs, bar charts and maps. Widgets can also include real-time user count based on a number of different dimensions such as marketing channel and page. However, the real differentiator between Google and Adobe’s dashboarding is how easily date comparisons can be done in Google. Google provides the same date dropdown in the dashboard as it does in all of the other reporting allowing me to easily select the date ranges I’d like to compare without the extra steps required in Adobe. Also, the comparison applies to all of the visualizations (except real-time of course).

Date dropdown in Google Analytics
Bar chart from Google Analytics custom dashboard

There are some really nice advantages to using Adobe Analytics over Google Analytics. Adobe has much more by the way of customization and Adobe has dedicated account services, while Google Analytics Premium provides SLAs and some services but lacks the true assigned account representation. With that said, as I’ve mentioned in my post, I find the lack of structure, lack of expected default metrics / dimensions (bounce rate, new vs repeat, etc.) and the cumbersome nature of the raw data export to be some pretty large issues with Adobe Analytics. While many other comparison posts end with something to the effect of “its up to organizations themselves to make the decision of which tool to use”, I have a hard time not endorsing Google.

An Alternative to Google Analytics BigQuery Export Using R and Google Tag Manager

Google Analytics has proven to be one of the most influential tools ever created for marketing analysis.  Google is pretty unrelenting in their pursuit of innovation for Google Analytics and that innovation shows in the number of other tools they’ve built for analysts.  From Google Sheets to BigQuery to Google Data Studio, the complementary tools built are a great aid for dealing with the dearth of data that can be mined from Google Analytics.  One of the little known yet game-breaking tools available for use with Google Analytics data is the Google Analytics BigQuery Export.

Google Analytics Premium BigQuery Export
Google Analytics Premium BigQuery Export

This tool, which is only available for users of Google Analytics premium product, is in essence a raw data export of a website’s Google Analytics data.  This unlocks any analyst with a decent knowledge of SQL from the shackles of Google canned reports.  This also allows an analyst to create much more robust logic for creating reports.  For instance, if an analyst wanted to create a report for all users that viewed a particular page during their session and returned to the site within 6 days, they would only be limited by only their knowledge SQL and their ability to fork out the $150K Google charges for their premium product!!!

Google Analytics does not provide data at the user level out of the box, however, with the aid of a process outlined in Simo Ahava’s tremendously useful blog, you can use Google Tag Manager to pull Google’s user and session IDs out of the cookie (also known as Client ID) and feed them back to the interface in custom dimension or event.  This gives an analyst the ability to report on user activity at the user ID level.

Remember: passing personally identifying information to Google Analytics is a violation of the terms of service, so don’t pass any personal identifying information to Google if you might have it, like email addresses.

Below are the steps I use for passing pageview data along with user and session data to the GTM data layer for logging in Google Analytics, however, you could technically use a slightly different process to pass ecommerce, event, goal, custom metric/dimension data as well.  I’ll cover that in a later post.  I’ll assume that the reader has already tagged all of their pages with a Google Tag Manager container, but if not, start by reading this post and make sure to tag your pages.

Steps:

  1. Create a Custom Dimension by going to the admin page in your Google Analytics view:Under “Custom Definintions” select “Custom Dimensions”, create a dimension and call it “Client ID” or whatever name you prefer. This dimension will have a scope of “Session”.  Make note of the dimension index (you’ll need to enter that later).
  2. Create a Custom JavaScript Variable in Google Tag Manager and give it a title such as {{Set Client ID in Dimension 1}}.
    Here is the code:

    Make sure to include the correct index to the customDimensionIndex variable.  If you’ve completed this step correctly, you will be able to see the ClientId being passed under whichever custom dimension you have set it up for in the Google Analytics Debugger tool.

    Client ID being passed into dimension 1
  3. If everything shows up, move back to Google Tag Manager and edit the pageview Tag for your site. Under “Fields to Set”, type “customTask” and under “Value” use the dropdown to select the variable we created in step B, {{Set Client ID in Dimension 1}}.Now that concludes the first part of the process.  Once you’ve reached this step, you could technically start playing with the user and session Client ID dimension in Google Analytics’ custom reports.Pull Client ID Custom Dimension DataSo we’ve tagged our site to send user and session data to Google Analytics and have dealt with sampling, now for the fun part.  This string pulls page URLs, user and session IDs by date based on the dimensions detailed above.  Where pro

    Run some other scripts

    Using some other scripts, an analyst can answer a number of other questions, like how long does it take a new user to become a repeat user.  These scripts rely heavily on the data.table syntax instead using base R.  Please take a look at my prior post on using data.table to learn why I do so.

    Data Returned

    Then run the rest:

    This will return the number of days on average it takes a new user to become a repeat user.

    calculate number of days for new user to return
    There are a number of other uses for the client ID data in GA.  For instance, a marketer might want to do some attribution modelling or a content manager would want to know if viewing an article in one session might effect subsequent sessions.

One consideration around doing this type of analysis is scale.  Most smaller websites won’t pose an issue, but some larger sites (like the one I currently work on) will.  Pulling an individual non-aggregated row for every session, page or event can yield some extremely large datasets.  In this case, it would make sense to send the data to a cloud storage data warehouse such as BigQuery.  Want to learn more on using R to solve for this?  Stay tuned…