Audience Analysis
Audience Analysis reads your audience back from the destination platform and puts that reading next to what BPP pushed. It answers the question a sync status cannot: the run said Complete — so is the list actually usable on the platform?
Every figure on the page is labelled with the API field it came from, and the page states plainly which figures the platform does not report at all.
How to open it
- Open an audience and go to the Destinations tab.
- Each destination row has an analysis cell showing a 7-day sparkline and its current reading.
- Click the cell (or the analysis icon at the end of the row) to open the full analysis.
The analysis is a sub-view of the Destinations tab, not a tab of its own — use Back to Destinations to return. You can also link straight to it: the destination id is carried in the ?analysis= URL parameter.
Where it is available
| Destination type | Analysis |
|---|---|
| Google Ads — Customer Match | ✅ |
| Meta Ads — Customer Audience (Customer Match) | ✅ |
| Meta Ads — CAPI Audience (rule-based) | ✅ |
| Anonymised, API Endpoint, BigQuery, Microsoft Ads | ❌ — the platform reports nothing BPP can read back |
On a destination with no analysis the cell reads "Analysis not available for this platform yet" and the row is inert — there is nothing to open.
Controls
- Audience destination — switch between this audience's destinations without leaving the view.
- Analysis window — 7, 30 or 90 days. The resolved date range is echoed next to the selector so the figures can never be read against the wrong period.
- Compare to previous period — adds a vs previous period delta to the peak-push tile, the one figure BPP measures itself and can therefore compare over time.
- Refresh data — fetches a fresh reading from the platform now. Refreshed X ago tells you how old the current one is. Each refresh is a live call to Google or Meta, so it is throttled to 20 per hour per user.
Your window and compare choice are remembered between visits.
Identity strip
Under the controls, a strip names which remote list the figures describe: the ad account, the list or audience name, the upload mode, and the Platform state.
| Platform state | What it means |
|---|---|
| Ready | The list is matched, open and eligible. |
| No size yet | The platform has not published a size — normal shortly after the first push. |
| Too small to serve | The list is healthy but below the platform's minimum size, so it delivers nothing. |
| Not eligible | The platform will not serve this list on one or more of its networks. |
| Closed | The platform closed the list, usually for inactivity. |
| Not delivering | The platform can no longer use the audience for delivery. |
| Stale | Too long since the last upload; the list has stopped refreshing. |
Too small to serve is the one worth looking for. Every other figure on the page can read green — good match rate, open list, eligible — while the list still delivers nothing because it is under the platform's floor (1,000 matched users on both Google and Meta). This pill is the only thing that says so.
KPI tiles
The tiles differ by platform, because the three platforms answer different questions. Each tile names the API field it came from underneath the number — that label is what distinguishes two similar-looking figures that are not the same measurement.
Google Ads — Customer Match
| Tile | What it is |
|---|---|
| Audience size (peak push) | The largest single push in the window, from BPP's own run history. A peak, not a total: every push re-uploads the whole membership, so summing them would count the same people once per push. |
| List match rate | Google's exact match rate for the whole list as it stands now — not for the last upload. |
| Size for search | Members Google considers usable on Search and Shopping. Needs at least 1,000 active members to serve. |
| Size for display | Members Google considers usable on Display. Refreshed asynchronously, up to 24h after an upload. |
| Membership life span | How long a member stays in the list before dropping out. Unlimited when the list never expires members. |
| List eligibility | Whether Google will serve the list at all, per network. Ineligibility is the usual reason a healthy-looking list stops delivering. |
| List status | Google auto-closes lists that go unused; a closing reason here is why one stopped. |
Meta Ads — Customer Audience
| Tile | What it is |
|---|---|
| Audience size (peak push) | As above — BPP's largest single push in the window. |
| Valid entries | Entries Meta received minus those it rejected. A received entry is a row Meta kept, not a person it matched. |
| Invalid entries | Entries Meta rejected outright. The reasons are listed under Rejection diagnostics. |
| Audience size (approx.) | Meta's own estimate, as a range — it never returns an exact count. A large gap between this and the peak push is the thing worth investigating. |
| Delivery status | Whether the audience can currently be used for delivery. Code 300 means fewer than 1,000 matched users. |
| Operation status | Turns 410 after 90 days without an upload, at which point the list stops refreshing. |
| Retention | How long a member stays in the audience. 0 means no expiry. |
Meta Ads — CAPI Audience
Same shape as above, with the vocabulary that fits a rule-based audience: Events sent (peak push), Events received (events Meta acknowledged), Dropped events, plus Audience size (approx.) and Retention. There is no operation status — a rule-based audience cannot go stale.
Members sent vs list size
One point per sync. The two lines are different kinds of number — what a push carried, against how big the whole list is — so they sit on separate axes and the gap between them is not a quantity you can read off the chart.
Neither Google nor Meta keeps a history BPP can backfill, so a young destination's chart starts empty. When that happens the page says so outright: the empty stretch at the start is "we were not looking yet", not a drop to zero.
Upload requests / Upload sessions / CAPI requests
One row per BPP sync, with the platform's own record of it. The columns differ because the platforms report different things:
| Platform | Columns |
|---|---|
| Request ID, Run started, Sent, Failed, Result | |
| Meta Customer Match | Upload session, Run started, Sent, Received, Invalid, Batches, Failed, Result |
| Meta CAPI | Request ID, Run started, Sent, Received, Invalid, Failed, Result |
Google reports no per-upload received or invalid count for an audience, so those columns are absent rather than empty — an always-blank column reads as data BPP failed to capture, which is not what is happening.
On Meta Customer Match, emails and phones upload as separate sessions while members are counted once. Received is therefore not comparable to Sent on that platform, and the Batches column is there to explain the discrepancy.
A run may show its reference as "not captured": BPP's exporters only started recording platform references from release 6.3.0, so earlier runs have nothing to match on.
Open Execution History takes you from here to the full run history for the audience.
Rejection diagnostics
Why the platform turned records away, aggregated over the window:
| Column | What it shows |
|---|---|
| Reason | The platform's own reason code. |
| What it means | Plain-language explanation. |
| Members | How many records carried that reason. |
| % of attempted | Share of the records attempted — rejections sit on the failed side of the attempt, so the denominator is what was tried, not what was sent successfully. |
| vs 7d avg | Whether this reason is getting better or worse. |
| Where to fix it | Which part of your setup to change — data source column, destination mapping, or audience filter. |
BPP explains the common codes on each platform, for example:
INVALID_SHA256_FORMAT(Google) — the identifier is not a lowercase hex SHA-256 digest → fix the identifier column in your data source.NOT_SHA256(Meta) — the value was sent unhashed, or hashed with the wrong algorithm → fix the destination's customer parameters.INVALID_PHONE(Meta) — the phone is not in E.164 format → fix the phone column in your data source.EVENT_TIME_TOO_OLD(Meta CAPI) — the event is older than the Conversions API accepts → tighten the audience filter's event recency.
On a CAPI audience these are warnings, not rejections: the Conversions API accepts and warns rather than refusing outright.
What this platform's API exposes
The last block on the page lists every field the analysis is built from, with a Caveat column, and — just as importantly — the fields the platform does not report at all. Rows marked Not available are absent from the platform's API: BPP cannot show them, and nothing else on the page is standing in for them.
Rows marked Not read yet are different: the platform does report that field, BPP simply has not fetched it. Click Refresh data.
What each platform can and cannot tell you
This is the part worth reading before you draw a conclusion from any number above.
Google reports the list, not the upload
The match rate and sizes describe the whole user list as it stands now, including members from earlier pushes still inside their membership window — not the last sync. Google never returns which individual members matched, and BPP only ever adds members, so there is no removal count either.
Meta does not expose a match rate for an audience
Valid entries is the closest API-side proxy, and it counts rows Meta accepted, not people it matched. Meta's real match rate is visible in Ads Manager only. Sizes are approximate bounds — Meta never returns an exact count.
A CAPI audience's membership is inferred, never enumerated
The audience is built from a rule over the events BPP pushes, so its size counts everything matching that rule — including traffic BPP never sent. Meta acknowledges receiving events but reports no match rate and no Event Match Quality for the audience.
See also
- How Audience Syncs Work — what a sync actually does
- Execution History — the full run history for an audience
- Manage Audiences — the rest of the audience detail page