อัปเดตล่าสุด
- เพิ่มการผสานรวมการรายงานการระบุแหล่งที่มากับกลุ่มเป้าหมายที่มีการป้องกัน
- เผยแพร่ไทม์ไลน์ของฟีเจอร์ Protected Audience
- FLEDGE ได้เปลี่ยนชื่อเป็น Protected Audience API
- เพิ่มข้อเสนอสำหรับการมอบสิทธิ์กลุ่มเป้าหมายที่กำหนดเองแล้ว
- นำข้อกำหนด k-anonymity สำหรับ URL อัปเดตรายวันออกแล้ว
Protected Audience อยู่ในเวอร์ชันเบต้าและพร้อมให้ทดสอบในอุปกรณ์สาธารณะ
กลุ่มเป้าหมายที่มีการป้องกันช่วยให้คุณทำสิ่งต่อไปนี้ได้
- จัดการกลุ่มเป้าหมายที่กำหนดเองตามการกระทำของผู้ใช้ก่อนหน้านี้
- เริ่มการประมูลในอุปกรณ์ด้วยผู้ขายรายเดียวหรือการรองรับสื่อกลาง Waterfall
- ใช้รายงานการแสดงผลหลังจากเลือกโฆษณา
อ่านคู่มือนักพัฒนาซอฟต์แวร์ Protected Audience เพื่อเริ่มต้นใช้งาน ขอขอบคุณสำหรับความคิดเห็นของคุณขณะที่เราพัฒนา Protected Audience อย่างต่อเนื่อง
ไทม์ไลน์
เราจะเปิดตัวฟีเจอร์ใหม่ในอีกไม่กี่เดือนข้างหน้า วันที่เผยแพร่ที่แน่นอนจะแตกต่างกันไปตามฟีเจอร์ และจะอัปเดตตารางนี้พร้อมด้วยลิงก์ไปยังเอกสารประกอบเมื่อพร้อมให้บริการ
| ฟีเจอร์ | มีให้บริการในตัวอย่างสำหรับนักพัฒนาซอฟต์แวร์ | พร้อมใช้งานในรุ่นเบต้า |
|---|---|---|
| การรายงานระดับเหตุการณ์ | ไตรมาส 1 ปี 2023 | ไตรมาส 3 ปี 2023 |
| สื่อกลางแบบ Waterfall | ไตรมาส 1 ปี 2023 | ไตรมาส 4 ปี 2023 |
| การกรองโฆษณาเพื่อการติดตั้งแอป | ไตรมาส 2 ปี 2023 | ไตรมาส 3 ปี 2023 |
| การกรองความถี่สูงสุด | ไตรมาส 2 ปี 2023 | ไตรมาส 3 ปี 2023 |
| ส่งโฆษณาตามบริบทไปยังเวิร์กโฟลว์การเลือกโฆษณาเพื่อทำการกรอง | ไตรมาส 2 ปี 2023 | ไตรมาส 3 ปี 2023 |
| การรายงานการโต้ตอบ | ไตรมาส 2 ปี 2023 | ไตรมาส 3 ปี 2023 |
| เข้าร่วมการมอบสิทธิ์กลุ่มเป้าหมายที่กำหนดเอง | ไตรมาส 3 ปี 2023 | ไตรมาส 4 ปี 2023 |
| การเรียกเก็บเงินที่ไม่ใช่ CPM | ไตรมาส 3 ปี 2023 | ไตรมาส 4 ปี 2023 |
| การผสานรวมบริการเสนอราคาและบริการประมูล | ไตรมาส 3 ปี 2023 | ไตรมาส 4 ปี 2023 |
| การรายงานการแก้ไขข้อบกพร่อง | ไตรมาส 3 ปี 2023 | ไตรมาส 4 ปี 2023 |
| การผสานรวมการรายงานการระบุแหล่งที่มา | ไม่มีข้อมูล | ไตรมาส 4 ปี 2023 |
| สื่อกลางในการเสนอราคาแบบเปิด | ไตรมาส 4 ปี 2023 | ไตรมาส 4 ปี 2023 |
| การจัดการสกุลเงิน | ไตรมาส 1 ปี 2024 | ไตรมาส 2 ปี 2024 |
| การผสานรวม K-anon | ไม่มีข้อมูล | ไตรมาส 2 ปี 2024 |
| การผสานรวมการรายงานสรุป | ไตรมาส 3 ปี 2024 | ไตรมาส 4 ปี 2024 |
ภาพรวม
ในการโฆษณาบนอุปกรณ์เคลื่อนที่ ผู้ลงโฆษณามักต้องแสดงโฆษณาต่อผู้ใช้ที่อาจสนใจโดยอิงจากวิธีที่ผู้ใช้มีส่วนร่วมกับแอปของผู้ลงโฆษณาก่อนหน้านี้ ตัวอย่างเช่น นักพัฒนาซอฟต์แวร์ของ SportingGoodsApp อาจต้องการโฆษณาต่อผู้ใช้ที่มีสินค้าเหลือในรถเข็นช็อปปิ้ง โดยแสดงโฆษณาเพื่อเตือนให้ผู้ใช้ทำการซื้อจนเสร็จสมบูรณ์ อุตสาหกรรมมักจะอธิบายแนวคิดทั่วไปนี้โดยใช้คำอย่างเช่น "รีมาร์เก็ตติ้ง" และ "การกำหนดกลุ่มเป้าหมายที่กำหนดเอง"
ปัจจุบัน Use Case เหล่านี้มักทำโดยการแชร์ข้อมูลบริบทเกี่ยวกับวิธีแสดงโฆษณา (เช่น ชื่อแอป) และข้อมูลส่วนตัว เช่น รายการกลุ่มเป้าหมายกับแพลตฟอร์มเทคโนโลยีโฆษณา การใช้ข้อมูลนี้ทำให้ผู้ลงโฆษณาสามารถเลือกโฆษณาที่เกี่ยวข้องในเซิร์ฟเวอร์ของตนได้
Protected Audience API ใน Android (ก่อนหน้านี้เรียกว่า FLEDGE) ครอบคลุม API ต่อไปนี้สำหรับแพลตฟอร์มเทคโนโลยีโฆษณาและผู้ลงโฆษณา เพื่อรองรับ Use Case ที่อิงตามการโต้ตอบที่พบบ่อยในลักษณะที่จำกัดการแชร์ตัวระบุทั้งในแอปและข้อมูลการโต้ตอบในแอปของผู้ใช้กับบุคคลที่สาม
- API กลุ่มเป้าหมายที่กำหนดเอง: ศูนย์กลางอยู่ที่นามธรรม "กลุ่มเป้าหมายที่กำหนดเอง" ซึ่งแสดงถึงกลุ่มเป้าหมายที่ผู้ลงโฆษณากำหนดซึ่งมีความตั้งใจร่วมกัน ข้อมูลกลุ่มเป้าหมายจะจัดเก็บอยู่ในอุปกรณ์และเชื่อมโยงกับโฆษณาที่ผู้สมัครที่เกี่ยวข้องสำหรับกลุ่มเป้าหมายและข้อมูลเมตาที่กำหนดเอง เช่น สัญญาณการเสนอราคา ข้อมูลนี้สามารถใช้เพื่อแจ้งราคาเสนอ การกรองโฆษณา และการแสดงผลของผู้ลงโฆษณา
- Ad Selection API: เป็นเฟรมเวิร์กที่จัดระเบียบเวิร์กโฟลว์ของแพลตฟอร์มเทคโนโลยีโฆษณาที่ใช้ประโยชน์จากสัญญาณในอุปกรณ์เพื่อกำหนดโฆษณาที่ "ชนะ" โดยพิจารณาจากโฆษณาที่เป็นคู่แข่งซึ่งจัดเก็บไว้ในเครื่อง และดำเนินการเพิ่มเติมกับโฆษณาที่แพลตฟอร์มเทคโนโลยีโฆษณาส่งกลับไปยังอุปกรณ์
การผสานรวมจะทำงานในระดับสูงดังนี้
SportingGoodsApp ต้องการเตือนให้ผู้ใช้ซื้อสินค้าที่เหลืออยู่ในรถเข็น หากผู้ใช้ไม่ทำการซื้อภายใน 2 วัน SportingGoodsApp ใช้ Custom Audience API เพื่อเพิ่มผู้ใช้ลงในรายการกลุ่มเป้าหมาย "ผลิตภัณฑ์ในรถเข็น" แพลตฟอร์มจะจัดการและจัดเก็บรายการกลุ่มเป้าหมายนี้ในอุปกรณ์ โดยจำกัดการแชร์กับบุคคลที่สาม SportingGoodsApp เป็นพาร์ทเนอร์กับแพลตฟอร์มเทคโนโลยีโฆษณาเพื่อแสดงโฆษณาให้แก่ผู้ใช้ในรายการกลุ่มเป้าหมาย แพลตฟอร์มเทคโนโลยีโฆษณาจะจัดการข้อมูลเมตาสำหรับรายการกลุ่มเป้าหมายและจัดเตรียมโฆษณาที่เป็นตัวเลือก ซึ่งพร้อมใช้งานสำหรับเวิร์กโฟลว์การเลือกโฆษณาเพื่อนำมาพิจารณา คุณสามารถกำหนดค่าแพลตฟอร์มให้ดึงข้อมูลโฆษณาตามกลุ่มเป้าหมายที่อัปเดตเป็นระยะในเบื้องหลัง ซึ่งจะช่วยให้รายการโฆษณาของผู้สมัครรับเลือกตั้งตามกลุ่มเป้าหมายมีความสดใหม่และไม่สัมพันธ์กับคำขอที่ส่งไปยังเซิร์ฟเวอร์โฆษณาบุคคลที่สามในระหว่างที่มีโอกาสแสดงโฆษณา (เช่น คำขอโฆษณาตามบริบท)
เมื่อผู้ใช้เล่น FrisbeeGame ในอุปกรณ์เดียวกัน อาจเห็นโฆษณาช่วยเตือนให้ซื้อสินค้าที่เหลือในรถเข็นช็อปปิ้งของ SportingGoodsApp ให้เสร็จสมบูรณ์ ซึ่งทำได้ด้วย FrisbeeGame (ที่มี SDK โฆษณาที่ผสานรวม) ให้เรียกใช้ Ad Selection API เพื่อเลือกโฆษณาที่มีประสิทธิภาพสูงสุดแก่ผู้ใช้โดยอิงตามรายการกลุ่มเป้าหมายที่ผู้ใช้อาจเป็นส่วนหนึ่งของ (ในตัวอย่างนี้คือกลุ่มเป้าหมายที่กำหนดเอง "ผลิตภัณฑ์ในรถเข็น" ที่สร้างโดย SportingGoodsApp) คุณตั้งค่าเวิร์กโฟลว์การเลือกโฆษณาให้พิจารณาโฆษณาที่ดึงมาจากเซิร์ฟเวอร์ของแพลตฟอร์มเทคโนโลยีโฆษณาได้ นอกเหนือจากโฆษณาในอุปกรณ์ที่เชื่อมโยงกับกลุ่มเป้าหมายที่กำหนดเอง ตลอดจนสัญญาณอื่นๆ ในอุปกรณ์ นอกจากนี้ แพลตฟอร์มเทคโนโลยีโฆษณาและ SDK โฆษณายังปรับแต่งเวิร์กโฟลว์ได้ด้วยตรรกะการเสนอราคาที่กำหนดเองและการให้คะแนน เพื่อให้บรรลุเป้าหมายการโฆษณาที่เหมาะสม วิธีนี้จะทำให้ความสนใจของผู้ใช้หรือข้อมูลการโต้ตอบกับแอปมีข้อมูลในการเลือกโฆษณา ในขณะเดียวกันก็จำกัดการแชร์ข้อมูลนี้กับบุคคลที่สาม
SDK ของแอปการแสดงโฆษณาหรือแพลตฟอร์มเทคโนโลยีโฆษณาแสดงโฆษณาที่เลือก
แพลตฟอร์มนี้ช่วยอำนวยความสะดวกในการรายงานการแสดงผลและผลการเลือกโฆษณา ความสามารถในการรายงานนี้เป็นส่วนเสริมของ Attribution Reporting API แพลตฟอร์มเทคโนโลยีโฆษณาอาจปรับแต่ง ตามความต้องการในการรายงานของตน
รับสิทธิ์เข้าถึง Protected Audience ใน Android API
แพลตฟอร์มเทคโนโลยีโฆษณาต้องลงทะเบียนเพื่อเข้าถึง Protected Audience API โปรดดูข้อมูลเพิ่มเติมที่ลงทะเบียนบัญชี Privacy Sandbox
การจัดการกลุ่มเป้าหมายที่กำหนดเอง
กลุ่มเป้าหมายที่กำหนดเอง
กลุ่มเป้าหมายที่กำหนดเองคือกลุ่มผู้ใช้ตามที่กำหนดโดยผู้ลงโฆษณาที่มีความตั้งใจหรือความสนใจร่วมกัน แอปหรือ SDK อาจใช้กลุ่มเป้าหมายที่กำหนดเองเพื่อระบุกลุ่มเป้าหมายที่เจาะจง เช่น ผู้ที่ "เหลือสินค้าในรถเข็นช็อปปิ้ง" หรือ "ผ่านด่านเริ่มต้น" ของเกม แพลตฟอร์มจะดูแลรักษาและจัดเก็บข้อมูลกลุ่มเป้าหมายไว้ในอุปกรณ์และไม่แสดงให้เห็นว่าผู้ใช้อยู่ในกลุ่มเป้าหมายที่กำหนดเองกลุ่มใด กลุ่มเป้าหมายที่กำหนดเองแตกต่างจากกลุ่มความสนใจของ Protected Audience ของ Chrome และจะแชร์ข้ามเว็บและแอปไม่ได้ วิธีนี้จะช่วยจำกัดการแชร์ข้อมูลผู้ใช้
แอปของผู้ลงโฆษณาหรือ SDK ที่ผสานรวมอาจjoinหรือออกจากกลุ่มเป้าหมายที่กำหนดเองตามตัวอย่างต่อไปนี้ เช่น การมีส่วนร่วมของผู้ใช้ในแอป
ข้อมูลเมตากลุ่มเป้าหมายที่กำหนดเอง
กลุ่มเป้าหมายที่กำหนดเองแต่ละรายการจะมีข้อมูลเมตาต่อไปนี้
- เจ้าของ: ชื่อแพ็กเกจของแอปเจ้าของ ซึ่งตั้งเป็นชื่อแพ็กเกจของแอปผู้โทรโดยปริยาย
- ผู้ซื้อ: เครือข่ายโฆษณาของผู้ซื้อที่จัดการโฆษณาสำหรับกลุ่มเป้าหมายที่กำหนดเองนี้ นอกจากนี้ ผู้ซื้อยังเป็นตัวแทนของฝ่ายที่อาจเข้าถึงกลุ่มเป้าหมายที่กำหนดเองและดึงข้อมูลโฆษณาที่เกี่ยวข้องได้อีกด้วย ผู้ซื้อได้รับการระบุตามรูปแบบ eTLD+1
- ชื่อ: ชื่อหรือตัวระบุที่กำหนดเองสำหรับกลุ่มเป้าหมายที่กำหนดเอง เช่น ผู้ใช้ที่มี "ผู้ละทิ้งรถเข็นช็อปปิ้งกลางคัน" แอตทริบิวต์นี้ใช้เป็นเกณฑ์การกำหนดเป้าหมายได้ เช่น เกณฑ์การกำหนดเป้าหมายหนึ่งในแคมเปญโฆษณาของผู้ลงโฆษณา หรือสตริงคำค้นหาใน URL เพื่อดึงข้อมูลโค้ดการเสนอราคา
- เวลาเปิดใช้งานและเวลาหมดอายุ: ช่องเหล่านี้จะกำหนดกรอบเวลาที่กลุ่มเป้าหมายที่กำหนดเองนี้จะมีผล แพลตฟอร์มจะใช้ข้อมูลนี้เพื่อถอนการเป็นสมาชิกจากกลุ่มเป้าหมายที่กำหนดเอง เวลาหมดอายุต้องไม่เกินกรอบเวลาสูงสุดเพื่อจำกัดอายุการใช้งานของกลุ่มเป้าหมายที่กำหนดเอง
- URL อัปเดตรายวัน: URL ที่แพลตฟอร์มใช้ในการดึงข้อมูลโฆษณาที่ผู้สมัครและข้อมูลเมตาอื่นๆ ที่ระบุไว้ในช่อง "สัญญาณการเสนอราคาของผู้ใช้" และ "สัญญาณการเสนอราคาที่เชื่อถือได้" เป็นประจำ ดูรายละเอียดเพิ่มเติมได้ที่ส่วนเกี่ยวกับวิธีดึงโฆษณาที่ผู้สมัครสำหรับกลุ่มเป้าหมายที่กำหนดเอง
- สัญญาณการเสนอราคาของผู้ใช้: สัญญาณเฉพาะแพลตฟอร์มเทคโนโลยีโฆษณาสำหรับการเสนอราคาใดก็ตามสําหรับโฆษณารีมาร์เก็ตติ้ง ตัวอย่างสัญญาณ ได้แก่ ตำแหน่งคร่าวๆ ของผู้ใช้ ภาษาที่ต้องการ และอื่นๆ
- ข้อมูลการเสนอราคาที่เชื่อถือได้: แพลตฟอร์มเทคโนโลยีโฆษณาอาศัยข้อมูลแบบเรียลไทม์ในการดึงข้อมูลและการให้คะแนนโฆษณา ตัวอย่างเช่น โฆษณาอาจใช้งบประมาณหมดและต้องหยุดแสดงทันที เทคโนโลยีโฆษณาจะกำหนดปลายทาง URL จากที่ที่ดึงข้อมูลแบบเรียลไทม์นี้ได้และชุดคีย์ที่จำเป็นต้องใช้การค้นหาแบบเรียลไทม์ เซิร์ฟเวอร์ที่จัดการคำขอนี้จะเป็นเซิร์ฟเวอร์ที่เชื่อถือได้ที่จัดการโดยแพลตฟอร์มเทคโนโลยีโฆษณา
- URL ตรรกะการเสนอราคา: URL ที่แพลตฟอร์มใช้ในการดึงโค้ดการเสนอราคาจากแพลตฟอร์มฝั่งดีมานด์ แพลตฟอร์มจะทําตามขั้นตอนนี้เมื่อเริ่มการประมูลเพื่อแสดงโฆษณา
- โฆษณา: รายการโฆษณาที่เป็นตัวเลือกสำหรับกลุ่มเป้าหมายที่กำหนดเอง ซึ่งรวมถึงข้อมูลเมตาโฆษณาเฉพาะแพลตฟอร์มเทคโนโลยีโฆษณาและ URL เพื่อแสดงโฆษณา เมื่อมีการเริ่มการประมูลสำหรับกลุ่มเป้าหมายที่กำหนดเอง เราจะพิจารณารายการข้อมูลเมตาของโฆษณานี้ ระบบจะรีเฟรชรายการโฆษณานี้โดยใช้ปลายทาง URL ที่อัปเดตรายวันเมื่อทำได้ เนื่องจากข้อจำกัดด้านทรัพยากรบนอุปกรณ์เคลื่อนที่ จึงมีขีดจำกัดจำนวนโฆษณาที่สามารถจัดเก็บไว้ในกลุ่มเป้าหมายที่กำหนดเอง
การมอบสิทธิ์กลุ่มเป้าหมายที่กำหนดเอง
การกำหนดและการกำหนดค่ากลุ่มเป้าหมายที่กำหนดเองแบบเดิมมักจะอาศัยเทคโนโลยีฝั่งเซิร์ฟเวอร์และการผสานรวมซึ่งขับเคลื่อนโดยเทคโนโลยีโฆษณาที่ร่วมมือกับเอเจนซี ลูกค้า และพาร์ทเนอร์ผู้ลงโฆษณา Protected Audience API จะเปิดใช้การกำหนดและการกำหนดค่ากลุ่มเป้าหมายที่กำหนดเอง พร้อมกับปกป้องความเป็นส่วนตัวของผู้ใช้ไปพร้อมกัน หากต้องการเข้าร่วมกลุ่มเป้าหมายที่กำหนดเอง เทคโนโลยีโฆษณาของผู้ซื้อที่ไม่มี SDK ในแอปจะต้องทำงานร่วมกับเทคโนโลยีโฆษณาที่มีการแสดงผลในอุปกรณ์ เช่น พาร์ทเนอร์การวัดผลอุปกรณ์เคลื่อนที่ (MMP) และแพลตฟอร์มฝั่งซัพพลาย (SSP) Protected Audience API มีเป้าหมายที่จะรองรับ SDK เหล่านี้ด้วยการนำเสนอโซลูชันที่ยืดหยุ่นสำหรับการจัดการกลุ่มเป้าหมายที่กำหนดเอง โดยให้ผู้เรียกใช้อุปกรณ์เรียกใช้การสร้างกลุ่มเป้าหมายที่กำหนดเองในนามของผู้ซื้อ กระบวนการนี้เรียกว่าการมอบสิทธิ์กลุ่มเป้าหมายที่กำหนดเอง กำหนดค่าการมอบสิทธิ์กลุ่มเป้าหมายที่กำหนดเองโดยทำตามขั้นตอนต่อไปนี้
เข้าร่วมกลุ่มเป้าหมายที่กําหนดเอง
การเข้าร่วมกลุ่มเป้าหมายที่กําหนดเองทําได้ 2 วิธี ดังนี้
joinCustomAudience()
แอปหรือ SDK สามารถขอเข้าร่วมกลุ่มเป้าหมายที่กำหนดเองโดยการเรียกใช้ joinCustomAudience() หลังจากสร้างออบเจ็กต์ CustomAudience ด้วยพารามิเตอร์ที่คาดไว้ ตัวอย่างข้อมูลโค้ดสำหรับอธิบายมีดังนี้
CustomAudience audience = new CustomAudience(
Buyer = "example-dsp.com",
Name = "running-shoes",
ActivationTime = now(),
ExpirationTime = ActivationTime.plus(30 days),
DailyUpdateURL = Uri.parse("https://..."),
UserBiddingSignals = new JSONObject("{...}"),
TrustedBiddingURL = Uri.parse("https://..."),
TrustedBiddingKeys = {'key1","key2", ...,"key n"},
BiddingLogicURL = Uri.parse("https://..."),
Ads = [new AdData(renderUrl = Uri.parse("https://..."),
metadata = new JSONObject("{...}"), ...];
// Invoke ad services API to join a custom audience.
joinCustomAudience(audience);
fetchAndJoinCustomAudience()
แอปหรือ SDK สามารถขอเข้าร่วมกลุ่มเป้าหมายที่กำหนดเองในนามของเทคโนโลยีโฆษณาที่ไม่มีการแสดงผลอยู่ในอุปกรณ์โดยการเรียกใช้ fetchAndJoinCustomAudience() ด้วยพารามิเตอร์ที่คาดไว้ ดังตัวอย่างต่อไปนี้
FetchAndJoinCustomAudienceRequest fetchRequest = new FetchAndJoinCustomAudienceRequest(
// Example: Optional verification token passed inside the fetch URL
FetchURI = Uri.parse("https://example-dsp.com/...?mytoken=arbitrary1234"),
// All the following parameters are optional
Name = "running-shoes",
ActivationTime = now(),
ExpirationTime = ActivationTime.plus(30 days),
UserBiddingSignals = new JSONObject("{...}")
);
fetchAndJoinCustomAudience(fetchRequest);
ปลายทาง URL ที่ผู้ซื้อเป็นเจ้าของตอบกลับด้วยออบเจ็กต์ JSON CustomAudience ในเนื้อหาการตอบกลับ ระบบจะไม่สนใจช่องผู้ซื้อและเจ้าของของกลุ่มเป้าหมายที่กำหนดเอง (และ API จะป้อนข้อความอัตโนมัติ) API ยังบังคับใช้ว่า URL อัปเดตรายวันจะตรงกับ eTLD+1 ของผู้ซื้อด้วย
{
"name": "running-shoes",
"activation_time": 1680603133000,
"expiration_time": 1680803133000,
"user_bidding_signals" : {"signal1": "value"},
"trusted_bidding_data": {
"trusted_bidding_uri": "https://example-dsp.com/.."
"trusted_bidding_keys": ["k1", "k2"],
},
"bidding_logic_uri": "https://example-dsp.com/...",
"daily_update_uri": "https://example-dsp.com/...",
"ads": [
{
"render_uri": "https://example-dsp.com/...",
"metadata": {},
"ad_filters": {
"frequency_cap": {
"win": [
{
"ad_counter_key": 1,
"max_count": 2,
"interval_in_seconds": 60
},
],
"view": [
{
"ad_counter_key": 2,
"max_count": 10,
"interval_in_seconds": 3600
},
]
},
"app_install": {
"package_names": [
"package.name.one",
"package.name.two", ...
]
}
}
},
...
]
}
fetchAndJoinCustomAudience() API ระบุข้อมูลประจำตัวของผู้ซื้อจาก eTLD+1 ของ fetchUri ระบบจะใช้ข้อมูลระบุตัวตนของผู้ซื้อ CustomAudience ในการดำเนินการลงทะเบียนและการตรวจสอบการให้สิทธิ์แอปแบบเดียวกับที่ joinCustomAudience() ดำเนินการ และจะแก้ไขโดยการตอบกลับการดึงข้อมูลไม่ได้ เจ้าของ CustomAudience คือชื่อแพ็กเกจของแอปพลิเคชันการโทร ไม่มีการตรวจสอบความถูกต้องอื่นๆ ของ
fetchUri นอกเหนือจากการตรวจสอบ eTLD+1 กล่าวอย่างเจาะจงคือ ไม่มีการตรวจสอบ k-anon fetchAndJoinCustomAudience() API จะส่งคำขอ HTTP GET ไปยัง fetchUri และคาดหวังออบเจ็กต์ JSON ที่แสดงถึงกลุ่มเป้าหมายที่กำหนดเอง ระบบจะนำข้อจำกัดที่ไม่บังคับและไม่บังคับเดียวกัน รวมถึงค่าเริ่มต้นสำหรับช่องออบเจ็กต์กลุ่มเป้าหมายที่กำหนดเองไปใช้กับการตอบกลับ ดูข้อมูลเกี่ยวกับข้อกำหนดปัจจุบันและข้อจำกัดในคู่มือนักพัฒนาซอฟต์แวร์
การตอบกลับข้อผิดพลาด HTTP จากผู้ซื้อจะทำให้ fetchAndJoinCustomAudience ไม่สำเร็จ โดยเฉพาะการตอบกลับสถานะ HTTP 429 (มีคำขอมากเกินไป) จะบล็อกคำขอจากแอปพลิเคชันปัจจุบันในระยะเวลาที่กำหนด นอกจากนี้ การเรียก API จะล้มเหลวหากการตอบกลับจากผู้ซื้อมีรูปแบบไม่ถูกต้อง ระบบจะรายงานความล้มเหลวไปยังผู้เรียกใช้ API ที่รับผิดชอบในการลองอีกครั้งเนื่องจากความล้มเหลวชั่วคราว (เช่น เซิร์ฟเวอร์ไม่ตอบสนอง) หรือการจัดการการทำงานล้มเหลวอย่างต่อเนื่อง (เช่น การตรวจสอบข้อมูลล้มเหลว หรือข้อผิดพลาดที่ไม่ใช่ชั่วคราวเกี่ยวกับการสื่อสารกับเซิร์ฟเวอร์)
ออบเจ็กต์ CustomAudienceFetchRequest ช่วยให้ผู้เรียกใช้ API กำหนดข้อมูลบางอย่างสำหรับกลุ่มเป้าหมายที่กำหนดเองได้โดยใช้พร็อพเพอร์ตี้ที่ไม่บังคับที่แสดงในตัวอย่างด้านบน หากมีการตั้งค่าไว้ในคำขอ ค่าเหล่านี้จะไม่สามารถเขียนทับโดยการตอบกลับจากผู้ซื้อที่แพลตฟอร์มได้รับ เนื่องจาก Protected Audience API จะไม่สนใจช่องในการตอบกลับ หากไม่ได้ตั้งค่าไว้ในคำขอ จะต้องตั้งค่าในการตอบสนองด้วย เนื่องจากต้องระบุช่องเหล่านี้เพื่อสร้างกลุ่มเป้าหมายที่กำหนดเอง การแสดง JSON ของเนื้อหาของ CustomAudience ตามที่ตัวเรียกใช้ API กำหนดบางส่วนจะรวมอยู่ในคำขอ GET ที่ส่งไปยัง fetchUri ในส่วนหัวพิเศษ X-CUSTOM-AUDIENCE-DATA ขนาดของข้อมูลรูปแบบต่อเนื่องที่ระบุสำหรับกลุ่มเป้าหมายที่กำหนดเองจะจำกัดอยู่ที่ 8 KB หากขนาดเกินขีดจำกัด การเรียก API fetchAndJoinCustomAudience จะไม่สำเร็จ
หากไม่มีการตรวจสอบ K-Anon จะทำให้คุณใช้ fetchUri สำหรับการยืนยันผู้ซื้อ รวมถึงเปิดใช้การแชร์ข้อมูลระหว่างผู้ซื้อกับ SDK ได้ ผู้ซื้อจะแสดงโทเค็นสำหรับยืนยันเพื่อช่วยในการยืนยันกลุ่มเป้าหมายที่กำหนดเองได้ SDK ในอุปกรณ์ควรรวมโทเค็นนี้ใน fetchUri เพื่อให้ปลายทางที่ผู้ซื้อโฮสต์สามารถดึงเนื้อหาของกลุ่มเป้าหมายที่กำหนดเอง และใช้โทเค็นการยืนยันเพื่อยืนยันว่าการดำเนินการ fetchAndJoinCustomAudience() สอดคล้องกับผู้ซื้อและมาจากพาร์ทเนอร์ในอุปกรณ์ที่เชื่อถือได้ หากต้องการแชร์ข้อมูล ผู้ซื้อสามารถตกลงกับผู้โทรในอุปกรณ์ว่าข้อมูลบางอย่างที่จะใช้ในการสร้างกลุ่มเป้าหมายที่กำหนดเองจะได้รับการเพิ่มเป็นพารามิเตอร์การค้นหาลงใน fetchUri ซึ่งจะช่วยให้ผู้ซื้อตรวจสอบการเรียกและดูว่ามีการใช้โทเค็นการตรวจสอบความถูกต้องโดยเทคโนโลยีโฆษณาที่เป็นอันตรายหรือไม่ในการสร้างกลุ่มเป้าหมายที่กำหนดเองที่แตกต่างกันหลายกลุ่ม
หมายเหตุเกี่ยวกับการกำหนดและพื้นที่เก็บข้อมูลของโทเค็นการยืนยัน
Protected Audience API จะไม่ใช้โทเค็นการยืนยันเพื่อวัตถุประสงค์ใดๆ และจะใช้หรือไม่ใช้ก็ได้
- ผู้ซื้ออาจใช้โทเค็นการยืนยันเพื่อยืนยันว่าผู้ชมที่กำลังสร้างนั้นดำเนินการในนามของผู้ซื้อ
- ข้อเสนอ Protected Audience API ไม่ได้ระบุทั้งรูปแบบสำหรับโทเค็นการยืนยันและวิธีที่ผู้ซื้อโอนโทเค็นการยืนยันไปยังผู้โทร เช่น โทเค็นการยืนยันอาจโหลดไว้ล่วงหน้าใน SDK หรือแบ็กเอนด์ของเจ้าของ หรือ SDK ของเจ้าของจะดึงข้อมูลแบบเรียลไทม์จากเซิร์ฟเวอร์ของผู้ซื้อก็ได้
ออกจากกลุ่มเป้าหมายที่กำหนดเอง
เจ้าของกลุ่มเป้าหมายที่กําหนดเองอาจเลือกที่จะออกจากการตั้งค่าโดยการโทรไปยัง leaveCustomAudience() ดังที่แสดงในข้อมูลโค้ดสำหรับภาพประกอบด้านล่าง
// Invoke ad services API to leave a custom audience.
leaveCustomAudience(buyer, name);
กลุ่มเป้าหมายที่กำหนดเองจะหมดอายุและถูกนำออกจาก Store ในอุปกรณ์หลังจากระยะเวลาที่กำหนดไว้ล่วงหน้า เพื่อช่วยประหยัดการใช้พื้นที่เก็บข้อมูลและทรัพยากรอื่นๆ ในอุปกรณ์ ระบบจะพิจารณาค่าเริ่มต้น โดยเจ้าของจะลบล้างค่าเริ่มต้นนี้ได้
การควบคุมของผู้ใช้
- ข้อเสนอนี้มีจุดประสงค์เพื่อให้ผู้ใช้เห็นรายการแอปที่ติดตั้ง ซึ่งสร้างกลุ่มเป้าหมายที่กำหนดเองอย่างน้อย 1 กลุ่ม
- ผู้ใช้สามารถนำแอปออกจากรายการนี้ได้ การนำออกจะล้างกลุ่มเป้าหมายที่กำหนดเองทั้งหมดที่เชื่อมโยงกับแอปและป้องกันไม่ให้แอปเข้าร่วมกลุ่มเป้าหมายที่กำหนดเองใหม่
- ผู้ใช้จะรีเซ็ต Protected Audience API ทั้งหมดได้ ในกรณีนี้ ระบบจะล้างกลุ่มเป้าหมายที่กำหนดเองที่มีอยู่ทั้งหมดในอุปกรณ์
- ผู้ใช้สามารถเลือกไม่ใช้ Privacy Sandbox โดยสมบูรณ์ใน Android ซึ่งรวมถึง Protected Audience API หากผู้ใช้เลือกไม่ใช้ Privacy Sandbox แล้ว Protected Audience API จะล้มเหลวโดยไม่มีการแจ้งเตือน
การออกแบบความสามารถนี้ยังอยู่ระหว่างการพัฒนา และรายละเอียดจะรวมอยู่ในการอัปเดตในภายหลัง
สิทธิ์และการควบคุมแอป
ข้อเสนอนี้มีวัตถุประสงค์ที่จะให้แอปควบคุมกลุ่มเป้าหมายที่กำหนดเอง ดังนี้
- แอปจะจัดการการเชื่อมโยงของตนกับกลุ่มเป้าหมายที่กำหนดเองได้
- แอปสามารถให้สิทธิ์แพลตฟอร์มเทคโนโลยีโฆษณาบุคคลที่สามเพื่อจัดการกลุ่มเป้าหมายที่กำหนดเองในนามของแอปได้
การออกแบบความสามารถนี้ยังอยู่ระหว่างการพัฒนา และรายละเอียดจะรวมอยู่ในการอัปเดตในภายหลัง
การควบคุมแพลตฟอร์มเทคโนโลยีโฆษณา
ข้อเสนอนี้ระบุวิธีที่เทคโนโลยีโฆษณาจะควบคุมกลุ่มเป้าหมายที่กำหนดเอง
- เทคโนโลยีโฆษณาลงทะเบียนกับ Privacy Sandbox และให้โดเมน eTLD+1 ที่ตรงกับ URL ทั้งหมดสำหรับผู้ชมที่กำหนดเอง
- เทคโนโลยีโฆษณาเป็นพาร์ทเนอร์กับแอปหรือ SDK เพื่อมอบโทเค็นการยืนยันที่ใช้ในการยืนยันการสร้างกลุ่มเป้าหมายที่กำหนดเองได้ เมื่อมอบสิทธิ์นี้แก่พาร์ทเนอร์แล้ว คุณจะกำหนดค่าการสร้างกลุ่มเป้าหมายที่กำหนดเองเพื่อให้เทคโนโลยีโฆษณาต้องรับทราบได้
- เทคโนโลยีโฆษณาเลือกที่จะปิดใช้งานการเรียก
joinCustomAudienceในนามของตนได้ และอนุญาตเฉพาะfetchAndJoinCustomAudienceAPI เพื่อเปิดใช้กลุ่มเป้าหมายที่กำหนดเองสำหรับการโทรทั้งหมด คุณจะอัปเดตการควบคุมได้ในระหว่างการลงทะเบียน Privacy Sandbox โปรดทราบว่าการควบคุมจะอนุญาตเทคโนโลยีโฆษณาทุกประเภทหรือไม่อนุญาตให้ใช้เลย เนื่องจากข้อจำกัดของแพลตฟอร์ม สิทธิ์การมอบอำนาจจะเป็นสิทธิ์แบบต่อเทคโนโลยีโฆษณาไม่ได้
การตอบกลับโฆษณาที่มีตัวเลือกและข้อมูลเมตา
โฆษณาและข้อมูลเมตาของผู้สมัครที่แสดงจากแพลตฟอร์มฝั่งซื้อควรมีช่องต่อไปนี้
- ข้อมูลเมตา: ข้อมูลเมตาโฆษณาเฉพาะสำหรับเทคโนโลยีโฆษณาฝั่งผู้ซื้อ ตัวอย่างเช่น ซึ่งอาจรวมถึงข้อมูลเกี่ยวกับแคมเปญโฆษณา และเกณฑ์การกำหนดเป้าหมาย เช่น สถานที่ตั้งและภาษา
- URL แสดงผล: ปลายทางสำหรับแสดงครีเอทีฟโฆษณา
- กรอง: ข้อมูลที่ไม่บังคับที่จำเป็นสำหรับ Protected Audience API เพื่อกรองโฆษณาตามข้อมูลในอุปกรณ์ อ่านรายละเอียดเพิ่มเติมได้ที่ส่วนตรรกะการกรองฝั่งซื้อ
เวิร์กโฟลว์การเลือกโฆษณา
ข้อเสนอนี้มีเป้าหมายที่จะปรับปรุงความเป็นส่วนตัวโดยเปิดตัว Ad Selection API ซึ่งจัดการการประมูลสำหรับแพลตฟอร์มเทคโนโลยีโฆษณา
ปัจจุบันแพลตฟอร์มเทคโนโลยีโฆษณาในปัจจุบันมักจะทำการเสนอราคาและการเลือกโฆษณาเฉพาะใน เซิร์ฟเวอร์ของตน ในข้อเสนอนี้ กลุ่มเป้าหมายที่กำหนดเองและสัญญาณที่ละเอียดอ่อนอื่นๆ ของผู้ใช้ เช่น ข้อมูลแพ็กเกจที่ติดตั้งไว้ซึ่งพร้อมใช้งาน จะเข้าถึงได้ผ่าน Ad Selection API เท่านั้น นอกจากนี้ สำหรับกรณีการใช้รีมาร์เก็ตติ้งโฆษณาผู้สมัครจะถูกดึงออกจากวง (กล่าวคือ ไม่ใช่ในบริบทที่จะแสดงโฆษณา) แพลตฟอร์มเทคโนโลยีโฆษณาจะต้องเตรียมการติดตั้งใช้งานและดําเนินการบางส่วนของตรรกะการประมูลและการเลือกโฆษณาในปัจจุบันในอุปกรณ์ แพลตฟอร์มเทคโนโลยีโฆษณาอาจพิจารณาการเปลี่ยนแปลงต่อไปนี้ในเวิร์กโฟลว์การเลือกโฆษณา
- หากไม่มีข้อมูลแพ็กเกจที่ติดตั้งไว้บนเซิร์ฟเวอร์ แพลตฟอร์มเทคโนโลยีโฆษณาอาจต้องส่งโฆษณาตามบริบทหลายรายการกลับไปยังอุปกรณ์และเรียกใช้เวิร์กโฟลว์การเลือกโฆษณาเพื่อเปิดใช้การกรองตามการติดตั้งแอปเพื่อเพิ่มโอกาสในการแสดงโฆษณาที่เกี่ยวข้อง
- เนื่องจากระบบดึงข้อมูลโฆษณารีมาร์เก็ตติ้งนอกกลุ่ม จึงอาจจำเป็นต้องอัปเดตรูปแบบการเสนอราคาปัจจุบัน แพลตฟอร์มเทคโนโลยีโฆษณาอาจต้องสร้างรูปแบบย่อยของการเสนอราคา (การใช้งานอาจอิงตามรูปแบบที่เรียกว่าโมเดล 2 หอ) ซึ่งทำงานกับฟีเจอร์โฆษณาและสัญญาณบริบทแยกกันได้ และรวมเอาต์พุตของโมเดลย่อยในอุปกรณ์เพื่อคาดการณ์ราคาเสนอ ซึ่งจะได้รับประโยชน์จากทั้งการประมูลฝั่งเซิร์ฟเวอร์และการประมูลสำหรับโอกาสในการโฆษณาใดๆ
วิธีนี้ช่วยให้ข้อมูลการโต้ตอบในแอปของผู้ใช้มีข้อมูลในการเลือกโฆษณา ในขณะเดียวกันก็จำกัดการแชร์ข้อมูลนี้กับบุคคลที่สาม
เวิร์กโฟลว์การเลือกโฆษณานี้จัดการการดําเนินการโค้ด JavaScript จากเทคโนโลยีโฆษณาในอุปกรณ์ตามลําดับต่อไปนี้
- การดำเนินการตามตรรกะการเสนอราคาฝั่งซื้อ
- การกรองและการประมวลผลโฆษณาฝั่งซื้อ
- การใช้ตรรกะการตัดสินใจฝั่งผู้ขาย
สำหรับการเลือกโฆษณาที่เกี่ยวข้องกับกลุ่มเป้าหมายที่กำหนดเอง แพลตฟอร์มจะดึงโค้ด JavaScript ที่ได้จากฝั่งลูกค้าโดยอิงตามปลายทาง URL สาธารณะที่กำหนดโดยข้อมูลเมตา "URL ตรรกะการเสนอราคา" ของกลุ่มเป้าหมายที่กำหนดเอง ระบบจะส่งปลายทาง URL สำหรับโค้ดการตัดสินใจฝั่งขายเป็นอินพุตเพื่อเริ่มต้นเวิร์กโฟลว์การเลือกโฆษณาด้วย
การออกแบบการเลือกโฆษณาที่ไม่เกี่ยวข้องกับกลุ่มเป้าหมายที่กำหนดเองจะอยู่ภายใต้การออกแบบที่ใช้งานอยู่
เริ่มเวิร์กโฟลว์การเลือกโฆษณา
เมื่อแอปจำเป็นต้องแสดงโฆษณา SDK ของแพลตฟอร์มเทคโนโลยีโฆษณาอาจเริ่มเวิร์กโฟลว์การเลือกโฆษณาด้วยการเรียกใช้เมธอด selectAds() หลังจากเริ่มต้นออบเจ็กต์ AdSelectionConfig ด้วยพารามิเตอร์ที่คาดไว้ ดังนี้
- ผู้ขาย: ตัวระบุสำหรับแพลตฟอร์มโฆษณาฝั่งขายตามรูปแบบ eTLD+1
- URL ตรรกะการตัดสิน: เมื่อเริ่มการประมูลเพื่อแสดงโฆษณา แพลตฟอร์มจะใช้ URL นี้เพื่อดึงโค้ด JavaScript จากแพลตฟอร์มฝั่งขายเพื่อให้คะแนนโฆษณาที่ชนะการประมูล
- ผู้ซื้อที่มีกลุ่มเป้าหมายที่กำหนดเอง: รายการแพลตฟอร์มฝั่งซื้อที่มีความต้องการตามกลุ่มเป้าหมายที่กำหนดเองสำหรับการประมูลนี้ ซึ่งเป็นไปตามรูปแบบ eTLD+1
- สัญญาณการเลือกโฆษณา: ข้อมูลเกี่ยวกับการประมูล (ขนาดโฆษณา รูปแบบโฆษณา ฯลฯ)
- สัญญาณของผู้ขาย: สัญญาณเฉพาะแพลตฟอร์มฝั่งซัพพลาย
- URL สัญญาณการให้คะแนนที่เชื่อถือได้: ปลายทาง URL ของสัญญาณที่เชื่อถือได้ฝั่งผู้ขายซึ่งดึงข้อมูลแบบเรียลไทม์เฉพาะของครีเอทีฟโฆษณาได้
- สัญญาณต่อผู้ซื้อ: ฝั่งดีมานด์ที่เข้าร่วมอาจใช้พารามิเตอร์นี้เพื่อป้อนข้อมูลสําหรับการประมูล ตัวอย่างเช่น พารามิเตอร์นี้อาจรวมถึงข้อมูลบริบทที่ครอบคลุมซึ่งมีประโยชน์ในการกำหนดราคาเสนอ
ข้อมูลโค้ดสำหรับแสดงตัวอย่างต่อไปนี้แสดง SDK ของแพลตฟอร์มเทคโนโลยีโฆษณาที่เริ่มเวิร์กโฟลว์การเลือกโฆษณาโดยกำหนด AdSelectionConfig ก่อน แล้วจึงเรียกใช้ selectAds เพื่อให้ได้โฆษณาที่ชนะ
AdSelectionConfig myAdSelectionConfig = new AdSelectionConfig {
Seller = "example-ssp1.com",
DecisionLogicURL = Uri.parse("https://..."),
CustomAudienceBuyerList = Arrays.asList("example-dsp1.com","bexample-dsp2.com"),
AdSelectionSignals = "{"min_price": 10,"auction_attempts": 3}"
SellerSignals = "{"seller_type": "news", "content_category": "sports","mature_ads_accepted" :"false"}"
PerBuyerSignals = " {"buyer1Name": {"key1" : "value1"},
"buyer2Name": {"key1" : "value1", "key2" : "value2" }"
};
// Invoke ad services API to initiate ad selection workflow.
Ad winningAd = selectAds(myAdSelectionConfig);
ตรรกะการเสนอราคาฝั่งซื้อ
โดยทั่วไปตรรกะการเสนอราคาจะได้จากแพลตฟอร์มฝั่งซื้อ วัตถุประสงค์ของโค้ดนี้คือกำหนดราคาเสนอสำหรับโฆษณาที่ผู้สมัคร อาจใช้ตรรกะทางธุรกิจเพิ่มเติมในการกำหนดผลลัพธ์
แพลตฟอร์มจะใช้ข้อมูลเมตา "URL ตรรกะการเสนอราคา" ของกลุ่มเป้าหมายที่กำหนดเองเพื่อดึงข้อมูลโค้ด JavaScript ซึ่งควรมีลายเซ็นของฟังก์ชันด้านล่าง
generateBid(ad, auction_signals, per_buyer_signals, trusted_bidding_signals,
contextual_signals, user_signals, custom_audience_signals) {
// ...
return {'bid': ...};
}
วิธีการ generateBid() จะแสดงผลราคาเสนอที่คำนวณได้ แพลตฟอร์มจะเรียกใช้ฟังก์ชันนี้กับโฆษณาทั้งหมด (ตามบริบทหรือรีมาร์เก็ตติ้ง) ตามลำดับ ในกรณีที่มีผู้ให้บริการตรรกะการเสนอราคาหลายราย ระบบจะไม่รับประกันลำดับการดำเนินการของผู้ให้บริการ
ฟังก์ชันนี้ต้องการพารามิเตอร์ต่อไปนี้
- โฆษณา: โฆษณาที่โค้ดการเสนอราคาฝั่งซื้อกำลังพิจารณา วิดีโอนี้จะเป็นโฆษณาจากกลุ่มเป้าหมายที่กำหนดเองที่มีสิทธิ์
- สัญญาณการประมูล: สัญญาณเฉพาะแพลตฟอร์มฝั่งผู้ขาย
- สัญญาณต่อผู้ซื้อ: ฝั่งดีมานด์ที่เข้าร่วมอาจใช้พารามิเตอร์นี้เพื่อป้อนข้อมูลสําหรับการประมูล ตัวอย่างเช่น พารามิเตอร์นี้อาจรวมถึงข้อมูลบริบทที่ครอบคลุมซึ่งมีประโยชน์ในการกำหนดราคาเสนอ
- สัญญาณการเสนอราคาที่เชื่อถือได้: แพลตฟอร์มเทคโนโลยีโฆษณาอาศัยข้อมูลแบบเรียลไทม์เพื่อแจ้งการดึงข้อมูลและการให้คะแนนโฆษณา ตัวอย่างเช่น แคมเปญโฆษณาอาจใช้งบประมาณจนหมดและจำเป็นต้องหยุดแสดงทันที เทคโนโลยีโฆษณาจะกำหนดปลายทาง URL จากที่ที่ดึงข้อมูลแบบเรียลไทม์นี้ได้และชุดคีย์ที่ต้องใช้การค้นหาแบบเรียลไทม์ เซิร์ฟเวอร์ที่มีการจัดการของแพลตฟอร์มเทคโนโลยีโฆษณาที่ให้บริการคำขอนี้จะเป็นเซิร์ฟเวอร์ที่เชื่อถือได้ที่จัดการโดยแพลตฟอร์มเทคโนโลยีโฆษณา
- สัญญาณบริบท: ซึ่งอาจรวมถึงการประทับเวลาแบบคร่าวๆ หรือข้อมูลตำแหน่งโดยประมาณ หรือต้นทุนต่อคลิกในโฆษณา
- สัญญาณของผู้ใช้: ซึ่งอาจรวมถึงข้อมูลต่างๆ เช่น ข้อมูลแพ็กเกจที่ติดตั้งไว้
ค่าโฆษณา
นอกจากราคาเสนอแล้ว แพลตฟอร์มฝั่งซื้อยังมีตัวเลือกในการแสดงผลต้นทุนต่อคลิกเป็นส่วนหนึ่งของ generateBid() ด้วย เช่น
generateBid(ad, auction_signals, per_buyer_signals, trusted_bidding_signals,
contextual_signals, user_signals, custom_audience_signals) {
// ...
return {'bid': ..., 'adCost': ...,};
}
หากโฆษณานี้เป็นผู้ชนะ adCost จะปัดเศษโดยอัตโนมัติเป็น 8 บิตเพื่อความเป็นส่วนตัว จากนั้นระบบจะส่งมูลค่าปัดเศษของ adCost ไปยังพารามิเตอร์ contextual_signals ใน reportWin ระหว่างการรายงานการแสดงผล
ตรรกะการกรองฝั่งซื้อ
แพลตฟอร์มฝั่งซื้อจะกรองโฆษณาได้ตามสัญญาณเพิ่มเติมในอุปกรณ์ที่มีอยู่ในระหว่างขั้นตอนการเลือกโฆษณา ตัวอย่างเช่น แพลตฟอร์มเทคโนโลยีโฆษณา สามารถใช้ความสามารถในการกำหนดความถี่สูงสุดที่นี่ หากมีผู้ให้บริการการกรองหลายราย ระบบจะไม่รับประกันลำดับการดำเนินการระหว่างผู้ให้บริการรายนั้นๆ
คุณนําตรรกะการกรองฝั่งซื้อมาใช้เป็นส่วนหนึ่งของตรรกะการเสนอราคาได้โดยการแสดงผลมูลค่าราคาเสนอเป็น 0 สําหรับโฆษณาหนึ่งๆ
นอกจากนี้ แพลตฟอร์มฝั่งซื้อยังส่งสัญญาณได้ว่าควรกรองโฆษณาหนึ่งๆ ตามสัญญาณเพิ่มเติมในอุปกรณ์ที่พร้อมใช้กับกลุ่มเป้าหมายที่ได้รับการปกป้อง โดยโฆษณาจะไม่ออกไปจากอุปกรณ์ เมื่อเราทำให้การออกแบบตรรกะการกรองเพิ่มเติมแข็งแกร่งขึ้น แพลตฟอร์มฝั่งซื้อก็จะทำตามโครงสร้างเดียวกันนี้เพื่อส่งสัญญาณว่าควรมีการกรองเกิดขึ้น
ตรรกะการให้คะแนนฝั่งผู้ขาย
โดยทั่วไปตรรกะการให้คะแนนจะระบุโดยแพลตฟอร์มฝั่งขาย วัตถุประสงค์ของโค้ดคือการกำหนดโฆษณาที่ชนะตามผลลัพธ์ตรรกะการเสนอราคา และอาจใช้ตรรกะทางธุรกิจเพิ่มเติมเพื่อหาผลลัพธ์ หากมีผู้ให้บริการตรรกะการตัดสินหลายราย ระบบจะไม่รับประกันลำดับการดำเนินการระหว่างผู้ให้บริการรายนั้นๆ แพลตฟอร์มจะใช้พารามิเตอร์อินพุต "URL ตรรกะการตัดสิน" ของ API ของ selectAds() เพื่อดึงข้อมูลโค้ด JavaScript ซึ่งควรมีลายเซ็นของฟังก์ชันที่ด้านล่าง
scoreAd(ad, bid, auction_config, trusted_scoring_signals,
contextual_signals, user_signals, custom_audience_signals) {
// ...
return score_for_this_ad;
}
ฟังก์ชันนี้ต้องการพารามิเตอร์ต่อไปนี้
- โฆษณา: โฆษณาที่กำลังประเมิน ซึ่งแสดงผลจากฟังก์ชัน
generateBid() - ราคาเสนอ: ราคาเสนอที่ได้จากฟังก์ชัน
generateBid() - การกำหนดค่าการประมูล: พารามิเตอร์อินพุตไปยังเมธอด
selectAds() - สัญญาณการให้คะแนนที่เชื่อถือได้: แพลตฟอร์มเทคโนโลยีโฆษณาอาศัยข้อมูลแบบเรียลไทม์เพื่อแจ้งการกรองและการให้คะแนนโฆษณา ตัวอย่างเช่น ผู้เผยแพร่แอปอาจบล็อกแคมเปญโฆษณาไม่ให้แสดงโฆษณาในแอป โดยข้อมูลนี้ดึงมาจากพารามิเตอร์ URL สัญญาณการให้คะแนนที่เชื่อถือได้ของการกำหนดค่าการประมูล เซิร์ฟเวอร์ที่แสดงคำขอนี้ควรเป็นเซิร์ฟเวอร์ที่เชื่อถือได้ซึ่งจัดการโดยเทคโนโลยีโฆษณา
- สัญญาณบริบท: ซึ่งอาจรวมถึงการประทับเวลาแบบคร่าวๆ หรือข้อมูลตำแหน่งโดยประมาณ
- สัญญาณผู้ใช้: ซึ่งอาจรวมถึงข้อมูล เช่น App Store ที่เริ่มการติดตั้งแอป
- สัญญาณกลุ่มเป้าหมายที่กําหนดเอง: หากโฆษณาที่กำลังได้รับคะแนนมาจากกลุ่มเป้าหมายที่กําหนดเองในอุปกรณ์ ข้อมูลนี้จะมีข้อมูล เช่น ผู้อ่านและชื่อของกลุ่มเป้าหมายที่กําหนดเอง
รันไทม์ของโค้ดการเลือกโฆษณา
ในข้อเสนอ ระบบจะดึงโค้ดการประมูลที่ได้จากแพลตฟอร์มเทคโนโลยีโฆษณาจากปลายทาง URL ที่กำหนดค่าได้และเรียกใช้ในอุปกรณ์ เมื่อพิจารณาจากข้อจำกัดด้านทรัพยากรบนอุปกรณ์เคลื่อนที่ โค้ดการประมูลควรเป็นไปตามหลักเกณฑ์ต่อไปนี้
- โค้ดควรทำงานเสร็จภายในระยะเวลาที่กำหนดไว้ล่วงหน้า ขอบเขตนี้จะใช้กับเครือข่ายโฆษณาของผู้ซื้อทั้งหมดอย่างเท่าเทียมกัน เราจะแชร์รายละเอียดของขอบเขตนี้ ในการอัปเดตภายหลัง
- โค้ดต้องมีทุกอย่างในตัวและไม่มีทรัพยากร Dependency ภายนอก
เนื่องจากโค้ดการประมูล เช่น ตรรกะการเสนอราคา อาจต้องเข้าถึงข้อมูลส่วนตัวของผู้ใช้ เช่น แหล่งที่มาของการติดตั้งแอป รันไทม์นี้จะไม่แสดงสิทธิ์เข้าถึงเครือข่ายหรือพื้นที่เก็บข้อมูล
ภาษาโปรแกรม
โค้ดการประมูลที่ได้จากแพลตฟอร์มเทคโนโลยีโฆษณาควรเขียนด้วย JavaScript วิธีนี้ช่วยให้แพลตฟอร์มเทคโนโลยีโฆษณา (เช่น แชร์โค้ดการเสนอราคาข้ามแพลตฟอร์มที่รองรับ Privacy Sandbox)
การแสดงโฆษณาที่มีประสิทธิภาพสูงสุด
โฆษณาที่มีคะแนนสูงสุดจะถือว่าเป็นผู้ชนะการประมูล ในข้อเสนอเริ่มต้นนี้ ระบบจะส่งโฆษณาที่ชนะไปยัง SDK เพื่อการแสดงผล
แผนคือการพัฒนาโซลูชันเพื่อให้แน่ใจว่าแอปหรือ SDK ไม่สามารถกำหนดข้อมูลเกี่ยวกับการเป็นสมาชิกกลุ่มเป้าหมายที่กําหนดเองของผู้ใช้หรือประวัติการมีส่วนร่วมกับแอปผ่านข้อมูลเกี่ยวกับโฆษณาที่ชนะ (คล้ายกับข้อเสนอการใช้เฟรมที่มีการปิดกั้นของ Chrome
การรายงานการแสดงผลและเหตุการณ์
เมื่อโฆษณาแสดงผลแล้ว อาจมีการรายงานการแสดงผลที่ชนะกลับไปยังแพลตฟอร์มฝั่งซื้อและฝั่งขายที่เข้าร่วม วิธีนี้ช่วยให้ผู้ซื้อและผู้ขายสามารถรวมข้อมูลจากการประมูล เช่น ราคาเสนอหรือชื่อกลุ่มเป้าหมายที่กำหนดเอง ไว้กับรายงานการแสดงผลที่ชนะได้ นอกจากนี้ แพลตฟอร์มฝั่งซื้อและฝั่งขายที่ชนะการประมูลยังมีสิทธิ์ได้รับรายงานระดับเหตุการณ์เพิ่มเติมเกี่ยวกับโฆษณาที่ชนะด้วย ซึ่งทำให้สามารถรวมข้อมูลเกี่ยวกับการประมูล (ราคาเสนอ ชื่อกลุ่มเป้าหมายที่กำหนดเอง ฯลฯ) กับการคลิก การดู และเหตุการณ์โฆษณาอื่นๆ ได้ แพลตฟอร์มจะเรียกใช้ตรรกะการรายงานตามลำดับต่อไปนี้
- การรายงานฝั่งผู้ขาย
- การรายงานฝั่งซื้อ
วิธีนี้ทำให้แพลตฟอร์มฝั่งซื้อและฝั่งผู้ขายส่งข้อมูลที่สำคัญในอุปกรณ์กลับไปยังเซิร์ฟเวอร์เพื่อเปิดใช้ความสามารถต่างๆ เช่น การจัดทำงบประมาณแบบเรียลไทม์ การอัปเดตรูปแบบการเสนอราคา และเวิร์กโฟลว์การเรียกเก็บเงินที่แม่นยำ การรองรับการรายงานการแสดงผลนี้เป็นส่วนเสริมของ Attribution Reporting API
การรองรับการรายงานเหตุการณ์มี 2 ขั้นตอน ได้แก่ JavaScript ฝั่งขายและฝั่งซื้อต้องบันทึกเหตุการณ์ที่ควรได้รับรายงานเหตุการณ์ และฝั่งผู้ขายมีหน้าที่รายงานข้อมูลระดับเหตุการณ์
Protected Audience เป็นกลไกในการติดตามเหตุการณ์ในอนาคตที่เกี่ยวข้องกับการประมูลที่ชนะโดยการลงทะเบียนบีคอน ในฟังก์ชัน JavaScript reportResult() ของผู้ขาย แพลตฟอร์มฝั่งขายสามารถลงทะเบียนบีคอนโดยใช้ฟังก์ชัน registerAdBeacon() ของแพลตฟอร์มได้ ในทํานองเดียวกัน แพลตฟอร์มฝั่งซื้อจะเรียกเมธอด registerAdBeacon() จากฟังก์ชัน JavaScript reportWin() ได้
registerAdBeacon(beacons)
อินพุต:
event_key: สตริงที่อธิบายประเภทการโต้ตอบที่ควรลงทะเบียน ฟังก์ชันนี้ใช้เป็นคีย์ในการค้นหาจุดสิ้นสุดที่คำสั่ง ping ของแพลตฟอร์มพร้อมกับรายงานผลการประมูลreporting_url: URL ของแพลตฟอร์มเทคโนโลยีโฆษณาสำหรับจัดการเหตุการณ์
คีย์เหตุการณ์คือตัวระบุสตริงที่เป็นของ SDK ฝั่งขายซึ่งมีหน้าที่รายงานผลการประมูล เพื่อให้มีการติดต่อกลับ เทคโนโลยีโฆษณาจะลงทะเบียนบีคอนด้วยคีย์ที่ตรงกับคีย์ที่ฝั่งขายใช้เมื่อรายงานเหตุการณ์ คีย์เหล่านี้ไม่จำเป็นต้องเป็น k-anonym นอกจากนี้จะมีขีดจำกัดจำนวนและความยาวของคีย์ที่ลงทะเบียนสำหรับกลุ่มเป้าหมายที่กำหนดเองที่ระบุได้ หากมีการเรียก reportEvent() แพลตฟอร์มฝั่งขายที่ใช้การประมูลจะได้รับรายงานเหตุการณ์เหล่านี้เสมอ เฉพาะแพลตฟอร์มฝั่งซื้อที่ชนะเท่านั้นที่มีสิทธิ์ได้รับรายงานเหล่านี้
การรายงานฝั่งผู้ขาย
แพลตฟอร์มจะเรียกใช้ฟังก์ชัน JavaScript reportResult() ในโค้ดที่ได้จากฝั่งซัพพลายซึ่งดาวน์โหลดจากพารามิเตอร์ URL ตรรกะการตัดสินใจของผู้ขายสำหรับ selectAds() API
reportResult(render_url, bid, auction_config, contextual_signals) {
// ...
beacons = {"click":clickUri}
registerAdBeacon(beacons)
return {
"status": 0,
"results": {"reporting_url": reporting_url,
"signals_for_buyer": signals_for_buyer}};
}
เอาต์พุต: ออบเจ็กต์ JSON ที่มี
- สถานะ:
0สำหรับความสำเร็จ ค่าอื่นๆ สำหรับความล้มเหลว - URL การรายงาน: แพลตฟอร์มจะเรียกใช้ URL นี้ที่ส่งคืนจากฟังก์ชัน
- สัญญาณสำหรับผู้ซื้อ: ออบเจ็กต์ JSON ที่จะส่งไปยังฟังก์ชัน
reportWinของผู้ซื้อ
ฝั่งซัพพลายอาจเข้ารหัสสัญญาณที่เกี่ยวข้องใน URL การรายงานเพื่อช่วยให้ได้ข้อมูลเชิงลึกเพิ่มเติมเกี่ยวกับการประมูลและโฆษณาที่ชนะการประมูล เช่น อาจมีสัญญาณต่อไปนี้
- URL การแสดงโฆษณา
- ราคาเสนอที่ชนะ
- ชื่อแอป
- ตัวระบุการค้นหา
- สัญญาณสำหรับผู้ซื้อ: แพลตฟอร์มจะส่งข้อมูลผลตอบแทนนี้เป็นพารามิเตอร์อินพุตไปยังโค้ดการรายงานฝั่งดีมานด์เพื่อรองรับการแชร์ข้อมูลระหว่างฝั่งซัพพลายและฝั่งดีมานด์
การรายงานฝั่งซื้อ
แพลตฟอร์มจะเรียกใช้ฟังก์ชัน reportWin() JavaScript ในโค้ดที่ได้จากฝั่งดีมานด์ซึ่งดาวน์โหลดจากข้อมูลเมตา URL ตรรกะการเสนอราคาของกลุ่มเป้าหมายที่กําหนดเองที่เชื่อมโยงกับการประมูล
reportWin(render_url, bid, auction_signals, per_buyer_signals,
signals_for_buyer, contextual_signals, custom_audience_signals) {
// ...
beacons = {"click":clickUri}
registerAdBeacon(beacons)
return {
"status": 0,
"results": {"reporting_uri": reporting_uri}};
}
อินพุต:
auction_signalsและper_buyer_signalsดึงมาจากAuctionConfigข้อมูลที่แพลตฟอร์มฝั่งซื้อจำเป็นต้องส่งไปยัง URL การรายงานอาจมาจากมูลฐานนี้signals_for_buyerเป็นเอาต์พุตของ report Results ฝั่งขาย ซึ่งทำให้แพลตฟอร์มฝั่งขายมีโอกาสแชร์ข้อมูลกับแพลตฟอร์มฝั่งซื้อเพื่อวัตถุประสงค์ในการรายงานcontextual_signalsมีข้อมูลอย่างเช่นชื่อแอป และcustom_audience_signalsมีข้อมูลกลุ่มเป้าหมายที่กำหนดเอง อาจมีการเพิ่มข้อมูลอื่นๆ ในอนาคต
เอาต์พุต:
- สถานะ:
0สำหรับความสำเร็จ ค่าอื่นๆ สำหรับความล้มเหลว - URL การรายงาน: แพลตฟอร์มจะเรียกใช้ URL นี้ที่ส่งคืนจากฟังก์ชัน
เหตุการณ์การรายงาน
เหตุการณ์การรายงานจะทำได้หลังจากการรายงานการแสดงผลสำหรับการประมูลเสร็จสมบูรณ์แล้วเท่านั้น SDK ฝั่งขายมีหน้าที่ในการรายงานเหตุการณ์ต่างๆ แพลตฟอร์มจะแสดง API ที่ใช้ ReportEventRequest ที่ระบุการประมูลที่ใช้งานล่าสุด คีย์เหตุการณ์ที่รายงาน ข้อมูลที่เชื่อมโยงกับคีย์นั้น การเลือกว่าควรส่งรายงานไปยังผู้ซื้อหรือผู้ขาย (หรือทั้งคู่) และเหตุการณ์อินพุตที่ไม่บังคับสำหรับเหตุการณ์โฆษณา ไคลเอ็นต์จะกำหนดคีย์เหตุการณ์
และการรวบรวมข้อมูลที่จะรายงาน
ReportEventRequest request = new ReportEventRequest(
AdSelectionId = ad_selection_id,
event_key = "view"
event_data = "{ "viewTimeInSeconds" :1 }",
reporting_destinations =
FLAG_REPORTING_DESTINATION_SELLER |
FLAG_REPORTING_DESTINATION_BUYER,
input_event = clickInputEvent // or null for view
)
reportEvent(request)
อินพุต:
ad_selection_idต้องเป็นAdSelectionIdของการประมูลที่ดำเนินการล่าสุดซึ่งดึงมาจากAdSelectionOutcomeevent_keyคือสตริงที่กำหนดฝั่งขายซึ่งอธิบายถึงเหตุการณ์การโต้ตอบevent_dataเป็นสตริงที่แสดงข้อมูลที่เชื่อมโยงกับevent_keyreporting_destinationsเป็นชุดมาสก์บิตที่ใช้แฟล็กที่แพลตฟอร์มมีให้ ซึ่งอาจเป็นFLAG_REPORTING_DESTINATION_SELLERหรือFLAG_REPORTING_DESTINATION_BUYERหรือทั้ง 2 อย่างก็ได้input_event(ไม่บังคับ) จะใช้สำหรับการผสานรวมกับ Attribution Reporting API โดยอาจเป็นออบเจ็กต์InputEvent(สำหรับเหตุการณ์การคลิก) หรือ Null (สำหรับเหตุการณ์การดู) ดูรายละเอียดเพิ่มเติมเกี่ยวกับพารามิเตอร์นี้ได้ที่การผสานรวม Attribution Reporting API
หลังจากที่ SDK ฝั่งขายเรียกใช้ reportEvent แพลตฟอร์มจะพยายามจับคู่ event_key กับคีย์ที่ผู้ซื้อและผู้ขายลงทะเบียนในฟังก์ชัน reportWin และ reportResult ของ JavaScript ทั้งนี้ขึ้นอยู่กับแฟล็ก reporting_destinations หากมีการจับคู่ที่ตรงกัน แพลตฟอร์มจะ POST
event_data ไปยังreporting_urlที่เชื่อมโยง ประเภทเนื้อหาของคำขอจะเป็นข้อความธรรมดาที่มีส่วนเนื้อหาเป็น event_data คำขอนี้จะพยายามอย่างเต็มที่และจะล้มเหลวโดยไม่มีการแจ้งเตือนในกรณีที่เกิดข้อผิดพลาดเกี่ยวกับเครือข่าย ตอบกลับข้อผิดพลาดเกี่ยวกับเซิร์ฟเวอร์ หรือไม่พบคีย์ที่ตรงกัน
การผสานรวม Attribution Reporting API
เราเสนอฟังก์ชันการทำงานข้าม API ใน Protected Audience และ Attribution Reporting API (ARA) เพื่อสนับสนุนผู้ซื้อที่เข้าร่วมการประมูล Protected Audience ฟังก์ชันการทำงานนี้ทำให้เทคโนโลยีโฆษณาสามารถประเมินประสิทธิภาพการระบุแหล่งที่มาของตนในกลยุทธ์รีมาร์เก็ตติ้งต่างๆ เพื่อให้เข้าใจว่ากลุ่มเป้าหมายประเภทใดที่ให้ ROI สูงสุด
ด้วยการผสานรวมข้าม API นี้ AdTech จะทําสิ่งต่อไปนี้ได้
- สร้างแผนที่คีย์-ค่าของ URI ที่จะใช้สำหรับทั้ง 1) การรายงานการโต้ตอบกับโฆษณา และ 2) การลงทะเบียนแหล่งที่มา
- รวมข้อมูลการประมูลจากการประมูล Protected Audience ไว้ในการแมปคีย์ฝั่งแหล่งที่มาเพื่อการรายงานสรุปแบบรวม (โดยใช้ Attribution Reporting API) ดูข้อมูลเพิ่มเติมได้ที่ข้อเสนอการออกแบบ ARA
เมื่อผู้ใช้เห็นหรือคลิกที่โฆษณา
- URL ที่ใช้ในการรายงานการโต้ตอบของเหตุการณ์เหล่านั้นโดยใช้ Protected Audience จะให้ข้อมูลที่จำเป็นแก่ผู้ซื้อเพื่อใช้ลงทะเบียนการดูหรือคลิกเป็นแหล่งที่มาที่มีสิทธิ์ด้วย Attribution Reporting API
- เทคโนโลยีโฆษณาอาจเลือกส่ง
CustomAudience(หรือข้อมูลบริบทที่เกี่ยวข้องอื่นๆ เกี่ยวกับโฆษณา เช่น ตำแหน่งโฆษณาหรือระยะเวลาการดู) โดยใช้ URL ดังกล่าว เพื่อให้ข้อมูลเมตานี้เผยแพร่ไปยังรายงานสรุปได้เมื่อเทคโนโลยีโฆษณากำลังตรวจสอบประสิทธิภาพแคมเปญโดยรวม
การเปิดใช้การลงทะเบียนแหล่งที่มา
reportEvent() จะยอมรับพารามิเตอร์ใหม่ที่ไม่บังคับ InputEvent ผู้ซื้อที่ชนะซึ่งลงทะเบียนบีคอนโฆษณาสามารถเลือกรายงาน reportEvent ที่จะลงทะเบียนด้วย Attribution Reporting API เป็นแหล่งที่มาที่ลงทะเบียนได้ ระบบจะเพิ่มส่วนหัวคำขอ Attribution-Reporting-มีสิทธิ์ลงในคำขอการรายงานเหตุการณ์ทั้งหมดที่ส่งจาก reportEvent() ระบบจะแยกวิเคราะห์การตอบกลับที่มีส่วนหัว ARA ที่เหมาะสมในแบบเดียวกับการตอบกลับการลงทะเบียนแหล่งที่มา ARA ปกติอื่นๆ โปรดดูวิธีลงทะเบียน URL แหล่งที่มาในคำอธิบาย Attribution Reporting API
เนื่องจาก ARA บน Android สนับสนุนกิจกรรมการดูและการคลิกInputEvents
จึงมีการใช้เพื่อแยกความแตกต่างระหว่างกิจกรรมทั้งสองประเภทนี้ ซึ่ง reportEvent() API จะตีความ InputEvent ที่แพลตฟอร์มยืนยันแล้วว่าเป็นเหตุการณ์การคลิก เช่นเดียวกับในการลงทะเบียนแหล่งที่มาของ ARA หาก InputEvent ขาดหายไป เป็นค่าว่าง หรือไม่ถูกต้อง การลงทะเบียนแหล่งที่มาจะถือว่าเป็นการดู
โปรดทราบว่า eventData หลังการประมูลอาจมีข้อมูลที่ละเอียดอ่อน ดังนั้นแพลตฟอร์มจะใช้ eventData ในคำขอลงทะเบียนต้นทางที่เปลี่ยนเส้นทาง
ตัวอย่างการรายงานการมีส่วนร่วมและ Conversion
ในตัวอย่างนี้ เราจะดูจากมุมมองของผู้ซื้อที่สนใจ เชื่อมโยงข้อมูลจากการประมูล โฆษณาที่แสดง และแอป Conversion เข้าด้วยกัน
ในเวิร์กโฟลว์นี้ ผู้ซื้อจะประสานงานกับผู้ขายเพื่อส่งรหัสที่ไม่ซ้ำกันเข้าสู่การประมูล ในระหว่างการประมูล ผู้ซื้อจะส่งรหัสที่ไม่ซ้ำกันนี้พร้อมข้อมูลการประมูล ในระหว่างการแสดงผลและเวลาที่เกิด Conversion ระบบจะส่งข้อมูลจากโฆษณาที่แสดงพร้อมรหัสที่ไม่ซ้ำกันเดียวกันด้วย จากนั้นคุณจะใช้รหัสที่ไม่ซ้ำกันเพื่อเชื่อมโยงรายงานเหล่านี้เข้าด้วยกันได้
ขั้นตอนการทำงาน:
ก่อนที่การประมูลจะเริ่มขึ้น ผู้ซื้อจะส่งรหัสที่ไม่ซ้ำกันให้กับผู้ขาย โดยเป็นส่วนหนึ่งของ
การเสนอราคาตอบการเสนอราคาแบบเรียลไทม์ ("RTB") แบบเป็นโปรแกรม รหัสดังกล่าวจะตั้งค่าเป็นตัวแปรได้ เช่น auctionId รหัสนี้ส่งผ่านด้วยชื่อ perBuyerSignals ใน auctionConfig และจะพร้อมใช้งานในตรรกะการเสนอราคาของผู้ซื้อ
- ในระหว่างการดำเนินการของ
reportWinผู้ซื้อสามารถบันทึกบีคอนโฆษณาที่จะถูกเรียกใช้ ระหว่างเวลาในการแสดงโฆษณาและสำหรับเหตุการณ์การโต้ตอบที่เฉพาะเจาะจง (registerAdBeacon()) หากต้องการเชื่อมโยงสัญญาณการประมูลสำหรับเหตุการณ์โฆษณา ให้ตั้งค่าauctionIdเป็นพารามิเตอร์การค้นหาของ URL บีคอน - ในระหว่างเวลาแสดงโฆษณา บีคอนที่ลงทะเบียนไว้ในช่วงเวลาการประมูลจะทริกเกอร์หรือปรับปรุงด้วยข้อมูลระดับเหตุการณ์ได้ ผู้ขายต้องทริกเกอร์
reportEvent()และส่งข้อมูลระดับเหตุการณ์ แพลตฟอร์มจะใช้คำสั่ง ping กับ URL บีคอนโฆษณาที่ลงทะเบียนของผู้ซื้อซึ่งสัมพันธ์กับreportEvent()ที่ทริกเกอร์ - ผู้ซื้อจะลงทะเบียนโฆษณากับ Attribution Reporting API โดยตอบกลับคำขอบีคอนโฆษณาด้วยส่วนหัว
Attribution-Reporting-Register-Sourceหากต้องการเชื่อมโยงสัญญาณการประมูลสําหรับเหตุการณ์ Conversion ให้ตั้งค่าauctionIdใน URL แหล่งที่มาของการลงทะเบียน
หลังจากขั้นตอนข้างต้น ผู้ซื้อจะมีรายงานการประมูล รายงานการโต้ตอบ และรายงาน Conversion ที่สัมพันธ์กันได้โดยใช้รหัสที่ไม่ซ้ำกันซึ่งสามารถใช้เชื่อมโยงกัน
เวิร์กโฟลว์ที่คล้ายกันนี้ใช้กับผู้ขายได้หากจําเป็นต้องเข้าถึงข้อมูลการระบุแหล่งที่มา และผู้ขายยังใช้รหัสที่ไม่ซ้ำกันเพื่อส่งด้วย registerAdBeacon() ได้ด้วย การเรียก reportEvent() มีพร็อพเพอร์ตี้ปลายทางที่สามารถใช้ส่งรายงานไปยังทั้งผู้ซื้อและผู้ขายได้
เซิร์ฟเวอร์ที่เชื่อถือได้ซึ่งจัดการโดยแพลตฟอร์มเทคโนโลยีโฆษณา
ตรรกะการเลือกโฆษณาในปัจจุบันต้องใช้ข้อมูลแบบเรียลไทม์ เช่น สถานะการใช้งบประมาณจนหมด เพื่อตัดสินว่าควรเลือกตัวเลือกโฆษณาเข้าสู่การประมูลหรือไม่ ทั้งแพลตฟอร์มฝั่งซื้อและฝั่งขายจะได้รับข้อมูลนี้จากเซิร์ฟเวอร์ที่ดูแล เพื่อลดการรั่วไหลของข้อมูลที่ละเอียดอ่อนผ่านเซิร์ฟเวอร์เหล่านี้ ข้อเสนอจึงต้องมีข้อจำกัดต่อไปนี้
- ลักษณะการทำงานของเซิร์ฟเวอร์เหล่านี้ (ซึ่งอธิบายไว้ภายหลังในส่วนนี้) จะไม่ทำให้ข้อมูลผู้ใช้รั่วไหล
- เซิร์ฟเวอร์จะไม่สร้างโปรไฟล์ที่ไม่ระบุตัวบุคคลตามข้อมูลที่เห็น เช่น ต้อง "เชื่อถือได้"
ฝั่งซื้อ: เมื่อฝั่งซื้อเริ่มตรรกะการเสนอราคาฝั่งซื้อ แพลตฟอร์มจะดึงข้อมูลการเสนอราคาที่เชื่อถือได้จาก HTTP จากเซิร์ฟเวอร์ URL ดังกล่าวสร้างขึ้นโดยการเพิ่ม URL และคีย์ที่ปรากฏในข้อมูลเมตาของสัญญาณการเสนอราคาที่เชื่อถือได้ของกลุ่มเป้าหมายที่กำหนดเองซึ่งกำลังประมวลผลอยู่ต่อท้าย การดึงข้อมูลนี้จะทําเมื่อประมวลผลโฆษณาจากกลุ่มเป้าหมายที่กำหนดเองในอุปกรณ์เท่านั้น ในขั้นตอนนี้ ฝั่งซื้อสามารถกำหนดงบประมาณ ตรวจสอบสถานะการหยุดชั่วคราว / ยกเลิกการหยุดชั่วคราวแคมเปญ ดำเนินการกำหนดเป้าหมาย ฯลฯ
ด้านล่างนี้คือตัวอย่าง URL สำหรับดึงข้อมูลการเสนอราคาที่เชื่อถือได้ โดยอิงตามข้อมูลเมตาสัญญาณการเสนอราคาที่เชื่อถือได้จากกลุ่มเป้าหมายที่กำหนดเอง
https://www.kv-server.example/getvalues?keys=key1,key2
การตอบกลับจากเซิร์ฟเวอร์ควรเป็นออบเจ็กต์ JSON ซึ่งมีคีย์เป็น key1, key2 เป็นต้น และค่าของค่าที่จะพร้อมใช้งานสำหรับฟังก์ชันการเสนอราคาของผู้ซื้อ
ฝั่งขาย: ฝั่งขายอาจต้องดึงข้อมูลเกี่ยวกับครีเอทีฟโฆษณาที่พิจารณาในการประมูล ซึ่งคล้ายกับขั้นตอนฝั่งซื้อที่ด้านบน ตัวอย่างเช่น ผู้เผยแพร่โฆษณาอาจต้องการบังคับใช้ไม่ให้ครีเอทีฟโฆษณาบางรายการแสดงในแอปของตนโดยอิงตามข้อกังวลด้านความปลอดภัยของแบรนด์ ข้อมูลนี้สามารถดึงมาและนำมาใช้กับตรรกะการประมูลฝั่งขาย เช่นเดียวกับการค้นหาเซิร์ฟเวอร์ที่เชื่อถือได้ฝั่งซื้อ การค้นหาเซิร์ฟเวอร์ที่เชื่อถือได้ฝั่งขายจะเกิดขึ้นผ่านการดึงข้อมูล HTTP ด้วย URL นี้สร้างขึ้นโดยการต่อท้าย URL สัญญาณคะแนนที่เชื่อถือได้ด้วย URL การแสดงผลของครีเอทีฟโฆษณาที่ต้องดึงข้อมูล
ด้านล่างนี้คือตัวอย่าง URL สำหรับดึงข้อมูลเกี่ยวกับครีเอทีฟโฆษณาที่พิจารณาในการประมูล โดยอิงตาม URL ที่แสดงครีเอทีฟโฆษณา
https://www.kv-server.example/getvalues?renderUrls=render_url1,render_url2
การตอบกลับจากเซิร์ฟเวอร์ควรเป็นออบเจ็กต์ JSON ซึ่งมีคีย์แสดงผล URL ที่ส่งในคำขอ
เซิร์ฟเวอร์เหล่านี้จะทำงานในลักษณะที่เชื่อถือได้ เพื่อให้สิทธิประโยชน์ต่างๆ ด้านความปลอดภัยและความเป็นส่วนตัว
- ค่าผลลัพธ์ของเซิร์ฟเวอร์สำหรับแต่ละคีย์เชื่อถือได้ให้อิงตามคีย์นั้นเท่านั้น
- เซิร์ฟเวอร์ไม่ได้บันทึกข้อมูลระดับเหตุการณ์
- เซิร์ฟเวอร์ไม่มีผลข้างเคียงอื่นๆ ตามคำขอเหล่านี้
เนื่องจากเป็นกลไกชั่วคราว ผู้ซื้อและผู้ขายจะดึงข้อมูลสัญญาณการเสนอราคาเหล่านี้จากเซิร์ฟเวอร์ใดก็ได้ รวมถึงเซิร์ฟเวอร์ที่ผู้ใช้ดำเนินการเอง อย่างไรก็ตาม ในเวอร์ชันการเผยแพร่ คำขอจะส่งไปยังเซิร์ฟเวอร์ประเภทคีย์-ค่าที่เชื่อถือได้เท่านั้น
ผู้ซื้อและผู้ขายสามารถใช้เซิร์ฟเวอร์ประเภทคีย์-ค่าที่เชื่อถือได้ทั่วไปสำหรับแพลตฟอร์มที่เข้ากันได้กับ Privacy Sandbox ใน Android และสำหรับเว็บ