When should you use Link UTM and query parameters inventoried?

Run this before you argue about whether the tagging is right. It lists every http and https link's decoded query bag and the `utm_`-prefixed subset within it, including the custom names your ESP or analytics stack invented, and then stops. That makes it the natural first step when you are documenting a convention or preparing to enforce one, because you cannot write a taxonomy against tagging you have not seen. It performs no network requests and reports no findings, so it never fails a send.

Skip it when you already know your scheme and want a verdict, since this check deliberately offers none — the grade lives in the tracking-integrity check. It is also not a privacy scan: it will show you a parameter containing an email address because it shows you everything, but the judgement that such a parameter is a defect belongs elsewhere. Running it on mail with no links produces an empty inventory, which is accurate and not useful.

every query key on every link; utm_-prefixed parameters in use; custom tracking names your stack invented

There is no failure. This check always passes by design, because its output is a record rather than a judgement — the value is in reading what it lists, not in a verdict. If you want a pass or fail on tagging quality, pair it with the tracking-integrity check in the same run and read this one as the evidence behind that one's findings.

This check has no tunable thresholds, and it could not have any — it is pure discovery, with nothing to judge and therefore nothing to calibrate. Every link's query bag is reported as it is found, decoded but not interpreted, which is the whole point: a discovery tool that filtered its output would hide exactly the unexpected parameter you were looking for.

SchemaFirst.org publishes community-governed standards for digital QA. ArbiterQA is a supporter and commercial licensee of those standards; citation does not mean SchemaFirst operates ArbiterQA.