Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: tracking #260

Merged
merged 5 commits into from
Jun 12, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
44 changes: 44 additions & 0 deletions specification/sections/06-tracking.md
Original file line number Diff line number Diff line change
@@ -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
toddbaert marked this conversation as resolved.
Show resolved Hide resolved

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
toddbaert marked this conversation as resolved.
Show resolved Hide resolved
- Support A/B testing and experimentation use-cases
- Support client and server paradigms
toddbaert marked this conversation as resolved.
Show resolved Hide resolved
toddbaert marked this conversation as resolved.
Show resolved Hide resolved
- Provide recommendations around:
- Async vs sync
- Flushing mechanisms
- Event batching

### Non-goals

- Creating an experimentation platform
- Covering every user-tracking use case
beeme1mr marked this conversation as resolved.
Show resolved Hide resolved
- 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
beeme1mr marked this conversation as resolved.
Show resolved Hide resolved
- Minimum traffic and payload size
- Ease-of-use for application authors, integrators, and provider authors (in that order)
Loading