共用方式為


實驗 (預覽)

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

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

請查看這段影片,以快速示範 應用程式組態 中的測試,並醒目提示用戶體驗優化使用案例,以提升您的商務計量。

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 量值確實取決於遙測資料和樣本大小。

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

使用實驗的案例

  • 智慧型應用程式 (例如 AI 型功能):透過快速實驗,加速採用通用 AI (Gen AI),並將 AI 模型和使用案例最佳化。 使用實驗,快速逐一查看 AI 模型、測試不同的案例,並判斷有效的方法。 其有助於增強調整 AI 解決方案以符合不斷演進之使用者需求和市場趨勢的靈活度,並協助了解調整 AI 方案最有效的方法。

  • CI、CD 和持續測試 (漸進式功能推出和版本更新):確保可透過每個版本更新順暢地轉換及維護或改善關鍵計量,同時管理功能版本。 利用實驗,使用功能旗標逐步向使用者子集推出新功能、監視效能計量,並收集意見反應以便反覆進行改善。 最好降低將錯誤 (Bug) 或效能問題引入整個使用者群的風險。 其支援在版本推出和功能旗標管理期間進行資料驅動決策,進而提升產品品質和使用者滿意度。

  • 使用者體驗最佳化 (UI A/B 測試):藉由比較不同的 UI 變化及判斷最有效的設計來將業務計量最佳化。 使用實驗執行 A/B 測試來測試 UI 元素、測量使用者互動,以及分析效能計量。 此處最好的回報就是根據經驗辨識項實作 UI 變更來提升使用者體驗。

  • 個人化和目標實驗:提供專為使用者喜好設定和行為量身打造的個人化內容與體驗。 使用實驗來測試個人化內容、測量參與度,以及反覆查看個人化策略。 透過相關的個人化體驗,結果可提高使用者參與度、轉換率和客戶忠誠度。 這些結果反過來又會以量身打造的訊息和供應項目為目標,來推動營收成長和客戶保留。

  • 效能最佳化實驗:提升應用程式效能,並透過效能最佳化實驗來提供有效率的使用者體驗。 進行實驗以測試效能增強功能、測量關鍵計量,並實作成功的最佳化。 在這裡,實驗可透過主動式效能改善來增強應用程式可擴縮性、可靠性及回應性。 其會透過實作有效率的最佳化,將資源使用率和基礎結構成本最佳化。

實驗作業

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

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

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

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

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

實驗作業的存取需求

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

設定實驗

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

建立或更新實驗

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

讀取實驗結果

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

計費考量和限制

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

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

下一步