A demo video explains in order and an ad opens on the result. That is the whole difference, and it is why the clearest, most carefully sequenced part of your demo makes the worst ad: it teaches, and an ad has no time to teach. An ad makes a claim and shows one piece of evidence for it. A demo earns its length with a viewer who has already decided to pay attention, which a feed viewer has not.
So a demo recording is source material, not an ad, and cutting it well is mostly a matter of inverting its order.
The ordering difference, stated plainly
| Demo video | Ad | |
|---|---|---|
| Opens on | Context and setup, sometimes an agenda | The result, in the first three seconds |
| Order | Chronological. Step one, then step two | Reverse. Outcome, then the mechanism that caused it |
| Assumed attention | Granted. The viewer chose to watch | Borrowed. The viewer is being interrupted |
| Completeness | Covers the product, or a whole module | One capability, and nothing else |
| Success measure | Understanding | A click, or a scroll stopped |
| Length | Two to twenty minutes | 15 to 30 seconds in feed |
| What the viewer does after | Books a call, or asks a colleague | Decides in one second whether this concerns them |
| Best moment to use | The clear, patient explanation | The moment something visibly changes |
Look at the last row. In a demo, the strongest passage is usually a well paced explanation of how a feature works, because it produces understanding. In an ad, that same passage is dead weight, because it answers a question the viewer has not yet asked. The ad has to make them ask it first, and the way to do that is to show the outcome and let the curiosity do the work.
Practically, the inversion looks like this. A demo says: here is the import screen, you map your columns, then you validate, then it runs. The ad says: this took eleven minutes instead of a week, and then shows six seconds of the import running.
Which demo moments make good hooks?
Not the explanations. Look for the frames where something visibly changes state, and for the moments where the presenter stops presenting.
| Demo moment | Works as a hook? | Why |
|---|---|---|
| A number changing on screen | Yes, best in class | Visible before it is understood, and it implies a result |
| A long list collapsing to a short one | Yes | The value is legible with no explanation at all |
| An error or conflict being caught | Yes | Recognition. The viewer has lived that problem |
| The presenter saying "this used to take us a day" | Yes | An unscripted claim, usually the best line in the recording |
| A drag and drop or one click action | Often | Only if what it produced is visible in the same frame |
| Navigation and menu tours | No | Nothing has happened yet |
| The feature explanation you are proudest of | No | It teaches. Save it for the landing page |
| The setup and configuration steps | No | It is work, shown as work |
| The agenda slide | No | It is a promise of value rather than value |
The pattern under the yes rows: state changed, and the change is visible without a caption explaining it. The pattern under the no rows: something is being described rather than happening.
Two things worth harvesting on a first pass through any demo recording. First, every unscripted aside the presenter makes, because "honestly, the reason we built this was that nobody could ever find last quarter's numbers" is a better hook than anything in the script. Second, every moment a prospect on a recorded call reacts, if you have permission to use the recording. Customer voices on demo calls need consent in writing before they appear in a paid ad, the same as any customer footage, so check before you cut rather than after.
Screen recording legibility at phone size
This is where most demo derived ads fail, and it is a purely mechanical failure. A full 1920x1080 desktop capture placed in a 1080x1350 feed slot puts your interface text at roughly a quarter of its intended size, on a screen held at arm's length. Nobody can read it, so nothing you showed registered.
What we do:
- Crop to the region that matters, then scale it up. One panel, one table, one field. Never the whole application window.
- Record at a higher browser zoom than feels natural, 150 percent or more, so the text is large before any cropping.
- Aim for interface text that occupies at least a twentieth of the frame height. If a label is smaller than the caption text, it is decoration rather than information.
- Use a clean demo account with short, plausible data. Real accounts are cluttered, and clutter costs you the frame.
- Hide the cursor's journey. Cut between states rather than showing the mouse travel across the screen.
- Never place important interface elements in the bottom fifth, where captions and platform chrome sit.
- Slow one action down and let it hold for a full second. Screen capture at natural speed reads as a blur in a feed.
If a capability genuinely cannot be made legible at phone size, do not build a feed ad around it. Make the ad about the outcome, with a caption stating the number, and keep the screen footage as a texture behind it. That is a legitimate choice, not a compromise, and it is how we handle most reporting and analytics features in a product demo video ad.
One capability per ad
The instinct with a 20 minute demo is to compress it, and compression is the wrong operation. Selection is the right one.
One capability, one claim, one next step per ad. Three reasons this is not just tidiness:
The viewer can only retain one thing from a 20 second video, so a three feature ad is a one feature ad chosen at random by the viewer. Second, an ad about one capability qualifies its audience sharply, which is the main job of a B2B feed ad: the person who cares about the import will click and the person who does not will scroll, and both outcomes are good. Third, one capability per ad turns your demo into a set rather than a summary, and a set is what a rotation needs.
That last point is the operational argument. A 20 minute demo recording typically yields 10 to 25 usable clips, which is enough for several distinct ads plus the b-roll to support them. Our 2026 fatigue benchmark puts a typical active campaign at 8 to 20 live variations, with CTR down 45 percent after a fourth exposure to the same creative, so one compressed demo ad is roughly two weeks of runway while a selected set is a quarter of it.
The workflow we use for this is turning long video into short ads: upload the demo recording once, it transcribes and tags every clip, then each variation is a fresh script, shot selection, voiceover, caption set and export built from that library rather than a trim of the same timeline. Same for interviews and webinar recordings feeding a SaaS video ads set. Exports are 9:16, 4:5, 1:1 and 16:9 at 1080p, no watermark, one credit per variation, five free with no card.
Two things we do not do, and they are relevant here. We cannot import your product from a URL and generate an ad from it, so the screen footage has to be recorded by you. And we have no AI avatars or synthetic presenters, so the voice explaining the capability is either yours, a voiceover, or captions.
Frequently asked questions
Can I just cut my demo video down to 30 seconds?
Compressing a demo produces a rushed demo, not an ad, because the order is still wrong. Select one moment where something visibly changes, put the outcome in front of it as a claim, and let the rest of the recording feed other ads. Selection beats compression every time.
Which part of a demo makes the best ad?
The moment a number changes, a list collapses, or an error gets caught, plus any unscripted line where the presenter says how long something used to take. Avoid the clearest explanation in the recording, however good it is, because explanation is what a landing page is for.
How many ads can I get from one demo recording?
A one hour recording typically yields 10 to 25 usable clips, which supports several distinct ads plus supporting footage. The limiting factor is how many capabilities are legible at phone size, not how long the recording is.
Why is my screen recording unreadable in the feed?
Because a full desktop capture scaled into a phone sized frame renders interface text at roughly a quarter of its intended size. Record at a high browser zoom, crop to one panel, and hold each action for a full second. If it still cannot be read, make the ad about the outcome and use the capture as texture.