-
Notifications
You must be signed in to change notification settings - Fork 488
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
feat: analytics opt-in per type #985
Conversation
see: #980 License: MIT Signed-off-by: Oli Evans <[email protected]>
License: MIT Signed-off-by: Oli Evans <[email protected]>
I'm exploring letting the user add consent for each type of data we collect. Checking the box at the top level enables all the the individual ones. Unchecking an individual one will disable that specific type of metric. The "show me" button will expand the section to reveal a summary help text to explain it, and example data payloads that would be sent if it was enabled. I've cataloged the request data per type here #980 (comment) |
That's absolutely wonderful! Note: I only asked to label this as "BETA" as a short-cut to get something in while we continue to improve it. I'm completely happy calling that design a 1.0 (we can leave the libp2p transport till 2.0). |
License: MIT Signed-off-by: Oli Evans <[email protected]>
License: MIT Signed-off-by: Oli Evans <[email protected]>
You can now opt-in to: - Sessions and browser metrics - Events - Page views - Location - App errors Toggle at the top level enables all but app errors, as they could contain CIDs or file paths, so must be enabled seperately. License: MIT Signed-off-by: Oli Evans <[email protected]>
License: MIT Signed-off-by: Oli Evans <[email protected]>
Countly will set itself on the window object, so no need to do so manually. Ensure a mock Countly prop exists, so code that expects it later on doesnt explode if it hasn't loaded. License: MIT Signed-off-by: Oli Evans <[email protected]>
adds a "more info" link to the status page ask, that takes the user to a stripped down settings page with just the analytics toggle already expanded, to focus things on the current task. License: MIT Signed-off-by: Oli Evans <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 😄 Can't wait for this to release 0.7.0 on Desktop side :D
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Damn, this is top notch work @olizilla 👌✨
Is there a reason for the separate Analytics page?
Yep, I was struggling with how best to link to the analytics section from the ask on the status page. Pushing the info into the ask on the status page had complications, and trying to link to it on the status page would mean adding in custom "scroll to anchor" code as the hash-router means we can't use the browser one. Then @lidel gave the bright idea of just linking out ot a custom settings page with just the analytics on. This has the added benefit of focusing the user on a single task. It is a little odd, but I think it works, and dodges a bunch of other complexity. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think I've ever seen a website or an app being so transparent about metrics gathering.
Down to payload examples and links to actual code, this truly sets the new bar for how this can be done.
Great stuff @olizilla! 😍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Excited to see this addition and the transparency is A++. I understand that an opt-in approach will lead to fewer data points so we will have to work towards encouraging people to enable these options during on-boarding or once related functionality is used. But overall this feels like a nice balance of control and transparency that will gain trust.
A couple of visual nits, feel free to consider:
- I adjusted the layout to remove the white inset. IMO this helps connect the main option with the sub configuration and removes unnecessary nesting.
- Moved the description to the main option in order to explain what is captured without having to expand the individual configuration options. This also creates a larger hit area.
- Changed the checkbox to use the sidebar bg colour in order to increase the contrast, currently it feels too low.
@cwaring thanks! I'll fix the update the first two points in this PR. Could you PR and update to the checkbox component pls. |
License: MIT Signed-off-by: Oli Evans <[email protected]>
Ok, this is holding up the ipfs-desktop release so it's going in! |
- Improved MFS file manager - Opt-in, anonymouse, self-hosted web analytics (see ipfs/ipfs-webui#985) - Bug fixes and UX improvements https://github.com/ipfs-shipyard/ipfs-webui/releases/tag/v2.4.4 License: MIT Signed-off-by: Oli Evans <[email protected]>
- Improved MFS file manager - Opt-in, anonymouse, self-hosted web analytics (see ipfs/ipfs-webui#985) - Bug fixes and UX improvements https://github.com/ipfs-shipyard/ipfs-webui/releases/tag/v2.4.4 License: MIT Signed-off-by: Oli Evans <[email protected]> This commit was moved from ipfs/kubo@6ab34b7
Allow the user to provide individual consents for each type of data we record. Adds explantion and examples to help the user understand what will be recorded. It's a lot of information, so we hide details under expandable sections at each level.
The top level ask is "Analytics? yes/no". Enabling it will enable everything except app error recording, as we cannot guarantee that an error message will never include a CID or a file path or other personal info, so the user must opt-in to that explicitly. It is likely that few will, but we can ask users to enable it when they open a tricky to recreate bug report.
The user can drill down into each type of data that we record, where it is described in more detail, along with an example request and formated query string, so they can see what will happen. Links to the relevant source code of ether the
countly-sdk-web
or the webui are included for the interested reader.see: #980 for more
License: MIT
Signed-off-by: Oli Evans [email protected]