Define and setup monitoring of Key Performance Indicators (KPIs) for Bisq

## Learning Goal
To be able to tell if changes in a new version of Bisq were a success or failure we first have to define the meaning behind these words. Defining success as an increase in volume probably has nothing to do with the actual changes, but more with the current market situation of the cryptocurrency space or just plain with public holidays in our main markets. The goal of setting up KPIs is to give everyone a tool to be able to measure the success of any change on the platform, find out problems more quickly and to be able to tackle issues we may not be aware of at the moment at all.

This issue should be a starting point of a discussion on what and how we want to measure our success.

## Hypothesis

If we track following KPIs [1] and make it accessible for everyone then everyone should be able to see if a change to the platform was a success or a failure. This should cover different parts of the client/network without being changed for every feature we roll out.

[1] **KPIs**: _To be able to differentiate between different versions of the client we need to be able to segment every metric we collect by version number of the client. Additionally we want to collect the data on a daily/hourly basis to be able to make assumptions about external incidents that occur. To be able to measure conversion rates within the client we could collect data for specific onion addresses and store it by hashing the address with a salt._

Metric | Why?
-------|-------
Number of downloads per timeframe|**Acquisition**: To know if anyone downloaded/updated the client
Number of users who started the client per timeframe|**Activation:** Of those who downloaded this version, how many are actually starting the client afterwards?
Number of users who interacted with the client again per timeframe|**Retention:** Of those who started the client once, how many come back within a certain timeframe (1st, 7th, 14th day retention)?
Number of users who create a offer|**Revenue:** Of those who use the client, how many are creating actually an offer?
Number of users who write a review/give feedback|**Referral:** Of those who use the client, how many are as satisfied with their experience that they write a review or invite a friend

## Metric
This quantitative metrics we are collecting could give us e.g. following actionable insights:
- **# of downloads**: How many downloads do we have on certain days or for certain versions? This could give us a hint on the success of certain marketing activities (we'll soon be able to measure conversions on our website as well (segmentation by referral)) and/or the acceptance of certain versions of our client
- **# of users who start the client**: What percentage of users is able/willing to start the client after downloading it? Do we have tor/bisq-network problems? Does it take too long to connect, so users drop out?,...
- **# of users who start the client more than once**: What percentage of users are using the client multiple times over a certain timeframe. After what time do they drop out? How many users do we loose after 1, 7, 14 days? If the retention rate is low - why is that? ...
- **# of users who create an offer**: What percentage of users that are using the client create an offer? Why is it that high/low? Do we usability/trust/privacy issues?
- **# of users that recommend/review/share the client**: Do the users like the client/idea that much, that they follow a link directing them to a review site, leaving feedback within the client,... What can we do to create a scalable referral source that is driven by the community? What can we do to increase social proof/trust?

## Experiment
The collected metrics should be accessible over an API with a JSON response that can be used e.g. in a Google Spreadsheet or other analytics tools.

## Result
> _- What happened?_
> _- What data did we collect?_
> _- Anything unexpected?_

## Next Step
> _- Pivot or persevere?_
> _- Another experiment for this goal?_
> _- Do we need to clean up?_