Create a specification for Telemetry "session stitching" and "client stitching"

RESOLVED INCOMPLETE

Status

Cloud Services
Metrics: Pipeline
RESOLVED INCOMPLETE
3 years ago
3 years ago

People

(Reporter: mreid, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
In order to provide output that is more amenable to analysis, we need a specification for how to combine session fragments into full sessions, and how to combine a set of client submissions into a single document per client.

Session stitching may be a subset of client stitching, or they may be different ways of combining the data.  If they are to be different, we should create a separate bug for each one.
(Reporter)

Updated

3 years ago
See Also: → bug 1140094
I would like to mention that we have two types of session-fragment-for-a-stable-id aggregation

1. A single record that is the collection(be it set/vector/array/list/ whatever) of all session fragments for that stable-id. There is no concept of order  - it is a set of session fragments.

2. A way of combining the fragments in some other order e.g. by time or by day etc. 

Number (1) is straightforward(at least it appears to be). (2) needs discussion as to how to combine.

Regards
Saptarshi
(Reporter)

Comment 2

3 years ago
(In reply to "Saptarshi Guha[:joy]" from comment #1)
> I would like to mention that we have two types of
> session-fragment-for-a-stable-id aggregation
> 
> 1. A single record that is the collection(be it set/vector/array/list/
> whatever) of all session fragments for that stable-id. There is no concept
> of order  - it is a set of session fragments.
Concatenating several submissions into a single set is a form of stitching, but I agree that this task is clear and doesn't require discussion.

> 2. A way of combining the fragments in some other order e.g. by time or by
> day etc. 
This part is what this bug is intended to determine. We need requirements from people who would like the data stitched together into various larger views.

Comment 3

3 years ago
Discussed this today: the by-profileID API will for the moment be returning a sequence of raw payloads, which is also what will be available on the client. We'll experiment with different ways to stitch that together using postprocessing scripts, but we don't need to come to a single solution for that problem yet.

Thus I'm going to mark this INCOMPLETE as it's not something we need to directly track.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.