Ad Ranking ও Real-Time Bidding ডিজাইন

বিজ্ঞাপন র‍্যাঙ্কিং আর real-time bidding (RTB) হলো সিস্টেম ডিজাইনের সবচেয়ে কঠোর latency-চাপের সমস্যাগুলোর একটা। একজন ব্যবহারকারী যখন একটা পেজ খোলে, তখন বিজ্ঞাপনের জায়গাটা ভরাতে পুরো নিলাম — candidate বাছাই, ML scoring, auction — সব মিলিয়ে চোখের পলকের চেয়েও কম সময়ে শেষ করতে হয়। চলো ধাপে ধাপে এগোই।

১. সমস্যা বোঝা (Requirements)

Functional requirements:

• Ad request এলে eligible বিজ্ঞাপন বাছাই, ranking, auction চালিয়ে সেরা বিজ্ঞাপন ফেরত দাও।
• প্রতিটি বিজ্ঞাপনের জন্য pCTR (probability of click) অনুমান করো।
• second-price auction চালাও এবং বিজয়ী ও তার price বের করো।
• Impression ও click ট্র্যাক করো, advertiser-এর বাজেট থেকে কাটো।
• প্রতিটি advertiser-এর daily budget সারা দিন ধরে pacing করো।

Non-functional requirements:

• Latency: পুরো ad serving p99 ১০০ ms-এর কম (RTB external bid হলে আরও কড়া, ১২০ ms timeout-এর মধ্যে)।
• Throughput: শত হাজার থেকে মিলিয়ন QPS।
• Accuracy: ভালো-ক্যালিব্রেটেড pCTR — শুধু ranking নয়, absolute মান গুরুত্বপূর্ণ কারণ দাম এর উপর নির্ভর করে।
• Correctness: budget overspend বা double-charge হবে না।
• Fraud resistance: invalid click/impression ফিল্টার।

২. স্কেল আন্দাজ (Estimation)

Ad requests/সেকেন্ড      : ৫০০,০০০ QPS (পিক)
Eligible ads/request     : হাজার হাজার থেকে সংকোচন করে ~১০০-৫০০
Latency budget (১০০ ms):
  candidate retrieval    : ~১৫ ms
  feature fetch          : ~১৫ ms
  pCTR scoring (৫০০ ad)  : ~৪০ ms
  auction + pacing check : ~১০ ms
  network/serialization  : ~২০ ms

মডেল সাইজ (pCTR DNN)     : ~১০০ MB-১ GB, in-memory serving
Feature lookup           : ৫০০ ad × কয়েকটি feature = কম-latency KV store
Impression/click log     : ৫০০K QPS × ~৩-৫ ইভেন্ট ≈ কয়েক মিলিয়ন ইভেন্ট/সে
                           ~৫০০ বাইট/ইভেন্ট → ~TB/ঘণ্টা
Budget counters          : প্রতি advertiser রিয়েল-টাইম counter (Redis)

মূল শিক্ষা: ৫০০K QPS-এ প্রতিটি রিকোয়েস্টে মাত্র কয়েক দশ মিলিসেকেন্ড — তাই candidate সংকোচন ও দ্রুত in-memory scoring অপরিহার্য, কোনো ধীর DB call নয়।

৩. API ডিজাইন

POST /v1/ad-request
  body: { request_id, user (id/segment/context),
          slot (size, placement, floor_price), device, geo }
  → 200 OK (১০০ ms-এর মধ্যে)
    { "ad_id": "...", "creative_url": "...",
      "price_paid": 2.35, "auction_id": "..." }

POST /v1/track/impression
  body: { auction_id, ad_id, request_id, ts }
  → 202 Accepted

POST /v1/track/click
  body: { auction_id, ad_id, request_id, ts, click_meta }
  → 202 Accepted

POST /v1/campaigns           # advertiser side
  body: { advertiser_id, budget, bid, targeting }

auction_id দিয়ে impression ও click পরে auction-এর সাথে জোড়া লাগে, যা billing ও pCTR training label-এর ভিত্তি।

৪. ডেটা মডেল ও Features

Feature গ্রুপ	উদাহরণ	উৎস	কোথায়
User	segment, আগ্রহ, সাম্প্রতিক আচরণ	profile + stream	online store
Ad / creative	category, format, historical CTR	ad DB	online store
Context	placement, hour, device, geo	request	request-time
Cross	user-segment × ad-category match	compute	request-time
Campaign	bid, remaining budget, pacing rate	campaign DB	online (Redis)
Label (offline)	impression → click? (joined)	log join	offline store

Recommendation-এর মতোই এখানে feature store-এর offline (training) ও online (serving) দুই অংশ একই definition থেকে আসে, যাতে training-serving skew না হয়। pCTR মডেলের জন্য calibration গুরুত্বপূর্ণ — predicted probability যেন বাস্তব click-rate-এর কাছাকাছি হয়, কারণ এর উপর সরাসরি টাকা নির্ভর করে।

৫. হাই-লেভেল ডিজাইন

কম্পোনেন্টগুলো:

• Ad Gateway / Exchange — ad request নেয়, orchestrate করে।
• Targeting / Candidate Service — eligibility (geo, budget>0, targeting match) দিয়ে candidate বাছে।
• Feature Store (online) — user/ad/context feature দ্রুত আনে।
• pCTR Model Server — candidate-প্রতি click probability দেয়।
• Auction Service — eCPM হিসাব, second-price auction, floor price প্রয়োগ।
• Budget / Pacing Service — real-time counter, overspend ঠেকায়।
• Tracking pipeline (Kafka + stream processor) — impression/click লগ, fraud filter, billing।
• Offline training — log থেকে pCTR মডেল retrain।

Flow ধাপে ধাপে:

1. Ad request gateway-তে আসে; request_id তৈরি।
2. Candidate service eligible ads বের করে (targeting + budget>0 + pacing allows)।
3. Feature store থেকে feature এনে candidate ও context-এর সাথে assemble।
4. pCTR model server প্রতিটি candidate-এর click probability দেয়।
5. Auction service eCPM = bid × pCTR হিসাব করে sort; floor price-এর নিচে বাদ।
6. Second-price নিয়মে বিজয়ী ও তার price ঠিক হয়।
7. Pacing/budget service অনুমোদন দিলে বিজ্ঞাপন ফেরত; auction তথ্য লগ হয়।
8. ব্যবহারকারী দেখলে/ক্লিক করলে tracking event Kafka-তে; fraud filter পাস করলে budget কাটা ও training label তৈরি।

৬. গভীরে (Deep Dive)

pCTR Prediction

pCTR মডেল হলো হৃদয়। সাধারণত sparse categorical feature (user_id, ad_id, segment) embedding করে একটা DNN (অনেক সময় Wide & Deep বা DCN ধরনের) ব্যবহার হয়। লক্ষ্য শুধু ranking নয় — calibration জরুরি, কারণ eCPM = bid × pCTR সরাসরি দাম নির্ধারণ করে। মডেল যদি pCTR বেশি দেখায়, advertiser বেশি ক্ষেত্রে জিতবে ও বেশি খরচ করবে; কম দেখালে সিস্টেম revenue হারাবে।

Label আসে impression ও click join করে: দেখানো হয়েছে কিন্তু ক্লিক হয়নি = ০; ক্লিক হয়েছে = ১। কিন্তু সাবধান — সব impression কখনো ক্লিক পায় না, তাই dataset প্রবলভাবে imbalanced; negative downsampling করে পরে prediction recalibrate করতে হয়।

Auction Mechanism (Second-Price)

eCPM দিয়ে candidate sort করার পর top বিজ্ঞাপন জেতে, কিন্তু দাম দেয় দ্বিতীয়-সর্বোচ্চ eCPM থেকে উদ্ভূত মান। সূত্রটা মোটামুটি:

eCPM_i = bid_i × pCTR_i × 1000
winner = argmax(eCPM)
price_paid (CPC) ≈ (eCPM_2nd / pCTR_winner) / 1000 + epsilon
floor price থাকলে: max(price_paid, floor)

Second-price-এর সৌন্দর্য — advertiser-দের নিজের সত্যিকারের মূল্য bid করতে উৎসাহিত করে, কারণ overbid করলেও তারা শুধু পরের জনের সামান্য বেশি দেয়। (বাস্তবে অনেক exchange এখন first-price-এ গেছে, কিন্তু ইন্টারভিউতে second-price-এর incentive logic বোঝানো জরুরি।)

Budget Pacing

একজন advertiser-এর দৈনিক বাজেট সকালেই শেষ হয়ে গেলে সারা দিনের ভালো ব্যবহারকারীদের আর ধরা যায় না। Pacing এটা ঠেকায়। সহজ কৌশল — প্রতি advertiser-এর জন্য একটা probability বা throttle rate রাখা: যদি খরচ লক্ষ্যের চেয়ে এগিয়ে থাকে, কিছু auction-এ অংশগ্রহণ throttle করা হয়। Redis-এ atomic counter দিয়ে real-time spend ট্র্যাক করা হয় যাতে overspend না হয়।

৭. বটলনেক ও স্কেলিং

• Latency: সবচেয়ে বড় চ্যালেঞ্জ। সমাধান — candidate দ্রুত সংকোচন, in-memory feature ও model serving, কোনো synchronous slow DB call নয়, এবং strict timeout (timeout হলে fallback বিজ্ঞাপন বা খালি slot)।
• Model serving cost: ৫০০K QPS × ৫০০ candidate scoring = বিশাল। batching, quantization, এবং feature caching দিয়ে খরচ কমানো হয়।
• Budget consistency: distributed counter-এ race condition থেকে overspend হতে পারে; sharded atomic counter ও সামান্য conservative throttle দিয়ে সামলানো হয়।
• Tracking accuracy: impression/click async হওয়ায় delayed বা lost event হতে পারে; idempotent ingestion ও auction_id দিয়ে de-dup জরুরি।
• Model drift: trend ও inventory বদলায়, তাই pCTR মডেল ঘন ঘন (এমনকি কয়েক ঘণ্টা পর পর) retrain ও calibration monitoring দরকার।

৮. সারসংক্ষেপ

RTB-তে তিনটি জিনিস একসাথে মেলাতে হয়: কঠোর ১০০ ms-এর কম latency, calibrated pCTR দিয়ে ML ranking, আর truthful incentive-যুক্ত auction। এর চারপাশে budget pacing, accurate click tracking আর fraud detection না থাকলে advertiser-রা টাকা হারাবে আর সিস্টেম বিশ্বাসযোগ্যতা হারাবে।