อัปเดตล่าสุด
- เพิ่มข้อมูลเกี่ยวกับการตั้งเวลาอัปเดตกลุ่มเป้าหมายที่กำหนดเอง
- เพิ่มการผสานรวม Attribution Reporting กับ Protected Audience
- เผยแพร่ไทม์ไลน์ของฟีเจอร์ Protected Audience
- FLEDGE เปลี่ยนชื่อเป็น Protected Audience API แล้ว
- เพิ่มข้อเสนอสำหรับการมอบสิทธิ์กลุ่มเป้าหมายที่กำหนดเอง
- นำข้อกำหนด k-anonymity สำหรับURL การอัปเดตรายวันออก
Protected Audience อยู่ในเวอร์ชันเบต้าและพร้อมสำหรับการพัฒนา
เมื่อใช้ Protected Audience คุณจะทำสิ่งต่อไปนี้ได้
- จัดการกลุ่มเป้าหมายที่กำหนดเองตามการกระทําของผู้ใช้ก่อนหน้านี้
- เริ่มการประมูลในอุปกรณ์ด้วยการสนับสนุนการไกล่เกลี่ยแบบแหล่งเดียวหรือแบบลำดับ
- ใช้การรายงานการแสดงผลหลังจากการเลือกโฆษณา
โปรดอ่านคู่มือนักพัฒนาซอฟต์แวร์ 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 |
การผสานรวม Attribution Reporting | ไม่มี | ไตรมาส 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 ต่อไปนี้สำหรับแพลตฟอร์มเทคโนโลยีโฆษณาและผู้ลงโฆษณาเพื่อรองรับกรณีการใช้งานทั่วไปที่อิงตามการโต้ตอบในลักษณะที่จำกัดการแชร์ทั้งตัวระบุในแอปต่างๆ และข้อมูลการโต้ตอบในแอปของผู้ใช้กับบุคคลที่สาม
- Custom Audience API: API นี้มุ่งเน้นที่การแยก "กลุ่มเป้าหมายที่กำหนดเอง" ซึ่งแสดงถึงกลุ่มเป้าหมายที่ผู้ลงโฆษณากำหนด ซึ่งมีความตั้งใจร่วมกัน ข้อมูลกลุ่มเป้าหมายจะจัดเก็บไว้ในอุปกรณ์และ เชื่อมโยงกับโฆษณาที่อาจเกี่ยวข้องสำหรับกลุ่มเป้าหมายและข้อมูลเมตาที่กำหนดเอง เช่น สัญญาณการเสนอราคา ข้อมูลนี้สามารถใช้เพื่อแจ้ง ราคาเสนอของผู้ลงโฆษณา การกรองโฆษณา และการแสดงผล
- Ad Selection API: API นี้มีเฟรมเวิร์กที่ จัดระเบียบเวิร์กโฟลว์ของแพลตฟอร์มเทคโนโลยีโฆษณาที่ใช้สัญญาณในอุปกรณ์เพื่อ พิจารณาโฆษณาที่ "ชนะ" โดยพิจารณาโฆษณาผู้สมัครที่จัดเก็บไว้ในเครื่อง และ ทำการประมวลผลเพิ่มเติมกับโฆษณาผู้สมัครที่แพลตฟอร์มเทคโนโลยีโฆษณา ส่งคืนไปยังอุปกรณ์
การผสานรวมจะทำงานดังนี้
SportingGoodsApp ต้องการเตือนผู้ใช้ให้ซื้อสินค้าที่เหลืออยู่ในรถเข็น หากผู้ใช้ยังไม่ได้ทำการซื้อภายใน 2 วัน SportingGoodsApp ใช้ Custom Audience API เพื่อเพิ่มผู้ใช้ลงในรายการกลุ่มเป้าหมาย "ผลิตภัณฑ์ในรถเข็น" แพลตฟอร์มจะจัดการและจัดเก็บรายการกลุ่มเป้าหมายนี้ในอุปกรณ์ ซึ่งจำกัดการแชร์กับบุคคลที่สาม SportingGoodsApp ร่วมมือกับแพลตฟอร์มเทคโนโลยีโฆษณาเพื่อแสดงโฆษณาต่อผู้ใช้ ในรายการกลุ่มเป้าหมาย แพลตฟอร์มเทคโนโลยีโฆษณาจะจัดการข้อมูลเมตาสำหรับกลุ่มเป้าหมาย และแสดงโฆษณาที่เป็นไปได้ ซึ่งจะพร้อมใช้งานในเวิร์กโฟลว์การเลือกโฆษณาเพื่อพิจารณา คุณกำหนดค่าแพลตฟอร์มให้ดึงโฆษณาตามกลุ่มเป้าหมายที่อัปเดตแล้วเป็นระยะๆ ในเบื้องหลังได้ ซึ่งจะช่วยให้รายการโฆษณาที่พิจารณาซึ่งอิงตามกลุ่มเป้าหมายเป็นข้อมูลล่าสุดและไม่เชื่อมโยงกับคำขอที่ส่งไปยังเซิร์ฟเวอร์โฆษณาบุคคลที่สามในระหว่างโอกาสในการแสดงโฆษณา (เช่น คำขอโฆษณาตามบริบท)
เมื่อผู้ใช้เล่น FrisbeeGame ในอุปกรณ์เดียวกัน ผู้ใช้อาจเห็นโฆษณา ที่ช่วยเตือนให้ซื้อสินค้าที่ทิ้งไว้ในรถเข็นช็อปปิ้งของ SportingGoodsApp ให้เสร็จสมบูรณ์ ซึ่งทำได้โดย FrisbeeGame (ที่มี SDK โฆษณาในตัว) เรียกใช้ Ad Selection API เพื่อเลือกโฆษณาที่ชนะ สำหรับผู้ใช้ตามรายการกลุ่มเป้าหมายที่ผู้ใช้อาจเป็นส่วนหนึ่ง (ในตัวอย่างนี้คือกลุ่มเป้าหมายที่กำหนดเอง "ผลิตภัณฑ์ในรถเข็น" ที่สร้างโดย SportingGoodsApp) คุณสามารถตั้งค่าเวิร์กโฟลว์การเลือกโฆษณาให้พิจารณาโฆษณาที่ดึงมาจากเซิร์ฟเวอร์ของแพลตฟอร์ม AdTech นอกเหนือจากโฆษณาในอุปกรณ์ที่เชื่อมโยงกับกลุ่มเป้าหมายที่กำหนดเอง รวมถึงสัญญาณอื่นๆ ในอุปกรณ์ แพลตฟอร์มเทคโนโลยีโฆษณาและ SDK โฆษณายังปรับแต่งเวิร์กโฟลว์ได้ด้วยตรรกะการเสนอราคาและการให้คะแนนที่กำหนดเองเพื่อให้บรรลุเป้าหมายการโฆษณาที่เหมาะสม วิธีนี้ช่วยให้ข้อมูลความสนใจของผู้ใช้หรือการโต้ตอบกับแอปเป็นข้อมูลในการเลือกโฆษณาได้ ขณะเดียวกันก็จำกัดการแชร์ข้อมูลนี้กับบุคคลที่สาม
SDK ของแอปที่แสดงโฆษณาหรือแพลตฟอร์มเทคโนโลยีโฆษณาจะแสดงโฆษณาที่เลือก
แพลตฟอร์มนี้ช่วยให้การรายงานผลการแสดงโฆษณาและผลการเลือกโฆษณาเป็นไปได้ ความสามารถในการรายงานนี้เป็นส่วนเสริมของ Attribution Reporting API แพลตฟอร์มเทคโนโลยีโฆษณาอาจ ปรับแต่งตามความต้องการด้านการรายงาน
รับสิทธิ์เข้าถึง Protected Audience API ใน Android
แพลตฟอร์มเทคโนโลยีโฆษณาต้องลงทะเบียนเพื่อเข้าถึง Protected Audience API ดูข้อมูลเพิ่มเติมได้ที่ ลงทะเบียนบัญชี Privacy Sandbox
การจัดการกลุ่มเป้าหมายที่กำหนดเอง
กลุ่มเป้าหมายที่กำหนดเอง
กลุ่มเป้าหมายที่กำหนดเองแสดงถึงกลุ่มผู้ใช้ตามที่ผู้ลงโฆษณากำหนด โดยมีเจตนาหรือความสนใจร่วมกัน แอปหรือ SDK อาจใช้กลุ่มเป้าหมายที่กำหนดเองเพื่อ ระบุกลุ่มเป้าหมายที่เฉพาะเจาะจง เช่น ผู้ที่ "ทิ้งสินค้าไว้ใน รถเข็นช็อปปิ้ง" หรือ "เล่นเกมจนจบระดับเริ่มต้น" แพลตฟอร์ม จะดูแลและจัดเก็บข้อมูลกลุ่มเป้าหมายไว้ในอุปกรณ์ และจะไม่ เปิดเผยว่าผู้ใช้อยู่ในกลุ่มเป้าหมายที่กำหนดเองใด กลุ่มเป้าหมายที่กำหนดเองแตกต่างจากกลุ่มความสนใจของ Protected Audience ใน Chrome และแชร์ในเว็บและแอปไม่ได้ ซึ่งจะช่วยจำกัดการแชร์ข้อมูลผู้ใช้
แอปของผู้ลงโฆษณาหรือ SDK ที่ผสานรวมอาจเข้าร่วมหรือ ออกจากกลุ่มเป้าหมายที่กำหนดเองโดยอิงตาม เช่น การมีส่วนร่วมของผู้ใช้ในแอป
ข้อมูลเมตาของกลุ่มเป้าหมายที่กำหนดเอง
กลุ่มเป้าหมายที่กำหนดเองแต่ละกลุ่มมีข้อมูลเมตาต่อไปนี้
- เจ้าของ: ชื่อแพ็กเกจของแอปเจ้าของ ระบบจะตั้งค่านี้เป็นชื่อแพ็กเกจของแอปที่เรียกใช้โดยนัย
- ผู้ซื้อ: เครือข่ายโฆษณาของผู้ซื้อที่จัดการโฆษณาสําหรับกลุ่มเป้าหมายที่กําหนดเองนี้ ผู้ซื้อยังเป็นตัวแทนของบุคคลที่อาจเข้าถึงกลุ่มเป้าหมายที่กำหนดเองและดึงข้อมูลโฆษณาที่เกี่ยวข้องได้ด้วย โดยระบุผู้ซื้อตามรูปแบบ 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 ที่ผู้ซื้อเป็นเจ้าของจะตอบกลับด้วยออบเจ็กต์ CustomAudience
JSON
ในเนื้อหาการตอบกลับ ระบบจะละเว้นฟิลด์ผู้ซื้อและเจ้าของของกลุ่มเป้าหมายที่กำหนดเอง (และ 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 หากขนาดเกินขีดจำกัด การเรียกใช้ fetchAndJoinCustomAudience
API จะล้มเหลว
การไม่มีการตรวจสอบ 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);
กลุ่มเป้าหมายที่กำหนดเองจะหมดอายุและถูกนำออกจากร้านค้าในอุปกรณ์หลังจากระยะเวลาที่กำหนดไว้ล่วงหน้า เพื่อช่วยประหยัดการใช้พื้นที่เก็บข้อมูลและทรัพยากรอื่นๆ ของอุปกรณ์ ค่าเริ่มต้นจะกำหนดในภายหลัง เจ้าของจะลบล้างค่าเริ่มต้นนี้ได้
การควบคุมของผู้ใช้
- ข้อเสนอมีจุดประสงค์เพื่อให้ผู้ใช้มองเห็นรายการแอปที่ติดตั้ง ซึ่งสร้างกลุ่มเป้าหมายที่กำหนดเองอย่างน้อย 1 กลุ่ม
- ผู้ใช้สามารถนำแอปออกจากรายการนี้ได้ การนำออกจะล้างกลุ่มเป้าหมายที่กำหนดเองทั้งหมดที่เชื่อมโยงกับแอป และป้องกันไม่ให้แอปเข้าร่วมกลุ่มเป้าหมายที่กำหนดเองใหม่
- ผู้ใช้สามารถรีเซ็ต Protected Audience API ได้อย่างสมบูรณ์ เมื่อเกิดกรณีนี้ ระบบจะล้างข้อมูลกลุ่มเป้าหมายที่กำหนดเองที่มีอยู่ในอุปกรณ์
- ผู้ใช้สามารถเลือกไม่ใช้ Privacy Sandbox ใน Android ได้ทั้งหมด ซึ่งรวมถึง Protected Audience API หากผู้ใช้เลือกไม่ใช้ Privacy Sandbox แล้ว Protected Audience API จะทำงานล้มเหลวโดยไม่มีข้อความแจ้ง
การออกแบบความสามารถนี้อยู่ระหว่างดำเนินการ และรายละเอียดจะรวมอยู่ในการอัปเดตในภายหลัง
อัปเดตตามกำหนดการ
โซลูชันที่อธิบายไว้ก่อนหน้านี้กำหนดให้แอปหรือ SDK เทคโนโลยีโฆษณาเรียกใช้ API ขณะที่แอปทำงานอยู่เบื้องหน้า และระบุพร็อพเพอร์ตี้ทั้งหมดของกลุ่มเป้าหมายที่กำหนดเอง ไม่ว่าจะโดยตรงหรือใช้การมอบสิทธิ์ อย่างไรก็ตาม ผู้ลงโฆษณาและผู้ให้บริการเทคโนโลยีโฆษณาไม่สามารถระบุได้เสมอไปว่าผู้ใช้เป็นสมาชิกของกลุ่มเป้าหมายใดในแบบเรียลไทม์ขณะที่ใช้แอป
เพื่ออำนวยความสะดวกในเรื่องนี้ เทคโนโลยีโฆษณาสามารถเรียกใช้
scheduleCustomAudienceUpdate()
API ได้ API นี้ช่วยให้ผู้เรียกสามารถระบุ
การหน่วงเวลาเมื่อควรเรียกใช้ API ได้ จึงมีเวลาเพิ่มเติม
ให้เทคโนโลยีโฆษณาที่ตอบกลับประมวลผลเหตุการณ์ระดับแอป และพิจารณาว่าผู้ใช้ควรเข้าร่วมหรือนำออกจาก
กลุ่มเป้าหมายที่ปกป้องใด
/**
* API To schedule delayed update events for Custom Audience
*
* @param request Criteria that determine when and where to trigger a call to a
* DSP endpoint to update one or more Custom Audiences
*/
public void scheduleCustomAudienceUpdate(
@NonNull ScheduleCustomAudienceUpdateRequest request,
@NonNull @CallBackExecutor Executor executor,
@NonNull AdServicesOutcomeReceiver<Object, Exception> receiver)
ScheduleCustomAudienceUpdateRequest
public final class ScheduleCustomAudienceUpdateRequest {
// Required Field
@NonNull public Uri getUpdateUri() {
return mUpdateUri;
}
// Required Field
@NonNull public Duration getMinDelay() {
return mMinDelay;
}
// Required Field
@NonNull public List<PartialCustomAudience> getPartialCustomAudienceList() {
return mPartialCustomAudiences;
}
// Optional Field (default false)
public boolean shouldReplacePendingUpdates () {
return mShouldReplacePendingUpdates;
}
}
ScheduleCustomAudienceUpdateRequest
มีข้อมูลที่จำเป็นสำหรับการลงทะเบียนงานที่ล่าช้าเพื่อเรียกใช้กับแพลตฟอร์ม หลังจากผ่านไปตามระยะเวลาหน่วงที่ระบุ
งานในเบื้องหลังจะทำงานเป็นระยะๆ และส่งคำขอ ScheduleCustomAudienceUpdateRequest
อาจมีข้อมูลต่อไปนี้
- UpdateUri: ปลายทาง URI ที่จะส่งการเรียก GET เพื่อดึงข้อมูลอัปเดต
ระบบจะอนุมานตัวตนของผู้ซื้อจาก eTLD+1 โดยไม่ต้องระบุอย่างชัดเจน และการตอบกลับการอัปเดตจะเปลี่ยนแปลงตัวตนของผู้ซื้อไม่ได้ คำขอ GET
คาดหวังออบเจ็กต์ JSON ที่มีรายการออบเจ็กต์
customAudience
ใน การตอบกลับ - DelayTime: เวลาที่แสดงถึงความล่าช้าตั้งแต่เวลาที่ทำการเรียก API
scheduleCustomAudienceUpdate()
เพื่อกำหนดเวลาการอัปเดต
PartialCustomAudience: API ยังอนุญาตให้ SDK บนอุปกรณ์ส่งรายการ ของกลุ่มเป้าหมายที่กำหนดเองที่สร้างขึ้นบางส่วนได้ด้วย ซึ่งจะช่วยให้ SDK ในแอปทำหน้าที่ ได้ 2 อย่าง ตั้งแต่การควบคุมการจัดการกลุ่มเป้าหมายที่กำหนดเองทั้งหมดไปจนถึงการควบคุมบางส่วน โดยอิงตามการเป็นพาร์ทเนอร์กับ DSP
- นอกจากนี้ ยังช่วยให้ API นี้ใช้ร่วมกับ
fetchAndJoinCustomAudience()
API ซึ่งอนุญาตให้แชร์ข้อมูลที่คล้ายกันได้
- นอกจากนี้ ยังช่วยให้ API นี้ใช้ร่วมกับ
ShouldReplacePendingUpdates: บูลีนที่กำหนดว่าจะยกเลิกและแทนที่การอัปเดตที่กำหนดเวลาไว้ ซึ่งรอดำเนินการด้วยการอัปเดตที่มีรายละเอียดใน
ScheduleCustomAudienceUpdateRequest
ปัจจุบันหรือไม่ หากตั้งค่าเป็นfalse
และ มีการอัปเดตที่ขอไว้ก่อนหน้านี้ซึ่งยังคงรอดำเนินการสำหรับผู้ซื้อรายเดียวกันใน แอปเดียวกัน การเรียกใช้scheduleCustomAudienceUpdate
ที่มีScheduleCustomAudienceUpdateRequest
นี้จะล้มเหลว ค่าเริ่มต้นคือfalse
สิทธิ์และการควบคุมของแอป
ข้อเสนอมีจุดประสงค์เพื่อให้แอปควบคุมกลุ่มเป้าหมายที่กำหนดเองได้ ดังนี้
- แอปสามารถจัดการการเชื่อมโยงกับกลุ่มเป้าหมายที่กำหนดเองได้
- แอปสามารถให้สิทธิ์แพลตฟอร์มเทคโนโลยีโฆษณาของบุคคลที่สามในการจัดการกลุ่มเป้าหมายที่กำหนดเองในนามของแอปได้
การออกแบบความสามารถนี้อยู่ระหว่างดำเนินการ และรายละเอียดจะรวมอยู่ในการอัปเดตในภายหลัง
การควบคุมแพลตฟอร์มเทคโนโลยีโฆษณา
ข้อเสนอนี้ระบุวิธีที่เทคโนโลยีโฆษณาสามารถควบคุมกลุ่มเป้าหมายที่กำหนดเองได้ ดังนี้
- เทคโนโลยีโฆษณาลงทะเบียนกับ Privacy Sandbox และระบุโดเมน eTLD+1 ซึ่ง ตรงกับ URL ทั้งหมดของกลุ่มเป้าหมายที่กำหนดเอง
- เทคโนโลยีโฆษณาสามารถเป็นพาร์ทเนอร์กับแอปหรือ SDK เพื่อจัดหาโทเค็นการยืนยันที่ใช้เพื่อยืนยันการสร้างกลุ่มเป้าหมายที่กำหนดเองได้ เมื่อมอบหมายกระบวนการนี้ให้ พาร์ทเนอร์ คุณจะกำหนดค่าการสร้างกลุ่มเป้าหมายที่กำหนดเองให้ต้องมีการรับทราบ โดยเทคโนโลยีโฆษณาได้
- เทคโนโลยีโฆษณาสามารถเลือกปิดใช้งานการเรียก
joinCustomAudience
ในนามของตน และอนุญาตให้เฉพาะ API ของfetchAndJoinCustomAudience
เท่านั้นที่เปิดใช้กลุ่มเป้าหมายตามการเรียกที่กำหนดเองทั้งหมดได้ คุณอัปเดตการควบคุมได้ในระหว่างการลงทะเบียน 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
สำหรับโฆษณาที่กำหนด
นอกจากนี้ แพลตฟอร์มฝั่งซื้อจะสามารถส่งสัญญาณว่าควรกรองโฆษณาหนึ่งๆ ตามสัญญาณเพิ่มเติมในอุปกรณ์ที่พร้อมใช้งานสำหรับ 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 ปลายทางที่กำหนดค่าได้และเรียกใช้ในอุปกรณ์ เนื่องจากข้อจำกัดด้านทรัพยากรในอุปกรณ์เคลื่อนที่ โค้ดการประมูลควรเป็นไปตามหลักเกณฑ์ต่อไปนี้
- โค้ดควรดำเนินการให้เสร็จภายในระยะเวลาที่กำหนดไว้ล่วงหน้า ขอบเขตนี้ จะมีผลกับเครือข่ายโฆษณาของผู้ซื้อทั้งหมดอย่างสม่ำเสมอ รายละเอียดของขอบเขตนี้จะ แชร์ในการอัปเดตในภายหลัง
- โค้ดต้องมีทุกอย่างครบสมบูรณ์และไม่มีการอ้างอิงภายนอก
เนื่องจากโค้ดการประมูล เช่น ตรรกะการเสนอราคา อาจต้องเข้าถึงข้อมูลส่วนตัวของผู้ใช้ เช่น แหล่งที่มาของการติดตั้งแอป รันไทม์จึงไม่ให้สิทธิ์เข้าถึงเครือข่ายหรือ พื้นที่เก็บข้อมูล
ภาษาโปรแกรม
โค้ดการประมูลที่แพลตฟอร์มเทคโนโลยีโฆษณามอบให้ควรเขียนใน JavaScript ซึ่งจะช่วยให้แพลตฟอร์มเทคโนโลยีโฆษณาสามารถแชร์โค้ดการเสนอราคาในแพลตฟอร์มที่รองรับ Privacy Sandbox เป็นต้น
การแสดงโฆษณาที่ชนะ
โฆษณาที่มีคะแนนสูงสุดถือเป็นผู้ชนะในการประมูล ใน ข้อเสนอเริ่มต้นนี้ ระบบจะส่งโฆษณาที่ชนะไปยัง SDK เพื่อแสดงผล
แผนของเราคือการพัฒนาโซลูชันเพื่อยืนยันว่าแอปหรือ SDK ไม่สามารถระบุข้อมูลเกี่ยวกับการเป็นสมาชิกกลุ่มเป้าหมายที่กำหนดเองของผู้ใช้หรือประวัติการมีส่วนร่วมกับแอปได้ผ่านข้อมูลเกี่ยวกับโฆษณาที่ชนะ (คล้ายกับข้อเสนอเฟรมที่แยกของ Chrome)
การรายงานการแสดงผลและเหตุการณ์
เมื่อแสดงผลโฆษณาแล้ว ระบบจะรายงานการแสดงผลที่ชนะกลับไปยังแพลตฟอร์มฝั่งผู้ซื้อและฝั่งผู้ขายที่เข้าร่วมได้ ซึ่งจะช่วยให้ผู้ซื้อและผู้ขาย สามารถรวมข้อมูลจากการประมูล เช่น ชื่อราคาเสนอหรือกลุ่มเป้าหมายที่กำหนดเอง ไว้ในรายงานการแสดงผลที่ชนะได้ นอกจากนี้ แพลตฟอร์มฝั่งขายและแพลตฟอร์มฝั่งซื้อที่ชนะยังมีสิทธิ์รับการรายงานระดับเหตุการณ์เพิ่มเติมเกี่ยวกับโฆษณาที่ชนะด้วย ซึ่งช่วยให้คุณสามารถรวมข้อมูล เกี่ยวกับการประมูล (ราคาเสนอ ชื่อกลุ่มเป้าหมายที่กำหนดเอง ฯลฯ) ไว้กับการคลิก การดู และเหตุการณ์โฆษณาอื่นๆ แพลตฟอร์มจะเรียกใช้ตรรกะการรายงานตามลำดับต่อไปนี้
- การรายงานฝั่งผู้ขาย
- การรายงานฝั่งซื้อ
ซึ่งจะช่วยให้แพลตฟอร์มฝั่งซื้อและฝั่งขายมีวิธีส่งข้อมูลสำคัญในอุปกรณ์กลับไปยังเซิร์ฟเวอร์เพื่อเปิดใช้ความสามารถต่างๆ เช่น การกำหนดงบประมาณแบบเรียลไทม์ การอัปเดตรูปแบบการเสนอราคา และเวิร์กโฟลว์การเรียกเก็บเงินที่ถูกต้อง การรองรับการรายงานการแสดงผลนี้ เป็นการเสริม Attribution Reporting API
ต้องมี 2 ขั้นตอนเพื่อรองรับการรายงานเหตุการณ์ ได้แก่ ฝั่งผู้ขายและฝั่งผู้ซื้อ JavaScript ต้องลงทะเบียนเหตุการณ์ที่ควรรับรายงานเหตุการณ์ และ ฝั่งผู้ขายมีหน้าที่รับผิดชอบในการรายงานข้อมูลระดับเหตุการณ์
Protected Audience มีกลไกในการติดตามกิจกรรมในอนาคตที่เกี่ยวข้องกับ
การประมูลที่ชนะโดยการลงทะเบียนบีคอน ในreportResult()
ฟังก์ชัน JavaScript ของผู้ขาย แพลตฟอร์มฝั่งผู้ขายจะลงทะเบียนบีคอนได้โดยใช้ฟังก์ชัน registerAdBeacon()
ของแพลตฟอร์ม ในทำนองเดียวกัน แพลตฟอร์มฝั่งซื้อสามารถเรียกใช้เมธอด registerAdBeacon()
จากฟังก์ชัน JavaScript reportWin()
ได้
registerAdBeacon(beacons)
อินพุต:
event_key
: สตริงที่ระบุประเภทการโต้ตอบที่จะลงทะเบียน โดยใช้เป็นคีย์ในการค้นหาปลายทางที่แพลตฟอร์มจะ Ping ขณะรายงานผลการประมูลreporting_url
: URL ที่แพลตฟอร์มเทคโนโลยีโฆษณาเป็นเจ้าของเพื่อจัดการเหตุการณ์
คีย์เหตุการณ์คือตัวระบุสตริงที่เป็นของ SDK ฝั่งผู้ขาย
ซึ่งรับผิดชอบในการรายงานผลการประมูล หากต้องการให้มีการเรียกกลับ
เทคโนโลยีโฆษณาจะต้องลงทะเบียนบีคอนด้วยคีย์ที่ตรงกับคีย์ที่ฝั่งผู้ขายใช้
เมื่อรายงานเหตุการณ์ โดยไม่จำเป็นต้องเป็นแบบ k-anonymous แต่มีขีดจำกัดด้านปริมาณและความยาวของคีย์ที่ลงทะเบียนได้สำหรับกลุ่มเป้าหมายที่กำหนดเองที่เฉพาะเจาะจง หากมีการเรียกใช้ 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
คือเอาต์พุตของ sell-side reportResult ซึ่งจะช่วยให้แพลตฟอร์มฝั่งขายมีโอกาสแชร์ข้อมูลกับแพลตฟอร์มฝั่งซื้อเพื่อวัตถุประสงค์ในการรายงาน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
และแพลตฟอร์มจะพยายามจับคู่ event_key
กับคีย์ที่ผู้ซื้อและผู้ขายลงทะเบียนไว้ในฟังก์ชัน reportWin
และ reportResult
JavaScript ทั้งนี้ขึ้นอยู่กับแฟล็ก
reporting_destinations
หากตรงกัน แพลตฟอร์มจะ POST
event_data
ไปยัง reporting_url
ที่เชื่อมโยง content type
ของคำขอ
เป็นข้อความธรรมดาโดยมีเนื้อหาเป็น event_data
คำขอนี้จะดำเนินการอย่างเต็มที่
และจะล้มเหลวโดยไม่มีการแจ้งเตือนในกรณีที่เกิดข้อผิดพลาดเกี่ยวกับเครือข่าย การตอบกลับข้อผิดพลาดเกี่ยวกับเซิร์ฟเวอร์
หรือหากไม่พบคีย์ที่ตรงกัน
การผสานรวม Attribution Reporting API
เราจะมอบฟังก์ชันการทำงานข้าม API ใน Protected Audience API และ Attribution Reporting API (ARA) เพื่อรองรับผู้ซื้อที่เข้าร่วมการประมูล Protected Audience ฟังก์ชันนี้ช่วยให้เทคโนโลยีโฆษณาสามารถประเมิน ประสิทธิภาพการระบุแหล่งที่มาในกลยุทธ์รีมาร์เก็ตติ้งต่างๆ เพื่อให้เข้าใจว่ากลุ่มเป้าหมายประเภทใดที่ให้ ROI สูงสุด
การผสานรวมข้าม API นี้ช่วยให้เทคโนโลยีโฆษณาสามารถทำสิ่งต่อไปนี้ได้
- สร้างแผนที่คีย์-ค่าของ URI ที่จะใช้สำหรับทั้ง 1) การรายงานการโต้ตอบกับโฆษณาและ 2) การลงทะเบียนแหล่งที่มา
- รวมข้อมูลการประมูลจาก Protected Audience Auction ไว้ในการแมปคีย์ฝั่งแหล่งที่มาสําหรับการรายงานสรุปรวม (โดยใช้ Attribution Reporting API) ดูข้อมูลเพิ่มเติมได้ที่ข้อเสนอการออกแบบ ARA
เมื่อผู้ใช้เห็นหรือคลิกโฆษณา
- URL ที่ใช้ในการรายงานการโต้ตอบเหตุการณ์เหล่านั้นโดยใช้ Protected Audience จะ ให้ข้อมูลที่จำเป็นแก่ผู้ซื้อเพื่อใช้ลงทะเบียนการดูหรือการคลิก เป็นแหล่งที่มาที่มีสิทธิ์ด้วย Attribution Reporting API
- เทคโนโลยีโฆษณาอาจเลือกส่ง
CustomAudience
(หรือข้อมูลตามบริบทอื่นๆ ที่เกี่ยวข้อง เกี่ยวกับโฆษณา เช่น ตําแหน่งโฆษณาหรือระยะเวลาการดู) โดยใช้ URL นั้น เพื่อให้ข้อมูลเมตานี้สามารถส่งต่อไปยังรายงานสรุปได้เมื่อเทคโนโลยีโฆษณากําลัง ตรวจสอบประสิทธิภาพของแคมเปญแบบรวม
การเปิดใช้การลงทะเบียนแหล่งที่มา
reportEvent()
จะยอมรับพารามิเตอร์ที่ไม่บังคับรายการใหม่ InputEvent
ผู้ซื้อที่ชนะ
ซึ่งลงทะเบียนบีคอนโฆษณาจะเลือกได้ว่ารายงานเหตุการณ์ใดจะได้รับการ
ลงทะเบียนกับ Attribution Reporting API เป็นแหล่งที่มาที่ลงทะเบียน ระบบจะเพิ่มส่วนหัว Attribution-Reporting-Eligible ของคำขอ
ไปยังคำขอการรายงานเหตุการณ์ทั้งหมด
ที่ส่งจาก reportEvent()
ระบบจะแยกวิเคราะห์การตอบกลับที่มีส่วนหัว ARA ที่เหมาะสม
ในลักษณะเดียวกับการตอบกลับการลงทะเบียนแหล่งที่มาของ ARA ปกติอื่นๆ
ดูคำอธิบาย Attribution Reporting API เพื่อดูวิธีลงทะเบียน URL แหล่งที่มา
เนื่องจาก ARA ใน Android รองรับเหตุการณ์การดูและการคลิก จึงมีการใช้ InputEvents
เพื่อแยกความแตกต่างระหว่างเหตุการณ์ 2 ประเภท เช่นเดียวกับการลงทะเบียนแหล่งที่มาของ ARA reportEvent()
API จะตีความ InputEvent
ที่แพลตฟอร์มยืนยันแล้ว
ว่าเป็นเหตุการณ์คลิก หากไม่มี InputEvent
เป็นค่าว่าง หรือไม่ถูกต้อง
ระบบจะถือว่าการลงทะเบียนแหล่งที่มาเป็นการดู
โปรดทราบว่า eventData
หลังการประมูลอาจมีข้อมูลที่มีความละเอียดอ่อน ดังนั้นแพลตฟอร์มจึงทิ้ง eventData
ในคำขอลงทะเบียนแหล่งที่มาที่เปลี่ยนเส้นทาง
ตัวอย่างการรายงานการมีส่วนร่วมและ Conversion
ในตัวอย่างนี้ เราจะพิจารณาจากมุมมองของผู้ซื้อที่สนใจ ในการเชื่อมโยงข้อมูลจากการประมูล โฆษณาที่แสดง และแอป Conversion เข้าด้วยกัน
ในเวิร์กโฟลว์นี้ ผู้ซื้อจะประสานงานกับผู้ขายเพื่อส่งรหัสที่ไม่ซ้ำกันไปยัง การประมูล ในระหว่างการประมูล ผู้ซื้อจะส่งรหัสที่ไม่ซ้ำกันนี้พร้อม ข้อมูลการประมูล ในระหว่างเวลาการแสดงผลและเวลา Conversion ระบบจะส่งข้อมูลจากโฆษณาที่แสดงผล พร้อมกับรหัสที่ไม่ซ้ำกันเดียวกันด้วย ต่อมา คุณจะใช้รหัสที่ไม่ซ้ำกันเพื่อ เชื่อมโยงรายงานเหล่านี้เข้าด้วยกันได้
เวิร์กโฟลว์
ก่อนที่การประมูลจะเริ่มขึ้น ผู้ซื้อจะส่งรหัสที่ไม่ซ้ำกันไปยังผู้ขายเป็นส่วนหนึ่งของการตอบกลับราคาเสนอในการเสนอราคาแบบเรียลไทม์ ("RTB") แบบเป็นโปรแกรม โดยตั้งค่ารหัสเป็นตัวแปรได้ เช่น auctionId
ระบบจะส่งรหัสเป็น perBuyerSignals
ใน auctionConfig
และรหัสจะพร้อมใช้งานในตรรกะการเสนอราคาของผู้ซื้อ
- ในระหว่างการดำเนินการของ
reportWin
ผู้ซื้อสามารถลงทะเบียนบีคอนโฆษณาเพื่อ ทริกเกอร์ในระหว่างเวลาการแสดงโฆษณาและสำหรับเหตุการณ์การโต้ตอบที่เฉพาะเจาะจง (registerAdBeacon()
) หากต้องการเชื่อมโยงสัญญาณการประมูลสำหรับเหตุการณ์โฆษณา ให้ตั้งค่าauctionId
เป็นพารามิเตอร์การค้นหาของ URL บีคอน - ในระหว่างเวลาการแสดงโฆษณา บีคอนที่คุณลงทะเบียนไว้ในระหว่างเวลาการประมูลจะ
ทริกเกอร์หรือได้รับการปรับปรุงด้วยข้อมูลระดับเหตุการณ์ ผู้ขายต้องทริกเกอร์
reportEvent()
และส่งข้อมูลระดับเหตุการณ์ แพลตฟอร์มจะ Ping URL บีคอนโฆษณาที่ลงทะเบียนของผู้ซื้อซึ่งสัมพันธ์กับreportEvent()
ที่ทริกเกอร์ - ผู้ซื้อจะลงทะเบียนโฆษณากับ Attribution Reporting API โดย
ตอบกลับคำขอ Beacon โฆษณาด้วย
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, etc. และมีค่าที่พร้อมใช้งานสำหรับฟังก์ชันการเสนอราคาของผู้ซื้อ
ฝั่งผู้ขาย: เช่นเดียวกับขั้นตอนฝั่งผู้ซื้อนี้ ฝั่งผู้ขายอาจต้องการดึงข้อมูลเกี่ยวกับครีเอทีฟโฆษณาที่พิจารณาในการประมูล ตัวอย่างเช่น ผู้เผยแพร่โฆษณา อาจต้องการบังคับไม่ให้แสดงครีเอทีฟโฆษณาบางรายการในแอปของตนโดยอิงตาม ข้อกังวลด้านความปลอดภัยของแบรนด์ ระบบจะดึงข้อมูลนี้และทำให้พร้อมใช้งานสำหรับ ตรรกะการประมูลฝั่งผู้ขาย การค้นหาเซิร์ฟเวอร์ที่เชื่อถือได้ฝั่งขายจะเกิดขึ้นโดยใช้การดึงข้อมูล HTTP เช่นเดียวกับการค้นหาเซิร์ฟเวอร์ที่เชื่อถือได้ฝั่งซื้อ URL ประกอบด้วยการต่อท้าย URL ของสัญญาณการให้คะแนนที่เชื่อถือได้ด้วย URL การแสดงผลของครีเอทีฟโฆษณา ซึ่งต้องดึงข้อมูล
ต่อไปนี้คือตัวอย่าง URL ที่ใช้ดึงข้อมูลเกี่ยวกับครีเอทีฟโฆษณาที่พิจารณาในการประมูลตาม URL การแสดงผลครีเอทีฟโฆษณา
https://www.kv-server.example/getvalues?renderUrls=render_url1,render_url2
การตอบกลับจากเซิร์ฟเวอร์ควรเป็นออบเจ็กต์ JSON ที่มีคีย์เป็น URL การแสดงผล ที่ส่งในคำขอ
เซิร์ฟเวอร์เหล่านี้จะทำงานในลักษณะที่เชื่อถือได้เพื่อมอบประโยชน์ด้านความปลอดภัยและความเป็นส่วนตัวหลายประการ ดังนี้
- ค่าที่เซิร์ฟเวอร์ส่งคืนสำหรับแต่ละคีย์จะเชื่อถือได้ว่าอิงตามคีย์นั้นเท่านั้น
- เซิร์ฟเวอร์ไม่ได้ทำการบันทึกระดับเหตุการณ์
- เซิร์ฟเวอร์ไม่มีผลข้างเคียงอื่นๆ ตามคำขอเหล่านี้
ผู้ซื้อและผู้ขายสามารถดึงสัญญาณการเสนอราคาเหล่านี้จากเซิร์ฟเวอร์ใดก็ได้ รวมถึงเซิร์ฟเวอร์ที่ดำเนินการด้วยตนเอง ซึ่งเป็นกลไกชั่วคราว อย่างไรก็ตาม ในเวอร์ชันที่เผยแพร่ ระบบจะส่งคำขอไปยังเซิร์ฟเวอร์ประเภทคีย์-ค่าที่เชื่อถือได้เท่านั้น
ผู้ซื้อและผู้ขายสามารถใช้เซิร์ฟเวอร์ประเภทคีย์-ค่าที่เชื่อถือได้ร่วมกันสำหรับ แพลตฟอร์มที่เข้ากันได้กับ Privacy Sandbox ใน Android และสำหรับเว็บ