Auto-captured Events

When remote-config tags or snippets fail, the SDK also reports $tag_error, $snippet_error, and $snippet_compilation_error; a failing event transformer reports $transformer_error.

$experiment_viewed fires once per session per assignment, so it counts sessions exposed to a variation — not pageviews. To split other events by variation, filter on the $experiments super property that every event carries once the assignment is known: "<experimentId>:<variationId>" for Convert.com, "posthog:<flagKey>:<variant>" for PostHog, "mida:<testId>:<variant name>" for Mida. For PostHog, only experiment-linked and multivariate flags appear — boolean feature flags are rollouts, not tests.

Count exposures with first_exposure: true. A testing tool keeps its assignment for months (Convert: ~6), so a visitor bucketed on a landing page carries that variation into later visits — and $experiment_viewed fires again in each new session, sometimes on pages the test never touched. first_exposure: false marks those: correct for attributing later behaviour to the variation, wrong as an exposure count. A sighting that arrives with a variation name but no id yet (the tool announced itself before writing its cookie) is held briefly and completed from the cookie; detected_via: held_then_enriched marks those, and <source>_unresolved marks one that never completed.

Alongside the event, the SDK stores the A/B assignment on the person profile: $convert_visitor_id + $convert_experiments for Convert.com, $posthog_distinct_id + $posthog_experiments for PostHog, $mida_visitor_id + $mida_experiments for Mida. $experiments is a super property, so it only rides events sent from the browser — a conversion that arrives server-side (a CRM close, a subscription rebill) carries no super properties at all. The person copy is what lets a later off-browser conversion still be credited to the variation, and it is what the convert_experiments and mida_experiments destinations read. Both are erased with the rest of a person's data on a deletion request, and neither is written for HIPAA-enabled locations, where experiment capture is off entirely.

form_submitted never includes password or hidden inputs, and fields whose names look sensitive (SSN, credit card, CVV, API token, etc.) are redacted before the event is sent. A single user submit produces exactly one form_submitted event.

$obref is read from OpenAI's cookie the same way $ga_client_id is read from Google's, and for the same reason: it is their browser identifier, not ours. Their __oppref cookie is deliberately not read back — oppref is a click id, and a cookie that outlives the click would mark 30 days of direct traffic as paid ChatGPT traffic. A conversion that happens later gets its oppref from the person's stored attribution server-side instead.

$ga_client_id is read, never written. Google Analytics owns the _ga cookie, and minting our own value would fork the identity and make GA4 count one visitor twice — so if GA is not on the page, the property is simply absent. It is the join key for the google_analytics destination: without it, a server-side GA4 event is attributed to a brand-new user rather than the session that earned it. Not on the HIPAA allowlist, so it is stripped for HIPAA-enabled locations.

$fbc and $fbp follow Meta's Conversions API formats — fb.<subdomainIndex>.<creationTime>.<clickId> and fb.<subdomainIndex>.<creationTime>.<random> — and are persisted for 90 days, with the window rolling forward on each page load. If Meta's pixel already set _fbc/_fbp on the domain, those values are reused rather than regenerated, so the SDK and the pixel report the same browser ID. Once captured, $fbc keeps its original creation time until a different fbclid arrives, which is what lets Meta dedupe browser and server events for the same click. $fbclid itself stays URL-scoped: it is not backfilled from a stored $fbc. Meta treats a click as expired 90 days after the fbc creation time, so a stored $fbc older than that is dropped instead of being carried forward.