Skip to main content
A campaign is the container your links hang under. It does two things: it groups links so “everything from the spring launch” is one list, and its name is the default utm_campaign of the links created under it, so the report can be narrowed to that campaign. Campaigns live at https://app.utmkit.co/campaigns. Everyone in the workspace can see the list; owners, admins and members can create, rename and delete. A viewer sees the list and nothing else.

​
Creating a campaign

1

Open Campaigns and choose New campaign

Give it a name and, if you like, a description.
2

Check the derived value

After saving, the row reads Added to links as utm_campaign=…, rewritten to follow the workspace’s convention: “Spring Launch” becomes spring-launch under the default rules. That value is checked against the rules when you save. If utm_campaign has approved values, a name that does not produce one of them is refused, with the approved values in the message.
Names are unique per workspace and matched without regard to case. Asking for a campaign that already exists gives you the existing one rather than a duplicate, which is why the console says the campaign “is ready to use” either way. You can also create one by asking the assistant for a link under a new campaign, and ask it to rename a campaign or move links into or out of one the same way you would on this page.

​
Renaming, and what renaming does not change

Edit a campaign to change its name or description. Renaming changes the default utm_campaign for links created from now on. Links already created keep the value they were born with: it is baked into their destination, already published to the edge and already counted in your reports. Rewriting it would split a campaign’s history in two at the moment somebody fixes a typo. The editor says so before you save. Each row counts the links it holds and offers two shortcuts. See its links opens the links list at https://app.utmkit.co/links already narrowed to that campaign, and See its numbers opens the report filtered to it. On a link’s row and on the cards the assistant shows when it changes something, a campaign’s name is a link to the campaign. Hover it (or tap it on a phone) to preview its utm_campaign value, how many links it holds, and its clicks and conversions, with shortcuts to its links and its analytics, without leaving the page.

​
Deleting a campaign

Deleting a campaign removes the grouping and nothing else. Its links keep working, keep redirecting and keep the utm_campaign they carry; they simply no longer belong to a container. The confirmation states how many links that is, so a campaign holding forty links reads differently from an empty one.
A campaign whose name today’s rules would refuse is still listed as it is. The rules apply when a name is chosen, not retroactively; the audit is what finds links that no longer comply.

​
From the API and the MCP

GET /api/v1/campaigns lists the workspace’s campaigns with their link counts, POST /api/v1/campaigns creates one (a repeated name returns the existing campaign), GET /api/v1/campaigns/{id} reads one, and PATCH /api/v1/campaigns/{id} renames or re-describes it — both fields are optional on PATCH, and existing links keep their utm_campaign exactly as in the console. DELETE /api/v1/campaigns/{id} deletes one: as in the console, its links keep working and keep their utm_campaign, and only lose the container. Reads need campaigns:read and writes need campaigns:write. Over the MCP the tools are list_campaigns, get_campaign, create_campaign, update_campaign and delete_campaign, under the same two permissions.