context is optional environment metadata about where and how an event was produced. It is not identity (userId, traits) and not business event data (event, properties).
| Layer | Answers | Fields |
|---|---|---|
| Identity | Who? | userId, anonymousId, traits |
| Event | What happened? | event / name, properties |
| Context | On what device, app, page, or network? | device, os, app, ip, locale, … |
ip and/or library).
When to send it
- From SDKs: Usually leave it alone — the SDK attaches context on every call.
- From your backend: Include useful server-known fields such as
ip,library, and optionallyapp. - Optional: Events are accepted without
context. Richer context improves platform detection, segmentation, and debugging.
Example
Field reference
Top-level
| Field | Type | Description |
|---|---|---|
ip | string | Client IP address. Useful for geo when sending from a server. |
locale | string | Locale / language tag (for example en-US). |
timezone | string | IANA timezone (for example America/New_York). |
userAgent | string | Browser or client user-agent string. Helps infer web platform. |
library
Which SDK or integration produced the event.
| Field | Type | Description |
|---|---|---|
library.name | string | Library name (for example @zixflow/analytics-browser, @zixflow/analytics-node) |
library.version | string | Library version |
app
| Field | Type | Description |
|---|---|---|
app.name | string | Application name |
app.version | string | Marketing / semver version (for example 2.1.0) |
app.build | string | Build number (for example 403) |
device
| Field | Type | Description |
|---|---|---|
device.id | string | Device identifier when available |
device.manufacturer | string | Manufacturer (for example Apple) |
device.model | string | Model (for example iPhone 14 Pro) |
device.name | string | User-facing device name when available |
device.type | string | Platform hint: ios, android, or web |
os
| Field | Type | Description |
|---|---|---|
os.name | string | OS name (for example iOS, Android) |
os.version | string | OS version |
screen
Display metrics (typically from mobile / browser SDKs).
| Field | Type | Description |
|---|---|---|
screen.width | number | Width in pixels |
screen.height | number | Height in pixels |
screen.density | number | Pixel density |
page
Mostly used by the browser SDK for page views and tracks.
| Field | Type | Description |
|---|---|---|
page.path | string | URL path |
page.url | string | Full URL |
page.referrer | string | Referrer URL |
page.title | string | Document title |
campaign
UTM / campaign attribution (typically browser).
| Field | Type | Description |
|---|---|---|
campaign.source | string | utm_source |
campaign.medium | string | utm_medium |
campaign.name | string | utm_campaign |
campaign.term | string | utm_term |
campaign.content | string | utm_content |
How Zixflow uses context
Platform detection (devices / push) prefers, in order:context.device.type(ios/android/web)context.os.namecontext.library.name(browser libraries →web)- Presence of
userAgent→web
Server-side example
Minimal context from a backend track call:What not to put in context
- Business event details → use
properties(track / screen / page) - Durable user profile fields → use identify
traits - Required identity → use
userIdand/oranonymousId
Applies to
context can be sent on: