Skip to content

Lesson 5 of 7 · 6 min read

Record the real product

Script a phone-sized recording of the real product with test data, keep it at full resolution, and label any result that is not real “Demo”.

A moment at work · fictional example

Maya can say what the pantry check does. A viewer believes it when they see the check run. Jo needs a recording of the real app that looks sharp on a phone and shows no real customer.

You will make: Record the product moment for your ad. Follow the fictional example first, then try it with material you are permitted to use.

Show only what the product does today

The product moment is the one part of a UGC ad that shows the product working. Everything else is a creator talking about it. So this part has to be the real product, recorded as it runs today.

Never mock up a screen, button or result the product does not have. A mocked-up screen shows a feature a viewer cannot find when they tap the link. If a feature ships next month, film it next month.

Effects in the edit are a different matter. Confetti, a caption or a zoom sits on top of the recording, and viewers read it as part of the ad. A button drawn inside the app’s screen reads as part of the product.

Script the recording

Record with a script, not by hand. A script taps the same places at the same speed on every take. When the product changes before you post, you run it again and get a matching take.

Playwright is a free browser automation tool that can drive a page the way a phone would. Set a viewport of 390 by 844 CSS pixels with a device scale factor of 3, and turn on mobile and touch. The page then renders at 1170 by 2532 pixels.

Without code, use your browser’s device mode and a screen recorder. Chrome’s documentation calls device mode a first-order approximation of a phone. A native app needs the phone’s own screen recorder or a simulator, and the rules below still apply.

Write the take the way the edit will use it. Hold on the first question long enough for a viewer to choose an answer. Answer the rest quickly, because the edit cuts that stretch. Hold on the result for several seconds.

Make the taps visible and the screen clean. Draw a soft dot where each tap lands, so viewers see the touch. Hide developer badges and staging banners. Have the script write the time of each event to a marks file, so the edit can find the question and the reveal.

Test data and the Demo label

Record a staging or local copy of the product, signed in as a test account. Never record a real customer’s account, even with their permission, because their data would then sit in an ad.

Seed the test account with data a plausible user might have. In the edit, label every result that comes from test data with the word “Demo”, such as “Demo result”. Put the label on the result itself, at a size a viewer can read on a phone.

Blur test names, internal IDs and anything else that reads as a test. The label tells viewers the result is not anyone’s real score. The blur keeps the screen from looking broken.

Keep full resolution

A vertical ad is 1080 pixels wide, so the recording must be at least that wide or the text goes soft. Built-in recorders often scale down. Playwright’s documentation says its video defaults to the viewport size scaled down to fit 800 by 800.

One fix is to capture full-resolution frames instead of a video. The Chrome DevTools Protocol can send each screen frame as an image with a timestamp. Save the frames, then assemble them at 30 fps with ffmpeg, holding each frame until the next one arrived.

Then check a still. Place one frame at full width on a 1080 by 1920 canvas and zoom in on the smallest text. If you can read it, the recording is sharp enough.

Worked example · Fernway

Jo records the pantry check

Lesson 4 left Jo with three lip-synced talking clips, three b-roll clips and voice take A, at $19.80 of the $25 cap. The recording costs nothing from the cap. The product beat needs the pantry check on screen: the start, one question and the waste-score reveal. A Fernway engineer sets up a staging copy of the app with a test household.

  1. Jo asks an assistant to write a Playwright script from the shot plan. It opens the check at 390 by 844 with a scale of 3. It holds 4.5 seconds on the first question, answers it, and answers the rest quickly. It holds 5 seconds on the result and logs each event time to a marks file.
  2. The first take uses Playwright’s built-in video. On a 1080-wide canvas, the question text is soft and the edges of the answer buttons blur.
    What would you do next?The page looked sharp in the browser. Why is the video soft?Think it through, then show the answer

    Playwright’s recorder scales the video down to fit 800 by 800 by default. Stretched to 1080 wide, the frames lose detail. Jo needs frames at the full 1170 by 2532 instead.

  3. Jo changes the script to save Chrome’s screencast frames at 1170 by 2532, each with its timestamp. An ffmpeg concat list holds each frame until the next and outputs a 30 fps video. A still at full width shows crisp question text.
  4. The result screen shows the waste score, a use-first list and the name “QA Household 2” in the header. Jo plans a blur over the name and a Demo result label over the score.That answers the question you guessed at: Guess: the pantry check in Jo’s recording runs on test data, so its waste score belongs to no real household. What should the video do about that score?
  5. A colleague asks for a “Share your score” button on the result screen, to make the reveal stronger. The app has no share button.
    What would you do next?Can Jo draw the button in the edit, since the confetti is added in the edit too?Think it through, then show the answer

    No. Confetti sits on top of the recording and reads as part of the ad. A button drawn inside the app’s screen reads as a feature, and viewers would look for it. Jo records the screen as it is.

  6. Jo watches the full take on a phone. Every tap shows a dot, no staging banner appears, and the marks file has the times of the question and the reveal.

Jo has a 40-second recording at 30 fps, a marks file and a label plan: a blur over the test name and “Demo result” over the score. The edit will use about 12 seconds of it. The script, seed data and frames sit in the project folder in case the app changes before the post.

Go deeper: the research and edge cases

Optional. The exercise needs only what is above.

Frame capture in detail

The protocol marks its screencast command as experimental, so pin your browser version for the length of a project. The command takes a maximum width and height. Set them to the full device pixel size, or the frames shrink.

Frames do not arrive on a fixed clock, so save each frame’s timestamp with it. To assemble them, write an ffmpeg concat list. Each line names one frame and gives its duration, the time until the next frame. Render the list to a 30 fps video, and a still screen holds as long as it held in the browser.

Fit the recording to the canvas width and align it to the top. A 1170 by 2532 recording placed at 1080 wide is about 2337 pixels tall. The bottom of the screen falls off a 1920-pixel frame, so keep what the edit needs in the top four-fifths.

When to record again

Record again whenever a screen in the take changes before the post. The script makes that a few minutes of work. Keep the script, the seed data and the marks file with the video files.

Starter prompts

  • Write my recording script

    Write a Playwright script in JavaScript that records my product on a phone-sized screen. The page is at [staging or local URL], signed in as a test account. Here are the steps to record, with how long to hold on each screen: [paste them]. Use a 390 by 844 viewport with a device scale factor of 3, with mobile and touch on. Capture full-resolution screencast frames through the Chrome DevTools Protocol, and save each frame with its timestamp. Draw a soft dot where each tap lands, and hide any developer overlay. Write the time of each step to a marks file. Where you do not know a selector, write TODO and say which element it should find. Do not invent screens or buttons I did not describe.

  • Plan my Demo labels

    Here is every screen in my product recording, with what each one shows: [paste them]. Here is the data in the test account that is made up: [paste it]. For each screen, list every value that comes from test data, and say whether it needs a "Demo" label, a blur, or nothing. Flag anything that could read as a real customer’s result. Do not suggest adding any element the product does not show.

  • Assemble frames at 30 fps

    Here is my frames file, with each frame’s file name and timestamp in seconds: [paste the first lines]. Write a short script that turns it into an ffmpeg concat list, where each frame’s duration is the time until the next frame. Give the last frame a duration of one second. Then write the ffmpeg command that renders the list to an H.264 video at 30 fps, at the frames’ full size.

When not to use AI

  • Recording a real customer’s account or real customer data, even with their permission. Use a test account.
  • Mocking up a screen, feature or result the product does not have, including one that is coming soon.
  • A built-in recorder’s default output, before you check a still at full width.
Recall from memoryWhat keeps the product screen in a UGC ad honest?Answer it without looking back, then show the answer

Record the real product as it runs today, with a script and a test account. Label any result from test data “Demo”, blur test names, and never mock up a screen or feature the product does not have.

Exercise · your project

Record the product moment for your ad.

  1. List the screens your script’s product beat needs, and how long each should hold.
  2. Set up a staging or local copy with a test account, and seed it with plausible data.
  3. Write or generate the recording script, with a marks file and visible taps.
  4. Check one still at full width on a 1080 by 1920 canvas, and record again if the text is soft.
  5. Write your label plan: every value that needs “Demo” or a blur.

Your project workspace

Leave with work you can use.

Write here or use an approved tool. Use fictional or permitted information. Your work stays in this open page and disappears on reload. Nothing is submitted to Emeri or an AI service.

This is self-review. Completion is saved on this device and does not award certification.

Sources