Beacon Blocking

[#1]

We're seeing some of our users blocking our beacon at the network level.  I'm guessing they're seeing the IP for our beacon on some sort of deny list since that IP is the same as Adobe.  Anyone have a good way around this?

[pramseycom · Accepted solution]

If the issue is an Adobe-blacklist you should look into first-party tracking--unless your IP is also on a blacklist.

Also, if it is blocking Launch/DTM code, you can host your own versions instead of using Akamai.

[pramseycom · Accepted solution]

So we use first-party cookies, but even though the beacon call is with our local domain, the IP it resolves to is still an Adobe one. My guess is that it's the IP that's in a deny-list vs the the subdomain we're using. Ideally what we'd be able to do is proxy, but I'm not sure what all is involved with that and the issues we may have.

[pramseycom · Accepted solution]

Actually this a partially correct answer, the launch hosting is solid, but the beacon itself is also getting blocked, smetrics.*/ss/b* is on public blocking lists, it also appears that some of the strings in the URL are also getting picked up by some lists.

[jkm-disco · Accepted solution]

@pramseycom , good find. Sounds like a clever blocking list. Luckily, you can actually create whatever CNAME records you want, as long as they resolve to Adobe's host. Maybe just come up with an uncommon naming convention and distinguish between secure/non-secure protocol.

[pramseycom · Accepted solution]

We also found blocking with *b/ss*AQB=*, which is a bit harder to get around.

[jkm-disco · Accepted solution]

Ah, yea, it sounds like there isn't much you can do to get around this. Do many of your users actually use this blocking list?

The only possible ways I can think of to get around this would be to either have Adobe modify their tracking servers (and subsequently the Launch code)--not very likely, or, the only thing that you could maybe do on your side, review the different methods for data insertion API and see if the those formats are on the block list. If not, you could integrate that API into your site (client-side) to manually push the data instead of using the conventional format and convenience of Launch.

Oh, and, with a bit more setup, a server-side integration could work as well: You could send the data insertion API requests server-side based on the data layer for that user. (So think--your own tracking server which basically just forwards the data to Adobe).

[pramseycom · Accepted solution]

The use of blocking lists and such will become more and more of an issue as privacy controls get baked into browsers natively. We could get to the point where the browser pops up a message saying "this URL is tracking these items about you"

[jkm-disco · Accepted solution]

Yea, but I doubt the average user would be okay with a million popups for every bit of blocked traffic. Most major sites use multiple tracking mechanisms where a user would get a list of blocked tracking every time they navigated to a new page. If this is something you suspect will be an issue moving forward, now might be the best time to begin work on an in-house tracking solution that is server-side. Though the data itself can be stored and reported from Adobe if you forward it to them.

I s'pose a reasonable solution for Adobe would be maybe include more dynamic, organizational-specific URLs/paths which would break the mentioned regex. Doesn't sound very technically difficult, but is still a major effort.