Menstrupedia · TruBuddy — shared audience pool

Audience catalog

Recommends which audience to launch next for each product, ranked from real spend, conversion, overlap, and reach history — not guesswork.

—last refreshed

—audiences catalogued

—currently active (at refresh)

—history window

Settings

—

High overlap threshold % audiences overlapping an active audience by more than this are flagged and ranked below the rest

CPO thresholds (₹)

an audience whose last 5 completed attempts all cost more than its product's threshold is ranked far below the rest

Show blacklisted audiences

Ad account

Catalog not built yet First automatic refresh is scheduled — or ask Claude to run it now to populate this page.

Schema (Cloudflare D1, database meta-ads-audience-catalog): meta_status (refresh metadata) · audiences (targeting, scope, size — refreshed twice a month) · ad_set_facts (raw per-ad-set spend/purchases). Weighted spend, weighted conversions, weighted CPO, confidence tier, and overlap are computed live on every page load from ad_set_facts, using today's date for recency decay and the actual currently-active ad sets — not precomputed at refresh time. The Overlap column's first line shows what fraction of this audience's own targeting is already covered by something currently active anywhere in the account, pooled across every product together (not just the single closest active audience); the second line is the same calculation restricted to only audiences currently active under the product you're viewing — a candidate can show high account overlap (redundant with something active for a different product, which still matters for Meta's own auction/cost) while showing low product overlap (safe from cannibalizing this product's own campaigns, since a different product means different creative/offer and much less of the classic same-ad-fatigue risk) — worth weighing both together, not just one. Hover the cell to see the single closest active audience by name and its own overlap percentage against this one specifically — shown for context, not what either line's percentage is itself computed against (both lines are computed against the full active set, not just this one audience). The Reach/day @₹500 column's first line is total reach/day, normalized to a ₹500/day budget and linearly rescaled from the refresh-time ₹450 basis stored in audiences; the second line, Exclusive, discounts out the account overlap's covered fraction — an estimate of how much of this audience's reach is genuinely new territory, not a re-spend on people something active is already reaching. "Last used" and "Active now" are scoped to the audience's literal name, not its internal identity — Meta allows the exact same name to be reused across many different targeting definitions, so these reflect what anyone browsing by name in Ads Manager would see. Ranking: audiences passing both the overlap ceiling and 7-day recency gate, and not already active themselves, are ranked first — by track record, then confidence tier, then weighted CPO, then exclusive reach/day as a final tiebreaker; anything failing either gate drops below all gate-passing audiences regardless of tier or CPO; audiences already active under this exact targeting rank below that (still visible via the "Active now" badge — you can't meaningfully launch what's already running); audiences benched by track record rank below that; blacklisted audiences rank last of all. Size floor stays a soft badge, not a ranking gate. Weighted spend/conversions/CPO all use recency decay (half-life 90 days). Track record (the 5-dot column): an attempt is a run of consecutive days an audience actually spent money, bounded by an observed $0 day — not by ad-set status, since ads inside an ad set can be paused without the ad set itself changing status. Each attempt's CPO is judged against its product's threshold (set above, or that product's own live average CPO if unset); an audience whose last 5 completed attempts all failed is benched. A row never fetched shows "—"; once fetched, if it has no completed attempt yet (e.g. its only run is still in progress) it shows 5 grey dots rather than "—", so "fetched, nothing to judge yet" is visually distinct from "not fetched"; once it has at least one completed attempt, real attempts fill in left-to-right (oldest first) and any remaining slots on the right are greyed out — this audience just hasn't accumulated that many attempts yet, not "history unknown that far back." Hover a dot for that attempt's dates, spend, and daily breakdown. This data is only fetched for a bounded set of audiences that matter (top-ranked, currently active, or explicitly requested) via each row's "⋮" menu, never for the whole catalog at once. The "Ad account" toggle above filters which already-loaded rows are shown by which Meta ad account ever ran that audience — it's a view filter only, computed client-side from data already returned by the API; it doesn't change rank numbers, gating, or the overlap/recency math. Each row's "⋮" menu blacklists/unblacklists it (blacklisted audiences are excluded from this table entirely, with no rank gap, unless "Show blacklisted audiences" is checked, in which case they're shown but forced below every other row) and, until fetched, offers "Fetch track record".