Page MenuHomePhabricator

Create an application for exploring reader and editor user agents
Closed, ResolvedPublic

Description

Our PdMs and engineers would benefit from having a good idea about what browsers different classes of users use, and what they should be expected to support.

Event Timeline

Ironholds claimed this task.
Ironholds raised the priority of this task from to Needs Triage.
Ironholds updated the task description. (Show Details)
Ironholds subscribed.

I've actually finished the application - I'm just talking through the data release limitations with Legal (my feel is that if we can release the aggregated, high-volume raw agents, we can benefit upstream developers who maintain our agent parser. Everyone wins!)

(to keep the archive happy), after reviewing this with Legal we decided we will not release the raw UA dataset, only the parsed one.

Ironholds closed this task as Resolved.EditedMar 5 2015, 11:51 PM

Also to keep the archive happy: BOOM.

I thought we agreed to include some brief docs on the preparation of the dataset before closing this task?

@Ironholds will this data be collected/updated constantly? or only run as a query when we request it?

http://datavis.wmflabs.org/agents/ is a great start but we'll also want to be able to filter on things like geo, all of a certain bowser (across platforms) all of a certian platform (across browsers) etc. Should we log these as separate tasks to improve later?

This data will not be collected/updated constantly, or run as a query when you request it; it was gathered in response to a specifc, ad-hoc request from Erik. If you want further argumentation or runs people will need to either convince Erik that it's necessary for the Product & Strategy researchers to work on, or push it to R&D/Analytics Engineering (if you're talking about automated reporting that sounds like an Analytics thing).

Note that for per-country browsers we're going to need either a private application store (which we don't have), a flat spreadsheet emailed to you (which isn't great for reuse) or a really heavy legal review probably resulting in very few browsers crossing the anonymisation threshold. This is new territory.

Its also a bit unclear on http://datavis.wmflabs.org/agents/ what the time span is… and currenlty not way to see this change over time. All of which can be progressive improvements, but at least letting viewers easily know what time span is represented in the current tool would be useful.

Thanks @Ironholds I've added this task to the Finch backlog, and I'll keep T58575: Browser and platform stats for logged-in vs. anon users for security and product support decisions open as it is similar but different for the reasons above.

@DarTar it has documentation? Where should it have documentation that it doesn't?

Regardless; I'm going to get to subsequent tasks/suggestions tomorrow, because I'm currently a mass of stress from the massive context switching. Other than cleaning around the edges (docs, etc) requests for progressive enhancements should come through/from Eloquence.

@Ironholds, it has documentation now, thanks. Per @Jaredzimmerman-WMF, it would be good to also specify the period during which the data was collected. I'm happy to help with the datahub release, if you want to do it.

I suggest we prioritize the following for now:

  • HIGH: Show % of total traffic (for the view I'm in) as a separate column
  • MEDIUM: Switches to group platform, browser version (if I group "platform" I still get all Chrome versions, if I group "browser version" I still get the OS breakdown, if I group both I just get "Chrome", "Firefox" etc.)

This is a prototype but also intended to give us some initial insights. We'll iterate in prototype mode before implementing updates. Oliver -- not urgent, the priorities are internal to this task and not relative to other work you're doing.

Sure. The "not agent" is appreciated; tasks ballooning is a consistent
risk ;p. One thing we might want to do with future tasks is say when
describing it ("this will probably result in future
refinements/requests", "this will probably not" just so we can
mentally apportion out more time than we think it'll take (or not, as
the case may be)

...not urgent. And on that particular freudian slip I'm going to sign
off for the evening.