click ID tracking for SaaS
Click ID Tracking for SaaS: How gclid, fbclid, msclkid, and ttclid Reach Your Payment Records
gclid, fbclid, msclkid, and ttclid explained for SaaS: what each can tell you, why they disappear before checkout, and how to carry them into payment metadata.
What a click ID is, and what it is not
Concise answer
A click ID records a platform click signal on the landing URL. It does not describe the campaign in words, prove the click was billable in every case, or prove that it caused a purchase.
Each major ad platform documents its own identifier. Google's auto-tagging is described as a feature that automatically adds a parameter to your URLs to help you track offline conversions and report on your ad performance; the parameter is the Google Click Identifier, gclid, attached to the URL your customers click. Google also documents gbraid, a privacy-preserving identifier used to measure ad performance that measures conversions in a non-unique fashion, like a campaign ID, without linking them to individual users or events; it is case sensitive and must not be changed. Meta's Conversions API documentation says the click ID is passed with the URL of an advertiser's website when a user clicks an ad on Facebook or Instagram, as the fbclid query parameter, and describes how the Meta Pixel stores it in a first-party cookie formatted as version, subdomain index, creation time, and the fbclid value.
Microsoft Advertising documents that auto-tagging of Microsoft Click ID automatically adds a unique click ID, msclkid, to the landing page URL, that it is enabled by default, and that it exists so conversions are still tracked when the Microsoft cookie cannot be returned because of browser settings such as third-party cookie blocking. TikTok describes ttclid as a tracking parameter appended to a landing page URL when you click on an ad on TikTok, matched back to actions on TikTok when events shared through its Pixel or Events API contain the ID.
The distinction from UTM parameters is the one that trips up most teams. UTMs are yours: you write utm_source, utm_medium, and utm_campaign, and analytics tools can group visits by them. Click IDs are opaque platform values. A UTM gives you a campaign label; a click ID can help connect the visit to a platform click. The ID alone does not tell you which campaign or prove that every click was billable. Siteimprove's paid-versus-organic Facebook guide specifically uses a paid UTM medium alongside fbclid to separate the two. Google Analytics also recommends source and medium tags on paid Meta destination URLs. Keep both on the landing URL and, when possible, through to payment.
| Parameter | Platform | Appended by | Documented purpose | Notes |
|---|---|---|---|---|
| gclid | Google Ads | Auto-tagging | Offline conversion import and ad performance reporting | gbraid and wbraid are privacy-preserving variants for iOS measurement |
| fbclid | Meta (Facebook, Instagram) | Meta click URL | Matching events sent via Pixel or Conversions API | Does not establish paid status or exact surface in Metrivo without other evidence |
| msclkid | Microsoft Advertising | Auto-tagging, on by default | Conversion tracking when the Microsoft cookie is unavailable | Can be disabled at the account level |
| ttclid | TikTok Ads | Ad click | Attribution, audiences, and delivery optimisation | Validity follows the click-through window in Attribution Manager |
| utm_* | Any | You | Campaign grouping in analytics tools | Human-readable campaign labels; verify them against campaign setup |
Why click IDs disappear before a SaaS payment
Concise answer
A SaaS trial can span days and a hosted checkout can cross domains, so a click ID captured on the landing page may be missing when payment is recorded.
The ID arrives on the very first URL and nowhere else. Everything after that first pageview is a chance to lose it.
The landing page rewrites the URL
Client-side routers, canonical redirects, locale redirects, and trailing-slash normalisation can all replace the URL before your script runs. A redirect that reconstructs the path without the query string drops every parameter at once. The symptom is a paid campaign whose visits show up as direct. If you see that pattern, the UTM parameters lost at checkout guide walks through where the handoff breaks.
The trial gap
A SaaS buyer clicks an ad, starts a trial, and pays on day seven or day fourteen from a different tab, often from a bookmarked app URL that never carried the ID. Unless the ID was written to first-party storage on day one and read back on the day of payment, the payment has no way to reference the click. Ad platforms handle this with their own cookies and conversion windows; your own records need an equivalent.
The checkout lives on another domain
Hosted checkouts run on the provider's domain. Your browser storage does not follow the user there. Pass the attribution context explicitly when creating checkout, through supported provider metadata or a server-side mapping to your own visitor and customer IDs. Check which object the provider includes in the webhook you use; metadata on one object is not automatically available on every related object.
The script loads too late
Consent banners, deferred script loading, and client-side route changes can all mean your tracker first runs on a URL that no longer carries the parameter. If your tracker is gated behind consent, the visitor may have navigated to a second page before consent is given, and the landing URL with the ID is gone. The fix is to read and store the query string in your own first-party code at page load, then hand the stored record to the tracker once it is allowed to run. Note that some visits will never be recorded by design: Metrivo's tracker halts initialisation when the browser sends a Do Not Track signal and honours a local opt-out key, so those visits carry no click ID into your records at all, and that is the correct outcome for them.
The browser removes the ID before you see it
Apple's WebKit team describes Private Browsing in Safari 17 and later as removing query parameters identified as being used for pervasive cross-site tracking granular to users or clicks, prior to navigation, so the values are never propagated over the network, while allowing campaign attribution parameters through. In that mode, third-party scripts that read the page URL receive a version without any query parameters, and cross-site referrers are hidden from script. The practical consequence is that a share of paid visits will never carry a click ID no matter how well you store it. Those visits should remain classified by whatever evidence survives, usually the UTMs, and otherwise stay unknown.
The first-party pattern that survives the trial
Concise answer
Capture at first pageview, persist in first-party storage, hand off as checkout metadata, classify at webhook time. Four steps, each with an inspectable output.
This pattern is not specific to any tool. It is the minimum that makes a click ID usable weeks later.
Capture at the first pageview
Read the query string as early as possible, before any router or redirect rewrites it. Record the click IDs together with the UTMs, the referrer, and the landing path, because they are evidence about the same visit. Metrivo's tracker reads gclid, fbclid, msclkid, and ttclid alongside the UTM fields on every pageview and includes them in the event payload.
Persist a first-touch and a last-touch record
Keep two records: the first campaign that ever brought this visitor, and the most recent one. Both matter. A buyer who first arrived from a Google ad and returned from a retargeting ad on Meta has a story that neither record tells alone. Metrivo stores both records in the browser's local storage rather than cookies, keyed to a first-party anonymous visitor identifier, and does not track a visitor across different customer websites. The last-touch versus multi-touch attribution guide covers how to read the two records once they reach the payment.
Hand off at checkout creation
When your server creates the checkout session or subscription, read the stored records and attach them to the provider object your payment webhook will read. Metrivo exposes a tracker helper for the current attribution record, and its metadata contract accepts visitor and session identifiers, landing URL, referrer, five UTM fields, and four click IDs. For Stripe Checkout, Session metadata and PaymentIntent or Subscription metadata are separate fields; choose the fields required by your webhook flow and verify the resulting object. The Stripe integration documentation and source-to-revenue tagging documentation describe the Metrivo handoff.
Classify when the webhook arrives
Once the payment carries identifiers, classify it from the evidence that actually survived. Prefer a session or visitor match, because it connects the payment to more of the journey. Fall back to the metadata fields on the payment itself when no session can be matched. Record which evidence produced the classification, because a click ID in payment metadata and a matched session are not equally informative.
How Metrivo classifies click IDs
Concise answer
Metrivo treats different click IDs differently: fbclid alone identifies Meta social traffic, while an explicit paid UTM medium makes Metrivo classify the visit as paid social. A metadata-only payment fallback remains low confidence.
Metrivo classifies a session with gclid or msclkid as paid search and one with ttclid as paid social. With fbclid alone, it preserves a Facebook or Instagram referrer if available, or uses the broader Meta source when the exact surface is unknown; the channel stays social. An explicit paid UTM medium such as cpc changes a Meta social source to paid social. A click ID can make the session's source evidence confirmed, but that confidence label does not independently verify paid status or the payment match. A UTM source on its own without a click ID or medium is only inferred.
At payment time the engine tries session hints first, including the Metrivo session identifier and the provider's client reference, then visitor identifiers, then a hashed customer email match. If none resolve, it falls back to the payment's metadata. There, gclid resolves to google / cpc, msclkid to bing / cpc, fbclid alone to meta / social, and ttclid to tiktok / paid_social, unless explicit source or medium fields take precedence. This metadata-only source match is labelled low confidence; see attribution confidence for the evidence levels.
| Signal present | Session channel | Session confidence | Payment fallback source and medium |
|---|---|---|---|
| gclid | paid_search | confirmed | google / cpc |
| msclkid | paid_search | confirmed | bing / cpc |
| fbclid without paid UTM | social | confirmed source signal; paid status unverified | meta / social (low-confidence fallback) |
| fbclid with Meta paid UTM medium | paid_social | confirmed source signal | Explicit UTM source and medium take precedence |
| ttclid | paid_social | confirmed | tiktok / paid_social |
| utm_source and utm_medium, no click ID | By medium | confirmed | From the UTM values |
| utm_source only | By source | inferred | From utm_source |
| Nothing survived | direct or unknown | unknown | Stays unattributed |
What Metrivo does not do with click IDs
The current tracker captures four identifiers: gclid, fbclid, msclkid, and ttclid. It does not capture gbraid, wbraid, dclid, LinkedIn's li_fat_id, or X's twclid, so iOS-only Google measurement that relies on gbraid or wbraid is not recorded and stays unknown. Metrivo also does not send your customers' conversions back to Google Ads, Meta, Microsoft, or TikTok; the IDs are recorded as evidence for your own revenue reporting, not uploaded to the platforms. If you need offline conversion import or a conversions API integration, that is a separate system, and the click ID stored in your payment metadata is the value you would use to feed it.
Reading the result honestly
Concise answer
A click ID on a payment supplies platform click evidence, with limits that depend on the ID. It does not by itself prove that an ad caused the purchase; fbclid alone also does not establish paid status.
Three limits are worth stating in your reporting. First, a click signal is not causation: a customer who already intended to buy and clicked a branded ad on the way in may carry a gclid. For Meta traffic, an fbclid without paid campaign evidence does not prove an ad click. Second, the last-touch record can over-credit retargeting, and the first-touch record can over-credit discovery; read them together. Third, coverage is partial. Private Browsing may strip IDs, some redirects rewrite URLs, and some users arrive on a bookmarked link. Report the share of payments attributed to campaigns with explicit paid evidence that carried an ID, and keep the rest visible without allocating them proportionally.
None of this makes click IDs less useful. It makes the reporting honest. The revenue attribution guide covers how confirmed, inferred, and unknown matches should be presented side by side, and the GDPR-friendly attribution guide covers why first-party storage without cookies is the right default for this data in the first place.
An end-to-end test
Concise answer
Prove the path end to end with one fake click ID and one sandbox payment before you trust a month of reports.
Open your landing page with a made-up parameter such as gclid=test-click-001 and, if you use UTMs, a matching utm_source and utm_medium. Confirm the value was stored: in Metrivo's case, the first-touch record in local storage should contain it, and the verify tracking documentation shows how to confirm the pageview arrived with its properties. Navigate to another page, close the tab, and come back through a bookmark to simulate the trial gap; the stored record should still be there.
Then start a sandbox checkout from your own signup flow, not from the provider's test button, so that your server's checkout creation code runs. Inspect the metadata on the checkout, PaymentIntent, or subscription object your webhook actually reads; the test click ID should be present there. Complete the test payment and check the webhook payload your handler received. Confirm that the payment has google / cpc source fields. A matched session can give stronger confidence than a payment matched only from metadata.
If the ID is missing at any step, you have found the boundary where it was lost. Check redirects on the landing URL, checkout creation code that may not read the stored record, and webhook handling that may ignore the relevant object. If you want Metrivo to run this path for one website and one payment path, use the Add my website flow on the homepage; the separate demo is a seeded sample and does not test your own URLs.
- Landing URL with gclid=test-click-001 loads without a redirect that drops the query string.
- First-touch record in first-party storage contains the click ID and the landing path.
- Record survives a new tab and a bookmark visit.
- Checkout session metadata in the provider dashboard contains the click ID and the visitor identifier.
- Webhook payload received by your handler contains the same metadata.
- Payment has google / cpc source fields; confidence reflects whether a session matched or only metadata survived.
Frequently asked questions
What is the difference between a click ID and a UTM parameter?
A UTM parameter is a campaign label you write yourself, readable by analytics tools. A click ID is an opaque platform identifier. A UTM names a campaign; a click ID helps connect the landing visit to a platform click. Neither alone proves that a payment was caused by an ad, and fbclid alone does not establish paid status. Use both with the referrer when available.
Does Safari remove gclid and fbclid?
In Private Browsing, Safari 17 and later removes query parameters identified as being used for click-level or user-level cross-site tracking before navigation, while allowing campaign attribution parameters through. Visits affected by this will carry UTMs but no click ID, so classify them from the UTMs and otherwise leave them as unknown.
How do I pass gclid to Stripe?
Store the gclid first-party when the visitor lands, then pass it to your server when creating Stripe Checkout. Attach it with visitor and session IDs to the Checkout Session and, where your webhook needs it, to PaymentIntent or Subscription metadata through the corresponding Checkout creation fields. Verify the object in the webhook actually contains the value.
Does Metrivo send conversions back to Google Ads or Meta?
No. Metrivo records gclid, fbclid, msclkid, and ttclid as attribution evidence for your own revenue reporting. It does not upload conversions to any ad platform. The stored click ID in your payment metadata is the value you would use in a separate offline conversion or conversions API integration.
What happens when the click ID is missing at payment time?
Metrivo tries session and visitor matches first, then a hashed email match, then the payment's own metadata. If nothing resolves, the payment stays visible as unattributed revenue rather than being assigned to a source. A missing click ID lowers coverage; it should not silently inflate a channel.
Which click IDs does Metrivo capture?
The current tracker captures gclid, fbclid, msclkid, and ttclid. It does not capture gbraid, wbraid, dclid, li_fat_id, or twclid, so measurement that depends on those parameters is not recorded and remains unknown.