Page MenuHomePhabricator

actor_signature_per_project_family does not work for apps
Open, HighPublic

Description

I'm excited about the pageview_actor table but I wanted to point out a minor bug with how actor_signature_per_project_family is computed. For the mobile apps, the accept_language parameter is not actually stable and changes based on the language being viewed in the app (i.e. en if you look at English Wikipedia but fr if you switch to French, etc.). Because accept_language is used in the computation of the actor signature across projects, app users will actually end up with different actor_signature_per_project_family values when they switch languages. In my brief browsing, I haven't seen any indication that this would happen in mobile web or desktop.

This is the query you can use to verify this behavior (if you scroll, you generally find an example pretty quickly of someone who visited multiple languages):

SELECT x_analytics_map['wmfuuid'] AS wmfuuid, uri_host, actor_signature, actor_signature_per_project_family, accept_language FROM pageview_actor WHERE year = 2020 AND month = 7 AND day = 10 AND hour = 18 AND access_method = 'mobile app' AND x_analytics_map['wmfuuid'] IS NOT null ORDER BY wmfuuid LIMIT 1000;

Event Timeline

Great finding @Isaac ! Thanks for documenting :)

Happily! I had done some analysis of these sorts of actor signatures a while back with app users to see how stable the signatures are (meta) and so had thought (erroneously) that accept_language wasn't stable on any device so was glad to find out that it's just the app where it switches.

Milimetric triaged this task as High priority.
Milimetric moved this task from Incoming to Data Quality on the Analytics board.
Milimetric subscribed.

Nuria is taking a look at this and will explain why the repercussions are not too bad.

This is a good catch, let me explain why effect on data is not that significant (so you understand why we might not rush to fix it right away). The signatures are used to 1) identify bot requests and 2) mainly and as a computational aid to compute uniques. For bots the use cases on apps when we have a lot of "spammy" traffic have to do with the (mal)functioning of the app when "rogue" requests get sent. For example, an app with a bug in which every request is repeated. This has little to do with user behaviour of changing languages and produces many spammy requests for 1 device.

In the case of unique devices computations the app data does not at all play a part, our apps do not manage cookies the way a browser does so uniques for apps cannot be computed with a cookie based strategy. In fact, that mobile app data should explicitly be excluded from that computation. See: T258288: explicitily exclude mobile-app traffic from unique devices per domain computation

Thanks @Nuria! Yeah, no hurry on our end to fix either, but I know we're excited about this table in Research for its potential for speeding up a lot of the querying / session-building work we do and so I want to make sure it's eventually fixed or at least clearly documented somewhere so we don't unknowingly reach wrong conclusions when we work on multilingual reading behavior that includes the apps.

Hi @Isaac, I was hoping to do this task last year, but I was still getting up to speed and now I can see this isn't really in the purview of SRE (my role), and unfortunately prioritized against our goals it is not going to happen anytime soon