--- name: custom-product-pages description: Plan an app Product's Custom Product Pages — one brief per audience with the ad groups it serves, screenshot plan and promotional text. Use for "custom product page", "CPP", "different screenshots per ad", "landing page per audience", "which CPP for this ad group", "did the custom product page work". For the default page's screenshots use screenshot-optimization; for the campaigns that route to the pages use apple-search-ads. metadata: version: 1.0.0 --- # Custom Product Pages Ship 2–4 product page variants that match the message of the traffic landing on them. Output is one `listing` Proposal per page — its screenshot plan and promotional text — that the User creates in App Store Connect and marks done the day it goes live, plus a brief Output for the routing and the launch plan; assigning a page to an ad group happens in Apple Ads. ## Gather 1. `read_context` — ICP segments, use cases, channels, positioning per audience. 2. `connector_asc_screenshots` and `connector_asc_localizations` when the ASC Connector exists — the default page's screenshot and preview sets and its promotional text per Locale: the baseline each variant departs from. Look at its first three slots with `view_image`. 3. `connector_asc_product_pages` when the ASC Connector exists — the current CPPs with their state, visibility, URL and deep link, and any product page optimization experiment running on the default page. Without it, assume no CPPs exist and say so. 4. `connector_apple_ads_campaigns` when the Apple Ads Connector exists — ad groups by theme, their TTR and CVR: the routing candidates, ad groups with TTR under 3 % first. Without it, route by the Foundation doc's segments and channels. 5. `connector_asc_analytics` when the ASC Connector exists — default page conversion overall, read as `pageDownloads` ÷ `pageViews`: the baseline to beat. ## Plan Patterns, what a CPP can and cannot change, measurement floors and the mistakes to avoid are in [`references/cpp-playbook.md`](references/cpp-playbook.md); read it before choosing an axis. 1. **Worth it?** — a CPP earns its review cycle when a source carries a distinct angle: a paid or partner source with enough volume (≥ 1,000 installs/month from the source), or a keyword theme — a CPP shows in organic search since July 2025 for the keywords assigned to it. A default page that has never been optimized gets `aso` first. 2. **One axis** — audience, use case, feature, channel, funnel stage or market. Pick one and plan 2–4 pages along it. 3. **Per page** — the hook the visitor arrived with, the promotional text (170 chars) that restates it, the 10-slot screenshot plan with slot 1 carrying the hook, whether the preview video is reused, and the ad groups or sources that route to it. 4. **Existing CPPs** — keep, rewrite, or retire each one against the axis; a CPP with no live source is dead weight. ## Output: one Proposal per page, and the brief Each new or rewritten page is one `propose` with `appStoreField: "customProductPage"`: `content` names the page and its promotional text with `chars/170`, then one block per slot with the screen it shows and its caption (design in `screenshot-optimization`), and the preview decision; `why` names the audience, the sources routed (ad group names from the Connector or channels from the Foundation doc), the hypothesis and the success metric as `conversion ≥ baseline + X %`. The brief, saved with `save_output`, carries the reasoning across pages: - **Routing table** — ad group or source × CPP, so every paid ad group with TTR under 3 % lands on a matching page. - **Launch plan** — create and submit in App Store Connect (1–3 day review), assign in Apple Ads, 14 days minimum and ≥ 1,000 product page views per page before judging, monitor in App Store Connect → Analytics → Custom Product Pages. - **Kill criteria** — the install floor and the conversion shortfall that revert a page to the default. Done when every page has its Proposal with promotional text within 170 characters and a full slot plan, every routed ad group appears in the routing table exactly once, and the brief names the data it lacked (existing CPPs, ad groups, conversion) when a Connector was absent. ## Read-out: did the page work A page is judged on the reports that follow its launch. When you write a report, read out every page the User launched, before planning new ones: 1. `read_proposals` with `category: ["listing"]` — the custom product page Proposals in state `done`, known by the page they name; `doneAt` is the day the page went live, and `why` names the sources routed to it. 2. `read_outputs` with `kind: "report"` — the earlier reports: which pages already have a verdict, and which were left pending. 3. `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:` ÷ `pageViews:`, and overall. The Series counts sources, not pages: the routed sources carry the page's effect, and Apple Ads traffic sits inside `App Store search`. Choose the two windows, and decide whether the page is readable yet against the launch plan's floor; 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 page 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 against the Proposal's success metric and the kill criteria, or the day the page becomes readable. The next Run finds a pending read-out through `read_outputs` and takes it up. Done when every custom product page Proposal marked done without a verdict in an earlier report has, in this report, a verdict or the day it becomes readable. ## Related Skills - `apple-search-ads` — the ad groups that route to each page. - `screenshot-optimization` — the screenshot sets per page. - `app-preview-video` — a variant preview when a page calls for one. - `ads` — Meta, TikTok and Google campaigns that use the CPP URL as destination.