Explain a conversion pixel, click-to-signup flow, and failure points

WHAT THIS TESTS: This question tests whether you understand distributed state management in a browser environment with unreliable storage. The interviewer cares if you know that attribution is not a single request but a multi-step persistence problem across page loads, domains, and time.

A GOOD ANSWER COVERS: First, the click phase: the ad platform appends a click identifier like GCLID to the landing page URL. Second, the landing page phase: JavaScript from the Google tag or a custom snippet reads that parameter and writes it to a first-party cookie or local storage so it survives navigation away from the page. Third, the conversion phase: when the user completes the signup, the same script reads the stored identifier and fires an asynchronous HTTPS request, usually a GET to a tracking endpoint or a POST via the Measurement Protocol, sending the GCLID alongside the conversion event and a timestamp. Fourth, the server side: the ad platform matches the conversion event to the original click using the identifier and attributes credit. Fifth, failure modes: Safari ITP often truncates first-party cookies to seven days or one day; ad blockers and DNS filters prevent the tag from loading entirely; SPA navigation without full page loads can miss tag initialization; race conditions during page unload can abort the pixel request before it completes; cross-domain redirects strip parameters unless explicitly forwarded; and GDPR or CCPA consent banners can delay or block tag execution until consent is granted.

COMMON WRONG ANSWERS: A weak answer treats the flow as a single synchronous redirect chain where the signup page somehow knows the click source automatically. Another red flag is blaming only third-party cookies, since modern conversion tracking relies on first-party cookies and local storage. Candidates who omit the storage step entirely or describe the pixel as an image tag loaded at click time rather than at conversion time show they do not understand deferred attribution.

LIKELY FOLLOW-UPS: How would you handle this in a single-page application where the landing and signup share no full page refresh? How do you make the conversion signal more resilient against ad blockers? What changes when the conversion happens offline or on a mobile app rather than the web? How do consent management platforms affect your tagging strategy?

ONE CONCRETE EXAMPLE: Imagine a user clicks a Google Search ad on Monday. The ad URL contains gclid=abc123. Your landing page script grabs abc123 and sets a first-party cookie named gcl_aw with a thirty-day expiration. The user browses but does not sign up. On Wednesday they return directly and complete signup. The conversion page script reads gcl_aw, finds abc123, and sends an event to Google Ads. If the user was on Safari and the gap was eight days, ITP would have deleted the cookie and the conversion would appear unattributed.