Tracking in Browser Portal

We should have a discussion about appropriate ways to track user interaction with the Browser Portal.

Right now, we’re using Mixpanel. As currently implemented, information about names the user owns and/or is browsing gets sent to Mixpanel in the Referrer header.

This doesn’t really seem consistent with our messaging about user control of data and no tracking:

We need to balance this goal with getting an idea of how people are using the software.

Things that are interesting to us are information such as: When someone downloads the app, what do they do? Do they try to register a name? Do they look up other names? Does anyone actually use the Dropbox hosting feature? How many people start to register a name but drop off when they need to pay?

At the very least, it seems to me we should make this opt-in. Longer term we might look at more anonymous/decentralized options.

What do you think?

@larry Check this out: https://sebastiangreger.net/2014/02/privacy-aware-design-replacing-google-analytics/

Mint is no longer being sold but Piwik is a self-hosted solution that looks pretty good:

I was thinking about this in the context of removing Mixpanel, as I feel that’s very important. At least if we keep some form of analytics we can go with a self-hosted privacy preserving one.

Alternatively, we can remove the analytics altogether and focus on network metrics that cannot be gamed (like names registered and profiles filled out).

We could use a self hosted, solution like piwik and make the analytics URL configurable like our other URLs. By default it could point to the Blockstack Inc hosted installation - users could change the URL to point to their own piwik installation or disable analytics all together.

Reviving this discussion.

I think we should have self-hosted analytics that only collects anonymized usage statistics and is open sourced. We could even go one step further and open up the data that’s collected. If the data we collect does not compromise the privacy of users, then there shouldn’t be any issue publishing that data. And of course we should allow users to opt out of the analytics if they want to. cc @larry @hologram @ryan

2 Likes

Think this makes a lot of sense!

I’d add that we should make analytics and diagnostics opt-out during pre-release/beta and opt-in on stable releases. (Copying Apple’s model here)

1 Like

Second this. Could be interesting to actually allow users to easily view our analytics data. Could also be a little scary though if we don’t do so hot :smiley:

Hmm interesting. I’m thinking about how we could use beta analytics to better understand how the app is being used before a launch. Normally that kind of enhancement is done post-launch though so this would be fine with me.

Are all of the releases so far technically pre-releases, which would mean an opt-out policy for the current browser? I don’t like that policy in that case.

Did you have already a discussion about how third party developers should handle this?
Would they have access to some tools provided by Blockstack?
Are they allowed to develop/implement tracking tools themselves, or is it no allowed by some terms?
What about features like recommendation systems that are basically built on top of user behaviour?

Currently hard to imagine to develop a product without having at least some user behaviour data for feature optimising and performance review.
On the other hand, that’s exactly what a decentralized app should be about… don’t track my user behaviour… period.
Classic user comment: "Even if you say that you track data anonymized, how should I be sure that you do?"
Having a clear line, taking a stand, black / white, is often a much stronger value proposition vs. coming up with some blurry compromises, which than is not taken seriously in the broader public "they are all the same … sell our data… "

I like that. It would be great if developers would have access to it and users would have a Blockstack platform wide “opt out” option.

So moving forward on this @larry @yukan, what’s a reasonable first step? Perhaps we should begin by including a simple Telemetry Consent prompt in the browser and marketing site which stores the user’s response in the browser cache. We can do that separate from actually implementing any anonymous tracking features.

I’m also not sold on it being opt-out by default for pre-releases.

I think a consent prompt in the Blockstack browser is a good start.

I’ve been wondering about how to collect metrics from the app I’m building and I like where you guys are going. One thing I wanted to add/ask is guarantee does a user have that I wont just add google analytics and track user information without their consent?

I think @patrick raised somewhere the point that it’s hard to discover/debug programming errors with the decentralized model because they happen at the user’s side.

Providing a good solution for analytics and debugging is probably a really important thing for Blockstack. Users should have a very low barrier for reporting errors to the developers (i.e. a popup with “The app just had an error. Want to report it? [Text box for additional information]”).

If we don’t provide a good and easy-to-use solution for this people might get back to “just including the already working Google Analytics suite”, which is probably a very bad thing for a new internet :slight_smile:

1 Like