ปรับปรุงเวลาในการตอบสนองในการประมูลของ Protected Audience API

การตรวจสอบว่า Protected Audience API ทำงานอย่างมีประสิทธิภาพเป็นสิ่งที่ทุกคนให้ความสำคัญ

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

เอกสารนี้สรุปแนวทางปฏิบัติแนะนำสำหรับการใช้งาน Protected Audience API เพื่อให้มั่นใจว่าเว็บไซต์ของคุณทำงานได้อย่างมีประสิทธิภาพสูงสุด

แนวทางปฏิบัติแนะนำสำหรับผู้ซื้อ (ผู้เสนอราคา)

โปรดทำตามแนวทางปฏิบัติแนะนำต่อไปนี้เพื่อเพิ่มประสิทธิภาพการประมูล Protected Audience API

ลดจำนวนเจ้าของกลุ่มความสนใจ

เพื่อปกป้องผู้เสนอราคา Protected Audience API เช่นเดียวกับที่เบราว์เซอร์ปกป้องต้นทางต่างๆ ในเว็บโดยใช้การแยกเว็บไซต์ เบราว์เซอร์จะใช้ทรัพยากรราคาแพง (เช่น กระบวนการของระบบปฏิบัติการ) เพื่อปกป้องเจ้าของกลุ่มความสนใจแต่ละราย

ในการลดรายจ่ายของทรัพยากรที่มีราคาแพงมากเหล่านี้ การมีเจ้าของกลุ่มความสนใจให้มีจำนวนน้อยที่สุดนั้นเป็นสิ่งสำคัญอย่างยิ่ง หลีกเลี่ยงการมีกลุ่มความสนใจที่แตกต่างกัน ที่เป็นของโดเมนย่อยหลายรายการ เช่น หาก adtech.example มีกลุ่มความสนใจที่เป็นของ cats.adtech.example และ dogs.adtech.example เบราว์เซอร์ก็น่าจะใช้กระบวนการ 2 อย่างในการเรียกใช้สคริปต์การเสนอราคา

การเสนอราคาตามกลุ่มความสนใจน้อยลง

เบราว์เซอร์ต้องตั้งค่าและเตรียมการที่สำคัญก่อนเรียกใช้สคริปต์ generateBid() ของผู้ซื้อ เช่น การตั้งค่าสภาพแวดล้อมการดำเนินการ JavaScript แบบใหม่ที่ปลอดภัย รวมถึงการแยกวิเคราะห์และโหลดโค้ด generateBid()

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

กรองกลุ่มความสนใจออกจากการเสนอราคาในบริการจัดการคีย์/มูลค่า

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

ใช้สภาพแวดล้อมการดำเนินการ JavaScript ซ้ำ

เบราว์เซอร์ต้องเริ่มต้นสภาพแวดล้อมการดำเนินการ JavaScript ใหม่ก่อน จึงจะเรียกใช้ generateBid() ได้ การดำเนินการนี้อาจใช้เวลานานพอสมควรเมื่อเทียบกับระยะเวลาที่ generateBid() ใช้ในการดำเนินการได้ คุณประหยัดเวลานี้ได้โดยใช้โหมดการดำเนินการแบบกลุ่มตามต้นทางหรือโหมดที่ตรึงบริบท

โหมด group-by-origin นําสภาพแวดล้อมการดําเนินการมาใช้ซ้ำได้ในกรณีที่มีการเข้าร่วมกลุ่มความสนใจบนต้นทางเดียวกัน และมักจะไม่จําเป็นต้องเปลี่ยนแปลงสคริปต์การเสนอราคา หากต้องการดูข้อมูลเพิ่มเติม โปรดดูคําอธิบาย group-by-origin ในข้อความอธิบาย โหมดบริบทที่หยุดนิ่งจะนำสภาพแวดล้อมการดำเนินการทั้งหมดที่เป็นไปได้มาใช้ซ้ำได้ แต่อาจต้องมีการเปลี่ยนแปลงสคริปต์การเสนอราคา ดูข้อมูลเพิ่มเติมได้ในคำอธิบาย frozen-context ในวิดีโออธิบาย

ใช้สคริปต์การเสนอราคาซ้ำ

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

ใช้ trustedBiddingSignalsUrls ซ้ำ

เวลาในการตอบสนองของเครือข่ายและการใช้ทรัพยากรอาจสูงมาก การดึงข้อมูลสัญญาณการเสนอราคาแบบเรียลไทม์ที่เชื่อถือได้น้อยลงจะช่วยลดเวลาในการตอบสนองนี้ได้

ระบบจะรวมการดึงข้อมูลสัญญาณการเสนอราคาที่เชื่อถือได้ไว้ด้วยกันเมื่อมีการนำ trustedBiddingSignalsUrl มาใช้ซ้ำในกลุ่มความสนใจหลายกลุ่ม หากเป็นไปได้ ให้ใช้ trustedBiddingSignalsUrl เดียวกันสำหรับกลุ่มความสนใจทั้งหมด

ระบุส่วนหัวการควบคุมแคช HTTP ที่เหมาะสมเพื่อให้ระบบแคชการดึงข้อมูลสัญญาณการเสนอราคาที่เชื่อถือได้ในช่องโฆษณาในหน้าเว็บหนึ่งๆ หลีกเลี่ยงการตั้งค่า trustedBiddingSignalsSlotSizeMode เป็น slot-size เนื่องจากจะป้องกันไม่ให้มีการแคชในช่องโฆษณาเมื่อขนาดของช่องโฆษณาแตกต่างกัน เนื่องจาก URL ที่ขอนั้นแตกต่างกัน

การดึงข้อมูลสัญญาณการเสนอราคาแบบเรียลไทม์ที่เชื่อถือได้ขนาดเล็กลง

เวลาในการตอบสนองของเครือข่ายอาจมีความสำคัญมาก และจะมีผลกระทบโดยตรงจากจำนวนการโอนข้อมูลระหว่างการดึงข้อมูลสัญญาณการเสนอราคาที่เชื่อถือได้แบบเรียลไทม์

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

คุณควรจัดเก็บสัญญาณที่อัปเดตเป็นประจำทุกวันหรือนานกว่านั้นไว้ในกลุ่มความสนใจ และอัปเดตโดยใช้การอัปเดตรายวัน

ไม่ต้องแสดงผลสัญญาณการเสนอราคาที่เชื่อถือได้สำหรับกลุ่มความสนใจที่ถูกกรองออกตามที่อธิบายไว้ใน "กรองกลุ่มความสนใจออกจากการเสนอราคาในบริการคีย์/มูลค่า"

จัดลำดับความสำคัญของกลุ่มความสนใจ

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

กลุ่มความสนใจอาจมีลําดับความสําคัญแบบคงที่ซึ่งระบุด้วยช่อง priority นอกจากนี้ กลุ่มความสนใจยังใช้ลําดับความสําคัญแบบไดนามิกที่คํานวณได้ในบริการสัญญาณการเสนอราคาที่เชื่อถือได้ และกลับไปยังเบราว์เซอร์โดยมีการตอบสนองpriorityVectorต่อการดึงข้อมูลสัญญาณการเสนอราคาที่เชื่อถือได้

โปรดทราบว่าเมื่อเบราว์เซอร์เรียกใช้กลุ่มความสนใจจากลำดับความสำคัญสูงสุดไปต่ำสุด อาจทำให้กลุ่มความสนใจปะทะกันจากแหล่งที่มาการเข้าร่วมที่แตกต่างกัน ซึ่งอาจเอาชนะการเพิ่มประสิทธิภาพ group-by-origin ได้

แนวทางปฏิบัติแนะนำสำหรับผู้ขาย

ตรวจสอบว่าคุณตรวจสอบและเพิ่มประสิทธิภาพการประมูล Protected Audience API อยู่

โหลดการประมูลพร้อมกัน

การเชื่อมต่อเครือข่ายที่ทันสมัยและโปรเซสเซอร์หลายแกนช่วยให้ทำงานหลายอย่างพร้อมกันได้ เบราว์เซอร์จะใช้การประมูล Protected Audience ควบคู่ไปกับกิจกรรมอื่นๆ ได้ วิธีการนี้ช่วยอำนวยความสะดวกได้ดีที่สุดด้วยการโทรหา runAdAuction() โดยเร็วที่สุด โปรดทราบว่าอินพุตบางรายการไปยัง runAdAuction() อาจไม่พร้อมใช้งานก่อนเวลา ตัวอย่างเช่น ข้อมูลที่ส่งกลับไปยังเบราว์เซอร์ในการตอบสนองตามบริบท เบราว์เซอร์อนุญาตให้เรียกใช้ runAdAution() ก่อนที่จะพร้อมใช้งาน และป้อนข้อมูลเหล่านี้ในภายหลังโดยใช้ JavaScript Promises คุณควรเรียกใช้ runAdAuction() เมื่อทราบอินพุต interestGroupBuyers เพื่อให้ได้เวลาในการตอบสนองของการประมูลต่ำที่สุด วิธีนี้ช่วยให้การประมูลหลายส่วนเริ่มขึ้นได้ทันที ซึ่งรวมถึงการดึงข้อมูลสัญญาณการเสนอราคาแบบเรียลไทม์ของผู้เสนอราคา

ติดตามการประมูลของคุณ

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

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

ป้องกันสคริปต์ราคาเสนอที่ช้า

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

ผู้ขายควรใช้ perBuyerCumulativeTimeouts เพื่อป้องกันการประมูลที่ล่าช้า และยังคงยอมรับราคาเสนอเมื่อการประมูลช้าและถึงระยะหมดเวลา การใช้ perBuyerCumulativeTimeouts ดีกว่าการใช้ perBuyerTimeouts และ perBuyerGroupLimits เนื่องจาก perBuyerCumulativeTimeouts ไม่ได้แสดงความคิดเห็นเกี่ยวกับจำนวนกลุ่มความสนใจหรือความเร็วของ generateBid() (เช่น กลุ่มความสนใจหลายกลุ่มที่เสนอราคาเร็ว และกลุ่มความสนใจเพียงไม่กี่กลุ่มที่เสนอราคาได้ช้าอาจทำได้สำเร็จก่อนหมดเวลา)

การใช้ช่อง signal การกำหนดค่าการประมูลเพื่อกำหนดเวลาหมดเวลาในการประมูลโดยรวมก็เป็นความคิดที่ดีเช่นกัน ที่จะป้องกันการประมูลที่ใช้เวลานานเกินไปในกรณีที่การดึงข้อมูลสัญญาณการให้คะแนนที่เชื่อถือได้และดำเนินการ scoreAd() ใช้เวลานานเกินไป

ขั้นตอนถัดไปคือ

เราต้องการพูดคุยกับคุณเพื่อให้แน่ใจว่าเราได้สร้าง API ที่เหมาะสำหรับทุกคน

พูดคุยเกี่ยวกับ API

API นี้จะได้รับการจัดทำเอกสารและอภิปรายต่อสาธารณะเช่นเดียวกับ Privacy Sandbox API อื่นๆ

ทดลองใช้ API

คุณจะทดสอบและเข้าร่วมในการพูดคุยเกี่ยวกับ Protected Audience API ได้