alephium / desktop-wallet

The official Alephium wallet for desktop
https://alephium.org
GNU Lesser General Public License v3.0
78 stars 44 forks source link

Add anonymised interaction collection to monitor wallet use #477

Closed mvaivre closed 1 year ago

mvaivre commented 1 year ago

First use case : collect how many addresses our users have.

Other potential use cases :

nop33 commented 1 year ago

What is Ledger Live using

Ledger Live seems to be using Segment for analytics. I couldn't, however, see any related npm packages. I dived into the source code and found these files related to analytics:

In src/renderer/index.html:

    <script
      async
      src="https://resources.live.ledger.app/public_resources/analytics.min.js"
    ></script>

Interesting resources

List of possible analytics tools that we could use image

source: https://getanalytics.io/plugins

Shower thoughts 🚿 🤔

Our own service?

Create our own alephium-apps-analytics service?

How to identify a user without knowing any personal identifiable info?

  1. On app launch, create a unique ID (with nanoid for example)
  2. Store it in localStorage
  3. Use it when recording events
mvaivre commented 1 year ago

Two thoughts:

2 solutions: either use an existing self-hosted analytics solution, or create our own simple service (simple DB + REST or GraphQL server).

Self hosted solution:

TLDR: we either deploy a Posthog stack and use their actions related endpoints, or we quickly develop our own service without wasting too much time on DB schema building etc. as we'd be the only user consuming data.

nop33 commented 1 year ago

Posthog looks like a great proposal! ⭐⭐⭐⭐⭐

Implementing use cases

When the app is launched, we can check if analytics_user_id is stored in localStorage. If it's not, we create one and store it:

const analyticsUserId = nanoid()
localStorage.setItem('analytics_user_id', analyticsUserId)

Then, we identify the user to posthog (or we can pass the id with every event capture, need to look more into this):

posthog.identify(analyticsUserId)

At what frequency is the wallet opened?

We could trigger an event when the app is launched:

posthog.capture('app lauched')

I guess no need to pass a property timestamp, since the event must be stored with some sort of timestamp itself. Otherwise we could do:

posthog.capture('app lauched', { timestamp: new Date() })

How frequently is the default address changed?

We can trigger an event once the address is changed from:

posthog.capture('default address changed')

How many times are the advanced actions used?

We could trigger an event when the "Submit" button of each of the modals of the advanced operations is clicked:

posthog.capture('UTXOs consolidated')
posthog.capture('1 address per group generated')
posthog.capture('Addresses discovered manually')

How frequently is the scan-to-import feature used?

We could trigger an event once the camera captures the QR code and the import was successful

posthog.capture('Imported wallet via QR code')

How many wallets?

I think that's a bit tricky cause it's not an event/action. Maybe it would make sense to just capture the "Created/Imported new wallet" event. Since all events of a particular user will be associated with them through a unique ID that is stored in localStorage on the first app launch after installation, we can calculate the number of wallets based on this metric (maybe also add a metric for deleting a wallet).

posthog.capture('Created new wallet')
posthog.capture('Imported wallet')
posthog.capture('Deleted wallet')

Another approach would be to set a user property. On app launch, we could include the number of wallets the user has, using the $set property:

posthog.capture('app lauched', { $set: { wallets: number_of_wallets } })

Other cool things to track

I think we should ask also the rest of the team, but here's some ideas:

Events to track:

User properties to register:

Things to keep in mind

There's the autocapture setting that it's by default on. It tracks many things out of the gate, like clicks on buttons, pageviews, etc. I would say we turn it off so that we collect only data that we specifically want. Another thing is that session recording is on by default. I think we should turn that off as well

autocapture: false
disable_session_recording: true
mvaivre commented 1 year ago

Great implementation examples! This looks good! 💯

Also fully aligned with the other cool things to track. One addition: with the user property approach, it could be great to collect the number of addresses and contacts as well.

Things to keep in mind: 💯% aligned as well. Let's focus solely on custom events for now.

nop33 commented 1 year ago

Closing since it's merged in v2.0!