Thanks Aaron, I will try something along these lines. This avoids the latency concerns mentioned by Nuria, and it is very flexible - we'll see how painful it is to aggregate the data on the backend.
So we agree you do not need to use cookies right? Being a single page app you should not need them. As you said you actually do not even need local storage.
I don't see how UserTiming is related. That API is about obtaining sub-millisecond precision - that is useful when you >are building a 3D rendering engine or similar extremely time-sensitive feature, but generally using regular millisecond >numbers is OK.
While the API is part of the performance spec it can be used for anything that needs to track 'workflow' and time across those steps. It's usefulness comes not only from precision when it comes to time but also from being able to track steps with a clear api.
what if the user comes back after a month?
If you use session storage the events disappear when the user closes the browser. That means we are biasing the stats towards successful users, as they are guaranteed to make another page load in >the same session, while unsuccessful ones might just leave for a while. Trying to compensate for that by making guesstimates, as you suggest, is a path I would rather not take.
Being a single page app you do not need session storage, of course. Also you should be able to report every step w/o issues.
On Fri, May 16, 2014 at 1:51 AM, Gergo Tisza gtisza@wikimedia.org wrote:
On Wed, May 14, 2014 at 5:58 AM, Aaron Halfaker ahalfaker@wikimedia.org wrote:
Hey guys,
Here's how I'd do it.
Assumption: Only logged-in users can start the UW funnel
Schemas:
UploadWizardStep
Stored when the user loads a new step of the Upload Wizard
user_id : int -- The user's identifier flow_initialized : str -- The timestamp at which the current flow through the funnel began (will need to be stored in a cookie and reset at loads of step 1) step : int -- 1 - 4 of the UW process
UploadWizardRightsSelection
Stored when the user selects a "rights" option.
user_id : int -- The user's identifier flow_initialized : str -- The timestamp at which the current flow through the funnel began (will need to be stored in a cookie and reset at loads of step 1) rights_selected : enum("own", "other) -- The rights that a user selected (note that multiple selections actions can take place for a single flow)
I'd make a pass over the DB, to identify the last RightsSelection for each flow_initialization (if any) to figure out what an uploading user settled on during a particular flow. I'd also look at how many selections a user makes per flow to see evidence of confusion & indecisiveness or maybe just exploration of the UI.
Thanks Aaron, I will try something along these lines. This avoids the latency concerns mentioned by Nuria, and it is very flexible - we'll see how painful it is to aggregate the data on the backend.
(will need to be stored in a cookie and reset at loads of step 1)
We don't even need this part since UploadWizard is a single-page application with no page load between the steps, so we can just store the token in memory. I don't want to log userids unless we really need them, so I'll just go with initial timestamp + random number. I don't think connecting separate upload attempts by the same user is particularly useful at this point.
Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics