Context
At KubeCon EU 2026, both the experimentation and OFREP discussions (recap) raised the question of whether OFREP should define an endpoint for collecting tracking events.
Problem
Today, OFREP defines flag evaluation endpoints but has no mechanism for clients to send tracking or analytics events back to the server. Tracking data (flag evaluations tied to user actions, conversion events, etc.) is left entirely to provider-specific implementations.
Considerations from the discussion
- Pre-aggregation on the client side may be needed to reduce volume
- Configurable flush intervals and bulk payloads were discussed
- The evaluation response could include the events endpoint URL, letting the provider enable tracking conditionally
- flagd could potentially aggregate tracking events before forwarding
- This is a non-breaking addition that could land post-1.0
Questions
- Should this be part of the OFREP 1.0 spec or a post-1.0 extension?
- What is the minimal event schema?
- Should the endpoint URL be discoverable via the evaluation response or a separate configuration endpoint?
Related
Context
At KubeCon EU 2026, both the experimentation and OFREP discussions (recap) raised the question of whether OFREP should define an endpoint for collecting tracking events.
Problem
Today, OFREP defines flag evaluation endpoints but has no mechanism for clients to send tracking or analytics events back to the server. Tracking data (flag evaluations tied to user actions, conversion events, etc.) is left entirely to provider-specific implementations.
Considerations from the discussion
Questions
Related