What happens to a conversion after capture. How it is stored, retried, recovered and counted, and the point at which Converly stops trying.
After detecting a conversion, deduplicating it and then normalising and hashing the data, Converly sends the conversion off to your chosen ad platforms and analytics tools.
How conversions are delivered to ad platforms and analytics tools
The two ways a conversion reaches a platform
Ad platforms accept conversions in two different ways, and they actually recommend you send a single conversion both ways to maximise the chance it makes it to the ad platform (which is what Converly does):
- From the visitor's browser. If you have the platform's native tracking code installed on your site (i.e. the Google Tag or the Meta Pixel), then the Converly tracking script you place on your site calls the platform's native tag and tells it a conversion happened. Because the platform's native tag sees the visitor directly, it can capture the click identifiers, cookie data, etc itself.
- From our servers. Converly sends the same conversion to the platform's API from our own servers, and includes information about the lead (like their name, email, phone, any click identifiers they had, IP address, user agent, etc).
The whole idea is that by sending the conversion through both paths at the same time, you get a much better delivery rate (a conversion just sent through the visitor's browser won't work whenever an ad blocker, a privacy setting or a closed tab stops the tag from running).
The ad platforms then deduplicate them based on a shared identifier that Converly sends with each conversion. You can read more in the Deduplication article.
The table below breaks down how a conversion reaches each of the destinations Converly supports:
| Destination | Browser | Server | Notes |
|---|---|---|---|
| Google Ads | yes | yes | |
| Meta | yes | yes | |
| GA4 | no | yes | Sent server-side only, deliberately. GA4 reliably deduplicates purchases and not much else, so firing both would double count your leads. |
| yes | yes | Needs a conversion rule for each leg. With only one, only that leg can fire. | |
| TikTok | yes | yes | |
| yes | yes | ||
| ChatGPT Ads | yes | yes | |
| Microsoft Ads | yes | yes | |
| Snapchat | yes | yes | |
| yes | yes | ||
| X Ads | yes | yes | |
| AdRoll | yes | yes | |
| Taboola | yes | yes | |
| Plausible | yes | no | |
| Fathom | yes | no | |
| Pirsch | yes | no | |
| GoSquared | yes | no | |
| Simple Analytics | yes | no |
What information gets sent
Browser-side
The browser-side conversion is a call to the platform's own tag, so most of what the platform ends up recording comes from the tag itself rather than from Converly. The tag already knows the visitor, the page they're on, their browser, and any data it has stored in its own cookie (like its own click identifiers).
What Converly sends is:
- The conversion or event name you chose when setting up the conversion
- The value and currency you chose for the conversion
- The identifier that ties the browser-side conversion to the server-side one, so the platform can recognise the two as a pair.
The platform's tag then adds its own click identifiers, cookies and page context, and sends the conversion to its own servers.
Server-side
Conversions are sent to each server-side destination using their API (typically called the Conversions API, or CAPI for short). The API call to each destination is sent one after another, so every result is recorded before the next destination is attempted. Each call carries:
- The conversion you chose for that destination, covered in Destinations.
- The value and currency, when your flow carries them.
- The time the conversion happened, and the identifier that ties it to the browser-side conversion.
- The lead's details, formatted and hashed the way that platform requires, covered in Normalization and hashing.
- The click IDs and browser identifiers that platform accepts, covered in Click IDs.
- The visitor's IP address and user agent, and the page they converted on with any query string removed.
GA4 is the exception, because it matches conversions to the visitor's Google Analytics session rather than to the lead's contact details. So for GA4, we send the client and session identifiers read from the visitor's own Google Analytics cookies instead.
Exceptions
A few things work differently to the general pattern above:
- Conversions from certain form tools and scheduling widgets are only ever sent server-side. Converly only ever sends a conversion when the form submission/meeting booking is confirmed successful, and certain form tools and scheduling platforms only confirm success later on via an API call that Converly makes to the platform. And we can't fire a browser-event from a server. We send all relevant data with the server-side conversion anyway so this has no impact on the accuracy of your conversion tracking, it's just worth mentioning. See Conversion detection for more information.
- No platform tag on the page means no browser-side conversion. Converly fires into the tag you already have rather than loading a second copy of it (because two copies of the same tag cause problems of their own). So if you don't have the platform tag on your website already (i.e. you don't have the Google Tag or the Meta Pixel installed), then sending the conversion browser-side is skipped. All relevant data is still sent with the server-side conversion though, so this has no impact on the accuracy of your conversion tracking.
- A visitor with Global Privacy Control turned on isn't tracked at all. Global Privacy Control is a signal some browsers send on the visitor's behalf, telling every website they visit not to sell or share their personal information. Brave and DuckDuckGo send it by default, Firefox has a setting for it, and several US state privacy laws require websites to honour it. When the Converly tracking script sees that signal, it switches itself off for that visit before doing anything else. No cookies are set, nothing is captured if they submit a form, and nothing is sent to us or to your ad platforms. You won't see a failed conversion in your event log for these people, because there was never a conversion recorded in the first place. This applies to every site running Converly and cannot be turned off.
- A visitor who hasn't agreed to advertising cookies isn't tracked either. This only applies if you've connected a consent platform (in other words, a cookie banner) to Converly. When you have, Converly checks what the visitor chose at the moment they convert. If they declined advertising cookies, or they haven't answered the banner yet so there's no answer to read, then the conversion isn't recorded or sent anywhere, browser-side or server-side. Converly re-checks on every conversion rather than trusting an earlier answer, so if that same visitor later accepts, their next conversion is tracked normally. If you don't have a consent platform connected to Converly, none of this applies and nothing is blocked.
How failures are handled
How we know whether a send worked
Not every platform tells you the truth in its response. Some report success for a conversion they didn't really accept, and others accept everything up front and only check it properly later. So Converly doesn't simply trust the status code that comes back. Where a platform puts the real result inside the response, Converly reads that instead.
The table below shows what Converly treats as a successful send for each destination, and what that success does and doesn't tell you.
| Destination | How success is determined | Notes |
|---|---|---|
| Google Ads | Google's API returns a 200 success response | Google accepts the conversion but doesn't actually check the details until afterwards. If it finds anything wrong then a message appears in the Diagnostics section of Google Ads within 24 hours. |
| Meta | Meta's API returns a 200 success response | Meta accepts the conversion but whether the conversion was matched to a Meta user is reported separately, as Event Match Quality in Events Manager. |
| GA4 | GA4's API returns a 204 success response | GA4 returns that for every event it receives, even a malformed one, so the response proves nothing on its own. So Converly checks each event against Google's rules before sending it to make sure it isn't malformed. |
LinkedIn's API returns a 201 success response | LinkedIn will accept the conversion but it only appears in your reporting if LinkedIn is able to match it back to an actual ad click. | |
| TikTok | TikTok's API returns a 200 success response with a result code of 0 inside it | TikTok reports most errors inside a success response, so the status code on its own can't be trusted. Converly reads the result code in the body instead. |
Reddit's API returns a 200 success response | Reddit will accept the conversion, but it will only appear in your reports if it gets matched it to an ad click. | |
| ChatGPT Ads | The ChatGPT Ads API returns a 200 success response | ChatGPT Ads doesn't validate the data at ingestion, so you could send junk data and it would never tell you it's wrong. So Converly checks every field itself before sending |
| Microsoft Ads | Microsoft's API returns a 200 success response with no errors | Microsoft accepts the conversion even if some details are invalid (like badly formatted email). It drops that detail and says so only as a warning inside the success response. So Converly reads those warnings and alerts you if a conversion arrived with less than it should have. |
| Snapchat | Snapchat's API marks the conversion as valid | |
| Pinterest's API returns a success result for the conversion | Pinterest reports the outcome in the body of its response rather than in the status code, so a conversion can fail while the response itself looks fine. Converly reads that result rather than the status code. | |
| X Ads | The X API reports the number of conversions processed and it matches the number Converly sent | X doesn't return errors, so the count is the only signal it gives that the conversion was taken. |
Converly keeps each platform's full response against the conversion, including any trace ID the platform returned (such as Meta's fbtrace_id), which is the first thing their support teams ask for. Sites set to store no personal data don't keep the response.
Failed sends are retried automatically
A send that fails for a temporary reason (server errors, timeouts, rate limits, network failures, etc) is retried up to 3 times in total, with a short pause between attempts.
A rejection that will never succeed, such as a malformed conversion or a revoked credential, fails immediately rather than burning retries.
Some of that classification is platform specific and not obvious. Meta, for example, reports rate limiting inside an HTTP 400, which naive code treats as a permanent rejection and gives up on. Converly reads the body and retries it.
Nothing is left behind
The retries mentioned above handle the situation where an ad platform or analytics tool is down, but they do not handle a situation where Converly itself is down.
To make sure that is handled, a recovery job sweeps every 5 minutes, finds any conversion that was interrupted, and picks it up again. While a conversion is being sent it is claimed by one of our servers for 15 minutes, so two servers can never be sending the same conversion at the same time. And if one of our servers drops out after a platform has accepted a conversion but before the result was recorded, the copy that gets sent again carries the same identifier, so the platform recognises it and discards it.
Retries don't result in duplicate conversions
Every conversion is given its own identifier in our database as soon as it happens, and every attempt to send it carries that same identifier rather than a new one.
Retrying stops as soon as the conversion is delivered successfully, so in the normal case the platform only ever receives the conversion once. But in rare cases the ad platform's success message may not make it back to us, so the retry system will continue to send the conversion.
In this case, the ad platform receives the same conversion twice, but because the same identifier is sent with each retry, the ad platform recognises it's a duplicate and discards it.
Our article on Deduplication covers the full set of protections, including what happens on the few platforms that don't deduplicate this way themselves.
One platform failing does not block the others
A single conversion flow in Converly can send a conversion to several destinations. Each destination is attempted independently and recorded independently, so if a flow sends to 4 platforms and one rejects the event, the other 3 still receive it.
The conversion itself is still marked as failed when that happens, rather than partially delivered, so one destination failing is never hidden behind the three that worked. You can always see which destination did what in the logs. Reading the event log covers the per-destination detail.
When Converly gives up, it says so
Retries and recovery do not continue forever. A conversion that cannot be delivered within about an hour is marked as failed and stops.
A conversion that reaches this point stays visible in your event log with the reason it failed. The goal is to alert you of the issue (i.e. a platform needs reconnecting) so you can fix it. Our support team can replay conversions back into ad platforms and analytics tools when asked, so once you have fixed the issue you can contact us and we can resend the conversions to your chosen ad platforms and analytics tools (with the original timestamps so they appear in your reporting for the correct dates).
How long you have to do that is set by the platforms rather than by us, because each one refuses conversions past a certain age:
| Destination | Limit | Measured from | Notes |
|---|---|---|---|
| Google Ads | 90 days | The ad click | Or 63 days when the conversion carries the lead's contact details, which Google calls enhanced conversions for leads. |
| Meta | 7 days | The conversion | |
| GA4 | 72 hours | The conversion | An older event is still accepted, but GA4 records it as having happened 72 hours ago. |
| 90 days | The conversion | ||
| ChatGPT Ads | 7 days | The conversion | |
| Microsoft Ads | 7 days | The conversion | |
| Snapchat | 7 days | The conversion | |
| None published | Pinterest asks for conversions to be sent within an hour of happening, but doesn't publish a limit. | ||
| X Ads | None published |