Opened 4 weeks ago

Last modified 18 hours ago

#7302 new change

Pass Acceptable Ads user status to uninstall page

Reported by: erezson Assignee:
Priority: P3 Milestone:
Module: Platform Keywords:
Cc: greiner, sebastian, sporz, wspee, erezson Blocked By:
Blocking: Platform: Unknown / Cross platform
Ready: yes Confidential: no
Tester: Unknown Verified working: no
Review URL(s):

Description (last modified by sebastian)

Background

As ABP team we would like to know if uninstalled users are AA opt-in/out so we can have better decisions based on data

What to change

Add s (for subscriptions) query string parameter to uninstall URL that represents the following information:

  • Is Acceptable Ads filter list inactive and are all ad blocking filter lists inactive?
  • Is Acceptable Ads filter list active and are all ad blocking filter lists inactive?
  • Is Acceptable Ads filter list active and are some ad blocking filter lists active?
  • Is Acceptable Ads filter list inactive and are some ad blocking filter lists active?

Active means filter list is installed and enabled.
Inactive means filter list is either not installed or disabled.

e.g.

  • 0: AA inactive; ad blocking inactive
  • 1: AA inactive; ad blocking active
  • 2: AA active; ad blocking inactive
  • 3: AA active: ad blocking active

Change History (16)

comment:1 Changed 4 weeks ago by greiner

  • Cc greiner added
  • Component changed from Unknown to Platform

comment:2 Changed 3 weeks ago by sebastian

  • Cc sebastian sporz added

@sporz: Any chance we can already extrapolate these data?

comment:3 Changed 3 weeks ago by sporz

TL;DR: No.

Explanation
We could match IP/UA combinations of users uninstalling with recently (same day) downloaded notification.json and exceptionrules.txt files. However, there would be a large number of users we'd be misinterpreting because they downloaded the day before (possibly on a different IP), but are still within the 24h interval.

Another way is assuming the same opt-out rate in uninstallations as in our active users.

Both ways are unfortunately unsuited to answer questions like "Do users with AA enabled uninstall more frequently than those with AA disabled?". @erezson is this about what you're aiming for?

comment:4 follow-up: Changed 3 weeks ago by sebastian

Alright, if we cannot extrapolate those data, fine with me adding a query string parameter like aa=0|1 (indicating whether Acceptable Ads was enabled) to the uninstall URL.

But keep in mind that the uninstall URL is limited to 255 characters, currently we have ~168 characters here, which leaves still enough space to add an aa parameter, but more complex data like a complete list of filter list subscriptions wouldn't be possible.

comment:5 in reply to: ↑ 4 Changed 9 days ago by erezson

Replying to sebastian:

Alright, if we cannot extrapolate those data, fine with me adding a query string parameter like aa=0|1 (indicating whether Acceptable Ads was enabled) to the uninstall URL.

But keep in mind that the uninstall URL is limited to 255 characters, currently we have ~168 characters here, which leaves still enough space to add an aa parameter, but more complex data like a complete list of filter list subscriptions wouldn't be possible.

That's fine, for your example about list of filters we're going to do it via the telemetry. But anyway, if we will get to the maximum amount of characters, I would suggest to revise the data we really need. Thanks for letting me know about it.

Sebastian, Do you have any idea when we can have this feature implemented?

comment:6 Changed 6 days ago by greiner

  • Description modified (diff)

I updated the ticket description to reflect what has been agreed on so far but also added a third state to reflect whether the filter list is disabled to detect whether the filter list is in an invalid state.

Along those lines, we could also add further states, if there's any piece of information related to this filter list we're interested in, without increasing the size of the uninstall URL.

Examples:

  • List is installed and enabled but it has always failed to download so far
  • Acceptable Ads without third-party tracking list is installed, enabled, etc.

Presumably, however, the three states should be sufficient for now.

@erezson Do you agree with this assessment? If so, can you confirm that the Acceptable Ads without third-party tracking list should not be considered when determining whether a user has opted-in/out of Acceptable Ads? Otherwise we'll need to agree on how to represent that information without making it too hard to understand (i.e. intransparent) for users.

e.g. Representing AA being installed and enabled and AA3p being installed but disabled:

  • In binary: aa=e (i.e. 1110 in hexadecimal)
  • In decimal: aa=12

comment:7 Changed 6 days ago by erezson

Agree. I don't think it's that important to know about 3rd party.

comment:8 follow-up: Changed 6 days ago by sebastian

  • Cc wspee added

Wasn't the Acceptable Ads list meant to never be disabled but can only be removed?

Also according to Winsley it would be good to know if any ad blocking list (i.e. EasyList or any EasyList bundle) is active, e.g. in order to identify the scenario when users might uninstall because effectively nothing is blocked. We could encode these information like following:

0 no known ad blocking list enabled
1 known ad blocking list enabled
2 known ad blocking list and Accapeble Ads enabled

comment:9 Changed 5 days ago by wspee

  • Cc erezson added

comment:10 in reply to: ↑ 8 Changed 5 days ago by greiner

Replying to sebastian:

Wasn't the Acceptable Ads list meant to never be disabled but can only be removed?

Yes, there are various invalid states the user could theoretically be in.

Some examples:

  • AA installed but disabled, AA3p not installed
  • AA not installed, AA3p installed but disabled
  • AA installed and enabled, AA3p installed and enabled
  • AA not installed, AA3p not installed

For that the aforementioned notations could help us identify the exact state the extension is in to make sure there are no users that are in such an invalid state (see also #5933).

Also according to Winsley it would be good to know if any ad blocking list (i.e. EasyList or any EasyList bundle) is active, e.g. in order to identify the scenario when users might uninstall because effectively nothing is blocked. We could encode these information like following:

0 no known ad blocking list enabled
1 known ad blocking list enabled
2 known ad blocking list and Accapeble Ads enabled

I'd argue 2 is redundant if we also have the aa parameter but yes, good point, such information could also end up being quite helpful in identifying problems with the extension state.

Referring back to the binary format I mentioned, we could encode all of that information in a single character (or a series of characters), if we want to keep the query string size at a minimum by instead representing the extension's state rather than only the Acceptable Ads state.

comment:11 follow-up: Changed 5 days ago by sebastian

Of course, I'm not suggesting to add yet another parameter, but instead of the aa parameter we could add an s (for subscriptions) parameter with the states suggested above. Yes, I don't distinguish between disabled and missing subscriptions, as I fail to see how that difference is relevant, as the effect is the same (and as mentioned before Acceptable Ads cannot be disabled anyway). Also I don't distinguish between no filter list and only Acceptable Ads, since the effect is the same there as well.

comment:12 in reply to: ↑ 11 Changed 2 days ago by greiner

Replying to sebastian:

Of course, I'm not suggesting to add yet another parameter, but instead of the aa parameter we could add an s (for subscriptions) parameter with the states suggested above.

Ok, thanks for clarifying.

Yes, I don't distinguish between disabled and missing subscriptions, as I fail to see how that difference is relevant, as the effect is the same (and as mentioned before Acceptable Ads cannot be disabled anyway).

I was seeing it more from an analytical perspective since disabled filter lists would still lead to update requests to our servers. However, you're right that from a user experience perspective there's no difference between those.

Also I don't distinguish between no filter list and only Acceptable Ads, since the effect is the same there as well.

That's not accurate. The Acceptable Ads filter list also contains blocking and hiding rules which, at least in theory, could lead to some websites behaving differently.

Apart from that, the request states that we want to know whether the user "is AA opt-in/out" and for that it shouldn't make a difference whether a blacklist is en-/disabled. Although it would be good to have this kind of information in addition to it.

With that we'd at least have the following states:

  • AA filter list inactive and all ad blocking filter lists inactive
  • AA filter list active and all ad blocking filter lists inactive
  • AA filter list active and some ad blocking filter lists active
  • AA filter list inactive and some ad blocking filter lists active

We still wouldn't know any of the following information:

  • Is AA filter list installed but disabled?
  • Is AA3p filter list installed and/or enabled?
  • Does the user have all the appropriate ad blocking lists? (e.g. user may only have plain EasyList enabled)

@erezson @sebastian Would that satisfy your requirements?

comment:13 Changed 2 days ago by sebastian

Sounds good to me.

comment:14 Changed 32 hours ago by greiner

  • Description modified (diff)
  • Summary changed from AA user status when uninstalling to Pass Acceptable Ads user status to uninstall page

Updated ticket description accordingly.

comment:15 Changed 20 hours ago by sebastian

  • Priority changed from Unknown to P3
  • Ready set

comment:16 Changed 18 hours ago by sebastian

  • Description modified (diff)
Note: See TracTickets for help on using tickets.