Pre-launch attribution checklist

Launch day is the worst time to learn that a form never told analytics anything, or that every lead arrived as "direct". Attribution is cheap before the first visitor and impossible to rebuild for the weeks you missed. This list covers what each tool must record, and one test that proves it. Crawling and indexing belong to the technical SEO checklist.

Open the analytics debug view, the CRM and the inbox that receives new leads, and date the page before you start.

• The live address is the verified property. Why: a property for a staging host or the http version reports on a site nobody visits. How to check: in Google Search Console and in Bing, open the property and confirm it is the exact https address you will promote.
• Verification survives the next deploy. Why: a tag pasted into one page can vanish in a redesign, and the tool stops trusting you. How to check: prefer a DNS record, or render the tag from the site template so every release carries it; Bing can also import a verified Search Console site.
• The sitemap was submitted and read. Why: the tool shows when it last read the file and how many addresses it found. How to check: submit the sitemap in both tools, wait for a successful read and compare the count with the pages you meant to publish.

• One written pattern for social posts. Why: social apps often hide the referrer, so untagged clicks from a post land as direct traffic. How to check: write the rule down, for example utm_source=<platform>&utm_medium=social&utm_campaign=<page-slug>, in lowercase, and watch one tagged click arrive in the realtime report.
• Editorial and internal links stay clean. Why: a tagged link in a guest post creates a parameter address publishers often strip, and a tag on your own internal link restarts the visit with a false source. How to check: search your templates and content for utm_, and send publishers the plain page address; read those visits as referrals instead.
• Every link you control has a tagged version. Why: email signatures, directory profiles and a link page otherwise blend into direct or referral traffic. How to check: list each place you own a link and give it a URL from the same pattern, such as utm_medium=profile for profiles.

• Each call to action sends a named event with its location. Why: a lead total can't tell you whether the hero button or the closing band did the work. How to check: click two buttons on the same service page and confirm one event name with two different location values.
• The event carries the service, not the visitor. Why: page context is enough to compare offers. How to check: read the parameters: a service key, a page type and a placement, all from fixed lists.
• A click is not counted as a lead. Why: clicking shows interest; only a saved submission is an inquiry. How to check: in analytics, mark only the form event as a key event and leave the click events unmarked.

• The lead event waits for the save. Why: an event fired on the button counts validation errors, spam blocks and server failures as leads. How to check: submit once with a required field empty and once correctly; only the saved one should appear in the debug view.
• One submission sends one event. Why: a double click or a reloaded thank-you page doubles the count. How to check: double-click the submit button, then refresh the confirmation, and count the events.
• Each form says which form it is. Why: a full contact page and a short inline brief convert differently. How to check: confirm a form type value on the event for every form on the site.

• Event values come from fixed lists. Why: free text sends names, emails and phone numbers to a tool whose terms forbid them. How to check: in the debug view, read every parameter of the lead event and accept only picked values, such as an industry key or a two-letter country code.
• Addresses carry no form contents. Why: a confirmation URL with an email in it is recorded with every page view. How to check: after a test submission, read the address bar and the page location the tag sent.
• Privacy signals switch tracking off. Why: a visitor who sends Do Not Track or Global Privacy Control has said no before any banner. How to check: turn the signal on in a test browser and confirm no analytics request leaves the page.

• The wording is stored with the record. Why: months later, someone may ask what the person actually saw. How to check: open the test contact and find the consent text or its version, the page it came from and a timestamp.
• Asking for a quote stays separate from marketing permission. Why: a request for help is not a request for newsletters. How to check: confirm marketing permission is its own unticked choice and arrives in the CRM as its own field.
• An opt-out reaches every tool. Why: a person who unsubscribes in one system can keep receiving messages from another. How to check: unsubscribe the test contact and look for the suppression in the CRM and in each sending tool.

• The form passes its source to the CRM. Why: analytics and the CRM can't be joined on personal data, so the CRM needs its own copy of the origin. How to check: capture the landing page, referrer and campaign values in hidden fields, and find them on the test contact.
• The first source is never overwritten. Why: a second visit from a newsletter would erase the post that brought the person in. How to check: keep separate first and latest source fields; submit again from another tagged link and confirm only the latest one changed.
• A repeat inquiry updates the same contact. Why: a second record splits the history. How to check: submit twice with the same email and look for one contact with two inquiries on it.

• Send one real test through the live form. Why: tools that pass on their own can still drop the lead at a handoff. How to check: open a tagged link, submit with an obviously fake name, and find it in the debug view, the CRM and the notification inbox.
• Every tool tells the same story. Why: if analytics says social and the CRM says direct, one of them is set up wrong. How to check: compare source, campaign and time for the test lead across the tools, then label it and keep it out of reports.

• A dated snapshot exists before launch. Why: without a starting number, no later number can be called a change. How to check: record the date, the date range and each figure you will compare later (search clicks and impressions, sessions by source, key events, new contacts by source), even when it is zero, and save screenshots.
• Tracking changes have a log. Why: a fixed tag mid-month looks exactly like a jump in demand. How to check: keep one dated line per tracking change next to the baseline and read it before every monthly report.

Fix anything that failed the end-to-end test, then send a second labeled lead and reconcile it again. After launch, compare the same date ranges, from the same tools, against the dated baseline. Consent rules differ by market and by message type; this list checks that you record consent, not what the wording should say, so have your adviser review the wording itself.