匯總服務負載測試架構

歡迎您在準備將這份文件新增至公開指南存放區時提供寶貴意見。

我們建議廣告技術對 100% 的實際工作環境流量執行負載測試：

  1. 廣告技術應以 Attribution Reporting API 存取轉換歸因評估，做為報表用途。
  2. 廣告技術應做出設計決策，同時盡量減少雜訊 (參考資料：設計決策型式)
  3. 測試時，廣告技術應追蹤每日執行的工作數量 (例如依廣告主的工作數量)、轉換事件量和匯總鍵數量估計各處理工作輸入內容 (請參閱 Aggregation Service API 說明文件中的 output_domain_blob_prefix 工作參數)，以及每項輸入報表的預估平均轉換事件。
  4. 進行測試時，廣告技術應根據預期的工作大小 (如報表量、網域大小)，從規模調整指南表格中查詢建議的例項類型，並據此調整部署的匯總服務大小。參考資料：在 AWS 上調整匯總服務的大小指南
  5. 廣告技術應執行匯總工作以進行工作負載測試。

目標

本指南僅適用於轉換歸因評估，其中包含重要設定與設定操作說明，供廣告技術人員用於：

  • 估算匯總轉換歸因評估的負載預期。
  • 根據他們要評估的維度和目標，以及廣告主的大小和區隔，調整鍵設定和設定以成效和雜訊最佳化。

修課條件

本指南適用於廣告技術目標對象。在執行下列步驟前，建議您先參閱使用雜訊、摘要報表設計決策，以及嘗試雜訊研究室來獲得最佳設定。

操作步驟

1. 初始匯總鍵設定策略

根據業務類型和目標，決定您需要幾種不同的鍵結構 (也就是一組維度)。請注意，最佳化鍵結構有助於減少報表雜訊。

您的廣告客戶數量
舉例來說，假設您有 1,000 個廣告客戶。

廣告主的相似度
評估相似之處時，應考量轉換量、相對轉換價值，以及廣告客戶特性的整體涵蓋範圍。您能夠分組的行為越相似，結果的微調程度越高 (由於輸出值的差異較小)，因此雜訊的影響越少。詳情請參閱進階金鑰管理一文。舉例來說，廣告技術可以按照產業、支出和轉換量區隔廣告客戶，如下所示：

  • 產業 (例如：保險、珠寶、成長零售)
  • 支出 (例如：每季低於 $50,000 美元，每季 $50-$150,000 美元，每季 $150,000-$250,000 美元)
  • 轉換量 (低、中、高)

要建立的匯總鍵結構數量
例如，27 (3 x 3) ：3 個產業、3 種支出類型，以及 3 個轉換價值分組。

2. 識別匯總鍵維度

接著，請找出要追蹤曝光和轉換的重要維度，以便估算來源和觸發事件端鍵的數量。

針對每個匯總鍵結構，曝光您需要追蹤的重要維度有助於決定來源端鍵的數量。維度取決於上方第 1 名的廣告客戶類型 (也就是產業、支出、轉換)。以下舉例說明維度：

  • 主要結構 1：(產業 = 保險，支出 = <50,000，轉換量 = 低)

    • A：4 個維度：廣告活動 (例如50 個 可能性)、廣告群組 (例如20 種可能性)、裝置類型 (例如：5 項可能性)、地理區域 (例如：50 個可能性)
      1. 可能的維度組合 = 50 x 20 x 5 x 50 = 250,000。這代表鍵結構 1 來源端鍵的可能維度組合數量。
      2. 需要保留 18 位元 (18 位元 = 262,144 個可能的組合)

  • 主要結構 2：(產業 = 保險，支出 = <50,000，轉換量 = 中)

    • A：4 個維度：廣告活動 (例如30 個 可能性)、廣告群組 (例如80 項可能性)、廣告類型 (例如3 種可能性)、地理區域 (例如：50 個可能性)。
      1. 可能的維度組合 = 30 x 80 x 3 x 50 = 360,000。這代表鍵結構 2 的可能維度組合或來源端鍵的數量。
      2. 需要保留 19 位元 (19 位元) = 524,288 個可能的組合)

  • 主要結構 3：重複 (同樣規劃所有主要結構)

針對每個匯總鍵結構，您必須追蹤轉換的重要維度，才能決定觸發事件端鍵。例如：

  • 主要結構 1：(產業 = 保險，支出 = <50,000，轉換量 = 低)

    • A：2 個維度：產品類別 (例如100 種可能性)、轉換類型 (例如5 種可能性)
      1. 可能的維度組合 = 100 x 5 = 500
      2. 需要保留 9 位元 (9 位元 = 512 個可能的組合)

  • 主要結構 2：(產業 = 保險，支出 = <50,000，轉換量 = 中)

    • A：3 個維度：產品類別 (例如50 種可能性)、產品類型 (10 個可能性)、轉換類型 (3 個可能性)
      1. 可能的維度組合 = 50 x 10 x 3 = 1,500
      2. 需要保留 11 位元 (11 位元 = 2,048 個可能的組合)

  • 主要結構 3：重複執行 (同樣地，所有主要結構都適用)

匯總鍵的預估值

  • 鍵結構 1：250,000 個曝光鍵 x 500 個轉換鍵 = 125,000,000 個鍵
  • 鍵結構 2：360,000 個曝光鍵 x 1,500 個轉換鍵 = 540,000,000 個鍵
  • 主要結構 3：(同樣地規劃現有所有主要結構)
  • 為每個主要結構重複
  • 匯總鍵數量上限 = 540,000,000 個索引鍵 (所有索引鍵結構)。需要保留 30 位元 (30 位元 = 1.07B 個可能的組合)

預期轉換量

請使用以下範例來說明每個匯總鍵結構的預期磁碟區：

  • 主要結構 1：(產業 = 保險、支出 = <50,000，轉換量 = 低)
    • 答：預期鍵結構 1 在未來一季會用大約 $500,000 美元的廣告客戶支出，讓平均千次曝光出價為 $8 美元。預計會產生 62,500,000 次曝光，需要註冊。
    • 預期鍵結構 1 到下一季所構成的平均轉換率為 0.08%，因此必須擷取 50,000 次歸因轉換。評估每次轉換的購物價值和購買次數。
  • 主要結構 2：(產業 = 保險，支出 = <50,000，轉換量 = 中)
    • 答：預期，鍵 2 將佔下一季度平均 $800,000 美元的支出，平均千次曝光出價為 $10 美元。預計會產生 80,000,000 次曝光，需要註冊。
    • 預期鍵 2 在下一季所構成的轉換率平均曝光次數為 0.03125%，因此必須擷取 25,000 次歸因轉換。評估每次轉換的購物價值和購買次數。
  • 為每個主要結構重複

報表傳送和批次處理頻率 (每個廣告主批次)**

針對每個匯總鍵結構，您必須定期傳送轉換報表。我們建議廣告技術依據廣告客戶進行批次處理 (以便更簡化每份報表的資料區隔並提高匯總效率)，並使用報表的 shared_info.scheduled_report_time 欄位進行批次處理。

  • A：每小時
  • B：每天
  • C：每週

附註

  • 如要依廣告客戶進行批次處理，請向廣告主確認服務水準協議。

  • 提高批次處理頻率會增加每批次的雜訊量。(請參閱決策：批次頻率)。

  • 為了避免批次處理出錯而發生錯誤，請確認批次處理使用的是 scheduled_report_time 欄位，而非 report arrival time。舉例來說，如果您每小時批次一次，則上午 11 點的批次應僅納入 scheduled_report_time 介於上午 10 到 11 點之間，而不是在上午 10 到 11 點之間以不同的 scheduled_report_time 抵達的報告 (例如：上午 9 點)。

報告量的估計值

  • 主要結構 1：50,000 次歸因轉換 / 2160 (每季每小時報表) = 每個廣告客戶每小時 24 份摘要報表 (24 x 1000 廣告客戶 = 24, 000 份摘要報表)
  • 主要結構 2：25,000 次歸因轉換 / 2160 (每季每小時報表) = 每個廣告客戶每小時 12 份摘要報表 (12 x 1000 廣告客戶 = 12, 000 份摘要報表)
  • 主要結構 3：重複
  • 每小時的摘要報表總數 = 金鑰結構的 24 份摘要報表 + 金鑰結構 2 的 12 份摘要報表 + ... = 每個廣告主每小時的摘要報表

意見回饋摘要

瞭解廣告技術提供的下列預估值，有助於規劃功能和改善項目，進而因應廣告技術要求的規模。建議提供下列資訊。詳情請參閱 AWS 匯總服務的大小指南：

  • 每項匯總服務工作輸入的網域索引鍵數量上限 (要匯總的鍵)
  • 每項工作的最大輸入資料報表量 (歸因轉換)
  • 每份報表的預估貢獻 (報表中的鍵/值組合)
  • 每項工作的歸因轉換預估分佈情形
  • 工作中的網域金鑰預估分佈情形
  • 預估每小時/天/週的工作數量