Skip to content

Seen Player tracking explainer ​

Summary ​

  • The player sets no cookies.
  • Events carry no names or contact details. They carry only IDs (e.g., datapointId, playerId) and player metadata.
  • A sessionId is derived on our servers from the request IP using a keyed hash. The key changes every day and is then deleted. The sessionId is used only to count distinct sessions per referrer source.
  • Events are sent from the player in the browser to Seen's metrics collection service and stored in Seen's analytics datastore.
  • Events are linked to a recipient only when you export per-recipient metrics, your systems call the Seen API, or you enable the External Events webhook.

What gets tracked (events) ​

The Seen web player emits a small set of product events:

  • player-opened
  • video-played
  • video-playing (heartbeat/position)
  • video-watched (completion)
  • cta-clicked
  • share-clicked

These are first-party events used to measure player delivery, engagement and CTA performance for a given personalised video.

Related article: Dashboard documentation

Payload structure ​

Events are sent over HTTPS from the browser to Seen's metrics collection service.

Fields:

  • id – Unique UUID for the event
  • type – Event type (e.g., "com.seen.player.player.opened")
  • source – Current page URL
  • time – ISO 8601 timestamp

data object (client-supplied)

  • playerId – The ID of the player instance (ties events to the rendered datapoint/video)
  • deviceType – (optional) Client-detected device category

Example payload (as received by the service) ​

json
{
  "id": "69e78f39-2adb-4f09-a2f0-9b596ac5e001",
  "specversion": "1.0",
  "type": "com.seen.player.player.opened",
  "source": "https://player.seen.io/F30uWMk7Xk5eT6Ezftxo",
  "time": "2025-10-16T13:11:53.868Z",
  "data": {
    "playerId": "F30uWMk7Xk5eT6Ezftxo",
    "deviceType": "desktop"
  }
}

On ingest, Seen adds the sessionId and processing metadata. No cookies are used.

Data model (stored fields) ​

FieldWhat it isSource
typeEvent type stringClient
sourcePage URL of the playerClient
idEvent UUIDClient
timeEvent timestamp (ISO)Client
playerIdPlayer instance identifierClient
datapointIdThe data row the video was made forServer enrichment
motionIdThe rendered videoServer enrichment
journeyIdThe Journey that produced the videoServer enrichment
workspaceIdYour WorkspaceServer enrichment
sessionIdKeyed hash of the request IP and Workspace, with a key that is deleted daily. Used only to count distinct sessions per referrer sourceServer enrichment
deviceTypeDevice category (e.g., mobile/desktop)Client (optional)
playerModePlayer modeClient (optional)

What's not stored: Seen's player analytics does not process or retain any directly identifiable information (such as names, email addresses, phone numbers, or other user contact details). Metrics data is limited to pseudonymous technical identifiers required for service performance and analytics.

Linking events to recipients ​

  • Every event carries the internal ID of the data row the video was made for (datapointId) and its playerId. It carries no name or contact details.
  • That ID points to a person only when it is matched with your own data. This happens in three cases, each on your instruction:
    • Export: a per-recipient export from your Workspace adds counts such as plays and CTA clicks to each row of your data.
    • API: your systems request per-recipient data through the Seen API.
    • External Events webhook: if you enable External Events, each event is sent to your endpoint with its Player ID and Player link, plus any Workspace properties you add to the payload, such as a customer ID.
  • Seen does not link events to recipients for any purpose of its own.

Sessions and unique counts ​

  • Unique opens, plays, watches, CTA clicks and shares are counted per video link. No IP address is involved.
  • Returning visits are counted per video link as well: the first open of a link is a new visit, and every later open of the same link is a returning visit.
  • The sessionId is used for one measure only: distinct sessions per referrer source, such as email or LinkedIn.
  • The sessionId is a keyed hash of the IP address and your Workspace. The key changes every day and the previous key is deleted, so a sessionId cannot be linked to an IP address after that day, by Seen or anyone else. It also differs between Workspaces and between days, so a viewer cannot be followed across customers or over time.
  • The raw IP address is not stored in the analytics data.

Cookies and browser storage ​

  • The player sets no cookies and does not use session storage or IndexedDB.
  • It saves the viewer's own volume, mute and subtitle language in local storage when the viewer changes them (media-chrome-pref-volume, media-chrome-pref-muted, media-chrome-pref-subtitles-lang). These contain no identifier, are not used for analytics, and stay until the viewer clears their browser data.
  • The player uses no third-party analytics, pixels, advertising tags or fingerprinting, and loads scripts, styles and fonts only from Seen's servers.

Server logs ​

Our hosting provider records the IP address and request URL of every request in standard web request logs. These are kept for 30 days in the EU for security and troubleshooting, then deleted. Access is restricted to authorised Seen personnel.

Transport & visibility ​

  • Events are sent from the browser to Seen's metrics collection endpoint over HTTPS.
  • Because the calls originate from the page, they're visible in the browser network panel (transparent first-party tracking).
  • Seen validates and rate-limits on ingest and enriches the record before storage.

Security of Player IDs ​

  • Each video delivered through the Seen player has a globally unique 21-character Base62 identifier (~125 bits of entropy). This makes IDs effectively unguessable by brute force.
  • Seen also enforces rate-limiting and monitoring on the player domain to detect and block automated or sequential access attempts. These measures ensure that player links cannot realistically be discovered or enumerated by third parties.
  • Role: Seen acts as your processor for player metrics. You (the customer) are the controller. See:
    • Terms & Conditions, Data Processing Agreement (DPA), and Privacy Policy at trust.seen.io
    • Certifications and security posture at trust.seen.io (Seen is ISO/IEC 27001 and 27701 certified)
  • Lawful basis: You are the controller and decide the lawful basis. Events are sent from the viewer's browser, so check whether your local ePrivacy rules require consent. Your basis should be reflected in your own privacy notice.
  • Cookies: Not used. The player sets no cookies, does not fingerprint, and uses no third-party advertising or analytics IDs.
  • Personal data: While engagement data is linked to a recipient identifier, it is pseudonymised personal data. The raw IP address is not stored in the analytics data, and the sessionId cannot be linked to an IP address once its daily key is deleted. See Server logs.
  • Data minimisation: Metrics tables store only technical and campaign IDs required for measurement and troubleshooting.
  • Data subject rights: Requests are fulfilled against the recipient's data row in your Workspace. Deleting the row removes the recipient's details and removes its events from your reporting. If you export per-recipient data, those exports are in scope for requests under your control.
  • Retention and deletion: At the end of the retention period, the video is deleted and the personalisation values on the data row are removed. The row keeps only the recipient identifier you supplied, so the row's events stay in your totals and remain linked to that identifier. This engagement data is Client Data, processed under the Data Processing Agreement for the term of your agreement. When your agreement ends, the link to your recipient identifier is removed and what remains is anonymous. If you delete a data row yourself, its events are removed from your reporting.

FAQ ​

Do we need a cookie banner for Seen player analytics?

The player sets no cookies, so no cookie banner is needed for it. Your local ePrivacy rules may still require consent for sending engagement events, so confirm with your counsel.

Can we disable tracking?

Append ?preview=true to any player URL to open it in preview mode, for example:

https://player.seen.io/v/AhdlZ6Qq28LDQAptGHUY?preview=true

In this mode, no engagement or analytics events are sent to Seen's metrics service.

Can we see everything Seen collects?

Yes: events are visible in your browser developer tools while testing, and you can export aggregated or row-level engagement from your workspace or via API.

How are recipients identified?

Through your own data row, by export, API or the External Events webhook. See Linking events to recipients.