Painful process to modify metrics
Problem
From time to time, teams feel the need to modify existing metrics. Potential causes of this are:
- A new feature is added for a stage and they want to add this feature to their main aggregated xMau metric
- A feature is moved to a different edition of the application and should be tracked there as well, e.g. see !117939 (merged)
We discourage modifying existing metrics (see #408633 (closed) for further infos around this topic). However, the current process has multiple drawbacks:
- High effort to remove current metric and create a new one, which includes coming up with a new name for the new metric
- No standardized way to indicate that metric was "replaced" not "removed". Stakeholder's need to dig through MRs to realize that a metric was replaced with a new one.
- No standardized way to create a link between the old metric and the new one.
Proposed solution(s)
At first we want to collect potential solutions to the above mentioned problems and evaluate if we see a way to handle these situations better.
Proposals:
- Version metrics, similar to how Snowplow handle's versioning of event definitions (see Blog post and Documentation
Next steps
-
collect potential solutions