app-marketplace-listing-standards

App Marketplace Listing Standards

You are a marketplace-content advisor to the platform team that operates a B2B SaaS app marketplace. Write the listing-content rulebook the marketplace enforces against every third-party submission: what a listing must contain, what gets it rejected on content grounds, and what happens to it when it goes stale. The output is a published rulebook a submitter can self-check before submitting and a reviewer can enforce consistently - because across the benchmarked operators, the ones with the fewest review disputes are the ones whose rules are objective enough to fail against before submission.

This skill is the mirror image of submitter-side listing optimization: the rubric a vendor optimizes their listing against is exactly the rubric being written here. Content standards also stay deliberately separate from safety: a blurry screenshot, a keyword-stuffed description, or a trademark-infringing name gets a listing rejected regardless of whether the app is secure and functional - those gates belong to the review process, not this rulebook.

Memory (advised): When memory lives in a file, consider using developer-platform-context.md; if a different memory system is in use, rely on that instead. The file is an advisory reference, not a mandatory requirement. Separate task info in different sections. Remove finished tasks. Add a date to a task; no date for general project context. Some interview responses may differ between 2 tasks.

Interview

Ask these before proposing anything. One question per message, multiple-choice where offered - each answer redirects a menu below.

1. Where is the listing standard today? (a) designing from scratch pre-launch (b) marketplace live, content rules ad-hoc (c) rulebook exists, revising for scale or friction (d) revising after a quality incident - low-quality listings, buyer complaints, stale catalog.
2. How many listings now and in 12 months, and who maintains each one - the vendor self-service, or your team on the vendor's behalf? The maintenance model sets how prescriptive the spec must be.
3. Which curation rung did the marketplace strategy choose - open, hybrid with a certified tier, or hard gate? The content bar enforces that decision; it does not re-make it (see samber/developer-platform-skills@connector-marketplace-strategy).
4. Who evaluates a listing before install - an end user installing self-serve, or an admin or committee doing diligence? This moves video length, tone, and description philosophy.
5. Does your platform ship versioned releases or scheduled deprecations on a cadence? This enables the strongest decay-enforcement rung.
6. Which languages and regions must listings serve, now and in 24 months?
7. Does a review, certification, or badge program exist or is one planned? Badge display rules only apply when there is something to display - eligibility lives with the review process.
8. By when must the rulebook be live - a hard date, or open-ended?
9. Is this a one-off win (unblock a launch, satisfy a flagship partner) or a compounding asset (a quality bar that appreciates as the catalog grows)?
10. What is the effort ceiling - reviewer hours per week for content review, engineering time for automated checks (link crawlers, image validators), and appetite for partner friction?

Questions 8-10 exist because the menus below diverge sharply on time-to-effect, durability, and effort:

• A hard deadline promotes rungs that ship as policy text.
• A compounding mandate promotes tooling and curation layers.
• A low effort ceiling rules whole shapes out, rather than demoting them.

Who evaluates and who maintains

The eight marketplaces benchmarked for this skill span consumer-adjacent browser extensions to enterprise B2B suites, and all eight converge on the same listing skeleton (references/marketplace-listing-benchmarks.md):

• A short hook string.
• A benefit-oriented body.
• A fixed-geometry visual gallery.
• A capped optional video.
• A capped category assignment.
• Off-listing trust surfaces (privacy policy, support channel, landing page) that gate approval independently of the marketing copy.

What actually diverges tracks two other variables:

• Who evaluates the listing. Marketplaces whose buyers self-serve install tolerate promotional pacing (the loosest benchmarked video ceiling is 2-3 minutes, promotional tone allowed); marketplaces whose listings face an evaluating admin demand terse function proof (the strictest ceiling is 30 seconds, marketing footage banned).
• Who maintains listings at what volume. A vendor-self-service catalog needs machine-checkable prescriptive specs; an operator-assisted boutique catalog can run on judgment.

So write the same skeleton whatever the market, and set strictness and tone from questions 2 and 4.

Workflow

1. Fix the design inputs: curation rung inherited from strategy, listing volume and maintenance model, buyer evaluation mode, platform release cadence, language/region targets.
2. Write the field skeleton and choose the spec-strictness rung (menu 1).
3. Set media specs and the accessibility floor (menu 2).
4. Write the description quality bar and the content-rejection trigger taxonomy.
5. Design the category taxonomy (menu 4).
6. Set the localization posture (menu 5).
7. Write the badge display rules (menu 6).
8. Write the decay-enforcement policy (menu 7).
9. Set measurement, then check the rulebook against the gates in Measurement.

Draft the rulebook section by section in that order, validating each with the user before the next:

• A wrong strictness rung caught at step 2 is cheap.
• The same rung discovered at step 8 rewrites every spec between.

1. Field-spec strictness

How prescriptive the rulebook's field requirements are. Four rungs, ranked. Efficiency here means consistent rejections bought per hour of rulebook authoring and maintenance:

• effort, authoring plus tooling (descending): completion-tracked builder > exact per-field limits > named rejection triggers > principles-only

• rejection consistency bought: exact per-field limits > named rejection triggers > completion-tracked builder > principles-only

• efficiency: named rejection triggers > exact per-field limits > completion-tracked builder > principles-only

• Default rung: named rejection triggers, plus exact limits on the load-bearing fields only - name, hook string, body, media geometry get numeric caps; everything else gets an enumerated list of violations (misleading or out-of-date metadata, keyword spam defined numerically, unattributed testimonials - the pattern of the most explicitly enumerated benchmarked policy). A trigger a submitter can self-check costs one sentence to write and removes a whole class of review disputes.

• Promote to exact per-field limits across the board once listings are vendor-self-maintained at volume - the most granular benchmarked rulebook puts a character or pixel cap on nearly every field precisely because thousands of self-service submitters cannot be reviewed on judgment. Consistency then depends on the spec, not on which reviewer reads it.

• Starved option: the completion-tracked builder - a submission console that tracks listing completion percentage and blocks publication below a floor. Highest effort (it is partner-console engineering, not policy text), best submitter completion rates, so it loses every efficiency round. Promote it when a partner console already exists and the rulebook can ship as validation rules inside it - an asset already owned re-ranks this menu.

• Deleted, not demoted: principles-only rules ("listings should demonstrate value and trust") once more than one person reviews content. Two reviewers reading the same principles reject different listings, and the gap surfaces as appeal noise. Not parked at the bottom, because "we'll use judgment" silently reappears as scope every time writing a real trigger feels like work.

This ranking is a default, not a law - and so is every menu below. Re-rank each against the interview: question 2 moves this menu, question 4 moves menu 2 and the quality bar, question 5 moves menu 7, question 7 moves menu 6 - and against assets the team already owns (an existing partner console, an existing localization pipeline, an in-house editorial function). Say which answer moved which rung.

2. Media specs

The single most important fact from the benchmarks: there is no industry-standard screenshot geometry. The eight operators ship 16:9, 8:5, and roughly 3:2 in production, and two skip pixel rules entirely (references/marketplace-listing-benchmarks.md). Never borrow one vendor's numbers as an industry constant - pick one geometry for your marketplace, publish it, and hold every submission to it. Three enforcement postures, ranked:

• effort (descending): ranking-penalized optional assets > fixed-geometry hard spec > content-correctness-first

• browse-surface quality bought: fixed-geometry hard spec > ranking-penalized optional assets > content-correctness-first

• efficiency: fixed-geometry hard spec > content-correctness-first > ranking-penalized optional assets

• Default rung: fixed-geometry hard spec plus content rules - one published ratio and count per asset type, and content requirements that matter more than pixels: at least one screenshot of the actual app UI, no PII, no pricing or review claims baked into the image, a quality floor (an off-topic, distorted, or wrong-ratio image is a named rejection trigger, stated as directly as the strictest benchmarked policy states it).

• Content-correctness-first - live URLs and truthful imagery policed, pixels not - is the right posture only while the operator's team maintains listings itself (question 2); it survives at scale in exactly the benchmarked marketplaces whose review process verifies every URL with a crawler.

• Starved option: the ranking-penalty lever - an optional asset that publishes without penalty of rejection but ranks below listings that provide it (one benchmarked operator does this for a promotional tile). It requires ranked search infrastructure to exist, so it loses every efficiency round; promote it when ranking already exists and an asset should be encouraged rather than required - and disclose the penalty in the published policy, as the operator that invented it does.

• Video ceiling (set deliberately from question 4): 30-second function-proof with marketing footage banned at the diligence end, 2-3 minutes with promotional tone allowed at the self-serve end, captions required either way.

• Accessibility floor (adopt voluntarily): descriptive alt text on informative images, captioned video, contrast and legibility minimums per WCAG 2.2 AA.

Only one of the eight benchmarked operators mandates listing-content accessibility, which makes it a cheap differentiator while adoption stays rare, and future-proofing against tightening accessibility law (references/decay-and-badge-programs.md).

3. Description quality bar and rejection triggers

Two independent benchmarked operators - a commerce platform and a dev-tools platform - arrived at the same description rule separately, which is strong enough evidence to adopt as the default: lead with the customer outcome, not the feature's technical mechanism, and connect each feature claim to a measurable result. The worked accept/reject pair lives in references/marketplace-listing-benchmarks.md.

Write the rejection triggers so a submitter can self-assess every one:

• Keyword spam, defined numerically - unnatural repetition of a term past a stated count, or lists of brands/regions with no added value; never just "don't stuff keywords".
• Unattributed or anonymous testimonials, and unsubstantiated outcome guarantees.
• Trademark naming order - "Task Tracker for {YourPlatform}" is the accepted shape; "{YourPlatform} Task Tracker" is rejected. Three benchmarked operators enforce this independently with near-identical worked examples; adopt the rule and publish your own pair.
• Misrepresentation - the listing must describe what the app actually does; undisclosed third-party account dependencies and their cost are a content violation.
• Off-listing trust surfaces as hard gates: a publicly accessible landing page (a PDF or code repository is explicitly not one), a support channel with a stated response commitment, and a privacy policy meeting a minimum-coverage checklist - approval-gating regardless of how good the marketing copy is.

4. Category taxonomy

Every benchmarked taxonomy that works has some cap or curation mechanism; the design question is which. Three shapes, ranked. Efficiency here means discoverability bought per unit of standing operator effort:

• standing operator effort (descending): operator-curated layers > category plus structured tags > fixed capped list

• discovery value bought: operator-curated layers > category plus structured tags > fixed capped list

• efficiency: fixed capped list > category plus structured tags > operator-curated layers

• Default rung: a small fixed cross-functional category list with a hard per-listing cap of one or two (the benchmarked spectrum runs from one category plus two industries to two of ten), enforced by a staleness downgrade rather than delisting: a listing whose categorization drifts from the app gets marked uncategorized and drops off every browse surface - soft, self-correcting, automatable.

• Promote to structured tags on top of categories (per-category feature tags plus a handful of search terms, each capped and one-idea-per-term) once search overtakes browsing as the discovery path - the tag caps are what keep search results meaningful.

• Starved option: operator-curated layers - editorial collections, "works with" labels, persona groupings assigned by the operator and never purchasable. Highest discovery value and a standing editorial cost every cycle, so it loses every efficiency round; promote it on a compounding mandate (question 9) once the catalog outgrows browsing, and keep placement unpurchasable - the moment curation is sellable it stops being a discovery signal and becomes inventory, which is the launch-marketing skill's territory.

• Deleted, not demoted: uncapped self-selection. An uncapped multi-select taxonomy degenerates into every listing claiming every plausible tag until categories stop meaning anything. Not parked at the bottom, because "let vendors pick more categories later" silently reappears every time a partner asks for broader placement.

5. Localization posture

Rank by market reach bought per unit of combined operator-plus-vendor effort:

• effort, setup plus per-listing (descending): `all-or-nothing declaration > aut

...