การตรวจสอบว่า 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 ได้