App Store Connect gives you two very different kinds of data, and most teams only use one of them.
Reports tell you what happened over a period: impressions, downloads, conversion rates, sessions, deletions, proceeds. Apple builds them in batches, so they always run behind. Your first Analytics Reports request takes one to two days to generate, and after that new data lands once a day, covering days that are already over.
Events tell you that one specific thing just happened: a build finished processing, your app was approved, a tester hit a crash, someone subscribed, someone asked for a refund. Apple pushes these to a URL you choose as they happen, through App Store Connect webhooks and App Store Server Notifications V2.
Both are useful. They just answer different questions.
What reports are good at
Reports are how you see trends. If you want to know whether your new screenshots lifted conversion, or which traffic source carries your growth, or how many people deleted the app after the last release, you need report data. Nothing else adds it up for you.
The cost is time. By the time a report shows a dip, the dip is days old. Apple also applies privacy thresholds, and usage metrics like sessions and deletions only count people who opted in to share analytics, so smaller apps see gaps.
That is fine for the questions reports are built for. Nobody needs to know their weekly conversion rate within seconds.
What reports can't do
Some things lose most of their value if you hear about them two days later:
- A rejection. Every hour before you see it is an hour your fix isn't in review.
- A build that failed processing. Your release train is stuck until someone notices.
- A TestFlight crash. The tester's memory of what they were doing fades fast. So does their patience.
- Auto-renew turned off. This is the earliest churn signal Apple gives you. The subscription is still active, which means there's still time to act.
- A refund spike after a release. Two days of a broken purchase flow is real money.
None of these are trends. They're single moments that someone on your team should react to. Reports were never designed to deliver them.
Where the real-time data comes from
Apple has two event streams, run by two separate systems.
App Store Connect webhooks cover the development side: app version state changes (submitted, in review, approved, rejected), build upload and processing states, external TestFlight build states, TestFlight crash and screenshot feedback, and Background Assets and alternative distribution updates. You register a webhook URL per app, and App Store Connect sends a POST when the event happens.
App Store Server Notifications V2 cover the money side: new subscriptions, renewals, failed renewals, auto-renew changes, plan changes, expirations, refunds, offer redemptions and more. You set one URL per app for production and one for sandbox.
Both send small signed payloads that tell you that something happened, not everything about it. A crash event points to a crash submission. A subscription event carries a signed transaction you have to decode. Turning that into something a person can read takes a few more API calls. We wrote about that step in Enriched, Not Just Forwarded.
Use both
The setup we'd recommend for most iOS teams:
| Question | Source | How often you look |
|---|---|---|
| Is the funnel healthy? Did my ASO change work? | Reports | Weekly, or a daily glance |
| Which app or traffic source is growing? | Reports | Weekly or monthly |
| Did the build process? Are we in review? Approved? | Events | The moment it happens |
| Did a tester crash? What did they say? | Events | The moment it happens |
| Who subscribed, churned, or got a refund? | Events | The moment it happens |
Reports belong in a dashboard you open on purpose. Events belong where your team already talks, so nobody has to remember to check.
How Yeethook fits in
Yeethook handles the event side. Upload your App Store Connect API key and it registers the webhooks on Apple's side, configures Server Notifications V2, enriches every event with the details Apple leaves out (crash logs, tester comments, device and OS, subscription and transaction details), and posts it to Slack or Discord. You can route each kind of event to the channel where it belongs, and Yeethook watches the connections so a deleted webhook doesn't quietly cost you a week of events.
Keep your favorite analytics tool for the trends. Let the moments come to you. Get started, or browse every event Yeethook supports.