How do I set up a real-time bidding platform for frequency capping and inventory allocation across fragmented retail media supply?

To set up a real-time bidding (RTB) platform for frequency capping and inventory allocation across fragmented retail media supply, you need a system that combines:

• a unified identity and event layer
• a decisioning engine
• inventory forecasting and allocation
• real-time enforcement
• measurement and feedback loops

Here’s a practical blueprint.

---

1) Define the operating model

In retail media, supply is fragmented across:

• multiple retailer properties
• onsite placements
• offsite extension inventory
• different ad servers / SSPs / APIs
• different identity graphs and consent rules

Your RTB platform should act as a central decision layer that:

1. receives bid requests or opportunity signals,
2. looks up user and campaign state,
3. decides whether to bid and how much,
4. enforces frequency caps and budget pacing,
5. allocates inventory across campaigns/retailers in real time.

---

2) Core components

A. Bid request ingestion layer

This is the entry point for opportunity data.

Inputs may include:

• impression opportunities
• user/session IDs
• retailer/site/app ID
• placement metadata
• contextual signals
• timestamp
• consent/privacy flags
• deal type or auction type

Support:

• OpenRTB-like requests
• retailer APIs
• server-to-server callbacks
• batch event ingestion for impression/click conversions

Use a low-latency edge service or gateway.

---

B. Identity resolution and segmentation

Retail media is fragmented because IDs differ by retailer and channel.

You need:

• a unified identity key per user or household where allowed
• mapping from retailer-specific IDs to your internal ID
• consent-aware identity matching
• fallback to contextual or cohort-based logic when identity is unavailable

Store:

• user-level state
• household-level state
• retailer-specific exposure history
• campaign membership / eligibility

---

C. Frequency cap service

This is the most important real-time control.

You need to track exposure counts by:

• user or household
• campaign
• creative
• retailer
• channel
• time window

Typical caps:

• 3 impressions per 24 hours
• 10 impressions per 7 days
• 1 impression per retailer per day

Implementation pattern:

• fast in-memory store like Redis, Aerospike, DynamoDB Accelerator, or similar
• atomic increment/check operations
• TTL-based counters for rolling windows
• optional approximate counting if scale is very high

Example rule evaluation:

• if user has seen campaign X 3 times in the last 24h, do not bid
• if retailer Y already served 2 impressions today, reduce bid or exclude
• if user has reached overall brand cap, suppress all bids

Important:

• use atomic updates to prevent over-serving
• handle retries and duplicate event delivery
• reconcile with impression confirmation events, not just bid wins

---

D. Inventory allocation engine

This decides how to distribute limited inventory across campaigns, retailers, priorities, and goals.

You need to balance:

• campaign budgets
• margin / ROAS goals
• retailer-level commitments
• guaranteed deals vs auction demand
• audience scarcity
• frequency cap constraints
• pacing over time

A simple version:

• rank campaigns eligible for an impression
• score based on bid value, remaining budget, pacing need, and frequency slack
• allocate the impression to the highest-scoring eligible campaign

Better version:

• use a constrained optimization model
• allocate by campaign priority, expected value, and forecasted supply
• reserve inventory for high-value campaigns
• avoid wasting premium inventory early

You may use:

• linear programming
• bandits for exploration
• rule-based throttling
• forecast-driven reservations

---

E. Forecasting and supply planning

Because retail media supply is fragmented, you should forecast inventory per:

• retailer
• placement
• hour/day
• audience segment
• device/channel

Forecast outputs:

• expected available impressions
• expected eligible impressions after caps
• expected win rate
• expected delivery by campaign

Use this to:

• reserve inventory
• set bid floors
• adjust pacing
• prevent underdelivery on guaranteed campaigns

---

F. Real-time bidding/decision service

This is the low-latency brain.

For each bid request:

1. validate request and consent
2. identify user/campaign eligibility
3. check frequency caps
4. check budget and pacing
5. check inventory allocation rules
6. compute bid price
7. return bid or no-bid

Keep latency very low:

• target < 50 ms, ideally much lower
• use local caches for hot data
• minimize network hops
• precompute campaign eligibility where possible

---

3) Data model you need

At minimum:

User exposure state

• internal user ID
• retailer ID
• campaign ID
• impression count
• last seen timestamp
• TTL/window metadata

Campaign state

• campaign ID
• budget
• pacing target
• bid strategy
• frequency rules
• allowed retailers / placements
• priority

Inventory state

• retailer ID
• placement ID
• supply forecast
• reserved quantity
• available quantity
• historical win rate

Decision log

• request ID
• decision
• reason codes
• bid amount
• campaign selected
• cap checks
• latency

This is essential for auditing and troubleshooting.

---

4) Frequency capping design patterns

Pattern 1: Exact counters

Use when scale is moderate and caps must be strict.

Example:

• key = user:campaign:24h
• value = count
• TTL = 24h

Pros:

• precise
• easy to reason about

Cons:

• higher storage footprint

---

Pattern 2: Hierarchical caps

Track multiple levels:

• user + campaign
• user + brand
• user + retailer
• household + brand

This allows nuanced suppression:

• strict campaign cap
• looser brand cap
• retailer-specific caps for inventory fairness

---

Pattern 3: Approximate capping

For very high scale, use sketches or approximate data structures.

Pros:

• lower memory
• faster

Cons:

• may slightly over/under cap

Use only if small inaccuracies are acceptable.

---

5) Inventory allocation approach

Basic rule-based allocation

Good for MVP.

Example rules:

• premium inventory first to guaranteed campaigns
• if user is near cap, shift to lower-priority campaign or no-bid
• if campaign is behind pace, boost allocation
• if retailer inventory is scarce, conserve for high-value audiences

Advanced allocation

Use a scoring model:

score = expected_value × pacing_factor × audience_match × margin_factor × inventory_priority × cap_slack

Then allocate to the highest score among eligible campaigns.

---

6) Serving flow

A typical flow:

1. Retailer sends impression opportunity.
2. Decision engine identifies user.
3. Frequency service returns current exposure counts.
4. Allocation engine checks campaign priorities and supply reservations.
5. Decision engine computes bid.
6. Bid is returned within latency budget.
7. If win occurs, impression is logged.
8. Exposure counters are incremented asynchronously but with idempotency.
9. Forecasts and pacing are updated.

---

7) Handling fragmentation

Fragmented retail supply creates three challenges:

A. Different identifiers

Solution:

• retailer-specific ID mapping
• server-side identity graph
• consent-aware joins

B. Different auction mechanics

Solution:

• normalize all request types into a common internal schema
• apply common decision logic

C. Different reporting latency

Solution:

• treat impression confirmation as eventual
• use event sourcing / reconciliation jobs
• keep a near-real-time state layer plus batch correction

---

8) Tech stack suggestion

Real-time services

• Go, Java, or Rust for low latency
• Redis / Aerospike / DynamoDB for counters
• Kafka / Kinesis / PubSub for event streaming

Storage

• OLTP store for campaign and config state
• warehouse for analytics and forecasting
• feature store for scoring inputs

Analytics / forecasting

• Python jobs
• Spark / Flink / dbt / warehouse SQL

Orchestration

• Kubernetes
• service mesh optional
• autoscaling on traffic spikes

---

9) Governance and compliance

Because retail media involves consumer data:

• respect consent and privacy laws
• minimize PII exposure
• use hashed or tokenized IDs
• maintain data retention limits
• support opt-out and deletion requests
• log all decisions for auditability

---

10) MVP architecture

If you want the simplest viable version:

Build these 5 services:

1. Bid Gateway
2. Identity Resolver
3. Frequency Cap Service
4. Campaign Decision Engine
5. Reporting/Event Pipeline

Store:

• Redis for counters
• PostgreSQL for campaign configs
• Kafka for events
• warehouse for analytics

Logic:

• exact per-user per-campaign caps
• rule-based inventory prioritization
• simple pacing by spend rate
• basic bid shading / bid formula

This gets you a working platform quickly.

---

11) Example decision logic

Pseudo-logic:

if not consented:
    no-bid

if user cap exceeded:
    no-bid

if campaign budget exhausted:
    no-bid

if retailer inventory reserved for higher priority deal:
    no-bid

compute score based on:
    audience match
    pacing need
    inventory priority
    predicted conversion value

bid = base_bid * score
return bid

---

12) Monitoring KPIs

Track:

• bid response latency
• win rate
• impression delivery rate
• cap violation rate
• budget pacing error
• underdelivery / overdelivery
• retailer inventory utilization
• frequency distribution per user
• ROAS / CPA

Important alert conditions:

• counters not updating
• sudden cap breaches
• pacing drift
• inventory starvation
• latency spikes

---

13) Recommended rollout plan

Phase 1

• exact caps
• one retailer
• one campaign type
• rule-based bidding

Phase 2

• multi-retailer identity
• pacing and reservation
• delivery forecasting

Phase 3

• optimization engine
• automated allocation
• advanced measurement

Phase 4

• cross-channel frequency management
• household-level caps
• ML-driven bidding

---

14) Key design principle

The main idea is:

Frequency capping controls exposure; inventory allocation controls opportunity.

Your platform must evaluate both at the same time, in milliseconds, against fragmented supply sources, while keeping state consistent enough to avoid overdelivery and underutilization.

---

If you want, I can also provide:

1. a reference architecture diagram,
2. a database schema, or
3. a sample bidding and capping algorithm in pseudocode or Python.