# Topics API 以使用者追蹤進行精準廣告投遞的替代方案，由瀏覽器透漏使用者的興趣偏好，讓相關廣告在使用者跨站追蹤手段失效後仍能投遞給使用者 * 每個使用者有自己興趣週期(epoch)。epoch的長度均為1週，但起始時間各不相同 * 瀏覽器內有個torch lite模型能歸納epoch內的興趣主題，並排出最高的前5名 * 瀏覽器會儲存最新3個epoch的結果，並接受外界呼叫詢問，但回傳結果不完整，有以下限制 * 每次取得興趣主題時，瀏覽器會從最新3個epoch中從前5名主題中抽1個出來回傳 * 每次抽取主題時，還有5%的機率是隨機亂抽的主題，作為雜訊 * 獲取使用興趣的流程分成觀察和取得兩個階段，被觀察到的主題才能被獲得 * 呼叫API的一方(caller)會先觀察到該使用者瀏覽了特定主題，caller的hostname和觀察到的主題會被瀏覽器記下。未來caller再次查詢興趣時，該興趣才會被API回傳 * 同一個Caller從不同網站上呼叫API時獲得的興趣組合是分別計算的，因此不會相同 在RTB的應用場景，caller應該是AdExchange，所以AdExchange是否有在夠多類型的網站埋碼來觀察使用者的不同興趣，將決定此API是否有用 ---- # Protected Audience API 投遞廣告給特定使用者的retargeting替代方案，當使用者瀏覽廣告方網站時，網站可以要求瀏覽器加入某個興趣群(interest group)，並在之後有廣告版面出現時，由瀏覽器主動向興趣群的擁有者發出廣告競標邀請 * 廣告方能設立專屬且獨一無二的興趣群 * 當使用者瀏覽了廣告方網站，網站方能要求瀏覽器加入廣告主設立的興趣群 * 瀏覽器會紀錄興趣群名稱、興趣群擁有者的hostname、key/value server URL和bidding code URL * 如果瀏覽器已經加入此興趣群，原本興趣群的資訊會被覆蓋更新(所以使用者追蹤沒戲了) * 當使用者稍後又到了媒體方網站，在頁面上有廣告版位的情況下，站方的aution code能呼叫`navigator.runAdAuction()`取得瀏覽器紀錄的興趣群和擁有者，並對他們發送競標邀請 * 瀏覽器從每個興趣群的bidding code URL取得並執行對應的bidding code，發送競標邀請給各買家，買家回應價格和素材，再由auction code決定得標廣告並渲染在fenced frame上 和過去gid remarketing相比，此手段的額外限制是廣告方必須先接觸過使用者，而不能單純藉由獲取使用者id來進行針對性廣告投遞 目前預設SSP、AdExchange或廣告方可以自由的透過iframe從第三方domain呼叫`joinAdInterestGroup()`，要求瀏覽器加入興趣群。但未來當各網站都更新了iframe permissions policies後，將會預設禁止第三方domain呼叫該功能 呼叫`joinAdInterestGroup()`的domain name必須和interest group owner, `biddingLogicURL`, `biddingWasmHelperURL`, `trustedBiddingSignalsURL`和 `updateURL`的domain name一致 ## Key/value service 廣告方和媒體方各自會有取得即時資料的需求，譬如廣告方需要即時計算剩餘預算，或媒體需要檢查廣告素材是否符合規範。因此兩方可以架設各自的key/value cloud server，在競標時取得所需的資訊，並即時更新回server。媒體方和廣告方的service URL分別是`trustedScoringSignalsUrl`以及`trustedBiddingSignalsUrl`。目前chrome不限制key/value service的環境，但未來必須轉移到符合trusted execution environment(TEE)規範的平台，目前上述轉移沒有預期時間表 ## 競標邏輯設定 在廣告方的興趣群設定檔和媒體方的競標設定檔中分別有欄位能寫入各自的第一方資料，某些欄位只有寫入方能存取，某些欄位能給對方存取。 興趣群設定檔的`userBiddingSignals`能儲存來自廣告方寫入的使用者個人化資訊，並在競標時使用。設定檔範例如下 ```javascript const interestGroup = { owner: 'https://example-buyer.com', name: 'running-shoes', userBiddingSignals: { favoriteColor: 'blue' // First-party data }, // ...other interest group settings }; navigator.joinAdInterestGroup(interestGroup, 3600); // the second parameter definds how long will this interestGroup alive // capped at 30 days ``` 媒體方同時也能在競標設定檔寫入第一方資料，並且開放部份資料給廣告方存取。`auctionSignals`內的資訊雙方都能存取; `sellerSignals`是只給媒體方的資訊; `perBuyerSignals`則是能只開放資訊給特定廣告方。設定檔範例如下 ```javascript= const auctionConfig = { seller: 'https://example-seller.com', auctionSignals: { favoriteColor: 'blue', // Both buyer and seller will receive this signal }, sellerSignals: { favoriteIceCreamFlavor: 'chocolate', // Only the seller will receive this signal }, perBuyerSignals: { 'https://example-buyer.com': { favoriteDrink: 'tea', // Only a specific buyer will receive this signal }, }, // The same pattern applies to the component auction componentAuctions: [{ seller: 'https://example-component-seller.com', auctionSignals: { ... }, sellerSignals: { ... }, perBuyerSignals { ... } }], // ...other auction settings }; navigator.runAdAuction(auctionConfig); ``` ---- # Attribution Reporting 在第三方cookie追蹤失效後替代原先手段進行廣告成效和歸因追蹤的成效回報系統。報告分成event-level report和summary report。前者紀錄廣告素材、banner位置和轉換事件，但沒有轉換的詳細內容(如購買的品項、花費的價格);後者能以campaig或商品為單位呈現廣告累計成效，但是喪失事件等級的資訊。為了保護隱私，兩種報告都不會有能識別使用者的資訊，而且會加入隨機雜訊，此外所有報告都會延後送回，而不會即時回傳 在廣告主的視角，這個report紀錄的是使用者從進站到轉換(購買/填單)的過程，但對於AdExchange和DSP來說，report紀錄的是使用者瀏覽媒體頁面到點擊廣告的過程，兩者有各自獨立的event id。因此除非找到方法媒合兩個id，不然此API對DSP來說，只是AdExchange追蹤點擊成效的手段，以及統計哪些廣告素材/媒體版面有較高轉換率的功能，不是非常有參考價值 ## Event-level report 當使用者進入頁面時，頁面的指令會指引瀏覽器紀錄此次歸因事件(attribution source event)的編號。接著在限定時間內，使用者在產生轉換事件時(點擊廣告或購買商品)，網站指令能呼叫瀏覽器紀錄下此次的轉換事件(attribution trigger event)，並加註在點擊時產生的歸因事件內，兩者結合後就是個完整的event-level report。此報告會由瀏覽器延時傳送給廣告方伺服器(在RTB場景是送交AdExchage) * 使用者進入頁面的方式會呈現在`source_type`欄位，`event`代表沒點擊進入，`nevigation`代表是點擊某個連結抵達此頁 * source event中的兩個欄位: `attributionsrc`是接收報告的URL，`destination`是轉換目標的URL * trigger event用`atrributionsrc`和`destination`的eTLD+1和source event進行媒合。若有超過一個source events吻合，會選擇最新和`priority`最高的source event * `nevigation`的source event能被最高3個trigger event歸因，trigger event的`trigger_data`可接受3 bit共8個類別的資訊來識別轉換事件。`event`只能接受1個trigger event歸因，接受1 bit的`tirgger_data` 具體來說，在渲染廣告banne或廣告連結的html加入`attributionsrc` argument，就能在觸發(炫染或點擊)時讓chrome以get形式呼叫`attributuinsrc`提供的伺服器URL，並接收伺服器回應的header所含之註冊此source event的資訊。接著使用者點擊轉換連結時，chrome也呼叫超連結的`attributionsrc`的URL呼叫伺服器，由伺服器提供資訊註冊trigger event。Source-trigger的媒合則由瀏覽器完成並延時回傳給`attributionsrc`URL的伺服器 ## Summary report 瀏覽器會週期性將廣告成效根據廣告方預先定義的規則加總，並加密傳送給廣告方的collection server，廣告方能將從各瀏覽器匯總的加密檔案傳送給aggregation server解密、加入雜訊後回報給廣告方。在加入雜訊後，報告解析度越高，訊噪比越低，此機制是用噪音比例來避免廣告方藉由無限調降顆粒度重新獲得使用者追蹤能力。 ---- # Shared Storage 在第三方cookie失效後提供跨domain資料統計的替代方案，但是只能取得聚合後的資料，而無法獲得原始資料 * 瀏覽器能接受以javascript和response header儲存資料 * 網站能夠以domain name向瀏覽器註冊儲存空間，並以key/value的形式儲存資料 * 若第三方將javascript埋在第一方網站，儲存資料時會儲存在第一方domain的空間 * 若第三方用iframe呼叫瀏覽器儲存資料，資料會儲存在第三方domain的空間 * 當要取得資料時，網站無法直接讀取存進瀏覽器的資訊，而是由瀏覽器將資料聚合完後另外傳送給伺服器 網站透過瀏覽器載入worklet並執行查詢，查詢條件和統計規則以class註冊進worklet，並在class中呼叫`privateAggregation.contributeToHistogram`，瀏覽器將結果傳送到預先指定的collection server。此查詢結果仍需要再透過aggregation server來解密才能取得。因為網站在當下無法直接透過瀏覽器取得查詢結果，所以此API無法用於廣告精準投遞。