Google Analytics Reporting

How to Figure Out Origin of Direct Traffic

Original question from Quora:

How do I figure out where direct traffic in Google Analytics found my website in the first place? No one just enters a URL of a website first time visiting it; they need to know about the website through ads, organic search, referrals etc.

The short answer is: you can’t. The fact that the traffic is being classified under “Direct” by definition means that there is no referring information for Google Analytics to use to determine where the user came from.

You’re right that it seems strange and unlikely that someone’s first visit to a website would start by them typing in the URL, so here are a couple of possible explanations for that:

  • It’s not actually the user’s first visit. These days browsers are deleting cookies more aggressively and more users are adopting ad/tracking blockers. GA’s new / return visitor dimension depends on the GA cookie being present. If the GA cookie gets deleted for whatever reason, when that user comes back (even if they have been to your site dozens of times) they will look like a new visitor in the GA data.

  • Referral data or UTM parameters are getting stripped. It’s not unheard of for those details to get lost if there are a lot of redirects in between the origin site and the destination site. There are also some sites that are configured to strip any non-whitelisted URL parameters before the page (and therefore the GA tracking code) loads.

  • Vanity URLs. If you’re doing offline marketing where you’re using vanity URLs like and you don’t do anything special to flag those referrals in GA, they’ll come through as direct.

My heart always sinks when I’m digging into some anomaly and find that it’s related to direct traffic because that’s virtually a dead end for my investigation. You can try breaking down direct by landing page to get some sense of which page the user started on. If it’s a page deeper in the site, it might give you a hint to how/why they got there. But odds are it’s the homepage, and you’ll be stuck in another analytical dead end.

I wish I had a different and more helpful answer for you, but this is one of the painful and annoying realities of digital analytics!

Google Analytics

Understanding Time on Page / Time on Site / Bounces in Google Analytics

I have clients who put a lot of focus on time-spent metrics like “time on page” or “average session duration,” and there is a lot of time spent on my part making sure everyone understands how those metrics are counted (and how misleading they can be). It’s a common misconception that there is a countdown timer ticking on each page, and that said counter is only running when someone is actively looking at / scrolling down the page in the active browser tab, and that the counter stops when someone closes the tab or browser.

Sadly, those are completely inaccurate assumptions and often lead people to misinterpret what’s in those reports.  All time-spent metrics are calculated based on timestamps of when packets of data are sent to your reporting tool. The reporting tools have no idea whether or not your users were actively on your site, only that beacons of data are sent. Here’s a good example of why time-spent metrics shouldn’t be blindly trusted:

  • Best case scenario: If you were on Page A at 12:00pm and stayed engaged reading the page for a few minutes and navigated to Page B at 12:02pm, Google Analytics would show that your time on Page A was 2 minutes. Great!
  • More realistic scenario: If you were on Page A at 12:00pm, got distracted and looked at another site in another browser tab for 10 minutes, then had to take a 10 minute phone call, then finally returned and navigated to Page B at 12:20pm, GA would show that your time on Page A was 20 minutes. No it wasn’t, yikes!

Rather than using these types of passive metrics which can be misleading, I recommend using metrics that show users actively engaging: page views per session, scroll event tracking, page depth, etc. But if you do want to continue using the time-spent reports, it’s important to understand exactly what is being calculated and how.

  1. All time spent metrics are simple difference calculations based on timestamps of when hits are sent to GA.
  2. Average Session Duration is the difference between the timestamps of the first and last hits of the session (and that final hit can be either a pageview or an event). If only one hit happened in the session, the average session duration will be 0 since there is no second timestamp to perform the calculation. (Google Help Article)
  3. Average Time on Page is the time difference between subsequent pageviews. The final page (or in cases of single page visits the only page) will have a time on page of 0 because the subsequent timestamp is not there for the calculation.
    • Note that events are not taken into account on time on page calculations.
  4. Bounces are sessions that only trigger one hit, and that hit can be a pageview or an event. If a user only visited one page and incremented 1 single pageview but scrolled down enough to make a scroll event fire, that’s 2 hits and therefore they will not be a bounce. (Google Help Article)
    • Note that GA has an option for “non-interaction events” which were designed to be ignored for the purposes of bounce rate.

I always find it helpful to see detailed examples, so I generated data for a few scenarios to illustrate:

Session 1:
3 Pageviews, 0 Events

Page 1 @ 2:58pm
Page 2 @ 3:00pm
Page 3 @ 3:02pm

  • Avg Session Duration = 4 minutes (3:02pm minus 2:58pm)
  • Bounce Rate = 0%
  • Page 1 Avg Time on Page = 2 minutes (3:00pm minus 2:58pm)
  • Page 2 Avg Time on Page = 2 minutes (3:02pm minus 3:00pm)
  • Page 3 Avg Time on Page = 0 minutes (there is no subsequent timestamp to calculate)

Session 2:
3 Pageviews, 2 Events

Page 1 @ 3:02pm
Page 2 @ 3:03pm
Page 3 @ 3:04pm
Event A @ 3:05pm
Event B @ 3:10pm

  • Avg Session Duration = 8 minutes (3:10pm minus 3:02pm)
  • Bounce Rate = 0%
  • Page 1 Avg Time on Page = 1 minute (3:03pm minus 3:02pm)
  • Page 2 Avg Time on Page = 1 minute (3:04pm minus 3:03pm)
  • Page 3 Avg Time on Page = 0 minutes (there is no subsequent pageview timestamp to calculate)

Session 3:
1 Pageview, 1 Event

Page 1 @ 3:10pm
Event A @ 3:12pm

  • Avg Session Duration = 2 minutes (3:12pm minus 3:10pm)
  • Bounce Rate = 0%
  • Page 1 Avg Time on Page = 0 minutes (there is no subsequent pageview timestamp to calculate)

Session 4:
1 Pageview, 0 Events

Page 1 @ 3:13pm

  • Avg Session Duration = 0 minutes (there is no subsequent timestamp to calculate)
  • Bounce Rate = 100%
  • Page 1 Avg Time on Page = 0 minutes (there is no subsequent pageview timestamp to calculate)

Session 5:
2 Pageviews, 1 Event, 1 Pageview

Page 1 @ 3:32pm
Page 2 @ 3:34pm
Event A @ 3:36pm
Page 3 @ 3:38pm

  • Avg Session Duration = 6 minutes (3:38pm minus 3:32pm)
  • Bounce Rate = 0%
  • Page 1 Avg Time on Page = 2 minutes (3:34pm minus 3:32pm)
  • Page 2 Avg Time on Page = 4 minute (3:38pm minus 3:34pm)
    • NOTE: this is ignoring the event and is calculating the time difference from the previous pageview
  • Page 3 Avg Time on Page = 0 minutes (there is no subsequent pageview timestamp to calculate)

Hopefully that clarifies exactly how things are counted, and will empower you to interpret those reports correctly!

Google Analytics

When Does a Google Analytics Session Expire, Really?

One of the many ways that Google Analytics and Adobe Analytics differ are their individual definitions of what constitutes a session. Both abide by the industry standard of a session ending after 30 minutes of inactivity*.

* Unless you’ve changed the session timeout setting in a Google Analytics property, or the visit definition/visit timeout setting in an Adobe Analytics virtual report suite.

But Google Analytics has an additional trigger for ending a session that can be a real gotcha when trying to matchback data across the two tools: it ends a session and starts a new one “every time a user’s campaign source changes.” That statement always perplexes me because I’m not sure whether to interpret that as:

  1. when any UTM parameter changes, or …
  2. when only the utm_campaign parameter changes

I always assumed #1, but I decided to test this out so I’d be 100% sure. In each test scenario below, I opened a new guest browser window so none of my activity from each test would overlap.

If all other UTM parameters are the same but utm_medium is different, it will start a new session.

The proof: I loaded two URLs with identical values for utm_source, utm_campaign, and utm_id, but different values for utm_medium.

When I pull up the report by one of the other parameters, it shows two sessions, validating that a new session was started when I loaded that second page.

If all other UTM parameters are the same but utm_source is different, it will start a new session.

The proof: In a new, fresh guest window, I loaded two URLs with identical values for utm_medium, utm_campaign, and utm_id, but different values for utm_source.

Again, two sessions:

If all other UTM parameters are the same but utm_campaign is different, it will start a new session.

The proof: In a newer, fresher guest window, I loaded two URLs with identical values for utm_medium, utm_source, and utm_id, but different values for utm_campaign.

How many sessions? Two sessions!

If all other UTM parameters are the same but utm_content is different, it will start a new session.

The proof: In the newest, freshest of guest windows, I loaded two URLs with identical values for utm_medium, utm_source, and utm_campaign, but different values for utm_content.

Two sessions:

If all other UTM parameters are the same but utm_term is different, it will start a new session.

The proof: I loaded two URLs (in yet another guest window) with identical values for utm_medium, utm_source, and utm_campaign, but different values for utm_term.

This is getting boring and predictable, two sessions:

If all other UTM parameters are the same but utm_id is different, it will start a new session.

The proof: Another test, another guest window. I loaded two URLs with identical values for utm_medium, utm_source, and utm_campaign, but different values for the elusive and not-often-used utm_id.

Dos sessiones:

So there you go. Irrefutable evidence that a new session starts on change of any of the following:

  • utm_medium
  • utm_source
  • utm_campaign
  • utm_content
  • utm_term
  • utm_id
Adobe Analytics Google Analytics Implementation

Is it a good idea to run two digital analytics tools in tandem?

These questions come up a lot:

“Is it a good idea to run a double analytics implementation on one site/mobile app (i.e. Adobe + Google)?”

“Can we install GA and Adobe Analytics on the same website or do they conflict?”

You can add as many tracking tools as you want, they won’t adversely affect each other. I’ve seen companies that have Adobe Analytics, Google Analytics,, Mixpanel, and Coremetrics installed on the same site concurrently. It might affect page load time, but won’t affect data quality.

While you technically can have multiple tools in place, it doesn’t always mean you should. As a consultant I feel like I should have to put a dollar in a jar every time I say, “It depends,” but… it depends. Some of my clients do this, most don’t. There are reasons to do it, and reasons to avoid.

Advantages of tracking with two different tools:

  • A second source of data can be very handy for validation purposes or as a backup in case something catastrophic happens with the other tool.
  • Adobe is strong in some areas where GA is weak, and vice versa. Having both implemented gives you the best of both worlds.
    Novice analysts will be able to ramp up on GA faster, but seasoned analysts might be frustrated by the limitations of GA and need the more sophisticated functionality of Adobe.
  • Most companies use AdWords, so it’s likely that GA is already in place, anyway.

Disadvantages of tracking with two different tools:

  • $$$ – Assuming you’re on GA360, then you’re paying for two tools.
  • Double the tools, double the maintenance. New tagging requests will likely need to be implemented separately on each tool.
  • The idea of “one source of truth” can get muddied if you don’t have strong governance in place to choose and enforce which one is your system of record. Analysts could potentially cherrypick data and provide biased analysis.
  • You will inevitably end up down the data discrepancy wormhole when users report that the data from Adobe vs. GA don’t match perfectly . Expect to spend time and resources investigating those issues and/or educating your user base that it is normal and expected for two tools to yield slightly different data and to not freak out about a 2% variance.

If the advantages are something that you need and the disadvantages are something you are equipped to deal with, then running two tools in tandem might be a good option for you.

If the cons outweigh the pros, save yourself the $$$ and the trouble of implementing and maintaining two tools.

Cross-posted from

Adobe Analytics Google Analytics

Does Adobe Analytics Have Its Own Version of Google’s Custom (UTM) URLs for Campaign Tracking?

Adobe Analytics has similar functionality, but it works slightly differently.

Adobe Analytics has a pre-defined variable called s.campaign which is reserved for campaign tracking. However, the URL parameter that sends data to s.campaign is NOT pre-defined. As is usually the case with Adobe Analytics, it’s customizable and you can choose your own query string parameter. My clients often use “cid” or “cmpid” or “camp,” but you can use whatever you want.

In order to map data from that query string parameter to s.campaign, you’ll either need to:

    1. Implement the getQueryParam plugin.
    2. Specify the parameter and map it to s.campaign in your tag management tool.

In Google Analytics, there are five dimensions related to campaign tracking: utm_source, utm_medium, utm_term, utm_content, utm_campaign. Adobe Analytics was designed to use only one dimension / campaign ID, and then to supplement that unique campaign ID using classifications (formerly known as SAINT). These classifications add supplemental data into Adobe Analytics using that campaign ID as a key, and can be accomplished by either uploading a lookup table, or using Classification Rule Builder to write logical/conditional rules to automatically generate the classifications on the fly.

One benefit of Adobe’s method is that it gives you far more campaign-related dimensions. With Google Analytics you get five, but in Adobe Analytics you can have up to 30 classifications. I typically see classifications for Channel (paid search, display, social, email, etc.) and Campaign Name at a minimum. But it’s completely customizable and you can use it for whatever makes sense for your company: the Campaign Manager responsible for a campaign, what day of the week / time of day an email was sent, ad placement size, ad network, etc.

Another benefit of the classification method is that you can retroactively add or modify the supplemental data. If a campaign manager accidentally passed the wrong values to any of the utm campaign tracking parameters in Google Analytics, the data will be incorrect in the reporting. (It would be possible to write some transformation filters to correct it, but it would be a pain and not scalable.) In Adobe Analytics it would be a simple matter of either correcting/re-uploading the lookup table, or correcting the rules in Classification Rule Builder.

As far as what values to pass to s.campaign, here are the two most common and effective ways to handle:

    1. Using a obfuscated campaign ID – The value in the query string parameter would be some value like “234987423,” and then all the details about that ID would be captured elsewhere, i.e. in a simple spreadsheet, within campaign planning software, or in a tool like Tracking First | Campaign Code Validation. Then the supplemental data would be exported from that other tool and imported into Adobe Analytics.
    2. Using a concatenated series of values – The value in the query string parameter would be a delimited, concatenated series of values like “soc:111:555,” where “soc” is a reference to the channel being Social, “111” is Campaign = Memorial Day, and “555” is Partner = Facebook. Using Classification Rule Builder you can parse those three delimited values apart using regex, and dynamically populate “soc,” “111,” and “555” into their respective classifications.

      If you wanted to get fancy, you could also use sub-classifications (a classification on a classification) to give a friendlier name to the other values so instead of seeing “111” as a line item in the Campaign report, it would say “Memorial Day.”

So while Adobe Analytics doesn’t work exactly like Google Analytics, it does have similar (and arguably more sophisticated) campaign tracking functionality. The difference is that there is a lot more upfront configuration work to set up Adobe Analytics campaign tracking, whereas Google Analytics campaign tracking is ready to go out of the box. But on the flipside there is a lot more flexibility and ability to customize the data in Adobe Analytics, where you’re just stuck with the default in Google Analytics.

And honestly you can extend that observation to any feature that exists in both tools!

Cross-posted from

Adobe Analytics Google Analytics

What are the biggest differences between Adobe SiteCatalyst and Google Analytics Premium?

The short answer I always give is that Google Analytics is like a one size fits all t-shirt, and Adobe Analytics is like a custom-tailored suit. The rest of my answer is not so short.

Google Analytics:

  • The standard reporting interface is usually easier for beginners to learn, but isn’t very flexible when you want to orient the data differently than the default. Same goes for dashboards.
  • With Universal Google Analytics there are a lot more implementation options than there were in Classic Google Analytics, including far more ecommerce tracking options, along with custom dimensions and metrics. With enhanced ecommerce you can now track products from product impression to product view to cart to checkout to purchase, where in Classic GA you can only track products on the order confirmation page. With non-Premium Google Analytics you get 20 custom dimensions and 20 custom metrics. With Premium you get 200 custom dimensions and 200 custom metrics. However, the amount of customization and the degree to which you can configure these custom dimensions and metrics are very limited compared to Adobe.
  • One of Google Analytics Premium’s selling points is you get unsampled data, but to be clear, you do NOT get unsampled data in the browser-based reporting interface. You simply get an option to download the unsampled data into a .csv or .tsv file.
  • With Premium you also get support service, which I believe is Google partnering you up with an official Google Analytics third-party partner.

Adobe Analytics:

  • The standard reporting interface has always been super flexible. You’ve always been able to drag whichever metrics you want into a report, breakdown line items by other dimensions, and customize the reporting menu to your company’s needs and internal terminology. And now with their new Analysis Workspace interface that launched on 9/17/2015, it is even MORE flexible. Honestly, Analysis Workspace is the most nimble digital analytics interface I’ve ever seen. You can pivot and segment the data quickly and easily, and the load time is extremely fast.Adobe has other ancillary tools like Report Builder which is an Excel add-in, Ad Hoc (formerly known as Discover) with very powerful segmentation features, and Data Workbench (formerly known as Insight) which allows you to pull in other data sources.
  • The implementation options are really only limited by your imagination and availability of dev resources to put them into place! In regular Adobe Analytics you have 75 eVars and 100 events, and in Adobe Analytics Premium you get 250 eVars and 1,000 events. Each individual eVar can be customized on which value gets credit for conversions (first click / last click / shared) and how long values get credit for conversions (time-based, session-based, or on the completion of some other event). Similarly with events, they can be configured to be incremented, deduplicated per session, or deduplicated across multiple sessions with the use of some unique ID.Not to mention you can easily create calculated metrics in Admin, too.
  • Data is always unsampled.
  • Support is usually directly with Adobe’s account team or Adobe Client Care. The account team seems to be far more focused on selling you other tools in the Marketing Cloud than helping you with the ones you’ve got, and Client Care is usually worthless.

I like that Google Analytics gives you more out of the box to start with and there is less need to implement or configure the basic types of reports that are applicable across all sites (pages, campaigns, products, etc.)

On the flip side, I like that Adobe is so customizable and so flexible. This is a blessing and a curse. As others have stated, the quality of Adobe Analytics data is totally dependent on how well it is implemented. Going back to my original analogy, imagine someone who only knows how to sew on a button trying to sew an entire custom-fitted suit from scratch!

Cross-posted from