Cross-Review #3：時程壓縮的張力

張力來源

• Economist：POC 時程不宜拖過 2026 Q3（日銀 2026 下半年可能升息，日圓升值稀釋市場故事）
• Context Analyst 法規：合規化時程估 4–6 個月（PIA、PPC 諮詢、系統改造、consent 改版）
• Deep Researcher：3 個月 POC 期最短（含 attrition buffer 與 2 次赴日子樣本）
• Tech Scout：DCR 建置若走完整 Snowflake 架構需 3–4 個月（若用 SaaS 可縮短）

數學不等式

• 合規 4–6 個月 + POC 3 個月 = 7–9 個月
• 今日 2026-04-24 → 2026 Q3 結束 2026-09-30 → 可用 5 個月
• 結論：直線串行必定超時。必須並行、分階段、或接受某些環節降規格。

主線程裁決：並行壓縮

推薦時程表（5 個月內完成 POC）

M0 (今日)    | 並行啟動：法務 consent 改版 + 內部 panel 盤點 + Intage 談判
M0–M1       | 同意書改版上線（既有會員重新 opt-in 推播）
             | Intage 簽 POC MOU（範圍、分潤、退場）
             | 架構 D 聚合層 pre-POC feasibility 跑 1 個月
M1–M2       | 雙邊 opt-in matched panel 招募（目標 200–300）
             | 架構 B（資料留台）技術建置完成
M2–M5       | POC 正式期 3 個月：資料收集 + 3 個假說驗證
M5          | POC 結案報告、paid pilot 客戶簽約、Phase 2 roadmap

關鍵犧牲

1. 跳過完整 DCR 建置：POC 期用架構 D + B 組合，DCR 留給商業化期
2. 既有會員 consent 不全數改版：僅對高頻旅日子集（app 內過去 12 個月有赴日行為訊號）做 opt-in 推播
3. PIA（Privacy Impact Assessment）先做簡版：POC 前 1 個月完成初版，商業化前再做完整版
4. 首期 anchor 客戶談判與 POC 並行：不等 POC 結束再賣，POC 期就邀請 1–2 家 anchor 當 co-funder + observer

若合規真的拖慢（風險情境）

• Plan B：POC 改為「純台灣側」——只證明「台灣發票可識別赴日前購買行為、赴日回來後購買行為」的縱貫有效性，不做跨境 matching
• 這也是有商業價值的中間產品，可獨立賣給日本品牌主（透過 Intage 或直接）
• 保留「跨境 matching」為 Phase 2 目標，不綁死在 POC 期

對 POC 設計的具體指示

1. 提案書必須包含明確時程表，標示「M0–M5」各里程碑與可量測 deliverable
2. 列出「合規 / 技術 / 商業」三軸的依存關係，哪些可並行、哪些必須 sequential
3. 主動提出「Plan B（純台灣側）」作為 fallback，降低 Intage 對時程風險的疑慮
4. 提案內寫明「若合規阻塞超過 2 個月，雙方共同決定是否轉 Plan B」

未解事項

• 台灣 PDPC（2025-08 新成立）的事前諮詢回覆時效
• Intage 內部簽約流程時間（大企業法務週期可能本身就 6–8 週）