Capability

The UTM values that survive delivery, reviewed before send

The tracking you wrote into the template is not always what arrives at the destination. Sending platforms rewrite links, and redirect chains can drop, duplicate or mangle parameters along the way. SendProofs reviews UTM values on the final URL each check reached — after the redirects — and records every issue as a named finding.

What is inspected

Links only. For every eligible link, the review runs on the final URL the check reached after following HTTP redirects (up to 3 hops) — the URL where the chain ended, not the tracked link your platform wrote into the email. The workspace's required UTM keys, where defined, are captured at upload time and stored with the campaign, so a report reflects the requirements in force when the test was uploaded.

How the checker handles it

Five kinds of issue are detected, each recorded by name on the resource:

Missing required keys — where required UTM keys are defined for the workspace, each key absent from a link's final URL is recorded.
Duplicate keys — the same utm_* key appearing more than once on the final URL.
Blank values — a utm_* key present but carrying an empty value.
Non-canonical casing — UTM_Source and friends: key casing that differs from the canonical lowercase form.
Malformed URLs — a final URL that cannot be parsed at all is recorded as malformed.

A tracking issue on a reachable link marks the resource Warning, not Broken. The destination works; the finding asks for a human decision — fix the parameter in your sending platform if it matters, approve it deliberately if it does not.

What the report shows

Sample data Tracking findings from the August launch sample run

Resource	State	Evidence
campaign.example/launch?utm_source=email&utm_campaign=aug-launch	Healthy	200 after 2 redirects — no tracking issues on the final URL
campaign.example/blog/whats-new?utm_source=email	Warning	200, but the workspace's required utm_campaign is missing on the final URL

Sample data. In the full August launch sample run (24 unique resources, 18 links), this is one of the 2 Warning resources — the other is an image content-type finding.

Safety and limits

The final URL here is the final URL the probe reached over HTTP redirects. SendProofs does not execute JavaScript, so a destination that forwards visitors again in the browser — a JavaScript or meta-refresh hop — is beyond the check's view, and a link whose check faulted mid-chain stopped where the fault occurred. Read the findings as evidence about the final HTTP destination at check time, not as a recording of what an analytics session would capture. Where no required keys are defined for the workspace, the missing-key check has nothing to require — the other four checks still run.

Not included

No analytics integration — SendProofs does not connect to your analytics tool or read its data; every finding comes from inspecting the URL itself.
No attribution modeling — no claims about which campaign or channel gets credit for a conversion.
No link rewriting or fixing — findings are recorded, not repaired; the fix happens in the platform where you built the campaign, followed by a fresh test and a recheck.

Redirect evidence

Redirects followed up to three hops with every step recorded — source, target and status — plus warnings for HTTPS downgrades, loops and dead ends.

Link checking

Every unique public link in the delivered email, requested once with bounded, safe HTTP checks and the resulting status recorded as evidence.

Evidence reports

Timestamped, human-readable evidence for every checked resource, with a clear next action for each state — not an opaque score or a pass stamp.