การตรวจสอบว่า 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) ได้ขณะใช้สคริปต์เดียวกัน
หากไม่มีส่วนหัวการควบคุมแคช HTTP ระบบจะไม่แคชสคริปต์การเสนอราคา ระบุส่วนหัวที่เหมาะสมเพื่อให้มั่นใจว่าระบบจะไม่ดึงข้อมูลสคริปต์โดยไม่จำเป็น หากการประมูลหลายรายการในหน้าเว็บทํางานพร้อมกัน ระบบจะใช้สคริปต์การเสนอราคาของผู้เสนอราคารายเดียวกันซ้ำหากมีอยู่ในหน่วยความจําอยู่แล้ว โดยไม่สนใจความหมายของการแคช หากการประมูลทํางานตามลําดับ เบราว์เซอร์จะเป็นไปตามกลไกการแคช HTTP
โปรดทราบว่าเบราว์เซอร์จะโหลดสคริปต์การเสนอราคาในช่วงเวลาที่เสนอราคา (สําหรับ generateBid()) และในช่วงเวลาการรายงาน (สําหรับ reportWin()) หากไม่ได้ตั้งค่าส่วนหัวการควบคุมแคชไว้ เบราว์เซอร์จะดึงข้อมูลสคริปต์เดียวกัน 2 ครั้ง โดยดึงข้อมูล 1 ครั้งสําหรับแต่ละระยะเวลา
เราจึงขอแนะนำให้ตั้งค่าส่วนหัวการควบคุมแคชในสคริปต์ทั้งหมด
ใช้ซ้ำ 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() ก่อนที่จะพร้อมใช้งาน และระบุอินพุตเหล่านี้ในภายหลังโดยใช้ Promise ของ JavaScript คุณควรเรียกใช้ runAdAuction() เมื่อทราบอินพุต interestGroupBuyers เพื่อให้ได้เวลาในการตอบสนองในการประมูลต่ำที่สุด ซึ่งจะช่วยให้การประมูลหลายส่วนเริ่มต้นได้ทันที รวมถึงการดึงข้อมูลสัญญาณการเสนอราคาแบบเรียลไทม์ของผู้เสนอราคา
ตรวจสอบการประมูล
รวบรวมเมตริกเกี่ยวกับการประมูล เบราว์เซอร์สามารถรายงานper-buyerเมตริกเวลาในการตอบสนองให้แก่ผู้ขาย ซึ่งจะให้ข้อมูลเชิงลึกมากมายเกี่ยวกับระยะเวลาที่ใช้ในการประมูลของผู้ขาย ผู้ขายสามารถใช้เมตริกเหล่านี้เพื่อมองหาวิธีเพิ่มประสิทธิภาพการประมูล รวมถึงดูวิธีตั้งค่าการหมดเวลาให้มีประสิทธิภาพสูงสุด ผู้ขายสามารถแชร์เมตริกเวลาในการตอบสนองของผู้ซื้อที่เฉพาะเจาะจงกับผู้ซื้อเพื่อช่วยเพิ่มประสิทธิภาพเพิ่มเติม
ผู้เสนอราคาอาจมีข้อมูลเชิงลึกเกี่ยวกับประสิทธิภาพการเสนอราคาของกลุ่มความสนใจของตนเอง แต่อาจไม่สามารถเปรียบเทียบข้อมูลนี้กับผู้เสนอราคารายอื่นได้ การเปรียบเทียบอัตราสัมพัทธ์ของการชนะและอัตราการปฏิเสธราคาเสนอสำหรับผู้เสนอราคารายต่างๆ อาจช่วยระบุกรณีที่ทรัพยากรการประมวลผลราคาเสนอถูกใช้ไปโดยเปล่าประโยชน์เนื่องจากกลุ่มความสนใจไม่เคยสร้างราคาเสนอที่ใช้งานได้ หรือการเสนอราคามากเกินไปโดยใช้ครีเอทีฟโฆษณาที่ไม่ได้รับอนุมัติ
ป้องกันสคริปต์ราคาเสนอที่ทำงานช้า
สคริปต์การเสนอราคาที่ใช้เวลานานเกินไปอาจทำให้การประมูล Protected Audience API ช้าลงสำหรับทุกคนที่เกี่ยวข้อง การใช้การหมดเวลาจะช่วยป้องกันไม่ให้มีการประมูลที่ช้า ขณะเดียวกันก็ยังคงสร้างรายได้ได้เมื่อการประมูลช้า
ผู้ขายควรใช้ perBuyerCumulativeTimeouts เพื่อป้องกันไม่ให้มีการประมูลที่ช้า และเพื่อที่จะยังยอมรับราคาเสนอได้เมื่อการประมูลช้าและถึงเวลาหมด เราขอแนะนำให้ใช้ perBuyerCumulativeTimeouts แทนการใช้ perBuyerTimeouts และ perBuyerGroupLimits เนื่องจาก perBuyerCumulativeTimeouts ไม่ได้กำหนดจำนวนกลุ่มความสนใจหรือความเร็วของ generateBid() (เช่น กลุ่มความสนใจจำนวนมากที่เสนอราคาอย่างรวดเร็วและกลุ่มความสนใจน้อยที่เสนอราคาช้าอาจดำเนินการเสร็จสิ้นได้ก่อนหมดเวลา)
การใช้ช่อง signal ในการกําหนดค่าการประมูลเพื่อใช้การหมดเวลาการประมูลโดยรวมยังเป็นแนวคิดที่ดีในการป้องกันการประมูลที่ใช้เวลานานเกินไปในกรณีที่การดึงข้อมูลสัญญาณการให้คะแนนที่เชื่อถือได้และการดำเนินการ scoreAd() ใช้เวลานานเกินไป
What's next?
We want to engage in conversations with you to ensure we build an API that works for everyone.
Discuss the API
Like other Privacy Sandbox APIs, this API is documented and discussed publicly.
Experiment with the API
You can experiment and participate in conversation about the Protected Audience API.