共用方式為


實驗 (預覽)

實驗是有系統地測試假設或變更的流程,可改善使用者體驗或軟體功能。 此定義也適用於包括技術在內的大多數科學領域,其中所有實驗都具有四個常見的步驟:

  • 開發假設來記錄此實驗的目的,
  • 概述執行實驗的方法,包括設定、測量的內容及方法,
  • 觀察上一個步驟中已定義計量所測量的結果,
  • 得出假設是否已驗證或失效的結論

[查看此影片],快速示範應用程式組態中的實驗,醒目提示使用者體驗最佳化使用案例,以提升您的商務計量。

Azure 應用程式組態中的實驗 (預覽)

在 Azure 應用程式組態中,實驗功能可讓開發人員輕鬆地測試功能的不同變體,並監視功能層級的影響。 設定之後,使用者就能分析新功能、比較功能的不同變體,並立即評估新產品變更的相關計量。 此功能讓開發小組能夠獲得可測量的見解,從而促進更快速且更安全的產品部署。 Microsoft 合作夥伴與 Split Software 合作,在 Azure 應用程式組態中提供實驗功能。 Split 實驗工作區 (預覽) 是 Azure 原生 ISV 資源,適用於 Microsoft 與 Split Software 之間的整合。

Azure 中實驗的高階資料流程。

Azure 中實驗的資料流程圖。

若要開始實驗,首先,您必須識別要實驗的功能及其變化。 接下來是構成功能評估基礎的計量。 若要開始進行您在 Azure 中的第一個實驗,請遵循此教學課程中所述的步驟。

  • 變體功能旗標:代表功能的不同版本或設定。 在實驗中,將會比較變體功能旗標與您感興趣的計量及為應用程式對象所配置流量的相關性。

  • 遙測:遙測是功能變化和相關計量的資料,可用來評估該功能。 針對 Azure 中的設定,功能旗標評估/指派資料會流向遙測提供者。 Application Insights 是實驗設定的遙測提供者。 已定義計量的資料也會流向相同的 Application Insights 執行個體。

  • A/B 測試:A/B 測試 (也稱為分割測試) 是一種業界標準方法,可用來評估技術堆疊中潛在變更的影響。

  • 取樣大小:取樣大小是實驗期間使用者樣本的大小。 這是針對您正在實驗之功能的任何變化所傳送的事件數目。

  • 最小取樣大小:是實驗功能每個變化所需的最小事件數目,可從統計角度顯示值得關注的結果。 樣本大小越大,實驗結果的統計顯著性就越佳。

請考慮下列範例:您想要查看若結帳按鈕為黃色 (變體 A) 或藍色 (變體 B),電子商務網站的客戶是否更有可能按下該按鈕。 若要設定此比較,您很可能會在功能旗標的這兩個變體之間分割流量,並使用點擊次數作為計量來測量其效能。 您的所有功能不太可能都那麼容易地進行測量和立即評估,此時實驗就能派上用場。 執行實驗牽涉到設定下列流程的時間軸:比較與您感興趣之計量相關的每個變體效能。 「A/B 測試」和「實驗」等詞彙通常會交替使用,其中實驗基本上是延伸的 A/B 測試,可讓您在其中有系統地測試假設。

設定您的實驗

開始之前,請在假設探索階段考慮下列問題:您正嘗試透過執行實驗來回答哪些問題? 您應該對哪些功能進行實驗? 為什麼? 甚至是該從哪裡開始? 根據您的業務需求,要遵循哪些策略? 此實驗是否可協助您立即改善應用程式的效能或業務?

識別您希望在發行完整版本之前透過執行實驗達成的目標,您應該在此階段記錄您的計劃。 您要實驗的特徵或功能變化為何? 您感興趣的一些計量為何? 哪些使用者或系統互動的事件可用來擷取資料,以推動這些測量用的計量?

您實驗的好壞取決於您為其收集的資料。 開始實驗之前,必須先判斷您想要用來作為對照物的變體 (基準變體),以及您想要查看變更的變體 (比較變體)。

從實驗中得出結論

得出一個結論 (或視需要得出多個結論) 是您實驗週期的最後階段。 您可以檢查實驗結果,其顯示比較變體與對照變體的成果和影響。 結果也會顯示其統計顯著性。 Statsig 量值確實取決於遙測資料和樣本大小。

結果可協助您將學習和成果總結為可採取動作的項目,讓您能夠立即實作到實際執行環境。 不過,實驗是一個連續過程。 開始新實驗,以持續改善您的產品。

使用實驗的案例

發行防禦

目標:確順暢穩轉換,並在每次發行時維護或改進關鍵計量。

方法:透過實驗逐步推出新功能,監視效能計量,並收集反覆改進的意見反應。

優點:

  • 透過使用護欄計量在釋出早期偵測和解决問題,將廣泛問題的風險降至最低。
  • 透過以即時資料為依據做出明智的決策,協助維護或改進關鍵效能和使用者滿意度計量。

測試假説

目標:驗證假設和假說,以便對產品功能、使用者行為或商務策略做出明智的決策。

方法:透過建立不同的功能版本或案例,使用實驗來測試特定的假説,然後分析使用者戶互動和效能計量以確定結果。

優點:

  • 提供證據型深入解析,以减少不確定性並指導策略性決策。
  • 透過用真實使用者資料確認或否定假説,實現更快的反覆運算和創新。
  • 透過專注於經過證實有效的構想來增強產品開發,最終實現更成功和使用者一致的功能。

A/B 測試

目標:透過比較不同的 UI 變體並確定最有效的設計來最佳化商務計量。

方法:使用實驗執行 A/B 測試來測試 UI 元素、測量使用者互動,以及分析效能計量。

優點:

  • 透過以經驗證據為依據實作 UI 變更來改進使用者體驗。
  • 提高數位產品或服務的轉換率、參與度和整體效率。

適用於智慧型應用程式 (例如,AI 型功能)

目標:透過快速實驗加速生成式 AI (Gen AI) 的採用,最佳化 AI 模型和使用案例。

方法:使用實驗,快速逐一查看 AI 模型、測試不同的案例,並判斷有效的方法。

優點:

  • 增強了 AI 解決方案適應不斷演變的使用者需求和市場趨勢之彈性。
  • 有助於了解縮放 AI 倡議的最有效方法。
  • 根據真實的資料和意見反應,改進 AI 模型的正確性和效能。

個人化和目標實驗

目標:提供根據使用者喜好設定和行為量身打造的個人化內容和體驗。

方法:有效率的調控實驗來測試個人化內容、測量參與度,以及逐一查看個人化策略。

優點:

  • 透過相關和個人化的體驗,可提高業務開發、轉換率和客戶忠誠度。
  • 透過針對特定受眾提供量身打造的訊息和供應項目,推動收入增長和客戶保留。

效能最佳化實驗

目標:透過效能最佳化實驗改進應用程式效能和使用者體驗。

方法:進行實驗以測試效能增強功能、測量關鍵計量,並實作成功的最佳化。

優點:

  • 透過主動式效能改善來增強應用程式可擴縮性、可靠性及回應性。
  • 透過實作有效率的最佳化,將資源使用率和基礎結構成本最佳化。

實驗作業

  • 建立實驗:您可以在發出遙測的變體功能旗標上建立實驗。 建立實驗之後,也會使用該實驗來建立實驗版本。 對功能旗標的任何進一步編輯,都會導致針對該實驗建立新的實驗版本。

  • 封存實驗:封存實驗會將其置於封存狀態。 若實驗已封存,就不會對該實驗執行任何計算。 您稍後可隨時還原實驗,以繼續計算並回到使用中狀態。

  • 復原實驗:復原實驗會將已封存的實驗置於使用中狀態,且會針對實驗繼續計算。

  • 刪除實驗:刪除實驗會刪除 Split 中的實驗及其所有相關資料。 這是無法復原的作業,因此刪除之後就無法還原。

  • 檢查實驗結果:檢查使用中實驗的結果,可讓您查看實驗中每個變體的執行方式。

實驗作業的存取需求

下列各節詳述使用 Microsoft Entra ID 執行實驗相關作業所需的角色。

設定實驗

若要設定所需資源的實驗,包括分割實驗工作區,需要 Azure 訂用帳戶擁有者角色或訂用帳戶參與者和使用者存取管理員角色的組合。

建立或更新實驗

若要建立、更新、封存或刪除實驗,您需要應用程式組態存放區上的應用程式組態資料擁有者角色。 其也需要企業應用程式中的 ExperimentationDataOwner 角色,以管理對已連線 Split 實驗工作區的資料存取權。

讀取實驗結果

若要檢查實驗、其版本及結果,您需要應用程式組態存放區上的應用程式組態資料讀者角色。 其也需要企業應用程式中的 ExperimentationDataReader 或 ExperimentationDataOwner 角色,以管理對已連線 Split 實驗工作區的資料存取權。

計費考量和限制

應用程式組態不會特別針對實驗進行計費。 實驗會透過與 Split 實驗工作區 (預覽) 的整合來提供。 檢查適用於 Azure 應用程式組態之 Split 實驗的定價方案

Split 實驗所需的最小樣本大小為每個變體 30 個。 實驗必須具有最小樣本大小,才能取得實驗結果,否則結果會在成果中顯示「沒有資料」。

下一步