How would you design UTM capture and attribution persistence?

WHAT THIS TESTS: This question checks whether you understand the full data pipeline for marketing attribution, not just the front-end snippet. The interviewer wants to see that you can bridge browser storage, session semantics, and backend persistence so that a conversion minutes or weeks later can still credit the original campaign. Senior candidates should also surface privacy constraints and cross-device limitations.

A GOOD ANSWER COVERS four things in order. First, capture: read the query string on the landing page and immediately persist the UTM values to a durable store such as a first-party cookie with an expiration of 30 to 90 days or localStorage as a fallback. Second, session association: generate or reuse a session identifier and bind the attribution data to it so that subsequent page views carry the context without re-reading the URL. Third, event propagation: attach the attribution payload to every analytics event or at least include it in the session context that gets sent with each tracking call. Fourth, conversion persistence: when the user triggers a key event, the backend records the conversion alongside the original attribution fields so that reporting can credit the campaign that started the journey.

COMMON WRONG ANSWERS: Storing UTMs only in sessionStorage so they vanish when the tab closes. Relying on last-click logic without any stored first-touch data, which makes multi-touch analysis impossible. Proposing third-party cookies for attribution, which are largely blocked by modern browsers. Forgetting to handle direct returns: if a user bookmarks the site and comes back later, the system should still retain the original campaign unless a new UTM-bearing link overrides it.

LIKELY FOLLOW-UPS: How would you handle attribution across multiple devices or when a user clears cookies? What happens if the user clicks a new ad two days later, do you overwrite or keep the original? How does Safari Intelligent Tracking Prevention affect your cookie TTL, and would you use server-side storage or fingerprinting to extend it? Can your design support data-driven attribution models that distribute partial credit across several touchpoints rather than giving 100 percent to one?

ONE CONCRETE EXAMPLE: A shopper clicks a summer sale ad on Google and lands on example.com?utm_source=google&utm_campaign=summer_sale. Your landing-page JavaScript parses those parameters and writes source equals google and campaign equals summer_sale into a first-party cookie named attribution that expires in 60 days. On every subsequent page load, your analytics SDK reads that cookie and adds the values to the event metadata. Three days later the shopper creates an account, triggering a conversion event that POSTs to your backend with the same session ID and attribution payload. Your warehouse job joins the conversion row to the original landing event using the session ID, so the marketing team sees the signup credited to the summer sale campaign.