feat: analytics opt-in per type

[olizilla]

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]

[olizilla]

I'm exploring letting the user add consent for each type of data we collect.

expanded the sessions details

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)

[Stebalien]

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

[olizilla]

Such copy. Much care.

[hacdias]

LGTM 😄 Can't wait for this to release 0.7.0 on Desktop side :D

[fsdiogo]

Damn, this is top notch work @olizilla 👌✨

Is there a reason for the separate Analytics page?

[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.

[lidel]

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! 😍

[cwaring]

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.

[olizilla]

@cwaring thanks! I'll fix the update the first two points in this PR. Could you PR and update to the checkbox component pls.

[olizilla]

Ok, this is holding up the ipfs-desktop release so it's going in!