-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create an interface for viewing deployment analytics #288
Comments
@Manaswis, can't you just calculate touchscreen users from Google Analytics? Would be good to know this stuff ASAP. |
I see you in a meeting yet you are commenting :) |
Haha, I assure you I do this far less than the average prof! |
Thanks for pointing this out @Manaswis
Of course this is now either the "start mapping" or "login". How important is this metric to us right now?
This is included in the current admin interface.
I'm not sure we need a number that says what percentage of people finish one mission... I think this is mostly captured by histograms showing distance covered per user (split by registered and anon), as mentioned in #351 and #342
We can get this from Google Analytics I'm assuming?
We got an answer to this from Google Analytics. |
It is? Where. I use the admin interface all the time and I've never seen this (or understood the current analytics for this if it exists)
Why can't we have a histogram of number of missions completed complemented by descriptive stats like avg, median, mode, and SD of missions completed per person. Also, I do think it would be useful to know:
I would expect a dropoff at each step and tracking this seems important to informing future updates of our tools to better engage and sustain participation. |
What's the x-axis on this graph? To me, this thing is not super legible. Also, does this show how long it takes people to complete onboarding? If so, then it's not showing us information about people who drop out... I now see the bounce rate stat--I seemed to have overlooked this before (poor UI :)). Is the bounce rate defined as the number of people who do not finish (so 26.6% who start the tutorial do not finish) or is it the number of people who do finish (so, 26.6% who start the tutorial do finish)? |
That would be a time interval in seconds (you can kind of see it in the bottom right corner, but above the x-axis).
Much needs to be changed on this page :)
That would be 26% do not finish, the relevant line of code is here |
I think that there are a lot of cases where we would want to keep track of the session. How hard would it be to start recording this? |
I don't think homepage refreshes are very common, so not sure this should be a key concern. Though I understand (and appreciate) your point. And agree with it. Re: the visualization itself. You need to print raw % above each bar. In addition, perhaps we need not show Visit Index since that is always 100%, right? This would help with the flattening that has occurred, obscuring our ability to understand the underlying data. Re: @misaugstad's question about sessions. @Manaswis: aren't we currently doing session tracking? |
What are some other reasons for the huge bounce rate then? According to Google Analytics, shown in this comment, the bounce rate is ~50%, and @Adash12 seems to be getting a bounce rate of ~99%. Something is up here! |
Since we switched from "participate" to "start mapping", are those considered different activities? |
Not sure. We will have to investigate further but I'm fairly confident that, in general, homepage refreshes are uncommon. My suggestion to take out Visit Index stands (as do my other suggestions).
I doubt it. I think this is only a frontend change rather than a logging change. |
We don't for anonymous users across different pages. |
Shouldn't the graph always go down? Or are you individually calculating
retention at each step (i.e., the % shown is the % of users left in the
system who finish that step)....
…On Tue, Jun 20, 2017 at 11:56 AM, Aditya Dash ***@***.***> wrote:
[image: image]
<https://user-images.githubusercontent.com/13080218/27342861-5ad2f364-55af-11e7-8b22-8d1ec32c1f1f.png>
Removed Visit_Index as suggested, and got percentages to display.
Currently working on logging anonymous users completing their first
missions.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#288 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABi-9XKBPnG5dEhq2nMw56R-Vi9ZQav4ks5sF-uegaJpZM4JzSe4>
.
--
Jon Froehlich
Assistant Professor
Computer Science
University of Maryland, College Park
http://www.cs.umd.edu/~jonf/
@jonfroehlich <https://twitter.com/jonfroehlich> - Twitter
|
The latter - at the main page an anonymous user can either start mapping or log in (or do something else that isn't shown in this graph). Each subsequent bar should be smaller than Start Mapping, but I think Sign-In and Start Mapping are still independent of each other. |
So, you are saying that 0.3% of our users click 'Start Mapping'? That seems incredibly small. And only 0.026% complete onboarding (that is, less than 3 users per 100 complete onboarding)? And then, basically, 0% complete their first mission (the label says '0.00000%'). In addition to completing first mission, how many: (i) apply at least one label; (ii) take at least one step? |
I think it will be useful to test this code using a larger dump. Since he has a small local dump and could be that mostly researchers worked on it, the data is such. I'll send the link to the larger dump (until Dec 2016) on slack. |
First mission has a placeholder value right now since I haven't implemented it. I think that the low values are due to the fact that refreshes on the home page log as new page visits under my method of calculation, and since the data dump I had was probably used by developers there were a lot of page refreshes. Hopefully the new data that Manaswi sent will provide more accurate results. |
OK, thanks.
…On Tue, Jun 20, 2017 at 12:37 PM, Aditya Dash ***@***.***> wrote:
First mission has a placeholder value right now since I haven't
implemented it. I think that the low values are due to the fact that
refreshes on the home page log as new page visits under my method of
calculation, and since the data dump I had was probably used by developers
there were a lot of page refreshes. Hopefully the new data that Manaswi
sent will provide more accurate results.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#288 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABi-9Ss-de9WwhXAMP7AyBw2d0gSKaJVks5sF_VTgaJpZM4JzSe4>
.
--
Jon Froehlich
Assistant Professor
Computer Science
University of Maryland, College Park
http://www.cs.umd.edu/~jonf/
@jonfroehlich <https://twitter.com/jonfroehlich> - Twitter
|
Things that we need for the analytics interface:
4 and 5 can be retrieved using Google Analytics API and the rest can be retrieved from the Sidewalk Database.
Options: Add to the admin interface? OR some other interface e.g. a script.
The text was updated successfully, but these errors were encountered: