---
url: https://docs.seen.io/platform/player/tracking-explainer.md
description: >-
  Explains how the Seen video player tracks engagement without cookies or PII,
  and how events are collected, stored, and linked to receivers on export.
---

# 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.

::: info
Related article: [Dashboard documentation](../dashboard)
:::

## 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 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](http://trust.seen.io)
  * Certifications and security posture at [trust.seen.io](http://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.