Tracking

[cachethq]

Tracking

[jbrooksuk]

We could use segment.io

[GrahamCampbell]

Cool. What happens if we bust 100,000 events per month?

[jbrooksuk]

I guess it just stops logging them. It'd be stupid to just die.

[jbrooksuk]

We'd just have to limit what we track and have it opt-in as part of the setup process.

[GrahamCampbell]

Yeh, and make sure people don't change our api when they configure it, lol.

[jbrooksuk]

Yeah that'd be important hah!

[jbrooksuk]

I had a reply from Segment regarding having the API write key in the source code:

In general revealing the write key isn't too much of a concern. Of course when others know your write key it's possible for them to send analytics events to Segment without your permission, but we haven't seen any malicious behavior around that in the past.

Usually just adding the tracking with your key in there is alright. If you prefer to hide the key a layer deeper in a config file that's one option, or depending on the type of project you're working on you could make an API call to your server to retrieve the write key when a new project is started with your open-source software.

Any client-side javascript tracking calls will reveal the write key by default, so there's not a lot we can do for that, but again we've never seen any malicious behavior in that regard.

If you have some more detailed questions about the architecture of your project we'd be happy to help make some suggestions about best practices.

Looks like we're good just to implement Segment.io straightaway.

[jbrooksuk]

@GrahamCampbell you don't know of any Laravel adapters for this do you?

[GrahamCampbell]

I could write one if needed.

[jbrooksuk]

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 :)

[willdurand]

Sounds like a bad idea to me. Or make it optional and disabled by default.

[foxted]

@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 :)

[GrahamCampbell]

I think we should have a check box which is enabled by default on the setup page.

[GrahamCampbell]

I'm pretty sure WordPress tracking is actually non optional too.

[joecohens]

👍 Checkbox on Setup like the one we have now to show support.

[jbrooksuk]

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.

[willdurand]

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?

[jbrooksuk]

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.

[jbrooksuk]

Thoughts:

• We'll need some a privacy policy.
• We need to highlight that we don't track any personal information.
• All collected data is anonymous.
• List exactly what we're tracking.
• Rather than tracking, it should be "Usage stats" since that is what it is.

[jbrooksuk]

@GrahamCampbell how would you suggest we fetch the write key? We could host it encrypted on our website and fetch it at run time?

[GrahamCampbell]

No point. "encrypted" doesn't work because we'd still need to code the key to decrypt it into cachet...

[willdurand]

A first easy step to track downloads/installs would be to use Composer's notify-batch feature.

[GrahamCampbell]

That doesn't work. That only works when a package is installed, not when someone downloads this from github.

[willdurand]

Right

[GrahamCampbell]

We could always just require a dummy package and track the stats on that though.

[foxted]

GitHub doesn't have downloads stats??

[GrahamCampbell]

No, it doesn't. It shows repo clones, but most people seem to be downloading the zips.

[foxted]

I am surprised they didn't think about such feature!

[jbrooksuk]

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.

[jbrooksuk]

Heh, looks like someone is making a wrapper.

[GrahamCampbell]

They've misused facades, and been calling config in their class. Bad. :(

[jbrooksuk]

Yeah I took a look through and it's not great, we'd be better off with our own version.

Sent from my iPhone

On 10 Jan 2015, at 10:10, Graham Campbell [email protected] wrote:

They've misused facade, and been calling config in their class. Bad. :(

—
Reply to this email directly or view it on GitHub.

[jbrooksuk]

I've started work on this.

[jbrooksuk]

Package is done.

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.

[jbrooksuk]

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 app.key as the unique ID. This also means that we don't need track just the logged in users, but people just viewing the homepage etc.