Why refresh units matter in ASO automation pricing

ASO tools often look simple until automation enters the workflow. A human checking 10 keywords once a week is manageable. A script checking 100 keywords every hour can become expensive and noisy very quickly.

That is why refresh units matter. They make the cost of live store work visible.

Cached reads and live refreshes are different

A cached read returns recent data the product already has. It should be fast and cheap.

A live refresh asks the system to go back to the store, inspect current results, parse the response, normalize it, and save a new snapshot. That work is more expensive. It may also need to queue if many checks are running.

Treating both operations the same creates confusion. Developers need to know when their workflow is reading existing state and when it is spending fresh work.

Refresh units create a clear boundary

For a small team, a good pricing model should answer:

• How much live checking is included?
• What happens when usage gets heavier?
• Which operations are cached reads?
• Which operations spend units?
• When does work queue instead of blocking the user?

The answer should be visible in the dashboard and accessible through the API or MCP tools.

Avoid accidental polling loops

The biggest risk in ASO automation is not one expensive request. It is a script that quietly runs too often.

Examples:

• Refreshing every tracked keyword on every deploy.
• Running competitor discovery every time a dashboard opens.
• Asking an agent to inspect broad keyword sets without checking usage.
• Re-running the same live search when cached data is recent enough.

Good products make those patterns hard to miss.

Design automation around decisions

Spend refresh units when the answer changes a decision:

• Before a release.
• After metadata changes settle.
• When a competitor appears repeatedly.
• When a tracked term drops.
• When a scheduled report needs current data.

Use cached reads when the user is reviewing recent state, building a report, or preparing a prompt for an AI tool.

Why this matters for the Developer plan

AppTide's Developer plan is meant for indie teams. That means the product needs to support real workflows without pretending small teams have enterprise budgets.

The plan should include enough live refresh units for normal release cycles, while keeping heavier automation honest. If a workflow grows into broad recurring crawls, it should move to a higher tier or a more explicit job schedule.

A practical usage rule

Before you automate a refresh, ask:

1. Will this answer change a release, metadata, or competitor decision?
2. Is recent cached data already good enough?
3. Should this run live or queue as a crawl job?
4. Do we need to inspect every keyword, or only the active release set?
5. Will the same script run too often?

That rule keeps ASO automation useful without turning the data layer into the product's hidden cost center.