Conversion Sending
Pruuv automatically sends matched conversions back to your ad platforms — Meta CAPI, Google Conversion Upload API, and TikTok Events API. This closes the attribution loop, so the platforms have accurate revenue data to optimise your campaigns against.
How it works
Conversion sending is fully automatic. Once a funnel event is received (via the Pixel SDK or webhook), Pruuv:
- Works out which ad account the lead came from, using the ad IDs in the lead's own tracking parameters (UTMs)
- Sends the conversion to that account only — never to an account the lead is not matched to, and never to another platform
- Posts it to the platform's API with all available matching signals
- Records the latest send attempt for each lead and ad account (success or failure) in the conversion audit log
A conversion is only ever sent back to the ad account the lead is matched to. A lead we cannot match to one of your ad accounts — an organic visit, an email click, or a lead from an account you have not connected — is not sent anywhere, so a platform is never credited with a conversion its ads did not cause. If a lead's match is later corrected (for example after you re-attribute history), the corrected account receives it too; a conversion already sent cannot be taken back.
Sending runs as soon as a lead is matched to its ad account. For Meta and TikTok that is usually within about 15 minutes of the lead arriving, and for Google within about 45 minutes — later if the ad the lead came from has not been synced into Pruuv yet. A Meta or TikTok send that fails is retried with a growing wait (up to six attempts over about 31 hours); Google retries on its 30-minute batch. You can monitor individual send statuses from the Pruuv dashboard, and its Not sent view lists each lead that was not sent, with the reason.
Platform setup
Meta (Facebook) CAPI
Meta uses the Conversions API (CAPI) to receive server-side conversion events. This complements the Meta browser pixel and is required for accurate attribution in a world with browser tracking limitations.
| Signal | Source | Impact on match quality |
|---|---|---|
| Pixel ID | Connections > [Meta account] > Conversion settings | Required — identifies your Meta dataset |
| fbc cookie | Pruuv Pixel captures automatically from fbclid URL param | High — direct click match |
| fbp cookie | Pruuv Pixel creates it (or reuses the one Meta’s own pixel set) | Medium — browser identity |
| Email hash | Your CRM’s webhook (email or email_hash), or the email option of Pruuv.track(stageId, token, { email }) | High — audience match signal |
| Phone hash | Your CRM’s webhook (phone or phone_hash), or the phone option of Pruuv.track(stageId, token, { phone }) | High — audience match signal |
| IP address | The visitor’s browser request (Pruuv Pixel), or client_ip_address sent by your CRM | Medium |
| User agent | Pruuv Pixel captures navigator.userAgent automatically | Low |
The Pixel ID links the server-side event to your Meta dataset. Find it in your Meta Events Manager under the dataset connected to your ad account.
fbc — email and phone hash signals alone can produce good match rates. For best results, use all available signals together. The Pruuv Pixel captures fbc, fbp, and user_agent automatically. Call Pruuv.identify() when the visitor fills in your form, so Pruuv can add them to the lead your CRM sends, and send the email and phone with each lead for the strongest match.Google Ads — Conversion Upload
Google uses the Ads API Conversion Upload endpoint to receive click-matched conversions offline. This is the server-side equivalent of the Google Ads tag and is required for offline conversion tracking (e.g. leads that convert in a CRM after the initial form fill).
| Item | Where it comes from |
|---|---|
| Conversion Action ID (required) | Connections > [Google account] > Conversion settings > Conversion Action ID |
| OAuth token (required) | Connected automatically via Google OAuth — stored securely in Vault |
| gclid / wbraid / gbraid | Captured automatically by the Pruuv Pixel on the landing page. Without one, a lead dated from 22 Oct 2026 is sent with its hashed email or phone (see below) |
| click_timestamp (optional) | Captured by the Pruuv Pixel. Used only to keep the reported conversion time after the click |
The Conversion Action ID identifies which conversion action in your Google Ads account the event maps to. Create a conversion action of type "Import" in Google Ads and copy the ID from the action settings.
TikTok — Events API
TikTok's Events API allows server-side conversion events to be sent to your TikTok Pixel for attribution and campaign optimisation.
| Item | Where it comes from |
|---|---|
| Pixel Code (required) | Connections > [TikTok account] > Conversion settings > Pixel Code |
| Access Token (required) | Connected automatically via TikTok OAuth — stored securely in Vault |
| ttclid | Captured automatically by the Pruuv Pixel on the landing page. Improves the match; a hashed email or phone also works |
The Pixel Code identifies your TikTok Pixel. Find it in TikTok Ads Manager under Assets > Events > Web Events.
Click ID requirements by platform
A conversion is sent to an ad account only when all four of these are true. The first is absolute: no combination of signals overrides it.
- The lead was matched to that ad account. The match reads the lead's own tracking parameters: for Meta and TikTok it needs the ad ID; for Google Search the ad group ID; for Performance Max and other campaign-level Google types the campaign ID, together with the
utm_mediumthat names the type. A lead from another account, or from no paid ad at all, is not sent — and a deal stage synced by a Pruuv CRM connector carries only the source and campaign (no ad ID and noutm_medium), so it is not sent to any platform. - The lead's funnel stage is mapped to a platform event on that ad account (see below).
- The event is recent enough: Pruuv sends Meta events up to 7 days old and TikTok events up to 28 days old. Meta rejects older events, and 28 days is TikTok's longest attribution window. The age runs from the event time; for a deal synced from your CRM that is the deal's creation date.
- The lead carries something the platform can match on — the table below.
| Platform | Primary click ID | Works without click ID? | Fallback signals |
|---|---|---|---|
| Meta | fbc (from fbclid) | Yes — with a hashed email or phone | email hash or phone hash (without fbc, one of them is required); fbp, external_id, name/DOB/postcode hashes, city/state/country, gender, IP address and user agent improve the match but cannot replace them |
| gclid or wbraid or gbraid | Yes — with a hashed email or phone, for a lead dated from 22 Oct 2026. The Google Ads account must also accept the customer data terms and turn on Enhanced Conversions for Leads | email hash, phone hash | |
| TikTok | ttclid | Yes — lower match score | email hash, phone hash |
Using CRM and Pixel together
The best conversion data comes from combining a server-side CRM webhook (which has revenue, demographics, and a stable reference ID) with the Pruuv Pixel (which has fbc, fbp, gclid, ttclid, and hashed PII).
Order matters. Call Pruuv.identify() when the visitor fills in your form, before your CRM sends the lead. When the lead arrives, Pruuv finds the visitor by email hash or reference and adds the click IDs, browser details and location the lead is missing — before it sends the conversion. See Pixel SDK → How Pruuv links the pixel to your CRM.
Browser data that arrives later is still added, without overwriting anything already stored: Pruuv re-checks leads up to 7 days old every 30 minutes, and a Pruuv.track() call with the same stage and reference fills in the fields the stored lead is missing (an enrichment merge). But a conversion that was already sent is not sent again, so Meta and TikTok may have received it without the click ID, which gives a weaker match.
Per-stage conversion configuration
Each funnel stage you want sent must be mapped to a platform event, one mapping per stage per ad account — for example a Purchase event from your Sale stage and a Lead event from your Enquiry stage. A stage with no mapping is not sent at all; there is no default event name, because one would count the same person once per stage they passed through. Google additionally uses the connection-level Conversion Action ID unless the stage overrides it.
You can also disable conversion sending entirely for a specific platform on a specific stage — useful if a stage represents an internal milestone you do not want sent to ad platforms.
Stage-level conversion config is set in Connections > Funnel stages > [Stage] > Conversion sending.
Deduplication
Meta and TikTok count a browser pixel event and a Pruuv event as one when both have the same event name and the same event ID. Pruuv picks the event ID for each event in this order:
- The event's
item_reference, when the destination's Event ID is set to Item reference — for example a claim number your site also uses. - The event ID your pixel used, when it reached Pruuv: through
identify()for the lead, or asevent_idwithtrack()or your webhook post for any stage. One ID belongs to one lead: if several events carry it, only the earliest sends it. - Pruuv's own event ID.
Google always receives Pruuv's own event ID as its order ID. See Pixel SDK → Stop Meta and TikTok counting an event twice.
Audit log
Every outbound conversion send — whether successful or failed — is recorded in Pruuv's conversion audit log. Each record includes the platform, status, error message (if any), timestamps, retry count, the exact request payload Pruuv posted and the platform's full response. This log is available to agency staff in the Pruuv dashboard as the Event Delivery log — searchable by reference or email address — and can be used to diagnose attribution issues without opening the database.