AdTech 領域知識

廣告生態系：誰在買、誰在賣、誰在中間 高頻 基礎

線上廣告本質上是一個即時的雙邊市場：一邊是想買使用者注意力的需求方（demand），一邊是擁有版位與流量的供給方（supply）。中間有一層層的技術平台負責撮合、出價、投放、追蹤與結算。後端工程師進到 AdTech 公司，第一件事就是把這些角色搞清楚，因為每一個角色都對應著一組 API、一份資料流與一種效能要求。

Advertiser（廣告主）

付錢買廣告的品牌或 App 開發商，目標可能是品牌曝光、網站流量、App 安裝、購買轉換。

Agency（代理商）

替廣告主規劃與操作預算、選擇媒體與平台的公司，大型集團常有自己的程式化交易部門（trading desk）。

Publisher（媒體/發布商）

擁有網站或 App 流量並出售版位的一方，例如新聞網站、遊戲 App。目標是提高每次曝光的收益（eCPM）與填充率。

DSP（Demand-Side Platform，需求方平台）

替廣告主「買」流量的平台：接收 ad exchange 送來的競價請求，依目標受眾、預估成效、預算決定要不要出價、出多少。程式化廣告的核心技術難點多在這裡。

SSP（Supply-Side Platform，供給方平台）

替媒體「賣」流量的平台：把版位送到多個 exchange / DSP 競價、設定底價（floor price）、管理廣告品質，以最大化媒體收益。

Ad Exchange（廣告交易平台）

舉辦拍賣的市場：把一次曝光機會（bid request）同時發給多個 DSP，收集出價、決定贏家。現在 SSP 與 exchange 的界線很模糊，常是同一家公司。

Ad Network（廣告聯播網）

較早期的模式：彙集多個媒體的版位打包賣給廣告主，通常有自己的投放與計價規則，透明度較低。

Ad Server（廣告伺服器）

實際決定並遞送廣告素材、記錄曝光點擊的系統。媒體端 ad server 管理直購與程式化需求的優先順序；廣告主端 ad server 統一管理素材與跨平台追蹤。

DMP / CDP

DMP（Data Management Platform）偏重以匿名 ID（cookie、裝置 ID）建立受眾分群、對接 DSP 投放，多依賴第三方資料；CDP（Customer Data Platform）以品牌的第一方資料為核心，整合 CRM、網站、App、門市等資料成統一的使用者輪廓，用於行銷自動化與個人化。隨著第三方 cookie 與裝置 ID 受限，市場重心明顯往 CDP 與第一方資料移動。

MMP（Mobile Measurement Partner）

行動歸因平台（例如 AppsFlyer、Adjust、Branch 一類），作為廣告主與各廣告渠道之間的中立第三方，判定 App 安裝與 in-app 事件該歸功於哪個渠道，並把結果 postback 給各渠道。

一次廣告曝光的生命週期

1. 使用者打開 App，媒體 SDK 向 SSP / ad server 發出廣告請求（帶有版位、裝置、粗略地理位置、同意狀態等）。
2. SSP 把它包成 OpenRTB bid request，透過 exchange 同時送給多個 DSP。
3. 各 DSP 在時間限制內（常見約 100ms 級別，以 tmax 指定）回應出價與素材，或回 no-bid。
4. Exchange 決定贏家與成交價，通知贏家（win notice），把素材回傳給 App 顯示。
5. SDK 回報曝光（impression），使用者可能點擊（click），之後在一段時間內安裝或購買（conversion），由追蹤系統與 MMP 歸因回廣告。
6. 所有事件流入資料管線：用於計費、報表、模型訓練與下一次出價。

計價模式：CPM、CPC、CPA、CPI、oCPM 與 eCPM 高頻 基礎

計價模式決定了風險由誰承擔：按曝光付費時，成效不好的風險在廣告主；按轉換付費時，風險轉到平台（平台得自己預估轉換率才知道每次曝光值多少錢）。這正是 AI 驅動的廣告平台創造價值的地方。

eCPM：把不同計價模式放在同一把尺上比較

Exchange 或媒體端要比較「一個 CPC 廣告」與「一個 CPM 廣告」誰比較值錢，就要換算成每千次曝光的預期收益：

對 DSP 而言，同樣的公式反過來就是出價邏輯：若廣告主願意為每次轉換付 $20，而這次曝光的預估轉換機率為 pCTR × pCVR = 0.0002，那這次曝光的期望價值是 $0.004，也就是 $4 CPM。出價時再扣除平台利潤、乘上 pacing 調整係數，並考慮拍賣機制（第一價需 bid shading）。

def expected_value_cpm(goal: str, price: float, p_ctr: float, p_cvr: float = 1.0) -> float:
    """回傳這次曝光以 CPM 計的期望價值（廣告主的支付意願）。"""
    if goal == "CPM":
        return price
    if goal == "CPC":
        return price * p_ctr * 1000
    if goal == "CPA":
        return price * p_ctr * p_cvr * 1000
    raise ValueError(goal)

def bid_cpm(goal: str, price: float, p_ctr: float, p_cvr: float = 1.0,
            margin: float = 0.2, pacing_multiplier: float = 1.0) -> float:
    value = expected_value_cpm(goal, price, p_ctr, p_cvr)
    return value * (1 - margin) * pacing_multiplier

print(bid_cpm("CPA", 20, 0.01, 0.02))   # 3.2（$/CPM），單次曝光約 $0.0032

核心指標與公式 高頻 基礎

from dataclasses import dataclass

@dataclass
class CampaignStats:
    bid_requests: int
    bids: int
    wins: int
    impressions: int
    viewable: int
    measured: int
    clicks: int
    conversions: int
    spend_micros: int           # 用 micro 單位整數存金額
    revenue_micros: int

    @staticmethod
    def _safe(n: float, d: float) -> float:
        return n / d if d else 0.0          # 分母為 0 時回傳 0，避免報表炸掉

    def report(self) -> dict[str, float]:
        spend = self.spend_micros / 1e6
        return {
            "bid_rate": self._safe(self.bids, self.bid_requests),
            "win_rate": self._safe(self.wins, self.bids),
            "ctr": self._safe(self.clicks, self.impressions),
            "cvr": self._safe(self.conversions, self.clicks),
            "cpa": self._safe(spend, self.conversions),
            "roas": self._safe(self.revenue_micros, self.spend_micros),
            "viewability": self._safe(self.viewable, self.measured),
            "cpm": self._safe(spend, self.impressions) * 1000,
        }

Programmatic 與 RTB：100ms 內完成一場拍賣 高頻 進階

Programmatic advertising 指用軟體自動化買賣廣告；其中 RTB（Real-Time Bidding） 是對每一次曝光即時舉行拍賣。另有 PMP（私有市場，邀請制拍賣）與 Programmatic Guaranteed（保量保價的程式化直購）等形式。大型 DSP 每秒要處理的 bid request 可達數十萬甚至更高等級，每一個都要在嚴格時限內回應。

OpenRTB 協定主要欄位

OpenRTB 是 IAB Tech Lab 制定的業界標準，2.x 版（2.5、2.6）仍是最廣泛使用的版本，以 HTTP POST + JSON 傳輸。請熟悉以下欄位：

{
  "id": "8f2c1a7e-req",
  "at": 1,
  "tmax": 120,
  "cur": ["USD"],
  "imp": [{
    "id": "1",
    "banner": {"w": 320, "h": 50, "format": [{"w": 320, "h": 50}]},
    "bidfloor": 0.8,
    "bidfloorcur": "USD",
    "tagid": "home_banner_bottom"
  }],
  "app": {"id": "app-123", "bundle": "com.example.game", "cat": ["IAB9-30"],
          "publisher": {"id": "pub-77"}},
  "device": {"ua": "Mozilla/5.0 ...", "ip": "203.0.113.10", "os": "Android",
             "devicetype": 4, "ifa": "6d92078a-8246-4ba4-ae5b-76104861e7dc", "lmt": 0,
             "geo": {"country": "TWN", "city": "Taipei"}},
  "user": {"id": "exch-user-abc", "buyeruid": "dsp-user-42"},
  "bcat": ["IAB25", "IAB26"],
  "regs": {"coppa": 0}
}

{
  "id": "8f2c1a7e-req",
  "cur": "USD",
  "seatbid": [{
    "seat": "advertiser-seat-1",
    "bid": [{
      "id": "bid-001",
      "impid": "1",
      "price": 1.35,
      "adomain": ["shop.example.com"],
      "crid": "creative-555",
      "cid": "campaign-9",
      "adm": "<div>...creative markup...</div>",
      "nurl": "https://win.dsp.example/win?b=bid-001&p=${AUCTION_PRICE}",
      "burl": "https://bill.dsp.example/bill?b=bid-001&p=${AUCTION_PRICE}"
    }]
  }]
}

不出價時，DSP 回傳 HTTP 204 No Content（或空的 seatbid）。${AUCTION_PRICE} 是巨集，由 exchange 在通知時替換為實際成交價。nurl 是 win notice、burl 是 billing notice（通常在廣告真正顯示時才觸發，計費應以它為準）。

時間預算拆解：100ms 去哪了

以 tmax = 100ms 為例（實際值依 exchange 而異），下面是示意性的拆解，重點是理解「網路占掉大半，留給 DSP 內部的時間很少」：

第一價 vs 第二價拍賣

import math

def win_prob(bid: float, mu: float, sigma: float) -> float:
    """假設市場最高競爭出價服從 log-normal(mu, sigma)，回傳出 bid 的勝率。"""
    if bid <= 0:
        return 0.0
    z = (math.log(bid) - mu) / sigma
    return 0.5 * (1 + math.erf(z / math.sqrt(2)))

def shade_bid(value: float, mu: float, sigma: float, steps: int = 50) -> float:
    """第一價拍賣：最大化 期望剩餘 = P(win | b) × (value - b)。"""
    best_b, best_surplus = 0.0, 0.0
    for i in range(1, steps + 1):
        b = value * i / steps
        surplus = win_prob(b, mu, sigma) * (value - b)
        if surplus > best_surplus:
            best_b, best_surplus = b, surplus
    return best_b

# value=4 CPM，市場價格中位數約 e^0.7 ≈ 2.0 CPM
print(round(shade_bid(4.0, mu=0.7, sigma=0.5), 2))   # 出價會明顯低於 4

實務上 win price 的分布要靠歷史資料學習（贏了才知道成交價、輸了只知道「比我高」，屬於censored data），而且依媒體、版位、時段而不同。有些 exchange 會在輸標時回傳最低得標價（minimum bid to win）作為回饋。

Header bidding 與 waterfall

傳統 waterfall：媒體依歷史 eCPM 把需求來源排成順序，一個一個問，第一個願意出價高於底價的就成交，即使後面的人願意出更多。Header bidding：在頁面（或 App SDK）載入時同時向多個 SSP/exchange 請求出價，再把最高價送進媒體的 ad server 與直購廣告一起比較。好處是競爭更充分、媒體收益提高；代價是更多的請求量（DSP 會收到同一個曝光機會的多份 bid request）與頁面延遲。開源的 Prebid.js（client-side）與 Prebid Server（server-side）是主流實作。App 端類似的概念常稱為 in-app bidding。

DSP Bidder 內部架構與工程挑戰 高頻 深入

「設計廣告投放系統」是 Appier 真實出現過的系統設計題。Bidder 是其中最核心、最吃效能的元件：它是一個高 QPS、低延遲、讀多寫少、可容忍部分降級的線上服務。以下以業界常見做法拆解其處理管線。

Bidder 的請求處理骨架（Go）

Go 常被用於 bidder 這類高並行網路服務（goroutine、低延遲 GC、單一執行檔部署）。以下示範「整體 deadline + 各階段降級」的寫法：

package bidder

import (
	"context"
	"encoding/json"
	"net/http"
	"time"
)

const internalBudget = 25 * time.Millisecond // DSP 內部處理預算（示意）

type Server struct {
	users    UserStore    // 遠端 KV（帶 timeout 的 client）
	index    *CampaignIndex
	model    Predictor
	pacer    Pacer
	bidLog   chan<- BidLog // 非同步寫 log，由背景 goroutine 批次送 Kafka
}

func (s *Server) HandleBid(w http.ResponseWriter, r *http.Request) {
	ctx, cancel := context.WithTimeout(r.Context(), internalBudget)
	defer cancel()

	var req BidRequest
	if err := json.NewDecoder(r.Body).Decode(&req); err != nil || !req.Valid() {
		w.WriteHeader(http.StatusNoContent) // 不合法就 no-bid，不要回 5xx
		return
	}

	// User lookup：最多等 5ms，失敗就降級為匿名使用者
	uctx, ucancel := context.WithTimeout(ctx, 5*time.Millisecond)
	user, err := s.users.Get(uctx, req.UserKey())
	ucancel()
	if err != nil {
		user = AnonymousUser(req)
	}

	cands := s.index.Match(&req, user) // 記憶體內倒排索引，微秒級
	cands = FilterTargeting(cands, &req, user)
	if len(cands) == 0 {
		w.WriteHeader(http.StatusNoContent)
		return
	}

	preds, err := s.model.PredictBatch(ctx, &req, user, cands)
	if err != nil { // 模型逾時：用各 campaign 的歷史平均 CTR
		preds = FallbackPredictions(cands)
	}

	best, ok := ChooseBid(cands, preds, s.pacer, req.Imp[0].BidFloor)
	if !ok || ctx.Err() != nil { // 已超過內部預算，回應也來不及了
		w.WriteHeader(http.StatusNoContent)
		return
	}

	select { // 非阻塞寫 log：buffer 滿了就丟棄並計數，絕不卡住回應
	case s.bidLog <- NewBidLog(&req, best):
	default:
		droppedLogs.Inc()
	}
	w.Header().Set("Content-Type", "application/json")
	json.NewEncoder(w).Encode(BuildResponse(&req, best))
}

Budget Pacing、Frequency Capping 與 Targeting 進階 深入

Budget pacing：預算要怎麼花

廣告主設定「每日預算 $1,000」。若 bidder 只要符合條件就出價，可能早上 9 點前就花完（流量早上就很多），之後一整天沒有曝光，而且錯過了晚上轉換率更高的時段。Pacing 的目標是讓花費依計畫平滑分配：

兩種常見控制手段：throttling（以機率 p 決定是否參與這次競價）與 bid modification（調整出價倍率）。控制器常用 PID 概念：誤差 e = 目標花費 − 實際花費；P 項依當下誤差調整、I 項累積長期偏差（例如一直花不夠）、D 項抑制震盪。

from dataclasses import dataclass

@dataclass
class PIDPacer:
    kp: float = 0.6
    ki: float = 0.05
    kd: float = 0.1
    integral: float = 0.0
    prev_error: float = 0.0
    throttle: float = 0.5           # 參與競價的機率，0~1

    def update(self, target_spend: float, actual_spend: float, budget: float) -> float:
        """每個控制週期（例如每分鐘）呼叫一次；誤差以預算正規化。"""
        error = (target_spend - actual_spend) / budget      # 正值 = 花太慢
        self.integral = max(-1.0, min(1.0, self.integral + error))   # anti-windup
        derivative = error - self.prev_error
        self.prev_error = error
        delta = self.kp * error + self.ki * self.integral + self.kd * derivative
        self.throttle = max(0.01, min(1.0, self.throttle + delta))
        return self.throttle

# bidder 熱路徑：if random.random() > pacer.throttle: no-bid

分散式預算計數的取捨

數百台 bidder 同時為同一個 campaign 出價，「還剩多少預算」要怎麼算？而且真正的花費要等 win/billing notice 回來才知道，存在延遲。

業界常在「可接受的小幅超支」與「出價延遲」之間取捨：多數平台允許少量超支並由平台吸收，而不是讓每個出價都去做強一致的扣款。這正是 CAP / 一致性取捨在真實業務中的例子（見第 10 章）。

import threading
import time

class BudgetLease:
    """每台 bidder 向中央（例如 Redis 上的 Lua script）申請小額預算切片，本地扣減。"""
    def __init__(self, campaign_id: str, central, slice_micros: int = 5_000_000) -> None:
        self.campaign_id, self.central, self.slice = campaign_id, central, slice_micros
        self.local_remaining = 0
        self.lock = threading.Lock()

    def try_spend(self, price_micros: int) -> bool:
        with self.lock:
            if self.local_remaining < price_micros:
                granted = self.central.acquire(self.campaign_id, self.slice)  # 原子扣減中央餘額
                if granted <= 0:
                    return False                      # 預算已用完
                self.local_remaining += granted
            self.local_remaining -= price_micros
            return True

    def release(self) -> None:
        """優雅關機時把未用完的切片還回中央。"""
        with self.lock:
            if self.local_remaining:
                self.central.refund(self.campaign_id, self.local_remaining)
                self.local_remaining = 0

Frequency capping 實作

Frequency cap 限制同一使用者在一段時間內看到同一廣告（或同一廣告主）的次數，例如「每人每天最多 3 次」，避免疲勞與浪費預算。實作要點：

• 何時讀、何時寫：出價時讀計數判斷是否超過上限；在曝光事件（而非出價或得標）時寫入，因為只有真正顯示才算一次。
• 競態：同一使用者可能幾乎同時有多個請求，讀到相同計數而都出價，導致略為超過上限。通常接受這種小誤差，或在 bid 時做「暫時預留」。
• 資料結構：固定視窗（每日）用 INCR + EXPIRE；滑動視窗（過去 24 小時）用 sorted set 存時間戳，或分桶計數（每小時一桶，查詢時加總 24 桶）以節省記憶體。
• 規模：數億使用者 × 多個 campaign 的計數非常佔記憶體：把同一使用者的所有 campaign 計數放在一個 hash（一次查詢拿全部），並設定 TTL。

import time
import redis

r = redis.Redis(host="localhost", port=6379)

# 曝光發生時：同一使用者所有 campaign 的今日計數放在同一個 hash
RECORD_IMPRESSION = r.register_script("""
local n = redis.call('HINCRBY', KEYS[1], ARGV[1], 1)
redis.call('EXPIRE', KEYS[1], ARGV[2])
return n
""")

def day_key(user_id: str) -> str:
    return f"fc:{user_id}:{time.strftime('%Y%m%d', time.gmtime())}"   # 依 UTC 日切；實務上依廣告主時區

def record_impression(user_id: str, campaign_id: str) -> int:
    return RECORD_IMPRESSION(keys=[day_key(user_id)], args=[campaign_id, 2 * 86400])

def allowed_campaigns(user_id: str, candidates: dict[str, int]) -> list[str]:
    """candidates: campaign_id -> 每日上限。出價時一次 HMGET 取回所有計數。"""
    ids = list(candidates)
    counts = r.hmget(day_key(user_id), ids)
    return [cid for cid, c in zip(ids, counts) if int(c or 0) < candidates[cid]]

Targeting 維度

歸因（Attribution）與追蹤技術 高頻 進階

歸因模型

使用者在購買前可能看過多個渠道的廣告。歸因就是決定「這次轉換的功勞算給誰」，直接影響廣告主的預算分配與平台的計費。

Attribution window（歸因視窗）：點擊或曝光後多久內發生的轉換才算。例如 click-through 7 天、view-through 1 天是常見設定，但各平台與廣告主可自訂。視窗越長，歸因到的轉換越多，但越可能把自然轉換算進來。

-- Last-click 歸因：每筆轉換找 7 天視窗內、時間最近的一次點擊（以 ClickHouse/BigQuery 類 SQL 示意）
WITH candidates AS (
  SELECT
    cv.conversion_id,
    cv.user_id,
    cv.ts         AS conversion_ts,
    ck.campaign_id,
    ck.ts         AS click_ts,
    ROW_NUMBER() OVER (PARTITION BY cv.conversion_id ORDER BY ck.ts DESC) AS rn
  FROM conversions cv
  JOIN clicks ck
    ON ck.user_id = cv.user_id
   AND ck.ts <= cv.ts
   AND ck.ts >  cv.ts - INTERVAL 7 DAY
)
SELECT conversion_id, user_id, campaign_id, click_ts, conversion_ts
FROM candidates
WHERE rn = 1;

追蹤技術

Tracking pixel / tag

網頁上的 1x1 圖片或 JavaScript tag，觸發時對追蹤伺服器發請求，記錄曝光或轉換。受瀏覽器對第三方 cookie 與追蹤器的限制影響很大。

Postback / S2S（server-to-server）

轉換發生後由廣告主的伺服器或 MMP 直接呼叫廣告平台的 API 回報，不依賴瀏覽器。較可靠、不受 ad blocker 影響，但需要雙方用 click ID 等識別碼對上。實作上要支援重試與冪等（同一轉換可能被回報多次）。

Click ID

點擊時產生的唯一 ID，透過跳轉 URL 帶到落地頁或 App，轉換時回傳。是確定性歸因的關鍵；也被用於防止偽造（簽章、過期時間）。

Deep link / Deferred deep link

點擊廣告直接開啟 App 內特定頁面；若尚未安裝，則安裝後首次開啟時仍導到該頁（deferred），並把歸因資訊帶入。iOS 的 Universal Links、Android 的 App Links 是系統層的實作。

行動識別碼與隱私框架現況

隱私法規與後端資料設計 進階

隱私法規不是法務部門的事而已，它直接決定資料表要有哪些欄位、資料保留多久、刪除請求怎麼傳播、資料能存在哪個區域。

Privacy by design：後端怎麼做

1. 資料分類與最小化：標記哪些欄位是個資（PII）、哪些是敏感資料；不需要的就不收。分析用資料盡量只存假名化 ID。
2. 假名化與雜湊：email / 手機正規化後以 SHA-256 雜湊做比對鍵；但要知道雜湊後的 email 仍屬可識別的個人資料（可被字典攻擊），不能當成匿名化。
3. 同意狀態一級化：每筆事件帶 consent 欄位（或可查詢的 consent 版本），下游任務依目的過濾，例如未同意個人化的使用者不得進入再行銷 segment。
4. 刪除傳播：建立「刪除請求 → 所有系統」的工作流，包含 KV store、資料湖、衍生表、備份策略、模型特徵；用 lakehouse 的 delete / MERGE 處理資料湖。要能證明已刪除（稽核紀錄）。
5. 保留期限（retention）：原始事件設 TTL 或分區定期刪除，聚合後的報表可保留較久。
6. 資料落地（data residency）與存取控制：依地區分開儲存、最小權限、存取日誌、加密（傳輸中與靜態）。

import hashlib
import unicodedata

def normalize_email(email: str) -> str:
    e = unicodedata.normalize("NFKC", email).strip().lower()
    return e

def hashed_identifier(email: str, pepper: bytes | None = None) -> str:
    """跨系統比對時常用正規化後的 SHA-256；對內部儲存可再加 pepper（HMAC）降低字典攻擊風險。
    注意：與外部平台比對時雙方必須使用相同的正規化與雜湊規則，因此通常不加 pepper。"""
    data = normalize_email(email).encode("utf-8")
    if pepper:
        import hmac
        return hmac.new(pepper, data, hashlib.sha256).hexdigest()
    return hashlib.sha256(data).hexdigest()

print(hashed_identifier("  Alice@Example.com "))

廣告詐欺（Ad Fraud）與偵測 進階

只要有錢按曝光/點擊/安裝流動，就會有人造假。對平台而言，詐欺流量既浪費廣告主預算、又會污染模型訓練資料（模型學到「某些 App 的點擊率超高」），所以反作弊是資料管線與出價系統的一部分，而不是事後報表。

import statistics
from collections import defaultdict

def ctit_flags(installs: list[dict], min_n: int = 50) -> dict[str, list[str]]:
    """installs: {"source": 媒體或子渠道, "click_ts": 秒, "install_ts": 秒}。
    以來源為單位分析 CTIT 分布，標記可疑來源（規則僅為示意，門檻需依資料校正）。"""
    by_src: dict[str, list[float]] = defaultdict(list)
    for e in installs:
        by_src[e["source"]].append(e["install_ts"] - e["click_ts"])
    flags: dict[str, list[str]] = {}
    for src, ctits in by_src.items():
        if len(ctits) < min_n:
            continue
        reasons = []
        too_fast = sum(1 for t in ctits if t < 10) / len(ctits)
        if too_fast > 0.2:
            reasons.append(f"{too_fast:.0%} installs within 10s of click (injection?)")
        if statistics.median(ctits) > 24 * 3600:
            reasons.append("median CTIT > 24h (click spam?)")
        if reasons:
            flags[src] = reasons
    return flags

ML 在廣告中的角色與 ML Serving 後端工程 高頻 深入

主要應用

CTR / CVR prediction

出價的核心：預估這位使用者在這個情境下點擊/轉換的機率。資料特徵是極高維、稀疏的類別特徵（user id、app id、廣告 id、交叉特徵），經典模型從 logistic regression + 特徵交叉、FM（Factorization Machines）、GBDT，到深度模型（Wide & Deep、DeepFM、DCN 等）。由於直接用於出價，機率校準很重要。

Lookalike audience

給定一群種子使用者（例如高價值顧客），找出行為相似的使用者擴大受眾。可以做成分類問題（種子 vs 一般使用者），或以 embedding 相似度搜尋（近似最近鄰，ANN）。

推薦與個人化

電商商品推薦、動態廣告素材（依使用者看過的商品組出廣告）、推播內容與發送時機最佳化。常見兩階段架構：召回（retrieval，從百萬商品快速找出數百個候選）→ 排序（ranking，用較重的模型精排）。

其他

Bid shading（市場價格預估）、LTV 預測、流失預測、反作弊、預算分配與出價策略（強化學習/最佳化）。

Feature store 與線上/線下一致性

模型訓練用離線資料（資料湖中的歷史事件），推論用線上資料（bidder 查詢的即時特徵）。若兩邊計算特徵的邏輯或時間點不同，模型上線後效果會莫名變差，稱為 training-serving skew。

• 同一份特徵定義產生線上與線下特徵（同一段程式碼或同一個 DSL），避免兩套實作。
• Point-in-time correct join：產生訓練樣本時，只能使用「事件發生當下之前」已知的特徵值，否則會發生資料洩漏（data leakage），離線指標很好、上線很差。
• Log-and-wait：在線上推論時把實際使用的特徵值記錄下來，直接當訓練資料，是最可靠的一致性做法（代價是儲存量）。
• 延遲回饋（delayed feedback）：轉換可能在點擊後數天才發生，訓練時要處理「還沒轉換」不等於「不會轉換」的問題。

Model serving 的延遲

降低延遲的手段：批次預估多個候選、模型量化/蒸餾、特徵快取、把重的部分（使用者 embedding）預先算好、只對過濾後的候選打分。

A/B testing 與實驗平台

• 分流單位：通常以使用者為單位（同一人固定在同組），以 hash(experiment_id + user_id) % 100 決定 bucket，確保穩定且不同實驗之間相互獨立。
• 廣告特有的干擾：不同組的出價策略會共享同一份預算與同一個拍賣市場（A 組出價高會搶走 B 組的曝光），所以常需預算切分（每組各自的預算）或以 campaign 為單位分流。
• 指標：主要指標（CPA、ROAS、營收）+ 護欄指標（latency、timeout rate、超支），並事先決定樣本量與實驗時長，避免偷看結果提早停止（peeking）。
• 灰度與 shadow：新模型先 shadow（只算不用）比對預估分布，再以小流量上線。

import hashlib

def assign_bucket(experiment_id: str, unit_id: str, buckets: int = 1000) -> int:
    h = hashlib.sha256(f"{experiment_id}:{unit_id}".encode()).digest()
    return int.from_bytes(h[:8], "big") % buckets

def variant(experiment_id: str, user_id: str, allocation: dict[str, float]) -> str:
    """allocation 例如 {"control": 0.5, "new_model": 0.5}；同一人永遠得到同一組。"""
    b = assign_bucket(experiment_id, user_id) / 1000
    acc = 0.0
    for name, share in allocation.items():
        acc += share
        if b < acc:
            return name
    return "control"

行銷自動化（AIQUA 類）的後端工程 進階

行銷自動化平台讓行銷人員依使用者行為與分群，透過多個渠道在對的時間送出對的訊息。後端挑戰在於：大量分群計算、大量訊息的排程與節流、多渠道的不同 API 限制、使用者旅程的狀態管理。Appier 的真實面試題「設計發送 LINE 訊息的 API」就屬於這個範疇。

渠道與其特性

分眾（segment）計算的工程問題

• 批次 segment：「過去 30 天購買 ≥ 2 次且最近 7 天未開啟 App」—— 以 Spark / 倉儲 SQL 對全體使用者計算，輸出 user id 清單。數千萬使用者 × 數千個 segment 時，要共用掃描（一次掃描評估多個條件）、增量計算，並把結果以 bitmap（例如 Roaring Bitmap）儲存以便快速做交集與聯集。
• 即時 segment / 觸發：「加入購物車後 1 小時未結帳」—— 需要串流處理與計時器（Flink 的 keyed state + timer 很適合），或延遲佇列。
• 一致性：發送時的使用者狀態可能已與計算 segment 時不同（例如已經結帳），發送前要做最後一次檢查（suppression）。

使用者旅程（journey orchestration）

行銷人員在介面上畫流程圖：「進入條件 → 等待 1 天 → 若未開信則改發推播 → 若購買則離開旅程」。後端本質上是每位使用者一個狀態機實例，數百萬個實例同時存在，大部分時間在「等待」。

實作要點：狀態持久化（DB 或 workflow engine，例如 Temporal 一類的持久化工作流）、大量計時器的排程（時間輪、依到期時間分桶的延遲佇列、Redis sorted set 以到期時間為 score）、事件驅動的提早離開（使用者購買事件要能找到並結束對應實例）、每個步驟冪等（重試不重發）。

大量發送的節流與排程

一次活動要對 500 萬人發送推播，不能一口氣全打出去：外部 API 有 rate limit、自家 App 後端會被瞬間湧入的點擊打爆（thundering herd）、使用者所在時區不同。常見設計：

1. Campaign 排程器把目標名單切成批次（例如每批 1,000 人），寫入佇列（Kafka / SQS），可依使用者時區排定不同發送時間。
2. 多個 sender worker 消費佇列，每個渠道有自己的速率限制器（token bucket；分散式時可用 Redis 實作全域限流）與並行上限。
3. 發送前做 suppression 檢查：退訂、頻次上限（例如每人每天最多 N 則行銷訊息）、勿擾時段、已轉換者排除。
4. 以 (campaign_id, user_id, step) 作為冪等鍵，避免 worker 重試造成重複發送。
5. 處理回應：429 / 5xx 指數退避重試；無效 token 標記清理；結果寫入事件流供報表（送達、開啟、點擊）。

import asyncio
import time

class TokenBucket:
    def __init__(self, rate_per_sec: float, capacity: int) -> None:
        self.rate, self.capacity = rate_per_sec, capacity
        self.tokens = float(capacity)
        self.updated = time.monotonic()
        self.lock = asyncio.Lock()

    async def acquire(self) -> None:
        async with self.lock:
            while True:
                now = time.monotonic()
                self.tokens = min(self.capacity, self.tokens + (now - self.updated) * self.rate)
                self.updated = now
                if self.tokens >= 1:
                    self.tokens -= 1
                    return
                await asyncio.sleep((1 - self.tokens) / self.rate)

async def send_one(client, user: dict, msg: dict, bucket: TokenBucket,
                   sent_keys: set, max_retries: int = 5) -> None:
    key = (msg["campaign_id"], user["id"], msg["step"])
    if key in sent_keys:                       # 實務上用 Redis SET NX / DB unique key
        return
    for attempt in range(max_retries):
        await bucket.acquire()
        resp = await client.push(user["token"], msg)
        if resp.status == 200:
            sent_keys.add(key)
            return
        if resp.status in (400, 404, 410):     # 無效 token：不重試，標記清理
            return
        await asyncio.sleep(min(30, 2 ** attempt))   # 429 / 5xx：指數退避

async def send_campaign(client, users: list[dict], msg: dict) -> None:
    bucket = TokenBucket(rate_per_sec=500, capacity=500)
    sem = asyncio.Semaphore(200)               # 同時在途請求上限
    sent: set = set()
    async def guarded(u: dict) -> None:
        async with sem:
            await send_one(client, u, msg, bucket, sent)
    await asyncio.gather(*(guarded(u) for u in users))

報表系統：從事件到 Dashboard 高頻 進階

Appier 真實系統設計題：「客戶端 SDK 回報大量 JSON，設計統計報表系統」。這是 AdTech 最典型的資料系統：寫入量極大（每次曝光/點擊都是一筆事件）、查詢以聚合為主、客戶希望近即時看到數字，且數字要能對帳。

設計重點

1. 收集端點：無狀態、可水平擴展；SDK 端批次上傳並壓縮；伺服器盡快寫入 Kafka 後回應（不在請求路徑上做聚合）；每筆事件帶唯一 event_id 以便去重。
2. 去重與遲到資料：SDK 重試、網路重送都會造成重複；以 event_id 在一定時間視窗內去重。手機離線後補送的事件要依 event time 歸到正確的時間桶。
3. 預聚合（rollup）：明細事件量太大，dashboard 查詢以 (時間桶, campaign, creative, country, os) 等維度的聚合表為主；只聚合可加總的計數，比率在查詢時計算；UU 用 HyperLogLog 等 sketch 合併。
4. OLAP 儲存：ClickHouse（MergeTree 家族、materialized view 自動聚合）或 Druid / Pinot（從 Kafka 即時攝取）。依時間分區、依常用過濾維度排序。
5. 延遲 vs 精確度：即時數字（分鐘級）來自串流、可能略有誤差；每日批次在資料到齊後重算（含去重、反作弊扣除、時區調整），覆寫為最終數字。在介面上標示「今日數據為預估，將於 T+1 校正」。
6. 查詢層：多租戶權限（客戶只能看自己的資料）、查詢快取、限制可查詢的時間範圍與維度組合，避免單一大查詢拖垮叢集。

-- ClickHouse：原始事件表 + materialized view 自動聚合到分鐘級
CREATE TABLE events_raw
(
    event_id     UUID,
    event_type   LowCardinality(String),   -- impression / click / conversion
    event_time   DateTime,
    campaign_id  UInt64,
    country      LowCardinality(String),
    os           LowCardinality(String),
    user_id      String,
    cost_micros  UInt64
)
ENGINE = MergeTree
PARTITION BY toYYYYMMDD(event_time)
ORDER BY (campaign_id, event_time)
TTL event_time + INTERVAL 30 DAY;           -- 明細保留 30 天

CREATE TABLE campaign_minute_agg
(
    minute       DateTime,
    campaign_id  UInt64,
    country      LowCardinality(String),
    impressions  UInt64,
    clicks       UInt64,
    cost_micros  UInt64,
    uu_state     AggregateFunction(uniq, String)
)
ENGINE = AggregatingMergeTree
PARTITION BY toYYYYMM(minute)
ORDER BY (campaign_id, minute, country);

CREATE MATERIALIZED VIEW campaign_minute_mv TO campaign_minute_agg AS
SELECT
    toStartOfMinute(event_time)            AS minute,
    campaign_id,
    country,
    countIf(event_type = 'impression')     AS impressions,
    countIf(event_type = 'click')          AS clicks,
    sum(cost_micros)                       AS cost_micros,
    uniqState(user_id)                     AS uu_state
FROM events_raw
GROUP BY minute, campaign_id, country;

-- 查詢：比率在查詢時才算；UU 用 uniqMerge 合併 sketch
SELECT
    campaign_id,
    sum(impressions)                         AS imps,
    sum(clicks)                              AS clk,     -- 別名不要與欄位同名，避免 ClickHouse 的循環別名問題
    clk / nullIf(imps, 0)                    AS ctr,
    sum(cost_micros) / 1e6                   AS spend,
    uniqMerge(uu_state)                      AS uu
FROM campaign_minute_agg
WHERE minute >= now() - INTERVAL 1 DAY
GROUP BY campaign_id
ORDER BY spend DESC
LIMIT 20;

面試時如何把領域知識融入回答 高頻

領域知識的價值在於讓你的技術回答有脈絡。不需要假裝是廣告專家，而是在適當時機展現「我知道這些技術在你們的業務裡為什麼重要」。

「為什麼想來 Appier？」

「你覺得我們系統最難的地方是什麼？」

挑一兩點深入，比列一長串好。可選的角度（以業界常見挑戰描述，不要假裝知道內部實作）：

在技術題中自然帶入

可以反問面試官的問題

• 「團隊目前最主要的效能或擴展瓶頸在哪一部分？最近做過最有成就感的優化是什麼？」
• 「線上服務與 ML 團隊之間的協作方式是什麼？模型是由誰負責上線與監控？」
• 「隱私環境的變化（例如識別碼受限）對團隊的系統帶來了哪些工程上的改變？」
• 「實習生通常會參與哪類專案？如何衡量轉正的標準？」

面試自測題