Template & checklist · campaign log workspace

Campaign Tracking Spreadsheet

Log published links, final destinations, owners, and launch evidence in one place so reporting has a real source of truth after the link goes live.

This is the recordkeeping layer that sits after UTM Builder, UTM QA Checker, and Redirect Checker. Use it to preserve what actually shipped instead of trying to reconstruct it from memory later.

Log before launch

Create the row before the link goes live so the published asset is tied to one approved source of truth.

Store published and final URLs

Keep both the placed link and the final destination so redirect changes stay visible later.

Keep ownership and status

Track who launched the link, what state it is in, and where to look when results or failures show up.

Log the asset before it disappears into launch chaos

The spreadsheet should make it obvious what was published, where it was placed, who owned it, and what it finally resolved to. Treat each row as an evidence record, not as a casual note.

Sheet preview

One row per published link. Keep the fields stable so the record still makes sense a month later.

Published linkFinal URLOwner
DateCampaignChannelPlacementPublished URLFinal URLOwnerStatus
22 MarSpring sale launchTikTokBio linkshort.ly/sale/sale?utm_campaign=spring_saleEmilyLive
22 MarCRM reactivationEmailNewsletter CTAexample.com/offer?... /offer?utm_campaign=crm_reactivationDeanPlanned
21 MarInfluencer partner pushAffiliateCreator biopartner.link/abc/bundle?utm_campaign=creator_bundleNancyReview

What every row needs

  • Published URL + final URLKeep the exact link that went live and the final destination it resolves to after redirects.
  • Source, medium, campaign, placementThese are the fields that let you tie the launch back to the intended naming contract and later reporting.
  • Owner, date, statusLog who launched it, when it launched, and whether it is planned, live, paused, or retired.
  • Notes and evidenceUse notes for redirect changes, affiliate hops, creative swaps, approval references, and result context.
1

Build the link

Use approved values from naming and taxonomy, then assemble the final URL in the builder.

If the row is heading into Google Ads, decide whether Final URL suffix, a tracking template, or custom parameters should own the append layer before the sheet becomes the source of truth.

2

Run QA

Validate the finished link so missing UTMs, duplicates, and malformed parameters are caught before launch.

3

Check redirects

Confirm the final page is correct and that redirects do not drop parameters or send people to the wrong destination. If the route will be printed, shared offline, or turned into signage, add the controls from QR code tracking for offline campaigns before you approve the row.

4

Log what shipped

Record the live asset, final destination, owner, and status so your reporting has a stable source of truth.

What to log, and what breaks the sheet later

This sheet gets more useful when it is paired with channel-specific naming rules. Use UTMs for email marketing for newsletter and automation rows, and use UTMs for small businesses when the same spreadsheet has to support ads, social, referrals, and QR in one lean workflow.

The sheet should stay boring, stable, and useful. Add the fields you actually need, then use the same structure every time a link goes live. If your team still needs a pre-build control for approved values, row ownership, and launch-state handoff, keep that in the UTM naming template rather than bloating the live log.

Published asset

Log the exact link that went live plus the placement where it appeared. This is the field people usually forget, and it is the first thing they need later.

Final destination

Keep the landing page that the link finally resolves to so redirect changes and network hops do not hide where traffic really went.

Tracking contract

Store source, medium, campaign, and any meaningful content or term value so reporting stays tied to the approved naming decision.

Ownership context

Include owner, date, status, and notes so broken launches can be fixed by the right person without detective work.

Changing names mid-flight

When the campaign label changes after launch, the sheet stops matching reports and GA4 starts splitting traffic across multiple names.

Logging only the destination

If you only keep the intended landing page, you lose the actual published URL and the whole redirect or short-link path goes invisible.

No owner, no follow-through

If nobody owns the row, nobody updates the status, validates the redirect, or fixes the link when attribution goes wrong.

Ready to start the log?

Generate the sheet, log the asset before launch, then route the finished record into QA, redirect checks, and automation only where it makes sense.

UTM QA Checker

Validate the finished link before launch so the spreadsheet never becomes a record of a broken asset.

Use the QA Checker

Redirect Checker

Trace the live route and confirm the final destination so the published record includes what the link actually does in the wild.

Inspect the redirect path

Tracking Automation

Only automate the logging workflow after your naming, QA, and redirect controls are already stable and trusted.

See the automation layer

Automate link logging

Use this when the sheet is no longer the whole workflow and you need publish URLs, final URLs, owners, statuses, and review notes to move faster without losing evidence.

Open automated logging guide

FAQ

Short answers for the operational questions teams ask when they try to keep one campaign tracker clean across multiple channels.

What is the point of a campaign tracking spreadsheet if I already have GA4?

GA4 shows what happened after launch. The spreadsheet records what you intended to publish, who owned it, which URL went live, and where it finally landed.

What should I log before launch?

Log the destination URL, published URL, final destination if redirects are involved, source, medium, campaign, placement, owner, status, and launch timing.

When should I update the sheet after launch?

Update it when the link goes live, when the final destination changes, when ownership changes, and when there is a result or anomaly worth preserving.

Should I still use QA and redirect checks if I log everything here?

Yes. Logging is the recordkeeping layer. You still need the QA Checker to validate the built link and the Redirect Checker to confirm the live route.