> ## Documentation Index > Fetch the complete documentation index at: https://devdocs.xbox.com/llms.txt > Use this file to discover all available pages before exploring further. # 實驗最佳做法和建議 > 在上線遊戲中執行 PlayFab 實驗的最佳做法，包括測試設計、對象規模、樣本比例不符，以及資料導向的決策。 # 實驗回顧 本指南將向您介紹實驗這項做法。其中詳細說明了為何應及早進行實驗、最佳做法建議，並提供可協助您熟悉此程序的資訊。 ## 實驗為何重要 實驗是識別遊戲體驗變更所造成影響的黃金標準。如果您了解遊戲體驗變更的影響，並有資料佐證，就更容易做出決策，讓您打造更有效的遊戲設計、體驗和行銷策略。持續實驗可讓您判斷變更的效果是否會隨著時間而減弱。 無論您處於遊戲開發旅程的哪個階段 (建立或營運)，PlayFab Experiments 都能讓個人、團隊和工作室在收集實證資料的同時，謹慎地變更遊戲體驗，進而協助您確切找出最適合遊戲的做法。 實驗是一種有效的做法，可讓您在受控且有限的對象 (玩家流量) 中深入了解玩家的行為。藉此保護您的玩家群免於不滿意的遊戲體驗。此外，您可以更有效地運用資源，並在上線遊戲中輕鬆啟用或停用遊戲功能。實驗可協助您將決策能力從「我們認為」轉變為「我們知道」。這是一種有效的做法，可讓您在受控且有限的對象 (玩家流量) 中深入了解玩家的行為。藉此保護您的玩家群免於令人反感的遊戲體驗。此外，您可以更有效地運用資源，並在上線遊戲中輕鬆啟用/停用遊戲功能。 以下是遊戲工作室進行實驗時的一些常見目標： * 增加活躍玩家群 * 提高轉換率 * 降低流失率 ## 實驗的可信度很重要 當您根據所執行實驗的結果做出決策時，您會希望確保其中存在關聯/因果關係。實驗的可信度取決於實驗結果的統計顯著性。 可信度是 PlayFab 實驗結果的重點。所有計量都會檢查統計顯著性。 例如，如果您執行的實驗測得留存率提升了 2%，且顯示為統計上顯著，p 值為 0.04，這表示假設 A 和 B 之間沒有差異 (也就是假設虛無假設為真)，觀察到 2% 或更大結果的機率為 4%。真正的差異無法直接測量，因此會使用統計資料取得合理的估計值。雜訊 (隨機性) 有可能誤導我們。 統計顯著性很重要，因為它反映了您的風險容忍度和信賴水準。計量可能每天都會波動，而統計分析為在充滿雜訊的環境中做出商業決策提供了穩固的數學基礎。 PlayFab Experiments 會在 95% 信賴水準或 p 值 0.05 時，將計量變動標示為統計上顯著。 ## 樣本比例不符 (SRM) 樣本比例不符 (稱為 SRM) 是一種資料品質檢查，表示實驗變體之間預期的使用者比例 (例如在實驗開始前設定的比例) 與實驗結束時觀察到的實際使用者比例之間存在顯著差異。 SRM 表示存在某些遺漏資料或重複問題，以不均等的方式影響控制變體和處理變體。受控實驗的基本原則要求處理變體和控制變體在統計上必須相等。違反此原則時，實驗結果可能會受到選擇偏差的影響。 具有 SRM 的分析會被視為不可信，您不應使用它來做出決策。事實上，如果實驗出現 SRM，請勿從分析中得出任何結論 (直到您解決 SRM 為止)。 ### 如何偵測 SRM 讓我們舉一個例子，其中實驗設定為在控制變體和處理變體中各以 10% 流量執行。 | **類型** | **1 天** | **2 天** | **3 天** | **5 天** | **7 天** | **14 天** | **21 天** | | :- | :- | :- | :- | :- | :- | :- | :- | | **處理變體計數** | 105 | 1,050 | 10,500 | 105,000 | 1,050,000 | 10,500,000 | 100,500,000 | | **控制變體計數** | 100 | 1,000 | 10,000 | 100,000 | 1,000,000 | 10,000,000 | 100,000,000 | | **樣本比例** | 1.05 | 1.05 | 1.05 | 1.05 | 1.05 | 1.05 | 1.05 | | **SRM p 值** | 0.7269 | 0.2695 | 0.0005 | \~=0 | \~=0 | \~=0 | \~=0 | 在此情境中，即使兩個實驗組之間的實際比例在每個情境中都相同，但處理組和控制組中的使用者計數越大，p 值就越小。這表示觀察到的結果不如預期。 ### 如何調查 SRM SRM 的調查和解決是一個複雜且不確定的程序。因此，解決 SRM 需要結構化的方法、全面的視野，並了解根本原因的可能性和解決策略。為此， * 從「為什麼會發生這種情況？」這個問題開始 * 針對該 SRM 的原因提出假設 * 預測如果該假設為真，會觀察到哪些證據 * 找出這些證據 * 分析原因以找出解決方案 提出後續問題有助於調查，以擬定解決所需的步驟。例如： * 這是只發生在一個分析/實驗中，還是發生在多個分析/實驗中？ * 處理的作用是什麼？實驗的性質是什麼？ * 現在 (有 SRM) 和之前 (先前沒有 SRM 的實驗) 之間是否有任何變化？ * 是否有任何檢視、管線、篩選條件發生變化？ ### SRM 的常見根本原因 * 遊戲中的處理體驗比控制體驗更常當機 * 處理體驗非預期地傳送不同數量的資料。例如，在用戶端上增加遙測緩衝區的實驗，必定會增加傳回的資料量，進而導致 SRM ## 將實驗作為一種做法 * **從假設開始** 提出假設，以確保實驗有明確的目標和情境。此外，請確保您正在測試的變更足夠重要。 若要形成假設，請使用下列範本： 由於觀察 \[A] 和意見反應 \[B]，我們相信針對玩家 \[D] 變更 \[C] 將會使 \[E] 發生。當我看到 \[F] 並取得 \[G] 時，即可驗證此假設。 * **正確排程實驗** 若要取得可靠的結果，請在可比較的期間內執行 A/B 實驗。請務必考慮季節性的高峰和低谷。 * **實驗的期間** 給實驗足夠的時間。為實驗分配的時間不足可能會使結果產生偏差。如果執行時間太短，您可能無法收集足夠的資料點以得出統計上準確的結論。如果執行時間太長，您可能會因未將勝出的變體推出給潛在玩家而錯失轉換的風險。如果您有疑慮，重新測試是完全合理的。 * **注意實驗組的百分比** 實驗組的百分比決定了您的樣本大小。以正確的樣本大小鎖定對象，否則您將無法取得可靠的結果，而根據這些資料做出的決策可能會有缺陷。 * **避免型一和型二錯誤** 實驗中的統計資料提供的是機率，而不是確定性。因此，它無法 100% 確定實驗的某個變體是否最佳。所以，請避免型一和型二錯誤。 若要避免型一錯誤，請在做出決策之前提高所需的顯著水準 (我們已預設將其設定為 95%)，並延長實驗執行時間以收集更多資料。若要降低型二錯誤的機率，請增加實驗的實驗組母體 (樣本大小)。 * **不要在實驗進行到一半時進行變更** 如果您在理想期間結束前中斷測試，或引進不屬於原始假設的新變數，結果將不可靠。也就是說，將很難判斷轉換提升是由其中一項變更造成，還是只是隨機機率。 請注意，變化越多，您就必須執行測試越長的時間才能取得可靠的結果。請採取細緻的方法。建議在任何變體群組中同時對 2 到 4 個變數進行實驗。這樣可以在測試期間和效率之間取得最佳平衡。 * **注意 p 值所反映的統計顯著性** 確保資料可靠。資料可靠性的衡量標準是統計顯著性，它可判斷結果並非由隨機機率所造成。 p 值用於判斷 AB 實驗所依據之虛無假設中的統計顯著性。它衡量所收集的資料與虛無假設之間的相容性。p 值越低，就越有信心拒絕虛無假設。 * **保持開放的心態** 有時，您可能會想忽略統計資訊，轉而使用傳統知識甚至先前的經驗來做出決策，無論結果多麼令您驚訝。如果您不信服測試的結果，請再次執行並比較資料。 ## 採用實驗文化和程序 實驗文化很有價值。您必須將其融入其他程序中，讓整個組織的每個人都能從中受益。持續進行 A/B 實驗可以大幅提升轉換率，因為您有更大的機會找到為玩家增加正面產品價值的方法。 您可以將決策模式從依賴 HiPPO (最高薪者的意見) 轉變為資料導向的選擇。更多員工的想法將以測試的形式見到天日。重要的是，當嘗試想法很容易時，請談論結果和後續步驟。除此之外，員工也會更有工作動力。 若要建立實驗文化，請為遊戲反覆運算引進可靠且可重複的程序。您可以使用下列基礎步驟，培養持續實驗的文化： * **設定目標** 可行的實驗目標 (例如參與度) 可讓團隊推進實驗，而不是陷入「成長」等抽象目標中。 * **在團隊的支援下進行更多測試並排定優先順序** 收集並分析定性和定量資料，以便根據商業影響腦力激盪並排定假設/想法的優先順序。使用可靠且可重複的架構，在整個實驗旅程中引導您的團隊，否則如果您突然要求他們進行更多實驗並做出多項變更，團隊會感到迷失。 * **將結果傳達給您的團隊** 以團隊形式傳達測試結果，為實驗建立動力。分享可讓團隊深入了解如何反覆調整及改善未來的測試。這會讓大家對進一步的實驗感到興奮。 * **擁抱失敗** 失敗是測試的一部分，請將失敗視為常態。不要讓失敗阻礙實驗，請反思、學習，然後繼續進行實驗。 * **實踐良好的實驗衛生** 為團隊執行的每個實驗建立標準協定。無論由誰控制實驗，這都有助於保持實驗結果的準確性和意義。 ## 執行實驗的建議規劃程序 | **階段** | **描述** | | :- | :- | | **機會分析** | | | 調查 | 實驗擁有者調查並分析實驗機會。排定實驗的優先順序 | | **實驗設計** | | | 範圍界定 | 開始實驗設計。識別目標計量以形成假設 | | 功能設計檢閱 | 完成功能/體驗變更的設計。作為實驗的一部分，它會透過變數引進至處理變體群組 | | 撰寫程式碼 | 實作功能變更 | | 生產環境部署 | 檢閱實驗設計。部署相關的程式碼 | | **實驗建立** | | | 實驗設定 | 在 PlayFab 中建立實驗 | | **實驗執行** | | | 執行 A/B 實驗 | 實驗會根據實驗設定開始。體驗會協調至目標對象。系統會收集遙測並執行統計計算 | | **實驗分析** | | | 評估結果 | 透過計分卡評估結果 | | 做出推出決策 | 專案關係人評估推出決策 | | **推出或復原** | | | 結束實驗 | 將勝出的變體推出至 100% 的對象 | ## Related topics - [分析實驗](/zh-TW/services/playfab/live-service-management/game-configuration/experiments/analyze-experiments.md) - [新式玩家代號的最佳做法和測試](/zh-TW/services/xbox-services/fundamentals/identity/user-profile/gamertags/live-modern-gamertags-best-practices-and-testing.md) - [Insights 最佳做法](/zh-TW/services/playfab/data-analytics/legacy/insights/best-practices.md) - [最佳做法與推出檢查清單](/zh-TW/services/playfab/multiplayer/servers/best-practices.md) - [PlayFab 用量最佳做法](/zh-TW/services/playfab/pricing/consumption-best-practices.md)