Adding session replay to your product should be one script tag, not a project. The AIOProductOS replay SDK gzips to a few kilobytes (the SDK family ranges 1.7–5.2 KB each), loads asynchronously so it never blocks render, and — the part that matters — ties each recording to the same customer record as that user’s events and revenue. You install it in your own product; replays land on a shared spine, not in a separate replay silo.
How do you add session replay in practice?
Three steps, and the first is the only one that touches your markup.
1. Drop in the script. Add the SDK to the pages you want to record. It loads with async, so it stays off the critical rendering path:
<script async src="https://platform.aioproductos.com/sdk/productos.js"
data-org="your-org-key" data-replay="on"></script>
<script>
// illustrative — identify the user so the replay ties to their record
productos.identify("user_8842", { plan: "team" });
</script>2. Identify the user. The identify call is what welds the recording to a customer. Without it you get anonymous sessions; with it, the replay resolves to the same record as that user’s subscription and tracked events.
3. Verify masking. By default, input fields are masked before anything leaves the browser. Confirm the masking covers your sensitive elements before you ship — more on that below.
That is the whole integration. The SDK records DOM mutations incrementally, buffers them, and uploads without blocking navigation. It runs on EU and US data residency, picked at onboarding.
How does a replay tie to the same user record?
This is the difference between replay-as-a-toy and replay-as-a-tool. A standalone replay product gives you a video library you scrub through by hand. Here, the recording lands on the same spine as everything else about that customer, keyed to one ID.
So the workflow inverts. Instead of watching sessions hoping to spot something, you start from a signal — a drop in tracked events, a churn risk, a support ticket — and jump straight to the sessions behind it. The replay is not a separate destination; it is one more layer on a record that already holds revenue, work, and events. See how the layers connect on the SDKs page.
What does session replay cost in performance?
Less than teams fear, in the right places, more than they expect in the wrong ones.
The script itself is a few kilobytes gzipped and loads async, so it does not touch LCP or first paint. The real cost is upload volume: a page with heavy animation or a large, constantly-mutating DOM produces a lot of mutation events. That is a bandwidth and battery concern on the user’s device, not a bundle concern. The fix is sampling — record a fraction of sessions, or only sessions that hit a condition you care about — rather than recording everything, everywhere, always.
When is session replay the wrong call?
When you cannot guarantee sensitive data stays out of frame. Replay works by capturing the rendered DOM, which means anything on screen can end up in the recording. For products handling health data, financial details, or regulated PII, that is a genuine leak risk, and “we meant to mask it” is not a defense after the fact.
Masking is the mitigation, and it has to be deliberate:
| Approach | What it does | When to use |
|---|---|---|
| Default input masking | Redacts form fields before upload | Baseline — always on |
| Element allow/block lists | Mask specific selectors (SSNs, tokens, PII) | Any regulated surface |
| Session sampling | Record only a fraction or condition | High-volume or sensitive flows |
| No replay | Use aggregate/event analytics instead | When masking can’t cover exposure |
If your masking rules cannot cover the exposure with confidence, do not use replay on those screens — lean on aggregate analytics or server-side event tracking, which never see the rendered PII in the first place. A dedicated enterprise replay suite with granular consent management and compliance certifications may also be the better fit for heavily regulated products; that is a real reason to reach past a drop-in SDK.
The short version
Session replay is one async script tag away, and it should weigh a few kilobytes, not slow your product down. What makes it useful is not the recording — it is that the recording ties to the same customer record as revenue and events, so you navigate from a signal to the session that explains it. Just mask deliberately, and skip it on screens where masking cannot cover the risk.
You can see connected records — events, revenue, and shipped work on one customer — in the live no-signup demo, no setup required.