Earlier quoted context omitted.
I very well could, but I'm not going to find out. All it takes is one blogger somewhere to see that I collect stats like "70% of my visitors block tracking" and then the smear pieces start with wonderful headlines like "X tracks users that explicitly disabled tracking" and I lose a significant portion of my user base. I've had it happen before, i'm not going to make the same mistake again. It's kind of a hamfisted ap…
if you block tracking, i'm going to treat you like you don't exist Are you saying that you ignore server logs?
The Google Analytics Setup I Use on Every Site I Build
71–80 of 108 posts
Re: The Google Analytics Setup I Use on Every Site I Build
#72Echoing what others are saying, I much prefer Google Tag Manager. Many clients use a CMS which make injecting dynamic variables into a page a bit of a pain if it's not done via rules at runtime. The Next Web has open-sourced its Google Tag Manager setup ( https://github.com/thenextweb/gtm ), which has things like Scroll Tracking, Engagement Tracking (riveted.js), Outbound Link Tracking and lots of other things that a…
Re: The Google Analytics Setup I Use on Every Site I Build
#73Earlier quoted context omitted.
Google Tag Manager is not very practical in cases where you want a secure website. It renders CSP useless because it requires all sorts of permissions like 'self' on scripts and CSS. It's good to have on the marketing webpage where no user content is displayed though.
Also worth noting--depending on your setup, GTM essentially allows arbitrary execution of JS for anyone with access to edit and publish containers. I'm a more technically inclined marketer, but I make damn sure to check with an engineer before trying anything fancy with JS, and I make sure to test with QA. But having stuff in GTM more or less means you have separate workflows for code outside of your existing repo. Y…
Re: The Google Analytics Setup I Use on Every Site I Build
#74Earlier quoted context omitted.
Isn't that a relatively easy thing for a spammer to change? Also, I'm seeing some valid traffic coming in with that language (conversions and everything).
Most won't bother
Re: The Google Analytics Setup I Use on Every Site I Build
#75Re: The Google Analytics Setup I Use on Every Site I Build
#76Earlier quoted context omitted.
What are the best alternatives?
piwik or just grep your nginx logs.
Re: The Google Analytics Setup I Use on Every Site I Build
#77Not many people know about this feature of GA, but add the following to anonymize your users IP addresses before sending the information to Google. > ga('set', 'anonymizeIp', true);
That's a nice placebo that does almost nothing. Even if the packet body doesn't contain the IP address, it's still available in the IP header's Source Address field.
However, even if we assume Google - in a reversal of their general focus on gathering as much data as possible - doesn't recover the address from the IP header, their own documentation[1] for analytics collection URLs with the &aip=1 parameter (which should be present when 'anonymizeIp' is true) says:
"... the last octet of the user IP address
is set to zero ..."
Zeroing the least interesting 8 bits of the address doesn't make it anonymous. They still get to record the ASN, and they are recording at least 8 bit of fingerprintable data from other sources. I should be trivial to recover mostly-unique users, and calling this "anonymization" is at best naive and for Google, an obvious lie.Their documentation even betrays their intentions:
"This feature is designed to help site owners comply
with their own privacy policies or, in some countries,
recommendations from local data protection authorities,
which may prevent the storage of full
IP address information."
Actually making the data anonymous isn't the goal. They just want a rubber-stamp feature that lets them comply with the letter of the law.[1] https://support.google.com/analytics/answer/2763052?hl=en
Re: The Google Analytics Setup I Use on Every Site I Build
#78- If you have multiple domains, sub domains, etc. make sure to spend plenty of time reviewing the cross-domain setup documentation and test it thoroughly.
- If you have high volume, frequently do deep segmentations, use lots of custom dimensions, etc., make sure you have a clear understanding of how sampling in GA works, how to tell if you are being sampled, and find ways to avoid it by pulling reports in different ways. Otherwise you can end up in a situation where you are making decisions off of .3% of your traffic and while Google's sampling algorithm thinks it is fine, comparison against other data sources often shows it is not.
- Make sure any reporting you do across things like GA vs. AdWords is done with a clear understanding of how they each report on paid search. GA reports on it by default on a last non-direct click basis. AdWords just counts everything AdWords touches. This means that AdWords can give you a good sense of where you are gaining traction, whereas GA can help you understand how it works in conjunction with other touch points, and perhaps how you might change the way you weight things and measure success.
- GTM is powerful and free, but with great power comes great responsibility. Also, it can be a real PITA sometimes.
- Annotations are a highly underutilized tool in GA and can save you a lot of headaches. I just wish there was a way to bulk import/export them via spreadsheet or API.
- You can't currently create goal funnels from event-based conversions (please Google add this!), but the workaround for the time being is to push virtual page views at the same as the event fires, and then create funnels off of those.
- User stitching sounds awesome, but is actually much more limited than you'd think from reading overview. You need a separate view (which means your main GA view you use can't segment for the stitched sessions for comparison--just the new view which only contains the stitched users). And there's a 90 day rolling data retention window, so you need some sort of export process if you care about that data. Unfortunately, this is pretty important data if you have lots of cross-device tracking issues.
- Depending on your volume, you can reach the hit limits of the free tier pretty quickly if you start tracking a ton of events (since they all count as hits). Here's a good overview [1] of what these limits are, how they work, and what they mean for you. When I got the scary notification, Google was exceptionally unhelpful in working with me to resolve the problem, despite considerable ad spend. After reducing them to what we thought would be fine, they were unable to assure me that our data would not be nuked, and basically couldn't give me any real info beyond "this is the policy." Super frustrating.
- If you have good logging of events that tracks both server and client-side, it is healthy to compare for variances monthly or quarterly. You'd expect client-side tracking to break more often than server-side, but it is important to see how much that can alter your numbers.
[1] https://www.e-nor.com/blog/general/hit-count-in-google-analy...
Re: The Google Analytics Setup I Use on Every Site I Build
#79It's pretty annoying that I have to create spam filters for Google Analytics to be useful. Every site I've installed GA on has required me to filter out spam. I don't understand why something isn't done about it at an engineering level. If site owners can set up filters against spammers, is it really that hard for Google to do it? Especially since they can see it across their accounts. Seems like it's the same type o…
You can get around this with some fairly simple hacks. Write some JavaScript that evals a part of your page or something crazy like loading part of itself from Rot13 text file. Have this js generate an ID you can identify as 'real' or 'fake'. Filter your analytics by this ID. If you want to be extra funny make real and fake IDs look indistinguishable to human eyes. 99.9% of spammers are too lazy to spend any time fig…