How ad targeting decides which ad you see
How real-time bidding, user profiling, contextual targeting, and auction mechanics determine which ad appears in your feed within 100ms.
The Problem Statement
Interviewer: "You open Instagram and see a sponsored post for running shoes. You were just searching for sneakers on Google yesterday. How did that ad end up in your feed? Walk me through the full pipeline, from the moment the app requests an ad to the moment it renders."
This question tests three things: your understanding of real-time bidding (RTB) infrastructure, your knowledge of user profiling and privacy constraints, and whether you can reason about latency budgets in a system that must complete an auction in under 100ms.
Most candidates give a hand-wavy answer about "cookies and tracking." Strong candidates walk through the auction mechanics, explain how bid prices are calculated, and address the privacy landscape that is reshaping the entire industry.
The best answers also include concrete numbers: the 100ms total budget, the 20-30ms DSP processing window, the ~25% iOS ATT opt-in rate, and the revenue split across the supply chain. Numbers signal real understanding rather than surface-level awareness.
Clarifying the Scenario
You: "Before I dive in, I want to scope this correctly. When you say 'how did that ad end up in your feed,' are we talking about the full RTB auction pipeline, or specifically the user profiling and targeting side?"
Interviewer: "Both. Walk me through the end-to-end flow."
You: "Got it. And should I assume we are talking about a programmatic display ad (the kind bought through an ad exchange), not a direct-sold campaign where an advertiser buys placement directly from Instagram?"
Interviewer: "Assume programmatic. That is the more interesting case."
You: "OK. I will structure my answer in four parts: how the ad request triggers an auction, how user profiles are constructed for targeting, how the auction determines the winning ad, and how privacy regulations are changing all of this."
My Approach
I would break this down into five parts:
- The ad request trigger: What happens in the app when an ad slot becomes visible
- The RTB auction pipeline: How SSPs, DSPs, and ad exchanges coordinate in under 100ms
- User profile construction: How the system knows you were searching for sneakers
- Bid calculation and ranking: Why one ad wins over another (it is not just highest bid)
- Privacy and the future: GDPR, iOS ATT, Topics API, and how targeting is evolving
The Architecture
Here is how this works step by step:
-
Ad slot becomes visible. When you scroll past the third post on Instagram, the app detects that an ad placement is about to enter the viewport. It fires an ad request to the publisher's ad server.
-
Publisher ad server handles the request. Meta's ad server receives the request with context: your anonymized user ID, the app section (feed vs stories vs reels), device type, and rough location. It forwards this to the supply-side platform.
-
SSP broadcasts bid requests. The SSP sends a standardized OpenRTB bid request to multiple ad exchanges and DSPs simultaneously. This request includes the user signals and a strict timeout (typically 80-100ms).
-
DSPs evaluate the opportunity. Each DSP receives the bid request and decides whether to bid. They query their data management platforms to match the user to advertiser targeting criteria. The running shoe advertiser's DSP sees that your device ID matches a "sneaker intender" segment and decides to bid aggressively.
-
Auction determines the winner. The ad exchange collects all bids within the timeout window, runs the auction (first-price in most modern exchanges), and selects the winner.
-
Ad renders. The winning creative URL is sent back through the chain to the app, which renders the ad with tracking pixels for impression and click attribution.
The entire pipeline from ad request to ad render completes in 100-200ms. The auction itself takes 50-80ms. This is why DSPs use precomputed user segments rather than running models in real-time for each bid request.
The 100ms Auction Lifecycle
This is the most technically impressive part of ad tech. An entire auction, with dozens of participants, completes in less time than a human blink.
The latency budget breakdown
| Phase | Time Budget | What happens |
|---|---|---|
| App to ad server | 5ms | Client fires request, network hop |
| Ad server to SSP | 5ms | Internal routing, header bidding wrapper |
| SSP to exchange | 5ms | OpenRTB request formatting |
| Exchange to DSPs | 5ms | Fan-out to 10-50 DSPs simultaneously |
| DSP processing | 20-30ms | Segment lookup + bid model execution |
| DSP response | 5ms | Network return |
| Auction resolution | 10-15ms | Compare bids, apply floor, determine winner |
| Return path | 15-20ms | Response chain back to app |
| Ad render | 20-30ms | Creative load + pixel fires |
The 100ms deadline is enforced by the exchange. If a DSP does not respond in time, their bid is simply dropped. There is no "please wait." This is why DSPs invest heavily in low-latency infrastructure, often colocating servers in the same data centers as the exchanges.
User Profile Construction
The question "how did the system know I was looking for sneakers?" is actually the deepest part of this problem. The answer involves multiple data sources stitched together across devices and sessions.
How the shoe search becomes a targeting signal
Here is the concrete chain of events for the sneaker example:
-
You search "best running shoes 2026" on Google. Google records this search query against your Google account. This becomes a first-party signal for Google's ad products.
-
You click on a Nike product page. Nike's website has a Google Ads pixel (and Meta pixel, and Trade Desk pixel). The pixel fires an event: "user viewed Nike Pegasus 41, category: running shoes, price: $130."
-
The pixel creates a retargeting audience. Nike's DSP creates a segment: "users who viewed running shoes in the last 7 days but did not purchase." Your browser cookie or device ID is added to this segment.
-
The segment is synced to the DSP. Through cookie-sync chains (browser) or device graphs (mobile), your identity is matched across platforms. The DSP now knows that the same person who searched on Google also browsed Nike's site.
-
The bid request arrives. When you open Instagram, the bid request includes your device's advertising ID. The DSP matches this to the "sneaker intender" segment and bids aggressively.
Why retargeting bids higher
The running shoe ad you see is not just "an ad for running shoes." It is a retargeting ad, which means the advertiser already knows you expressed interest. Retargeting bids are typically 2-5x higher than prospecting bids (ads shown to people with no prior interaction) because the conversion rate is dramatically higher.
A prospecting campaign might see a 0.5% click-through rate and 1% conversion rate on clicks. A retargeting campaign targeting users who viewed a specific product in the last 24 hours might see a 3% click-through rate and 8% conversion rate. The math makes aggressive bidding rational: even at $3-5 CPM, the cost per acquisition is lower than prospecting at $1 CPM.
This is why you see the same shoe following you across apps. The advertiser is willing to pay more to reach you specifically because you already demonstrated purchase intent.
The cookie sync problem
How does Nike's DSP know that the browser cookie from Nike.com matches the device advertising ID on Instagram? This is the cookie sync (or identity sync) problem.
When you visit Nike.com, a Google Ads pixel fires. Google sets a cookie in your browser and maps it to your Google account. Simultaneously, Meta's pixel fires and maps a separate cookie to your Meta profile. These are different cookies from different companies.
The sync happens through intermediaries called "identity partners" (LiveRamp, The Trade Desk's Unified ID 2.0, etc.). These partners maintain a mapping table: Google cookie X = Meta ID Y = Trade Desk ID Z. The mapping is built when users log in to services with their email address, which is hashed (SHA-256) and used as a common identifier.
Without this sync, the DSP would see you as two different people: one who searched on Google and a completely unknown person on Instagram. The sync is what makes the "shoes following you everywhere" experience possible.
This cross-device, cross-platform identity resolution is the most valuable (and most privacy-sensitive) part of ad tech. A user who searched on desktop and is now on mobile is worth more to advertisers because the intent signal is fresh and the cross-device match demonstrates real interest.
The identity resolution problem
| Method | Coverage | Accuracy | Privacy status |
|---|---|---|---|
| Third-party cookies | Declining (Chrome deprecation) | High | Being eliminated |
| Device IDs (IDFA/GAID) | ~25% on iOS (ATT opt-in), ~70% Android | High | Severely restricted |
| Hashed email (deterministic) | 30-40% of users | Very high | Privacy-compliant |
| Probabilistic matching | 60-70% of users | Medium (70-80%) | Gray area |
| Google Topics API | All Chrome users | Low (coarse topics) | Privacy-first design |
| Contextual only | 100% of impressions | N/A (no user identity) | Fully compliant |
Privacy-Compliant Targeting
This is the section that separates average answers from great ones. The ad targeting industry is in the middle of a fundamental shift, and any answer that ignores privacy is outdated.
The three privacy earthquakes
-
GDPR (2018): Requires explicit consent for tracking in the EU. Users must opt in before any cookies or device IDs are collected. Non-compliance penalties up to 4% of global revenue.
-
iOS App Tracking Transparency (2021): Apple requires apps to ask permission before tracking across other apps and websites. Only ~25% of users opt in. This destroyed the mobile device graph for iOS.
-
Chrome third-party cookie deprecation (2024-2025): Google removed third-party cookies from Chrome (65% browser market share). This eliminates the primary mechanism for cross-site tracking on the web.
In an interview, proactively bringing up the privacy dimension shows you think about systems in the real world, not just in theory. Interviewers love candidates who mention ATT and cookie deprecation because it shows current industry awareness.
The Tricky Parts
-
The 100ms budget is really 50ms for the DSP. By the time the bid request reaches the DSP (network hops, SSP processing), there are only 20-30ms left for the DSP to query segments, run the bid model, and respond. This is why DSPs precompute everything and colocate with exchanges.
-
Second-price vs first-price auctions. Most exchanges have moved from second-price (you pay $0.01 above the second-highest bid) to first-price (you pay what you bid). This changes bidding strategy completely. In first-price auctions, DSPs use "bid shading" algorithms to avoid overpaying, estimating what the second-highest bid would have been and bidding just above that.
-
Frequency capping across platforms. An advertiser does not want to show you the same shoe ad 50 times. But frequency capping requires knowing how many times you have already seen the ad, which requires identity. With cookie deprecation, cross-platform frequency capping is becoming nearly impossible, leading to ad fatigue and wasted spend.
-
Attribution is a mess. Did you buy the shoes because of the Instagram ad, the Google search ad, or the email newsletter? Multi-touch attribution models try to assign credit across touchpoints, but they are increasingly blind due to privacy restrictions. Many advertisers are reverting to media mix modeling (statistical methods that do not require user-level tracking).
-
Ad fraud. Approximately 20-30% of ad impressions are fraudulent (bots, click farms, domain spoofing). The auction infrastructure has to include fraud detection at multiple layers: pre-bid filtering, ads.txt verification, and post-impression anomaly detection.
What Most People Get Wrong
| Mistake | What they say | Why it is wrong | What to say instead |
|---|---|---|---|
| Ignoring latency | "The system analyzes user behavior in real-time" | There is no time for real-time analysis in a 100ms auction | "User segments are precomputed offline and looked up in <5ms at bid time" |
| Assuming full tracking | "Cookies track you everywhere" | Third-party cookies are dead. iOS ATT limits mobile tracking | "The system uses layered targeting: first-party, cohort-based, contextual" |
| Forgetting the auction | "The advertiser pays to show you ads" | It is an auction, not a fixed price. Multiple advertisers compete in real-time | "Multiple DSPs bid simultaneously, and the exchange runs a first-price auction" |
| Ignoring ad quality | "The highest bidder wins" | Bid alone does not determine the winner. Platforms weight relevance and quality | "Winner = bid * quality score * expected engagement rate" |
| Missing the money flow | "The platform gets the ad money" | There is a complex chain of fees between advertiser and publisher | "The advertiser pays the DSP, which pays the exchange, which pays the SSP, which pays the publisher. Each takes 10-30%" |
How I Would Communicate This in an Interview
Here is how I would actually answer this in 90 seconds:
"When you see a shoe ad on Instagram, here is what happened in the last 100 milliseconds.
The app detected an ad slot in your feed and fired a request to Meta's ad server. That server forwarded the request, along with your anonymized user context, to an ad exchange.
The exchange sent bid requests to dozens of demand-side platforms simultaneously, each operating under a strict 80ms deadline. The DSPs looked up your device ID against precomputed audience segments. Nike's DSP saw that your device matched their 'sneaker intender' segment, because you had visited their product page yesterday and their website pixel recorded that visit.
Nike's DSP calculated a bid using a formula that combines their campaign budget, your predicted click-through rate, and a recency multiplier since your visit was less than 24 hours ago. They bid $3.10 CPM.
The exchange ran a first-price auction, Nike's DSP won, and the ad creative URL was sent back to your app, which rendered the shoe ad. Total time: about 100ms.
The interesting dimension here is privacy. On iOS, only about 25% of users opt into tracking through ATT, so the system increasingly relies on contextual targeting and first-party data rather than cross-platform device graphs. This is why the same ad platform might show you highly targeted ads on Google (where they have your search intent) but less relevant ads on a news app (where they only have contextual signals)."
Interview Cheat Sheet
- When asked about ad delivery: Start with the 100ms timeline. It immediately shows you understand the latency constraints that drive every architectural decision.
- RTB auction flow: Publisher ad server, SSP, ad exchange, DSPs, DMP lookup, bid, auction, render. Seven hops in 100ms.
- Bidding formula: Final score = bid price * quality score * predicted engagement. Highest bid alone does not win.
- First-price vs second-price: Most exchanges are now first-price. DSPs use bid shading to avoid overpaying.
- User profiling: Precomputed segments from first-party pixels, CRM hashed matches, and (declining) third-party cookies/device IDs.
- Privacy evolution: GDPR consent, iOS ATT (~25% opt-in), Chrome cookie deprecation. The industry is shifting to cohort-based and contextual targeting.
- Frequency capping: Hard to do cross-platform without cookies. Each platform caps independently, leading to repetitive ads across platforms.
- Attribution: Multi-touch attribution is declining. Media mix modeling (aggregate statistical approach) is making a comeback because it does not require user-level tracking.
- Latency trick: DSPs colocate in the same data centers as exchanges to save 5-10ms of network latency. At 10M QPS, every millisecond matters.
- Fraud: ~20-30% of impressions are fraudulent. ads.txt and sellers.json verify legitimate supply chains.
Test Your Understanding
Quick Recap
- An ad auction completes in under 100ms, with DSPs having only 20-30ms to decide their bid.
- User profiles are precomputed offline from first-party pixels, CRM matches, and (declining) third-party signals, then looked up at bid time in under 5ms.
- The winning ad is determined by bid price multiplied by quality score and predicted engagement, not by bid price alone.
- Most exchanges now use first-price auctions, requiring DSPs to implement bid shading to avoid overpaying.
- iOS ATT, GDPR, and Chrome cookie deprecation have fundamentally reshaped targeting, pushing the industry toward contextual and cohort-based approaches.
- Frequency capping across platforms is an unsolved problem because platforms do not share user-level frequency data with each other.
- Attribution is moving from user-level tracking to aggregate measurement (media mix modeling, incrementality tests) due to privacy restrictions.
- Retargeting bids are 2-5x higher than prospecting bids because users with prior interaction convert at dramatically higher rates.
- Identity sync across platforms (cookie sync, hashed email matching) is the glue that enables cross-device targeting, and it is the piece most impacted by privacy regulations.
Related Concepts
- Caching and CDN architecture: Ad creatives are cached at edge locations to meet the rendering deadline after the auction completes.
- Real-time stream processing: DSPs process millions of bid requests per second using Kafka and Flink-style stream processing.
- Distributed key-value stores: User segment lookups at bid time use systems like Aerospike or Redis with sub-millisecond latency.
- Privacy-preserving computation: Techniques like differential privacy and secure aggregation are being explored for ad measurement without individual tracking.
- Rate limiting and traffic shaping: DSPs must handle 1-10 million bid requests per second, requiring careful traffic management and load shedding when capacity is exceeded.