Track Actions, Not Feature Flag State

Data scientists and growth teams love to track everything. The assumption being that with enough data, user behaviors can be predicted and then manipulated. As such, when feature flags are introduced to an application, some people will want feature flag state to be included in the existing analytics data.

In my experience, this is a bad idea. For starters, it adds even more complexity to the code, especially if tracking happens in both the front-end and the back-end context. But, more than that, tracking feature flag state cuts against the grain of a feature flag's expected life-cycle.

Non-operational feature flags are intended to be transient: used briefly as a safe way to update the application; and then, removed when no longer needed. To track their state is to give feature flags a form of object permanence that they don't merit. This can dilute the sense of urgency that engineers should feel with regard to code quality.

Tracking feature flag state also represents data-leakage. Meaning, feature flags are an implementation detail used by the engineering team. If the knowledge of a feature flag becomes known outside of engineering, it can create an unclear ownership boundary. This, in turn, can create confusion around feature flag usage; which will, in turn, lead to poor coding standards.

Instead, data scientists and growth teams should continue to track actions performed within the system. And, if feature flags are being used to A/B test an interaction, each conditional branch should be tracked as a separate action or event property (having nothing to do with the low-level feature flag details).

Have questions? Let's discuss this chapter: https://bennadel.com/go/4556