Closed Bug 978994 Opened 7 years ago Closed 7 years ago

Telemetry: Allow "extras" field when starting a session

Categories

(Firefox for Android :: General, defect)

x86
Android
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: oogunsakin, Assigned: oogunsakin)

Details

When starting a session, need a way to add some extra info to give some more context to the session.

Motivation: 
Want to be able to start a Telemetry session when a user enters a home panel. Given a generic session name "homePanel", would be nice to store the panel ID with that session without encoding it into the name of the session. e.g sessionName="homePanel" extras="panelID=0123456789,...other useful info"
I suggest just recording a 'begin' event as the first event in the session. Sessions aren't events, they're scopes.
(In reply to Richard Newman [:rnewman] from comment #1)
> I suggest just recording a 'begin' event as the first event in the session.
> Sessions aren't events, they're scopes.

If we wanted to query for a specific panel's session, we would not be about to filter by examining session entity itself. We'd have to search for an adjacent 'begin' event containing the extras. Doesn't seem too clean. Thoughts?
If you're recording something that's scope-like, use a scope.

If you're recording something that's event-like, use an event.

scope="home,panel.topsites"
event="panel.begin", t=1, from="default", to="panel.topsites"
event="panel.swipe", from="panel.topsites", to="panel.bookmarks", t=2

scope="home,panel.bookmarks"
event="panel.begin", t=3, from="panel.topsites" to="panel.bookmarks"

scope="home,panel.bookmarks"
event="linktap", kind="bookmark", depth=0, t=4
I have a preference for sessions that are independent of events but can be used to give context to events within their the session timestamps, because it seems more flexible in terms of types of data we can collect, and post-collection analyses we can do.

In that case, the extras for a session would be a blob where we can add tags for telemetry probes that are relevant to that session. The sessions themselves also give us larger granularity information (about how long users are spending in each of these sessions).

So sessions and events might be used like:

session="homepanel.topsites", t={15, 30}, extras={loadpage, homebanner}

event="loadpage,contextmenu:newtab", t=30
event="homebanner" t=20

and we can use the timestamps to create a sequence of what's going on, if we care about the context of each event.

However, I don't think we have any telemetry records to play with, so I'm not completely sure that cross-referencing vs sequential records is necessarily better.
Also remember that events save the sessions the are active at the time the event is captured:
http://mxr.mozilla.org/mozilla-central/source/toolkit/components/telemetry/UITelemetry.jsm#110

So we don't really need to use the timestamps in post-analysis:

session="home"
event="showpanel", method="swipe", extra="{bookmarkid}", sessions="home"
session="panel.bookmark"
event="loadurl", method="list", sessions="home,panel.bookmark"
{close session="panel.bookmark"}
{close session="home"}

I added the implicit closing of sessions since that's what should happen since about:home would not be visible after opening the bookmark.

Lastly, for our own sanity, we talking about this stuff, use the terms we define in the code: event, session, method, extras
Things to remember:

* Sessions can overlap and be ended out of order. They're not nesting elements.
* Sessions automatically record an end event when they end.
* Sessions only exist inasmuch as they are a tag associated with a sequence of events. This is why I suggest using the term "scope" when reasoning about this.

So Chenxia: can you rephrase Comment 4 in terms of the concrete format that UITelemetry records, and the change you want to make to it?
I talked with Sola about what he wants to do with sessions, and I don't think we need to add anything to the API.

I'd forgotten about how we associate each event with all the sessions that have been started for that session, whoops. So if we do need to associate extras with a session, we can just add an "extras" Event, of the form:
event="session-extras", method="{session-name}", extra="{extras}"

If we actually need to use this, some method like addExtras(sessionName, [optional] probeName, extras) should be added.

Closing this as a WONTFIX.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.