1572530 - new ping for google ad id - Fennec- not showing any client id

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: Metrics, defect, P1)

Description

[arana]

We recently started sending a new ping for reporting google ad id for Fennec. The results are reported in the re:dash table below

moz-fx-data-shar-nonprod-efed.mobile_live.activation_v1

The table is not showing any values in the client_id column. It was decided that client_id will not be sent if the user is reporting google ad_id. However, the client_id field is completely empty. Can we please verify here that the client_id column is recording data properly.

implementation details can be found in the bug below

https://bugzilla.mozilla.org/show_bug.cgi?id=1534451

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:st3fan, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 2

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

[Tracking Requested - why for this release]:

Comment 3

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

I am moving this to a P1 because we are eager for getting this data. Unclear what the root cause is but I think it is good if engineering reviews the Fennec client code again. Is that a good start?

Comment 4

[Frank Bertsch [:frank]]

I have just discovered that this data is being sent, but it is invalid. Per the spec we are calling it client_id, but it is being sent as clientId. This should be an easy fix on the client end.

Comment 5

[Vlad Baicu]

Indeed.

Client:
https://dxr.mozilla.org/mozilla-central/source/mobile/android/base/java/org/mozilla/gecko/telemetry/pingbuilders/TelemetryActivationPingBuilder.java#42

Server:
https://github.com/mozilla-services/mozilla-pipeline-schemas/blob/334f59eafa324a31364952e46cb498b8ecd6a9f4/schemas/mobile/activation/activation.1.schema.json

This probably happened due to a communication/attention deficit. The activation ping's implementation is also heavily based on the core ping's in order minimise the risk of introducing any regressions which contributed to this incident.

Comment 6

[Vlad Baicu]

Attachment: Bug 1572530 - Fix client id field to match backend validation schema.r=petru

Comment 7

[Vlad Baicu]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=ec85f29a44494fa61ea39f4018c80fa5cfe76cce

Comment 8

[Vlad Baicu]

Comment on attachment 9098564 [details]
Bug 1572530 - Fix client id field to match backend validation schema.r=petru

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: We're not reporting the client id properly to the telemetry backend
• User impact if declined: The client id will not be processed
• Fix Landed on Version:
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Trivial change on the validation schema
• String or UUID changes made by this patch:

Comment 9

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9098564 [details]
Bug 1572530 - Fix client id field to match backend validation schema.r=petru

Fennec Telemetry fix, approved for 68.2b7.

Comment 10

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr68/rev/44b626af5250

Comment 11

[Sorina Florean [:sflorean]]

Tested the following builds: 68.2b7 and 68.2 RC 1 and 2 on different devices and here are my findings regarding this bug: https://sql.telemetry.mozilla.org/queries/65408/source.
Note: client_id is not null but our devices are not listed.
Do we need to wait a couple of days before they show up? Or we need to search by another query?

We tried also: https://sql.telemetry.mozilla.org/queries/65410/source.

Comment 12

[Sorina Florean [:sflorean]]

Removing the qe-verify flag due to the fact that entries for 68.2.0 and beta started to be displayed.