You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Semester.ly has some built-in data analytics in the form of the statistics page found in /analytics/ endpoint.
It shows statistics such as the following (this is my localhost):
The issue is that a lot of these are useless statistics, and there are other more useful statistics not shown. We want to improve our analytics to actually useful statistics, such as how often features are used, how many daily users there are, etc.
Tasks
Determine what analytics will be useful:
Determine what statistics do not need to be displayed:
Look into alternative data analytics services (perhaps not everything needs to be tracked by our own database)
Look into how to track load time, website traffic, and page views
Remove statistics that are not useful from the analytics page
Sign ups by permission
Number of google calendar exports
Number of ics calendar exports
Number of shared timetable views
Number of shared course views
Number of facebook alert views / by unique users
Number of facebook alert clicks / by unique users
Number of users by school
Number of timetables by school
Number of timetables by semester
Number of calendar exports by type
Number of each reaction used
Implement changes to analytics tables for the stats that we do want to track
Total number of timetables / shared timetables / personal timetables
Total signups
Total number of calendar exports
Number of calendar exports by unique users
Number of users by class year
Number of signups per day for the past week - Should we change this to month?
Total number of users / by class year / by major / by undergrad/grad
Number of daily visitors
Most popular courses
Number of searches
"Find New Friends" function uses
Compare timetable function uses
Average number of custom events per timetable
Dark mode vs light mode users
Devices used
Click-through rates
Load time
Website traffic - total visits, visit average time, which pages are viewed
Add an API test case that verifies statistics shown
Optimize the analytics page queries because it's timing out on production
Nice To Haves
Look into how to delegate saving analytics to the database to another process so that it is non-blocking
Work with search engine team to add analytics that could be used for analyzing student searches
Notes
You will need to either modify the analytics/views.py file or create a superuser to see the /analytics page. Remove the check on line 38 student.user.is_staff, but don't commit this change.
# Originaldefview_analytics_dashboard(request):
student=get_student(request)
ifstudentandstudent.user.is_staff:
# Number of time tables by schooltotal_timetables_by_school= {}
# Modifieddefview_analytics_dashboard(request):
student=get_student(request)
ifstudent:
# Number of time tables by schooltotal_timetables_by_school= {}
You also have to be signed in.
Ask James about connecting to the development database locally if you would like to try to render the analytics page using a snapshot of old production data.
The text was updated successfully, but these errors were encountered:
Data Analytics
Description
Semester.ly has some built-in data analytics in the form of the statistics page found in
/analytics/
endpoint.It shows statistics such as the following (this is my localhost):
![image](https://user-images.githubusercontent.com/27985363/221974028-43e0537b-a961-4d44-9f2d-6f40f28b243c.png)
The issue is that a lot of these are useless statistics, and there are other more useful statistics not shown. We want to improve our analytics to actually useful statistics, such as how often features are used, how many daily users there are, etc.
Tasks
Nice To Haves
Notes
You will need to either modify the
analytics/views.py
file or create a superuser to see the/analytics
page. Remove the check on line 38student.user.is_staff
, but don't commit this change.You also have to be signed in.
Ask James about connecting to the development database locally if you would like to try to render the analytics page using a snapshot of old production data.
The text was updated successfully, but these errors were encountered: