-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tracking #91
Comments
We could use segment.io |
Cool. What happens if we bust 100,000 events per month? |
I guess it just stops logging them. It'd be stupid to just die. |
We'd just have to limit what we track and have it opt-in as part of the setup process. |
Yeh, and make sure people don't change our api when they configure it, lol. |
Yeah that'd be important hah! |
I had a reply from Segment regarding having the API write key in the source code:
Looks like we're good just to implement Segment.io straightaway. |
@GrahamCampbell you don't know of any Laravel adapters for this do you? |
I could write one if needed. |
I've not been able to find one, but it'd be good to have if you've got the time? If not, I'll have a go by checking out your adapters and stuff :) |
Sounds like a bad idea to me. Or make it optional and disabled by default. |
@willdurand I think @jbrooksuk was talking about an 'opt-in' thing, which means it would be deactivated by default unless you choose to give some feedback. Seems like a cool idea, would love to work with you guys on the adapter :) |
I think we should have a check box which is enabled by default on the setup page. |
I'm pretty sure WordPress tracking is actually non optional too. |
👍 Checkbox on Setup like the one we have now to show support. |
Definitely a checkbox. One thing we could do is fetch the key when they say yes to tracking and decrypt it. This way we aren't giving it away easily. |
WP does not care about privacy, doing silly stuff. Does this mean Cachet should do the same? Nope. By the way what showing support actually does? And why can't I enable it later? |
It's not even tracking as such, because we aren't tracking a user in particular just usage stats. No component or incident data would be included. @willdurand it adds a link in the footer to Cachet. |
Thoughts:
|
@GrahamCampbell how would you suggest we fetch the write key? We could host it encrypted on our website and fetch it at run time? |
No point. "encrypted" doesn't work because we'd still need to code the key to decrypt it into cachet... |
A first easy step to track downloads/installs would be to use Composer's |
That doesn't work. That only works when a package is installed, not when someone downloads this from github. |
Right |
We could always just require a dummy package and track the stats on that though. |
GitHub doesn't have downloads stats?? |
No, it doesn't. It shows repo clones, but most people seem to be downloading the zips. |
I am surprised they didn't think about such feature! |
Ok, then we just pull down the key from the server and store it somewhere in plain text (also advisable as a solution from Segment) that way, if the key ever gets abused, we can re-issue quickly. |
Heh, looks like someone is making a wrapper. |
They've misused facades, and been calling config in their class. Bad. :( |
Yeah I took a look through and it's not great, we'd be better off with our own version. Sent from my iPhone
|
I've started work on this. |
Now we need to work out how we can assign each user within a Cachet setup a unique ID for anonymous tracking and of course, only do the tracking if the administrator allows us to. |
I have an idea regarding the unique ID. We don't actually care what user of what status page does what. So let's use |
I'm wondering whether it'd be worth adding some kind of internal tracking that gets sent to directly back to us, to see how often something happens.
We'd only need to track:
Then we'd have enough data to use as "we've had x installs" etc.
Of course, there are things like:
That we'd need to take care of.
The text was updated successfully, but these errors were encountered: