What an ASO Service Should Deliver (and When You Do Not Need One)

An App Store Optimization service should improve two connected outcomes: qualified discovery and conversion from store visitor to installer or pre-order. It should also leave the product team with a documented system for making the next decision.

That is more substantial than a list of keywords and a rewritten description. Apple App Store and Google Play expose different metadata, testing, localisation and custom-page capabilities. The work needs product evidence, design, analytics and release coordination. No provider controls organic rank, category demand, store editorial decisions or the app's quality signals, so a guaranteed position is not a credible deliverable.

A well-scoped ASO engagement promises research, decisions, approved assets, experiments and learning. This guide explains what those outputs should look like and when an ongoing service is unnecessary or premature.

TL;DR

• ASO has two primary jobs: increase relevant store visibility and improve conversion after someone sees the listing.
• Apple and Google Play require separate strategies. Their fields, search systems, experiments and custom pages are not interchangeable.
• Month one should produce a baseline, market research, metadata map, creative hypotheses, measurement plan and prioritised roadmap—not just “optimised copy”.
• Apple Product Page Optimization runs native tests on the default product page; Custom Product Pages tailor destinations and can now appear for assigned search keywords. They serve different jobs.
• Google Play Store Listing Experiments test listing assets; Custom Store Listings tailor content by country, URL, ad traffic, search keyword and eligible user segment.
• Ratings work means compliant prompt timing, support feedback and review analysis. It does not mean buying, gating or incentivising positive reviews.
• Foundational ASO is useful before launch. A monthly retainer may be premature when the app is not ready, measurement is absent, traffic cannot support tests or nobody can implement the findings.
• Judge providers on artefacts, experiment quality, store knowledge and connection to product economics—not a ranking guarantee.

What ASO includes—and what it does not

ASO covers:

• search and category discovery research;
• store-specific metadata strategy;
• icon, screenshot, preview-video and feature-graphic strategy;
• product-page conversion analysis and experiments;
• localisation by language and market;
• ratings and review operations within store policies;
• custom product or store listings for relevant audiences;
• release, in-app event and promotional-content coordination where in scope;
• measurement of visibility, conversion, quality and downstream value.

It cannot repair weak onboarding, crashes, poor retention, an uncompetitive price or a product that does not solve a meaningful problem. Those product outcomes influence reviews, word of mouth, paid efficiency and potentially discovery. A competent ASO provider surfaces the dependency instead of presenting metadata as the cure.

ASO is also not the same as paid app acquisition. Apple Ads and Google App campaigns can create traffic and data, while store optimisation determines how relevant visitors understand the product. They should exchange insights, but paid placement must not be reported as organic ranking success.

Apple App Store and Google Play need separate work

Apple's keyword field is limited to 100 characters. Its app name and subtitle have separate 30-character limits. Google Play currently allows up to 30 characters for the app name, 80 for the short description and 4,000 for the full description.

Character capacity is not a target to fill mechanically. Copy must remain accurate, readable, policy-compliant and differentiated. Repeating broad terms or adding unnatural strings can make the listing less persuasive and introduce review risk.

Apple now also generates app tags using large language models based on App Store Connect metadata. This reinforces the value of clear, accurate descriptions of the app's essential qualities. It does not justify keyword stuffing for an AI system.

For a deeper explanation of the store differences, read how App Store Optimization differs from SEO.

Deliverable 1: baseline and measurement specification

Before changing the listing, the provider should document the starting point by store, market, device and traffic source where data is available.

The baseline can include:

• impressions and product-page views;
• search, browse, referral and paid acquisition sources;
• first-time downloads or installs;
• product-page conversion rate under the store's definition;
• target-query visibility and rank observations;
• ratings volume, distribution and themes;
• listing version, localisations and asset order;
• acquisition cost and downstream activation, retention or revenue by source;
• release history and known seasonality.

Ranking trackers are directional. Results can vary by country, device, account and store changes. Record the method and avoid reporting a single personalised search result as market-wide rank.

Agree the primary outcome. A finance app may value funded accounts, not installs. A game may care about retained payers. A subscription app may prioritise trial-to-paid conversion. Store conversion is a leading indicator; quality after install decides whether the growth is valuable.

The deliverable should include a metric dictionary, data sources, owners, attribution limitations and an evaluation cadence.

Deliverable 2: market, audience and query research

A useful research pack connects language to product capability and customer intent.

It should contain:

• audience problems and use cases;
• category and subcategory language;
• query themes by intent, not just estimated popularity;
• existing visibility and terms where the app is credible;
• competitor positioning and asset patterns;
• review-language analysis for this app and the category;
• paid search terms, where available;
• market-specific vocabulary and cultural context;
• product features and claims that can be substantiated;
• opportunities deliberately rejected, with reasons.

Keyword tools estimate demand and competition; they do not reveal strategic relevance by themselves. A lower-volume phrase describing the app accurately can outperform a popular generic term that attracts people expecting a different product.

Paid search data is valuable because it links queries to taps, installs and sometimes downstream events. It is not the only or automatically “best” research source. New use cases, organic discovery and competitor language may not appear in a limited campaign. Combine store, paid, product and customer evidence.

Deliverable 3: a metadata map for each store and localisation

The metadata output should not be one text document copied into both consoles. Expect a version-controlled map showing:

• current and proposed field values;
• character counts and policy checks;
• primary query or positioning purpose of each field;
• duplication deliberately avoided;
• claim evidence and product owner approval;
• localisation source and reviewer;
• submission dependency and target release;
• hypothesis and evaluation date.

For Apple, allocate app name, subtitle, keywords, primary category and relevant descriptive metadata intentionally. Apple advises against repeating words already used in app name, subtitle or category in the keyword field.

For Google Play, write a clear app name, short description and full description for humans while expressing product relevance comprehensively. Do not assume that repeating a phrase more frequently will improve visibility. Google Play policies restrict misleading metadata and promotional or ranking claims in certain listing elements.

Descriptions must match the actual app. A provider needs access to current product behaviour, roadmap and compliance constraints; otherwise it can create attractive claims the product cannot support.

Deliverable 4: creative strategy and production-ready assets

Most visitors do not read every word. The icon and first visible screenshots often carry the first positioning decision.

A useful creative package includes:

• an audit of the icon and current screenshot sequence;
• messaging hierarchy for the first frames;
• storyboard or wireframes with device and language considerations;
• feature-to-benefit mapping backed by real UI;
• asset variants linked to explicit hypotheses;
• source files and export specifications;
• accessibility and legibility checks;
• review-ready assets for each required device class;
• a plan for preview video or Google Play video when evidence supports it.

Screenshots should show a truthful experience. Decorative lifestyle imagery can provide context, but it should not obscure what the app does. Claims, awards, rankings and prices need to be current and permitted.

Localisation may require new layouts because text expands and reading order changes. “Translate the caption and shrink the font” is not localisation quality.

Deliverable 5: a valid experimentation programme

Apple Product Page Optimization

Apple lets eligible iOS and iPadOS apps test up to three treatments against the original product page. Treatments can vary app icons, screenshots and app previews. Tests can run for up to 90 days, and App Analytics reports estimated conversion lift and confidence.

Important operational constraints include:

• only one Product Page Optimization test runs at a time under Apple's standard flow;
• alternate icons need to be included in the app binary;
• new assets may need App Review;
• releasing a new version can affect a live test;
• Product Page Optimization is not available for Custom Product Pages;
• changing several elements in one treatment makes causal learning harder.

Google Play Store Listing Experiments

Google Play provides native experiments for supported listing elements and localisations. The plan should document the control, treatment, audience, primary metric, expected effect, traffic allocation, stopping rule and what happens after the result.

Do not promise “one change at a time” as an inflexible law. A single-variable test is easier to interpret; a complete concept test can answer whether a new positioning system works. Label the question correctly and accept that a multi-element winner does not reveal which component caused the effect.

Experiment quality

A competent service should:

• prioritise a business question, not random visual preference;
• estimate whether available traffic can reach a useful conclusion;
• avoid overlapping changes that contaminate the result;
• account for paid campaigns, features and seasonality;
• wait for the platform's evidence rather than stopping at an early lead;
• preserve losing as well as winning learnings;
• monitor downstream activation or value when possible.

A store-conversion winner can attract lower-quality users. Check whether the test changed activation, retention or payer quality before rolling the idea across all markets.

Deliverable 6: Custom Product Pages and Custom Store Listings

Custom pages match the listing experience to a use case, search theme, audience or campaign. They are not automatically A/B tests.

Apple Custom Product Pages

Apple currently supports up to 70 additional product pages for eligible iPhone and iPad apps. Pages can vary screenshots, app previews and promotional text, use a unique URL, connect to Apple Ads and—when configured—appear for assigned App Store search keywords. Supported versions can also use deep links to take an installed-app user to relevant content.

The deliverable should map each page to a distinct audience or intent, approved assets, keywords, destination, campaign and measurement view.

Google Play Custom Store Listings

Google Play currently supports up to 50 custom listings and can tailor them by supported country, URL, ad traffic, search keyword or user-state segment. Each can vary elements such as app name, icon, descriptions and graphic assets, subject to shared fields and platform rules.

Availability and reporting thresholds can change. The provider should confirm whether the intended Google Ads format actually routes to the selected custom listing rather than assuming all app-campaign inventory does.

Use custom pages where the app genuinely offers distinct value. Creating dozens without sufficient traffic, maintenance ownership or meaningful differentiation adds operational debt.

Deliverable 7: localisation, not literal translation

For each priority market, the service should research:

• local query vocabulary;
• product and category conventions;
• cultural interpretation of visuals and claims;
• device and payment context;
• regulatory or store-policy requirements;
• language variants and fallback behaviour;
• local rating and review themes.

Use native or qualified market review. Machine translation can accelerate a draft but should not be the final quality check for high-value listings.

Prioritise markets by commercial opportunity, current traffic and operational readiness. Ten well-maintained localisations can be more valuable than fifty stale translations.

Deliverable 8: ratings and review operations

A ratings strategy should specify:

• an appropriate in-app moment for a neutral rating request;
• prompt frequency and platform API constraints;
• support routes for users who need help;
• response ownership and tone;
• thematic analysis and escalation to product teams;
• release-level monitoring for sudden negative changes;
• policy safeguards.

It must not offer incentives, buy reviews, create fake reviews, gate the prompt so only happy users can rate or pressure users to change a rating. Google Play explicitly prohibits manipulating ratings, reviews and install counts. Apple also applies review and manipulation policies that the implementation must follow.

The provider should report review themes and response time—not take credit for a ratings increase caused by filtering who is allowed to respond.

Deliverable 9: reporting that separates discovery from conversion

A monthly report should answer:

1. What was changed and when?
2. Did relevant visibility change?
3. Did store-page conversion change?
4. Did the source or market mix change?
5. Did downstream user quality change?
6. What did an experiment establish?
7. What will happen next, and why?

Useful layers include:

• search and browse impressions;
• product-page views by source;
• first-time downloads or installs;
• conversion rate by store, market and page;
• target-query visibility with method notes;
• custom-page traffic and conversion;
• ratings distribution and review themes;
• activation, retention, paid conversion and customer value where available;
• paid and organic interaction without claiming perfect incrementality.

Do not attribute all install growth to ASO. Product launches, featuring, paid media, seasonality, brand activity and competitor changes can move the same metrics. Use native experiments when possible and mark other conclusions as observational.

What the first 90 days can deliver

Weeks 1–3: baseline and strategy

• access and data-quality audit;
• store, market and product baseline;
• audience and query research;
• metadata and localisation map;
• creative audit and prioritised hypotheses;
• experiment feasibility and measurement plan.

Weeks 3–6: production and submission

• store-specific metadata approved by product and compliance;
• creative concepts and source files;
• first priority localisations;
• console submissions and review coordination;
• ratings and review operating process;
• custom-page plan where relevant.

Weeks 6–12: experiments and learning

• launch an experiment when traffic and release timing support it;
• monitor visibility and conversion without declaring early winners;
• assess downstream quality;
• apply or reject evidence-backed treatments;
• document learning and prepare the next iteration.

Store review, release calendars and traffic can extend this sequence. A serious provider should set dependencies and ranges rather than promise a universal day on which rankings will rise.

When you do not need an ongoing ASO service

Every published app needs an accurate, policy-compliant store listing. That does not mean every team needs an agency retainer.

The app or measurement is not ready

If onboarding is broken, crashes are severe, key events are missing or the commercial outcome is undefined, prioritise product and measurement repair. Complete foundational listing work, but do not pay for a sophisticated experiment programme that cannot judge user quality.

There is insufficient traffic for the proposed testing cadence

Low traffic does not make metadata irrelevant. It makes frequent native A/B tests difficult to conclude. A focused research and setup project may be better than a monthly programme promising a new “winner” every few weeks.

Nobody can implement the work

If design, development, localisation, legal review and release ownership are unavailable, a recurring strategy deck creates backlog rather than growth. Buy a scoped audit or wait until execution capacity exists.

The listing is healthy and another constraint is proven

If relevant discovery and store conversion are strong but paid acquisition, country availability, pricing, onboarding or retention is the documented bottleneck, fund that constraint first. Recheck the listing after meaningful product or market changes.

The portfolio is stable and can be maintained in-house

A team with strong research, design, analytics and release processes may need only periodic specialist review, not outsourced monthly execution.

How to evaluate an ASO provider

Ask for concrete answers:

Warning signs include guaranteed rankings, secret methods, paid installs presented as organic performance, incentivised review tactics, one listing copied across stores, no need for product-team input and reports containing rank screenshots without business outcomes.

Pricing and scope models

Foundation project

Suitable before launch or when the listing has never received structured work. Define markets, stores, research, metadata, creative direction, implementation support and measurement setup.

Experiment or creative sprint

Suitable when traffic exists and the question is specific. Scope hypotheses, asset production, console setup, monitoring, interpretation and application of the result.

Ongoing programme

Suitable for active products with frequent releases, multiple markets, enough traffic and owners able to act. The retainer should specify a cadence and tangible capacity—not “continuous optimisation” without limits.

Portfolio or localisation programme

Suitable for publishers managing several apps or countries. Pricing should reflect the number of stores, apps, localisations, custom pages and creative outputs.

Avoid compensation based solely on a promised rank. It encourages selection of easy, low-value queries and makes the provider responsible for an outcome the stores control. Performance components, if used, should rely on agreed business measures, baselines and attribution limitations.

The Space Ads operating approach

When ASO connects with app acquisition, we use a shared evidence loop:

1. define post-install value and priority markets;
2. audit store conversion, paid search terms and downstream cohorts;
3. separate Apple and Google Play metadata and creative decisions;
4. map campaign messages to relevant custom pages where supported;
5. design store experiments around a real decision;
6. feed review themes and conversion learnings back to product and creative;
7. judge scale on retained or paying users, not installs alone.

This is an industry-practice framework adapted to the app's category, data and release process. Our related acquisition guidance is in the Apple Ads guide.

FAQ

What should an ASO service include?

It should include a baseline, audience and query research, store-specific metadata, creative strategy and assets, localisations, experiment design and operation, compliant ratings and review processes, custom-page strategy, reporting and a prioritised roadmap.

Can an ASO agency guarantee rankings?

No credible provider can control organic placement. Apple and Google use multiple signals and continuously change search experiences. A provider can guarantee agreed work, quality controls and experiments—not a fixed position.

How long does ASO take?

Production and metadata changes can be delivered in weeks, subject to access and store review. Measuring their effect depends on traffic, release timing, seasonality and effect size. Low-volume apps may need longer observation and fewer experiments.

Does a new app need ASO before it has installs?

Yes, it needs a clear, accurate and discoverable listing before launch. What may be premature is a high-cadence monthly testing programme when there is too little traffic or no measurement and execution capacity.

Are Apple Custom Product Pages A/B tests?

No. They tailor product-page content to specific audiences, links, ads or assigned search keywords. Apple's native A/B capability for the default page is Product Page Optimization. Measure custom pages against their intended traffic, but do not confuse observational differences with randomised tests.

How should ASO success be measured?

Separate relevant visibility, product-page conversion and post-install quality. Track store and market changes, document paid and seasonal confounders, use native experiments where available and connect installs to activation, retention or revenue.

Can ASO be done in-house?

Yes. A capable product-growth team can own research, metadata, creative, experiments and releases. External support is most useful where the organisation lacks store-specific expertise, localisation capacity, creative testing discipline or independent diagnosis.

Key takeaways

• ASO should improve qualified discovery and store conversion while protecting post-install quality.
• Apple and Google Play require separate metadata, testing and custom-page plans.
• Demand tangible artefacts, source files, experiment rules and decision-ready reporting.
• Foundational ASO is important for new apps; an ongoing retainer depends on traffic and execution readiness.
• Custom pages tailor experiences, while native store experiments establish causal conversion evidence.
• Ratings strategies must earn and learn from genuine feedback, never manipulate it.
• Provider value is measured through disciplined work and business learning—not guaranteed positions.

Explore the broader relationship between app-store work and App Store Optimization, or see how Space Ads approaches search visibility on our AI SEO page.

Sources and further reading

• App Store search and discoverability — Apple Developer
• Product Page Optimization — Apple Developer
• Custom Product Pages — Apple Developer
• Create a Google Play store listing — Play Console Help
• Custom Store Listings — Play Console Help
• User ratings, reviews and installs policy — Play Console Help
• App Store Optimization: how it differs from SEO
• Apple Ads complete guide