[meta] Add support for Unified Telemetry to Firefox for iOS

NEW
Unassigned

Status

()

Firefox for iOS
General
2 years ago
2 years ago

People

(Reporter: mfinkle, Unassigned)

Tracking

unspecified
All
iOS

Firefox Tracking Flags

(fxios+)

Details

We need to start some basic Telemetry in Firefox for iOS. This is just a meta bug that needs a breakdown.

How can we do this incrementally, to get some support working ASAP?
(Reporter)

Updated

2 years ago
tracking-fxios: --- → ?
I think the first question is what the scope here is:
(1) submit data compatible with the full main ping format documented in [0] or
(2) submit data compatible with the top-level ping format [1] and iOS specific payloads

(2) seems much more reasonable. If we want some/all measurements to easily show up in telemetry.mozilla.org then maybe generating data compatible with the histogram / keyedHistogram format there and feeding t.m.o from it would be feasible.

0: https://gecko.readthedocs.org/en/latest/toolkit/components/telemetry/telemetry/main-ping.html
1: https://gecko.readthedocs.org/en/latest/toolkit/components/telemetry/telemetry/common-ping.html

Comment 2

2 years ago
I'm not convinced we need full compatibility with the desktop ping format. I bet a lot of the data won't make sense.

Please start with the kinds of questions we need to answer and figure out the data to collect from there. That was we can solve incrementally by building the data for the most important question first and working down the list.

Mark, you've got client engineers to work on this?
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #2)
> I'm not convinced we need full compatibility with the desktop ping format. I
> bet a lot of the data won't make sense.

Happy to remove some optional parts and start with a smaller set of data, but I want it to be compatible with Mozilla's core formats.

> 
> Please start with the kinds of questions we need to answer and figure out
> the data to collect from there. That was we can solve incrementally by
> building the data for the most important question first and working down the
> list.

Keep in mind: I don't want to grow separate server-side analysis systems. I want to use the same ones we already have in place. The less we need to re-invent, the better chance we have of actually getting metrics.

> 
> Mark, you've got client engineers to work on this?

I have client engineers ready to help the Telemetry client engineers. Telemetry has to be involved. This is your domain. You can't ignore Mobile. Sorry if that that was not your the purpose of your question, but I have seen that question before.
As we'll be writing two new network clients, I'd like one of the outputs from this effort to be an API spec for the ping service; I can't find one. Am I looking in the wrong place?

Comment 5

2 years ago
Just as with android, there's still a pretty fundamental question to answer about what a "session" is on a mobile device.

Sure, we should use common systems as much as possible. The question of whether that's possible really depends on what questions you're trying to answer on iOS. So we really can't say whether the existing data formats or reporting system(s) are going to be useful until know what kinds of questions the data is intended to answer.

Is this data going to feed executives? PMs? marketers? engineers? What are their actual requirements?
(In reply to Richard Newman [:rnewman] from comment #4)
> As we'll be writing two new network clients, I'd like one of the outputs
> from this effort to be an API spec for the ping service; I can't find one.
> Am I looking in the wrong place?

Do you mean a server or client side API?
Server-side we have the expected common format specd:
https://gecko.readthedocs.org/en/latest/toolkit/components/telemetry/telemetry/common-ping.html

mreid, can you expand on the end-point? I would love to see that documented either in e.g. the in-tree docs or on the wiki.
Flags: needinfo?(mreid)
(In reply to Georg Fritzsche [:gfritzsche] from comment #6)

> Do you mean a server or client side API?

Server-side. I don't expect much or any client submission code to be reused, but I found the reference to TelemetryController which'll suffice as inspiration.


> Server-side we have the expected common format specd:
> https://gecko.readthedocs.org/en/latest/toolkit/components/telemetry/
> telemetry/common-ping.html
> 
> mreid, can you expand on the end-point? I would love to see that documented
> either in e.g. the in-tree docs or on the wiki.

Yeah, that's what I'm after -- data format is one thing (and I'm glad that's documented!), but I'd like to know the endpoint and protocol details: what headers are sent with 503s to indicate backoffs? how does the server indicate a malformed payload, and what should the client do about it? how do we tell a client that this service has been permanently EOLed? do we support 301s? etc.

I'd like to see enough of that written down that it's possible to write a client and have it work without too much trial and error.
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #5)
> Just as with android, there's still a pretty fundamental question to answer
> about what a "session" is on a mobile device.

For FHR we defined a session as the period between onResume and onPause -- i.e., the total time that the browser activity is in the foreground (and the screen is awake, IIRC).

That's further divided into cold and warm starts: cold is when Gecko needs to be started in order to render pages.

This approach is just about the only thing that makes sense on a platform where the OS is in charge of when your application is started and stopped.

(Disregarding bugs, that means our "eyeball time" -- sum of all sessions -- for Android is both accurate and precise, which is nice.)

https://hg.mozilla.org/mozilla-central/file/default/services/healthreport/docs/dataformat.rst#l259
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #5)
> Just as with android, there's still a pretty fundamental question to answer
> about what a "session" is on a mobile device.
> 
> Sure, we should use common systems as much as possible. The question of
> whether that's possible really depends on what questions you're trying to
> answer on iOS. So we really can't say whether the existing data formats or
> reporting system(s) are going to be useful until know what kinds of
> questions the data is intended to answer.
> 
> Is this data going to feed executives? PMs? marketers? engineers? What are
> their actual requirements?

Firefox for iOS won't be so very different from our Android and Desktop browsers. The same general questions will be of interest. The dashboard for Firefox for Android [1] is the same type of executive level data we'd like to see for iOS. Telemetry histograms and UI Telemetry serve developers well on Firefox for Android. I'd expect the same to be true for iOS.

Comment 10

2 years ago
(In reply to Richard Newman [:rnewman] from comment #7)
> (In reply to Georg Fritzsche [:gfritzsche] from comment #6)
> > mreid, can you expand on the end-point? I would love to see that documented
> > either in e.g. the in-tree docs or on the wiki.
> 
> Yeah, that's what I'm after -- data format is one thing (and I'm glad that's
> documented!), but I'd like to know the endpoint and protocol details: what
> headers are sent with 503s to indicate backoffs? how does the server
> indicate a malformed payload, and what should the client do about it? how do
> we tell a client that this service has been permanently EOLed? do we support
> 301s? etc.
> 
> I'd like to see enough of that written down that it's possible to write a
> client and have it work without too much trial and error.

The server's behaviour is documented here:
https://wiki.mozilla.org/CloudServices/DataPipeline/HTTPEdgeServerSpecification

The server does not care if a payload is malformed - it is accepted and stored regardless. If it is malformed (ie. does not pass validation), it is sent to a separate backend storage location for further analysis.

Note in Bug 1129222 that the full spec is not yet implemented in the heka-based pipeline, but if you code against that, you will be futureproof (at least as far as Bug 1137424).
Flags: needinfo?(mreid)
tracking-fxios: ? → 2.0+
Hardware: Other → All
tracking-fxios: 2.0+ → 3.0+
Rank: 2
tracking-fxios: 3.0+ → +
You need to log in before you can comment on or make changes to this bug.