Seen Player tracking explainer

Summary

• No cookies are used for player analytics.
• No PII is stored in the metrics store. Events carry only IDs (e.g., datapointId, playerId) and player metadata.
• Session is derived server-side from the user's IP using a one-way hash and saved as sessionId.
• Events are sent from the player in the browser to Seen's metrics collection service and stored in Seen's analytics datastore.
• Linking events to an identifiable receiver only happens at export (or via authorized API) inside your workspace.

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)

{
  "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 enriches each event with non-personal metadata necessary for service performance and reporting. No cookies are created, read, or stored.

Data model (stored fields)

Field	What it is	Source
type	Event type string	Client
source	Page URL of the player	Client
id	Event UUID	Client
time	Event timestamp (ISO)	Client
playerId	Player instance identifier	Client
sessionId	Hashed IP used to group events into a session	Server enrichment
deviceType	Device category (e.g., mobile/desktop)	Client (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.

Identity, joining & exports

• Metrics rows are pseudonymous and keyed by IDs.
• If you export engagement per receiver, the join to your receiver record is done inside your workspace at export time (or via authorized API) through datapointId/playerId.
• Outside of your workspace (e.g., at the transport/storage layer) the events remain de-identified.

Sessions (no cookies)

• Seen does not set cookies for analytics.
• Uniqueness is determined server-side by deriving a sessionId from the request IP using a one-way cryptographic hash.
• This lets you count opens/plays and deduplicate events without storing the raw IP or using browser storage.

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.

Privacy & compliance notes (for legal teams)

• 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: Because metrics contain pseudonymous data (hashed IP and IDs), most customers rely on legitimate interests for essential delivery/analytics of the personalised video, or obtain consent where their local ePrivacy rules require it. Your basis should be reflected in your own privacy notice.
• Cookies: Not used. The player does not read or write cookies for analytics, nor does it fingerprint or use third-party ad/analytics IDs.
• Personal data: IP addresses are processed transiently server-side to derive sessionId. The stored value is a one-way hash; raw IPs are not stored in the metrics tables.
• Data minimisation: Metrics tables store only technical and campaign IDs required for measurement and troubleshooting.
• Data subject rights: Because metrics rows are de-identified, access/erasure requests are typically fulfilled in relation to the receiver data in your workspace. If you export per-receiver logs, those exports become in scope for data subject requests under your control.
• Retention & deletion: Player analytics are pseudonymous and stored separately from any PII. They may be retained beyond project data for legitimate operational and reporting purposes, in accordance with Seen's DPA and internal retention schedule.

FAQ

Do we need a cookie banner for Seen player analytics?

Not for Seen's player analytics, because no cookies are used. Your local ePrivacy rules might still require consent for any tracking, even pseudonymous, 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 receivers identified in exports?

Exports link events to the receiver through your own datapoint metadata inside your workspace. The underlying metrics store itself does not contain PII.