Ratings Mechanics

rshankras/claude-code-apple-skills/skills/app-store/ratings-mechanics

作者 rshankras9ffb83138209無授權條款784 個星標收錄於 2026年10月9日更新於 2026年10月9日儲存庫2 個月前更新

How App Store ratings actually behave — per-storefront isolation (your US stars show nowhere else), the never-reset rule, phased release + manual release as rating protection, and where prompting/replying fit. Use when planning ratings strategy for new markets, considering a ratings reset, setting release options, or diagnosing "why is my rating missing in country X."

僅含說明Marketing & Sales
AI 產生的概覽

說明 App Store 評分機制——各店面獨立、不可重置規則、分階段與手動發布、提示與回覆策略。

功能
這個技能說明四條 App Store 評分規則:評分依店面各自獨立,評分摘要不應重置,分階段加手動發布可限制問題版本的損害,提示與回覆是開發者唯一能控制的評分輸入。它也定義了稽核輸出格式,依店面報告評分、未回覆的負面評論、提示在地化情況和發布習慣。它是策略層,提示程式碼和回覆撰寫分別指向其他技能。
適用情境
適用於為新市場規劃評分策略、考慮重置評分、提交前選擇發布選項,或排查某個國家/地區評分缺失的原因。
執行需求
沒有指令碼,僅為說明性內容。它引用其他技能和 Apple 開發者文件連結,但除代理外不需要任何工具、套件、憑證或網路存取。

Ratings Mechanics

The rating is an asset with mechanics most developers learn the hard way. This skill covers the four rules that aren't obvious from the ASC UI. Prompting code lives in generators/review-prompt; reply writing lives in app-store/review-response-writer — this skill is the strategy layer that tells you when each matters.

When This Skill Activates

  • Localizing or expanding into new storefronts ("why does my app show no rating in Japan?")
  • Considering the "reset ratings summary" option on a version release
  • Choosing release options before submitting (phased vs immediate, auto vs manual)
  • Planning a per-market ratings strategy alongside product/localization-strategy
  • A bad build or review-bomb is threatening the rating

Rule 1: Ratings are per-storefront — they do not travel

Your 4.8★ from 2,000 US ratings renders as no rating at all on the Japanese storefront until Japanese users rate the app there. Every storefront starts from zero.

Consequences:

  • ✅ Entering a new market = re-running the early-days ratings playbook in that market: prompt eagerly (within guidelines), localize the prompt moment, reply to every early review.
  • ✅ Weight requestReview triggers by storefront maturity — a market with 12 ratings needs the prompt more than the home market with 5,000.
  • ❌ Assuming social proof transfers with the binary. A localized listing with zero local ratings converts like an unknown app, because there it is one.
  • The written-review pool is also per-storefront: expect empty review sections in fresh markets and seed them via TestFlight communities or launch outreach in that region.

Rule 2: Never reset the ratings summary

ASC offers a reset when you release a new version. It is almost always a mistake:

  • Reset discards the count as well as the average — 4.2★ from 3,000 ratings converts better than a naked 5.0★ from 6, and the count never comes back except one rating at a time.
  • The instinct to reset ("v2 is a big rewrite, old reviews don't apply") is better served by replying to outdated negative reviews (updated ratings replace the old score — see review-response-writer) and by the What's New copy.
  • ✅ Legitimate near-exception: a catastrophic launch (sub-3★, low count, fixed root cause) on an app with almost no ratings mass. Even then, run the math on count loss first.
  • ❌ Resetting an established app to chase a higher average. You'll rank and convert worse for months.

Rule 3: Phased release + manual release are rating armor

Two ASC toggles turn a bad build from a rating catastrophe into a contained incident:

  • Manual version release — approval ≠ release. Release when you're awake and watching crash dashboards, not whenever review finishes.
  • Phased release — 7-day staged rollout (1% → 2% → 5% → 10% → 20% → 50% → 100%) to users with automatic updates. A crashing build caught on day 1–2 has burned ~3% of your users; pause the rollout, fix, resubmit. Without it, 100% of users get the bad build and the 1-star flood arrives before the hotfix does.
  • ✅ Default for every release: phased ON + manual release + monitor day-1 crash rate.
  • ❌ Halting a phased release as a rollback. Pausing stops new deliveries only — users who got the build keep it, and manual App Store downloads always get the new version. The armor is damage limitation; the fix still has to ship.

Rule 4: The prompt-and-reply loop is the only rating input you control

  • Prompt at success moments with requestReview — never at launch, never mid-task. Aim the moment, cap the frequency, and localize what "success" means per market. Implementation: generators/review-prompt.
  • Reply to negative reviews — when a user updates their review after a reply, the new score replaces the old one in the average. Replies are the only mechanism that converts existing 1-stars into 4-stars. Templates: app-store/review-response-writer.
  • Per-storefront corollary: track "unanswered negative reviews" per market, not globally — a 5-review storefront is one bad review away from 60% negative.

Output Format

When auditing an app's ratings posture, report per storefront:

Storefront | Rating (count) | Unanswered 1–3★ (90d) | Prompt localized? | Phased+manual habit?

flagging: fresh storefronts with no prompting plan, any reset consideration (🔴 stop), and releases going out unphased.

References

來源與署名

來源:rshankras/claude-code-apple-skills位於skills/app-store/ratings-mechanics提交9ffb831

授權條款: 無授權條款

內容歸原作者所有。SourceWeft 從公開儲存庫中收錄這些內容。

檢舉或申請下架