Quantifying Data Coverage (Adobe Analytics)

Updated:

One of the first things we do with our customers when they deploy our solution is to make sure we're collecting an appropriate volume of data. This is different than qualifying it or assessing the quality of the data (i.e. Company XYZ has an usual industry value). Certainly that's a checkbox in the QA checklist but a sound integration with solid data coverage usually removes qualification questions out of the equation. We want to make sure for the page-views being collected have adequate API calls that we're accounting for.

The bottom line is that we're deploying an async solution that runs on the browser. This makes the solution prone to Ad Blockers, JS related issues and most of all the typical racing condition. We do our best to be preventative in this process and are proactive in accounting for this during implementation.

 

The first report we run is the eVar report for the standard custom conversion. This is different than the classification report.

 

 

Very important to now filter the report by:

1. DATE of Deployment (at least FULL 3 days to date)

2. PAGES of Deployment - it's possible not all pages of your report suite have Demandbase. Typically community pages, support pages and customer login pages. You should apply a segment if this is the case or at least add a segment to filter out a single page you know Demandbase is deployed (i.e page = www.demandbase.com")

 

Set up Metrics

Set the metrics to be Visits, Page Views and Single Page Visits. Remove Revenue, Instance etc.

Quantify the None row

 

You'll notice the first couple of rows will be your Non-Company traffic. The None row will be labeled as such "None".

This is totally expected. No one can collect 100% of all data since we can't be sure how anyone's browser is configured and if they have ad blockers or very high network latency. Additionally, some racing condition is expected given the method of deployment and the fact that Adobe won't stitch data retroactively if some of it is missed in a session.

If the None row is anywhere between 10-30% of Pageviews that is an acceptable range. Keep in mind the None row itself is misleading, it includes visit counts that are actually accounted for but because some of the SAME VISIT pageviews were without data, Adobe treats those as separate visits.

For more on the None row and duplicate visit counts please see below section (What is None)

 

Observe Audience and Company Reports 

 

You can break down None by pages to see if it's a tagging issue as well or just confirm that it is. Again we expect some data loss due to the nature of the web but as long as we're within the accepted range.

 

PAGES with None values 

 

 

Now let's run a company name report

 

 

Observe None here as well. It should be the same across the board.

You can break-down ISP VISITOR by Audience to see that this row is just grouping the noise that is NOT company traffic.

 

What is None 

Cause of None in eVar report : no data sent to eVar 

Causes of no data: Typically when the eVar is enabled, it will expect data on all pages the report suite is collecting data on. But if Demandbase isn’t on all the same pages as the report-suite data, then there will be None for all those visits. Additionally, ad blockers, cookies disabled, network latency and also JavaScript racing condition from Adobe s.t call racing against DB API can all cause None.

 

Why "None" is misconstrued In a report:

 

On first page load there might be no data read when Adobe pageview fires so you get 

 

Company Name
Visits
Pageviews
None 1 1

 

On second page view the data is cached and you have data with visit.

Demandbase 1 visit, 1 page view

 

Company Name
Visits
Pageviews
None 1 1
Demandbase 1 1
Report Total 2 2
Site Total 1 2

So now you have 2 visits total for the same visit (1 is None and 1 is Demandbase). Basically None isn't what it seems and it's misleading in a report. The None row visits are accounted for in some of the other values.

 Proving it

  1. You can prove this by creating a Segment called "Audience Exists" where the Custom Conversion Variable that has Audience 'exists'. This pulls all visits that have a Demandbase audience data point associated with them which in an ideal world is almost all visits. You'll notice the Visit Column for None is now LOWER. This is because you have removed the double counted visits by looking at sessions that had data at some point in their visit.
  2. You can prove this in another way to yourself by exporting your eVar report and ADD up all the visits of the report. You'll notice it won't match the Site Totals row at the bottom of your export.

 

 

Was this article helpful?
0 out of 0 found this helpful