App store optimization looks like marketing work until a screenshot needs a rebuild, an attribution rule changes, or the only person with publishing access leaves. In a 15–30 person engineering organization, I would treat ASO as a maintained release surface, not a collection of campaigns. The constraint is not how many experiments the team can launch; it is how many it can still explain, verify, and retire six months later.
Every ASO change creates a future release obligation
A listing change does not end when Apple or Google accepts it, because the claim, image, localization, and measurement attached to that change can all become stale. A screenshot showing an old navigation path needs replacement after a UI release. A subtitle promising a feature needs another review if that feature moves behind a subscription. Someone must notice those changes, decide whether the listing still describes the app, and get the correction published.
The freelancer-scale argument, Skip the default ASO tool stack if youre a solo freelancer, is a useful challenge to unnecessary subscriptions, but a smaller stack does not remove the need to track what was published and who can change it. A tech lead can cut a vendor from the workflow more easily than they can reconstruct an undocumented experiment after its author leaves. That is why I would require a record for each live change before buying another keyword or attribution tool.
Make that record small enough to maintain. For each change, keep the store and locale, the previous and new assets, the hypothesis, the publishing account, the release or product feature it depends on, a review date, and an owner with a backup. Store links to the relevant App Store Connect or Google Play Console entries alongside the source files; an image in a design folder alone does not tell an on-call engineer which live listing uses it. A pull request can hold the discussion, but the final record should remain findable after the branch and campaign board disappear.
Scope is a maintenance control, not a lack of ambition. Start with 2 locales as a provisional cap for active experiments, then revise it when the team has evidence of how long reviews and corrections take. That figure is a starting value to tune, not a platform limit. Give live assets an initial 14-day review interval during a product redesign; lengthen it if the product and listings remain stable. The useful question is not whether the calendar was followed perfectly, but whether it exposed stale claims before users or support did.
Ownership also needs to survive ordinary staffing changes. If marketing owns the copy and engineering owns the release, neither can safely approve a screenshot that depicts an unfinished feature alone. Name one person who can publish, one who can verify product accuracy, and a backup for each; otherwise an urgent correction can sit between teams while everyone assumes someone else has access.
Manual publishing wins until repetition becomes the larger risk
Manual publishing in App Store Connect and Google Play Console wins when changes are infrequent and the team wants a human to inspect each localized asset before submission. Its cost is repeated hand entry, access management in two consoles, and a weaker audit trail unless the team records what changed. Automated publishing with fastlane—using deliver for Apple metadata and supply for Google Play—wins when the same reviewed assets must be published repeatedly across locales. Its cost is code and credential maintenance, plus the possibility that a bad template distributes an error consistently.
I would not automate store metadata on the first ASO push, because a team that has not settled its asset naming, approval, and rollback process will encode those ambiguities into a script. Start with a checked-in manifest and manual submission. Move to fastlane only after repeated submissions show which steps are genuinely identical. A practical trigger to test, rather than a universal threshold, is 90 minutes of repeated publishing work per week; adjust that budget against the time spent maintaining the automation.
Automation also changes who maintains access. A GitHub Actions workflow that publishes listings needs secrets and a review path for workflow edits. Apple’s App Store Connect API authentication uses an API key and a JWT signed with ES256; Google Play Developer API automation commonly uses a service account with explicitly granted Play Console permissions. Those are different credential paths, so a single vague instruction to “rotate the ASO token” is not enough. Record the credential owner, where each permission is granted, and how to publish manually if the workflow fails.
Keep publishing separate from application release unless a listing depends on a specific build. Coupling every text correction to a binary release makes small fixes wait for unrelated engineering work. Conversely, publishing screenshots of an unreleased screen can mislead users, so mark those assets as blocked on the relevant build becoming available. The dependency belongs in the change record rather than in someone’s memory.
A simple expiry check can expose records that have remained live past their planned review. This runnable example uses Python 3’s standard library and deliberately writes sample data; replace the CSV with a maintained file before putting the check in CI:
cat > aso-changes.csv <<'CSV'
change,owner,review_by,status
en-US screenshots,mobile,2026-11-01,live
CSV
python3 - <<'PY'
import csv, datetime
with open("aso-changes.csv", newline="") as f:
rows = csv.DictReader(f)
for row in rows:
due = datetime.date.fromisoformat(row["review_by"])
if row["status"] == "live" and due < datetime.date.today():
print(f'REVIEW {row["change"]}: {row["owner"]} ({due})')
PY
This check cannot decide whether a screenshot is wrong; it can only make an overdue decision visible. That narrower job is useful because an automated check is easier to trust when it does not pretend to replace product review.
Attribution upkeep can outlast the campaign it was bought for
A growth playbook, App Marketing ASO and Growth Strategies for IT Apps, can justify testing acquisition ideas, but the team still has to maintain the boundary between store data and in-app data. App Store Connect and Play Console report store activity; Firebase Analytics and GA4 report events the app sends; BigQuery may hold exported event data. Comparing those numbers without their definitions invites false conclusions, because each system observes a different stage of the user journey and may apply different reporting rules.
Write down the exact question before adding an SDK or dashboard. If the question is whether a new store screenshot improves listing conversion, use the store’s experiment and reporting facilities first, because an in-app event does not observe everyone who saw the listing. Apple’s product page optimization and Google Play Store Listing Experiments are named options, but their results still need a record of dates, locales, variants, and overlapping releases. If the question is whether acquired users activate, instrument an activation event and document its schema; do not relabel an install count as activation.
Paid attribution brings a different maintenance contract. AppsFlyer or Branch may be justified when a team needs their campaign-level attribution workflows, but an SDK adds release testing, consent and data-flow review, and a migration task if the vendor changes. Apple’s SKAdNetwork 4.0 and AdAttributionKit also require care in interpretation because privacy-preserving attribution is not a person-level ledger of every install. Google Play Install Referrer API data has its own integration path. Mixing outputs from those systems into one chart without stating the source and denominator makes a precise-looking dashboard less useful.
Give every acquisition metric a definition next to the chart: numerator, denominator, event source, time window, platform, and owner. For example, “activation rate” might mean accounts completing a specified setup event divided by first opens within a stated window. That definition is a team choice, not a metric supplied by GA4. If an event name or setup flow changes, the owner must either update the definition and annotate the break or keep the old series separate; silently joining them makes a trend impossible to interpret.
Set a 48-hour target for triaging broken acquisition events during an active experiment, then tune it against the team’s actual release and analytics cadence. This is an operational target, not a claim about how quickly a vendor repairs data. If nobody can meet it, pause experiments whose decisions depend on those events rather than accumulating results the team cannot verify.
The cheapest ASO backlog item is one the team can retire
Many ASO tasks are created as permanent additions: another locale, another dashboard, another tracked event. Retirement deserves equal priority because each addition creates a place where product changes can leave incorrect information behind. At the end of an experiment, decide whether its assets become the maintained default, return to the previous version, or leave the active set entirely. Record that decision and remove obsolete scheduled reports or alerts; otherwise the next owner must investigate work that no longer has a decision attached to it.
A review should ask for evidence of continued use, not merely evidence that a tool was once installed. Check whether someone acted on a Looker Studio dashboard in the last planning cycle, whether its BigQuery query still matches the event schema, and whether its owner can explain discrepancies with the store console. If it cannot support a current decision, archive it with its definition intact. Keeping a historical snapshot is cheaper than maintaining a live pipeline solely because an old presentation linked to it.
The same rule applies to keywords and localized copy. A keyword sheet is worth updating if it informs a planned listing change; maintaining it on a schedule without a publishing decision consumes time without changing what users see. Ask the owner to name the next decision each recurring task supports. If there is none, stop the recurring task and leave a dated note explaining why, so its absence is deliberate rather than mysterious.
For a team of this size, the strongest operating model is a modest queue with explicit entry and exit conditions, because engineering, design, and marketing can review it without creating a separate ASO bureaucracy. A new experiment enters only with an owner, a measurement definition, and a planned review. It exits with a keep, revert, or retire decision. That may mean running fewer concurrent tests, but each finished test leaves the live listing easier to maintain.
Start by finding the live change nobody owns
Open the current App Store Connect and Play Console listings and pick one live screenshot, localized claim, or experiment whose owner is unclear. Find its source file, the product feature it depicts, and the person who can correct it. Put those facts and a review date in a shared record today. If that takes longer than expected, you have found the maintenance burden to fix before adopting another ASO tool.
