[EPIC] refactor metametrics

[NicolasMassart]

What is this about?

As MetaMetrics system evolved, we stacked multiple ways to define events. We even have a Legacy section in the events list.
Even on the new events, there's multiple ways to track events because they are structured differently. This forced us to build "conversion" functions.

Scenario

No response

Design

No response

Technical Details

• chore: clean the events list from unused events #11317
• chore: clarify the events and cleanup the list to align with extension #11570
• chore: get rid of legacy events #11568
• chore: remove all legacy related code (conversion functions and tests) #11569
• align mobile and extension metrics use(1)
• chore: Refactor event tracking method #11319
• chore: Replace Segment SDK Anonymous ID patch by plugin #11219
• [Bug]: Some metametrics events are sent with an anonymous ID when they should have user ID #11065
• Feat: display metametrics ID in app settings #12469
• Make getAnalyticsParam() called as default params for all tracking events #12468
• [Bug]: getAnalyticsParams return anonymous props that's not moved to sensitive props #12728
• chore: remove undefined from MetaMetrics.getMetaMetricsId() promise return #12688
• refactor: make storage-wrapper operations synchronous #12913

Note

1: research done, decision is not to align as none is an acceptable target, but refactor mobile the best way as possible and later align extension on it

Threat Modeling Framework

What are we working on?

• event tracking cleanup and alignment with extension

What can go wrong?

• too many events tracked (not enough cleanup)
• not enough events tracked (too much cleanup)
• data tracked when they should not be (privacy)
• data analytics broken (dashboards and data store not updated accordingly)

What are we going to do about it?

• sync with data team and PMs of each feature (ext and mobile)
• clearly define the Segment tracking plan
• write unit tests
• review code and QA test all critical features

Did we do a good job?

• so far yes, but we will do even better

Acceptance Criteria

• events list clarified and simplified, consistent and cleaned our of legacy
• all changes tested and test passes
• events properly received and usable on the analytics side (Segment/Mixpanel)

Stakeholder review needed before the work gets merged

• Engineering (needed in most cases)
• Design
• Product
• QA (automation tests are required to pass before merging PRs but not all changes are covered by automation tests - please review if QA is needed beyond automation tests)
• Security
• Legal
• Marketing
• Management (please specify)
• Other (please specify)

References

No response

[gauthierpetetin]

Linking this ticket here as well, to make sure that we adopt a similar approach in Extension and Mobile, whatever we agree on.
https://github.com/MetaMask/mobile-planning/issues/1898

[NicolasMassart]

Also related to https://github.com/MetaMask/mobile-planning/issues/1905 for aligning mobile and extension on this topic

[NicolasMassart]

The "align mobile and extension metrics use" item has to be considered partially.
We can align events and the way they are received on Segment, align prop names, ... but the two systems are very differently architectured (first because of the use of the Segment SDK on mobile), so I would not push for 100% alignment.
We can align the structure of events to pass to the tracking function (the payload).

[gauthierpetetin]

That sounds reasonable to me, thanks for the analysis!

[NicolasMassart]

It seems we only have to go through the cleaning and extension alignment phases!

[NicolasMassart]

This will move forward as we plan a quest for metrics streamlining this month. Results should allow to clean the events in app.
cc @bschorchit @MarioAslau