feat: tracking (#260)

- Adds section 6: tracking - no normative sections - overview - goals/non-goals (temporary) This is not final! Please review goals/non-goals especially, and add any questions you might have. --------- Signed-off-by: Todd Baert <[email protected]> Co-authored-by: Michael Beemer <[email protected]> Co-authored-by: Nicklas Lundin <[email protected]> Co-authored-by: Weyert de Boer <[email protected]>
open-feature · Jun 12, 2024 · d46e6dc · d46e6dc
1 parent e368a5c
commit d46e6dc
Showing 1 changed file with 44 additions and 0 deletions.
diff --git a/specification/sections/06-tracking.md b/specification/sections/06-tracking.md
@@ -0,0 +1,44 @@
+---
+title: Tracking
+description: Specification defining tracking API
+toc_max_heading_level: 4
+---
+
+# 6. Tracking
+
+[![experimental](https://img.shields.io/static/v1?label=Status&message=experimental&color=orange)](https://github.com/open-feature/spec/tree/main/specification#experimental)
+
+## Overview
+
+Experimentation is a primary use case for feature flags.
+In practice, this often means flag variants are assigned to users at random or in accordance with a business rule, while the impact of the assigned variant on some business objective is measured.
+Vendors and custom solutions often support a _tracking_ or _goal measuring_ API to facilitate the measurement of these business objectives.
+
+### Goals
+
+- Develop official terminology to support consistent implementation
+- Specify a flexible API widely compatible with basic vendor functionality
+  - Define tracking event payload
+  - Define tracking event identifier
+  - Support A/B testing and experimentation use-cases
+  - Support client and server paradigms
+  - Provide recommendations around: 
+    - Async vs sync
+    - Flushing mechanisms
+    - Event batching
+
+### Non-goals
+
+- Creating an experimentation platform
+- Covering every user-tracking use case
+  - We will not define any data aggregation mechanisms
+  - We will not focus on "metrics", but instead, "facts"
+
+### Design Principles
+
+We value the following:
+
+- Adherence to, and compatibility with OpenFeature semantics
+- Maximum compatibility and ease-of-adoption for existing solutions
+- Minimum traffic and payload size
+- Ease-of-use for application authors, integrators, and provider authors (in that order)