Booking.com 將每一項產品變更都包在 A/B 測試中——同時有 1,000 多項測試在進行

隨著 Booking.com 成長為最大的旅遊市場平台之一，產品團隊面臨僅憑意見決定功能的風險。該公司運行線上對照實驗已超過十年，並希望每個人（不只是產品經理）都能以低成本、安全且可信賴的資料來驗證想法。

讓實驗成為預設的決策系統：每一項變更，甚至錯誤修正，都以 A/B 測試的形式上線，而且任何人都可以啟動測試、查閱歷史紀錄，並停止有害的測試。

工程師打造了一套內部實驗平台，內含可搜尋的歷來所有成功與失敗紀錄、用於招募、追蹤與指標的通用 API、兩條獨立的監控管線、A/A 測試池，以及預先註冊與成功案例同儕審查等防護措施。每個部門都有專屬的支援團隊，因此任何人都能從頭到尾主導一項實驗。

同時有超過 1,000 項實驗在行動應用程式、旅宿業者工具、客服電話線與內部系統上運行；每一次重新設計、基礎架構變更與錯誤修正都包在測試中，因此產品決策從意見轉向證據，學習成果也在團隊之間重複使用。

在 Booking.com，實驗不是某些團隊使用的工具——而是公司做決定的方式。十多年來，這個旅遊平台一直以證據為基礎進行產品開發，而到了 2017 年，其各部門在任何一天都運行並分析超過一千項同時進行的實驗，涵蓋行動應用程式、旅宿業者工具、客服電話線與內部系統。

這是有意的選擇：民主化。實驗平台是可搜尋的紀錄庫，收錄自第一項實驗以來的每一次成功與失敗，因此任何人都能查閱歷史並形成新的假設。通用 API 將招募、隨機化與報告抽象化，而且每個部門都有專屬的支援團隊，因此執行測試不需要產品管理部門的許可。

信任來自工程紀律：兩條分別維護的管線計算相同的指標，並相互監控；一組 A/A 實驗池驗證統計方法；預先註冊與成功案例同儕審查等防護措施則抑制 p-hacking。公司裡的每個人都有權自行停止有害的實驗。

結果是這樣一家公司：「每一項變更，從整體重新設計與基礎架構變更到錯誤修正，都包在實驗中」，正如工程師在 2017 年一篇論文中所述——這讓產品開發成為一連串經過衡量的押注，而非一連串的意見。

將實驗去中心化，讓數千人得以測試想法，而不必等待產品經理排定優先順序。

可搜尋的成功與失敗紀錄，讓團隊能回顧並建立在彼此的學習成果之上。

值得信賴的基礎架構（雙管線、A/A 池、預先註冊）讓證據成為可被接受的決策仲裁者。

讓實驗平台與業務邏輯保持鬆散耦合，使推出成功的變更就像移除一個 API 呼叫一樣簡單。

賦予任何人停止有害實驗的權力，讓安全與速度得以並存。

如果每個人都能執行低成本、安全的實驗，你就不需要對某個意見達成共識：基礎架構加上證據文化，能將決策轉化為測試，並將失敗轉化為共享、可搜尋的學習。

這套由阿姆斯特丹工程師在 2000 年代中期撰寫的內部框架，歷經擴充但從未重寫；2026 年 Silicon Canals 報導，Booking.com 仍在實際生產的訂房頁面上運行超過 1,000 項同時進行的測試，每年累計數萬項實驗，其中 0.1% 的轉換率變動就相當於八位數的金額。這個模式以「實驗文化」之名傳遍整個產業——供應商平台、公開的實務指南與其他科技公司都採用了 Booking.com 所開創的同一套預設測試模型。