Redirect /progress to the homepage with campaign parameters

[mikaalnaik]

/progress is the vanity URL printed on an out-of-home ad. It has never been a route here, so it 404s today.

Why it carries UTM params rather than redirecting to a bare /

A server-side redirect fires no analytics event of its own. Sending /progress straight to / would land the scan as an ordinary homepage pageview, indistinguishable from organic traffic — so the ad would be uncountable, which defeats the point of giving it its own URL.

Redirecting to /?utm_source=ooh&utm_medium=offline&utm_campaign=progress means GA4 parses those off the landing URL and files the visit under the campaign, so the ad shows up in Reports → Acquisition → Traffic acquisition.

Details worth a look

• The UTM values live in one constant (OOH_DESTINATION) so the campaign can be renamed in a single place. Change these if there's an existing naming convention for other campaigns — utm_medium=offline is what keeps GA4 from filing the visit as "Unassigned".
• Temporary (307), not permanent. A 308 gets cached in the visitor's browser and skips the server on later visits, so repeat scans would go uncounted.
• /progress/ is covered too. skipTrailingSlashRedirect: true is set for the PostHog proxy, so the trailing-slash variant doesn't normalize itself and would otherwise 404.

Testing

/progress and /progress/ → 307 with params intact, one hop, landing on a 200 homepage. /progresss still 404s, so nothing over-matched. Ran dev with a test measurement ID to confirm the gtag snippet loads on the landing URL with the query string attached. tsc --noEmit and eslint clean.

Not verified: the actual GA collect request — the Chrome extension wasn't connected locally. Worth loading /progress once in GA4 Realtime or DebugView after deploy to confirm the campaign registers, ideally before the ad goes to print.

Aside, not fixed here

Client-side PostHog is never initialized — posthog-js is imported in 9 components but there's no posthog.init() anywhere in src, so those posthog.capture calls (pledge, share, subscribe, candidate links) are silent no-ops. That's why this uses GA4. Separate issue.

🤖 Generated with Claude Code

[greptile-apps]

Greptile Summary

Adds temporary redirects from both /progress URL variants to the homepage with fixed UTM campaign parameters.

• Centralizes the campaign destination in OOH_DESTINATION.
• Uses 307 redirects so campaign attribution remains adjustable and repeat requests continue reaching the server.
• Explicitly handles both trailing-slash forms because automatic trailing-slash redirects are disabled.

Confidence Score: 5/5

The PR appears safe to merge, with both intended vanity URL forms redirected to the campaign-tagged homepage.

The fixed same-origin destination preserves the UTM query parameters, and the two exact redirect rules cover the path variants required by the existing trailing-slash configuration.

Important Files Changed

Filename	Overview
next.config.ts	Adds narrowly scoped temporary redirects for /progress and /progress/; no actionable correctness issue was identified.

_{Reviews (1): Last reviewed commit: "Redirect /progress to the homepage with ..." | Re-trigger Greptile}