---
title: "Recording demo screencasts that pass marketplace review"
description: "We record the page, not the screen, in a dedicated browser, with steps addressed by selector and captions burned in. Each beat of the film shows one thing the requested permission is used for, so the reviewer can see the app do what the listing claims. Most of our rejected takes came from the surface and from leftover state, not from the app."
date: 2026-10-11
lang: en
canonical: https://goingstellar.ro/methods/recording-demo-screencasts-that-pass-marketplace-review/
author: Going Stellar
publisher: GOING STELLAR S.R.L.
topic: Apps / Review
license: CC BY 4.0
alternate_ro: https://goingstellar.ro/ro/metode/filmarea-demonstratiilor-care-trec-de-recenzie/
---

# Recording demo screencasts that pass marketplace review

*We record the page, not the screen, in a dedicated browser, with steps addressed by selector and captions burned in. Each beat of the film shows one thing the requested permission is used for, so the reviewer can see the app do what the listing claims. Most of our rejected takes came from the surface and from leftover state, not from the app.*

> Apps · Review · 2026-10-11 · https://goingstellar.ro/methods/recording-demo-screencasts-that-pass-marketplace-review/

## Key points

- A marketplace reviewer does not grade a demo video; the reviewer uses it to decide whether the app does what the listing and the permission request claim.
- Record the page rather than the screen, in a dedicated browser, so the capture shows only the app and never another window.
- Addressing each demo step by selector, with positions read live before the click, makes screencasts survive layout changes that break hand-calibrated coordinates.
- A video that hides a weakness only moves the rejection later: when a narrower permission path exists in the code, the fix is the code, not a better film.
- Most rejected takes come from the host interface and from state left over between takes, not from the app being filmed.

## What this is for

Marketplace reviewers ask for video. For a Google Workspace add-on, the review email asks for an end-to-end screen recording that shows how each requested permission is used. OAuth verification for a sensitive scope asks for a YouTube link. Shopify asks for a walkthrough in English or with English subtitles. This is how we record those videos so a reviewer can follow them without help, and the takes we had to throw away.

The point to hold on to: a reviewer does not grade the video. They use it to decide whether the app does what the listing and the permission request claim. A video that hides a weakness only moves the rejection later.

## Record the page, in a browser nobody else is using

**1. Record the page, not the screen.** We record with Playwright's page screencast over the Chrome DevTools Protocol. It captures only the page's pixels, runs in the background, needs no screen-recording permission and does not take over the machine. Capturing the whole display is a fallback only, and only after a test screenshot shows the right window in front: once, window activation failed silently and the recording caught whatever was on the screen, including private windows. That file was deleted at once.

**2. Use a dedicated browser.** Filming runs in its own Chrome instance, with its own profile and debugging port, separate from any browser a person is working in. We once started a recording agent on a browser that was in active use, and stopped it before it recorded anything.

**3. Address elements by selector.** Our first pipeline calibrated screen coordinates by hand, about 80% of the setup time, and broke whenever the layout moved. Now each step names an element by role, label or text, and its position is read live just before the click. Setting up a new app went from about a day of calibration to 30 to 60 minutes.

**4. No drawn cursor by default.** A synthetic pointer looked mechanical on video. Without it, clicks land and the interface reacts, like a recording where the cursor was not captured.

## A walkthrough, not a tour

A Shopify screencast of ours, for MergeGuard, was rejected under requirement 4.5.3: the reviewer needed clear step-by-step instructions to set up and test the core features. Our cut had pointed at headings and set nothing up. What passed followed the merchant's real setup order and exercised every core feature on camera, narrated as numbered steps.

For a Workspace add-on the film is short, about 45 to 85 seconds, silent, with captions burned in. One beat for each thing the permission is used for, in the order a person works: the document as it is; the selection, which shows that the add-on touches only what was selected; the panel opening and reporting what it read; the preview, if there is one; the action that writes, with its confirmation; Undo, if there is one; and a line saying the licence is checked locally, with no server. Seven beats, each one something the reviewer can see happen.

## Captions are part of the video

Our recordings have no voice, so the captions carry the explanation, and the reviewer should not have to switch them on. Neither obvious route worked for us: uploading caption tracks needed a YouTube permission our upload credential did not have, and our build of ffmpeg had no subtitle filter.

What works is rendering each caption as a transparent image and overlaying it for its time window, about 32 overlays for a two-minute demo. The script's narration lines are split into sentences and each gets a duration weighted by its length. A caption is never cut to fit three lines: that silently dropped half a sentence.

## Proving least privilege on camera

For OAuth verification the video has to show why each sensitive scope is needed. Our Gmail add-on Cards was refused because the video did not show *why narrower permissions cannot be used*. No better video could fix that, because a narrower path existed in the code. We changed the code to read only the message header when the panel opens and the body only when the person acts, and filmed again.

To make the narrower reading visible we put a witness in the data: a test email whose body contains a marker sentence that is not in the subject. When the panel opens, the marker is visible in the message and absent from the panel, in the same frame. After the action, it appears in the result. Without the marker, ‘we did not read the body’ and ‘we read it and did not show it’ look the same.

Two more things about verification videos. The project owner never sees Google's unverified-app screen, which the video is supposed to show; installing from the public store page with an outside account does show it, but only works once the add-on is public. And the written justifications we first drafted from memory contained claims the code contradicted, such as ‘nothing leaves the user's account’ for an add-on that sends email. An adversarial read of the code found them before submission.

## Traps of the Docs, Sheets and Slides surface

We filmed four add-ons in one session, across three surfaces: Docs, Sheets and Slides. Each trap below cost a take.

Every CardService control rebuilds the card on the server, so a click sent too soon after another lands on a detached node: it ‘succeeds’ and nothing happens. That produced three false reports of a broken button. We wait for the next control to be visible, then pause. Grids of icons are also exposed as a single container button whose name joins every label, so selectors on grid cells must be exact. In Docs, extending a selection with Shift and arrow keys did not work through automation; a real mouse drag did. In Sheets, the name box is safer than dragging, which tends to grab the column header and select the whole column, contradicting the ‘only what you selected’ story.

Search fields in the panel fire on Enter and arrive prefilled with the last saved search, so typing adds to it: we once filmed a search for ‘rocketrocketrocket’. Fill the field, then press Enter. In Slides the side panel is hidden until *Show side panel* is pressed. In Sheets, the Gemini panel can open in the add-on's place. In Docs, the built-in outline panel has to be collapsed, or the film appears to demonstrate a feature Docs already has.

## State between takes, and the reviewer who filmed us back

A dry run that clicks also changes the document, so we recreate the file between the dry run and the take. A dry run that does not interact cannot validate selectors: we used the hint text under a field instead of its accessible label and found out mid-take. Add-on settings persist between takes, so we write state in full rather than adding to it: once, entries left from old tests made our optimisation add-on refuse correctly on camera, a failure we had manufactured. And a checkbox's `value` is not its state. We narrated that whole numbers were on while the box was off, and the result on screen, 17.78 batches, contradicted the caption.

Before filming we activate a licence key, or the paid features never appear. Before taking listing screenshots we remove it again: one screenshot showed a test address as an active Pro licence. For Gmail screenshots, the guard checks structure, not words: every visible row must be one of our synthetic test messages.

Then a reviewer sent us a video of their own, a 1:07 clip. Its link was only in the raw source of the email, not in the rendered text. They had rebuilt the example from our demo but typed numbers where our sheet had formulas. The add-on diagnosed it correctly and left the sheet alone, and offered one button: Back. Our video was accurate; the product required a correctly built file before the first success. We added a button that builds a working example in a new sheet.

## Limits, and a checklist

A good recording gets a fair review. It does not prove the app works for people whose files and accounts differ from ours, and the reviewer's own attempt is a better test than our film. Some traps above belong to a particular week of Google's interface and will change.

**Checklist.** Page capture in a dedicated browser. Selectors read live, dry run first, document recreated. One beat per use of each scope; a walkthrough, not a tour. Captions burned in, never truncated. A witness in the data when least privilege is the question. Licence on for filming, off for screenshots. Look at a frame before uploading, and read any video the reviewer sends back.

## Questions and answers

### What should a demo video for Google Workspace Marketplace review show?

A demo video for Google Workspace Marketplace review should show, end to end, how each requested permission is used. A short silent film with captions burned in works well, with one beat per use of the permission in the order a person works: the document, the selection, the panel reporting what it read, any preview, the action that writes, any Undo, and a note on how the licence is checked.

### How do you prove least privilege for a sensitive OAuth scope in a video?

Proving least privilege for a sensitive OAuth scope on video works best with a witness in the data, such as a test email whose body contains a marker sentence absent from the subject. When the panel opens, the marker is visible in the message and missing from the panel in the same frame, and it appears only after the user acts. Without the marker, not reading the body and not showing it look identical.

### Why was my Shopify app screencast rejected for missing setup instructions?

A Shopify app screencast is rejected for missing setup instructions when the reviewer cannot follow clear step-by-step setup and testing of the core features. A video that only points at headings is a tour, not a walkthrough. The version that passes follows the merchant's real setup order, exercises every core feature on camera and narrates the steps as a numbered sequence, in English or with English subtitles.

### How do you add captions to a screencast when subtitle tools are unavailable?

Captions can be added to a screencast by rendering each caption as a transparent image and overlaying it for its time window. The script's narration lines are split into sentences, and each sentence gets a duration weighted by its length. Captions should be burned in so the reviewer does not need to switch them on, and a caption should never be truncated to fit, because truncation silently drops part of a sentence.

### Why do automated clicks in a Google Workspace add-on panel sometimes do nothing?

Automated clicks in a Google Workspace add-on panel can do nothing because every CardService control rebuilds the card on the server, so a click sent too soon after another lands on a detached node. The click appears to succeed but nothing happens, which looks like a broken button. Waiting until the next control is visible and then pausing briefly avoids these false failures during recording.

## How to cite

**Cite this as:** Going Stellar (2026). *Recording demo screencasts that pass marketplace review*. GOING STELLAR S.R.L.. https://goingstellar.ro/methods/recording-demo-screencasts-that-pass-marketplace-review/

```bibtex
@misc{goingstellar2026recording,
  title  = {Recording demo screencasts that pass marketplace review},
  author = {{Going Stellar}},
  year   = {2026},
  url    = {https://goingstellar.ro/methods/recording-demo-screencasts-that-pass-marketplace-review/},
  note   = {2026-10-11}
}
```

Licence. Free to quote with attribution.

## Also available

- This page as HTML: https://goingstellar.ro/methods/recording-demo-screencasts-that-pass-marketplace-review/
- Same article in Romanian: https://goingstellar.ro/ro/metode/filmarea-demonstratiilor-care-trec-de-recenzie/