UTM taxonomy and naming rules
Use when paid traffic arrives in analytics as inconsistent sources and no report can be trusted.
Fill in before running
Replace each placeholder with your own detail. The more specific you are, the less the model invents.
- {{CHANNELS}}
- {{CURRENT_UTMS}}
- {{REPORTING_CUTS}}
- {{AUTO_TAGGING}}
Getting a better result
- Settle the convention before the next launch; retagging live URLs splits every historical report.
- Keep the allowed value lists short enough to remember or nobody will follow them.
- Auto-tagging and manual tags on the same click will fight, so pick one per platform and write it down.
Questions about this prompt
When is a written convention worth it rather than fixing tags as I notice them?
When the same source appears in reports under four spellings and nobody trusts the channel numbers. Fixing tags one at a time preserves the inconsistency and adds to it. Do this before the next launch rather than after, because retagging live URLs splits every historical report at the point where you make the change.
What do I need in front of me?
Your current tagged URLs exactly as they appear in reports, warts included, the channels currently running, where auto-tagging is already switched on, and {{REPORTING_CUTS}}: how the business genuinely slices results, by market, product, funnel stage or agency. Those cuts are what the allowed values are derived from, so a vague answer produces a vague convention.
What comes back?
A rules table per parameter, a defect list pairing each broken tag with what it does to reporting and its corrected version, one full example URL per channel, the auto-tagging conflicts with a keep or drop call per platform, and a retagging order. Circulate the defect list. It is the part that shows colleagues what their tagging cost.
What is the mistake?
Approving a convention with fifty allowed values per parameter. Nobody remembers it, everybody improvises, and within a quarter you are back where you started. Keep the lists short enough to recall. Check the personal data rule holds too, since an email address or customer name inside a parameter is a problem no report redesign fixes.