I’ve been a web analyst at InfoTrust for nearly four of the five years I’ve worked here. During those years, I’ve hosted dozens of trainings and answered hundreds (if not thousands!?) of questions. Over time, lo and behold, I began to see a pattern. What started as a small document of FAQs has evolved into a full database of questions and answers!
So, where is this database, you ask? I have good news! Today I am officially unveiling part of my super secret database of Google Analytics Frequently Asked Questions to the world. Most of this post is not overly technical, but the questions are so common that I recommend learning these inside and out.
Without further ado, let’s start with a fun one:
Essentially, a New User is a user that arrives on your site and does not already have the Google Analytics cookie present on their browser. They may have never been to the site before, have been there before but deleted the cookie, or visited the site before but on a different device or browser. Any of these situations would be considered a new user. A Returning User would be a user that has the Google Analytics cookie present on their browser and Google Analytics identifies that they’ve been to the site before by the users Client ID, a dimension stored in the cookie.
Here’s where it gets interesting: a user can be both a New and Returning User in the same time period. Example below:
John visits my site on Day 1 for the first time. John is a New User. Cookie set. John then visits my site on Day 2, cookie is already set, GA can identify John was on the site yesterday. If I pull a time period that includes both Day 1 and Day 2 in it, John will be both a New and Returning User, but count as just one “User” in that time period. So, New + Returning Users does not always = Total Users.
For websites with a lot of hits, you may see a “high-cardinality” message at the top of your window. When there are a large number of possible values, reports containing these high-cardinality dimensions are affected by Google Analytics system limits. The main reason for this “high-cardinality” error, according to Google Analytics, is that processed tables speed up reporting. This results in the creation of (other), which contains the data that exceeds these limits. The dimensions rolled-up into (other) change day-to-day depending on volume. Sorting by a certain dimension/metric won’t change the data that’s been removed and set as (other).
What is shown in these reports are in fact determined by what dimension is the most “popular.” “Popularity” is based on how many GA hits were received for that dimension. In the example of products, it doesn’t matter whether or not the product was purchased, but instead how many interactions there were with it (e.g. clicks, impressions, etc).
The simple answer to why this happens with reports is that the scope of the dimensions you’re working with are different. For example, landing page, page, conversion rate, etc. are all session-level dimensions, whereas eCommerce dimensions like product price displayed, product SKU, average price, etc. are all product-level dimensions.
So, unfortunately, the two different dimension scopes can’t be used in the same report. If you try, you’ll nullify all the results in your report.
You cannot see Search Console data from the two most recent days, so this is not a bug. Easy answer, but I get the question all the time!
Unfortunately, name, email, phone, etc. are all considered PII – Personally Identifiable Information. For privacy reasons, Google Analytics cannot collect them anywhere – custom dimensions/metrics, event labels, etc. However, you can use the “User ID” dimension from GA to connect a user from Google Analytics to your internal CRM, thus effectively identifying them.
The total revenue on the events report isn’t an accurate measurement, because it could have revenue counted multiple times. For each row that shows an event, the revenue metric is essentially if a transaction happened in the same session an event occurred.
So if event A had a transaction for $100 in the same session, event A would look like revenue = $100. But if in that same session, event B occurred, then event B would also show $100 revenue in it’s row, thus making the total revenue added together = $200, which in aggregate isn’t correct, but is correct at the per-event level.
Product revenue (from the product performance report) equals the product price in the dataLayer. Product revenue is almost always higher than revenue because it does not include order-level coupons/discounts.
Revenue (from the sales performance report) equals the total order revenue. You should always use Revenue as your primary reporting metric since it includes coupons/discounts. The two are meant to be completely different metrics used in different ways.
And there you have it – the highlights from my FAQ database. What are your Google Analytics questions? Post a comment below if you can think of something that should be added to this list!