How would you capture UTM parameters for attribution?

WHAT THIS TESTS: This question assesses your ability to connect a business requirement (marketing attribution) to a concrete technical implementation. It tests your knowledge of the full data lifecycle: client-side data capture, state management across a session (persistence), and the critical handoff from an anonymous user to a known user in your backend database. Interviewers are looking for a practical, end-to-end solution, not just a narrow client-side answer.

A GOOD ANSWER COVERS: A complete answer walks through four distinct stages. First, CAPTURE: On page load, client-side JavaScript reads the URL's query string using window.location.search and a URLSearchParams object to parse the UTM parameters. Second, PERSIST: The captured parameters are stored client-side. A first-party cookie is the standard choice, as it's sent with subsequent HTTP requests. Discuss setting a reasonable expiry, like 30 or 90 days, to define the attribution window. Mention localStorage as an alternative but explain why cookies are often better for this use case. Third, ASSOCIATE: This is the most critical step. When the user performs a key action like signing up or logging in, the backend reads the attribution data from the cookie and saves it to the new user's record in the database. This permanently links the attribution data to a user ID. Fourth, ATTRIBUTE: When a conversion event (like a purchase) is recorded for that user ID, your system can join it with the stored attribution data to credit the correct campaign.

COMMON WRONG ANSWERS: A frequent red flag is providing a client-side-only solution. Candidates who only mention storing data in localStorage or a cookie without explaining how that data gets to the backend for permanent storage are missing the main point. Another mistake is failing to describe the association step—how the anonymous data from the cookie is linked to a specific user account upon registration. Finally, simply saying "use Google Analytics" is a non-answer; the question is asking you to design the system yourself.

LIKELY FOLLOW-UPS: Expect questions about attribution models: "How would you handle first-touch vs. last-touch attribution?" or "What if a user has multiple UTM touches over several sessions?" You should also be prepared to discuss the limitations and future of this approach, especially regarding privacy regulations like GDPR and browser changes like Safari's Intelligent Tracking Prevention (ITP), which can limit cookie lifespans to as little as 24 hours.

ONE CONCRETE EXAMPLE: A user clicks a link: mysite.com?utm_source=google&utm_campaign=summer_sale. A script on mysite.com parses these params and sets a first-party cookie named __utm_params with a JSON value {"source":"google","campaign":"summer_sale"} and a 30-day expiry. The user browses but doesn't convert. Two days later, they return directly and sign up. On the POST request to /api/users, the server reads the __utm_params cookie, parses the JSON, and writes google and summer_sale into the initial_utm_source and initial_utm_campaign columns on the new row in the users table. When that user makes a purchase a week later, the system can credit the summer_sale campaign.