Tracking/event endpoint for OFREP

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

• #59: [Tracking] Implement OFREP Configuration Pattern Across SDK Clients
• #39: OFREP 1.0 roadmap
• open-feature/spec#371: Official evaluation metrics hook for experimentation

Start by reading the discussion context, related issues #59 and #39, and open-feature/spec#371 to understand the existing OFREP evaluation model and tracking proposals. Done means reaching agreement on whether tracking is post-1.0, the minimal event schema, and how clients discover the endpoint; this issue names no implementation files or tests.