Data Handling

Percus supports two personalization models. They have materially different data-handling properties, and which one a client uses determines whether personalization data reaches Percus infrastructure at all. This page describes both.

The two models

	Client-side personalization	Percus-hosted render data
Where the data lives	The host page only	Percus infrastructure (DynamoDB)
How it reaches the player	postMessage from the host page to the player iframe	Uploaded in advance, delivered at view time
Percus stores personalization values	No	Yes
Typical use	The client's own system already renders the page and holds the data	Batch campaigns where the video link is sent by email and there is no host system at view time

Neither model is more correct than the other. Client-side personalization keeps personalization values out of Percus entirely; hosted render data is what makes a plain email link work without the client operating a runtime system.

Model 1 — Client-side personalization

Client system                          Percus infrastructure
─────────────────────────────────────  ────────────────────────────────────
Host page (customer website)           Campaign Service
  └── percus-embed-sdk                   └── Template files (S3)
        └── postMessage PERCUS/INIT            └── served to iframe
              └── data: { name, balance }
                        ↑
                 Stays in memory only.
                 Never sent to Percus.

In this model:

• Personalization data passes directly from the host page to the player iframe.
• The player holds it in memory only for the binding phase.
• It is never written to localStorage, sessionStorage, logs, or any network request.
• Error payloads are sanitized so no data values appear in PERCUS/ERROR.
• After binding, the data object is no longer referenced.

There is a second form of this model: instead of passing the data inline, the snippet can name your own endpoint (data-pc-data-url), which the player fetches at view time. The data travels from your endpoint to the recipient's browser and is held in memory for the binding phase, exactly as above — it does not pass through Percus infrastructure. See the Snippet reference.

For this model, in either form, a breach of Percus infrastructure does not expose personalization values, because they were never sent there.

Model 2 — Percus-hosted render data

Batch campaigns need the personalized video to work from a plain link in an email, where there is no host system to supply data at view time. For that, the client uploads personalization data in advance and Percus stores it.

Upload (backoffice)                    Delivery (recipient opens the link)
─────────────────────────────────      ────────────────────────────────────
CSV, one object per viewer token       snippet + data-pc-viewer-token
        │                                        │
        ▼                                        ▼
Render Data API ─► presigned PUT ─► S3    viewer-session token minted
                                 │              │
                          S3 event            GET /v1/render-data
                                 ▼              │
                          worker Lambda ─► DynamoDB ◄─┘
                                          merged into the player at view time

In this model, Percus does store the personalization values the client uploads. Two properties limit the exposure:

• The viewer token is chosen by the client and is opaque to Percus. Percus stores the personalization object keyed by that token; it does not hold the mapping between a token and a real identity unless the client puts identifying values inside the object itself.
• Access requires a short-lived session token, minted per view against the channel and its API key. The stored data is not readable by holding the link alone.

Clients who need personalization values to stay out of Percus entirely should use Model 1.

What Percus stores

Data	Where	Notes
User accounts	Identity Service (PostgreSQL)	Email, name, role assignments — from SSO login
Organization metadata	Identity Service	Name, settings
Projects and templates	Campaign Service (PostgreSQL)	Names, descriptions, template files
Template assets	S3	Animation files, images, video — encrypted at rest
Per-viewer render data	Render Data Service (DynamoDB)	Only when the client uses Model 2. Personalization objects keyed by a client-chosen opaque token
Share personalization	Campaign Service (PostgreSQL)	Only for shared video links that carry their own personalization
API credentials	Campaign Service	API key stored in plaintext; API secret stored as a one-way hash
Audit events	Campaign Service	Who performed what action and when
Analytics events	Analytics Service	Playback and interaction events — see the Analytics documentation for the identity model

Retention and deletion

Render data is bound to the project that owns it. When a project is archived, a retention process removes the associated per-viewer data. Clients who need a specific retention period or a documented deletion process should raise it during onboarding, as it forms part of the contractual arrangement rather than a platform default.

Template files

Template files (Lottie JSON, manifests, video files) uploaded by motion designers are stored in S3 with server-side encryption. They contain animation structure and binding definitions — not customer data.

API secrets

When an API credential is created, the secret is returned once and is not stored in recoverable form. Percus stores only a one-way hash. If a secret is lost it must be rotated; it cannot be retrieved.

Data residency

Percus infrastructure runs on AWS. The specific region is determined at deployment time by the Percus team and communicated to clients during onboarding.