| Item | What to review | Where to keep the evidence |
|---|---|---|
| App tags | Review Apple’s assigned labels and displayed selections. | Tag worksheet: label, supported action and saved selection. |
| Keyword field | Choose relevant localized terms and check the serialized field. | Keyword research sheet and metadata checker. |
| Screenshot promise | Ask what the visible screen and caption lead a visitor to expect. | Exact asset, neutral question and observed product task. |
Where App Store tags come from and where they appear
Apple bases tags on submitted metadata, AI and human curation. They can appear in search results and on product pages, where a visitor can explore related apps through a tag. Its current guidance limits support and display to the United States and identifies en_US as the metadata source. Record that scope rather than assuming a tag check covers every storefront.
Start a review by saving the public page you observed, the storefront, the date and the app version. Keep an observation separate from a console setting: a saved selection alone does not document what a particular visitor saw. If the label is absent in your review, record ‘not observed’ with the context. Do not convert that absence into a claim that the app is excluded everywhere. A teammate should be able to repeat the same check without guessing which language, release or page you used.
How to edit App Store tags in App Store Connect
With an Account Holder, Admin, App Manager or Marketing role, select the app in Apps. Open App Information under General, find App Store Tags, then choose Edit. Review the selections and save the intended changes. The documented control lets owners deselect assigned tags; Apple cautions that deselecting all of them may affect discovery. This is not a workflow for submitting an arbitrary list of new labels.
Before saving, write down the existing selection and the reason for a proposed change. Prefer a concrete mismatch over ‘this other label might get more traffic’. If you cannot find the control, record your role and current screen before checking Apple’s latest help or asking the account owner. Do not change unrelated metadata merely to make a missing control appear. Our worksheet tracks the planned choice, the actual saved choice and the public follow-up as separate fields so an unfinished task cannot look complete.
App Store tags versus keywords: keep the review separate
Tags are not the comma-separated keyword field. Apple’s search guidance describes text relevance across listing metadata; its version reference allows up to 100 bytes in the keyword field. Editing that field and reviewing assigned tags are different console actions. The free metadata checker counts entered keyword text and flags mechanical issues; it cannot retrieve private tag settings or confirm what Apple will assign.
Use the same supported product task as a reference for both reviews. A phrase may be relevant to your app while still needing language and demand research before it belongs in a keyword draft. A displayed label may be broadly related but give a visitor a more specific expectation than the app fulfills. Keep those findings in different rows. Avoid adding a tag label repeatedly to descriptions in the hope of forcing an assignment. Write metadata for the product and audience, then review the actual outcome in the console.
Review a tag against an observable product action
For each observed label, write what a new visitor might expect and identify the exact action the current release supports. Record an account requirement, paid boundary or device limitation when it changes that expectation. A feature on the roadmap is not evidence for the released app. Choose keep, investigate or consider deselecting, and give the reason. Leave the decision unresolved when the available evidence is incomplete rather than treating an empty cell as approval.
Use a neutral comprehension question before explaining your intended meaning: ‘What would you expect this app to help you do?’ Then ask the person to attempt one safe task with sample data. Record the answer and the observed result separately. If the task works but the label suggests a different outcome, investigate the wording around it. If the task fails, inspect the product issue before polishing the listing. A few private reports can explain a mismatch; they cannot establish the label’s effect on population-level traffic.
Keep the saved selection and follow-up evidence together
Download the worksheet and keep one row per label and review context. Save the original selection, the reason for the proposed choice, the responsible role and the console action date. Add the later public observation without overwriting the baseline. When you assess discovery, preserve the exact report definition, filters and period. If a report does not isolate tag traffic, state that attribution gap. Do not relabel all search traffic as tag traffic to fill it.
Plan the follow-up before seeing the numbers. Record concurrent changes such as a release, campaign, price or screenshot update. A before-and-after difference does not isolate which change caused it. When the report is too early or lacks a useful breakdown, leave the measurement pending and review the next product question. RateMyApp’s private testing workflow can help collect task observations from participants, while your authorized store reports remain the evidence for measured discovery. Neither a completed worksheet nor a positive community score proves an ASO lift.
Working example
Fictional review: Quiet Routine offers a timer for a bedtime checklist. An owner uses Apple’s example label ‘Sleep’ to rehearse the review; this is not a claim that Apple assigned it to that app. A new person expects sleep tracking, but the release records no sleep data. The worksheet marks the interpretation mismatch as investigate, saves the original metadata and assigns a review of the actual console selection. The owner tests clearer listing wording and the checklist task, then records the saved selection and a later public observation separately. No traffic estimate or ranking outcome is entered. The example demonstrates the decision record, not a customer result or a recommended universal tag choice.
Your next steps
- Record the observed label, storefront, date and current release.
- Compare the visitor’s expectation with one supported product action.
- Review the actual assigned selections with an eligible console role.
- Preserve the saved choice and follow-up evidence without claiming unmeasured lift.
Questions about this guide
Can I create my own App Store tags?
Apple’s documented workflow reviews assigned tags and lets you deselect them. Do not treat it as a free-form label submission tool.
Are App Store tags the same as keywords?
No. Review tags in App Information and edit keyword metadata separately. A text checker cannot confirm your private tag settings.
Will changing tags improve my ASO?
That needs measurement. Record the change, report scope and concurrent edits; a completed review is not a ranking or download guarantee.
Is the tag review worksheet free?
Yes. Download the editable CSV and fictional example without an account. Fill it with your own observations and authorized console evidence.
Official sources
Sources checked October 5, 2026. Review the current provider documentation before acting on requirements.
Turn the next test into something useful.
Publish a focused brief on RateMyApp. Credits fund approved private reports; public store reviews are voluntary and unrewarded.
List your app for feedback