Conversion Analysis
A signal sync that reports Complete tells you BPP delivered its events. It does not tell you whether the platform recorded them. Conversion Analysis closes that gap: it reads the destination platform's own conversion figures back and puts them next to what BPP pushed.
The headline number is the reconciliation rate — the share of sent events the platform confirmed. Everything else on the page exists to explain it.
How to open it
- Open a signal and go to the Destinations tab.
- Each destination row has an analysis cell with a 7-day conversions sparkline and a health pill: Healthy, Watch, Needs attention, or No data.
- Click it to open the full analysis.
The analysis is a sub-view of the Destinations tab, not a tab of its own — use the back link to return. Links shared with the older ?tab=conversions URL still work; they now land on the destination list.
No data is not zero. It means the destination has no usable reconciliation figure yet — nothing was sent in the window, or diagnostics have never been collected for it.
Where it is available
| Destination type | Analysis |
|---|---|
| Google Ads — Conversions (including Enhanced Conversions for Leads) | ✅ |
| Meta Ads — Conversions API | ✅ |
| Generic API Endpoint, Google Analytics 4, Microsoft Ads | ❌ — nothing to read back |
Controls
- Signal destination — switch between this signal's destinations.
- Analysis window — 7, 30 or 90 days, with the resolved range shown next to it.
- Compare to previous period — adds a comparison series to the chart.
- Refresh data — fetches fresh diagnostics from the platform. Throttled to 20 refreshes per hour per user; if you hit it, wait a few minutes.
KPI tiles
Four tiles are the same on both platforms. The fifth is not — and the difference matters.
| Tile | Google Ads | Meta Ads |
|---|---|---|
| Reconciliation rate | Share of sent events whose conversion Google confirmed. Attributed by click date, so recent days keep moving as more matches arrive. | Share of sent events Meta actually recorded. Meta accepting a batch is not the same as recording its events — this is the gap acceptance alone hides. |
| Events sent | Events BPP sent in the window. | Events BPP sent in the window. |
| Conversions recorded | Sent events Google confirmed as recorded conversions. | Events Meta recorded for this event name, server-side only — the browser pixel's own fires are excluded. Buckets materialise about an hour late, so today fills in through the day. |
| Rejected | Events Google rejected or could not process. Diagnostic only — not a failure rate. | Events Meta did not accept, as BPP recorded at push time. Meta validates a whole batch at once, so one bad event can cost the batch. |
| Fifth tile | Identifier match rate — a heuristic derived by BPP from identifier error codes. Not a Google-reported metric. | Event match quality — Meta's own score out of 10 for how well BPP's identifiers match people. Reported by Meta. |
| Last push | Timestamp of the most recent event BPP sent. | Timestamp of the most recent event BPP sent. |
The fifth tile is a BPP estimate on Google and a platform measurement on Meta. They are not comparable across platforms, and the Google one should not be quoted as if Google had reported it.
Alerts you may see
The page raises these when they apply, because each one changes how the numbers should be read:
- Reconciliation below threshold — fewer than 90% of sent events were confirmed. On Google, recent days keep moving; if the rate stays low, check the destination configuration. On Meta, check the identifier mapping and whether the same population is being re-sent.
- History starts later than this window — Meta's stats endpoint only answers for the last 7 days and cannot be backfilled, so the start of a 30- or 90-day window is genuinely unmeasured. The empty stretch at the start of the chart is missing data, not zero conversions.
- This destination uses a standard event name — recorded conversions count every server-side event Meta received under that name for the dataset. If anything other than BPP also sends it server-side, its events are counted here too. A BPP-specific custom event name makes the figure unambiguous.
- Enhanced Conversions for Leads — Google exposes no per-error API diagnostics for this conversion type, so the error breakdown comes from BPP's own upload records instead. Google's own diagnostics report is available in the Google Ads UI only, where
CLICK_NOT_FOUNDcounts as a warning rather than a failure.
Events sent vs conversions recorded
A daily chart of the two series over the window.
On Google you can also pick a conversion action to compare with from the same account — useful for telling "this destination is underperforming" apart from "the whole account is quiet". Meta has no conversion-action concept, so the selector does not appear there.
Event match quality (Meta only)
Meta's own reading of how well BPP's events match people. This card has no Google counterpart, and that asymmetry is the point: Google lets BPP only infer identifier quality from rejection codes, while Meta measures it.
- Score out of 10 — Meta's guidance: 6 or above is healthy, below 4 is worth acting on.
- Identifiers carried by BPP's events — the share of sent events that included each identifier. This is not a match rate: an identifier can be present on every event and still match few people.
- Additional conversions reported — conversions Meta measured thanks to the Conversions API that the browser pixel alone would have missed.
- Event coverage — share of the dataset's browser events also covered by the Conversions API.
- Upload frequency — how fresh Meta considers this dataset's uploads.
Meta omits several of these for most events, so each figure appears only when it actually arrived. A missing metric is not zero, and the card does not render at all if Meta has never answered for the event.
Upload runs
One row per BPP run for this destination.
| Column | What it shows |
|---|---|
| Job ID | Google's upload job id(s) for the run. Google only — Meta's Conversions API is synchronous and has no job concept. |
| Run started | When the run executed. |
| Attempted | Records the run set out to push. |
| Sent | Records successfully pushed. |
| Pending | Events Google acknowledged but has not yet decided on. Google only. |
| Failed | Records rejected or not sent. |
| Upload result | The run's outcome; a partial result names how many distinct error codes it produced. |
On a Google run, expand the row to see the two sides of the same upload side by side: what BPP recorded pushing, and what Google booked for the same job ids. Two reasons a comparison can be unavailable:
- The run recorded no job id — BPP's exporters only started capturing them in release 6.3.0, so earlier runs have nothing to match on.
- BPP never captured Google's counts — Google reports diagnostics for its last 7 jobs only, and this job had already dropped out of that window when BPP last looked. Once missed, it cannot be recovered.
Google Ads upload jobs
Google's own view of recent uploads for the conversion action, whatever BPP run produced them, accumulated from every daily diagnostics fetch.
| Column | What it shows |
|---|---|
| Job ID | Google's job id. |
| Booked | Every event Google acknowledged for the job — confirmed + pending + failed — whatever it later decided about them. |
| Confirmed | Events Google recorded as conversions. |
| Pending | Events Google has not yet decided on. |
| Failed | Events Google rejected. |
This table exists alongside the per-run comparison because Google's 7-job window rolls fast: an active destination routinely has jobs Google can account for and BPP cannot match to a run. Listing them keeps that visible rather than leaving unexplained empty comparison panels.
BPP's figures are what the exporter recorded at upload time; Google's are what Google booked. The two are counted at different moments by different systems, so small differences are expected.
Rejection diagnostics
Why events were turned away, aggregated over the window: Error code, What it means, Events, % of attempted, vs 7d avg, and Where to fix it.
Common Google codes and what they point at:
| Code | Usually means |
|---|---|
CLICK_NOT_FOUND | The click identifier does not match a click Google can find — often an expired or wrong-account GCLID. |
EXPIRED_EVENT | The event is older than Google's conversion upload window. |
CONVERSION_PRECEDES_EVENT | The conversion timestamp is before the click it is attributed to. |
DUPLICATE_ORDER_ID | Google already received this order id and deduplicated it. |
UNPARSEABLE_GCLID | The click identifier is malformed. |
INVALID_USER_IDENTIFIER | A hashed identifier is not in the format Google expects. |
On Meta, DISCARDED_BY_META and STALE_EVENT_SKIPPED are the ones you will see most.
See also
- How Signal Syncs Work — what a sync actually does
- Execution History — the full run history for a signal
- Manage Signals — the rest of the signal detail page
- Google Ads · Meta Ads — destination setup