As mentioned at T251464 https://phabricator.wikimedia.org/T251464, EventLogging https://www.mediawiki.org/wiki/Extension:EventLogging is currently blocked by EasyPrivacy https://easylist.to/ (a popular add-on for ad blocking software) due to EventLogging sending its data to a URL that includes the blacklisted string "beacon/event". In some cases, this makes it difficult or impossible for us to get the analytics data we need to make product decisions, e.g. T240697 https://phabricator.wikimedia.org/T240697. Two questions:
1. Is it reasonable to say that ad blockers should not be blocking EventLogging (since it's just an internal logging system)? 2. If the answer to #1 is "yes", could we change the URL that EventLogging uses so that it is no longer blacklisted by ad blockers?
Hello,
What are the problems you see with the beacon being blocked when it comes to extracting value from data?
In most instances what we look when deriving insights are ratios. For example: "of the people that saw the red link how many clicked it". In this scenario, with an adequate sample sizes, insights can be extracted without any issues.
Is it reasonable to say that ad blockers should not be blocking
EventLogging (since it's just an internal logging system)? Addblockers prevent requests to beacons, them being used for internal stats or otherwise (ad serving) so yes, it is pretty reasonable. A beacon does not necessarily imply it is used for adds [1]
If the answer to #1 is "yes", could we change the URL that EventLogging
uses so that it is no longer blacklisted by ad blockers Any url we use it is likely to be blacklisted by blockers that use lists in the absence of it being explicitly whitelisted. So, a naming change will have just a short lived effect.
Another way to proceed is the opposite: whitelist the url so it is not blocked by the blockers that -like adblocker- rely on lists. Now (since not all blockers work with lists. Example: Privacy Badger) that is by no means a 100% guarantee that data would not be blocked.
Thanks,
Nuria
[1] https://en.wikipedia.org/wiki/Web_beacon
On Tue, Sep 22, 2020 at 10:50 AM Ryan Kaldari rkaldari@wikimedia.org wrote:
As mentioned at T251464 https://phabricator.wikimedia.org/T251464, EventLogging https://www.mediawiki.org/wiki/Extension:EventLogging is currently blocked by EasyPrivacy https://easylist.to/ (a popular add-on for ad blocking software) due to EventLogging sending its data to a URL that includes the blacklisted string "beacon/event". In some cases, this makes it difficult or impossible for us to get the analytics data we need to make product decisions, e.g. T240697 https://phabricator.wikimedia.org/T240697. Two questions:
- Is it reasonable to say that ad blockers should not be blocking
EventLogging (since it's just an internal logging system)? 2. If the answer to #1 is "yes", could we change the URL that EventLogging uses so that it is no longer blacklisted by ad blockers?
-- *Ryan Kaldari* (they/them) Director of Engineering, Product Department Wikimedia Foundation https://wikimediafoundation.org/ _______________________________________________ Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics
Is it reasonable to say that ad blockers should not be blocking
EventLogging (since it's just an internal logging system)? Addblockers prevent requests to beacons, them being used for internal stats or otherwise (ad serving) so yes, it is pretty reasonable. A beacon does not necessarily imply it is used for adds [1]
I was just replying the same thing as Nuria, but I'll make a quick correction here: I think Nuria means it's reasonable for them to block EventLogging, not the opposite (which is what Ryan asked)
In most instances what we look when deriving insights are ratios. For example: "of the people that saw the red link how many clicked it". In this scenario, with an adequate sample sizes, insights can be extracted without any issues.
Yes, I agree that in most cases this doesn't significantly distort the data, as most data will be roughly evenly distributed between people who use ad blockers and people who don't. There are, however, some cases where it does significantly distort the data. In the case of T240697 https://phabricator.wikimedia.org/T240697, all of the editors using EasyPrivacy show up as users without JS support, which swamps the legitimate number, making the analysis unusable. Since it sounds like changing the EventLogging URL isn't advisable, I'll look into adding us to EasyPrivacy's whitelist. Thanks for the advice!
On Tue, Sep 22, 2020 at 2:59 PM Dan Andreescu dandreescu@wikimedia.org wrote:
Is it reasonable to say that ad blockers should not be blocking EventLogging (since it's just an internal logging system)? Addblockers prevent requests to beacons, them being used for internal stats or otherwise (ad serving) so yes, it is pretty reasonable. A beacon does not necessarily imply it is used for adds [1]
I was just replying the same thing as Nuria, but I'll make a quick correction here: I think Nuria means it's reasonable for them to block EventLogging, not the opposite (which is what Ryan asked) _______________________________________________ Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics
Event Platform uses a new url: https://intake-analytics.wikimedia.org/v1/events. We're working on migrating all legacy EventLogging over to Event Platform EventGate. When that happens the legacy data will be POSTed to the new URL. You could migrate over early if you want by creating a new schema and instrumentation; and/or I could migrate your legacy schema to Event Platform soonish as one of the earlier schemas we migrate.
Also relevant: https://phabricator.wikimedia.org/T263049 It seems Timo wishes we hadn't changed to a single URL for all events, as it makes clients open up a secondary HTTP connection. TBD what happens with the URL.
On Tue, Sep 22, 2020 at 3:47 PM Ryan Kaldari rkaldari@wikimedia.org wrote:
In most instances what we look when deriving insights are ratios. For
example: "of the people that saw the red link how many clicked it". In this scenario, with an adequate sample sizes, insights can be extracted without any issues.
Yes, I agree that in most cases this doesn't significantly distort the data, as most data will be roughly evenly distributed between people who use ad blockers and people who don't. There are, however, some cases where it does significantly distort the data. In the case of T240697 https://phabricator.wikimedia.org/T240697, all of the editors using EasyPrivacy show up as users without JS support, which swamps the legitimate number, making the analysis unusable. Since it sounds like changing the EventLogging URL isn't advisable, I'll look into adding us to EasyPrivacy's whitelist. Thanks for the advice!
On Tue, Sep 22, 2020 at 2:59 PM Dan Andreescu dandreescu@wikimedia.org wrote:
Is it reasonable to say that ad blockers should not be blocking EventLogging (since it's just an internal logging system)? Addblockers prevent requests to beacons, them being used for internal stats or otherwise (ad serving) so yes, it is pretty reasonable. A beacon does not necessarily imply it is used for adds [1]
I was just replying the same thing as Nuria, but I'll make a quick correction here: I think Nuria means it's reasonable for them to block EventLogging, not the opposite (which is what Ryan asked) _______________________________________________ Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics
Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics