Skip to main content
The Tracking Pixel, Web SDK, Unity SDK, and REST API are currently in alpha. The data collected and event schemas may change between releases.
Full reference of data collected and event schemas for the Web SDK, Unity SDK, and REST API, and the data forwarded externally by Conversion Postbacks. Use it to understand what each integration sends, when it sends it, and what properties each event carries. Also useful for privacy reviews, legal assessments, and technical audits.

Cookies

First-party cookies only. No third-party cookies are created. The Unity SDK does not use cookies. It persists AnonymousId and queued events to native local storage instead.
Persistent anonymous device identifier (UUID v4). Shared between the Tracking Pixel and Web SDK.
Session continuity across page loads. Refreshed on each tracking call. Expires after 30 minutes of inactivity.
Google Analytics client ID. Read-only. The Tracking Pixel reads this cookie for cross-platform identity stitching but does not write it.
Facebook click ID. Read-only. The Tracking Pixel reads this cookie for cross-platform identity stitching but does not write it.
Facebook browser ID. Read-only. The Tracking Pixel reads this cookie for cross-platform identity stitching but does not write it.

Auto-Tracked

Signals collected and events fired by the integration without any studio code.

Device Fingerprint Signals

These signals are collected automatically when consent is anonymous or full. The Tracking Pixel and Web SDK collect the same browser-based set, so the per-integration tabs for those two repeat the same table.

Attribution Signals

The Tracking Pixel and Web SDK collect the same URL-based signals. Mobile Unity builds with attribution enabled collect a separate set of device-level signals. Desktop Unity builds collect none.
The Tracking Pixel collects these on every page load.

Auto-Tracked Events

Events fired by the integration without studio code. Title badges indicate which integrations emit each event. Trigger conditions and per-integration property differences are described inside the accordion.
Player launched the game. The Unity SDK fires this automatically at Init when consent permits tracking. The Web SDK and REST API do not currently emit this event.Event name: game_launchOn mobile with EnableMobileAttribution = true, additional attribution signals are included. See Attribution Signals for the full set.Postback forwarding: when Conversion Postbacks are configured for the game, attributed game_launch events are forwarded to the configured ad network as a registration/install signal. See Outbound Forwarding.Fired automatically by ImmutableAudience.Init. Studios do not call this directly. The wire payload includes the full Unity property set:
Fires when a new session begins. The Unity SDK fires it on Init, consent upgrade from None, or resume after a pause longer than 30 seconds. The Tracking Pixel and Web SDK do not emit this event; they attach a sessionId to every message instead (see Auto-attached metadata) and session boundaries are derived from that.
Fires when a session ends. Only fires when consent is at Anonymous or higher. The Unity SDK fires it when Shutdown is called, consent is downgraded to None, or a session rolls due to extended pause. The Tracking Pixel and Web SDK do not emit this event.
Fires every 60 seconds while the game is focused. Pause and resume reset the heartbeat clock, so wall-clock and reported engagement time can diverge.Used to estimate playtime per session for studios where players regularly leave the game backgrounded. The Web SDK and Tracking Pixel do not emit this event.
ATT authorization status changed from its previously recorded value. Does not fire on first launch. The initial state is reported by game_launch.Requires: EnableMobileAttribution = true, Anonymous or Full consent, iOS only.Event name: tracking_authorization_changed
Android Play Install Referrer captured. Fires once per install. On first launch the Play Services fetch is usually still in flight when game_launch fires, so the event typically arrives on the second launch.Requires: EnableMobileAttribution = true, Full consent, Android only.Event name: install_referrer_received
The Tracking Pixel fires this automatically on every page load. In the Web SDK, call page() manually on each route change.
Fires on HTML form submission. Can be disabled with autocapture.forms: false.
Fires when the user scrolls past a depth milestone (25%, 50%, 75%, 90%, 100%). Each milestone fires at most once per page load. On above-the-fold pages (all content visible without scrolling), fires depth: 100 with aboveFold: true after a 2-second dwell time to filter immediate bounces. Can be disabled with autocapture.scroll: false.

Identity Stitching

Each integration assigns an anonymousId automatically when tracking begins. As a player moves through your funnel (visiting your marketing site, creating an account, launching the game), identity calls connect those anonymous sessions to a known player in attribution reports. The Tracking Pixel and Web SDK share the imtbl_anon_id cookie on the same domain, so sessions on the same domain are already continuous before any login occurs. Call identify() at login to associate the player’s userId with their activity and traits. A player who logs in on both the marketing site and in-game using the same userId will have both session histories attributed to the same profile, no alias call needed. Call alias() when the same player is known by different provider IDs across surfaces, for example a player previously identified as a Steam user who later links a Passport account. For exact method signatures and the full list of IdentityType values, see the API Reference section of the Web SDK, Unity SDK, or REST API docs.

Predefined Events

Typed events for common player actions. These schemas apply to the Web SDK, the Unity SDK, and the REST API. Each event accordion below shows the typed call shape for every integration. Properties are identical across integrations unless noted. Each integration also auto-attaches its own metadata to every event. See Auto-attached metadata below.

Event schemas

Player created a new account.Event name: sign_up
Player signed in to an existing account.Event name: sign_in
Player completed a purchase.Event name: purchasePostback forwarding: when Conversion Postbacks are configured for the game, attributed purchase events (including value and currency) are forwarded to the configured ad network for ROAS optimisation. See Outbound Forwarding.Player buys a sword for $9.99:
Player started, completed, or failed a level or stage.Event name: progressionPlayer completed level 3 of the forest world with a score of 4500 in 2 minutes:
Player gained or spent an in-game resource.Event name: resourcePlayer spends 500 gold on a weapon:
Player unlocked an achievement.Event name: achievement_unlockedPlayer defeats 100 enemies and unlocks a mastery achievement:
Player added or removed a game from their wishlist.Event names: wishlist_add, wishlist_removewishlist_add:
wishlist_remove:
Captured a player’s email address (e.g. from a newsletter signup or waitlist form).Event name: email_acquired
Player viewed a game page.Event name: game_page_viewed
Player clicked a link. Fires automatically for outbound link clicks (external domains only) via auto-capture — disable with autocapture.clicks: false — or manually via track()/the REST API for links auto-capture can’t see (e.g. non-anchor elements, server-rendered redirects).Event name: link_clickedAuto-captured clicks also carry the session’s attribution signals (utm_*, click IDs, referrer, landing_page, referral_code, touchpoint_type).
Player reached a named milestone or achievement. Use for any named accomplishment that does not fit the start/complete/fail shape of progression. Covers both one-shot achievements (e.g. first_boss_defeated, tutorial_complete, 100_percent_completion) and recurring named milestones (e.g. character_<id>_level_<N>, prestige_tier_<N>, streak_day_<N>, pvp_rank_<tier>). Parameterise name for the recurring case so each instance is distinguishable in analytics.Event name: milestone_reachedPlayer defeats the first boss:
The Web SDK does not yet ship a typed equivalent. Studios on that surface can emit the same event by passing the event name directly.

Auto-attached metadata

The Web SDK and Unity SDK auto-attach a shared baseline to every event, including identify()/Identify() and alias()/Alias() calls:
  • A persistent anonymous device identifier (anonymousId)
  • The current session identifier (sessionId)
  • An integration tag identifying the SDK source
  • The library identifier and version
  • Locale, screen size, timezone, and user-agent string
The Web SDK additionally captures browser page context (current page URL, path, referrer, and title) on every event. The tabs below document only the integration-specific additions on top of that baseline. The backend additionally stamps received_at and IP-derived geo on every event regardless of integration.
Attribution is the session’s first-touch snapshot, captured at session start. A player who arrives via ?utm_source=discord, navigates to another page, then triggers sign_up still carries utm_source=discord on that event, and landing_page is included.
All Audience integrations use a three-tier consent model. Consent defaults to None and can be changed at any time. Changes take effect immediately. The Audience integrations do not provide a consent UI. You are responsible for building the cookie banner or privacy prompt and setting the consent level when the user makes a choice. Native games do not have a cookie banner. Studios typically gate the consent call on a first-launch privacy prompt or a settings menu. You can downgrade consent at any time. All integrations share this core behavior:
  • Full → Anonymous: strips player identity from queued events, removes pending identify() and alias() messages.
  • Any level → None: purges all queued events.
Clears the session cookie. The anonymous device cookie persists per its lifetime unless the user clears cookies in the browser.
The tables below show whether each data category is collected at each consent level.

Outbound Forwarding

Most data collected by Audience integrations stays within Immutable. The exception is when Conversion Postbacks are configured for a game: attributed game_launch and purchase events are forwarded server-to-server to the configured ad network (TikTok Ads, Reddit Ads). Forwarded payloads contain only the fields each ad network requires for conversion matching: Player names, raw emails, wallet addresses, device fingerprints, session details, and event properties beyond the table above are not forwarded. Only events from players at anonymous or full consent are eligible. Forwarding requires explicit per-game configuration in Audience Hub; no postbacks fire for games without an active configuration. See Conversion Postbacks for setup, supported networks, and delivery monitoring.

What Is Not Collected

None of the Audience integrations collect the following:
  • No cross-domain tracking (first-party cookies only)
  • No session replay or screen recording
  • No heatmaps or mouse movement tracking
  • No A/B testing or feature flags
  • No impression or view-through tracking (click-through only)
  • No raw email addresses (only SHA-256 hashed, only at full consent)
Additionally, the Tracking Pixel does not support custom event tracking. Use the Web SDK, Unity SDK, or REST API for that.

Next Steps

Attribution

How tracking data powers player attribution and Hub reports

Web SDK

Typed SDK for web games, marketing sites, and SPAs

Unity SDK

In-game tracking for Unity games on PC and mobile.

REST API

Send events from your backend or game server

Conversion Postbacks

Send attributed conversions back to ad networks to improve campaign optimisation