Exactly what Converly captures from a form submission, what it never touches, what leaves our systems, and how long any of it survives.
In order to report a conversion to an ad platform, we need to capture and send information about the lead so the ad platform can match the conversion back to a real person and the original ad they clicked.
This means that Converly is capturing and sending personally identifiable information about the leads that come through your website, and in this article we outline what gets captured and how it's handled.
What data is captured
When someone completes a form, Converly captures the fields needed to report and match the conversion.
Typically that includes the lead's name, email and phone number, but it depends on what you actually ask for on your form (if you don't ask for the lead's phone number on the form then we can't capture it).
Converly also captures the ad click identifier that brought the visitor to the site, the first page they landed on, the page they were on when they converted, and the referrer.
What is never captured
Some fields are skipped before their value is ever read. This includes:
- Passwords, in any field marked as a password or labelled as one.
- Card numbers, security codes, expiry dates and cardholder names.
- One-time codes, PINs and social security numbers.
- Honeypot fields that form builders add to catch bots, which are recognised and ignored.
Information in skipped fields is never read nor stored, so it isn't available in Converly or sent to any ad platform or analytics tool.
Where it's stored and how it's protected
Conversions are stored in a PostgreSQL database hosted by Supabase, and Converly itself runs on Railway. Both are in the United States.
The database is encrypted at rest by Supabase, and everything travelling to or from Converly goes over HTTPS. That includes every call we make out to an ad platform or analytics tool. There is no path anywhere in Converly that sends your data over an unencrypted connection.
Your ad platform credentials are kept apart from your conversion data. When you connect Google Ads or Meta, the token goes into a dedicated encrypted vault rather than into the database alongside your conversions, and the database only holds a reference to it. That credential is never returned by any API, never included in a response, and cannot be retrieved by an AI assistant connected to your account. Security and access covers that side of things properly, including what an API key can do and what we don't yet have.
How contact details are hashed before sending
Before contact details are sent to an ad platform, Converly hashes them with SHA-256 wherever that platform requires it, so Google and Meta (for example) receive a fingerprint rather than a plain-text email address.
Each platform requires its own normalization before hashing, and our article on Normalization and hashing covers the per-platform rules.
How long data is retained for
The following table shows how long each type of data in your account is held for.
| What | How long | What happens |
|---|---|---|
| Raw contact details | 7 days | Name, email and phone are erased from the conversion record by a scheduled job, along with the full request and response exchanged with each platform. This is a privacy purge, not a retry window. Delivery finishes long before it. |
| The conversion record | 30 days | Deleted entirely. That includes the IP address, the user agent, and the operational detail of what was sent where and what each platform said. |
| Your flows and settings | Until you delete them | Configuration is not visitor data and is not on this schedule. |
Both jobs run on a schedule rather than on demand, so retention does not depend on anyone remembering to run anything.
Privacy signals and cookie consent
Converly works with all the most popular cookie consent tools as well as honouring browser-level settings.
Working with your cookie banner
Converly reads consent from the cookie banner you already run.
You connect your consent platform to Converly and then every time a visitor lands on your site, Converly checks what that visitor chose before capturing or sending any information to ad platforms and analytics tools.
Once connected, here is what happens:
- A visitor who accepts advertising cookies is tracked. If a visitor accepts advertising cookies, then Converly works as normal. It listens for conversions, collects all the data, fires the browser-side conversion, sends the data to our own servers, and then sends the server-side conversion to your chosen ad platforms and analytics tools.
- A visitor who declines advertising cookies is not tracked. If a visitor declines advertising cookies, then nothing is captured and nothing is sent (on either the browser path or the server-side one). You will not see a failed conversion in the conversion logs either, because there was never a conversion recorded.
- An unknown answer counts as no. If the banner has not loaded yet, or Converly cannot read a clear answer from it, that is treated as a refusal rather than as permission. This is the safer option legally.
- Withdrawing consent takes effect immediately. Converly re-reads the visitor's choice when a conversion happens rather than trusting an answer it read earlier. So someone who accepts advertising cookies but then changes their mind before converting is not tracked.
- Analytics and advertising are treated separately. Each destination in your flow carries its own category. A visitor who accepts analytics cookies but declines advertising ones still generates a GA4 conversion, and does not generate a Google Ads one.
- The real consent state travels with the conversion. Google's conversion APIs accept the Consent Mode v2 signals
ad_user_dataandad_personalization, and Converly sends the visitor's actual answer rather than assuming permission. Google's own documentation warns that conversions uploaded without these may not be attributable at all, so this matters for your reporting as much as for your compliance.
Some tools imply that sending a conversion from a server rather than from the browser gets you around a visitor declining cookies, on the grounds that no cookie was involved. That is not how the rules work. European regulators have been explicit that reading information from someone's device and sending it on to a server is covered regardless of whether a cookie was the mechanism, and Google's own terms separately require consent for visitors in the EEA, the UK and Switzerland no matter how the conversion reaches them. Google also discards data it knows was collected without consent, so sending it anyway does not even win you the conversion.
Server-side delivery is genuinely valuable, and it recovers conversions lost to ad blockers, closed tabs and browser restrictions. It does not recover conversions lost to someone saying no, and any vendor suggesting otherwise is selling you a compliance problem rather than a measurement one.
Honouring browser-level privacy settings
Separately from your cookie banner, some visitors carry a privacy setting in the browser itself. It applies to every website they visit rather than to yours specifically, and Converly honours it.
That signal is called Global Privacy Control. Brave and DuckDuckGo send it for every user by default, Firefox has a setting for it, and Chrome users can add it with an extension. When it is switched on, the browser attaches a flag to everything that visitor does, and any website is able to read it.
It carries real legal weight, which is what separates it from older browser signals. States like California, Colorado and Connecticut all treat it as a binding opt-out of selling or sharing someone's personal information. So a visitor who switches it on has essentially opted out of every website they will ever visit, in a single action.
Here's how Converly handles visitors with the Global Privacy Control flag turned on:
- No data is captured. If the signal is present, the tracking script stops completely. No conversions are captured and no data is sent to any of your ad platforms or analytics tools.
- It overrules your cookie banner. Converly checks the browser signal first, before it looks at your consent platform at all, so if a visitor has Global Privacy Control switched on but then clicks Accept on your banner, they are still not tracked. This is the legally required position because several countries and states treat Global Privacy Control as a binding opt-out (regardless of what they say in your cookie banner).
- No conversions appear in the conversion log. Because the conversion is never recorded in the first place, it won't appear in the log. Worth noting because the lead will likely still appear as a form submission in your form tool, or as a booked meeting in your scheduling tool.
Deleting a specific person
A visitor exercising their right to erasure can be removed by email or phone number through a single endpoint, and the deletion works across the whole retention window rather than only on records still holding raw details.
This only deletes data that Converly holds though. It does not delete data an ad platform has already received, which has to be requested from that platform directly.
Where data is not written
Personal data is kept out of logs and crash reports deliberately, and not only by filtering field names. Free text is scrubbed too, because ad platforms routinely include a customer’s email address inside their own error messages, which no field-name filter would ever catch.
Switching to privacy mode
If you need to pass an IT security review in order to use Converly, then one option is to switch your site to privacy mode. In this mode, no personally identifiable information is ever written to the conversion log in the first place.
This ultimately means that Converly never actually stores your lead data, and IT teams are generally much happier with this posture.
The personally identifiable information is still sent to ad platforms with each conversion so there is no impact to the accuracy of your conversion tracking, it's just that the conversion log will not show the lead's name, email, phone, etc.