Thanks, Gergo!
This is really helpful data, which will inform our development plans for Upload Wizard.
Identifying the file upload step as the main pain point is invaluable. It would be great
if we could track the upload error messages as you suggest, so we can better understand
what’s holding users back on this step. Also, do we have a way of finding out how often an
upload hangs because of a server-side issue, rather than a user issue? Should we create
tickets for these new tasks?
It would also be great if we could review this funnel data again in a few days, so we can
see if this pattern is steady or if it varies over time. Can we track whether the drop-off
is caused by people uploading multiple files? or large files? We might also want to look
at whether certain browsers or platforms are experiencing more issues than others — or
whether or not casual users are dropping off more than experienced users.
In any case, this is absolutely wonderful. Thank you so much for shedding more light on
this important process, in the middle of all your other responsibilities :)
To be continued,
Fabrice
On Jun 4, 2014, at 12:55 PM, Gergo Tisza <gtisza(a)wikimedia.org> wrote:
Hi all,
we have recently added some funnel [1] logging to UploadWizard. A nice dashboard is in
the works, but here are some preliminary results, showing the number of virtual pageviews
for each step of UploadWizard.
mysql:research@s1-analytics-slave.eqiad.wmnet [log]> select event_step, count(*),
count(*)/3623 as survival_rate from UploadWizardStep_8612364 group by event_step order by
survival_rate desc;
+------------+----------+---------------+
| event_step | count(*) | survival_rate |
+------------+----------+---------------+
| tutorial | 3623 | 1.0000 |
| file | 3496 | 0.9649 |
| deeds | 2433 | 0.6715 |
| details | 2373 | 0.6550 |
| thanks | 2109 | 0.5821 |
+------------+----------+---------------+
This is based on about a day's worth of logs (25.5 hours) - the logging code was
deployed to Commons yesterday.
The big drop is apparently in the file upload step (almost 30% - well over 1000 uploads a
day). Some of that might be intentional (upload caught by badtitle filter etc), but even
so the drop is huge. Given that that step is rather simple from a UX point of view, it
seems that upload bugs are a bigger problem right now than design issues.
(The license selection - deeds -> details - on the other hand is unexpectedly
unproblematic; I would have expected it to be the main source of confusion, but actually
adding description etc. seems worse.)
The next step would be to log JS/upload errors, I suppose.
Also, it would be nice to know which dropoffs are final and which are reloads/restarts.
The Navigation Timing API can tell apart reloads and normal navigation, alternatively we
could maybe group by IP + useragent + time bucket to find retries.
_______________________________________________
Multimedia mailing list
Multimedia(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/multimedia
_______________________________
Fabrice Florin
Product Manager
Wikimedia Foundation
http://en.wikipedia.org/wiki/User:Fabrice_Florin_(WMF)