Which advertising identifiers Converly captures, where they are stored, how long they last, and which one is sent with a conversion.
When a visitor clicks one of your ads, ad platforms like Google & Meta append a click ID to the end of the URL they land on.
So instead of clicking an ad and landing on https://converly.io, visitors actually land on https://converly.io?gclid=123456789.
There are unique identifiers for every click on every ad platform, and the idea is that if you can capture them and pass them back with the conversion, then the ad platform can use it to match the conversion to the original ad click with 100% confidence.
Identifiers Converly captures
To help improve the accuracy of your conversion tracking, Converly captures these identifiers, stores them in a cookie in the visitor's browser, and then passes them back to the ad platforms with each conversion.
The below tables outline the identifiers that Converly captures:
Captured on arrival
| Identifier | Platform | Description |
|---|---|---|
| gclid | Google Ads | Standard Google Ads click identifier. |
| gbraid | Google Ads | Used for app and web journeys on iOS where gclid is often absent entirely. |
| wbraid | Google Ads | Used for web-to-app journeys on iOS, same reason. |
| fbclid | Meta | Stored in the format Meta’s own pixel uses, so both agree on the value. |
| ttclid | TikTok | Sent with the server-side conversion. |
| rdt_cid | Paired with the Reddit pixel’s visitor identifier where one exists. | |
| li_fat_id | Present on ad landing pages when the advertiser has enhanced conversion tracking enabled. LinkedIn’s own tag does not need to be installed. | |
| oppref | ChatGPT Ads | Kept for the platform’s own 30 day window rather than the default. |
One further identifier is generated rather than captured. _fbp is Meta’s browser identifier, and Converly creates it in Meta’s own format when it is absent, because Meta counts it toward match quality. It is the only platform-owned identifier Converly writes rather than only reads. Every other one is left alone, as set out below.
Pulled from the platform's own tag
Several platforms set their own browser identifier through their own pixel. Where one is present, Converly reads it and passes it along to improve matching. It does not create these, so if you do not run that platform’s pixel on your website the value is simply absent.
| Identifier | Platform | Description |
|---|---|---|
_rdt_uuid | Set by the Reddit pixel. Sent alongside the Reddit click identifier. | |
_ttp | TikTok | Set by the TikTok pixel. |
__obref | ChatGPT Ads | Set by OpenAI’s pixel. Converly deliberately does not create this one, because doing so would set a long-lived identifier on every page of every site including those with no ChatGPT Ads destination, and OpenAI’s own coverage metric does not count it. |
_ga | GA4 | Google Analytics client identifier, taken from the last two segments of the cookie value. |
_ga_<stream> | GA4 | Google Analytics session identifier. There is one of these per GA4 property, so the cookie jar is scanned for the pattern rather than a single fixed name. |
How identifiers are stored
Converly stores identifiers in first-party cookies in the visitor's browser.
How cookies are scoped
A cookie set on example.com cannot normally be read on app.example.com because, as far as the browser is concerned, those are two separate places.
This presents a problem because it's common for someone to click your ad, land on your marketing site (i.e. example.com), and then convert on a subdomain (like app.example.com). And if the cookie can't be read on the subdomain (i.e. app.example.com) then the click ID can't be retrieved and sent with the conversion.
So Converly sets its cookies across your whole domain rather than on the single subdomain the visitor happened to land on. So if someone clicked your ad and arrived on example.com, then read something on blog.example.com, and finally converted on app.example.com, their click ID follows them the whole way.
To do that, Converly has to work out which web address actually belongs to you. For app.example.com that is example.com. For shop.example.co.uk it is example.co.uk, because co.uk is a shared ending that nobody owns, in the same way nobody owns .com.
There is a published list of those shared endings, and Converly checks your domain against it before setting anything. That is what stops a cookie ever being set wider than the domain you actually own.
How cookies are stored
The cookies are stored under 3 different naming conventions depending on whether we created the cookie, whether it's shared with the platform's own pixel, or whether it's owned entirely by another tag.
| Name | Type | Description |
|---|---|---|
_converly_* | Our Storage | Used when the platform doesn't store the click identifier in a cookie of its own. For example _converly_gclid for storing the Google Click ID (GCLID) or _converly_ttclid for storing the TikTok Click ID. Namespaced so it cannot collide with anything else on your site. |
| Platform's own name | Shared | Used when the platform's pixel/tag creates its own cookie. We use this rather than creating our own to ensure there's no mismatch. This includes _fbc & _fbp (Meta Ads) as well as __oppref (ChatGPT Ads). |
Each identifier is stored with its own lifetime. Generally speaking, most are kept for 90 days, but our ChatGPT Ads integration follows OpenAI's shorter click window and only stores the identifier for 30 days, whereas the cookies set by another platform's own pixel (such as _ga for Google Analytics) keep whatever lifetime that pixel gave them.
| Platform | Stored For | Description |
|---|---|---|
| Google Ads | 90 days | Applies to gclid, gbraid and wbraid. |
| Meta | 90 days | Applies to _fbc and _fbp. |
| TikTok | 90 days | Applies to ttclid. |
| 90 days | Applies to rdt_cid. | |
| 90 days | Applies to li_fat_id. | |
| ChatGPT Ads | 30 days | Matches the platform’s own click window. The original capture time is stored separately, so the window stays fixed rather than extending each time the visitor returns. |
Campaign parameters (like utm_medium, utm_source, etc) are stored for 90 days, as is the lead's initial landing page and referrer (which are captured on a first-touch attribution basis).
Which identifiers are sent
Each platform accepts a different set of identifiers, and the ones that travel with a conversion are selected at send time from whatever was captured.
| Platform | Identifiers Sent | Description |
|---|---|---|
| Google Ads | one click ID | Exactly one of gclid, gbraid or wbraid per conversion, with gbraid preferred when both braid identifiers are present. gclid travels with hashed contact details. gbraid and wbraid travel without them, because attaching user data to those two marks the upload as enhanced conversions for leads, which Google does not support for them. |
| Meta | click ID and browser ID | fbc and fbp together in user_data, unhashed, alongside the hashed contact details. |
| TikTok | click ID and browser ID | ttclid and ttp together in user, unhashed, alongside the hashed contact details. |
| click ID and browser ID | rdt_cid as an event-level click_id, and _rdt_uuid as user.uuid. | |
| click ID only | li_fat_id in userIds, as a LINKEDIN_FIRST_PARTY_ADS_TRACKING_UUID entry next to the hashed email. | |
| ChatGPT Ads | click ID and browser ID | oppref at the event level and __obref inside the user block. An event-level obref is rejected outright. |
| GA4 | client and session ID | The visitor's _ga client identifier and _ga_<stream> session identifier, with gclid passed through as an event parameter. |
It's possible for a person to click your ads and visit your website multiple times before converting, and in that case we need to decide which identifiers to send (the identifiers from the first click, the last click, or something in between).
Fortunately, ad platforms and analytics tools document which one they want you to send and we simply follow their requirements.
| Type | Attribution Model | Description |
|---|---|---|
| Click identifiers | last touch | We send the click identifier from the most recent visit to the website. |
| Campaign parameters | last touch | We capture and send campaign parameters from the most recent visit to the website. Note these are only sent to analytics tools as ad platforms don't require them. |
| Landing page and referrer | first touch | Written once and never overwritten, so how the visitor originally found you is retained alongside what they last clicked. |
Similarly, analytics tools like Google Analytics require us to send the Client ID and Session ID with each conversion.
Without it, GA4 has no way to connect the conversion being reported to the website session it happened in. The conversion event still arrives, but because there's no session ID to attach it to, GA4 creates its own session just for this one conversion event. And because it doesn't know what the Source, Medium or Landing Page of that session was, they get recorded as '(not set)'.
To fix this common problem, Converly captures the Client ID and Session ID (assuming the customer has Google Analytics on their website) and sends it over with each conversion.
Limits
There are a couple of limitations worth knowing about:
-
A visitor who arrives from organic channels (like organic search, organic social, direct traffic, etc) will have no click identifier (because they didn't click an ad). The conversion is still captured in Converly and still sent to ad platforms, and those ad platforms will try to match it to an ad click based on the contact details passed through. Assuming this person hasn't clicked an ad, this matching will fail and the conversion won't show up in reports in your ad platforms. This is completely expected behaviour and how it should work.
-
Cookie lifetime in the browser is subject to each browser’s own limits, which are shorter in Safari than elsewhere.
See also Deduplication for how identifiers interact with a pixel you already have installed, and Normalization and hashing for what happens when no click identifier is present.