screenshot-optimization

Turn the Product's positioning into the screenshots that convert a product page visitor into a download. Output is one listing Proposal per screenshot set you change, which a designer or the User produces, uploads in App Store Connect and marks done the day it goes live, plus a brief with the design direction, the competitor audit and the A/B hypotheses the User runs as a Product Page Optimization test. Judge every screenshot, the Product's and the competitors', from the picture itself with view_image.

Gather

1. read_context — positioning, ICP, the three benefits that matter most, voice, brand colors, competitors.
2. connector_asc_screenshots when the ASC Connector exists — the Product's screenshot and preview sets per localization and display type, in slot order. Look at every slot of the primary locale's sets with view_image: the screen shown, the caption burned into it, the layout. Without the Connector, the public screenshots come from iTunes, as below.
3. The public screenshots, through fetch_url on iTunes: Lookup (https://itunes.apple.com/lookup?id=<App Store id>&country=<storefront>) for the Product when read_product_state gives its App Store Surface's appId, Search (https://itunes.apple.com/search?term=<name>&entity=software&country=<storefront>&limit=1) by name otherwise and for each competitor named in the Foundation doc. Each result's screenshotUrls and ipadScreenshotUrls come in slot order: look at each competitor's first three with view_image for the competitor audit. No read returns a competitor's previews: mark them unknown.
4. connector_asc_analytics when the ASC Connector exists — page conversion per source (search, browse, referrer), read as pageDownloads ÷ pageViews, 30 days plus trend: the baseline the new set must beat. Without it, say the baseline is unknown and name it as the first number to read after the test starts.
5. app_store_reviews — the words users use for the outcome, and one quotable line for the social-proof slot.

Plan the set

A visitor decides in 3–6 seconds; the first three slots show in search results before any tap and carry most of the decision. The slot roles, effective first-slot patterns, caption and layout rules are in references/slot-framework.md — read it before assigning slots. Device sizes, counts and file rules are in references/device-sizes.md — read it when writing the Apply section or when the sets show a device without screenshots.

Assign the slots in this order:

1. Slot 1, the hook — the benefit headline plus the screen that proves it. The caption answers "what does this do for me".
2. Slots 2–3, core value — the two next benefits from the Foundation doc, each on its own screen.
3. Slots 4–7, feature showcase — one feature per slot, formula benefit headline + feature UI + supporting detail.
4. Slots 8–9, trust and differentiation — rating, review quote, press, awards; the angle competitors leave open per the audit.
5. Slot 10, close — recap or the offer ("Start your free trial").

Caption copy: 4–6 words, benefit over feature name, one idea per slot, zero words repeated from slot to slot, in the Product's voice. Every caption is a claim the screen behind it shows.

What neither the reads nor the pictures tell you — a screen the app may lack, the state a screen can be captured in, the audience a slot speaks to — is an assumption: state it as one in the brief and plan on it.

A/B hypotheses

Write three hypotheses, one variable each, ranked by expected lift: first-slot message (benefit vs social proof vs problem statement), caption style (benefit vs feature), layout (full-bleed vs framed device vs split). Each hypothesis states the variant, the reason drawn from the audit or the reviews, the metric (product page conversion), and the read-out rule: Product Page Optimization takes up to three treatments against the default, runs up to 90 days, and a treatment needs at least a week and Apple's confidence indicator before it is declared.

Output: one Proposal per set, and the brief

Each screenshot set you change is one propose with appStoreField: "screenshots". Its content names the display type and locale, then one block per slot:

Slot N — [role]
Caption: "[copy]" (words: N)
Screen: [which app screen, which state loaded]
Layout: [portrait/landscape, framed/full-bleed, caption position]
Eye lands on: [the one element]

Its why names what the new set should move and the baseline it must beat.

The brief, saved with save_output, carries the reasoning:

• Assumptions — each one, and the slot it bears on.
• Design brief — palette from the Foundation doc, type recommendation, background style, device frame choice, the caption copy for every slot in one list the designer pastes.
• Competitor audit — table: screenshot count, preview yes/no, first-slot type, caption style, design quality (1–10, from the pictures), angle claimed — Product vs each competitor — and the angle left open.
• A/B hypotheses — the three above, ready to enter as PPO treatments.
• Apply — App Store Connect → the version → App Previews and Screenshots per device; screenshots ship with a version, PPO treatments do not need one.

Done when every changed set has its Proposal, every slot in it has a caption within the word rule and a named screen, the first three slots read as a complete pitch on their own, the audit scores every competitor from the Foundation doc from its pictures, and the brief names the baseline conversion or states that it was unavailable.

Read-out: did the change work

A screenshot change is judged on the reports that follow it. When you write a report, read out every screenshot change the User applied and every product page optimization experiment, before planning the next set:

1. read_proposals with category: ["listing"] — the screenshot Proposals in state done, known by their slot plan; doneAt is the day the set went live.
2. connector_asc_product_pages — each experiment's startDate and endDate. Apple's API returns no experiment result, so an experiment is read like a change, from its dates; while it runs, its treatments get only trafficProportion of the traffic, so a shift is diluted by that share.
3. read_outputs with kind: "report" — the earlier reports: which changes already have a verdict, and which were left pending.
4. connector_asc_analytics with from and to, once for the window before the day and once for the window from it — in execute_typescript, product page conversion per source type, pageDownloads:<Source Type> ÷ pageViews:<Source Type>, and overall.

Choose the two windows, and decide whether the change is readable yet; until it is, its read-out is pending. Apple's reports run a day or two late, so the Series may stop short of today.

Write the read-out into the report you save with save_output: the change and its day, both windows, and per source the page views, the page downloads, the conversion before and after and the change in points; then the verdict, or the day the change becomes readable. The next Run finds a pending read-out through read_outputs and takes it up.

Done when every screenshot Proposal marked done and every experiment without a verdict in an earlier report has, in this report, a verdict or the day it becomes readable.

Related Skills

• app-preview-video — the autoplay video that occupies the first slot when present.
• app-icon-optimization — the icon shown beside the first three screenshots in search.
• custom-product-pages — screenshot variants per audience or campaign.
• localization — translated captions per storefront.