Automation Pipeline5 min read

My sales report spent four weeks reading an empty vendor

My App Store sales report returned 'no sales' for 26 days straight, and 30-day revenue looked cut in half. Sales had actually moved to a second vendor number, and my scripts only knew the old one.

#app-store-connect#revenue#monitoring#silent-failure#reporting
Old vendor report showing 26 straight days of 'no sales' next to the new vendor report where sales were actually counted
The report never failed once. It was correctly reading a vendor that no longer had any sales.

Revenue cut in half

The 30-day total in my revenue log had dropped from about USD 54 on 09-21 to about USD 26.6 on 10-20. The App Store share was about USD 8.

I opened the App Store SALES daily reports to find out why. Every day from 09-24 to 10-19, 26 days in a row, said 'There were no sales'. Paid sales weren't the only thing at zero. Free downloads were zero too, for every app.

The worse part: my daily ASC report had been sending Daily totals: … 0 0 0 0 the whole time. The alert arrived on schedule every day, and for four weeks nobody read it.

If your report returns a 'valid zero' instead of an error, what tells you that the zero is real?

There were two reporting vendors

In ASC, under Payments and Financial Reports, the name dropdown lists two sales-reporting vendors. My environment file only knew the old vendor number. Starting 2026-09-23, sales and downloads were being counted under the new one.

The old vendor doesn't throw an error. It answers 'no sales', meaning a normal zero. So from the script's point of view, it never failed once.

There was a second trap. On 09-30 I had changed the code to treat a 'no sales' response as an empty list []. The reasoning was that zero is data, and that reasoning was correct. But that same fix made this exact symptom look normal. Nothing anywhere questioned all 50 apps hitting zero at once.

Checking whether the zero was real

Before drawing a conclusion I checked four things against each other:

  • The September monthly SALES total, 3,763 units, equaled the sum of the September daily reports, also 3,763. So Apple's own records agree that the old vendor really was at zero from 09-24.
  • Analytics App Downloads Standard, which doesn't depend on vendor, showed daily downloads after 09-24 for Heardle, Plotta GPS and Itda.
  • Engagement page views for October were about 9.8k, against 10.4k for the same stretch of September. Demand hadn't changed.
  • Querying the new vendor directly showed 331 units on 10-07 alone. Real proceeds for 09-23 to 10-19 were the Heardle lifetime pass at USD 8.48 + GBP 3.52, a Flara monthly sub at 4.24 and a Reelo monthly sub at 4.24.

What would you do here: add the second vendor number and move on, or also make sure an all-zero day can never slip by quietly again?

What I changed

I did both.

  • The report download function now takes a comma-separated list of vendors. If any of them returns 'not available yet' (None), the whole day stays None. A half-reported day doesn't get written down as zero. I added two tests.
  • The subscription churn script fetches reports through its own path, so I changed it separately to loop over each vendor.
  • The environment file, which is outside version control, now lists both vendor numbers.
  • The daily revenue script bumps its ledger version from 2 to 3, which re-fetches 35 days, and now records units for each date. If App Store units are zero three days in a row, it writes 실패 ("failed") as the last log line and exits with rc=1, which turns the monitoring board red. I confirmed it catches the case in a simulation that includes the 10 days when only the old vendor was being read, and added that as an assertion in --demo.

Numbers after the fix

  • Real 30-day revenue was about USD 56.3 (App Store about 37.7, Play about 18.6). Revenue never halved.
  • The top-selling SKU was the Heardle lifetime pass. The Heardle payment wiring I built on another machine had been making its first sales since 09-23, and I couldn't see it until now.
  • On the other hand, fortune-shop credits (47% of September revenue) have been zero since 09-17. That comes from Play, not the App Store, so vendors don't matter there. That zero is real.
  • Downloads over 28 days came to 1,042 (about 37 a day): 510 in the first half, 532 in the second.

Blast radius

None of the active rows in my decision roster depended on App Store SALES. CPP and in-app events use Engagement, and the rest use Play or GA4. Still, any conclusion between 09-23 and 10-20 that cited App Store downloads or revenue needs a second look.

Self-check

  • When an external report returns a valid zero instead of an error, do you check it against a metric that doesn't depend on the same source, like downloads or page views?
  • Do you have a rule that treats every app or every line item hitting zero at once as a failure?
  • Do you get a daily number alert where nothing happens if nobody reads it?

The honest part

My records don't say why sales moved to the new vendor on 09-23, and I don't know why. I also don't know whether I could have seen it coming. The three-days-of-zero rule catches this symptom, but it can't tell the difference from a real three-day stretch with no sales. And when I made the 09-30 fix, I set down the right rule, that zero is data, without its counterpart, that an all-zero result deserves suspicion. What filled that gap wasn't good design. It was luck: revenue happened to look like it had been cut in half.

Related