app-preview-video

A preview autoplays muted in search results and takes the first slot on the product page; a good one lifts conversion 5–25%, a weak one costs the first-slot screenshot. Output is one listing Proposal per preview, a storyboard (shots, timing, caption copy, poster frame) the User or a producer records from in-app footage, uploads in App Store Connect and marks done the day it goes live, plus a brief with the decision and the production notes. Judge the current previews and screenshots from their pictures with view_image.

Gather

1. read_context — the core outcome, ICP, voice, the feature that demonstrates best.
2. connector_asc_screenshots when the ASC Connector exists — the Product's preview sets per localization and preview type, and its screenshot sets, whose orientation the preview shares. Look at each preview's posterUrl and the first screenshots with view_image. Without the Connector, fetch_url on iTunes Lookup (https://itunes.apple.com/lookup?id=<App Store id>&country=<storefront>) gives the public screenshotUrls and no previews: say that whether the Product carries one is unknown. No read returns a competitor's previews.
3. connector_asc_analytics when the ASC Connector exists — page conversion per source, read as pageDownloads ÷ pageViews, 30 days plus trend: the baseline. Without it, say it is unknown and name it as the first number to read once the preview is live.
4. app_store_reviews — the outcome users praise in their own words; it becomes the hook caption.

Decide, then storyboard

A preview earns its slot when the value shows in motion: games, apps with a distinctive interaction, apps that need a demonstration to be believed. A simple utility, or an app whose value sits in content instead of UI, keeps the first slot for a screenshot — say so and stop at the decision.

The beat timings, the three-variant strategy and the rejection reasons are in references/storyboard-beats.md — read it before writing the storyboard. Format, resolution, count and the pre-submission checklist are in references/spec-sheet.md — read it when writing the production notes.

Five beats fill 30 seconds: hook (the outcome in the first two seconds), problem (one caption states the pain), demo (the real screen recording, sped up when needed), proof (quick cuts of breadth, ratings, results as in-app screens), resolution (the outcome state as the last frame). Every frame is in-app footage; captions carry the message because most viewers never hear the audio; the poster frame is a still the store shows before play and in the search card, so it is the strongest frame, with no half-typed text.

Up to three previews per device: give each its own hook — outcome, demo, social proof — and put the outcome first unless the category expects a demo.

What neither the reads nor the pictures tell you — the screens a flow passes through, the device the footage can be captured on, whether the audio carries anything — is an assumption: state it as one in the brief and plan on it.

Output: one Proposal per preview, and the brief

Each variant is one propose with appStoreField: "appPreview": content is its storyboard, why names what it should move and the baseline it must beat.

PREVIEW — [Product] — Variant [A|B|C] — [outcome | demo | social proof]
Length: [15–30] s   Orientation: [portrait | landscape]   Locale: [primary]
Poster frame: [description]

00:00–00:02  HOOK        Visual: [screen, state]   Caption: "[copy]"
00:02–00:08  PROBLEM     Visual: …                 Caption: "…"
00:08–00:20  DEMO        Visual: …                 Caption: "…"   Speed: [1× | 1.25× | 1.5×]
00:20–00:26  PROOF       Visual: …                 Caption: "…"
00:26–00:30  RESOLUTION  Visual: [outcome state]   Caption: "…"

The brief, saved with save_output, carries the reasoning: the decision and its reason, the assumptions, the production notes (device model and OS version, demo account state, where to speed up, captions burned in, audio kept with captions or removed), then Apply — App Store Connect → the version → App Previews and Screenshots per device, one slot per variant, the poster frame chosen in the upload dialog; a preview ships with a version, and a Product Page Optimization treatment tests it against the screenshot-only page without one.

Done when the decision (preview or screenshot-only) is stated with its reason, every variant has its Proposal, every storyboard beat has a visual, a caption and a timing that sums to 30 s at most, the poster frame is named, the checklist in the spec sheet has been run against the storyboard, and the baseline is named or reported unavailable.

Related Skills

• screenshot-optimization — the slots that follow the preview, and the orientation the preview must match.
• localization — caption translation and re-recording per storefront.
• custom-product-pages — a preview per audience or campaign page.