รองรับการกำหนดกลุ่มเป้าหมายที่กำหนดเองด้วย Protected Audience API

แสดงความคิดเห็น

อัปเดตล่าสุด

• เพิ่มข้อมูลเกี่ยวกับการกำหนดเวลาอัปเดตกลุ่มเป้าหมายที่กำหนดเอง
• เพิ่มการผสานรวมการรายงานการระบุแหล่งที่มากับกลุ่มเป้าหมายที่มีการป้องกัน
• เผยแพร่ไทม์ไลน์ของฟีเจอร์ Protected Audience
• FLEDGE เปลี่ยนชื่อเป็น Protected Audience API แล้ว
• เพิ่มข้อเสนอสำหรับการมอบสิทธิ์กลุ่มเป้าหมายที่กำหนดเอง
• นำข้อกำหนด k-anonymity สำหรับ URL อัปเดตรายวันออกแล้ว

Protected Audience อยู่ในเวอร์ชันเบต้าและพร้อมสำหรับการทดสอบในอุปกรณ์สาธารณะแล้ว

Protected Audience ช่วยให้คุณทำสิ่งต่อไปนี้ได้

• จัดการกลุ่มเป้าหมายที่กำหนดเองตามการกระทำของผู้ใช้ก่อนหน้านี้
• เริ่มการประมูลในอุปกรณ์ด้วยการรองรับการแสดงโฆษณาสื่อกลางตามลำดับขั้น (Waterfall Mediation) หรือผู้ขายรายเดียว
• รายงานการแสดงผลทดสอบหลังการเลือกโฆษณา

หากต้องการเริ่มต้นใช้งาน โปรดอ่านคู่มือนักพัฒนาซอฟต์แวร์สำหรับ 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 ต่อไปนี้สำหรับแพลตฟอร์มเทคโนโลยีโฆษณาและผู้ลงโฆษณาเพื่อรองรับกรณีการใช้งานทั่วไปที่อิงตามการโต้ตอบในลักษณะที่จำกัดการแชร์ตัวระบุทั้งในแอปและข้อมูลการโต้ตอบของผู้ใช้กับบุคคลที่สาม

1. Custom Audience API: มีศูนย์กลางอยู่ที่กระบวนการนามธรรม "กลุ่มเป้าหมายที่กำหนดเอง" ซึ่งเป็นกลุ่มเป้าหมายที่ผู้ลงโฆษณากำหนดไว้และมีเจตนาร่วมกัน ระบบจะเก็บข้อมูลกลุ่มเป้าหมายไว้ในอุปกรณ์และสามารถเชื่อมโยงกับโฆษณาผู้สมัครที่เกี่ยวข้องสำหรับกลุ่มเป้าหมาย รวมถึงข้อมูลเมตาที่กำหนดเอง เช่น สัญญาณการเสนอราคา ข้อมูลนี้สามารถใช้เพื่อแจ้งการเสนอราคาของผู้ลงโฆษณา การกรองโฆษณา และการแสดงผล
2. Ad Selection API: มอบเฟรมเวิร์กที่ดูแลจัดการเวิร์กโฟลว์ของแพลตฟอร์มเทคโนโลยีโฆษณาที่ใช้ประโยชน์จากสัญญาณในอุปกรณ์เพื่อระบุโฆษณาที่ "ชนะ" โดยพิจารณาโฆษณาที่เป็นคู่แข่งที่จัดเก็บไว้ในเครื่อง และดำเนินการประมวลผลเพิ่มเติมสำหรับโฆษณาที่แพลตฟอร์มเทคโนโลยีโฆษณาส่งกลับไปยังอุปกรณ์

ในระดับสูง การผสานรวมจะทำงานดังนี้

1. SportingGoodsApp ต้องการเตือนให้ผู้ใช้ซื้อสินค้าที่ใส่ในรถเข็น หากยังซื้อไม่เสร็จภายใน 2 วัน SportingGoodsApp ใช้ Custom Audience API เพื่อเพิ่มผู้ใช้ลงในรายการกลุ่มเป้าหมาย "ผลิตภัณฑ์ในรถเข็น" แพลตฟอร์มจะจัดการและจัดเก็บรายการกลุ่มเป้าหมายนี้ไว้ในอุปกรณ์โดยจำกัดการแชร์กับบุคคลที่สาม SportingGoodsApp ร่วมมือกับแพลตฟอร์มเทคโนโลยีโฆษณาเพื่อแสดงโฆษณาให้แก่ผู้ใช้ในรายการกลุ่มเป้าหมาย แพลตฟอร์มเทคโนโลยีโฆษณาจะจัดการข้อมูลเมตาสำหรับรายการกลุ่มเป้าหมายและเสนอโฆษณาที่ต้องการ ซึ่งจะพร้อมใช้งานสำหรับเวิร์กโฟลว์การเลือกโฆษณา โดยจะกำหนดค่าแพลตฟอร์มให้ดึงข้อมูลโฆษณาตามกลุ่มเป้าหมายที่อัปเดตเป็นระยะๆ ในเบื้องหลัง วิธีนี้จะช่วยให้รายการโฆษณาผู้สมัครตามกลุ่มเป้าหมายมีความสดใหม่ และไม่เกี่ยวข้องกับคำขอที่ส่งไปยังเซิร์ฟเวอร์โฆษณาบุคคลที่สามในระหว่างการสร้างโอกาสในการแสดงโฆษณา (เช่น คำขอโฆษณาตามบริบท)

2. เมื่อผู้ใช้เล่น FrisbeeGame บนอุปกรณ์เดียวกัน ก็อาจเห็นโฆษณาที่เตือนผู้ใช้ให้ซื้อสินค้าที่เหลืออยู่ในรถเข็นช็อปปิ้งของ SportingGoodsApp ซึ่งทำได้ด้วย FrisbeeGame (ที่มี SDK โฆษณาที่ผสานรวม) ที่เรียกใช้ Ad Selection API เพื่อเลือกโฆษณาที่ชนะให้กับผู้ใช้ตามรายการกลุ่มเป้าหมายที่ผู้ใช้อาจอยู่ (ในตัวอย่างนี้คือกลุ่มเป้าหมายที่กำหนดเอง "ผลิตภัณฑ์ในรถเข็น" ที่สร้างโดย SportingGoodsApp) คุณตั้งค่าเวิร์กโฟลว์การเลือกโฆษณาให้พิจารณาโฆษณาที่ดึงมาจากเซิร์ฟเวอร์ของแพลตฟอร์มเทคโนโลยีโฆษณาได้ นอกเหนือจากโฆษณาในอุปกรณ์ที่เชื่อมโยงกับกลุ่มเป้าหมายที่กำหนดเอง รวมถึงสัญญาณอื่นๆ ในอุปกรณ์ นอกจากนี้ แพลตฟอร์มเทคโนโลยีโฆษณาและ SDK โฆษณายังปรับแต่งเวิร์กโฟลว์ได้ด้วยตรรกะการเสนอราคาที่กำหนดเองและการให้คะแนน เพื่อให้บรรลุเป้าหมายการโฆษณาที่เหมาะสม แนวทางนี้ช่วยให้ข้อมูลการโต้ตอบของผู้ใช้หรือความสนใจของผู้ใช้มีข้อมูลในการเลือกโฆษณา ขณะที่จำกัดการแชร์ข้อมูลนี้กับบุคคลที่สาม

3. SDK ของแอปการแสดงโฆษณาหรือแพลตฟอร์มเทคโนโลยีโฆษณาจะแสดงโฆษณาที่เลือก

4. แพลตฟอร์มนี้ช่วยให้รายงานการแสดงผลและผลการเลือกโฆษณา ความสามารถในการรายงานนี้เป็นส่วนเสริมของ Attribution Reporting API แพลตฟอร์มเทคโนโลยีโฆษณาอาจ ปรับแต่งตามความต้องการในการรายงาน

รับสิทธิ์เข้าถึง Protected Audience ใน Android API

แพลตฟอร์มเทคโนโลยีโฆษณาต้องลงทะเบียนเพื่อเข้าถึง Protected Audience API โปรดดูข้อมูลเพิ่มเติมที่ลงทะเบียนบัญชี Privacy Sandbox

การจัดการกลุ่มเป้าหมายที่กำหนดเอง

กลุ่มเป้าหมายที่กำหนดเอง

กลุ่มเป้าหมายที่กําหนดเองหมายถึงกลุ่มผู้ใช้ตามที่กำหนดโดยผู้ลงโฆษณาที่มีความตั้งใจหรือความสนใจร่วมกัน แอปหรือ SDK อาจใช้กลุ่มเป้าหมายที่กำหนดเองเพื่อระบุกลุ่มเป้าหมายที่เจาะจง เช่น ผู้ที่ "ทิ้งของลงในรถเข็นช็อปปิ้ง" หรือ "ผ่านระดับผู้เริ่มต้น" ของเกม แพลตฟอร์มจะดูแลรักษาและจัดเก็บข้อมูลกลุ่มเป้าหมายไว้ในอุปกรณ์และไม่แสดงกลุ่มเป้าหมายที่กำหนดเองของผู้ใช้ กลุ่มเป้าหมายที่กำหนดเองแตกต่างจากกลุ่มเป้าหมายที่ใช้ Protected Audience API ของ 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 จะใช้งานไม่ได้โดยไม่มีการแจ้งเตือน

ความสามารถนี้อยู่ระหว่างการออกแบบ และรายละเอียดจะอยู่ในการอัปเดตในภายหลัง

อัปเดตตามกำหนดการ

โซลูชันที่อธิบายไว้ก่อนหน้านี้กำหนดให้ SDK เทคโนโลยีโฆษณาหรือ SDK เรียกใช้ API ในขณะที่แอปทำงานอยู่เบื้องหน้า และมอบพร็อพเพอร์ตี้ทั้งหมดของกลุ่มเป้าหมายที่กำหนดเอง ไม่ว่าจะโดยตรงหรือใช้การมอบสิทธิ์ อย่างไรก็ตาม ผู้ลงโฆษณาและผู้ให้บริการเทคโนโลยีโฆษณาไม่สามารถกำหนดกลุ่มเป้าหมายที่ผู้ใช้อยู่แบบเรียลไทม์ในขณะที่ใช้แอปไม่ได้เสมอไป

เทคโนโลยีโฆษณาจะเรียกใช้ scheduleCustomAudienceUpdate() API ได้เพื่อช่วยอำนวยความสะดวกในเรื่องนี้ โดย API นี้ทำให้ผู้เรียกใช้ระบุการหน่วงเวลาที่ควรเรียก API ได้ ดังนั้นจึงให้เวลาเพิ่มเติมเพื่อให้เทคโนโลยีโฆษณาที่ตอบสนองประมวลผลเหตุการณ์ระดับแอปได้ และกำหนดว่าผู้ใช้ควรเข้าร่วมหรือนำออกจากกลุ่มเป้าหมายที่มีการป้องกันกลุ่มใด

/**
* API To schedule delayed update events for Custom Audience
*
* @param delayedCustomUpdates List of Delayed Update events that trigger a
* call to DSP endpoint provided inside the DelayedCustomUpdate object
*/

public void scheduleCustomAudienceUpdates(
    @NonNull DelayedCustomUpdate delayedCustomAudienceUpdate,
    @NonNull @CallBackExecutor Executor executor,
    @NonNull AdServicesOutcomeReceiver<Object, Exception> receiver)

DelayedCustomAudienceUpdate

public final class DelayedCustomAudienceUpdate {
    // Required Field
    @NonNull public Uri getUpdateUri() {
    return mUpdateUri;
  }

    // Required Field
    @NonNull public Duration getMinDelay() {
    return mMinDelay;
  }

    //  Required Field
    @NonNull public List<PartialCustomAudience> getPartialCustomAudiences() {
    return mPartialCustomAudiences;
  }
}

DelayedCustomAudienceUpdate มีข้อมูลที่จำเป็นสำหรับการลงทะเบียนงานที่ล่าช้าเพื่อเรียกใช้แพลตฟอร์ม หลังจากล่าช้าที่ระบุไว้ งานพื้นหลังจะทำงานเป็นระยะๆ และส่งคำขอ DelayedCustomAudienceUpdate อาจมีข้อมูลต่อไปนี้

• UpdateUri: อุปกรณ์ปลายทาง URI ที่จะส่งการเรียก GET เพื่อดึงข้อมูลการอัปเดต ข้อมูลประจำตัวของผู้ซื้อจะสรุปจาก eTLD+1 อย่างชัดแจ้ง และไม่จำเป็นต้องระบุไว้อย่างชัดแจ้ง และไม่สามารถเปลี่ยนแปลงได้จากการตอบกลับการอัปเดต คำขอ GET ต้องการออบเจ็กต์ JSON ที่มีรายการออบเจ็กต์ customAudience กลับมา
• DelayTime: เวลาที่แสดงถึงความล่าช้าจากเวลาที่เรียก API ของ scheduleCustomAudienceUpdate() เพื่อกำหนดเวลาการอัปเดต

• PartialCustomAudience: API ยังอนุญาตให้ SDK ในอุปกรณ์ส่งรายการกลุ่มเป้าหมายที่กำหนดเองที่สร้างขึ้นบางส่วนด้วย วิธีนี้ช่วยให้ SDK ในแอปสามารถใช้บทบาทคู่ได้ ตั้งแต่การควบคุมการจัดการกลุ่มเป้าหมายที่กำหนดเองโดยสมบูรณ์ไปจนถึงการควบคุมบางส่วนโดยอิงตามการเป็นพาร์ทเนอร์ทางธุรกิจกับ DSP

  • เพื่อให้ API นี้เข้ากันได้กับ fetchAndJoinCustomAudience() API ที่ช่วยให้แชร์ข้อมูลในลักษณะคล้ายกันได้ด้วย

สิทธิ์และการควบคุมแอป

ข้อเสนอนี้มีจุดประสงค์ให้แอปควบคุมกลุ่มเป้าหมายที่กำหนดเองของตน

• แอปสามารถจัดการการเชื่อมโยงกับกลุ่มเป้าหมายที่กำหนดเอง
• แอปสามารถให้สิทธิ์แพลตฟอร์มเทคโนโลยีโฆษณาของบุคคลที่สามเพื่อจัดการกลุ่มเป้าหมายที่กำหนดเองในนามของแอปได้

ความสามารถนี้อยู่ระหว่างการออกแบบ และรายละเอียดจะอยู่ในการอัปเดตในภายหลัง

การควบคุมแพลตฟอร์มเทคโนโลยีโฆษณา

ข้อเสนอนี้ระบุวิธีที่เทคโนโลยีโฆษณาจะใช้ควบคุมกลุ่มเป้าหมายที่กำหนดเองได้ ดังนี้

• เทคโนโลยีโฆษณาจะลงทะเบียนด้วย Privacy Sandbox และระบุโดเมน eTLD+1 ที่ตรงกับ URL ทั้งหมดสำหรับกลุ่มเป้าหมายที่กำหนดเอง
• เทคโนโลยีโฆษณาสามารถเป็นพาร์ทเนอร์กับแอปหรือ SDK เพื่อมอบโทเค็นการยืนยันที่ใช้เพื่อยืนยันการสร้างกลุ่มเป้าหมายที่กำหนดเอง เมื่อมอบสิทธิ์กระบวนการนี้ให้กับพาร์ทเนอร์ คุณจะกำหนดค่าการสร้างกลุ่มเป้าหมายที่กำหนดเองเพื่อให้เทคโนโลยีโฆษณารับทราบได้
• เทคโนโลยีโฆษณาสามารถเลือกที่จะปิดใช้งานการเรียก joinCustomAudience ในนามของของตน และอนุญาตให้ fetchAndJoinCustomAudience API เปิดใช้กลุ่มเป้าหมายที่กำหนดเองการโทรทั้งหมดเท่านั้น คุณอัปเดตการควบคุมได้ระหว่างการลงทะเบียน Privacy Sandbox โปรดทราบว่าการควบคุมอนุญาตเทคโนโลยีโฆษณาทั้งหมดหรือไม่อนุญาตเลย เนื่องจากข้อจำกัดของแพลตฟอร์ม สิทธิ์ในการมอบอำนาจจะแตกต่างกันไปตามเทคโนโลยีโฆษณา

ตัวเลือกโฆษณาและการตอบกลับข้อมูลเมตา

โฆษณาผู้สมัครและข้อมูลเมตาที่แสดงผลจากแพลตฟอร์มฝั่งซื้อควรมีช่องต่อไปนี้

• ข้อมูลเมตา: ข้อมูลเมตาของโฆษณาเฉพาะด้านเทคโนโลยีฝั่งผู้ซื้อ ตัวอย่างเช่น ข้อมูลนี้อาจมีข้อมูลเกี่ยวกับแคมเปญโฆษณาและเกณฑ์การกำหนดเป้าหมาย เช่น สถานที่ตั้งและภาษา
• URL การแสดงผล: ปลายทางสำหรับการแสดงครีเอทีฟโฆษณา
• ตัวกรอง: ข้อมูลเสริมที่จำเป็นสำหรับ Protected Audience API เพื่อกรองโฆษณาตามข้อมูลในอุปกรณ์ อ่านรายละเอียดเพิ่มเติมได้ที่ส่วนตรรกะการกรองฝั่งซื้อ

เวิร์กโฟลว์การเลือกโฆษณา

ข้อเสนอนี้มีเป้าหมายที่จะปรับปรุงความเป็นส่วนตัวโดยการเปิดตัว Ad Selection API ซึ่งดูแลจัดการการดำเนินการประมูลสำหรับแพลตฟอร์มเทคโนโลยีโฆษณา

แพลตฟอร์มเทคโนโลยีโฆษณาปัจจุบันมักจะทำการเสนอราคาและการเลือกโฆษณาเฉพาะในเซิร์ฟเวอร์ของตน ในข้อเสนอนี้ กลุ่มเป้าหมายที่กำหนดเองและสัญญาณอื่นๆ ที่มีความละเอียดอ่อนของผู้ใช้ เช่น ข้อมูลแพ็กเกจที่ติดตั้งไว้ จะเข้าถึงได้ผ่าน Ad Selection API เท่านั้น นอกจากนี้ สำหรับตัวเลือก Use Case รีมาร์เก็ตติ้ง ระบบจะดึงโฆษณานอกขอบเขต (กล่าวคือ ไม่ใช่ในบริบทที่โฆษณาจะแสดง) แพลตฟอร์มเทคโนโลยีโฆษณาจะต้องเตรียมบางส่วนของการประมูลและตรรกะการเลือกโฆษณาปัจจุบันไปใช้งานและดำเนินการในอุปกรณ์ แพลตฟอร์มเทคโนโลยีโฆษณาอาจพิจารณาการเปลี่ยนแปลงต่อไปนี้ในเวิร์กโฟลว์การเลือกโฆษณา

• หากไม่มีข้อมูลแพ็กเกจที่ติดตั้งไว้ในเซิร์ฟเวอร์ แพลตฟอร์มเทคโนโลยีโฆษณาอาจต้องการส่งโฆษณาตามบริบทหลายรายการกลับไปยังอุปกรณ์ รวมถึงเรียกใช้เวิร์กโฟลว์การเลือกโฆษณาเพื่อเปิดใช้การกรองตามการติดตั้งแอปเพื่อเพิ่มโอกาสในการแสดงโฆษณาที่เกี่ยวข้องให้ได้สูงสุด
• เนื่องจากโฆษณารีมาร์เก็ตติ้งถูกดึงออกจากช่วงสัญญาณแล้ว คุณจึงอาจต้องอัปเดตรูปแบบการเสนอราคาปัจจุบัน แพลตฟอร์มเทคโนโลยีโฆษณาอาจต้องการสร้างรูปแบบย่อยการเสนอราคา (การใช้งานอาจอิงตามรูปแบบที่เรียกว่าโมเดล 2 หอคอย) ซึ่งทำงานกับฟีเจอร์โฆษณาและสัญญาณบริบทแยกกันได้ และรวมเอาต์พุตของโมเดลย่อยในอุปกรณ์เพื่อคาดการณ์ราคาเสนอ ซึ่งจะได้ประโยชน์จากทั้งการประมูลฝั่งเซิร์ฟเวอร์และการประมูลสำหรับโอกาสในการโฆษณาแต่ละครั้ง

แนวทางนี้ช่วยให้ข้อมูลการโต้ตอบในแอปของผู้ใช้เป็นข้อมูลในการเลือกโฆษณา ในขณะเดียวกันก็จำกัดการแชร์ข้อมูลนี้กับบุคคลที่สาม

เวิร์กโฟลว์การเลือกโฆษณานี้จัดการโค้ด JavaScript จากเทคโนโลยีโฆษณาในอุปกรณ์ตามลำดับต่อไปนี้

1. การดำเนินการตรรกะการเสนอราคาฝั่งผู้ซื้อ
2. การกรองและประมวลผลโฆษณาฝั่งผู้ซื้อ
3. การดำเนินการตรรกะการตัดสินใจฝั่งขาย

สำหรับการเลือกโฆษณาที่เกี่ยวข้องกับกลุ่มเป้าหมายที่กำหนดเอง แพลตฟอร์มจะดึงข้อมูลซื้อโค้ด 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 สำหรับโฆษณาหนึ่งๆ

นอกจากนี้ แพลตฟอร์มฝั่งซื้อจะส่งสัญญาณได้ว่าควรกรองโฆษณาหนึ่งๆ ตามสัญญาณเพิ่มเติมในอุปกรณ์ที่ Protected Audience มีให้ใช้งานได้และไม่ได้ออกจากอุปกรณ์ เมื่อเราเสริมสร้างการออกแบบตรรกะการกรองเพิ่มเติม แพลตฟอร์มฝั่งซื้อจะยึดตามโครงสร้างเดียวกันนี้ เพื่อเป็นสัญญาณให้ทราบว่าการกรองควรเกิดขึ้นจริง

ตรรกะการให้คะแนนฝั่งขาย

ตรรกะการให้คะแนนมักจะมาจากแพลตฟอร์มฝั่งขาย จุดประสงค์ของโค้ดนี้คือการพิจารณาโฆษณาที่ชนะตามเอาต์พุตตรรกะการเสนอราคา และอาจนำตรรกะทางธุรกิจเพิ่มเติมมาใช้เพื่อระบุผลลัพธ์ หากมีผู้ให้บริการตรรกะการตัดสินใจหลายรายการ ระบบจะไม่รับประกันลำดับการดำเนินการในผู้ให้บริการเหล่านั้น แพลตฟอร์มจะใช้พารามิเตอร์อินพุต "URL ตรรกะการตัดสินใจ" ของ selectAds() API เพื่อดึงโค้ด 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 เพื่อการแสดงผล

เรามีแผนที่จะพัฒนาโซลูชันขึ้นมาเพื่อให้มั่นใจว่าข้อมูลเกี่ยวกับการเป็นสมาชิกกลุ่มเป้าหมายที่กำหนดเองหรือประวัติการมีส่วนร่วมในแอปของผู้ใช้จะระบุผ่านข้อมูลเกี่ยวกับโฆษณาที่ชนะ (คล้ายกับข้อเสนอเฟรมที่มีการปิดกั้น) ของ Chrome ไม่ได้

การรายงานการแสดงผลและเหตุการณ์

เมื่อมีการแสดงโฆษณา การแสดงผลที่ชนะจะสามารถรายงานกลับไปยังแพลตฟอร์มฝั่งซื้อและฝั่งขายที่เข้าร่วมได้ วิธีนี้ช่วยให้ผู้ซื้อและผู้ขายรวมข้อมูลจากการประมูล เช่น ราคาเสนอหรือชื่อกลุ่มเป้าหมายที่กำหนดเอง ไว้ในรายงานการแสดงผลที่ชนะได้ นอกจากนี้ แพลตฟอร์มฝั่งขายและที่ชนะการประมูลยังมีสิทธิ์ได้รับการรายงานระดับเหตุการณ์เพิ่มเติมเกี่ยวกับโฆษณาที่ชนะด้วย ซึ่งจะช่วยให้คุณใส่ข้อมูลเกี่ยวกับการประมูล (ราคาเสนอ ชื่อกลุ่มเป้าหมายที่กำหนดเอง ฯลฯ) กับจำนวนคลิก การดู และเหตุการณ์โฆษณาอื่นๆ ได้ แพลตฟอร์มจะเรียกใช้ตรรกะการรายงานตามลำดับต่อไปนี้

1. การรายงานฝั่งขาย
2. การรายงานฝั่งผู้ซื้อ

วิธีนี้ทำให้แพลตฟอร์มฝั่งซื้อและฝั่งขายสามารถส่งข้อมูลสำคัญในอุปกรณ์กลับไปยังเซิร์ฟเวอร์เพื่อเพิ่มความสามารถต่างๆ เช่น การจัดทำงบประมาณแบบเรียลไทม์ การอัปเดตรูปแบบการเสนอราคา และเวิร์กโฟลว์การเรียกเก็บเงินที่แม่นยำ การรองรับการรายงานการแสดงผลนี้เป็นส่วนเสริมของ Attribution Reporting API

การรองรับการรายงานเหตุการณ์มี 2 ขั้นตอน ได้แก่ JavaScript ฝั่งขายและฝั่งซื้อ JavaScript ต้องลงทะเบียนเหตุการณ์ที่ควรได้รับรายงานเหตุการณ์ และฝั่งการขายมีหน้าที่รายงานข้อมูลระดับเหตุการณ์

Protected Audience มอบกลไกในการติดตามเหตุการณ์ในอนาคตที่เกี่ยวข้องกับการประมูลที่ชนะด้วยการลงทะเบียนบีคอน ในฟังก์ชัน JavaScript reportResult() ของผู้ขาย แพลตฟอร์มฝั่งขายจะลงทะเบียนบีคอนได้โดยใช้ฟังก์ชัน registerAdBeacon() ของแพลตฟอร์ม ในทำนองเดียวกัน แพลตฟอร์มฝั่งซื้อจะเรียกใช้เมธอด registerAdBeacon() จากฟังก์ชัน JavaScript reportWin() ได้

registerAdBeacon(beacons)

อินพุต:

• event_key: สตริงที่ระบุประเภทการโต้ตอบที่ควรลงทะเบียน ซึ่งใช้เป็นคีย์ในการค้นหาจุดสิ้นสุดที่ใช้คำสั่ง ping ของแพลตฟอร์มในขณะที่รายงานผลการประมูล
• reporting_url: URL ที่เป็นของแพลตฟอร์มเทคโนโลยีโฆษณาที่ใช้จัดการเหตุการณ์

คีย์เหตุการณ์คือตัวระบุสตริงที่เป็นของ SDK ฝั่งขายซึ่งมีหน้าที่รายงานผลลัพธ์ของการประมูล เพื่อให้การเรียกกลับได้ เทคโนโลยีโฆษณาจะลงทะเบียนบีคอนกับคีย์ที่ตรงกับคีย์ที่ฝั่งขายใช้เมื่อรายงานเหตุการณ์ โดยไม่จำเป็นต้องเป็น k-anonymous แม้จะมีขีดจำกัดเกี่ยวกับจำนวนและความยาวของคีย์ที่ลงทะเบียนสำหรับกลุ่มเป้าหมายที่กำหนดเองได้ หากมีการเรียก reportEvent() แพลตฟอร์มฝั่งขายที่ดำเนินการการประมูลจะมีสิทธิ์รับรายงานเหตุการณ์เหล่านี้เสมอ เฉพาะแพลตฟอร์มฝั่งซื้อเท่านั้นที่จะมีสิทธิ์ได้รับรายงานเหล่านี้

การรายงานฝั่งผู้ขาย

แพลตฟอร์มจะเรียกใช้ฟังก์ชัน JavaScript reportResult() ในโค้ดที่ได้จากฝั่งซื้อซึ่งดาวน์โหลดจากพารามิเตอร์ The Decision Logic 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 การแสดงโฆษณา
• ราคาเสนอที่ชนะ
• ชื่อแอป
• ตัวระบุการค้นหา
• สัญญาณสำหรับผู้ซื้อ: แพลตฟอร์มจะส่งค่าการแสดงผลนี้เป็นพารามิเตอร์อินพุตไปยังโค้ดการรายงานฝั่งดีมานด์เพื่อรองรับการแชร์ข้อมูลระหว่างฝั่งซัพพลายและฝั่งดีมานด์

การรายงานฝั่งผู้ซื้อ

แพลตฟอร์มจะเรียกใช้ฟังก์ชัน JavaScript reportWin() ในโค้ดที่ได้จากฝั่งดีมานด์ ซึ่งดาวน์โหลดจากข้อมูลเมตาของ 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ผลลัพธ์ ของฝั่งผู้ขาย ซึ่งจะเปิดโอกาสให้แพลตฟอร์มฝั่งขายมีโอกาสแชร์ข้อมูลกับแพลตฟอร์มฝั่งซื้อเพื่อวัตถุประสงค์ในการรายงาน
• contextual_signals มีข้อมูลอย่างเช่นชื่อแอป และ custom_audience_signals มีข้อมูลกลุ่มเป้าหมายที่กำหนดเอง อาจมีการเพิ่มข้อมูลอื่นๆ ในอนาคต

เอาต์พุต:

• สถานะ: 0 สำหรับสำเร็จ ค่าอื่นๆ สำหรับความล้มเหลว
• URL การรายงาน: แพลตฟอร์มจะเรียก URL นี้ที่แสดงผลจากฟังก์ชัน

เหตุการณ์การรายงาน

คุณจะรายงานเหตุการณ์ได้หลังจากการรายงานการแสดงผลสำหรับการประมูลเสร็จสมบูรณ์แล้วเท่านั้น SDK ฝั่งขายมีหน้าที่รายงานเหตุการณ์ต่างๆ แพลตฟอร์มจะแสดง API ที่ใช้ ReportEventRequest ที่ระบุการประมูลที่เรียกใช้ล่าสุด คีย์เหตุการณ์ที่รายงาน ข้อมูลที่เชื่อมโยงกับคีย์นั้น ควรส่งรายงานไปยังผู้ซื้อหรือผู้ขาย (หรือทั้ง 2 อย่าง) และเหตุการณ์อินพุตที่ไม่บังคับสำหรับเหตุการณ์โฆษณา ไคลเอ็นต์จะกำหนดคีย์เหตุการณ์และการรวบรวมข้อมูลที่จะรายงาน

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 ของการประมูลที่ดำเนินการเมื่อเร็วๆ นี้ซึ่งดึงมาจาก AdSelectionOutcome
• event_key เป็นสตริงที่กำหนดด้านการขายซึ่งอธิบายเหตุการณ์การโต้ตอบ
• event_data คือสตริงที่แสดงข้อมูลที่เชื่อมโยงกับ event_key
• reporting_destinations เป็นมาสก์เล็กน้อยที่ตั้งค่าโดยใช้แฟล็กที่แพลตฟอร์มมีให้ ซึ่งอาจเป็น FLAG_REPORTING_DESTINATION_SELLER หรือ FLAG_REPORTING_DESTINATION_BUYER หรือทั้ง 2 อย่างก็ได้
• input_event (ไม่บังคับ) ใช้สำหรับการผสานรวมกับ Attribution Reporting API อาจเป็นออบเจ็กต์ InputEvent (สำหรับเหตุการณ์การคลิก) หรือ Null (สำหรับเหตุการณ์การดู) ดูรายละเอียดเพิ่มเติมเกี่ยวกับพารามิเตอร์นี้ได้ในการผสานรวม Attribution Reporting API

หลังจากที่ SDK ฝั่งขายเรียกใช้ reportEvent และขึ้นอยู่กับแฟล็ก reporting_destinations แพลตฟอร์มจะพยายามจับคู่ event_key กับคีย์ที่ผู้ซื้อและผู้ขายลงทะเบียนในฟังก์ชัน JavaScript reportWin และ reportResult หากมีการจับคู่ที่ตรงกัน แพลตฟอร์มจะโพสต์ event_data ไปยัง reporting_url ที่เชื่อมโยง ประเภทเนื้อหาของคำขอเป็นข้อความธรรมดาที่มีเนื้อหาเป็น event_data เราใช้คำขอนี้อย่างดีที่สุดและล้มเหลวโดยไม่มีการแจ้งเตือนในกรณีที่เครือข่ายเกิดข้อผิดพลาด การตอบกลับจากข้อผิดพลาดเกี่ยวกับเซิร์ฟเวอร์ หรือเมื่อไม่พบคีย์ที่ตรงกัน

การผสานรวม Attribution Reporting API

เพื่อสนับสนุนผู้ซื้อที่เข้าร่วมการประมูลที่ใช้ Protected Audience API เราจะให้บริการฟังก์ชันแบบข้าม API ใน Protected Audience และ Attribution Reporting API (ARA) ฟังก์ชันการทำงานนี้ทำให้เทคโนโลยีโฆษณาสามารถประเมินประสิทธิภาพการระบุแหล่งที่มาในกลยุทธ์รีมาร์เก็ตติ้งต่างๆ เพื่อให้เข้าใจกลุ่มเป้าหมายประเภทที่ให้ ROI สูงสุด

การผสานรวมข้าม API นี้ทำให้ AdTech ทำสิ่งต่อไปนี้ได้

• สร้างแผนที่คีย์-ค่าของ URI เพื่อใช้สำหรับทั้ง 1) การรายงานการโต้ตอบกับโฆษณาและ 2) การลงทะเบียนแหล่งที่มา
• รวมข้อมูลการประมูลจากการประมูลที่ใช้ Protected Audience API ไว้ในการแมปคีย์ฝั่งแหล่งที่มาสำหรับการรายงานสรุปรวม (โดยใช้ 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 เพื่อแยกความแตกต่างระหว่างเหตุการณ์ 2 ประเภทนี้ โดย reportEvent() API จะตีความ InputEvent ที่ได้รับการยืนยันตามแพลตฟอร์มเป็นเหตุการณ์การคลิก เช่นเดียวกับในการลงทะเบียนแหล่งที่มาของ ARA หาก InputEvent ขาดหายไป ไม่มีข้อมูล หรือไม่ถูกต้อง ระบบจะถือว่าการลงทะเบียนแหล่งที่มานั้นเป็นการดู

โปรดทราบว่า eventData หลังการประมูลอาจมีข้อมูลที่ละเอียดอ่อน แพลตฟอร์มจึงจะลด eventData ในคำขอการลงทะเบียนต้นทางที่เปลี่ยนเส้นทาง

ตัวอย่างการรายงาน Conversion และการมีส่วนร่วม

ในตัวอย่างนี้ เราจะมองจากมุมมองของผู้ซื้อที่สนใจในการเชื่อมโยงข้อมูลจากการประมูล โฆษณาที่แสดง และแอป Conversion เข้าด้วยกัน

ในเวิร์กโฟลว์นี้ ผู้ซื้อจะประสานงานกับผู้ขายเพื่อส่งรหัสที่ไม่ซ้ำกันเข้าร่วมการประมูล ในระหว่างการประมูล ผู้ซื้อจะส่งรหัสที่ไม่ซ้ำกันนี้พร้อมกับข้อมูลการประมูล ในระหว่างการแสดงผลและเวลาเกิด Conversion ข้อมูลจากโฆษณาที่แสดงผลจะส่งออกไปโดยมีรหัสที่ไม่ซ้ำกันเหมือนกัน จากนั้นจะใช้รหัสที่ไม่ซ้ำกันเพื่อเชื่อมโยงรายงานเหล่านี้เข้าด้วยกัน

ขั้นตอนการทำงาน: ก่อนที่การประมูลจะเริ่มขึ้น ผู้ซื้อจะส่งรหัสที่ไม่ซ้ำกันให้กับผู้ขาย ซึ่งเป็นส่วนหนึ่งของการเสนอราคาตอบแบบเรียลไทม์ ("RTB") แบบเป็นโปรแกรม สามารถตั้งรหัสเป็นตัวแปร เช่น auctionId ส่งรหัสเป็น perBuyerSignals ใน auctionConfig และจะใช้ได้ในตรรกะการเสนอราคาของผู้ซื้อ

1. ในระหว่างการเรียกใช้ reportWin ผู้ซื้อสามารถลงทะเบียนบีคอนโฆษณาเพื่อทริกเกอร์ในระหว่างเวลาในการแสดงโฆษณาและสำหรับเหตุการณ์การโต้ตอบที่เฉพาะเจาะจง (registerAdBeacon()) หากต้องการเชื่อมโยงสัญญาณการประมูลสำหรับเหตุการณ์โฆษณา ให้ตั้งค่า auctionId เป็นพารามิเตอร์การค้นหาของ URL บีคอน
2. ในระหว่างระยะเวลาแสดงโฆษณา บีคอนที่ลงทะเบียนไว้ในระหว่างการประมูลจะเรียกใช้หรือเพิ่มประสิทธิภาพด้วยข้อมูลระดับเหตุการณ์ได้ ผู้ขายต้องทริกเกอร์ reportEvent() และส่งผ่านข้อมูลระดับเหตุการณ์ แพลตฟอร์มจะใช้คำสั่ง ping กับ URL บีคอนของโฆษณาที่ลงทะเบียนไว้ของผู้ซื้อซึ่งสัมพันธ์กับ reportEvent() ที่มีการทริกเกอร์
3. ผู้ซื้อจะลงทะเบียนโฆษณากับ 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 ซึ่งมีคีย์เป็นคีย์ 1, คีย์ 2 ฯลฯ และค่าที่จะใช้ได้กับฟังก์ชันการเสนอราคาของผู้ซื้อ

ฝั่งขาย: ฝั่งขายอาจต้องการดึงข้อมูลเกี่ยวกับครีเอทีฟโฆษณาที่นำมาพิจารณาในการประมูล ซึ่งคล้ายกับขั้นตอนฝั่งซื้อข้างต้น ตัวอย่างเช่น ผู้เผยแพร่โฆษณาอาจต้องการบังคับใช้ไม่ให้แสดงครีเอทีฟโฆษณาบางรายการในแอปของตนตามข้อกังวลด้านความปลอดภัยของแบรนด์ ซึ่งสามารถดึงข้อมูลและนำมาใช้กับตรรกะการประมูลฝั่งขายได้ เช่นเดียวกับการค้นหาเซิร์ฟเวอร์ที่เชื่อถือได้ฝั่งซื้อ การค้นหาเซิร์ฟเวอร์ที่เชื่อถือได้ฝั่งขายจะเกิดขึ้นผ่านการดึงข้อมูล HTTP เช่นกัน URL สร้างขึ้นโดยการเพิ่ม URL สัญญาณการให้คะแนนที่เชื่อถือได้ต่อท้าย URL ที่แสดงผลของครีเอทีฟโฆษณาที่ต้องการดึงข้อมูล

ด้านล่างนี้คือตัวอย่าง URL สำหรับดึงข้อมูลเกี่ยวกับครีเอทีฟโฆษณาที่พิจารณาในการประมูลตาม URL การแสดงผลครีเอทีฟโฆษณา

https://www.kv-server.example/getvalues?renderUrls=render_url1,render_url2

การตอบสนองจากเซิร์ฟเวอร์ควรเป็นออบเจ็กต์ JSON ที่มีคีย์เป็น URL การแสดงผลที่ส่งในคำขอ

เซิร์ฟเวอร์เหล่านี้จะทำงานด้วยวิธีที่เชื่อถือได้เพื่อให้ประโยชน์ด้านความปลอดภัยและความเป็นส่วนตัวหลายประการดังนี้

• ค่าการแสดงผลของเซิร์ฟเวอร์สำหรับแต่ละคีย์สามารถเชื่อถือได้ว่าอิงตามคีย์นั้นเท่านั้น
• เซิร์ฟเวอร์ไม่บันทึกระดับเหตุการณ์
• เซิร์ฟเวอร์ไม่มีผลข้างเคียงอื่นๆ ตามคำขอเหล่านี้

กลไกชั่วคราวนี้ทำให้ผู้ซื้อและผู้ขายสามารถดึงข้อมูลสัญญาณการเสนอราคาเหล่านี้จากเซิร์ฟเวอร์ใดก็ได้ รวมถึงเซิร์ฟเวอร์ที่ดำเนินการด้วยตนเองด้วย อย่างไรก็ตาม ในเวอร์ชันที่เผยแพร่ คำขอจะส่งไปยังเซิร์ฟเวอร์ประเภทคีย์-ค่าที่เชื่อถือเท่านั้น

ผู้ซื้อและผู้ขายสามารถใช้เซิร์ฟเวอร์ประเภทคีย์-ค่าที่เชื่อถือได้ทั่วไปสำหรับแพลตฟอร์มที่เข้ากันได้กับ Privacy Sandbox ใน Android และสำหรับเว็บ