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"

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

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.

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 w...

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?

This would be good to have as a feature, can it be added? I should have better control over how Adobe perceives the calls I make to the system, instead of having it assume what I want.

But the next page load never happens, many of our customers come in from twitter and then close the browser. We're catching that "close" and submitting a beacon call as it's closed. Our bounce rates are normally in the 80's because people are reading and then leaving (also mostly on mobile). It woul...

Our bounce rate just got much lower, which we know isn't due to our brilliant content.  Seems that we're firing a direct call rule when the user leaves a page (this gives us the scroll depth, time on page, etc... for the user, which is then used to determine the quality of the story in question).  A...