Statsig

the statsig destination sends events to statsig https //www statsig com/ using the server side log event http api https //docs statsig com/api/content/api reference/events/log custom events , so that chord cdp events can be used as metrics for statsig experiments and feature gates this is a cloud mode (server side) destination only , and deliberately so the metrics that decide a statsig experiment are revenue events — order completed , refunds, subscription renewals — and in chord cdp those frequently arrive from backend sources (shopify webhooks, server to server ingest) that never touch a browser a device mode plugin could not see them, which would leave you with an experiment that cannot measure its own success metric segment ships statsig the same way, cloud mode only feature gate and experiment evaluation stays in your storefront's own statsig sdk this destination only ever calls log event ; it never calls check gate , because that endpoint automatically logs exposure events and would double count exposures the storefront sdk already records you will need server secret key — found in project settings > api keys in the statsig console it starts with secret do not use a client sdk key here connecting to the statsig cdp destination warning before connecting destinations in the chord cdp, please verify with all destination owners that all non chord cdp configured destinations are disabled running external destinations alongside configured chord cdp destinations can result in duplicate events downstream log into the chord data platform navigate to the cdp click the "add" button next to destinations select statsig from the destination catalog enter the destination name and your server secret key confirm the anonymous id key matches your experiment unit (see identity and experiment units # below) click "create" to connect identity and experiment units this is the setting that most often breaks a statsig integration, so it is worth getting right before you ship statsig randomizes each experiment on a unit id if the storefront's statsig sdk assigns a visitor to a variant using one id, but chord cdp sends the conversion event under a different one, the event will not join to the experiment group — every readout comes back flat, with no error anywhere to explain why the destination sends statsig field chord source user userid userid user customids \<anonymous id key> anonymousid the anonymous id key defaults to stableid , which is statsig's own convention for an anonymous unit for this to line up, your storefront must be configured to pass the chord anonymousid as statsig's stableid rather than letting the statsig sdk generate its own if your experiments are randomized on a different custom id, set the anonymous id key to match it migrating off segment? whatever field you mapped to statsig's userid in the segment destination is the unit your existing experiments are already keyed on carry that exact mapping over, or your readouts will break at cutover event mapping statsig has no fixed event taxonomy — custom event names are first class — so track events pass through under their own name no allowlist, no renaming chord event type statsig eventname notes track the chord event name, verbatim custom events pass through unchanged page page view sent only when send page events is enabled (default on) identify identify sent only when send identify events is enabled (default off ) any other event type ( group , screen , …) is skipped with an explicit log line, never dropped silently track events statsig field chord source notes eventname event passed through verbatim value properties revenue > properties total > properties value overridable via the value property setting numeric strings are coerced to numbers time timestamp unix milliseconds metadata properties see metadata flattening # user identity + context see identity and experiment units # page events statsig field chord source notes eventname (hardcoded) page view page identity lives in metadata , so a single metric can be filtered per page rather than fragmenting into one metric per page name metadata url / path / title / referrer context page explicit properties of the same name win over the context values metadata name name present when the page event is named value is never set on page events identify events statsig has no user profile api, so an identify call is logged as an ordinary identify event with the user's traits in metadata this is off by default to avoid inflating event volume for no analytical gain — enable it only if you want identify calls to be countable as a metric metadata flattening statsig's metadata is a flat key/value map nested values ( products\[] , address , …) are json stringified rather than dropped , so the data still reaches statsig and remains queryable as a string instead of silently disappearing primitives (string, number, boolean) pass through unchanged; null and undefined are omitted because metadata accepts arbitrary keys, any custom property mappings you configure in hub flow through automatically — there is no destination side schema to add them to email and pii the email handling setting controls where a user's email address goes mode behavior private (default) sent as user privateattributes email — usable for targeting, but never written to statsig's event log attribute sent as user email , which is logged omit never sent in private and omit mode, email is also stripped from metadata , so a value arriving via traits or properties cannot defeat the setting email handling covers email and nothing else every other trait and property is forwarded to metadata verbatim, and metadata is written to statsig's event log an identify event carrying phone , firstname , lastname or address sends those to statsig in plaintext, with no setting to suppress them this matters most for identify events, which carry a full trait set — one reason send identify events is off by default if a trait must not reach statsig, drop it upstream in a transformation function rather than relying on this destination to filter it environments the environment tier setting is sent as user statsigenvironment tier set it to staging or development on non production connections — otherwise staging traffic silently pollutes your production experiment metrics, which is painful to unwind after the fact retry behavior response behavior 202 accepted 429 , 5xx retried other 4xx not retried — a bad secret key or malformed payload cannot be fixed by sending the same request again transport failure retried