Data design guide
Form attribution fields: a practical data dictionary
Preserve submission-level source evidence with an eleven-field attribution dictionary, explicit touch boundaries and an eight-case capture test.
Form attribution fields preserve how a particular submission arrived. Save an immutable submission ID, time, form ID, landing page, available referrer, validated campaign values, approved click ID and consent context. Keep that event record separate from mutable contact summaries such as first-known and latest-known source so a later visit cannot rewrite an earlier conversion.
An eleven-field attribution dictionary, source-and-provenance matrix, explicit touch-model boundaries, worked multi-visit example and reproducible eight-case capture test, checked against current Google Analytics, W3C and involve.me sources on September 18, 2026.
Key findings
- The immutable submission row is the historical truth for one conversion event; first-known and latest-known source are separate contact-level summaries.
- Campaign values need validation, normalization, provenance and length limits before they enter reporting or workflow fields.
- A blank referrer is a valid observation—not proof of a direct visit—because browser and document policies can suppress or reduce referrer information.
What form attribution means
Form attribution is the evidence recorded with a submission about where that specific interaction arrived from. It can include campaign parameters supplied in the landing URL, an approved advertising click identifier, the available referrer, the landing page and the form that converted.
The submission row is the historical truth for that event. It should remain immutable after validation. Contact-level first-known and latest-known summaries are derived views with separate update rules, not substitutes for the event record.
Eleven-field attribution dictionary
| Field | Type | Write rule | Example |
|---|---|---|---|
submission_id | String | Immutable unique event key | sub_01… |
submitted_at | Timestamp | Immutable server time | ISO 8601 |
form_id | String | Immutable versioned form key | demo_request_v3 |
landing_page_url | URL | Keep canonical path; remove secrets | /pricing |
referrer_host | String | Record host when supplied | partner.example |
utm_source | String | Validated per submission | newsletter |
utm_medium | String | Validated per submission | email |
utm_campaign | String | Validated per submission | q3_demo |
utm_content | String | Optional creative label | roi_ad_a |
click_id | String | Approved providers only; restricted access | Provider identifier |
consent_context | Object or reference | Immutable notice version and choice | notice_v4:yes |
This is a minimum operational dictionary, not a universal standard. Add a schema version and ingestion status when the record crosses systems, and keep identity, qualification and workflow evidence in their own named fields.
Source and provenance rules
Store how each value was obtained: url_parameter, browser_referrer, approved_click_id, hidden_field, persisted_contact or server_record. Provenance makes an apparent source explainable and stops a hidden field copied from an old visit from masquerading as current evidence.
Google's current GA4 campaign guidance documents utm_source, utm_medium, utm_campaign and utm_content, recommends consistent case-sensitive naming and warns that missing parameters produce incomplete reporting. Use those names consistently, but validate values before storing them.
Do not copy an unrestricted raw query string into a contact property. Allowlist expected keys, normalize case and whitespace, cap lengths and reject suspected secrets or unexpected personal data.
First-touch, latest-touch and submission truth
| View | Record level | Update rule | Use |
|---|---|---|---|
| Submission truth | Event | Immutable after validation | Explain one conversion |
| First-known source | Contact | Write once; never replace with blank | Describe earliest observed acquisition |
| Latest-known source | Contact | Replace only with a qualifying new observation | Describe recent known acquisition |
A reporting query may choose one of these views, but it must name the view. Blending them into one mutable source field makes repeated visits impossible to audit.
Deterministic precedence rule
For each submission, prefer a complete set of validated campaign parameters; then an allowlisted click ID; then an available external referrer host; otherwise record direct_or_unknown. A blank referrer does not prove a direct visit: the W3C Referrer Policy defines policies that can omit the header or reduce it to an origin.
Log the matched rule version and provenance. If two sources conflict, preserve the raw allowed evidence in restricted event fields and let the documented rule choose the normalized reporting value.
Worked multi-visit example
A buyer first arrives through a tagged newsletter link, reads a guide and leaves. Two weeks later, the same buyer returns without campaign parameters and submits a demo form. The demo submission is direct_or_unknown unless a documented persistence rule supplies separate prior-touch context. The contact's first-known source can remain newsletter; its latest submission source is direct_or_unknown. Neither view rewrites the other.
Eight-case capture test
- Submit a complete source, medium and campaign set; confirm normalized values and URL provenance.
- Submit source and medium without campaign; confirm the missing field remains explicit instead of being invented.
- Use an untagged external referral; confirm only the available host is stored.
- Use no campaign or referrer evidence; confirm
direct_or_unknown, not a fabricated source. - Vary capitalization and spacing; confirm the documented normalization rule.
- Send an over-length value; confirm safe rejection or truncation with an ingestion note.
- Include a suspected secret or personal value in the URL; confirm it is excluded and flagged.
- Submit twice as the same contact from different sources; confirm both events remain intact while first/latest summaries follow their own rules.
The published form, stored submission, contact summary and downstream CRM mapping agree on normalized values, provenance and rule version; unsafe values are rejected; and a later visit cannot alter the earlier event.
Current product boundary
As checked September 18, 2026, the current involve.me pricing table lists “Pass UTMs & hidden fields” on Grow. That supports transporting values into a funnel on that plan; it does not by itself prove immutable event storage, a particular attribution model or automatic causality. Verify the intended plan, field mapping, persistence and downstream write behavior with the eight-case test.
This article is product-neutral. Other builders, tag managers and CRMs can implement the same contract natively or through integrations; the buyer should evaluate the saved record and downstream behavior, not the label on the feature.
Evidence and limitations
An eleven-field attribution dictionary, source-and-provenance matrix, explicit touch-model boundaries, worked multi-visit example and reproducible eight-case capture test, checked against current Google Analytics, W3C and involve.me sources on September 18, 2026.
- Attribution is a reporting convention, not proof that a channel caused a conversion or a measurement of incremental impact.
- Browsers, privacy controls, redirects, cross-domain journeys and consent choices can remove parameters or referrer information.
- Plan access, hidden-field behavior, persistence and CRM mappings vary by platform and workspace; test the published path with non-sensitive records.
Sources and verification
Current product and plan claims use the primary sources below. Internal methodology links describe the publication's own frameworks and should not be read as vendor documentation.
- Google Analytics, URL builders and UTM parameters
- W3C, Referrer Policy
- involve.me pricing and plan features
- CRM-ready form data model
- What should happen after a form submission?
- The Form Review testing methodology
Last materially verified .