What is Allowed Origin Policy?
An explicit allowlist of origins permitted to send analytics events for a site, rejecting data from impostor domains. Origin policies keep client-side telemetry trustworthy when the collection endpoint is public.
Example
A BYOB project adds its production domain to the Fruitalytics origin allowlist so events from the live site are accepted while copycat domains posting to the same endpoint are dropped.
What people get wrong
Relying on obscurity of the tracking endpoint. Public client keys are copyable by design, so the allowlist — not secrecy — is the trust boundary.
Related terms
PII Redaction
Stripping emails, tokens, keys, and secrets from logged payloads before storage or display. Redaction belongs in the pipeline itself, since downstream dashboards and exports inherit whatever the collector kept.
First-Party Data
Behavioral and account data collected directly from your own product and site with user consent. It survives cookie deprecation and platform shifts, which is why owned telemetry beats rented audience segments.
Fruitalytics Verify
Batch analytics assertions: click a selector, require the events. Verification turns “we shipped tracking” into “tracking fires” — per release, automatically.
Autocapture
Automatic collection of clicks, pageviews, and form interactions without per-element instrumentation. Fast to start but noisy: retroactive data comes with vague names and mystery events that explicit tracking would have labeled.
Explicit Events
Hand-defined tracking calls placed at meaningful product moments: signup completed, checkout started, invite sent. Explicit events cost engineering time upfront and pay back in clean names and trustworthy funnels.
Event Taxonomy
The naming contract for analytics: object-action conventions, required properties, and ownership per event. Taxonomies prevent the analytics swamp where three teams log the same signup three different ways.