16

I'm considering using segment.io for several of my client-side 3rd party API needs, but I'm a little concerned about ad-blockers.

My app has no ads, but I do a lot of event-tracking for product analytics, as well as error tracking.

Segment.io offers a nice all-in-one solution, but if it's blocked, and all my eggs are in that basket, then, well, I won't have any eggs left, or however that idiom ends.

So my question is: is there a way to integrate multi-purpose event tracking (segment.io, keen.io, etc.) that isn't as susceptible to ad-blocking?

My app is mostly serverless, using a Firebase+AWS Lambda setup, so I've tried to think of some kind of back-end solution, but no big ideas so far.

ETA: I'm not looking to track adblocking users or violate anyone's trust. my question is about event-tracking unrelated to a user's identity, and whether or not that's possible in an all-in-one event tracking library that might be ad-blocked.

Brandon
  • 7,736
  • 9
  • 47
  • 72
  • 1
    If someone doesn't want to be tracked, don't try to work around it. Not only would you damage trust with your users, but there will always be a way to block tracking since the user is in control of the client system. – Matt S Mar 14 '16 at 19:49
  • thanks. my concern, though, is that a user, in an effort to not be tracked, would disable my ability to track other things, like errors or analytics not attached to the user's identity. the easy answer is to use separate libraries for non-identity-related things, but I'm hoping there's a way to use an all-in-one like segment and not have adblock hamstring all my event-tracking, identity-related or not. – Brandon Mar 14 '16 at 20:12

3 Answers3

13

First, I'd typically consider such blocking to be "privacy" blocking instead of ads. So instead of Adblock it's more likely to be Ghostery or uBlock Origin.

Although most website uses of analytics are benign (improving conversion rates, catching browser exceptions, etc), the concern many have is that it allows the third party analytics sites (including segment, etc) to track users across multiple websites. Now most of these analytics sites are also not interested in that, but better safe than sorry?

The ethics of wanting to have analytics about all your webapp use are far more nuanced than "privacy good, tracking bad" and I don't think this is the forum for it, so I'll provide you a technical answer. Just note that your disclaimer about not wanting to "track adblocking users" is not really valid. If your aim is to gather analytics about them, that's still essentially tracking. Otherwise just use a hosted solution and realise that maybe 10-20% of users don't provide you with analytics.

The bad news: basically every "hosted" analytics solution is or will be in the block lists. Not only are their API hosts directly blocked, but there are also blocks in placed based on the name of JS files you may try to include.

The good news: you can work around it if you relay events through your own API, and AWS API Gateway which you may already be using is perfect for this.

There are multiple steps to this.

Step 1: The analytics provider need to provide the option of a fully bundled/built JS file. If they require you to pull the script dynamically from their own servers then it will be blocked there before it even downloads.

Step 2: Rename the bundled script so that it doesn't trigger any filename-based blocks, e.g. rename from mixpanel.umd.js to mp.js, and add it to your server.

Step 3: Create an API gateway to relay events back to the "correct" API (e.g. to api.analyticshost.com). You can actually do this with AWS API gateway only (no lambda required) if you pass through the right headers and URL params.

Step 4: Initialise the library to use your API host rather than the default one.

The result of this is (a) the browser no longer needs to dynamically pull the analytics from the analytics provider's CDN, and instead gets it from your server, and (b) the browser sends it to your API and then relayed through to the analytics provider's.

rgareth
  • 3,377
  • 5
  • 23
  • 35
  • 1
    great, thanks for the thorough answer. you're right re: 'privacy' vs 'ad' blockers--I did some more research and found out that uBlock blocks segment's lib, but adblocker doesn't (both on default configs). but something like what you've outlined might be a great fallback for more important systems (eg, Sentry exception monitoring) if that 10-20% grows. – Brandon Mar 23 '16 at 22:32
  • 2
    I kind of made that figure up though - it entirely depends on the type of user base. For pure consumer, it would be in low percentages. Whereas if it's a SaaS product aimed at developers, it could easily grow beyond 10-20%. Beware also that privacy blockers also block exception trackers such as sentry, rollbar, trackjs, etc. So the worse case is (a) blocking your analytics causes and exception/problem, and (b) you don't even notice it as the exception tracking is lost too. This is why I'm looking to relay. – rgareth Mar 24 '16 at 04:54
  • 1
    Just wondering how/if this complies with GDPR rules and such... as it hides the tracking from the user but it's still being done. On the other hand, if Segment is disclosed in the privacy policy then... it's fine? – Edd Nov 15 '18 at 10:31
  • I guess that the script will send directly to Segment, so I would need to search and replace in the bundle from segment.com to my-own-gateway.com. Overall it looks risky if real things are a bit more complex. – Nicolas Zozol Dec 26 '22 at 14:15
2

When gathering analytics segment also provides server side tracking libraries. This can be quite useful when you want to gather metrics for certain types of events that might be blocked by users on the client. At it's simplest, Segment has an HTTP Source but there are a number of popular languages supported as well. https://segment.com/docs/connections/sources/catalog/#server

The classic example is the order complete event, this would typically happen in your server once that transaction has been committed to a database. Regardless of browser configuration, you could send this event from the server and track.

Be sure you respect the users consent management settings here though.

Troy Sellers
  • 66
  • 2
0

A lot of valid points are already mentioned in the accepted answer, I would mention a few technical considerations to minimize ad blockers impact on tracking tools (Segment, Google Tag Manager, etc):

  • Develop for server-side tracking. Whatever is on server cannot be blocked by ad blockers. However, this is usually tricky and very custom, Segment gives some examples on it as well.
  • Use managed client-side proxy solutions like DataUnlocker. This is great and does not require many code changes.
  • Use self-hosted open-source solutions for proxying Google Analytics and Google Tag Manager like this or this. I believe these solutions can be extended to support Segment as well.
ZitRo
  • 1,163
  • 15
  • 24