Cohort analysis - User retention in a Rails application
ninjasandrobots.com
Cohort analysis - User retention in a Rails application
1–10 of 22 posts
Re: Cohort analysis - User retention in a Rails application
#2Interesting but MixPanel does this out of the box, no?
Re: Cohort analysis - User retention in a Rails application
#3Interesting but MixPanel does this out of the box, no?
Yep, and it's a great tool. But I was in a situation where I already have an app with data that hasn't been using Mixpanel. In fact I've got a bunch of apps like that. And I was irritated that there wasn't an easy way to just use that data I already have without having to get into Excel and pivot tables.
I also didn't want to integrate with another API right now and figure out what my "events" are, when those events already exist in my database.
Re: Cohort analysis - User retention in a Rails application
#4Interesting but MixPanel does this out of the box, no?
Yep, and it's a great tool. But I was in a situation where I already have an app with data that hasn't been using Mixpanel. In fact I've got a bunch of apps like that. And I was irritated that there wasn't an easy way to just use that data I already have without having to get into Excel and pivot tables. I also didn't want to integrate with another API right now and figure out what my "events" are, when those events…
The more I think about it, the more an entirely event based app makes a lot of sense (these days). I'm not sure what the design methodology is called but there's a concept where an app's state is essentially determined purely based on events. So without the history, current state is lost. But... A lot of benefits come from this. For example, you can essentially replay your app from day one to any point later on in time.
Your comment made me think of this. I would have recently been in a similar scenario but fortunately I built some internal event tracking early on. It's also a rails app. So every action is tracked using some simple observers. There are subclasses of Event for types like UserRegistrationEvent, etc... Anyway long story short I can essentially replay history by using these events and build, for example, notifications for those events or mixpanel tracking data - retroactively.
It was a fortunate design decision and has ended up really showing its value a number of times. Push notifications hook onto these, tracking credits for our game component, etc...
Edit, I think that the concept I was referring to is called Event Sourcing.
Some resources: http://martinfowler.com/eaaDev/EventSourcing.html
Event Sourcing ensures that all changes to application
state are stored as a sequence of events. Not just can
we query these events, we can also use the event log to
reconstruct past states, and as a foundation to automatically
adjust the state to cope with retroactive changes.
Re: Cohort analysis - User retention in a Rails application
#5Earlier quoted context omitted.
Yep, and it's a great tool. But I was in a situation where I already have an app with data that hasn't been using Mixpanel. In fact I've got a bunch of apps like that. And I was irritated that there wasn't an easy way to just use that data I already have without having to get into Excel and pivot tables. I also didn't want to integrate with another API right now and figure out what my "events" are, when those events…
The more I think about it, the more an entirely event based app makes a lot of sense (these days). I'm not sure what the design methodology is called but there's a concept where an app's state is essentially determined purely based on events. So without the history, current state is lost. But... A lot of benefits come from this. For example, you can essentially replay your app from day one to any point later on in ti…
That sounds pretty awesome. It kind of reminded me of doing operational transforms on collaborative documents.
Re: Cohort analysis - User retention in a Rails application
#6Earlier quoted context omitted.
Yep, and it's a great tool. But I was in a situation where I already have an app with data that hasn't been using Mixpanel. In fact I've got a bunch of apps like that. And I was irritated that there wasn't an easy way to just use that data I already have without having to get into Excel and pivot tables. I also didn't want to integrate with another API right now and figure out what my "events" are, when those events…
The more I think about it, the more an entirely event based app makes a lot of sense (these days). I'm not sure what the design methodology is called but there's a concept where an app's state is essentially determined purely based on events. So without the history, current state is lost. But... A lot of benefits come from this. For example, you can essentially replay your app from day one to any point later on in ti…
Re: Cohort analysis - User retention in a Rails application
#7Interesting but MixPanel does this out of the box, no?
Yep, and it's a great tool. But I was in a situation where I already have an app with data that hasn't been using Mixpanel. In fact I've got a bunch of apps like that. And I was irritated that there wasn't an easy way to just use that data I already have without having to get into Excel and pivot tables. I also didn't want to integrate with another API right now and figure out what my "events" are, when those events…
FYI: You could've just dumped that raw log data into Mixpanel and we would've given you an incredibly beautiful cohort report. We have an API:
https://mixpanel.com/docs/api-documentation/importing-events...
Since you already know the events in your DB, you could've just named them whatever they were. It would've been a smaller script to just import the data into Mixpanel.
Re: Cohort analysis - User retention in a Rails application
#8Earlier quoted context omitted.
Yep, and it's a great tool. But I was in a situation where I already have an app with data that hasn't been using Mixpanel. In fact I've got a bunch of apps like that. And I was irritated that there wasn't an easy way to just use that data I already have without having to get into Excel and pivot tables. I also didn't want to integrate with another API right now and figure out what my "events" are, when those events…
The more I think about it, the more an entirely event based app makes a lot of sense (these days). I'm not sure what the design methodology is called but there's a concept where an app's state is essentially determined purely based on events. So without the history, current state is lost. But... A lot of benefits come from this. For example, you can essentially replay your app from day one to any point later on in ti…
> So every action is tracked using some simple observers.
PSA, as of Rails 4, observers have been extracted to a plugin: https://github.com/rails/rails-observers
Re: Cohort analysis - User retention in a Rails application
#9Nice job :) I've been in the same spot. Looking forward to try this out.
Re: Cohort analysis - User retention in a Rails application
#10This looks cool and I'm excited to try it in a Rails project.
But, mainly, this post highlights my frustration with most analytics tools. I have tried MixPanel and I'm currently paying $99/mo for Kiss Metrics (about to cancel). Frankly, I don't have the time to get neck-deep into one of these services, integrate it, and figure out how to turn the data into revenue-generating actions. And that's setting aside the risk the one I choose gets acqui-hired and shut down.
Maybe I'm asking for magic beans or maybe my products aren't the best fit, but I'm a hacker and I want to do less work, not more. For now, I'll stick to Google Analytics, some basic A/B testing, looking at data via the console, and emailing with my users.
It's pretty sad that this blog post does a better job at explaining what a "cohort" is than Kiss Metrics can [1].