2023 年第 2 季的季度報告匯總了我們在 Privacy Sandbox 提案和 Chrome 回覆中收到生態系統的意見回饋。
根據對 CMA 的承諾，Google 同意公開提供每季報告，說明其 Privacy Sandbox 提案的相關人員參與程序 (請參閱承諾第 12 和 17(c)(ii) 項)。這些 Privacy Sandbox 意見回饋摘要報表是匯集 Chrome 從意見回饋總覽頁面上列出的各種來源的意見回饋匯總而成，包括但不限於：GitHub 問題、privacysandbox.com 上的意見回饋表單、與業界相關人士的會議，以及網頁標準論壇。Chrome 十分歡迎生態系統收到的意見回饋，並積極探索如何將所學知識整合至設計決策中。
意見回饋主題是依 API 的常見程度排名，方法是擷取 Chrome 團隊針對特定主題收到的意見回饋總數，並依數量遞減排序。我們透過公開會議 (W3C、PatCG、IETF)、直接意見回饋、GitHub 及 Google 內部團隊和公開表單提出的常見問題，找出常見的意見回饋主題。
更明確地說，網路標準體系會議的會議分鐘數都經過審查，而為了直接提供意見回饋，Google 的 1:1 相關人員會議記錄、個別工程師收到的電子郵件、API 郵寄清單和公開意見回饋表單接著，Google 會和參與這些各種外聯活動的團隊協調，判斷各主題相對於各 API 的相對情況。
我們根據已發布的常見問題、對利害關係人提出問題的實際回應，制定了 Chrome 回應回應的說明，並針對這項公開報告練習制定專屬定位。回顧目前的開發和測試重點，以及有關 Topics、Protected Audience 和 Attribution Reporting API 的問題和意見回饋。
在目前的報表統計期結束後收到的意見回饋，可能尚未視為 Chrome 的回應。
縮寫詞
- 方塊
- 具有獨立分區狀態的 Cookie
- DSP
- 需求端平台
- FedCM
- Federated Credential Management
- FPS
- 第一方集合
- IAB
- 互動廣告協會
- 印尼盾
- 識別資訊提供者
- 網際網路工程任務組 (IETF)
- 網際網路工程任務組
- IP
- 網際網路通訊協定位址
- openRTB
- 即時出價
- 延長賽
- 來源試用
- PatCG
- 私人廣告科技社群
- RP
- 宗教派對
- 賣方平台
- 供應端平台
- TEE
- 受信任的執行環境
- UA
- 使用者代理程式字串
- UA-CH
- 使用者代理程式用戶端提示
- W3C
- 全球資訊網協會
- 建構中
- 有益 IP 盲點
一般意見回饋，無特定 API/技術
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 資料管理與監管法規遵循 | 業界指南：使用 Privacy Sandbox 時遵循法規要求。 | 如同任何新技術，各家公司必須確保 Privacy Sandbox 的使用行為遵守法律；Google 無法提供任何法律建議。但我們瞭解，這是整個生態系統最關注的領域。我們發布了各種 API 相關技術文件，這些說明文件旨在提供必要的法律評估基礎。此外，我們正致力於為公司盡力遵守法規要求並提供其他資料。 |
| CMA 量化測試提案 | 進一步瞭解 CMA 量化測試提案 | 我們正與 CMA 合作設計實驗，概略瞭解第三方 Cookie 淘汰的影響，以及 Privacy Sandbox 提案對生態系統的影響。4 月時，CDA 發布了概略指南，說明在測試和試用期間的預期影響，並於 6 月提供詳細指南。因此，我們鼓勵您針對 CMA 的量化測試提案提出疑問或意見回饋，並直接與 CMA 分享。 |
| Chrome 輔助測試模式 | 測試時間表的詳細資訊和說明 | 我們在 5 月 18 日發布了一篇網誌文章，進一步說明 Chrome 輔助的兩種測試模式。這些細節尚未定案，我們會在 2023 年第 3 季推出進一步的導入指南。 |
| 分區儲存空間 | 在 Chrome 協助進行的測試中，是否會使用分區儲存空間？ | 在第三方 Cookie 淘汰實驗之前，我們會向所有使用者運送儲存空間分區。因此，所有實驗組都會啟用這項功能。針對在這段時間內，網站可以選擇啟用淘汰試用功能，以便取回未分區的儲存空間。 |
| 實際工作環境支援 | Chrome 目前採取什麼程序來支援 Privacy Sandbox 技術問題和影響生態系統的提報問題？ | Google 提供多種管道，讓廣告技術人員回報問題，以及進行必要的提報。 如要進一步瞭解公開和私人論壇，以便使用者提供意見和提報問題，請參閱開發人員文章。 |
| 註冊時程 | 目前的報名期限太短 | 我們仍在評估政策施行期限，因此我們希望向生態系統分享更合適的時程。 |
| 鄧白氏環球編碼 | 進一步瞭解註冊與認證的鄧白氏環球編碼規定 | 參與者可前往鄧白氏集團的網站，瞭解取得鄧白氏環球編碼的相關規定。相關規定會因市場而異，因此參與者務必前往網站，瞭解感興趣的特定市場。但一般而言，參與者必須提供商家基本資訊，例如商家名稱、地址，以及業主或管理員的聯絡資訊。參與者也需要提供財務資訊，例如公司的年度收益。申請完成後，D&B 會進行審查，並在申請獲準後核發鄧白氏環球編碼。 |
| 從來源試用轉換至正式發布 | 從來源試用轉換至正式發布版會影響目前的來源試用測試人員嗎？ | 自 7 月起，測試人員將能使用關聯性和評估 API 正式發布。如此一來，來源試用資格和正式發布版會重疊。 |
| AdExchanger 研究 | 進一步瞭解問卷調查方法 | 這份問卷調查請作答者估算商家的同步率和收益。作答者可自行決定回答個別問題的方法。 |
| 參數值 | 雜訊等級、匿名性門檻和隱私權預算等參數值是如何決定的？ | 這個 GitHub 說明提供了 Privacy Sandbox API 背後的一般原則。許多價值觀仍未定案，歡迎針對這個主題提供意見。 |
顯示相關內容與廣告
主題
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 保護隱私權 | 評估 Topics API 以保護隱私權 | 我們積極與研究社群互動，在論文、報告和研討會簡報中，針對 Topics API 的隱私權屬性進行研究。我們很高興看到研究社群中有更多外部成員能與這個領域互動。 Topics API 會難以大規模追蹤使用者，防止使用者在網路上進行一般追蹤。這些報告顯示我們順利採用 Topics API 來達成這個目標。這種 Cookie 比第三方 Cookie 更能保護使用者，並可保護使用者，同時支援他們造訪的網站。 |
| 主題分類的精細程度不足 | 廣泛主題分類不包含更精細的主題，包括特定區域。 | 為因應我們先前對生態系統的意見回饋，我們在 6 月 15 日發布了一篇網誌文章，詳細說明新版分類法，其中彙整了從生態系統提出意見後所得到的多項改善。在更新分類的過程中，我們與生態系統中的多家公司合作，例如 Raptive (舊稱 CafeMedia) 和 Criteo。新版分類法則將我們聽過的類別移除較不實用，但會優先排除與廣告客戶興趣更相符的類別，同時也會繼續致力於排除潛在的敏感主題。 我們鼓勵生態系統回顧最新的分類，並針對異動提供意見回饋。 |
| 分類和分類器更新程序 | 進一步瞭解 Topics 分類和分類器的發布頻率，以及公司如何為這類更新做好準備。 | 如近期的網誌文章所述，我們預期分類方式會隨著時間改變，且對於分類管理，最終轉型將轉型為代表業界各方利害關係人的外部人員。我們也在 topics-announce 群組中分享了增加曝光量的計畫。 |
| 對第一方信號的影響 | 近期分類更新中的 Topics 數量增加可能價值極大，這也會導致其他第一方興趣信號的價值降低。 | 在 2023 年第 1 季的報告中，CMA 表示：「我們瞭解 Google 一直與多位廣告技術供應鏈的市場參與者討論他們提議的新分類。儘管有少數大型發布商表示，提高主題實用性會使第一方資料解決方案的競爭壓力加重，但我們初步的調查結果是，整體競爭更有幫助，更重要的是，可讓小型發布商在淘汰第三方 Cookie 後，持續透過廣告空間營利。」我們的觀點與 CMA 的這則留言相符。 |
| 不同各類型相關人員的實用性 | 做為賣方平台和需求端平台的廣告技術，比其他生態系統業者俱有明顯優勢。 | 我們對前幾季的作答內容維持不變： 「Google 致力於設計及導入 Privacy Sandbox 提案，不會因自己偏好 Google 自身業務而扭曲競爭情形，並將影響數位廣告及發布商和廣告客戶對各規模的影響力納入考量。我們會繼續與 CMA 密切合作，確保我們所做的努力符合這些承諾。隨著 Privacy Sandbox 的進展，我們要評估一項重要問題，就是新技術對不同類型相關人員的成效。對此，意見回饋至關重要，尤其是具體且可做為行動依據的意見回饋，有助於我們進一步改善技術設計。我們與 CMA 合作制定量化測試做法，並支持 CMA 推動實驗設計，除了為市場參與者提供更多資訊，也讓大家有機會評論建議的做法。」 |
| 子系主題 | 如果主題選擇條件是瀏覽器造訪頻率，區隔劃分是否會導致子系主題永遠上升？ | Chrome 正在評估其他排名方法，並探索其他可改善排名的信號。我們會在預定課程中向大環境說明調整後的計畫。 |
| 機密程度 | Topics API 的目標應是確保從 Topics API 取得或衍生的使用者資訊，比目前追蹤方式可以取得的使用者資訊更低。 | 我們認為 Topics API 的隱私性遠高於現有技術、大幅限制重新識別使用者身分，並用於排除敏感主題。我們瞭解，主題可以與第一方資料建立關聯，也可以結合第一方資料來建立敏感類別，但我們認為 Topics API 是邁向使用者隱私的一大步，因此我們會持續改善 API。 |
| 分類結構 | 在主題分類中加入 ID、版本管理和其他中繼資料結構 | 目前在 API 回應中，我們加入了分類 ID。在邁向長期管理的過程中，建議您查看 Topics 物件，並視需要加入其他有關版本管理的中繼資料。 |
| 發布商控制選項 | 發布商應該指出其網站應該歸類的 Topics。 | 網站分類錯誤可能導致 Topics 信號的整體信號略微下降，但與任何其他網站相比，分類錯誤的網站也不會再加以影響，也不會對該網站造成任何影響。這是因為網站的競價過程中一定會顯示網站的相關背景資訊，因此即使分類錯誤，系統還是會提供與正確主題類似的資訊。歡迎在這裡針對這個主題提供意見。 如果允許發布商控管分類，也有風險。網站可能刻意將網站分類錯誤、減少所有內容的實用性，或是為較不常見主題將敏感意義編碼，進而危害使用者隱私。 |
| Chrome 擴充功能 | 允許 Chrome 擴充功能管理及篩選 Topics (與目前的 Cookie 管理擴充功能類似) | 如同 GitHub 上的討論，應該已經有可能發生，但我們歡迎生態系統提供其他意見回饋。 |
| 轉換至正式發布版 | 從來源試用轉換至正式發布版時，Topics API 會有任何影響嗎？ | 從來源試用轉換至正式發布版的使用者不會遺失任何資料。 |
| 隱私權 | 主機名稱可能包含 Topics API 可能顯示的私人資訊 | 為確保隱私，我們採取了許多因應措施，詳情請參閱這篇文章。 |
| 詐欺與濫用 | 如何防止造訪詐欺行為而操控 Topics | 如要瞭解因應措施，請參閱這篇文章。 |
| 主題分類器 | 網站可以要求變更 Topics 分類嗎？ | 我們想瞭解 YouTube 生態系統對於這個主題有興趣，也歡迎你在這裡提供寶貴意見。 |
| 主題提供者網站 | 將代管許多主題內容的特定網站指定為「特殊主題提供者網站」，並依照網頁提供的標記訓練分類器。 | 我們會在這裡討論提案，歡迎提供其他意見回饋。 |
Protected Audience API (舊稱「FLEDGE」)
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 流量塑造 | SSP 驅動篩選作業對效能的影響，將每秒查詢次數 (QPS) 負載最佳化 | 我們已花了許多時間思考流量型態，現在也建議賣方平台充分利用快取功能。 |
| 正在測試音量 | 賣方平台和需求端平台難以獲得大量流量，因此想要測試 Protected Audience。 | 我們持續與賣方平台和需求端平台合作夥伴合作，採用並測試 Protected Audiences。產品市場已進入正式發布階段，我們確信，啟用私下競價的流量中，合作夥伴較容易進行測試。 |
| 複雜度 | 導入 Protected Audience 解決方案需要投入大量心力和成本。 | 我們瞭解 Privacy Sandbox 等新技術難以採用。Privacy Sandbox 團隊與各方相關人員密切合作，藉此教育及提供支援，並持續評估其他加速狀況，確保他們都能順利採用生態系統。 |
| 受信任的執行環境 | 支援非公有雲環境中信任的執行環境 (TEE) | 我們正在研究可能支援雲端式解決方案以外的選項，但由於地端部署 TEE 的運作限制需要耗費大量時間的評估來評估 Privacy Sandbox，因此目前尚無法支援地端部署 TEE。由於 Privacy Sandbox 安全性需求，以及地端部署部署項目面臨的重大挑戰，我們認為持續擴大雲端式部署規模 (例如同時支援 GCP 和 AWS) 才能充分提高這個生態系統的效益。不過，我們也歡迎你提出更多意見回饋，說明為何你必須這麼做。 |
| 成本結構 | 相較於用戶端模型，出價和競價服務提案會增加廣告技術的費用和複雜度。 | 我們目前正在開發一份指南，說明在「出價和競價」伺服器中支援出價和競價工作流程的費用，且該指南將與廣告技術使用情形相關，達成我們設計的目標之一。 |
| K-Anon 時間表 | 何時能對「renderUrl」強制執行預定的 k-anonymity 限制？ | 我們正在擬定說明，確保很快就會發布。 |
| runAdAuction 限制 | Chrome 可以限制 runAdAuction 只能透過頁面頂端呼叫嗎？ |
雖然我們的設計已全面支援可從頂端呼叫 runAdAuction，但我們認為限制使用者只能從頂層網域呼叫，更有利於發布商使用。許多廣告生態系統都明確指出 Privacy Sandbox 需要盡量減輕發布商和廣告客戶的負擔。這些意見回饋符合網站開發的一般原則，可讓網站擁有者使用第三方工具經營網站。Privacy Sandbox 的目標一直是鼓勵發布商建立健全的生態系統，而所有發布商和廣告技術都不需要說明發布商和廣告技術的運作方式。 我們期望發布商能選擇在自家網站上呼叫 runAdAuction 的方式和對象，進而彈性找出最符合自家規定的發布商。 |
| 導入支援 | Chrome 是否可以建立或參與導入多重賣方競價的開放原始碼計畫？ | Privacy Sandbox 旨在開發無需仰賴第三方 Cookie 或其他跨網站 ID 的隱私權保護技術。我們想要鼓勵廣告技術生態系統健全運作， 我們已在 GitHub 存放區中發布相關指南，說明 API 如何在 GitHub 存放區中運作，並希望與業界一起探索解決方案。 我們的核心修訂版本是打造平台技術，而非規定使用這些技術的策略，因此不打算建立任何特定實作。我們的技術可協助廣告技術公司為消費者提供合適的隱私權防護機制。 |
| 多重賣方競價 | Chrome 是否會強制與元件競價分享「內容相關」勝出者？ | Protected Audience API 旨在讓各方發起多重賣方競價，將資訊傳送至元件競價 (注意：僅在發起競價前)。 然而，無論如何，瀏覽器都無法判斷資訊是否來自情境內容，因此無法強制封鎖或要求特定資訊。 |
| 使用者同意聲明追蹤偏好設定 | 廣告技術詢問資料保護主管機關如何正確導入使用者同意聲明追蹤功能 | 我們的回應包含我們在第 1 季的說法： 「針對特定廣告，相關廣告技術是最適合用來控管顯示廣告素材或選取方式的一方。」 我們在 5 月 WICG Protected Audience Meeting 期間討論了幾個與這個問題相關的情境，也歡迎針對這個問題提出其他意見回饋和討論。 |
| 自訂目標對象 | Protected Audience API 是否支援建立自訂目標對象的相關賣方平台？ | Protected Audience API 可讓賣方平台和其他廣告技術供應商擁有及管理自訂目標對象。關於賣方平台如何在開發階段與 PA API 整合，未來將開放賣方平台和其他廣告技術供應商用於整合相關工作，提供進一步指引。 |
| 格式 | Protected Audience API 是否支援影片？ | 影片廣告可透過下列其中一種方式放送：VAST XML 或 HTML (最後可能會將 VAST XML 載入影片播放器的串流外廣告)。買方可以透過 RenderURL 傳回這兩種格式。為支援 Attribution Reporting API，VAST 規格最近已更新。放送影片廣告的網站必須準備透過 Protected Audience API 放送廣告的方式。這表示要確保刊登位置代碼能將網址從 Protected Audience iframe 傳送至影片播放器。針對 Fenced Frames，我們會盡力在符合使用圍欄框架規定前 (2026 年之內) 解決影片需求。 |
| 使用速度 | 使用速度用途如何與 Protected Audience API 搭配運作？ | 感謝你提供寶貴的意見回饋。我們期望看到更多這類請求，以及更多由更多賣方平台合作夥伴提供詳細資料的案例，因為這主要是目前發生 DSP 的疑慮。 |
| 更新頻率 | dailyUpdate 的來電頻率 (每天每個興趣群組最多 1 次) 可能不足以用於特定用途，例如更新產品資訊。 |
感謝你提供寶貴的意見回饋。廣告技術還可採用其他解決方案，讓廣告技術採用以不同頻率 (例如關鍵字/影音查詢) 更新的頻率重新整理的信號。 |
| 廣告品質控制選項 | 發布商如何導入廣告品質控制選項？ | 目前 Protected Audience API 提供功能，可讓發布商告知賣方平台，說明其可在競價設定中建立的特定控制項 (即根據廣告相關標籤的拒絕清單)。歡迎針對生態系統可能要求的其他功能提供意見。 |
| 偵錯 | forDebuggingOnly 功能何時會移除？ |
我們計劃因第三方 Cookie 淘汰而造成損失事件 forDebuggingOnly。我們計劃提前在 2026 年停用 forDebuggingOnly 的勝利活動。 |
| 跨裝置興趣群組 | 建議針對通過驗證的使用者代理程式啟用跨裝置興趣群組 | 我們正在評估這項提案，但跨裝置指定功能明確層面對隱私權構成了重大疑慮，如這個 GitHub 問題所述。 |
| (同樣列於第 1 季報表中) 動態再行銷 | 第三方 Cookie 淘汰後，Protected Audience API 仍可進行動態再行銷嗎？ | 我們認為這種用途可以透過 Protected Audience，詳情請參閱這篇文章。 |
| 點擊相關資料 | 在 browserSignals. 中加入點擊相關資料 |
目前，我們希望能釐清點擊發生的時間，釐清點擊事件發生的時間，以利初步調查。 |
| (同樣在 2022 年第 4 季一併報告) Protected Audience 中的使用者定義函式 | Protected Audience API 如何支援使用者定義函式 (UDF)？使用者可運用這些程式碼來擴充 API 的功能。 | 提出這個問題的廣告技術也提到，他們仍在評估自己能如何運用 UDF，因此目前還沒有可採取行動的相關意見回饋，而不是等到正式發布前。 |
| 幣別 | 貨幣金額不應以浮點值表示。 | 我們解決了這個問題，詳情請參閱這篇文章。 |
| 非 DSP 廣告選擇功能 | 廣告伺服器在 Protect Audience API 競價中扮演什麼角色？ | 我們瞭解廣告伺服器要求繼續提供出價後的廣告選擇 / 動態廣告素材最佳化服務。我們目前正在評估目前 Protected Audience API 與這些要求之間存在的詳細差距分析。 |
| GenerateBid | 支援 Google Ads 提案，從 generateBid 的每個廣告興趣群組傳回多個候選廣告，並在「scoreAd」中為這些候選廣告評分。 |
目前正在評估這個項目。歡迎點選這個連結，提供其他意見。 |
| 競價訂單 | 是否需要最後一個執行 Protected Audience API 競價，系統才能根據所有其他競價的結果提供意見回饋？ | 自動執行 Protected Audience API 不需符合任何技術需求。 |
| 非使用者啟動的導覽 | 公開非使用者啟動的導覽 | 我們正在審查這項要求，並在這裡討論 ，也歡迎提供其他意見回饋。 |
| 快取 | 如果使用者狀態改變，賣方平台不應透過快取建立特定 DSP 的 perBuyerSignals。 | 我們瞭解快取功能不適用於每個用途，因此無法處理個別買方信號，目前正在評估其他選項。我們也歡迎生態系統提供任何意見回饋，協助我們瞭解快取功能是否適合其用途。 |
| 歸因報表和 Protected Audience | Attribution Reporting API 和 Protected Audience API 如何搭配運作？ | Protected Audience API 目前適用於 Attribution Reporting API 模式 (事件層級和摘要報表) 的整合功能。我們曾於 6 月 1 日分享更多改良後的 Protected Audience API 和 Attribution Reporting 整合功能的相關資訊。詳情請參閱這個網頁。 |
| 伺服器端點 | 最終設計中的伺服器端點會是受信任的匯總伺服器嗎？ | 伺服器端點是由廣告技術維護的端點，與用於處理所收集和轉換報表的受信任匯總伺服器無關。目前，我們尚未針對報表端點規劃任何變更。目前的設計旨在確保可匯總報表 (使用已加密的酬載) 不會外洩跨網站資料，因此不需要信任的端點。另外還有一個難題是，不同廣告技術人員可能會有不同的所需的批次處理策略。歡迎點選這個連結，提供其他意見。 |
| WebIDL | 目前的 Protected Audience API 規格與 WebIDL 規格不相容。 | 我們正在評估這份意見回饋，並在這裡討論問題。 |
| 同意聲明管理 | 如何在 Protected Audience API 中處理同意聲明信號傳遞作業？ | 內容比對資訊不在 Protected Audience API 的範圍內。我們正在討論這個問題，歡迎您提供其他意見。 |
| 以帳戶為基礎的行銷 | 可以採用以帳戶為主的行銷應用實例嗎？ | Protected Audience API 支援各種以目標對象為依據的行銷用途。我們持續瞭解 Protected Audience API 如何最適合這個特定用途，也歡迎從大環境針對這個問題提出其他意見。 |
| 組件競價 | 組成元件競價的參與者得分為何？ | 元件競價不會直接為興趣群組評分，而是為需求端平台透過 generateBid 函式提交的廣告和出價評分。generateBid() 函式會為每個興趣群組執行，且需求端平台在執行 generateBid 時傳回下列內容：
return {
'ad': adObject,
'adCost': optionalAdCost,
'bid': bidValue,
'render': renderUrl,
'adComponents':
[adComponent1, adComponent2, ...],
'allowComponentAuction': false,
'modelingSignals': 123};
}
|
| 外部貢獻 | 要求支援透過鍵/值伺服器 GitHub 程式碼集的外部貢獻。 | 我們正在更新相關程序，以支援外部貢獻者對 GitHub 程式碼。 |
| 興趣群組規模 | IG 支援的金鑰數量上限是多少？ | 目前，一個 IG 的大小上限為 50 KB，並計入該 IG 的按鍵數。歡迎進一步討論大小上限。 |
| 批次處理 | 如何減少 K/V 伺服器呼叫次數？ | 您可以使用 HTTP Cache-Control 標頭來減少 K/V 呼叫次數。舉例來說，廣告素材可在各元件競價中快取，也可以快取至單一網頁上的各個廣告版位。 |
| 版本管控 | 支援多個版本的廣告技術程式碼 | 出價和競價服務將支援多個版本的廣告技術程式碼。在出價和競價 API 中，SelectAd 要求可以指定競價請求所使用的程式碼版本 (亦即用於出價 / 競價和製作報表)。 |
| 共用儲存空間 | 支援在出價和競價服務中寫入共用儲存空間。 | 出價和競價服務目前不支援共用儲存空間，但歡迎您提出更多意見，說明這類使用情境為何對大環境至關重要。 |
| 網頁至應用程式 | 支援在網頁之間分享興趣群組。 | 「網頁至應用程式」目前未在 Chrome 和 Android 平台部署的 Protected Audience API 範疇，但我們很想瞭解這個做法的重要性。 |
| K - 匿名性 | 如何處理 K-Anonymity 備用廣告 | 我們正在討論這個問題，也歡迎您提供意見。 |
評估數位廣告
Attribution Reporting (和其他 API)
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 替代瀏覽後轉換事件層級報表設定 | 針對替代瀏覽後轉換事件層級報表設定提供意見回饋 | 根據使用者的意見回饋，目前的事件層級設定並不理想，因此希望您能提供意見回饋，協助我們瞭解最適合的全域設定。我們很樂意針對這一點提供更多意見回饋，並認為彈性事件層級說明有助於解決這項問題。 |
| 彈性事件層級設定 | 彈性事件層級設定功能的狀態為何？ | 我們已分享有關彈性事件層級設定的說明文件。這項功能仍在提案階段，因此我們希望您提供更多意見，瞭解這項功能對整個大環境是否有幫助。 |
| 彈性事件層級設定 | 如何核對不同方的衝突報表？ | 大多數報表情況都是透過匯總報表解決，而彈性事件層級設定提案則是特別為事件層級報表提供彈性選擇，最常見的用途是最佳化用途。歡迎針對這個情境提供其他生態系統意見或意見回饋。 |
| 來源登錄 | 如果來源登錄作業在觸發條件登錄後會發生什麼情況？ | 目前，如果來源登錄作業是在觸發事件登錄後才進行，來源和觸發條件將無法相互歸因。這似乎是極端案例。我們歡迎針對這個問題提供其他意見，如果許多廣告技術都面臨到相同情況，將設法解決。 |
| 與多個廣告代理商合作 | 如果廣告客戶與多個廣告代理商合作，需求端平台如何使用 Attribution Reporting API？ | 此 API 支援重新導向，因此即使廣告客戶與多家廣告代理商合作，仍可使用。此外，為了改善隱私權，我們對重新導向功能也有一些限制。我們也針對廣告技術提出的特定情況，找出使用 Shared Storage API 的可能解決方法。歡迎您針對本情境提供其他任何意見，我們會繼續根據這些意見進行修正。 |
| 目的地限制 | 如果設有到達網頁限制，自動重新整理廣告用途可能會受到影響。 | 我們在 5 月 1 日的 WICG 會議中討論了這個問題，並希望收到意見回饋，說明合理的限制。我們在含有事件層級報表的說明歸因報表中新增了說明，指出瀏覽器可限制來源網站所代表的「目的地」eTLD+1 數量。(請參閱提取要求)。 |
| 歸因報表和 Protected Audience | Attribution Reporting API 和 Protected Audience API 如何搭配運作？ | Protected Audience API 目前適用於 Attribution Reporting API 模式 (事件層級和摘要報表) 的整合功能。我們曾於 6 月 1 日分享更多改良後的 Protected Audience API 和 Attribution Reporting 整合功能的相關資訊。詳情請參閱這個網頁。 |
| 彈性事件層級設定 | 您現在可以設定參數，分享雜訊模擬的最佳做法。 | 我們在 GitHub 上分享的程式碼可供所有人針對想測試的任何彈性事件層級設定，評估其資訊獲取和雜訊造成的影響。如果有人選擇使用程式碼進行測試，我們想瞭解你對這些程式碼的看法，也歡迎與我們分享。 |
| 跨應用程式和網站歸因評估 | 何時可以進行跨應用程式和網站歸因評估？ | 我們在 5 月 9 日宣布了透過 Attribution Reporting API 進行跨應用程式和網站歸因評估的實驗。雖然 Chrome 第 115 版預計推出關聯性和評估 API，但「跨應用程式和網站歸因評估」功能目前並未正式發布。 |
| 簡化轉換 | 如何針對 ARA 核對獨立成效評估解決方案？ | 如同目前的標準做法，廣告客戶會與第三方獨立評估服務供應商合作，去除重複的轉換報表。我們提供了一些資源，讓您瞭解如何在事件層級報表中刪除重複轉換。 |
| 歸因報表資料庫更新期間的資料遺失 | 如已公布更新歸因報表資料庫，Chrome 是否會遺失任何資料？ | 從 Chrome 穩定版 115 開始，我們將開始預設為部分使用者的 Chrome 使用者啟用 Relevance 和 Measurement API。我們會監控潛在問題，進而提高正式發布的程度。目標是在 2023 年第 3 季前，於數週內達到 100% 的可用性。與「關聯性和評估」來源試用結束的時間一致。自 7 月起，測試人員可以註冊使用這些 API 並正式發布。這會導致來源試用在來源試用與正式發布階段之間的推出重疊。來源試用權杖的有效期限為 9 月 19 日，但建議您在到期日前註冊 API，以便順暢地在來源試用期間進行轉換，而不中斷任何進行中的測試。 如這項公告所述，更新完成後，系統不會遷移從舊版 (M113 或更早的版本) 註冊的資料，因此資料可能會遺失。這類資料遺失不會顯示在偵錯報表中，而且我們會盡量避免資料在 114 到 115 間遺失。 |
| 帳單 | 使用歸因報表進行單次轉換費用帳單 | 如本文所述，由於事件層級和摘要報表加入了雜訊，因此 Attribution Reporting API 可能不適用於單次轉換費用帳單需求。我們鼓勵生態系統玩家在 GitHub 上透過 Attribution Reporting API 分享對各種計費模式的影響。 |
匯總服務
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 可匯總報表延遲變更 | 在收到生態系統意見回饋後，將「可匯總報表」延遲時間從 [10-60 分鐘] 變更為 [0-10 分鐘] 的提案正面反應 | 我們很高興看到這項提議的改變能更加成功，也鼓勵整個大環境繼續針對我們的提案提供意見。 |
| 地端部署解決方案 | 匯總服務可以部署在地端部署資料中心嗎？ | 我們正在研究可能支援雲端式解決方案以外的選項，但由於地端部署 TEE 的運作限制需要耗費大量時間的評估來評估 Privacy Sandbox，因此目前尚無法支援地端部署 TEE。由於 Privacy Sandbox 安全性需求，以及地端部署部署項目面臨的重大挑戰，我們認為持續擴大雲端式部署規模 (例如同時支援 GCP 和 AWS) 才能充分提高這個生態系統的效益。不過，我們也歡迎你提出更多意見回饋，說明為何你必須這麼做。 |
| 重新處理不同時間範圍的報表 | 可重新處理不同時間範圍的報表 | 我們聽說可以批次處理不同日期範圍的類似要求。其中一個提案是允許以廣告技術定義的標籤擴充共用 ID，以便將報表拆分成不同的批次。我們目前仍在初步評估這項程序，並隨著提案內容不斷更新，整個生態系統都會持續更新。 |
| 受信任執行環境的隱私權影響 | 對受信任執行環境影響隱私權的正面觀感 | 我們很高興收到生態系統對於各項提案的正面回應，也歡迎持續提供其他意見，協助我們持續改進及開發。 |
| 服務條款 | 接受匯總服務條款的期限為何？ | 雖然我們尚未指定接受條款及細則的期限，不過我們鼓勵生態系統公司盡快接受條款及細則，以免發生註冊延誤。我們建議相關公司如有任何問題，歡迎與我們聯絡。 |
| 金鑰探索 | 主要探索功能可讓測試人員查詢匯總報表，而不需要明確的主要組合清單，來處理跨聯播網歸因的摘要報表以改善成效和準確度。 | 我們目前正努力研究可能的解決方案與替代方案，並歡迎來自生態系統的意見回饋。 |
Private Aggregation API
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 報表來源 | 報表來源的定義為何？ | 報表來源一律是不公開匯總呼叫端的指令碼來源。 |
| 128 位元金鑰空間 | 128 位元索引鍵空間限制的清晰度 | 我們將進一步說明這項鍵空間限制，並解決網頁間不一致的問題。建議您使用雜湊策略，維持在這個鍵空間內。 |
| 每份報表的貢獻上限 | 目前每份報告的貢獻數量超過上限 (20 筆)。 | 與其提高貢獻數量，我們願意考慮分割報表，而非刪減上限。隨著這項提案的演進，我們會與大環境互動。 |
| 觸及報表 | 請求跨平台/跨裝置報表。觸及率是品牌宣傳廣告的基本指標。廣告客戶必須透過跨平台/跨裝置的預估值，取得觸及與頻率報表來分析廣告活動並分配支出。觸及模型會使用第三方 Cookie 做為評估第三方環境所顯示廣告的信號。因此，在第三方 Cookie 淘汰後，廣告技術已要求提供替代解決方案。 |
Privacy Sandbox 團隊正在探索相關功能，以便在第三方 Cookie 淘汰後支援跨網域觸及方法。 歡迎與生態系統分享其他意見回饋。 |
限制轉換追蹤
使用者代理程式縮減/使用者代理程式用戶端提示
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| (另於 2023 年第 1 季一併回報) 其他板型規格的提示 | 要求使用者代理程式用戶端提示 (UA-CH) 提供電視、VR 等額外板型規格 | 我們仍在擬定一些主要的設計決策 (是否提供單一值 (例如「電視」) 或板型規格功能清單)，但仍有興趣構思這個概念的原型。 |
| 隱私預算 | 隱私預算限制可能會導致 UA-CH 要求在傳送過多要求時出現不確定因素。 | 「隱私權預算」提案目前沒有更新，但我們承諾在第三方 Cookie 淘汰前，不會限制通用 Analytics (分析) 用戶端提示的要求。 |
| 網站相容性 | 網站使用 UA-CH 品牌來限制某些瀏覽器存取網站。 | 品牌清單的確存在有效，但其中之一是高度相容性。通用 Analytics (分析) 可以讓多個品牌共同解決這些問題。 |
IP 保護 (原稱 Gnatcatcher)
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 詐欺與濫用 | 公司如何運用「IP 保護」設定反詐欺措施？ | 我們瞭解反詐欺用途的重要性，以及這些用途可能受到的影響。我們預計今夏稍晚會發布更多有關反欺詐行為的詳細資訊。因此，我們正在徵求生態系統意見回饋，協助我們改進反詐欺相關用途。 |
| GeoIP | 進一步瞭解 GeoIP 的測試及部署時程 | Chrome 最近發布了新資訊，詳細說明我們的地理 IP 計畫。我們計劃在第 3 季發布更多部署時間表的相關資訊。我們預計在一開始對少數流量推出「IP 保護」，做為使用者選擇加入的功能。這是因為 Google 瞭解這項提案可能與公司進行一些重大調整，因此希望在這項功能推出前，讓生態系統有更多時間進行調整並提供意見回饋。 |
| 帳戶驗證 | 透過 Proxy 伺服器進行帳戶驗證是如何運作的？ | 我們預計在今夏稍晚發布更多帳戶驗證相關詳細資訊，但先前已經分享了一些初步考量事項。 |
跳轉追蹤因應措施
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 測試指南 | 瞭解如何測試跳轉追蹤因應措施 | 我們在 5 月發布了一篇 網誌文章，進一步說明如何測試跳轉追蹤因應措施。 |
| 說明文件 | 跳轉追蹤提案的重要性 | 目前的提案仍在開發階段，Chrome 將持續更新提案，為生態系統提供清楚的說明和相關資訊。我們正努力提供更多詳細資訊，也歡迎你提供其他意見回饋。 |
| Cookie 刪除 | 跳轉追蹤因應措施是否會刪除網域中的所有 Cookie？ | 跳轉追蹤緩解措施 (BTM) 會清除所有儲存空間和所有快取，詳情請參閱這篇文章。 |
| 規避跳轉追蹤因應措施 | 可能會在彈出式視窗或新分頁中執行重新導向作業，避免跳轉追蹤器分類。 | 我們目前仍在開發跳轉追蹤因應措施。目前為止，我們主要是以單一分頁重新導向技術為重心，不過我們計劃在日後努力改善彈出式視窗的流程。歡迎點選這個連結，提供其他意見。 |
隱私預算
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 指定鄰近目標 | 隱私預算可能會影響指定鄰近目標的用途。 | 我們已經收到針對此問題的意見，並希望進一步瞭解 YouTube 生態系統的潛在影響。 |
強化跨網站隱私界線
第一方集合
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| (如前幾季一併回報) 網域限制 | 要求增加相關網域數量 | Chrome 正在評估「關聯群組」的適當數值限制，以平衡特定用途的隱私和實用性。Chrome 從一開始就指出，關聯子集的最終數字尚未確定。 |
| 嵌入式應用實例 | 支援需要第一方集合、CHIP 和共用儲存空間的內嵌用途 | Chrome 已收到這個使用情境的意見回饋，我們的團隊正在調查中，並歡迎你提供其他意見回饋。 |
| 存放區管理 | 在 GitHub 存放區中，移除第一方集合的政策相關資訊，說明差異或遺漏 | Chrome 已收到這個使用情境的意見回饋。我們的團隊正在調查中，並歡迎提供其他意見回饋。 |
| 使用者教育 | Chrome 應提升使用者對第一方集合的認識和瞭解，進而提升採用率。 | Chrome 致力於向使用者說明第一方集合，並發布了一篇 說明中心文章 (透過 Chrome 使用者介面連結) 至此情況。此外，Chrome 也持續投入資源，希望能持續瞭解如何在適當的情境下讓使用者教學。 |
| 3PCD 貼文 | 在第三方 Cookie 淘汰後，第三方 Cookie 會繼續存在第一方 Cookie。 | 雖然 requestStorageAccess 和 requestStorageAccessFor 確實會讓第三方 Cookie 再次用於特定定義的用途，但現在這類 Cookie 需要網站主動叫用，而非預設為 Chrome 目前的第三方 Cookie 狀態。雖然在單一集合中叫用此作業不需要使用者核准，但使用者可以在「設定」中選擇不進行這項行為，防止這種情況發生。 如需更多資訊，請參閱說明中心文章 (可透過 Chrome UI 連結)。隨著每秒影格數達到 100%，我們預計持續擴充現有的開發人員指南。 |
| 提交第一方集合 | 重新命名必要 .well-known/first-party-set，加入 .json 副檔名。 |
我們做出這項調整，是為了確保我們能支援特定網站代管方案。 |
| IANA 註冊 | 「first_party_sets.JSON」應向 IANA 註冊 |
我們正在考慮提案，歡迎點選這個連結提供其他意見回饋。 |
Fenced Frames API
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 封鎖廣告 | 圍欄頁框可讓廣告攔截器更易於封鎖廣告。 | 擴充功能可以與圍欄頁框互動，方法與與 iframe 互動的方式類似。擴充功能將要前往的實際網址也一併顯示，因此擴充功能可以套用任何網址比對規則來封鎖，就像在 iframe 中一樣。只要無條件封鎖所有圍欄影格，可能會導致圍欄影格的非廣告用途受到影響。 |
Shared Storage API
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 擴大採用 | 共用儲存空間應是業界通用的標準，可在不同瀏覽器上使用。 | 歡迎提供意見。Chrome 將持續積極參與 W3C fora 計畫，推廣這項提案、收集意見回饋及提升採用率。 |
| 輸出閘道 | 共用儲存空間輸出閘道數量太少。 | 我們正在考量這些意見回饋，並歡迎其他生態系統的意見回饋，說明為何輸出門檻過大。 |
| 監管法規遵循 | 共用儲存空間如何處理資料保留政策等法規遵循法規？ | 共用儲存空間能讓您靈活實作及自訂邏輯，藉此控管任何儲存資料的生命週期和到期時間。廣告技術可根據寫入時間戳記更新或清除共用儲存空間資料。 |
| A/B 版本測試 | 如何執行 Shared Storage 和 Protected Audience API 的 A/B 測試？ | 我們正在針對這項問題發布其他指引，希望能在未來提供更多詳細資訊。 |
| 共用儲存空間限制 | 一旦達到共用儲存空間上限，會有什麼影響？ | 達到上限時，系統就不會再儲存輸入內容。 |
| 在同個網頁載入時進行多重存取權 | 如果多次在載入網頁時存取共用儲存空間，會發生什麼情況？ | 處理這種情況的最佳方式是透過 window.sharedStorage.append(key, value) 函式。請勿更新每則廣告的值，如果有多個廣告，可能會導致網址發生衝突。附加函式只會在現有函式的尾端加入新值。 |
| iframe 功能 | 在第三方 Cookie 淘汰後，共用儲存空間仍可支援特定的 iframe 功能嗎？ | 第三方 Cookie 淘汰後，iframe 中的本機儲存空間會依照頂層網站進行分區，但 iframe 本身不會遭到封鎖。iframe 本機儲存空間中的資料無法在多個頂層網站上複製，但仍可在 iframe 中使用。 |
方塊
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 分區限制 | 每個分區網站的 10 KiB 仍龐大，且希望降低 10 KiB。 | Firefox 已針對 CHIPS 表明 正向排名。如需 Webkit 支援，建議開發人員針對自己使用分區 Cookie 而非分區儲存空間的用途，直接在 這個 GitHub 問題中提供意見回饋。 |
| 經過驗證的嵌入 | 區塊設定會影響目前的單一登入 (SSO) 登入流程，因為不同的分區會影響已驗證的嵌入項目。 | 我們打算利用 Storage Access API (含使用者提示) 支援已驗證的嵌入用途，且最近也傳送了一個 意圖到原型。 |
| 生命週期政策 | 可能的生命週期政策是否適用於第一方 Cookie？ | 我們目前不打算對第一方 Cookie 設下生命週期限制。 |
FedCM
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| OAuth 授權支援 | 協調授權非設定檔 OAuth 範圍 | 我們正積極透過 W3C FedID CG 向 Web Identity 社群徵求意見，希望在第三方 Cookie 淘汰後，除了基本驗證以外，還需要哪些最佳方式支援授權。 |
| 支援 SAML | 達成 SAML 支援的要求 | 團隊在第三方 Cookie 淘汰後，也積極尋求研究和教育社群對於 SAML 支援需求 (以及 OpenID-connect 支援) 的意見。 |
打擊垃圾內容和詐欺
Private State Token API (和其他 API)
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 探索新信號 | 不少合作夥伴對於探索透過瀏覽器輔助的裝置完整性或使用者信任信號，表達出正向的感受。一般來說，這些專用信號足以持續偵測目前的詐欺情況，因此這類信號也須小心謹慎。 | 我們很期待一起探索反詐欺和網路安全社群中的新提案，也瞭解並認同他們的疑慮。正因如此，「打擊垃圾內容和詐欺」是 Privacy Sandbox 的核心工作流，因此我們持續優先投入資源來維護網路安全，在加強使用者隱私的同時，持續優先應投資維護網路安全性。 |
| 對 PST 的正面評價 | 有多家合作夥伴表示有意測試，或是將 PST 用於各種反詐欺或網路安全性用途。 | 我們很高興聽到支持並有意進一步探索運用 PST 的新解決方案。歡迎前往 Chrome 開發人員網站提供相關資源和程式碼範例，也歡迎你進一步提供意見。 |
| 詐欺與濫用 | ID 淘汰後，在第三方 Cookie 淘汰後進行廣告詐欺 / 偵測評估指南。 | 為此，我們導入了 Private State Tokens 等工具，以便復原第三方 Cookie 遺漏的部分信號 (用於反詐欺)，不過我們還推出了新的隱私權控制項。我們正積極投資新的反詐欺和反濫用提案，以保護 Privacy Sandbox 的其他異動功能。 |
| 核發來源資訊率的發卡機構 | 核發機構對來源資訊的比率足以識別不重複使用者。 | 我們更新了規格，以更清楚地說明可以透過私密狀態權杖傳達哪些使用者資料。根據設計，一次最多可使用六組公開金鑰，可代表特定使用者的「狀態」。這些金鑰組合只能每 60 天更新一次 (除非是必須使用緊急金鑰輪替的做法除外)，因此隨著時間過去，加入其他使用者資料的速度會變慢。以任何新的網路 API 來說，在實用性與新使用者資訊之間取得平衡。預估 PST 能在保護使用者隱私的前提下，達到適當平衡，同時實現受到第三方 Cookie 淘汰影響的關鍵反詐欺行為。 |
| 擷取整合 | fetch 整合方式複雜且非必要。 |
使用 fetch 有利於許多優缺點，我們想要在網路生態系統中進一步標準化，但我們相信要做出改變是更早，直到有清楚的標準。如果標準出現，我們也致力以負責任的方式協助網頁開發人員轉換至該標準。 |
| Storage Location | 私密狀態權杖金鑰設定應儲存在與 PrivacyPass 通訊協定相同的位置。 | 在來源試用期間進行測試時，開發人員表示他們偏好將金鑰儲存在一般網址，而不是儲存在 .well-known，PrivacyPass 中的金鑰承諾使用格式特別適合用於金鑰組允許隱含「公開中繼資料」值的版本。如果 PrivacyPass 變化版本最終將公開中繼資料標準化 (無論是 POPRF、部分 RSA 盲方法或鍵盤)，我們可能會改用日後的 PST 版本來支援這項功能。 |
| API 的標頭實作 | 關於 API 標頭實作的問題 | 隨著 API 的標準化，而且此 API 生態系統的使用率也逐漸成熟，我們希望能同時支援這個 API 的標準非標頭版本，並在使用率偏低時，最終淘汰標頭版本，或者有足夠的開發人員工具/支援與其他資料建立關聯的標準方法/支援。我們正在在這裡討論問題。 |
| 註冊 | 建立核發機構向瀏覽器供應商註冊是否實用？ | 我們更新了規格說明，藉此說明私人狀態權杖的發卡機構註冊程序。雖然採用自己的程序，但這類似於 Privacy Sandbox 工作的其餘註冊計畫。在此處，我們要求發卡機構公開聲明他們預計如何使用 PST，並確認接受保護使用者隱私的技術限制。 |