I (dev) would like to have analytics for dApp interactions

[mohsen-ghafouri]

📜 User Story

As a user, I would like to have analytics for dApp interactions, so that I can make informed decisions when improving the feature.

Story Link

Description

We want to understand how users interact with dApps, which dApps are the most popular, and how different actions impact user behavior and experience. This will help us focus on compatibility, user experience, and feature development.

Acceptance Criteria

• The system should track when a user connects to a dApp.
• The system should track each type of interaction (e.g., sign, send) with a dApp.
• The system should track the type of request made to a dApp.
• The system should log each network requested by dApps during interactions.
• The system should track when a user clicks the “Buy ETH” button during a transaction request.
• The system should log failed session requests, including failures due to processing or signing.
• The system should track user actions on session requests (approve/reject).
• The system should track when a user disconnects from a dApp explicitly.

Additional Information

• Data points for each event should include: dapp_name, request_type (if applicable), requested_network, and timestamp.
• Events should be implemented with privacy considerations, avoiding storing identifiable user or session data.

[ilmotta]

About tracking the names of dApps users are using, to me this falls in the category of real private data. It would facilitate identifying individuals in MixPanel, which is something we don't want, even if the user agreed to share usage data.

dApps users connect to the most to know on which dApps to focus the most in terms of compatibility

-- https://www.notion.so/I-dev-would-like-to-have-analytics-for-dApp-interactions-41068dbaf9284ce0b482ae5198a01435?pvs=4#0d1b708c391a42cd93f897048f2702ab

We can alleviate this problem a lot if we change our implementation in status-go and the client to allow events to override the default Distinct ID we generate once per Status installation.

I believe this implementation is the way to go for metrics that are not tied to user flows. Similar to how metrics are available in app stores. In MixPanel, these metrics would live in the Insights reports, not in flows/funnels/retention reports.

Of course, the tradeoff is that the metrics would be distorted by the frequency at which users use the dApps, but we would still be able to see which dApps are growing in usage and which ones almost never happen, which will allow us to answer the business question in the Notion doc.

@mohsen-ghafouri @clauxx @shivekkhurana

cc @Samyoul

[clauxx]

@ilmotta fully agree with you. These requirements were built with the assumption of no Distinct ID. Would be great to have a way to send an event without tying it up to a session/device, since we don't care too much for the distinction between: many users using a dapp sometimes and few/one user(s) using a dapp frequently.