---
title: "How to Record a Demo Without Exposing Customer Data"
canonical: https://supportpages.io/guides/record-a-demo-without-exposing-customer-data
updated: 2026-08-13
---

You will finish with a recording setup where real customer data is never on screen in the first place, plus a review pass for the places video leaks that screenshots do not - autocomplete dropdowns, notification banners, and the single frame between two screens.

## Before you start

Seed a demo account with fictional data you would be content to publish: plausible names, realistic volumes, sensible dates. Empty accounts show empty states that teach nothing, and "Test User 1" tells the viewer nobody took the video seriously.

Create a dedicated browser profile for recording, or a separate operating system user account. A profile you use for work carries bookmarks, saved passwords, extension badges, form history and a signed-in avatar, and every one of those has appeared in somebody's published demo.

## Steps

1. **Record from the demo account, never from production.**
   Everything below is damage limitation for a recording that should not have contained real data. This step removes the risk rather than managing it.

2. **Turn on system-wide do-not-disturb before opening the recorder.**
   Notification banners arrive during the take you keep, they contain message previews with real names, and they appear for two seconds in the middle of an otherwise perfect segment.

3. **Clear form history and disable autofill in the recording profile.**
   Clicking into a search field and having three real customer names drop down is the most common way a demo leaks, because nothing about it looks like a mistake while you are recording.

4. **Record a window region, not the whole screen.**
   The desktop, the dock, the menu bar, a second monitor and any other application are all outside the frame if you set the capture region to the browser window and leave it there.

5. **Audit the browser chrome before the first take.**
   Tab titles from other sessions, the bookmarks bar, extension icons with unread counts, and the URL bar. URLs are the one most people miss: a path containing an account ID identifies a customer to anybody with access to your admin tools.

6. **Walk the flow once and note where real data could surface.**
   Search results, autocomplete, tooltips, chart hover states, email preview panes, exported filenames and error messages containing identifiers. Write the list down and check those moments specifically in review.

7. **Review the finished recording frame by frame at those moments.**
   Scrub at quarter speed or step through frames. Playing it back at normal speed reliably misses a single-frame flash, which is long enough to pause on and read.

8. **If something did get recorded, re-record rather than blur it.**
   Blur tracking drifts when the content moves, video compression can leave a readable frame at the cut point, and a redaction applied over a scrolling table only covers what it was tracking. Re-recording a segment is faster than defending a blur.

9. **Check the exported filename and metadata.**
   Recorders name files after the window title, which is often the account name, and some write the device and user into the file's metadata.

10. **Publish it unlisted and have someone else watch it first.**
    You know what you intended to keep off screen, which makes you the worst available reviewer of whether you did.

## Common mistakes

**Relying on blur in video.** Blur is applied to a moving target across hundreds of frames, and it only has to fail on one of them. Treat it as a last resort on a recording you cannot re-take.

**Recording the whole desktop "to save time".** The saving is thirty seconds; the cost is a Slack preview, a calendar title, and a folder of client names in the dock.

**Forgetting the account switcher.** Product headers show the logged-in user, the organisation name and often a list of other accounts the session can reach. It is on screen for the entire video.

**Editing after publishing.** Re-uploading a corrected version does not recall the downloads, the caches or the embed somebody already shared. Review before the file is public, not after.

**Using a production account "because the demo data looks fake".** Every demo account looks fake until you seed it properly, and seeding it properly is one afternoon against an open-ended risk.

## When this stops scaling

The setup above works and it keeps working, provided one careful person is doing every recording. That is the limit, and it is a people limit rather than a volume one.

It stops holding as soon as recording is something several people do occasionally - a support lead capturing a workaround, an engineer recording a bug reproduction that becomes documentation, a founder shooting a launch clip from a live account. None of them will have created a demo profile, and the failure is invisible until somebody outside the company points it out. The exposure is also asymmetric in a way most documentation risks are not: a stale button label costs a viewer thirty seconds, while a customer's email address on screen for one frame is a data incident that persists in every copy already downloaded.

Past a couple of recordings a month across more than one person, the reliable control is not a checklist but the absence of real data anywhere in the pipeline - walkthroughs generated from the product's interface code with fictional content, so no production screen is ever captured. [SupportPages](https://supportpages.io) generates them from a repository for that reason. If any published video was recorded from a live account, it is worth watching back this week regardless of what you do next.