Show HN: Visit tracking for Rails | Hacker News Reader

Show HN: Visit tracking for Rails

ankane.github.io

51 pointsakane16 comments

My e-commerce company started tracking all page visits in the database about a year ago, it's been one of the best decisions we've made.

It's amazing to have all of your data in one database, you can do so much with that data. I can answer virtually any question about how people interact with our sites without needing to closely integrate with 3rd party services.

Sure, if you have thousands of visits a second, you need to put some thought into handling that load, but it's definitely doable and not too hard. Once we get to that point, we'll probably have the page views going to another dedicated databases and use postgres_fdw to handle the queries across the two databases.

Won't this absolutely hammer your database with real-time writes?

Unless you have hundreds of unique visitors per second, this shouldn't be a problem.

You could also run a secondary db and use db_charmer or something to set the writes on a different db

This looks great! I was just thinking I needed something like this a couple days ago, and then this popped up on HN today. I will definitely check it out.

I haven't had a chance to dig too deeply into it yet, but is the info stored in a session cookie and then you can decide if/when to write it to the db? For example, if I didn't want to write every unique visit to the db, but only when a user signs up, or signs in, or takes some action x, do I have the flexibility of when I write to the db?

Currently, a visit record is created as soon as a user lands on a page with the Javascript, but I'm curious to see other ways people want to it.

Why not just log your visits and explore them in something like Splunk?

Any stats on how much of a load this puts on the existing app?

Could this send to redis or a delayed job and be eventually consistent to database for non-logged in users?

Excellent point. This type of logging should go into the background.

Redis, yes. Perfect for this kind of thing. delayed_job might make less sense, since delayed_job still INSERTs to the database.

I haven't benchmarked it specifically but I'd have to guess your time savings to store the information in a postgresql job queue vs the visits table would be negligible at best.

Nice work Andrew. No specs though? :(

nice work. one of the biggest problems with external tracking services (mixpanel/kissmetrics/google analytics) is reconciling the data with what's present in your database. this solves that problem really well. great start

I'm not familiar with the other analytics providers, but can't you track certain events (like orders and charges) and bind properties to them using Mixpanel? This could help you reconcile the data in your database.

you can track server side events with google analytics too (if using universal analytics).

I would have no idea how to add the data if you hadn't been tracking it already though.

Most of these analytics providers also allow you send data from your server that you can then correlate with your visit data. While I think solutions like this works initially, in my experience you will spend a lot more time building the capabilities that an analytics package could provide out of the box with little work. For eg., being able to visualize tracking live as it happens is something I have really gotten used to.

Easy setup and integration so far!

Reply on news.ycombinator.com