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 asynchronous solution that runs on the browser. This makes the solution prone to Ad Blockers, Javascript 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:
- DATE of Deployment (at least FULL 3 days to date)
- 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 Unspecified Row
You'll notice the first couple of rows will be your Non-Company traffic. The Unspecified row will be labeled as such "Unspecified".
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 Unspecified row is anywhere between 10-30% of Pageviews that is an acceptable range. Keep in mind the Unspecified 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 Unspecified row and duplicate visit counts, see What is Unspecified.
Observe Audience and Company Reports
You can break down Unspecified 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 Unspecified values
Now let's run a company name report
Observe Unspecified 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.
Cause of Unspecified 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 Unspecified 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 Unspecified.
Why "Unspecified" 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
|
|---|---|---|
| Unspecified | 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
|
|---|---|---|
| Unspecified | 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 Unspecified and 1 is Demandbase). Basically Unspecified isn't what it seems and it's misleading in a report. The Unspecified row visits are accounted for in some of the other values.
Proving it
- 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 Unspecified 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.
- 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.