Capture UTM params and attribute on signup

WHAT THIS TESTS This probes attribution mechanics across the anonymous-to-authenticated boundary, where the data exists at landing but the account does not yet exist.

A GOOD ANSWER COVERS On landing, read the UTM parameters from the URL query string. Persist them, because the user may browse and sign up days later when the URL no longer carries them. Store in a first-party cookie or local storage tied to a generated anonymous id, and decide a policy: first-touch keeps the original campaign and only sets if empty, last-touch overwrites. Also capture landing page and timestamp. At signup, read the stored attribution and write it onto the new account record, and emit a signup event carrying both the anonymous id and the new user id so the analytics layer stitches the pre-signup history to the account. Respect consent before setting cookies.

COMMON WRONG ANSWERS Trying to grab UTMs at the signup request, when they are long gone from the URL. Relying on document.referrer, which is frequently empty, stripped, or spoofed. Storing only in memory so a refresh loses them. No identity stitch, so the anonymous journey never connects to the account.

LIKELY FOLLOW-UPS First-touch versus last-touch, and when each is appropriate? How do you handle a user landing multiple times from different campaigns? How does consent and privacy regulation constrain cookie storage?

ONE CONCRETE EXAMPLE A visitor lands via a link with utm_source equals google and utm_campaign equals summer_sale. The client parses these, stores them in a first-party cookie under anonymous id anon_55 with a first-touch policy, and tags subsequent events. Three days later they sign up; the backend copies summer_sale onto the new account and emits a signup event with both anon_55 and the new user id, attributing the conversion to the summer_sale campaign.