Adobe to Acquire comScore’s Digital Analytix Technology: A comparison of Adobe Analytics and comScore Digital Analytix (DAx)
With yesterday’s confirmation of Adobe’s intention to purchase the Digital Analytix product from comScore, here at DMPG we thought it would be a good time to share our extensive experience with both technologies by way of a high level overview and comparison.
Positioned as part of a ‘Marketing Cloud’ by Adobe, they really consider their analytics products as the backbone to the collection of all digital data. This is primarily focused around website and app behaviour tracking but will also include integrations with their other products such as Target, Social, Media Optimizer, Audience Manager and so on.
Enterprise Analytics is a relatively saturated market particularly within Europe and United States where the majority of Adobe’s business will be coming from. As such one of their key initiatives is to use Adobe Analytics as a way of upselling other Marketing Cloud products and also using it as a sweetener to sell other leading products in with clients. If you use Adobe Analytics or start using it expect a very well structured and convincing sales pitch to use their other tools.
comScore Digital Analytix (DAx)
This product has had a bit more of a turbulent ride over the years since it was acquired from Nedstat. The original Nedstat had very humble origins but grew very quickly into a low-cost digital data collection system. Following the acquisition by comScore the solution has grown into more of a ‘Media Hub’ offering. One of the key propositions of the DAx solution over others is its video streaming tracking solution and audience measurement integrations (MMX/VMX).
In much the same way as Adobe have used their analytics product to try and upsell other solutions within their Marketing Cloud, comScore have used DAx as a way of selling a wider range of audience measurement products to their clients. In recent years, somewhat thanks to a few big wins such as the BBC and DailyMail, the DAx product in itself has also started to stand-out as a viable competitor to Adobe’s analytics offering.
The implementation methods are actually near identical. They both rely on structuring GET requests with various different parameters passed to it either from a custom implementation effort or via to some form of plugin that generates them.
So, what are the key similarities and differences?
Both use GET request logic utilising libraries in languages such as JS, Java and Objective C among others
Both have a concept of a ‘page/screen’ hit that is different from an ‘event’ hit
Both utilise inferred data from the HTTP header such as the IP, User Agent, Cookie values etc
Both use a combination of standard parameters (populated by the libraries) and custom parameters (defined by the developer implementing) to pass in attributes about the user and their behaviour
Both allow you to define your own Visitor Identification Key which will act as primary binding method for all subsequent interaction data
Both can be used to receive data from absolutely anywhere. The GET request need not come from a website or app. It could come from any internet connected device as long as the basic structure is adhered to
DAx by default uses a 3rd party https cookie to track data – this is to ensure they can provide richer audience metrics with their MMX and VMX products. Adobe uses a client-side first party cookie by default but will also allow customers to use their CNAME mapping option to create a server-side method of generating the 1st party https cookie. 1st party cookies delivered using a server-side method are generally considered more reliable than those generated by client-side methods
The parameters passed to Adobe are fixed in terms of their end destination whereas DAx labels can be defined on the fly
There are no limits to the number of parameters you could use for DAx whereas Adobe will impose limits based on your contract. In reality a limit for DAx will/should be imposed internally for reporting sanity reasons
DAx libraries are far lighter/smaller than those of Adobe. This makes basic implementations a lot easier and better for page load but may mean a lot more developer effot to track more complex attributes
This is where an explanation is going to be hard to fully understand in context. As such I will put down some headline information but to understand this in context I recommend that you get in touch directly to discuss further.
Flexibility – I would consider DAx as generally a more flexible solution to extract data from. You do not need to define relationships of dimensions and events in advance and their Report Builder capability allows you to drag and drop pretty much anything you can think of to build a table of data. The Adobe solution is still very flexible in comparison to other key analytics systems (including Google Analytics) but more limits are imposed on what dimensions and metrics can be used in combination. I understand this to be due to Adobe wanting to ensure a faster processing time and to avoid customer confusion when data is returned.
Segments/Filters – very similar in both systems in that they both have 3 levels of segment/filtering capabilities. In both you can create segments/filters that either apply at the User scope, Session scope or Event/Hit scope. This simply means that depending on how you want to identify behaviour you can chose one or a nested set of segment options. One key difference is a current inability to easily create sequential logic with DAx segments/filters whereas with Adobe this is made very simple.
Extensibility – both can accept data from any source assuming it’s structured correctly. Both also offer the ability to enhance data keys within the system with richer meta data such as enhancing a video ID with information about the content, author, format etc. Adobe however focus much more on the connectivity with other marketing tools (mainly its own) and have a very large network of technology partners such as call tracking, SEO tracking, CRM systems and many more.
Reporting Tools – this is where they start to differ quite a lot. It is better to list these in tabular format to give a better representation:
Pre-built reporting types that cater for the most common reporting requests such as content popularity, conversion funnels, pathing, product revenue etc. The specific attributes about these are defined by the user within the specific limits of the report item ranges. This can also include segments/filters.
Allows user to build a custom report with any dimension and metric available in the system as well as apply segment/filters. Data is requested in real-time and normally delivered within a matter of seconds/minutes.Data does have some basic limitations in that only the top 5,000 rows of data will be returned. If more than this is required then the data would need to be downloaded normally via the APIs.
Effectively like a mini version of Report Builder it allows for very quick smaller views of the top data points that you might expect to see from Report Builder. As such this is a good way of quickly exploring the data to determine if your logic for accessing it gives you what you need before opting for the more involved Report Builder process.
This is designed to give custom dashboards. They cannot be configured directly and need to be created by the DAx consulting team but can give very powerful/useful reports on the most commonly requested items and displayed in a way that is visually appealing and can be shared around the organisation.
Allows for data to be accessed from the DAx system in any Office product such as Excel, Word, PPT etc without having to go into the standard reporting login. The capabilities in here are relatively basic and will now allow scheduling and auto-refreshing but with a bit of coding knowledge it could be possible to overcome this.
Reports & Analytics
Pre-built reporting types the cater for the most common reporting requests such as content popularity, conversion funnels, pathing, product revenue etc.In addition any custom reporting can be built on the fly using similar templates to those used for standard reporting items.
Allows user to build a custom report with any dimension and metric available in the system as well as apply segment/filters.
Data is then sent to user either as an email attachment or to an FTP location depending on the size of the file. There are no limits to the size or the data output but the larger and more complex the output the longer it could take. The time range for getting data sent after a request tends to vary from a number of hours to days depending on what is required.
This bridges the gap between the standard reporting and analytics interface and the Ad Hoc Analysis Java client for much more advanced analysis. It provides a drag and drop reporting workspace capability to interrogate the data in pretty much any way you can think of to get a handle on whether the queries you’re creating are the correct ones. In addition it acts as a collaboration space to share key insights with other colleagues around the business.
Ad Hoc Analysis
In my view this is Adobe’s key reporting tool. It’s not for the faint-hearted and really is designed for the hardcore analyst who doesn’t really care that much about pretty looking graphs but wants to apply some very advanced logic to get at the data.
In here you can drag and drop and dimension/metric you’d like (as long as you have it) as well as apply pretty much any segment or filter you can imagine. You can also nest segments, drop them on top of each other, use them as dimensions and the list goes on.
With great power comes great responsibility and as such you need to be very careful when you disseminate the data out of this system otherwise many versions of the truth may be revealed.
Similar to Office Link but only designed for Excel. It provides you the same capabilities as you’ll find in the standard Reporting and Analytics area of Adobe but directly in Excel. It will also allow you to schedule data refreshes directly in Excel and email them out to users or a distribution list so can become a very basic alternative for a more advanced BI system internally.
If you’d like to know more about the differences between these tools then please get in touch. We have a lot of experience implementing and using both of these tools and are happy to share knowledge of these within our client confidentiality limits.