Signal Export
A Signal Export pushes conversion event data from your data warehouse to an ad platform for offline conversion attribution, enhanced measurement, and value-based bidding.
How it works
- BPP reads your event table and applies the signal's trigger filters (e.g., rows where
Stage = Closed Won). - For each qualifying event, BPP:
- Looks up the user identifiers (email, phone, click IDs) configured for the destination.
- Computes the conversion value using your formula.
- Builds the platform-specific payload.
- BPP sends the events to the destination platform in batches.
- The sync result (events processed, events failed, latest event date, timestamp) is saved to Sync History.
What gets sent
| Destination | Data sent |
|---|---|
| Google Ads Enhanced Conversions | Conversion action, event timestamp, Order ID (optional), value, hashed identifiers |
| Google Ads Conversion Adjustment | Conversion action, Order ID, restated value |
| Google Ads Store Sales | Conversion action, event timestamp, value, hashed identifiers |
| Meta Ads Conversions API | Pixel, event name, value, currency, hashed identifiers |
| API Endpoint | Custom metric fields with your formula-computed values, plus user identifiers |
Incremental syncs — no duplicate sends
Signal exports track the latest event date processed. On each run, BPP only picks up events newer than the last successful push. This prevents the same conversion event from being sent to the ad platform twice.
Each destination independently tracks its own high-water mark, so if one destination is paused or fails, the others continue independently.
Order ID deduplication
For Google Ads Enhanced Conversions, you can send an Order ID with each event. If your site pixel and BPP both send the same conversion event with the same Order ID, Google Ads will count it only once. This prevents double-counting in your conversion reporting.
Using Order ID is strongly recommended when your site pixel and BPP might both send the same lead or purchase event.
Scheduling
Signal syncs run daily by default. The signal must be in Ready status (enabled) for runs to execute.
Partial syncs
If some events fail to push (e.g., a missing required identifier or a platform rejection), the destination moves to Partial Complete status. The events that were successfully sent are still counted — a partial failure does not cancel the whole sync.