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.
Why ad targeting needs a real-time decision
When a feed or webpage reaches an ad slot, the publisher has to choose a creative that is relevant, eligible, and valuable before the slot is rendered. In a programmatic flow, many demand-side platforms can evaluate the same opportunity concurrently. The result is a short auction, not a single database lookup.
The running-shoe example is useful because it combines two different ideas: a prior signal may make an audience eligible for a campaign, while the current page, device, consent state, and auction rules determine whether a bid can be made now. The system must also work when the user has no cross-site identifier at all.
Scope and assumptions
This article follows a programmatic display request from an app or publisher ad server through an SSP/ad exchange and DSPs, then back to the client. The latency figures are illustrative budgets; the exact deadline, auction type, identity signals, and consent rules vary by exchange, platform, region, and inventory type. The examples use familiar products to make the flow concrete, not to claim that their private implementations are identical.
30-second mental model
Think of targeting as two pipelines joined at the auction:
- Offline signal pipeline: first-party events, consented data, contextual features, and model outputs are normalized into audience segments or scores.
- Real-time decision pipeline: an ad request carries the signals that are allowed for this impression; DSPs look up precomputed state, calculate a bid, and return before the deadline.
- Policy and measurement: the platform applies eligibility, quality, privacy, and fraud rules, then records impression/click/conversion events for later analysis.
The latency budget explains the architecture: expensive feature engineering and model training happen offline, while the request path performs bounded lookups and simple scoring.
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
Five-minute end-to-end flow
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. The ad server attaches the context that the platform is allowed to use: an advertising or audience identifier when available, the app section or page metadata, device type, and coarse 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 in this example. The render path can be longer because the creative may still need to load. This is why DSPs use precomputed user segments rather than running heavy models in the bid request path.
The 100ms Auction Lifecycle
This is the latency-sensitive part of ad tech. An auction with many participants must complete before the publisher's deadline, so slow participants are treated as if they did not bid.
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 exchange enforces the deadline. If a DSP does not respond in time, its 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 a concrete chain of events for the sneaker example:
-
You search for running shoes on a search service. If you are signed in and have given the relevant permissions, that service may use the search as a first-party signal for its own ad products. It is not automatically shared with every other platform.
-
You visit an advertiser's product page. The site may send a consented event through its analytics or advertising integration: "user viewed a running-shoe product, 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 made available to an eligible buyer. A browser or device identifier may be matched through an approved identity mechanism, but the match can be missing, stale, or blocked by consent and platform policy. A DSP should only use the signal when the permitted linkage exists.
-
The bid request arrives. When the ad slot opens in an app, the request includes the permitted identifier and contextual fields. If the DSP can match them to the audience segment, it can score the opportunity; otherwise it can still bid contextually or decline.
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 an advertiser site, its measurement or advertising integrations may write or receive their own identifiers. Those identifiers are scoped to the provider and are not inherently the same as an identifier held by the app or publisher.
Where policy permits, an identity partner or first-party login can provide a mapping between those identifiers. A common design uses a consented, normalized identifier such as a hashed email, but a hash is not anonymization by itself: it remains personal data when it can be linked back to a person.
Without an allowed match, the DSP sees two unrelated contexts. It can still use first-party or contextual signals, but it should not infer that the same person moved between properties.
Cross-device identity resolution can improve relevance, but it is also one of the most privacy-sensitive parts of the system. Treat the match as conditional data with purpose limitation, consent checks, retention controls, and an explicit fallback when it is unavailable.
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
Privacy is part of the data model, not an afterthought. The available signals depend on consent, browser policy, operating-system permissions, geography, and the relationship between the user and the platform.
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.
-
Browser changes to third-party state: Modern browsers restrict or partition third-party cookies and other cross-site storage. The exact behavior changes by browser and configuration, so a design must work without a universal cross-site identifier.
Privacy affects every stage of the pipeline: collection, identity matching, feature storage, bid eligibility, measurement, and deletion. A robust design has a no-identifier path rather than treating it as an exceptional failure.
Bottlenecks and failure modes
-
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.
Common mistakes
| 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%" |
Practical checklist
- Define the auction deadline, the response path, and a per-stage latency budget; time out slow dependencies.
- Precompute expensive features and keep the bid-time path to bounded lookups and lightweight scoring.
- Separate eligibility, privacy/consent checks, quality, and bid value; the highest bid is not automatically the winner.
- Provide a contextual or first-party fallback when identity signals are unavailable.
- Scope identifiers, retention, hashing, deletion, and cross-device matching to an explicit purpose and consent state.
- Track frequency caps and attribution boundaries; do not promise cross-platform deduplication when platforms do not share identifiers.
- Add pre-bid fraud filters, supply-chain validation, post-impression anomaly detection, and a way to quarantine suspicious inventory.
- Monitor bid timeout rate, cache/segment freshness, win rate, effective CPM, fill rate, creative errors, and privacy-policy failures.
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.