mathieudutour
commented
6 years ago why a saga instead of a redux middleware? Seems like the perfect use case for a middleware
Closed joshwcomeau closed 6 years ago
mathieudutour
commented
6 years ago why a saga instead of a redux middleware? Seems like the perfect use case for a middleware
AWolf81
commented
6 years ago Thanks for creating the issue. I like the idea of having the abstraction with an analytics service.
I briefly checked Heap and one thing we'll need to add is an identification heap.identify(userId) of the installation. I think we can do this with an uuid that we'll generate on first start because electronStore will not contain that id or do we have another option to do this because clearing the store would always create a new userId?
But I think that's the easiest way with-out a login and probably won't happen often. Or maybe we can read an id from the computer (e.g. network MAC address) and use this as identifier.
A location to store the id would be in an analytics.reducer or maybe we could add an app-settings.reducer and store the Id there. So we can also add app settings there later e.g. author name, E-Mail etc.
joshwcomeau
commented
6 years ago why a saga instead of a redux middleware? Seems like the perfect use case for a middleware
The reason I want to try a saga is just to reduce the amount of potentially-foreign concepts this repo uses (new contributors shouldn't have to learn about both middlewares and sagas, ideally).
I think we can create something very similar if we takeEvery('*', handleAnalytics); inside handleAnalytics we can switch on the action type, the same way we would in a middleware.
But yeah, if the ergonomics of it are weird, I can switch it to a middleware.
I briefly checked Heap and one thing we'll need to add is an identification heap.identify(userId) of the installation
Yep! I decided to generate a UUID (feels less personally invasive than finding some sort of device identifier), and store it in electron-store. I don't think Redux needs to know about it since it never affects the UI. It's true that if the user clears their state, they'll be treated as a brand-new user, but I think that's OK.
First PR is up: #244.
After playing with Heap, I realized it's not great for what we need. They do a bunch of stuff for you, to be helpful, but it winds up making things more complicated. For example, they do page-tracking automatically, but it doesn't work since in our desktop app, we don't have routes. They do have a custom events system, but it feels bolted on, and we'd get a bunch of noise from all their wrong assumptions.
Mixpanel is much closer to what I was looking for. You just submit events with a .track call. Plus, their UI is much cleaner, and I actually have experience working with them (It's been a couple years, but I remember having good experiences with their client library).
j-f1
commented
6 years ago Both Heap and Mixpanel have a free tier, but are paid beyond that, and are quite expensive. In the future I imagine we might have a Patreon or similar to fund services like this, but for now we should assume that we might need to switch providers if we outgrow the one we pick, and find a cheaper alternative.
If you outgrow Mixpanel, you could contact them to see if they’d be willing to give us a free plan since we’re open source.
AWolf81
commented
6 years ago Great, I'd like to test the analytics later.
Is it possible to see the statistics from Mixpanel? I would be interested to see some stats. I think that would be useful for testing the analytics.
joshwcomeau
commented
6 years ago Yeah, Mixpanel has a reports section :) I just submitted a test event and it looks like it'll be helpful.
Unfortunately, Mixpanel bills by the seat, and we only get 3 seats =( so I'm thinking I'll create a contributors account and DM any interested collaborators the authentication details?
AWolf81
commented
6 years ago Yes, I've seen the pricing 999 USD/year is pretty expensive but I think the free plan is large enough for us.
I'm interested to see the stats. Please DM me the contributors account details on Gitter.
Right now, Guppy has no tracking at all. As a result, we don't know how many people are using it =(
This has been discussed much in Gitter, and I think we should move towards using a pre-built service. The obvious choice is Google Analytics, but because Google uses this product to follow users around the web (and beyond), I don't feel great about adding another data point for them through Guppy.
I've been turned on to some other services though:
Fathom is essentially a fancy counter, it tells you how many people are using your thing, although it's very web-focused and doesn't seem to have additional info about what folks are doing. Plus it doesn't offer a hosted solution yet, so we'd need to figure out where to put it.
The other two are analytics products; you wire it up to track certain events (launch dev server, build, test, etc). Now that I think about it, that info would be really good to have; it could help us prioritize features based on how people are using Guppy, for example. And I feel OK about it from a privacy perspective because we still aren't collecting any personally-identifiable information, although we will definitely add this to our privacy policy.
Both Heap and Mixpanel have a free tier, but are paid beyond that, and are quite expensive. In the future I imagine we might have a Patreon or similar to fund services like this, but for now we should assume that we might need to switch providers if we outgrow the one we pick, and find a cheaper alternative.
I think our solution should be an abstraction over one of those services, so that we can easily swap it out later if needed. So I imagine we will have a new Redux Saga that will watch for specific actions, and when it sees them, will call a method in a new
analytics.service.jsfile. That way, if our analytics provider ever changes, we just need to update that service file.I'm gonna take a quick stab at implementing it this morning. I'll start with Heap Analytics, since I've heard good things from a trusted source, but I'm not married to that solution if anyone has alternative suggestions.