algo-price-dynamic
依需求、時間和競爭即時調整價格的動態定價
中文翻譯
---
name: "algo-price-dynamic"
description: "實作動態定價策略，依需求、時間和競爭狀況即時調整價格。當使用者需要建立動態定價系統、實作 surge 定價、或針對易逝性庫存最佳化價格時使用，即使他們說的是「即時定價」、「surge pricing」或「依需求調整價格」也一樣。"
metadata:
category: "WP-39 定價演算法"
tags: ["pricing", "dynamic-pricing", "revenue-management", "real-time"]
---
# 動態定價（Dynamic Pricing）
## 概述
動態定價會依需求訊號、時間、庫存和競爭狀況即時調整價格。常見於航空、飯店、叫車和電商。目標：在產能／庫存限制下，讓營收（或利潤）最大化。
## 何時使用
**觸發條件：**
- 要替易逝性庫存定價（飯店房間、機位、活動票券）
- 要替電商實作隨需求變動的定價
- 要建立 surge 定價或依時段定價的系統
**何時不要用：**
- 一次性的定價決策（用 Van Westendorp 或聯合分析）
- 價格調整不切實際時（受管制的市場、長期合約）
## 演算法
```
鐵律：動態定價需要即時資料。過期的資料算出來的是「過去」最佳的價格，不是現在的。三個資料流都必須是最新的：1. 需求訊號（訂位、搜尋、加入購物車）2. 庫存／產能狀態 3. 競爭者價格（適用時）。更新頻率：叫車是分鐘級，飯店是小時級，零售是每天。
```
### 階段 1：輸入驗證
蒐集：目前的需求指標、剩餘庫存／產能、距離到期／活動的時間、競爭者價格、價格下限／上限的限制。
**關卡：** 即時資料串流已接上、商業規則已定義。
### 階段 2：核心演算法
**規則式：** 需求 > 門檻就加價 X%。依庫存水位設定分層規則。
**需求曲線式：** 1. 估計目前條件下的需求曲線。2. 找出讓營收 = P × Q(P) 最大的價格。3. 套用庫存限制：產能吃緊就漲價，有多餘就降價。
**機器學習式：** 訓練模型，在給定情境特徵下預測每個價格點的需求。在預測出的需求曲線上做最佳化。
### 階段 3：驗證
監控：單位營收、訂位速度、客訴、競爭地位。新的定價規則要做 A/B 測試。
**關卡：** 營收有提升，且沒有明顯的銷量流失或客戶反彈。
### 階段 4：輸出
回傳建議價格，附上理由和預期影響。
## 輸出格式
```json
{
"recommended_price": 1200,
"current_price": 999,
"reasoning": {"demand_signal": "high", "inventory_remaining_pct": 15, "competitor_avg": 1100},
"expected_impact": {"revenue_change_pct": 18, "volume_change_pct": -5},
"metadata": {"strategy": "demand-curve", "update_frequency": "hourly"}
}
```
## 範例
### 輸入輸出範例
**輸入：** 飯店房間，距離入住日 3 天，住房率 85%，競爭者平均價格 $150
**預期：** 價格高於競爭者（$160-170），因為住房率高、時間視窗短。
### 邊界情況
| 輸入 | 預期 | 原因 |
|-------|----------|-----|
| 零需求 | 降到價格下限 | 刺激需求，至少回收一些營收 |
| 剩最後一個 | 價格接近上限 | 稀缺性會讓願付價格最大化 |
| 競爭者閃購 | 沒必要就不要自動跟進 | 避免價格戰；先評估你的產品有沒有差異化 |
## 常見陷阱
- **顧客的公平感**：看得見的價格歧視（同一個產品，不同使用者價格不同）會引發反彈。要依時間、通路或組合包來區分，不要依個人。
- **價格戰螺旋**：自動化的競爭定價可能造成逐底競爭。要設絕對下限和變動速率上限。
- **需求自我蠶食**：顧客發現價格之後會降，就會等。這是「策略性顧客」問題，別訓練顧客延後購買。
- **法規風險**：動態定價在緊急時期可能違反反哄抬物價的法律。要內建法律限制規則。
- **A/B 測試偏誤**：測試不同價格會讓營收衡量變困難。控制組放在「錯的」價格，本來就注定虧錢。
## 參考資料
- 營收管理模型（航空／飯店），見 `references/revenue-management.md`
- 動態定價的公平性限制，見 `references/fairness-constraints.md`英文原文
---
name: "algo-price-dynamic"
description: "Implement dynamic pricing strategies that adjust prices in real-time based on demand, time, and competition. Use this skill when the user needs to build a dynamic pricing system, implement surge pricing, or optimize prices for perishable inventory — even if they say 'real-time pricing', 'surge pricing', or 'demand-based price adjustment'."
metadata:
category: "WP-39 定價演算法"
tags: ["pricing", "dynamic-pricing", "revenue-management", "real-time"]
---
# Dynamic Pricing
## Overview
Dynamic pricing adjusts prices in real-time based on demand signals, time, inventory, and competitive conditions. Common in airlines, hotels, ride-sharing, and e-commerce. Objective: maximize revenue (or profit) subject to capacity/inventory constraints.
## When to Use
**Trigger conditions:**
- Pricing perishable inventory (hotel rooms, airline seats, event tickets)
- Implementing demand-responsive pricing for e-commerce
- Building surge pricing or time-based pricing systems
**When NOT to use:**
- For one-time pricing decisions (use Van Westendorp or conjoint)
- When price changes are impractical (regulated markets, long-term contracts)
## Algorithm
```
IRON LAW: Dynamic Pricing Requires REAL-TIME Data
Stale data produces prices optimal for PAST conditions, not current ones.
Three data streams must be current:
1. Demand signal (bookings, searches, cart additions)
2. Inventory/capacity status
3. Competitive prices (where applicable)
Update frequency: minutes for ride-sharing, hours for hotels, daily for retail.
```
### Phase 1: Input Validation
Collect: current demand indicators, remaining inventory/capacity, time until expiration/event, competitor prices, price floor/ceiling constraints.
**Gate:** Real-time data feeds connected, business rules defined.
### Phase 2: Core Algorithm
**Rule-based:** If demand > threshold, increase price by X%. Tiered rules by inventory level.
**Demand-curve based:** 1. Estimate demand curve at current conditions. 2. Find price that maximizes revenue = P × Q(P). 3. Apply inventory constraint: if capacity is scarce, price up; if excess, price down.
**ML-based:** Train model to predict demand at each price point given context features. Optimize over predicted demand curve.
### Phase 3: Verification
Monitor: revenue per unit, booking pace, customer complaints, competitive position. A/B test new pricing rules.
**Gate:** Revenue improved without significant volume loss or customer backlash.
### Phase 4: Output
Return recommended price with reasoning and expected impact.
## Output Format
```json
{
"recommended_price": 1200,
"current_price": 999,
"reasoning": {"demand_signal": "high", "inventory_remaining_pct": 15, "competitor_avg": 1100},
"expected_impact": {"revenue_change_pct": 18, "volume_change_pct": -5},
"metadata": {"strategy": "demand-curve", "update_frequency": "hourly"}
}
```
## Examples
### Sample I/O
**Input:** Hotel room, 3 days until date, 85% occupancy, average competitor price $150
**Expected:** Price above competitor ($160-170) due to high occupancy, short time horizon.
### Edge Cases
| Input | Expected | Why |
|-------|----------|-----|
| Zero demand | Drop to floor price | Stimulate demand, recover some revenue |
| Last unit available | Price near ceiling | Scarcity maximizes willingness to pay |
| Competitor flash sale | Don't auto-match if unnecessary | Avoid price war; assess if your product differentiates |
## Gotchas
- **Customer fairness perception**: Visible price discrimination (same product, different prices for different users) generates backlash. Segment by time, channel, or bundle — not by individual.
- **Price war spiraling**: Automated competitive pricing can create a race to the bottom. Set absolute floors and rate-of-change limits.
- **Demand cannibalization**: If customers learn prices drop later, they wait. This is the "strategic customer" problem — don't train customers to delay.
- **Regulatory risk**: Dynamic pricing may violate anti-gouging laws during emergencies. Build in legal constraint rules.
- **A/B testing bias**: Testing different prices creates revenue measurement challenges. The control group at the "wrong" price loses money by design.
## References
- For revenue management models (airline/hotel), see `references/revenue-management.md`
- For fairness constraints in dynamic pricing, see `references/fairness-constraints.md`