ASO templates.
Make the next change count.
An app store audit, keyword research spreadsheet, screenshot experiment brief, tag review worksheet, custom listing launch record and localization checklist. Download editable files with worked examples for independent iOS and Android app owners.
From one finding to one useful change
- Audit one listing and locale. Record the promise and the evidence behind it.
- Use the keyword sheet to connect candidate terms with supported tasks.
- Prepare one experiment in the store console when you have a suitable hypothesis.
- Review the product journey and localized wording before applying the change.
The kit is free to copy and adapt, including for commercial team projects. Attribution is optional. Its examples are fictional teaching cases. There are no supplied search-volume figures, ranking scores or promised conversion lifts.
App Store tag review worksheet
Keep an observed tag, visitor expectation, supported action and saved console decision in one editable record.
Use one row per label and review context. Start with a label you actually observed or a clearly marked teaching example. Keep the public observation separate from the assigned console selection and save the baseline before proposing a change.
Write the visitor's expectation and the product action that supports it. Mark keep, investigate or consider deselecting with a reason. Record the actual console decision and later observation separately; leave traffic attribution blank when the available report does not isolate it.
Worked example
Fictional example: Quiet Routine offers a bedtime checklist timer. A reviewer interprets the example label Sleep as sleep tracking, which the app does not support. The row remains investigate until the owner reviews the actual console selection and listing promise. This is a teaching case, not an assigned tag or measured customer result.
Preview and copy the full template
"app","storefront","metadata_locale","build_or_version","observed_on","tag_label","label_source","original_console_selection","visitor_expectation","supported_action","observed_gap","proposed_decision","reason","owner_role","saved_console_decision","saved_on","public_follow_up","report_source_period_filters","attribution_gap","next_review" "[app]","[storefront]","[locale]","[version]","[date]","[observed label]","[public observation / console / teaching example]","[original selection]","[neutral paraphrase]","[observed task]","[finding / none observed]","[keep / investigate / consider deselecting]","[evidence]","[role]","[pending / actual selection]","","[pending / observation and context]","","[unknown / report limitation]","[condition and owner]"
Custom store listing launch record
Map one audience to a supported feature, published listing, checked destination and report scope for Google Play or App Store custom pages.
Keep one record per page and locale. Write the customer task before changing assets, then connect the promise to an available product action. Save the default listing and the exact custom version so a future teammate can see what changed and repeat the launch check.
Use the platform's own setup and reporting definitions. A custom page sent to a different audience is not automatically a randomized asset test. Record approval, visibility, the exact public URL and the advertised first action separately; a saved draft does not prove that customers can see or use it.
Worked example
Fictional example: Trail Ledger plans a page about its offline walk journal. The record excludes live navigation because that feature is unavailable, preserves the reviewed caption and records a test of finding the saved entry after reopening. Its report status remains pending until matching store data is available.
Preview and copy the full template
CUSTOM LISTING LAUNCH RECORD — ONE AUDIENCE, ONE LOCALE Store / app / package or app identifier: [public product details] Page or listing reference name: [stable console name] Owner / review date / build: [responsible role and version] Target customer task: [one outcome the released app supports] Audience route: [selected search terms, exact URL or other console option] Reason for a custom version: [difference from the default audience or story] Default listing saved at: [safe file reference] INTENT AND PROMISE Candidate phrase and evidence source: [customer language or measured research] Selected console keyword or targeting setting: [exact configured selection] Variations / locale reviewed: [meaning and fit checked by a local reviewer] First screenshot promise: [what a fresh reader expects] Released feature supporting the promise: [build and observed action] Unsupported claims removed: [planned features or ambiguous wording] Pricing, account or permission boundary: [relevant condition] ASSETS AND LANGUAGE Listing name / secondary text / description: [reviewed draft reference] Screenshots and other assets: [filenames and locale] Language fit and field lengths: [checks and unresolved items] Product text in the same locale: [observed gaps and owner] Final approved files saved at: [safe team reference] PUBLICATION AND DESTINATION Approval / publication / visibility: [actual console state and checked date] Exact public custom listing URL: [copy the released URL] In-app destination when configured: [separate from the store page URL] Device / OS / account state used: [repeatable context] Observed listing and language: [assets shown, not assumed] Advertised task attempted: [harmless sample action] Observed result and mismatch: [completed, blocked or unexpected] Issue owner and retest condition: [next action] MEASUREMENT AND NEXT DECISION Report name and page identifier: [exact console scope] Period / locale / source / audience filters: [matching comparison context] Numerator, denominator and definition: [report labels and eligible counts] Completed acquisition or use evidence: [separate report, or unavailable] Concurrent product or acquisition changes: [potential confounding context] Conclusion: [supported observation, pending or inconclusive] Next decision and owner: [one action justified by the evidence] Use the store's actual approval and reporting workflow. This record organizes observations; it does not publish metadata, estimate demand, attribute an uplift or guarantee a ranking. Do not include account credentials, private customer details or identifiable analytics exports. Original template by RateMyApp, October 5, 2026. https://ratemyapp.io/resources/aso-templates/ Free to copy and adapt, including for commercial team projects. Attribution optional. Keep account credentials, customer information and unpublished business figures out of shared copies.
ASO audit template
Turn a listing review into a short queue of decisions, with evidence and a named owner for each change.
Start with one store and one locale. Save the listing as a visitor sees it, then write down the first promise the title and first screenshot make. An audit is useful when it identifies a specific mismatch: unclear task, unreadable visual, missing proof or an advertised action that the app does not deliver.
Record observations separately from guesses about their cause. An empty search report is missing evidence, not proof that a keyword has no demand. When you change the listing, preserve the old wording and the release date so a later review can distinguish a metadata edit from a product change.
Worked example
Fictional example: Pantry Note’s first screenshot says ‘Plan your week’, but opens on a saved-recipe grid. The audit records the mismatch and proposes showing the weekly planner first. Its status is ‘needs testing’, not ‘conversion improved’. The owner then checks whether a new person can actually create that plan in the current build.
Preview and copy the full template
ASO AUDIT — ONE STORE, ONE LOCALE App and listing URL: [public name and URL] Store / locale / storefront: [App Store or Google Play / language / market] Build or listing version: [exact version] Reviewed on: [date] Owner: [team role] Audience and supported task: [who needs the app and what they can do] Decision this audit should inform: [one change or research question] 1. LISTING PROMISE Title and secondary field as published: [exact wording] First screenshot promise: [what a visitor is likely to understand] Visible proof in that screenshot: [specific UI, output or workflow] Product capability that supports the claim: [build and observed action] Gap or ambiguity: [observable mismatch, or none observed] 2. DISCOVERY EVIDENCE Candidate terms and their source: [user language, store search, authorized tool] Metric source / locale / period: [source and definitions, or unavailable] Supported terms to investigate: [relevant tasks] Terms to exclude: [unsupported features, unrelated brands, misleading claims] Field checks: [length, repeated words and separator issues] 3. LISTING UNDERSTANDING Neutral question: [what do you think this app helps you do?] Observed answer: [quote with permission or anonymous summary] Expected action: [what the visitor expects after installation] Uncertainty: [what this small review cannot establish] 4. FIRST-USE CHECK Starting state / device / build: [context] Task attempted: [one outcome] Observed result: [completed, blocked or abandoned, with details] Mismatch with listing: [specific difference] 5. PRIORITIZED DECISION Finding: [observation] Proposed change: [one change] Why this change follows from the evidence: [reason] Owner / date / review condition: [role, date and criterion] Control listing saved at: [safe file reference] Follow-up result: [pending, inconclusive or documented outcome] Use the store's own experiment report for experiment conclusions. A private comprehension check explains an observation; it does not prove a ranking or conversion lift. Original template by RateMyApp, October 5, 2026. https://ratemyapp.io/resources/aso-templates/ Free to copy and adapt, including for commercial team projects. Attribution optional. Keep account credentials, customer information and unpublished business figures out of shared copies.
ASO keyword research spreadsheet
Keep candidate terms, audience intent, supported features and evidence in a portable spreadsheet instead of an invented keyword score.
Write one candidate phrase per row. Add the intended audience, the task the phrase describes and the exact feature that fulfils it. Choose keep, investigate or exclude before trying to fit terms into a store field. This prevents a broad phrase from looking attractive while referring to an action your app cannot perform.
Leave demand and difficulty blank when you have no measured source. If a licensed tool supplies figures, preserve its name, date, locale and metric definition. A phrase collected from a customer conversation is useful language evidence, but it is not a monthly search-volume estimate. Check the resulting App Store field with the free metadata checker after making the editorial decision.
Worked example
Fictional example: a card organizer supports ‘card collection’ through saved binders, while ‘card price alerts’ is excluded because notifications do not exist. ‘Trade cards’ remains an investigation item: interviews must establish whether users mean finding trading partners or simply recording a trade. No demand value is supplied by this template.
Preview and copy the full template
"candidate_phrase","store","locale","audience","user_task","supported_feature","language_evidence","demand_value_if_measured","metric_source_and_date","decision","proposed_field","owner","follow_up" "[candidate]","[store]","[locale]","[audience]","[task]","[observed feature]","[source]","","","[keep / investigate / exclude]","[field]","[role]","[next action]"
App store screenshot experiment brief
Prepare a control, a single hypothesis and a review rule before setting up the test in your store console.
Describe what changes and what stays the same. A first-screenshot experiment can compare a task-led headline with the current headline while retaining the same app UI, visual style and later screenshots. Record the reasoning before you see results. This makes it easier to explain what the test can and cannot tell the team.
Set eligibility, traffic, localization, timing and any confidence or detectable-effect settings in the store console. Copy those settings into the brief rather than choosing a universal number of days from this page. Preserve an inconclusive result when the provider report cannot support a decision. Qualitative feedback can help design the next variant, but it cannot replace randomized experiment evidence.
Worked example
Fictional example: the control headline is ‘All your recipes together’ and the variant is ‘Plan five dinners from saved recipes’. Only the first headline changes. The team expects clearer understanding of meal planning, but records the hypothesis as unproven. It will review the provider report, inspect the stated uncertainty and separately check whether the promised planning flow works.
Preview and copy the full template
ASO EXPERIMENT BRIEF App / store / listing version: [context] Audience / locale / storefront: [eligible visitors] Experiment owner: [role] Experiment identifier: [console reference] QUESTION AND HYPOTHESIS Problem observed: [evidence that motivated the test] Hypothesis: [one change may affect one defined outcome because...] Control: [exact existing asset and safe file reference] Variant: [exact proposed asset and safe file reference] Single intentional difference: [headline, screenshot order or another eligible asset] Assets and product behavior held constant: [list] Supported feature behind the claim: [observed build and action] CONSOLE SETUP Provider feature: [Apple product page optimization / Google Play listing experiment] Eligible assets and prerequisites checked: [current console guidance] Treatment or variant count: [actual setup] Traffic allocation and audience: [actual setup] Locale coverage: [actual setup] Metric and definition: [copy the provider definition] Confidence / detectable-effect settings if exposed: [actual setup] Estimated duration from console if available: [estimate, not a guarantee] Planned review and stopping rule: [criterion chosen before launch] Confounding changes to avoid or record: [release, price, campaign, seasonality] RESULT AND NEXT DECISION Report source and date: [export or safe screenshot reference] Control and variant outcomes: [provider values and definitions] Uncertainty / confidence as reported: [provider presentation] Interpretation: [supported result / needs more data / inconclusive] Decision: [keep control / apply treatment / investigate] Reason: [evidence supporting that choice] Post-change product check: [listing promise still matches first use] Next hypothesis: [if needed] A comprehension review is not an experiment result. Do not label a before-and-after difference as a causal lift without matching experiment evidence. Original template by RateMyApp, October 5, 2026. https://ratemyapp.io/resources/aso-templates/ Free to copy and adapt, including for commercial team projects. Attribution optional. Keep account credentials, customer information and unpublished business figures out of shared copies.
ASO localization review checklist
Review one locale for natural language, supported claims, visible screenshot text and a working first-use journey.
Choose a locale your team can support in the product as well as the listing. Ask a fluent reviewer to explain the promise in their own words, then test that promise in the localized app. Preserve a question or an unresolved term rather than hiding it behind a completed translation checkbox.
Use separate review fields for metadata, screenshots and first-use behavior. A good title translation does not prove that screenshot text fits or that permission messages and errors are understandable. Mark the decision as ready, revise or investigate, and keep the exact wording approved by the reviewer so a later release does not silently revert it.
Worked example
Fictional example: a habit app has translated its listing, but the first reminder screen still displays an English date format and a truncated button. The review keeps metadata approval separate from product readiness. The team fixes that screen before advertising a fully localized reminder journey, then retests the exact build with a fluent reviewer.
Preview and copy the full template
ASO LOCALIZATION REVIEW App / store / build: [exact context] Target language / locale / storefront: [one locale] Reviewer role: [fluent reviewer; no personal contact details needed] Review date: [date] Supported product languages: [current build] Primary audience task: [one outcome] LANGUAGE AND SEARCH INTENT Original promise: [source wording] Localized promise: [reviewed wording] Reviewer paraphrase: [what the wording communicates] Candidate search phrases and source: [natural language evidence] Unsupported, ambiguous or borrowed terms: [items to revise] Measured search demand, if available: [source, date and definition; otherwise unknown] LISTING CHECKS Title / subtitle or short description: [reviewed text and field check] Keyword field when applicable: [locale-specific reviewed terms] Screenshot captions: [visible text and approved wording] Text fit and legibility on a phone: [observations] Claims supported by localized app: [build and exact capability] Support and pricing information: [current public wording] FIRST-USE CHECKS Starting state / device / build: [context] Task attempted in this locale: [outcome] Permission and error messages observed: [wording and fit] Dates, numbers, layout or direction issues: [observations] Blocked or untranslated actions: [specific findings] RELEASE DECISION Metadata decision: [ready / revise / investigate] Product journey decision: [ready / revise / investigate] Unresolved items and owner: [next action] Approved text saved at: [safe file reference] Retest build / date / result: [follow-up] Local review can identify language and comprehension issues. It does not promise ranking, downloads or approval by a store. Original template by RateMyApp, October 5, 2026. https://ratemyapp.io/resources/aso-templates/ Free to copy and adapt, including for commercial team projects. Attribution optional. Keep account credentials, customer information and unpublished business figures out of shared copies.
What evidence belongs in the kit?
Use public listing text, your own authorized store reports and observations from an agreed test. Label each source and period. Keep a visitor’s interpretation separate from your explanation of why it happened. A handful of interviews can reveal confusing wording, but cannot establish population-level conversion or search demand.
Apple’s product page optimization guidance describes testing eligible page assets against the original. Google Play’s experiment guidance explains how to configure listing comparisons and interpret their reports. Check the current console for prerequisites, available assets and statistical settings before launching.
Apple product page optimization · Google Play listing experiments · Apple search guidance
Check the draft. Then test the promise.
Run the free metadata checker after editing your fields. If your listing promises a particular outcome, ask a fresh tester to attempt that journey and submit a private report. Positive feedback and public store reviews are never conditions for testing rewards.
Using the ASO kit
Are these ASO templates free?
Yes. Download and adapt the original files for your own app or commercial team project. No account, email address or attribution is required.
Do the keyword sheets include search volume?
No. Demand fields are intentionally blank. Add a measured value only when you can record its source, date, locale and definition. The worked example is fictional.
Can I use the CSV in a spreadsheet?
Yes. The keyword research and App Store tag review worksheets are UTF-8 CSV files with headers and editable placeholder rows. Import them into your spreadsheet and keep one candidate phrase or observed label per row.
Does a completed audit prove an ASO improvement?
No. An audit records observations and proposed actions. Use matching store-console evidence to assess experiment outcomes, and keep incomplete or inconclusive findings visible.
Published October 5, 2026 by the RateMyApp editorial team. These files support a practical ASO workflow; store eligibility and experiment conclusions need separate evidence. How we publish.