Glossary
Terms & definitions
Plain-English definitions of the concepts behind server-side tagging, first-party data collection, identity resolution, and vendor APIs. Bookmark this page or link to specific terms.
- Ad blocker
- Browser extension or network-level tool that blocks requests to known advertising and analytics domains. Typically removes 20-40% of conversions from vendor pixel-based tracking. First-party server-side tagging bypasses ad blockers because there is no third-party domain to block.
- Anonymous ID
- A randomly generated identifier that ties events to a single visitor without revealing their identity. Datafly Signal stores it in the `_dfid` first-party cookie, set server-side from your own domain so Safari’s 7-day cookie limit does not apply. Learn more →
- Attribution window
- The length of time a user’s action (e.g. an ad click) is credited with a resulting conversion. Client-side tracking is limited by how long its cookies survive, and Safari deletes JavaScript cookies after 7 days if the visitor doesn’t come back. Datafly Signal keeps the visitor’s identity in a server-set first-party cookie for up to 400 days and stores their click IDs server-side, so conversions inside a longer window can still be matched to the click. Learn more →
- CAPI (Conversions API)
- Meta’s server-to-server API for sending conversion events directly from your server to Meta’s ad platform, independent of the browser-based Meta Pixel. Solves ad-blocker and iOS privacy restrictions. Learn more →
- CDP (Customer Data Platform)
- A system that unifies customer data from multiple sources into persistent profiles and activates those profiles to downstream tools. Datafly Signal feeds CDPs cleaner, complete data rather than competing with them. Learn more →
- CNAME cloaking
- The practice of using a customer subdomain (e.g. data.example.com) as a CNAME to a vendor’s tracking endpoint, making the request appear first-party. Once widely used to get around ITP; Safari now limits cookies set this way to 7 days. Not the same as genuine first-party server-side tagging.
- Consent Mode v2
- Google’s framework for signalling consent state to Google’s ad and analytics products via four flags: `ad_storage`, `analytics_storage`, `ad_user_data`, `ad_personalization`. Datafly Signal supports Consent Mode v2 by enforcing consent both client-side and server-side before each event.
- Customer-hosted
- A deployment model where the platform runs inside the customer’s own cloud account, not the vendor’s. Datafly Signal’s primary model: you run it in your VPC on AWS, GCP, or Azure, and Datafly never processes your data. Learn more →
- Device recognition
- Probabilistic re-identification of a visitor using server-side signals (network characteristics, request metadata) after their cookies have been cleared. Datafly Signal uses hashed signals stored in the `_dfdid` cookie, configurable per-pipeline with high/medium/low confidence thresholds. Learn more →
- EMQ (Event Match Quality)
- Meta’s score (0-10) for how well the identity parameters on a CAPI event can be matched to a known Meta user. Higher EMQ means better ad optimisation. Achieved by sending more hashed identity signals: email, phone, `_fbp`, `_fbc`, `em`, `ph`, `external_id`, IP, and user agent.
- Enhanced Conversions
- Google Ads feature that enriches standard conversion events with hashed first-party customer data (email, phone) for improved campaign optimisation. Datafly Signal supports Enhanced Conversions for Web and Enhanced Conversions for Leads. Learn more →
- fbp / fbc
- Meta’s browser-side cookie identifiers. `_fbp` is a persistent browser ID (up to 400 days when server-set from your own domain). `_fbc` captures the `fbclid` click ID from a Meta ad URL for attribution. Datafly Signal generates `fbp` server-side and builds `fbc` from a captured `fbclid`, storing both against the visitor’s identity rather than setting Meta’s cookies.
- gclid / fbclid / ttclid / li_fat_id
- Vendor-specific click-ID URL parameters that identify an ad click (Google, Meta, TikTok, LinkedIn respectively). Captured by Datafly Signal’s collector on page load, stored server-side, and attached to subsequent events for attribution.
- Ingestion Gateway
- The HTTP endpoint that receives events from Datafly.js in the browser. Sets first-party cookies (`_dfid`, `_dfdid`), enforces rate limits and body-size limits, validates event signatures, and publishes to Kafka. Learn more →
- ITP (Intelligent Tracking Prevention)
- Safari’s built-in tracking protection. Safari deletes JavaScript cookies after 7 days if the visitor doesn’t come back, and after just 24 hours when they arrive from an ad click. Cookies set by a server with a `Set-Cookie` header avoid this and can last up to 400 days, as long as that server sits on your website’s own domain and network, not a CNAME to another company. ITP also blocks third-party cookies and restricts known tracker domains.
- Kafka
- The distributed event-streaming platform Datafly Signal uses between the Ingestion Gateway, Event Processor, and Delivery Workers. Provides ordered, durable event flow with at-least-once delivery semantics.
- Measurement Protocol
- Google’s server-side API for sending events directly to Google Analytics 4. Replaces client-side `gtag.js` calls with server-to-server HTTP requests, improving data completeness and bypassing ad blockers. Learn more →
- OIDC (OpenID Connect)
- An identity-layer protocol on top of OAuth 2.0. Datafly Signal uses the OIDC authorization-code flow with PKCE for cross-domain identity propagation between customer sites. Learn more →
- Pipeline
- A Datafly Signal configuration that maps incoming events to one or more outbound destinations with per-field transformations, enrichments, PII handling, and consent rules. Stored as YAML in PostgreSQL; versioned and auditable.
- PKCE (Proof Key for Code Exchange)
- A security extension to OAuth 2.0 / OIDC authorization-code flows that binds each authorization request to a dynamically generated secret. Datafly Signal uses PKCE on every cross-domain identity exchange.
- Server-side tagging
- The practice of collecting events in the browser via a first-party collector, then forwarding them from your own server to vendor APIs server-to-server, instead of running each vendor’s tag in the browser. Learn more →
- Single-tenant
- A deployment architecture where each customer runs its own isolated instance of the platform with its own database, Kafka cluster, and Redis cache. Datafly Signal is single-tenant by design: one Kubernetes namespace per customer. Learn more →
- VPC (Virtual Private Cloud)
- A logically isolated network within a public cloud (AWS, GCP, Azure) under the customer’s control. Datafly Signal’s primary deployment model runs entirely inside the customer’s VPC — Datafly has no access to the data plane. Learn more →