How an app activity audience works
If you have a mobile app, every meaningful action inside it can be reported back to Meta as an event: the app opened, an item added to a basket, a level reached, a purchase completed. An app activity audience is a list of the people who triggered a chosen event within a chosen lookback window.
For any of it to exist, three things have to be in place. The app must be registered in Business Manager. Events must be sent, either through Meta’s own software development kit inside the app or through a mobile measurement partner that forwards them. And the events must be named and configured in Events Manager, because Meta can only build an audience from an event it recognises.
Once that plumbing is right, the audience behaves like any other custom audience: it refreshes continuously, people age out at the end of the window, and you can target it, exclude it, or use it as the source for a lookalike.
Why app activity audiences matter
Installs are not the goal; use is. An app activity audience is what turns install advertising into something you can judge, because it separates people who downloaded the app and forgot it from people who actually did something with it. Targeting the first group with a re-engagement message, and excluding the second from install ads, is the difference between buying downloads and buying customers.
It is also the only clean way to find more of your good users. A lookalike seeded from people who bought inside the app describes a far more specific person than one seeded from everyone who installed.
Common mistakes with app activity audiences
The first is assuming the data is complete. On Apple devices, a user who declines the App Tracking Transparency prompt limits what can be attributed and passed back, so the audience you can build is smaller than your real user base. Planning as though every user is targetable leads to budgets that cannot be spent and lists that never reach a workable size.
The second is event naming drift. A developer renames an event in a release, the old name stops arriving, and the audience quietly stops growing. Nobody notices until delivery falls, because nothing in the interface reports an error.
The third is building audiences for events that almost nobody triggers. A list that is too small to deliver against is not a targeting option; it is a stalled ad set.
How to act on it
Start by agreeing a short list of events that matter commercially and freeze their names, then treat any change to them as a release that needs checking in Events Manager. Verify each event is arriving before you build anything on top of it.
Build the audiences you will actually use: recent openers for re-engagement, purchasers for exclusion and for seeding, and lapsed users for a win-back message. Keep the windows long enough for the lists to hold a usable number of people, and if a segment is too small to deliver, merge it upward rather than running it alone. Where the app is the product, this sits alongside your app install advertising; where installs stall, check whether App Tracking Transparency is limiting the signal before blaming the creative.