What the SDK captures
They are read from the URL query string, then from a query inside the hash (
/#/?utm_source=..., for hash routers), then from the referrer. Within a session they are kept in sessionStorage, so they survive client side navigation and redirects.
First and last touch
Across sessions the SDK keeps anattribution object in localStorage:
first_touchandfirst_click_idsare written once: the campaign that first brought the visitor.last_touchandlast_click_idsare overwritten on every new tagged visit.
conversion() carries this object. You don’t need to read the URL or pass UTMs yourself.
How the server uses it
- Lead source: an explicit
sourceproperty on the conversion wins. Otherwise the last touchutm_source, then the first touch, then the UTMs of the session. - Google Ads: the last touch
gclid(orgbraid/wbraid) is stored on the lead and matched with the clicks of your synced Google Ads campaigns, so each lead is tied to the campaign that paid for it. - Meta Ads: Meta has no click level report, so
fbclidproves that a visit came from a Meta ad but cannot be joined with spend. The join usesutm_id(the Meta campaign id), with the campaign name inutm_campaignas a fallback. - Older SDKs: if a conversion has no
attributionobject (SDK before 1.6) the server recovers UTMs and click ids from the landing URL of the session.
Tag your ads
Ad platforms add their click id automatically (gclid with auto tagging in Google Ads, fbclid on Meta). Add UTMs as well, and always utm_id: unlike utm_campaign it survives a campaign rename.
Check it
Open your site with?utm_source=test&utm_campaign=check using the development key, submit a conversion, and open the request in Dev mode: the payload has the attribution object, and there is no missing_attribution warning. A conversion without UTMs or click ids gets that warning and the lead counts as direct.