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

1. Open a signal and go to the Destinations tab.
2. Each destination row has an analysis cell with a 7-day conversions sparkline and a health pill: Healthy, Watch, Needs attention, or No data.
3. 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.

note

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	✅
Microsoft Ads — Offline conversions	✅
Microsoft Ads — Enhanced conversions (UET tag)	❌ — the UET goal also counts the site's own tag, so its figures cannot be tied to what BPP sent
Generic API Endpoint, Google Analytics 4, OpenAI 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 every platform. The fifth is not — and the difference matters.

Tile	Google Ads	Meta Ads	Microsoft 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.	Share of sent conversions Microsoft Ads recorded on the goal. Attributed by click date, so recent days keep moving.
Events sent	Events BPP sent in the window.	Events BPP sent in the window.	Conversions 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.	Conversions Microsoft recorded on the destination's goal, by click date. BPP re-reads the last 90 days on every refresh, so late attributions are picked up.
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.	Conversions Microsoft rejected at upload, plus the ones BPP held back because Microsoft would have refused them. Diagnostic only.
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.	Attribution rate — share of accepted conversions Microsoft matched to an ad click, as Microsoft reports it per upload day. Reported by Microsoft.
Last push	Timestamp of the most recent event BPP sent.	Timestamp of the most recent event BPP sent.	Timestamp of the most recent conversion BPP sent.

warning

The fifth tile is a BPP estimate on Google and a platform measurement on Meta and Microsoft. They are not comparable across platforms, and the Google one should not be quoted as if Google had reported it.

note

On Microsoft Ads, accepted is not attributed. Microsoft answers each upload synchronously and accepts conversions it will later fail to match to any click — typically those without a Microsoft Click ID (msclkid). The reconciliation rate and the attribution rate are where that gap shows.

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.
• Microsoft Ads setup checks — on a Microsoft Ads destination the pill reads Setup status (Setup OK / Setup needs attention) instead of the diagnostics status, and BPP reads the goal and account settings on every refresh. Each finding names what to fix:
  • Conversion goal not found — the goal selected on the destination no longer exists.
  • Conversion goal was renamed — Microsoft matches uploads by goal name, so a renamed goal rejects every conversion until the destination is updated.
  • Conversion goal is not active — a paused or inactive goal records nothing.
  • Conversion goal isn't recording — Microsoft reports no conversions on the goal in the last 7 days.
  • Enhanced conversions are off — BPP sends hashed email or phone, but the goal ignores them and can match only on the Microsoft Click ID.
  • Microsoft Click ID auto-tagging is off — new clicks carry no msclkid to match on.
  • Conversion window may be too short — at least 5% of recent conversions matched a click older than the goal's window.
  • Goal counts one conversion per click — informational: repeat conversions from the same click are not added.
• 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_FOUND counts 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.

On Microsoft Ads the selector is Compare with conversion goal and lists the account's goals. Goals marked (UET tag) count what the site's own tag recorded, not what BPP uploaded — useful as a reference for volume, not as a like-for-like comparison.

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.

Why conversions were not attributed (Microsoft Ads only)

Microsoft's own verdict on the conversions it accepted: how many it attributed to an ad click and, for the rest, why not. Figures are reported by Microsoft per upload day, more than 20 hours after the upload, so the most recent days fill in later.

Reasons — Reason, What it means, Conversions, % of uploaded, Where to fix it. The ones you will see most:

Reason	Usually means
NoMatchingClickFound	No Microsoft ad click matches the Click ID, email or phone sent — most often the customer never clicked a Microsoft ad.
MissingMatchIdentifiers	The conversion had no Microsoft Click ID, and its hashed email or phone matched no click either. Email-only conversions rarely match on Microsoft.
OutsideGoalLookbackWindow	The matching click is older than the goal's conversion window.
AccountMismatch	Clicks were found, but in other Microsoft Ads accounts.
DuplicateConversionKey	Microsoft already had this conversion and kept the first copy — usually harmless.

By upload day — Upload day, Sent, Attributed, Not attributed, Attribution rate, Status. A day BPP uploaded on but Microsoft has not reported yet shows Pending for up to two days, then Not reported by Microsoft — never as 0%.

If Microsoft attributed everything, the card reads All uploaded conversions were attributed.

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 and Microsoft's offline conversion upload are synchronous and have 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.

note

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.

On Microsoft Ads, codes are Microsoft's own error names, kept verbatim (for example OfflineConversionMicrosoftClickIdNullOrEmpty, OfflineConversionMicrosoftClickIdInvalid, ClickIdDateTimeOutsideGoalConversionWindow, ConversionTimeEarlierThanClickTime). Codes BPP sets itself when it holds a conversion back because Microsoft would refuse it — INVALID_EVENT_TIMESTAMP, STALE_EVENT_SKIPPED, FUTURE_EVENT_SKIPPED, NO_USABLE_IDENTIFIER — and BATCH_REJECTED_<reason> when Microsoft refused a whole upload (for example an expired token or a rate limit).

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 · Microsoft Ads — destination setup