3 ms·
My problem is rather simple actually. We currently track events in a local database very similarly to the events we would send to the Mixpanel. These events hav
by mtarnovan 17y ago
My problem is rather simple actually. We currently track events in a local database very similarly to the events we would send to the Mixpanel. These events have been analyzed only superficially until now. If I wrote the code to analyze and plot the data, it would work on new data also and would make Mixpanel somewhat redundant (dealing with updates is a non-issue, it's the logic that's difficult, not dealing with more data).
However, I don't want to reinvent the wheel, or to invest a lot of time in something that other apps like Mixpanel, NuConomy already do very well. I suspect Mixpanel uses the timestamps of the events for billing and if so they might require some non-trivial changes to their business logic to allow historical data. I hope they will, someday. Until then I might settle on sending them only new events and using R on the historical data.
- adora 17y agoI'm not sure what trends you are looking at, but most consumer startups usually find it unnecessary to look at historical data points past X months. Things (features, users, etc.) change so much that averaging in those data points so far back would misguide you at the present. I would go with a solution that is almost perfect for you if you started today (for example, Mixpanel might be it) -- gives you the best odds for your future analysis. During the couple weeks after switchover, I would just export the Mixpanel data to a local spreadsheet (and run in R as you mentioned) with your other data. After sometime, you won't need it.