Skip to main content

Route your feature flag data anywhere

GO Feature Flag doesn't compute your data - it delivers it. Every flag evaluation and every outcome you record is routed straight to your own data stack, so analytics, experimentation, and auditing stay where you already run them.

Export your dataRead the docs
The core idea

A router for your flag data, not an analytics engine

GO Feature Flag deliberately doesn’t compute, aggregate, or analyze anything. It captures a lightweight event for every flag evaluation - and any outcome you choose to record - and forwards it, untouched, to the destinations you configure.

That keeps your data yours: it lands in your warehouse, your queue, or your observability stack, where you already do the computing. Two patterns feed that pipeline - evaluation tracking built into the providers, and the OpenFeature Track API for custom outcomes.

Evaluations& Track() outcomesGO Feature Flagroutes — never computesWarehouseBigQuery, S3…QueueKafka, Pub/Sub…Data lakeGCS, Blob…

Two ways data is collected, one way out

Evaluation tracking, built in

Every flag evaluation is captured automatically by the providers and the relay proxy. No code to write - just keep trackEvents on and point it at an exporter.

Flag usage tracking

Track API for outcomes

Call client.track() to record what users actually did - a checkout, a click, revenue. The outcome half of experimentation, joined to the flag they saw.

Tracking API

Exported everywhere

Both event streams flow through the exporters you configure to your warehouse, queue, lake, or observability stack - in batches or in real time.

Exporter concept
Pattern 1 - built into the providers

Evaluation tracking, with no extra code

Every time a flag is evaluated, a feature event - who saw which variation, and when - is captured automatically. The OpenFeature provider’s data collector buffers these events and the relay proxy ships them to your exporters.

How to use it: keep trackEvents: true (the default) on the flags you care about and configure an exporter. No application code changes - the exposure data just starts flowing.

Built in — no application codeOpenFeature providerflag evaluatedflag evaluatedflag evaluatedRelay proxydata collectorExporterfeaturefeatureEvery evaluation → one feature event, shipped automatically
flags.goff.yaml
new-checkout:
  variations:
    on: true
    off: false
  defaultRule:
    percentage:
      on: 50
      off: 50
  # trackEvents is true by default - every evaluation
  # becomes a "feature" event sent to your exporters.
  trackEvents: true

trackEvents is on by default. Add an exporter and every evaluation is delivered as a feature event.

Flag usage tracking docs

Pattern 2 - the OpenFeature Track API

Record outcomes to close the experimentation loop

Exposures tell you who saw what; outcomes tell you what happened next. The standard OpenFeature Track API lets you record a named action - a checkout, a click, revenue - against the same context you evaluate flags with.

How to use it: call client.track(...) where the action happens, add a tracking exporter, and join exposures to outcomes in your stack to measure which variation actually won.

EXPOSUREnew-checkoutvar Bu_8f3OUTCOME · Track() APIcheckout-completed$99.99u_8f3same context keyMEASUREDVariation B convertedwinner
track.js
// Record a business outcome from your app, using the
// same evaluation context you use for flag evaluation.
client.track('checkout-completed', evaluationContext, {
  value: 99.99,
  currency: 'USD',
});
// GO Feature Flag forwards it to your tracking exporters -
// join it with the flag exposure to measure the variation.

The same evaluation context links the outcome back to the variation the user was exposed to.

goff-proxy.yaml
# Send tracking events to their own destination by
# setting eventType on a second exporter entry.
exporters:
  - kind: webhook                 # feature events (flag usage)
    endpointUrl: https://my-collector.example.com/feature
  - kind: webhook
    eventType: tracking           # custom Track() outcomes
    endpointUrl: https://my-collector.example.com/tracking

Route tracking events to their own destination with eventType: tracking.

Tracking API docs

Deliver it wherever you need it

Both event streams flow through the same exporters. Stream each event straight to a queue or endpoint, or batch them and write to storage - mix and match as many destinations as you like.

Stream in real time

Batch to storage

All export integrations

Own your feature flag data

Self-hosted, OpenFeature-native, MIT-licensed. Capture every evaluation and outcome, then route it straight to the stack you already trust - no black box in between.

Get startedView on GitHub

Frequently asked questions

Does GO Feature Flag store or analyze my data?
No. GO Feature Flag does not compute analytics or hold a dashboard of its own. It records a lightweight event for each evaluation and each tracked outcome, then delivers those events to the destinations you configure. The analysis happens in your stack, on your terms.
What is the difference between flag-usage events and tracking events?
A flag-usage (or “feature”) event records that a user received a given variation - it is the exposure. A tracking event records a custom action or outcome you send with the OpenFeature Track API - it is the result. Join the two and you can measure which variation drove a conversion.
Do I need to change my code to collect evaluation data?
No. Flag-usage tracking is built into the providers and the relay proxy. Keep trackEvents: true (the default) on your flags and configure at least one exporter - evaluations start flowing with no application code. The Track API is the only part that needs a call, and only because it records outcomes your app knows about.
Can I send data to more than one destination?
Yes. Configure multiple exporters and each event is delivered to all of them. You can also route feature events and tracking events to different backends by setting eventType on separate exporter entries.
How do I correlate flag exposures with conversions?
Use the same evaluation context (the targeting key and attributes) for both the flag evaluation and your client.track() calls. Both event types carry that key, so in your warehouse you can join exposures to outcomes and measure each variation. See the Tracking API docs.