How would you capture and persist UTM parameters for attribution?

WHAT THIS TESTS: This question tests your ability to design a simple, robust data pipeline that connects a client-side event to a server-side record. It's not just about parsing a URL; it's about state management across a user's session. The interviewer is looking for your understanding of persistence mechanisms (cookies vs. local storage), their trade-offs, and how that data ultimately gets associated with a user entity in the backend database for later analysis.

A GOOD ANSWER COVERS: A complete answer describes a three-stage process. First, CAPTURE: on the initial page load, client-side JavaScript checks for UTM parameters in the URL using window.location.search and a parser like URLSearchParams. Second, PERSIST: the captured parameters are stored to survive navigation. The best choice is a first-party cookie with a defined expiration (e.g., 30 or 90 days), as it's automatically sent with subsequent server requests. Third, ASSOCIATE: when a key event occurs (e.g., user creation, purchase), the backend API reads the UTM data from the cookie included in the request and saves it to the relevant database record, such as a new users row or an events table.

COMMON WRONG ANSWERS: A junior-level answer focuses only on the JavaScript parsing step. A major red flag is failing to mention a persistence strategy; storing the UTMs in a JavaScript variable means the data is lost on the next page load. Another mistake is suggesting Local Storage without explaining how that data would be retrieved and sent to the server, since unlike cookies, it is not sent automatically with HTTP requests. Finally, not mentioning an expiration policy for the stored data shows a lack of foresight about data hygiene and attribution windows.

LIKELY FOLLOW-UPS: Expect questions about the trade-offs: "Why a cookie over Local Storage?" (Cookies are sent automatically but have a 4KB size limit; Local Storage is larger but requires manual JS to send). "How would you handle multiple campaigns?" (This opens a discussion on first-touch vs. last-touch attribution). "What is a reasonable expiration time for this cookie?" (Typically 30, 60, or 90 days, aligning with marketing campaign cycles). "How do browser privacy features like ITP affect this design?" (Shorter cookie lifespans may require moving to server-set cookies or other identifiers).

ONE CONCRETE EXAMPLE: A user lands on your-site.com?utm_source=google. Your client-side script parses this and sets a first-party cookie: utm_data={"source":"google"}; max-age=2592000; path=/ (a 30-day expiration). The user browses three more pages. On the fourth page, they sign up. The POST /api/users request from the browser automatically includes the utm_data cookie. Your server-side code reads the cookie, parses the JSON, and writes attribution_source: 'google' into the new row in your users database table. The attribution is now permanently stored.