Where a submission came from is recorded, not guessed.

The question attribution answers

Not "how much traffic did this campaign send" — analytics answers that. The question is "which campaign produced this enquiry", for a specific record, months later, when the analytics retention window has expired and nobody remembers which landing page existed. That answer has to live on the record or it does not exist.

What gets stored

Value	Where it comes from
Source	Parsed from the referrer header at submission time.
Campaign	UTM parameters present on the request.
Device	Derived from the user agent, server-side.
Origin	The hostname the form was submitted from.

Why storing it beats joining it

An analytics join requires an identifier that survives from the page view to the submission — usually a cookie or a client id — plus a property that still exists when you ask the question. Both fail routinely: cookies get blocked, properties get reset, and the person who set up the property leaves. A value written onto the record cannot be lost that way.

UTM discipline in one paragraph

Use three parameters or fewer, keep them lowercase, and never change the naming convention mid-campaign. utm_source is the platform, utm_medium is the channel type, utm_campaign is the specific push. Anything else is a comment, and comments belong in a spreadsheet next to the campaign, not in a field you will have to normalise later.

The honest limits

Referrer data is incomplete by design and always will be. Some browsers strip it, some apps pass nothing, and a visitor who types the URL directly sends nothing at all. Attribution is evidence, not proof: it tells you which enquiries a campaign can plausibly claim, and it will never balance against a traffic number in a different tool.