Ideate how we can add anonymous analytics to fidesctl

So we can get a better idea of how people are using fidesctl, we should add a completely anonymous and respectful analytics phone-home to fidesctl that is optional

– updated 12/20 as a product manager, we’re trying to answer the questions,

• “what commands and flags are adopters using the most?”
• “what errors are adopters running into?” so that we can make the experience or documentation better
• “how are adopters deploying fidesctl, if at all?” so we know what types of infra/configurations to support or create documentation around
• “what resources are being used? and how are they being used?” as we’re looking to improve the language/taxonomy, the experience around creating manifest files, and where we can help with documentation or CLI features

With these questions in mind, here we can aspire to having a standardized event message format that contains:

1. the usual anonymous analytics suspects (version, unique clientid, timestamps, etc)
2. cli command(s) and flag(s) used
3. nonspecific errors returned from commands run
4. whether using our vscode plugin?
5. whether pinging from webserver or from local?
6. fides resource utilization metrics (quantity of systems? datasets? policies? further, number of declarations?)
7. fideslang utilization metrics (high level, which qualifiers are being used? categories? and how many of each?)

in functional requirements, the user should be opted-in, with the option to opt-out as part of our commitment to building and enabling privacy respecting systems.

– updated 01/25

This work is moving to the fideslog repo and will be integrated here once it is ready

[brentonmallen1]

I think the following are probably the key things we want to meet :

• transparency through legible code
  • like the examples
• transparency through clear and concise documentation (outside the codebase)
  • doc page that says what we track and why
• clear means to opt out

[ThomasLaPiana]

@PSalant726 while that is unfortunate, I do not see a world in which this feature ships without the ability to opt-out, it is a key part of respectful systems. If users opt-out and as a result features are incorrectly prioritized, that is the nature of things and we could attempt to do user interviews/other avenues of figuring out what our users want