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.