How to Record a Demo Without Exposing Customer Data

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