If you’ve heard me talk about news apps lately, you’ve probably heard me talk ad nauseum about return on investment: earning revenue, open-sourcing code, doing anything under the sun to ensure the time and effort developers spend building great online data projects produces more than just pageviews.
Add to that list something every news app developer should be doing but few of us actually do: Using your apps to learn more about your users.
News apps are typically among the highest drivers of traffic to a website. They are also extremely specific in subject – school test scores, crime by neighborhood, etc. Combine those two attributes and you have a tool that gathers extremely granular data about what large numbers of your users care about.
If a bunch of users visit your education page, you’ve learned one thing: Your users are interested in education. But if a large group of users is looking up standardized test score information about High School X in Los Angeles, not only do you know that they care about education – you know the schools they care about, the subjects they value and likely where they come from, among many other things.
That data, in turn, can be used to drive all sorts of initiatives: Obviously it can help you build better apps, but it can also feed useful data to personalization algorithms; reveal low-level details about the priorities of your user base; and point out trends that might be worth reporting in the news.
Here at CIR, we’ve started to develop a simple event-tracking framework we call django-littlebro. It is designed to work in a manner similar to Django’s built-in caching system – deployable sitewide as middleware, at the view level as a decorator, or at a granular level as a function called within individual views.
It’s designed to work asynchronously using celery and relies on MongoDB for efficiency and flexibility. Most of that code was forked from HonzaKrai’s excellent django-event-tracker application.
The project is still early in development, but we expect to have a working version all packaged up before Christmas. In the mean time, we’re applying an early version to our popular lobbying database, where we’ve been recording search data in a much more primitive way since it launched in August.
Truth by told, you could also use Google Analytics’ event tracking functions to accomplish something similar – we just wanted lower-level integration with Django and more complete access to raw data. But using anything is better than using nothing.
We’ll keep you posted as our project moves along.