Free UTM Campaign Builder

Google Analytics documents five campaign parameters, and its guidance is to always set utm_source, utm_medium and utm_campaign - GA4 needs those three to assemble a session's traffic-source dimensions cleanly. utm_term (a paid keyword) and utm_content (which creative) are optional refinements. Skip either optional one and attribution still works; skip a required one and GA4 falls back to weaker signals or files the traffic under "(not set)."

Because Google treats parameter values as case sensitive - its documentation gives utm_source=google versus utm_source=Google as the canonical example - a team without a written convention ends up with the same channel scattered across three rows of Traffic Acquisition. Three habits prevent essentially all of it: lowercase everything, always; hyphens instead of spaces, so values survive encoding and stay readable in a report; and a closed vocabulary for utm_medium (pick from something like email, paid-social, cpc, referral, qr - and never invent a new one mid-campaign). For campaign names, a repeatable pattern such as goal-market-yyyymm sorts chronologically on its own.

It also helps to know exactly which GA4 dimension each parameter feeds, because that is where you will go looking for it later:

UTM tags on internal links. Campaign parameters describe how a visitor arrived at your site. Put them on your own navigation or an internal banner and the click rewrites the visit's origin story - the homepage promo steals credit from the ad that actually paid for the visitor. Tag entry points only: ads, emails, social posts, QR codes.

Fighting the click IDs. Google Ads auto-tagging appends a gclid that already carries the campaign, ad group and keyword; when a URL arrives with both a gclid and manual UTM tags, Google Analytics uses the auto-tagged values unless you switch on the manual-override setting, so hand-written tags on Google Ads URLs mostly get ignored. Meta does the inverse: it appends fbclid to outbound clicks automatically, but that identifier is not something GA4 can read as a source or medium - Meta ad URLs therefore do need manual UTMs. That asymmetry is a large part of the ad-to-conversation attribution mess, and why chatbot analytics ends up reconciling numbers from two systems that count differently.

A raw space in a UTM value breaks the query string at the first one - everything after it stops being read as part of that parameter. The conventional fix is to encode it as %20 or avoid it with a hyphen or underscore, which is why "spring-sale" reads better in a report than "spring sale" ever will. This builder encodes every value automatically. It also checks the destination URL you paste in for a "?" or an existing utm_ parameter - appending more tags to a link that already carries tracking produces a URL with two conflicting versions of the same parameter, and only one of them wins.

GA4 documents three newer parameters beyond the original five. utm_source_platform identifies the platform that managed the buy and is genuinely captured in GA4 reporting today. utm_creative_format and utm_marketing_tactic are documented too, but Google's own reference notes neither is currently reported inside Google Analytics 4 properties - safe to include for another tool downstream, invisible in your GA4 reports for now.

A wa.me link only recognizes two things: the phone number in the path and an optional pre-filled text= message. That is the entire documented specification. Anything else appended to the query string, UTM parameters included, is not part of that spec - WhatsApp opens the chat using the phone number and message it recognizes, and nothing else in the URL travels with it into the thread. The conversation that results has no query string attached at all, so a web analytics tool watching for utm_source on a landing page never sees the click, because the click never lands on a page it can watch.

Messenger and Instagram behave better here: an m.me or ig.me link can carry a ref parameter - m.me/yourpage?ref=spring_sale - which Meta delivers to your business through a messaging_referral webhook when the conversation opens. Telegram offers the same idea through t.me/yourbot?start=spring_sale, handed to the bot with the /start command. Neither value is a UTM parameter and GA4 will not read either one, but they are the mechanisms those platforms built for exactly this job.

The practical fix is to stop expecting one mechanism to do both jobs. Tag the page or ad that links to the chat destination with UTM parameters as usual, so GA4 can attribute the click that led someone to tap through. Then use the platform's own parameter - ref for Messenger and Instagram, start for Telegram, a coded prefix inside text for WhatsApp - to carry a matching identifier into the conversation itself, where your bot or unified inbox tooling can log it. Two separate tags, two separate systems, one campaign traceable end to end - which is also what makes cross-channel context possible once a conversation is underway.