Your first month on the App Store: what to keep an eye on

Which App Store numbers should you track first?

Start with a short note containing the app, reporting period, downloads, estimated proceeds, refunds, new reviews and anything that changed. Add reliability and usage checks in Apple's tools. These answer different questions, so avoid turning them into one success score.

Apple separates acquisition and engagement analysis from final payment reporting. Use its reporting tools overview to find the right place for each question.

What should you do in the first week?

Choose a reporting baseline before interpreting growth. Record your launch date, version, platforms, countries and selected timezone. Save the exact name of your download metric alongside its number.

Apple's Total Downloads combines first-time downloads and redownloads. Usage data comes from people who opted to share analytics. Those are different populations; a usage chart is not a complete census of everyone who downloaded the app. See Apple's metric definitions.

Then try the public journey yourself: follow your shared link, inspect the product page, install a fresh copy and complete the main task. Test the support link too. Your existing development installation may conceal an awkward first-run experience.

Keep a launch log with one line per change. A screenshot update, newsletter mention, price change and bug fix are all worth dating. Later, that little record will be more useful than trying to remember why Tuesday looked different.

What deserves a daily check?

Give yourself a short appointment with the app, perhaps ten minutes after breakfast. Look for a broken purchase flow, a new crash report, a repeated support question or an unexpected change that needs investigation. Read new reviews for the experience behind the stars.

Classify what you find as fix now, investigate this week or keep watching. Someone unable to open their work belongs in the first group. One unusually quiet day usually belongs in the third, unless other evidence points to a fault.

Use the same completed reporting period each time. Comparing part of today with all of yesterday creates a very convincing-looking problem that may disappear once the periods match. If numbers disagree across screens, work through our download-number comparison guide before changing the app.

How should you review weeks two and three?

Compare complete weeks, keeping the app, platform, country and metric consistent. Look at counts beside percentages, and read your launch log before assigning a cause.

Illustrative example: a fictional app grows from four downloads one week to eight the next. That is a 100% increase and four additional downloads. Both descriptions are true. The smaller-sounding one helps you judge how much evidence you actually have.

Use acquisition sources to see whether discovery came through search, browsing or referrals; Apple explains these in its Analytics overview. Then choose one question you can investigate. If people mention confusing setup, watch a willing tester complete it. If a particular post brought interested visitors, examine what it explained clearly.

A timing match is a clue, not proof of cause. Avoid changing screenshots, pricing and onboarding together if you want to understand the next result.

How should you read proceeds and country data?

Keep sales and proceeds separate. Proceeds account for applicable taxes and Apple's commission, and the figures in Sales and Trends are estimates rather than final payments. Apple's sales and proceeds guide explains the distinction.

For your own weekly note, record the currency and whether the amount is estimated. Investigate refunds alongside purchase and support context; one refund does not explain itself.

A first download in another country is worth enjoying. Before committing to a full translation, look for repeated activity and specific feedback. Test practical details such as dates, decimal separators, text length and local assumptions. A chart appearance can add context, but use rankings alongside actual downloads when deciding where to spend your time.

What belongs on your first-month checklist?

Keep this beside your release notes and work through it at the end of the month:

• Confirm the public product page, install journey and support contact work.
• Record metric names, dates, filters, timezone and currency.
• Check current crashes and reproduce serious customer problems.
• Group review and support themes without treating one comment as universal.
• Compare complete weeks and note the underlying counts.
• Check purchases and refunds against the issues people report.
• Record which countries are finding the app.
• Choose one improvement and write what would indicate it helped.

If you request a rating, let people experience the app first. Apple's rating prompt guidance recommends waiting for meaningful engagement and using a natural pause. Keep support available to everyone, whether or not they leave a rating.

How can you make the routine easier to keep?

Perch brings installs, proceeds, reviews and rankings together on iPhone and in your Mac menu bar. Public rankings work without a key; connecting your own App Store Connect key adds reports and review features, subject to permissions. The setup guide walks through that connection.

Use it for your regular glance, then open Apple's tools when a question needs deeper investigation. The useful outcome of month one is a clearer sense of who your app helps, where people get stuck and what you will improve next. Give that next piece of work a date, close the numbers and get back to making.