3 ms·

Interesting but MixPanel does this out of the box, no?

nate 14y ago
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.
- whalesalad 14y ago
  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 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. And also: http://krasserm.blogspot.se/2011/11/building-event-sourced-web-application.html http://krasserm.blogspot.se/2011/11/building-event-sourced-w...
  - revorad 14y ago
    That sounds pretty awesome. It kind of reminded me of doing operational transforms on collaborative documents.
  - another 14y ago
    http://www.cs.cornell.edu/fbs/publications/smsurvey.pdf http://www.cs.cornell.edu/fbs/publications/smsurvey.pdf
  - steveklabnik 14y ago
    > 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 https://github.com/rails/rails-observers
- suhail 14y ago
  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-older-than-31-days 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.

nate 14y ago

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.

whalesalad 14y ago
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 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. And also: http://krasserm.blogspot.se/2011/11/building-event-sourced-web-application.html http://krasserm.blogspot.se/2011/11/building-event-sourced-w...
- revorad 14y ago
  That sounds pretty awesome. It kind of reminded me of doing operational transforms on collaborative documents.
- another 14y ago
  http://www.cs.cornell.edu/fbs/publications/smsurvey.pdf http://www.cs.cornell.edu/fbs/publications/smsurvey.pdf
- steveklabnik 14y ago
  > 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 https://github.com/rails/rails-observers
suhail 14y ago
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-older-than-31-days 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.