Recording your product when the screen is full of customer data
A practical guide to demo environments, masking policies and the things that get accidentally published.
Every B2B software company eventually publishes a video containing something it should not have. A customer name in a list view. An email address in a test account. An API key visible in a settings screen for eleven frames.
It is rarely negligence. It is that the person recording is concentrating on the demo, and the sensitive thing was in their peripheral vision for two seconds.
Three approaches, in order of preference
1. A seeded demo tenant
The best option by a wide margin: a dedicated tenant in staging, populated with fictional data that looks realistic. It costs a day to build and eliminates the problem structurally.
The usual objection is that the demo tenant never has enough data to look real. That is a seeding problem, not an argument against the approach. Generate a few thousand plausible records once and maintain them with a script that runs weekly.
2. Production with enforced masking
Sometimes production is unavoidable — the feature only works with real volume, or the staging environment is three releases behind. In that case the masking has to be enforced at the workspace level rather than left to the person recording.
The distinction matters enormously. A masking feature that the recorder has to remember to turn on will be forgotten. A workspace policy that applies automatically and cannot be disabled will not.
3. Post-hoc redaction
The worst option, because it means the sensitive value was written to storage before it was removed. If your threat model includes your own vendor's storage, post-hoc redaction does not solve it.
The thing people forget
Blur the video and you have blurred the video. The transcript, the generated guide, the screenshots and the search index may all still contain the value. Redaction has to apply to every derived artifact, not just the frames.
What to mask
Start with the obvious: email addresses, phone numbers, card numbers, API keys, bearer tokens, account identifiers, physical addresses. Then add the ones specific to you — customer names in a list, internal ticket references, anything that identifies which of your customers this is.
A pattern worth adopting: mark whole regions as always-blurred rather than relying on value detection. If the left panel of your app always contains a customer list, mask the region. Detection catches known patterns; region masking catches the ones you did not anticipate.
Publishing checks
- Review the generated guide's screenshots separately from the video — they are cropped differently and may reveal what the video did not.
- Search the transcript for @ and for digit sequences of 13+ characters before publishing.
- Check the first and last two seconds specifically; that is where recording starts before the demo tenant is loaded.
- If a video is public, assume it will be indexed, archived and downloaded. Retraction is not a control.