Introduction
On every digital marketing platform, like Meta, TikTok or Apple Search Ads (ASA), the price you pay to acquire a user doesn't just depend on how many users you want to reach, but on how many other people want to reach that same segment. Platforms like ASA tell you how much you pay, how many times you show up and how many people tap your ad, but nowhere near who you're competing against, only that your daily spend has dropped, and the most immediate fix for that is to pay more for every impression and raise the budget.
While campaigns are stable and predictable, you accept these rules. But when a sudden change shows up that our own data can't explain, that's when it becomes more urgent to understand what's going on before just raising spend.
In September 2026, impressions on our Brand (or defensive) campaigns for I Am and Vocabulary dropped more than 90% in a few weeks, without us changing anything on our side. These are the campaigns that trigger an ad when someone searches for our own apps in the App Store.
This post describes how we built a system to watch those searches from a real iPhone, what we found, what decisions we made and how it has changed the way we work for advertising in the App Store.
The drop in impressions on our apps
Between August and early October, daily impressions for I Am ads when people searched related terms on the App Store fell by more than 90%, as a 7-day average. Vocabulary's practically disappeared between September 30 and October 4, a drop of over 99%.
Trying to understand what was happening with the data we had, we were able to rule out a demand problem:
- The Click Through Rate (CTR) stayed around 20% for the whole drop.
- Daily spend stayed well below the daily budget we had set.
- We didn't change anything on our side during that period, neither budgets nor bids.
If people keep tapping the ad at the same rate but the ad is shown less, the most likely explanation is that we're losing the auctions. Another advertiser shows up above us when someone searches for our apps because they are willing to pay more for that slot.
That's exactly the data Apple doesn't give you. The information Apple Ads gives us includes spend, impressions, taps, cost per tap and our impression share, but not which app holds the first position for a specific search.
The only way to check it is to run the search for the terms we were losing on a device, or get that information some other way.
We ruled out two alternatives:
- Third-party tools. They sample now and then and don't give you continuous observation of our own terms. Not to mention the high price.
- Manual searches. They don't scale, they take a lot of time and, as we explain later, repeating searches from the same device skews what you see.
How we built it
The system had to meet four requirements:
- See the results the way a real user in the US sees them.
- Be able to repeat the same searches consistently.
- Run without manual intervention.
- Store every observation in a way that can be joined with our campaign data.
Since iOS simulators don't include the App Store, we couldn't automate any search that way; the solution was to use a physical iPhone.
The architecture has three pieces. An iPhone connected to a computer. A crawler that runs searches over a list of terms and records which app holds each ad position. And our data warehouse, where every observation sits next to the impressions, taps and cost per tap of our campaigns.
Once we had the idea clear, we built the whole architecture with Claude in a single afternoon. After a first POC to check it was feasible and what data we were storing, we ran a loop with Claude to improve the functionality. One thing Claude did on its own, for example, was turning off the phone's auto-lock while it was searching, since after a while the phone locked and couldn't finish the search.
Then we saved the whole process as a skill, so we could schedule it or run it ad hoc with a single command.
The real complexity of the process was interpreting the data we were getting and inferring how the ASA algorithm behaves, so we could understand what was going on:
- Apple limits how many times the same advertiser is shown to the same user.
- Our own searches generate impressions on our ads that nobody taps.
On top of that, keeping the setup running wasn't trivial: the device locks, hangs and its developer signature expires, not to mention possible changes in the App Store design that can suddenly make the whole process outdated.
We're not going to describe here how we solve each one in this post.
A mistake we learned from
On October 6 we ran 50 passes in a row: about 1,400 searches in around 90 minutes. We expected to get a bigger and more significant sample out of it. It didn't work out that way.
Since Apple limits how many times a user sees the same advertiser, the top-ranked advertisers stopped showing up after the first passes. The following ones mostly showed the advertisers further down, which either have noticeably lower bids or were starting to come in because they had broad search match.
Related to this, we found that even though Apple doesn't say it anywhere, there must be a frequency parameter on ads, which we estimate at 2 impressions in a row, and another two after a cooldown period.
So handling the data and the competitors properly isn't just about counting, but also about modeling when they show up. An app showing up on the first search isn't the same as an app showing up on the 48th.
What we found and what we decided
With all this new data at hand, we were able to confirm our hypothesis: we had competitors advertising more aggressively on our own terms. On "i am", our app didn't show up in the first position in any of the observations between October 5 and 13. We also found something more interesting:
- Many of them are recent apps with few ratings. They're not established competitors, but fairly similar apps, built with AI, that have been accepted on the App Store recently.
- There are relevant searches we didn't have in our campaigns. Now we also have ads on competitor apps that are interesting for us.
With this information we made two different decisions.
Vocabulary: win the position back. We added a new term, "vocab", with a higher bid, and that got the impressions back to September levels in a matter of days. The cost is clear: cost per tap is now around 65% higher than before the drop.
I Am: not competing at any price. Even without the ad, our app still comes up first in the organic results for "i am", so the question isn't how much it costs to win the ad back, but how many installs or purchases it was really bringing in, and being able to quantify how many of the attributed ones happen even when we don't have an ad on our terms.
So we've decided not to adjust the bids on our campaign and leave it like that for a while longer, to quantify how many installs we get and also to see whether it recovers on its own, or whether the automatic bid adjustment processes we have manage to lift it without having to pay much more.
How the way we work has changed
Getting data that isn't available anywhere is always a challenge, but everything we've built has made us embrace this new information, adapt to it and make the most of it, since it's something that pretty much doesn't exist on the market.
Now this information, which we get every week, lets us know what's going on and not only when something breaks. It also helps us find competitors we didn't know about, which lets us be more aggressive and run ads on their terms, for example.
This information also improves the automatic management process we have set up in ASA (maybe we'll cover it in another blog post) and lets us optimize bids and keyword management significantly.
Conclusions
When a campaign drops for no apparent reason, the default answer on any ad platform is to raise the budget and pay more per impression. We preferred to understand what was going on first. After analyzing the data, we came up with the hypothesis that other apps were advertising on our own terms. Since Apple doesn't give you that data, we built the process to get it. Besides confirming the hypothesis, it let us identify competitors we didn't know about and has given us a new way of working in Apple Ads.
Thanks to that process, built on a physical iPhone and developed with the help of Claude, we now know that a good part of the apps advertising on our searches were recent apps, very similar to each other. With that, we can manage our bids much better and start exploring search terms we weren't even looking at before.
