Data Processed — Userplay

This document describes the categories of data Userplay processes, the source of each category, the purpose it serves, and how long it is retained. It is the canonical reference for Subprocessors, the Privacy Policy, and the Data Processing Addendum.

All data is processed in the United States.

Account and Workspace Data#

Source — studio members at sign-up and through workspace configuration.
Includes — name, work email, hashed password (when password auth is used), workspace name, billing details, role assignments, workspace settings, and integrations.
Purpose — provide authenticated access, bill customers, enforce role-based access, surface workspace-scoped configuration.
Retention — maintained for the lifetime of the workspace; deleted within 30 days of confirmed account closure, except where retention is required by law (for example, financial records).

Steam Integration#

Source — a studio member connecting Steam in workspace settings, and the players who link their Steam account.
Includes — the studio’s Steamworks publisher Web API key, stored encrypted (AES-256-GCM), with only the last four characters shown in the UI; the App IDs the studio tracks. For a linked player: their Steam ID, persona name, and avatar, and per-title ownership, playtime, and wishlist state for the studio’s tracked titles.
Purpose — confirm a player owns or has played a studio’s title, and surface playtime and wishlist coverage to match players to playtests. The publisher key is used only to query the studio’s own titles.
Retention — the encrypted publisher key is kept until the studio disconnects Steam or rotates the key. Per-player Steam ownership and playtime data are refreshed while Steam stays linked and deleted when the player disconnects Steam.

Discord Integration#

Source — a studio member connecting a Discord server through OAuth, and the players who link their Discord account.
Includes — the connected server’s Discord ID with its cached name and icon, and which studio member connected it; studio-authored announcements (title, subtitle, body, cover image) posted to that server for a published playtest, key vault, or player group. For a linked player: their Discord ID, username, and avatar.
Purpose — let a studio announce playtests and distributions to its own Discord community, and let players sign in with Discord.
Retention — kept until the studio disconnects the server or removes the announcement. A player’s linked Discord identity is deleted when the player disconnects it or closes their account.

Player Account and Profile#

Source — players at sign-up and through the player application; the Steam library sync when the player links Steam.
Includes — email and sign-in identity (Google, Steam, Discord, passkey, password, or magic link); player profile (age range, gender, country, player type, genre and platform preferences); when Steam is linked, the games the player owns and wishlists on Steam, with playtime.
Purpose — provide the player application and portal, and match players to relevant playtests. A studio can see a player’s playtime for that studio’s own titles. Userplay is the controller of this data.
Retention — maintained for the lifetime of the player account. The synced Steam library is deleted when the player disconnects Steam; everything else is deleted within 30 days of confirmed account closure.

Player Groups#

Source — studio members organizing players, and players who join through a group’s public link.
Includes — a group name and description, a rotatable public join identifier, and the list of member players with the time each was invited or joined. Every playtest also has a system group that holds its invite roster.
Purpose — let a studio build reusable rosters of players and invite them to playtests.
Retention — kept until the studio deletes the group or the parent workspace. Removing a player from a group deletes that membership record.

Key Vaults and Key Redemption#

Source — studio members adding keys to a vault, and players redeeming them.
Includes — named vaults of distributable keys or credentials (for example, Steam keys), and for each key its value, the player it is assigned to, and the times it was assigned and redeemed. A vault can be tied to one playtest or reused across playtests.
Purpose — distribute build keys or credentials to eligible players and record who redeemed what.
Retention — kept until the studio deletes the vault or the parent workspace.

Playtest Configuration#

Source — studio members when designing a playtest.
Includes — playtest title, description, objectives, prompts shown to players, capture toggles (screen, microphone), player invite list, expiry date.
Purpose — define what players see, what is captured, and how outputs are processed.
Retention — persists for the lifetime of the playtest. Deleted when the parent workspace or playtest is deleted.

Session Recordings (Screen and Audio)#

Source — player clients during a playtest session. Recordings are captured locally and uploaded to Mux.
Includes — screen video, microphone audio and system audio (when the player consents), basic device and locale metadata (OS, browser, resolution, language, timezone). No webcam video is captured.
Purpose — allow studios to review what players did during a session.
Retention — default 12 months from session completion. Workspace owners can configure shorter retention. Soft-deleted recordings are purged from Mux storage within 30 days.

Screening Responses#

Source — players answering a studio’s screening questions before joining a playtest, joining a player group, or redeeming from a key vault.
Includes — one submission per player email and owner, holding the player’s answers and the eligibility verdict. Submissions are kept even when a player is found ineligible.
Purpose — let studios qualify players against their own criteria before granting access.
Retention — kept for the lifetime of the parent playtest, group, or vault; deleted when it is deleted.

Source — players accepting a playtest’s consent and any non-disclosure terms before a session.
Includes — the player email, the time of acceptance, a frozen snapshot and hash of exactly what was agreed (the briefing shown and the checkboxes ticked), and the IP address and user agent captured as proof of informed consent.
Purpose — hold a durable, verifiable record that a player agreed to the terms shown.
Retention — retained as a compliance record for the lifetime of the parent playtest; deleted when the playtest is deleted.

Survey and Participation Responses#

Source — players completing surveys and play-throughs during a playtest.
Includes — normalized survey answers (single choice, multiple choice, rating, and free-text responses), and per-player participation records such as sessions completed and status.
Purpose — capture structured feedback and track a player’s progress through a playtest.
Retention — tied to the parent playtest; deleted when the playtest is deleted.

In-Game Telemetry#

Source — an optional Userplay telemetry agent, when both the studio and the player opt in. Captures occur after gameplay ends and run locally in the player’s browser. Credential and token patterns are excluded before submission.
Includes — in-game events the game itself emits, page-level metadata for playtest pages only.
Purpose — give studios additional context beyond screen and audio.
Retention — stored alongside the parent recording; follows the same retention schedule.

Support Communications#

Source — customers and players when contacting support.
Includes — email content, support ticket metadata, attached files when included.
Purpose — provide customer support, troubleshoot issues, improve documentation.
Retention — retained while the support relationship is active, then deleted within 24 months of last contact.

Web Analytics and Product Telemetry#

Source — the Userplay web application and marketing site, via Vercel and Cloudflare logs and our product analytics layer (PostHog).
Includes — pseudonymous page views, feature usage events, performance metrics, error reports, and masked session replays of the web application interface (inputs and text masked).
Purpose — operate the service, understand product usage in aggregate, fix bugs.
Retention — aggregated metrics retained indefinitely; raw event records retained for 90 days.

Out of Scope#

Userplay does not collect, process, or sell:

Player credentials, authentication tokens, cookies, or session secrets from games being tested.
Live in-game telemetry during active gameplay — telemetry agents activate only post-gameplay.
Children’s data — Userplay is not intended for users under the age of majority in their jurisdiction. See Use Restrictions.
Personal data unrelated to operating the service.