1

Tracking analytics for users that have ad blockers installed

A substantial portion of our user base has ad blockers installed that block Segment and prevent us from collecting analytics on them. (Our frontend is decoupled so all analytics are collected on the client.) We would really like to collect analytics on those users. One solution could look like this:

- Include the Segment JavaScript library in our frontend codebase instead of loading it from a third party
- Enable the new Cloud-Based Connection Mode in Segment
- Somehow configure Segment to send analytics requests to an endpoint on our backend instead of to the Segment remote endpoint
- Set up that endpoint on our backend which just transparently forwards all requests to the Segment remote endpoint

We might lose IP-based stats, but we can live with that.

Is something like this possible now, or could it be done in the near future?

6replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
  • Hey Isaac, and thanks for writing in. I'm not sure that Cloud-Based Connection Mode would help at all in this case - our Analytics.js library would still need to load to your page; this connection mode simply forwards events from our servers to downstream integrations. Otherwise events are sent directly from the user's browser.

    I also wouldn't suggest hosting Analytics.js locally, since you'd then be responsible for pulling down a new version of the library each time you update your integration settings in the Segment UI. Rather, a potential workaround here may actually be to browserify our Node library. Let me know what you think!

    Upvote
  • Hi Brennan,

    I'm not sure that Cloud-Based Connection Mode would help at all in this case - our Analytics.js library would still need to load to your page; this connection mode simply forwards events from our servers to downstream integrations. Otherwise events are sent directly from the user's browser.

    I understand how this works. In the process I proposed above, Analytics.js would load on our pages from our own domain instead of from cdn.segment.com , which is blocked by ad blockers. The reason Cloud-Based Connection Mode could help is that I'm proposing that Analytics.js could send events to our own domain instead of to api.segment.io and other integrated endpoints (e.g. api.amplitude.com), which, again, are blocked by ad blockers. Then we could forward the events to Segment and Segment could forward them to other providers. Without Cloud-Based Connection Mode, we'd have to load a bunch of third-party libraries that would each send events to their own domains, all of which are blocked by ad blockers, and so we'd need to implement a solution for each integration individually.

    What I'm trying to avoid here is writing our own client-side library that calls an API of our own that then translates those calls into Segment library calls on the server side. It would be easier if we could just tell Analytics.js to send its events to us, and then we could transparently forward them.

    I also wouldn't suggest hosting Analytics.js locally, since you'd then be responsible for pulling down a new version of the library each time you update your integration settings in the Segment UI.

    Is this true even for services that work with Cloud-Based Connection Mode, and if so, why would Analytics.js need to know about them?

    Rather, a potential workaround here may actually be to browserify our Node library.

    I assume that you're suggesting this because the Node library just talks to Segment's HTTP API whereas the JS client library normally imports and then talks to other client-side libraries. However, I don't understand why the JS client library would behave differently than the Node library in this respect when no other client-side libraries are loaded for the integrations, which is what I understand to be the case in Cloud-Based Connection Mode.

    Regardless, this might be a fine way to load a script from our own domain that gives us a straightforward way to call Segment from the client, which would address the first part of the problem I'm facing. I'd be concerned about the performance characteristics though.

    Upvote
  • Hey Isaac, to boil everything down, the cloud-based connection mode option isn't available for all integrations - at the moment it is available only for Adobe Analytics, Mixpanel, Amplitude, Keen.io , Vero, and Customer.io . In this case, to ensure that Segment data is sent to integrations that don't support cloud mode via Segment, you can browserify our Node library. Hope this helps!

    Upvote
  • Brennan - thanks for your responses. We are only using Amplitude and Slack at the moment so that's not a concern for us. I have determined that it is possible to take the approach I proposed above with Amplitude separately from Segment, but I'd prefer to do it through Segment. Sounds like that's not a supported approach though.

    Upvote
  • Hey Isaac, correct, going back to your original post, no, configuring Segment to post to a custom endpoint is not a feature we support, although you are welcome to attempt to build this yourself and share it here! 

    Referencing:

    - Somehow configure Segment to send analytics requests to an endpoint on our backend instead of to the Segment remote endpoint
    - Set up that endpoint on our backend which just transparently forwards all requests to the Segment remote endpoint

    Upvote
  • Hey Isaac Sukin  did you find the way to configure segment post to a custom endpoint? if yes then can you share me the idea, if not then what approach you applied to solve same.

    Thanks in advance

    Upvote