How do you attribute a delayed direct conversion to original ad copy?

WHAT THIS TESTS: Whether you understand how to bridge ad clicks and delayed direct conversions using durable identifiers, first-party state, and server-side validation rather than fragile client-side scripts.

A GOOD ANSWER COVERS: First, the entry moment. When the user clicks the ad, the landing page URL should contain tracking parameters such as utm_content for the specific copy variant plus a unique click or session ID. Your server or a tag manager should immediately parse these parameters and drop a first-party cookie on your own domain that stores the ad copy ID, campaign ID, timestamp, and click ID. Set the cookie expiry to match your business attribution window, commonly 30 to 90 days, so it survives the two-day gap. Second, the conversion moment. Because the user visits directly two days later, there are no new UTM parameters. Your backend must read the existing first-party cookie during the conversion request or page load. It then emits a server-side conversion event to your analytics warehouse and ad platform APIs, passing the original click ID and copy variant metadata. Server-side events are critical because they bypass ad blockers, browser privacy restrictions like ITP, and third-party cookie deprecation. Third, identity resolution and fallback. If the cookie is missing due to clearing or cross-device usage, a logged-in user ID can map to a database record of the last known attribution source. Device fingerprinting or IP matching can serve as lower-confidence fallbacks but should not be the primary method. Fourth, attribution logic. Implement a lookback window and an attribution model such as last non-direct click so the system only credits the ad copy if the conversion falls within the defined days and rules.

COMMON WRONG ANSWERS: Relying solely on a client-side pixel that fires on a thank-you page, which fails when ad blockers are present or when Safari deletes first-party cookies after seven days. Proposing third-party cookies, which are blocked by default in Safari and being deprecated in Chrome. Storing attribution data only in session storage, which disappears when the browser tab closes. Suggesting IP address as a stable cross-day identifier, ignoring NAT and dynamic IP reassignment. Omitting consent management and GDPR or CCPA requirements before dropping attribution cookies.

LIKELY FOLLOW-UPS: How would you attribute the conversion if the user switched from mobile to desktop? How do you prevent duplicate conversions when both a browser pixel and a server-side event fire? What changes when third-party cookies are fully unavailable? How do you reconcile discrepancies between your server-side log and the ad platform's reporting?

ONE CONCRETE EXAMPLE: A user clicks a Facebook ad showing copy variant Summer Sale on Monday morning. The landing page captures fbclid and utm_content=summer_sale_v2 and writes a first-party cookie named _attr containing the copy ID, campaign ID, and a server-side timestamp with a 60-day expiry. On Wednesday the user types the domain directly and completes a purchase. The checkout API reads the _attr cookie, sees the unexpired Monday entry, and sends a server-side Purchase event to the ad platform's Conversions API including the original fbp and event_id. The platform attributes the revenue to the Summer Sale copy variant within the 60-day lookback window.