Mobile & Google Analytics (Analysis) - James Moore, CRO
Simpli.fi and Google have been partners ever since our founding, as we spend heavily on their exchange AdX and you could say we’re
‘Premier Partners’, if we cared to tout the title. This means that we go their offices and they fly to our offices and we work and
collaborate on a variety of topics; Google Analytics happens to be one that we usually discuss at the end of these quarterly meetings.
I can tell you that Google knows firsthand that GA is an free system that is outdated. Below I’m going to lay out multiple scenarios
that lead to either ‘no data’ or worse, ‘incomplete data’ for a GA session.
1. GA May Drop The Advertiser Tag
GA uses a Java Script Tag that is both asynchronous and requires a cookie to work properly (this is critical).
An asynchronous pixel simply means that if the page is loading slow, then the pixel breaks automatically to allow the page to not be
slowed down by it – it’s protection in a world where users expect fast page loads and advertisers will strip their sites dry if there’s
perception that anything is slowing it down and causing potential customers to go elsewhere – this isn’t anything strange but you
need to know – slow page load/bad wifi = GA tag drops to protect advertiser – this can cause the following:
● A ‘session’ but no ‘time on site’ – pulls down your time on site (ToS) averages
● This guarantees a registered ‘bounce’ – even if the users spends hours on the site navigating the site because the tag dropped
● This pulls down your ‘pages viewed’ metric also – even if the user navigated to many pages – no tag = no or incomplete info
2. GA Has A Real Problem With Apps
We all know that users and traffic are heavily moving towards mobile devices and App usage is growing through the roof. This is
great for us and it’s awful for GA. It’s awful for GA because of the following technical factors:
● Apps don’t drop cookies – GA requires a cookie – no cookie = no or incomplete info
● Mobile browser settings allow for cookie blocking – GA requires a cookie – no cookie = no or incomplete info
● The users and traffic know nothing of this, or care. They can have long time on site, multiple page viewing sessions, and not bounce and NONE
of this is counted in GA and if the info is incomplete, it would actually register at ‘less than 1 second’ for ToS, up the Bounce Rate, and pulled
down PV averages = no data is better than incomplete data.
● Mobile is the fastest growing space for users and our companies, so you cannot avoid this but you cannot fix it because the GA JS Tag simply
requires a cookie and there’s no way to avoid this
3. GA Claims HTTPS Traffic As DIRECT
Google bought the company Urchin Software some 10+ years ago. They relabeled the product into GA. This software works best in a
desktop environment that is pro-cookie. The landscape has changed dramatically with the rise of both Mobile/App & RTB/
Programmatic – here’s where RTB poses challenges and limitations to GA:
● Sites who put inventory into RTB exchanges are often secured or HTTPS. Makes sense, they’re high traffic sites who are seeking exchanges to
monetize all the pages/placements they cannot sell on their own. These busier sites have likely converted to HTTPS, from HTTP long ago –
that’s the landscape
● Referrer information is needed to complete the GA data story, or Referrer URL, the site where the banner was served and the user clicked thru
from. Example – NY Times is HTTPS and Matt clicks on the 300 x 250 and goes to a local pizza restaurant’s site that is an SMB and HTTP (not
secured)
● A secured site/HTTPS will not pass referrer information to an unsecured site/HTTP – this likely happens often in RTB/Programmatic with local
SMB client bases
● If referrer information cannot be passed, GA gets incomplete information, and either routes the incomplete data into ‘Direct Traffic’ or ‘Other’,
even though it was 100% ‘Referrer Traffic’ and could have had a wonderful session, the information is complete – see all aforementioned
problems with incomplete information
4. GA Falsely Reports Out Of Market Clicks:
RTB exchanges will test and thus generate ‘test clicks’ all the time and this is a good thing, it’s done to ensure quality ads are being
served and it provides countless other safeguard measures. However, GA captures every one of those clicks and Google employees
themselves have called it a dumb system because of this. It cannot filter a ‘real click’ from a test click, and it doesn’t care to. It’s
trying to tell the site owner all that happens and remember, it was created and added upon in a world that was pre-RTB and test clicks
by exchanges. Here’s how it happens:
● AppNexus (an exchange) pings our ad server to generate a test click
● Our system knows this is a test click because there is no money changing hands via the clearing price that would have been tied to the Media –
like NY Times cleared for $1.25 – it comes back to us at $0.00, so we know it’s a test click, scrub it out of our system and move on – this
happens daily and across exchanges and ad servers all over the world and certainly outside of the UK
● GA registers the click, because it registers it before the clearing price has come back at $0.00 – hence a dumb system.
● We have our test server called ‘Adspreview.Simpli.fi’ and it’s where the overwhelming majority of our test clicks come from – GA doesn’t know this
is used for this purpose and counts all ‘clicks’ from here
CTR performance from a campaign should always, and only be derived from the platform that was serving the campaign. Simpli.fi
does not count test clicks, it does not count crawlers or any type of mechanism used to test for malware or fraud, we simply count the
human clicks and therefore our numbers in our system are actual clicks that have been scrubbed of items like this. GA, as we know,
doesn’t scrub a test click because it doesn’t know what a test click is. What else does it not know, count, and then create confusion.
To use GA’s clicks for CTR is a losing game, and one that is purely inaccurate. Especially given the obvious misses that it has.
A friend of mine works for Google, in fact, she works for the SMB division and she trains business owners and media companies on
how to ‘best’ use GA. In her trainings, she expresses the best uses for GA are these:
● Use it to establish a pre-campaign baseline of site activity
● Review the devices that people use to find your site
● Review ‘Sources’ so you know how people are arriving at your site
She says that it’s best used to draw broad knowledge, and not minute details. She also says that she puts ZERO time, training, or
encouragement in the following:
● Time on Site – this can be inaccurate in too many ways and it’s not indicative of a bad user experience
● Bounce Rate – this too can be inaccurate in too many ways and depending on the actual page, it could provide all needed information for the
user’s purpose
● ‘Unknown’ or ‘not available’ – even Google doesn’t know everything and you’ll have information that’s lumped into this bucket – if it’s unknown,
keep in mind, it still is incomplete numbers that are put against all averages
To my knowledge, you are able to filter out test clicks from certain traffic delivery sources – as I understand it though, this only
removes them from your view and doesn’t not remove their numerical averages out of your overall GA numbers. So if a test click has
less than one second of ToS, is a Bounce, and has one PV, then it’s all still pulling your numbers down considerably and filtering just
removes it from view, not the stats.
There is one more piece to this and it’s called ‘Sampling’. When Google’s servers are busy, which they often are, it means there’s
bandwidth pressure like we all face. Google wants to make sure when people use their system, in any capacity – Search, email, GA, etc.
that it’s both fast and good user experience. If a person goes to pull their GA numbers and let’s pretend they’re not just pulling the last
‘two months’ but rather a YOY comparison or simply a larger date range. If there is pressure on Google’s servers then they will institute
a process called ‘Sampling’. Sampling is basically them spitting out a GA report with the requested date range that is just that, a
sample of what likely happened on your site. That’s right, what ‘likely’ happened or is an averaged slice of what happened. This is done
so you get your information fast, and have a good user experience. Good user experience is based upon being FAST, not ACCURATE.
All of these problems that I’ve outlined have not only been told to me by Google employees themselves, but are also super easy to find
in Google’s own search engine itself. GA is simply a tool used to grab a very broad picture of what’s happening on your site and as my
SMB friend who trains on GA’s best usages says, use it for baseline and to see where people are coming from to your site – nothing
more. If you have a lot of mobile traffic – make sure your mobile site is good. If you have lots of traffic from NY Times, then deduct
what you want to think it means.
GA is simply a free tool that is not purpose built for both RTB/exchange based ad serving (where it’s all going) and only works best in
the presence of a cookie (Apps/Mobile make this incredibly challenging)
I hope this helps.
I have had great success in the US with local business owners buying thru newspaper partners like you by getting them to under the
basics of how to use it and how not to use it. And above all, GA’s inadequacy does not mean Simpli.fi or any other DSP isn’t providing
value, driving great traffic to your site, and achieving all you need. It just means that GA cannot report back on it like we all direly wish
it could.