1339308 - Please consider adding partner.distribution_id to client_count

Status: VERIFIED FIXED

(Cloud Services Graveyard :: Metrics: Pipeline, defect, P1)

Description

[Hector Zhao [:hectorz]]

I just found out there's a `distributionid` field in the `mobile_clients_v1` dataset[1] through the "Android: Distributions" dashboard[2].

If you agree this addition, I'm guessing some kind of whitelist needs to be set up to limit the fragmentation. For me, I'm mostly interested in the "MozillaOnline" repacks distributed by Beijing office in China.

Thanks.

[1]: https://wiki.mozilla.org/Mobile/Metrics/Redash
[2]: https://sql.telemetry.mozilla.org/dashboard/mobile-distributions

Comment 1

[Frank Bertsch [:frank]]

Unfortunately this isn't possible. Client Count is Desktop Firefox only. I've talked with Barbara about generating a similar dataset for mobile, but if that happens it won't be for awhile.

Any reason you can't do this analysis on STMO?

Comment 2

[Hector Zhao [:hectorz]]

(In reply to Frank Bertsch [:frank] from comment #1)
> Unfortunately this isn't possible. Client Count is Desktop Firefox only.

Yes, I'm requesting the inclusion of desktop `partner.distribution_id` into `client_count`, which I can query in the `longitudinal` dataset.

I mentioned the mobile dataset only because it kinda enlightened me to request such a change, sorry for any confusion.

Comment 3

[Frank Bertsch [:frank]]

Roberto, you're the owner of Client Count - can you decide if this is appropriate?

Comment 4

[Roberto Agostino Vitillo (:rvitillo)]

(In reply to Hector Zhao [:hectorz] from comment #2)
> (In reply to Frank Bertsch [:frank] from comment #1)
> > Unfortunately this isn't possible. Client Count is Desktop Firefox only.
> 
> Yes, I'm requesting the inclusion of desktop `partner.distribution_id` into
> `client_count`, which I can query in the `longitudinal` dataset.

I am not sure I understand what you are asking. The longitudinal dataset isn't related to the client_count dataset. Are you asking to add that field to the longitudinal dataset, to the client_count dataset or to both? 

Afaik distribution_id is already part of the longitudinal dataset; is the available data insufficient for your purposes? What kind of question are you trying to answer with this data?

What's the cardinality of distribution_id and what sort of whitelist would be appropriate? Who is going to maintain the whitelist?

For prioritization purposes, it would also be helpful to know where I can find the OKR that this request supports.

Comment 5

[Hector Zhao [:hectorz]]

(In reply to Roberto Agostino Vitillo (:rvitillo) from comment #4)
> (In reply to Hector Zhao [:hectorz] from comment #2)
> > (In reply to Frank Bertsch [:frank] from comment #1)
> > > Unfortunately this isn't possible. Client Count is Desktop Firefox only.
> > 
> > Yes, I'm requesting the inclusion of desktop `partner.distribution_id` into
> > `client_count`, which I can query in the `longitudinal` dataset.
> 
> I am not sure I understand what you are asking. The longitudinal dataset
> isn't related to the client_count dataset. Are you asking to add that field
> to the longitudinal dataset, to the client_count dataset or to both? 
> 

I want it added to the `client_count` dataset.

I mentioned `longitudinal` in an attempt to make it clear that `partner.distribution_id` is a desktop field.

> 
> Afaik distribution_id is already part of the longitudinal dataset; is the
> available data insufficient for your purposes? What kind of question are you
> trying to answer with this data?
> 

Yes, it is already part of `longitudinal`.

Since the early days of Telemetry, we at Beijing office are often asked why we're writing codes in our own extensions to track things like DAU, instead of relying on the built-in mechanism. I don't have a complete answer for that, but there's one particular aspect that I can think of: we don't have good access to globally gathered data. I think we always have access to DAU in China, but since some users in China prefer vanilla Firefox, it's not the same as users of China repack (which bundles a few extensions and has a patched installer).

I've been interested in the possible differences between global users, users in China and those using China repack for some time. I talked to :vladan about it in Portland, but bug 1107713 was shelved maybe as a side effect of the work to unify FHR and Telemetry.

I didn't quite figure out how to use Map/Reduce or Spark for self-service analysis, but re:dash seems to be easier. Something I've confirmed/learned with `longitudinal` so far:

1. Chinese users have a slower uptake of new Flash Player[1] and Windows[2] versions
2. Top NPAPI plugins that's still being used within China repack[3]
3. Fx China repack has fewer users on Linux[4]
4. As a result of our slow progress of e10s-compat fixes, we were only able to unblock ~20% of sessions since Fx 51[5]

I have to admit there's not much difference between users in China and those using China repack here. I assumed there would be more once I learn how to work with more non-environmental probes, especially those opt-in ones not available in `longitudinal` dataset.

Now with the transition to the more restrictive WebExtension API, I think it's necessary for us to understand the correlation between our own tracked numbers and the ones as calculated from UT[6]. But since `longitudinal` is a 1% sample and only updated weekly, I think it might be better if `distributionid` is also available in `client_count`.

I'm also interested in a "MozillaOnline" specific retention rates, but I think that's another dataset, "churn"? My own calculations using `longitudinal`[7] doesn't look quite right.

> 
> What's the cardinality of distribution_id and what sort of whitelist would
> be appropriate? Who is going to maintain the whitelist?
> 

If the partner engineering team is interested in using `client_count`, they would have better judgements of which distribution_ids to track. My sole concern is the "MozillaOnline" repacks.

> 
> For prioritization purposes, it would also be helpful to know where I can
> find the OKR that this request supports.

There's not such an OKR, it's another one of those things we don't really have in Beijing office.

[1]: https://sql.telemetry.mozilla.org/queries/1450
[2]: https://sql.telemetry.mozilla.org/queries/1423
[3]: https://sql.telemetry.mozilla.org/queries/1430
[4]: https://sql.telemetry.mozilla.org/queries/2042
[5]: https://sql.telemetry.mozilla.org/queries/2056
[6]: https://sql.telemetry.mozilla.org/queries/2912
[7]: https://sql.telemetry.mozilla.org/queries/2918

Comment 6

[Roberto Agostino Vitillo (:rvitillo)]

Attachment: PR

Comment 7

[Hector Zhao [:hectorz]]

Thanks!