Chrome กำลังเสนอประสบการณ์การใช้งานแบบใหม่สำหรับตัวเลือกของผู้ใช้เกี่ยวกับคุกกี้ของบุคคลที่สาม คุณต้องเตรียมเว็บไซต์ให้พร้อมสําหรับผู้ใช้ที่เลือกท่องเว็บโดยไม่มีคุกกี้ของบุคคลที่สาม
หน้านี้มีข้อมูลเกี่ยวกับสิ่งที่อาจได้รับผลกระทบจากการเปลี่ยนแปลงที่กำลังจะเกิดขึ้น
เส้นทางของผู้ใช้ที่พบบ่อย
เวิร์กโฟลว์การชำระเงินและช็อปปิ้งจำนวนมากใช้คุกกี้ของบุคคลที่สาม ตารางต่อไปนี้แสดงเส้นทางของผู้ใช้บางส่วนที่อาจได้รับผลกระทบหากปิดใช้คุกกี้ของบุคคลที่สาม และแนะนํา API ทางเลือกที่นักพัฒนาซอฟต์แวร์สามารถใช้เพื่อหลีกเลี่ยงปัญหา รายการนี้อาจไม่ครอบคลุมทั้งหมดและอาจได้รับการอัปเดตเมื่อมีโซลูชัน Privacy Sandbox พร้อมใช้งานมากขึ้น เราขอแนะนำให้คุณแชร์ความคิดเห็นหากคุณพบสถานการณ์อื่นๆ ที่ได้รับผลกระทบ
ทดสอบเส้นทางของผู้ใช้ที่เกี่ยวข้องกับการชำระเงิน
วิธีที่ดีที่สุดในการทดสอบว่าเส้นทางของผู้ใช้ได้รับผลกระทบจากข้อจํากัดของคุกกี้ของบุคคลที่สามหรือไม่คือให้ตรวจสอบเส้นทางเหล่านั้นโดยเปิดใช้การแจ้งว่ากําลังทดสอบคุกกี้ของบุคคลที่สาม
โปรดทดสอบขั้นตอนต่อไปนี้โดยจำกัดคุกกี้ของบุคคลที่สามเพื่อให้แน่ใจว่าเว็บไซต์ทํางานตามที่คาดไว้
- การชำระเงินข้ามเว็บไซต์: ทดสอบขั้นตอนการชำระเงินที่ใช้ผู้ให้บริการชำระเงินบุคคลที่สาม (เช่น ชำระเงินด้วย <example-provider>) ตรวจสอบว่าได้ดำเนินการต่อไปนี้แล้ว
- การเปลี่ยนเส้นทางสําเร็จ
- โหลดเกตเวย์การชำระเงินอย่างถูกต้อง
- กระบวนการชําระเงินเสร็จสมบูรณ์โดยไม่มีข้อผิดพลาด
- ระบบจะเปลี่ยนเส้นทางผู้ใช้กลับไปยังเว็บไซต์ของคุณตามที่คาดไว้
- หน้าแดชบอร์ดการชำระเงิน: ทดสอบว่าวิดเจ็ตหน้าแดชบอร์ดธุรกรรมทำงานได้ตามที่คาดไว้เมื่อมีการจํากัดคุกกี้ของบุคคลที่สาม ยืนยันว่าผู้ใช้สามารถทำสิ่งต่อไปนี้ได้
- เข้าถึงแดชบอร์ด
- ดูการชำระเงินทั้งหมดตามที่คาดไว้
- ไปยังส่วนต่างๆ ของแดชบอร์ดได้โดยไม่มีข้อผิดพลาด (เช่น ประวัติการทำธุรกรรม รายละเอียดการชำระเงิน)
- จัดการวิธีการชำระเงิน: ทดสอบว่าวิดเจ็ตการจัดการวิธีการชำระเงินทำงานตามที่คาดไว้ เมื่อบล็อกคุกกี้ของบุคคลที่สาม ให้ทดสอบว่า
- การเพิ่มหรือลบวิธีการชำระเงินทำงานได้ตามที่คาดไว้
- การชําระเงินด้วยวิธีการชำระเงินที่บันทึกไว้ก่อนหน้านี้จะไม่ได้รับผลกระทบ
- การตรวจจับการประพฤติมิชอบ: เปรียบเทียบวิธีการทํางานของโซลูชันการตรวจจับการประพฤติมิชอบเมื่อใช้และไม่ใช้คุกกี้ของบุคคลที่สาม
- การบล็อกคุกกี้ของบุคคลที่สามจะเพิ่มขั้นตอนเพิ่มเติมซึ่งทําให้ผู้ใช้ไม่สะดวกหรือไม่
- ฟีเจอร์นี้ยังตรวจหารูปแบบที่น่าสงสัยได้ไหมเมื่อมีการบล็อกคุกกี้ของบุคคลที่สามในเบราว์เซอร์
- ปุ่มชำระเงินที่ปรับเปลี่ยนในแบบของคุณ: ทดสอบว่าปุ่มการชำระเงินแสดงผลอย่างถูกต้องเมื่อมีการจํากัดคุกกี้ของบุคคลที่สามหรือไม่
- ผู้ใช้จะยังทำการซื้อให้เสร็จสมบูรณ์ได้ไหม แม้ว่าปุ่มที่ปรับเปลี่ยนในแบบของคุณจะไม่แสดงวิธีการชำระเงินที่ต้องการ
การชำระเงินข้ามเว็บไซต์
ผู้ให้บริการชำระเงินบางรายอาจใช้คุกกี้ของบุคคลที่สามเพื่อให้ผู้ใช้เข้าถึงบัญชีของตนในเว็บไซต์ของผู้ขายหลายแห่งได้โดยไม่ต้องตรวจสอบสิทธิ์อีกครั้ง เส้นทางของผู้ใช้นี้อาจได้รับผลกระทบสำหรับผู้ที่เลือกท่องเว็บโดยไม่มีคุกกี้ของบุคคลที่สาม
แบบฟอร์มการชำระเงินที่ฝัง
ลองพิจารณาโดเมนต่อไปนี้
payment-provider.example
ให้บริการการชำระเงินแก่เว็บไซต์ของผู้ขาย รวมถึงจัดเก็บข้อมูลการชำระเงินและเซสชันของผู้ใช้merchant.example
เป็นเว็บไซต์ที่ฝังแบบฟอร์มการชำระเงินจากpayment-provider.example
ผู้ใช้เพิ่งเข้าสู่ระบบ payment-provider.example
(เช่น ขณะชำระเงินในเว็บไซต์อื่น) ผู้ใช้เริ่มกระบวนการชําระเงินในmerchant.example
เมื่อใช้คุกกี้ของบุคคลที่สาม payment-provider.example
การชำระเงินแบบฟอร์มที่ฝังใน merchant.example
จะมีสิทธิ์เข้าถึงคุกกี้เซสชันระดับบนสุดของตัวเองที่ตั้งค่าไว้ใน payment-provider.example
ในบริบทระดับบนสุด
อย่างไรก็ตาม หากมีการบล็อกคุกกี้ของบุคคลที่สาม เนื้อหาที่ฝังจะไม่มีสิทธิ์เข้าถึงคุกกี้ระดับบนสุดของตนเอง

โซลูชันที่ปรับแต่งได้โดยใช้ FedCM
payment-provider.example
ควรพิจารณาใช้ FedCM เพื่อทำหน้าที่เป็นผู้ให้บริการข้อมูลประจำตัว แนวทางนี้เหมาะสําหรับกรณีต่อไปนี้
payment-provider.example
ฝังอยู่ในเว็บไซต์ของบุคคลที่สามที่ไม่เกี่ยวข้องpayment-provider.example
ฝังอยู่ในเว็บไซต์ที่เกี่ยวข้องมากกว่า 5 เว็บไซต์
ประโยชน์หลักของ FedCM คือ UI จะให้บริบทเพิ่มเติมแก่ผู้ใช้สำหรับตัวเลือกต่างๆ เมื่อได้รับสิทธิ์จากผู้ใช้ FedCM จะอนุญาตให้แชร์ข้อมูลที่กำหนดเองระหว่างฝ่ายที่ใช้ (merchant.example
) กับผู้ให้บริการข้อมูลประจำตัว (payment-provider.example
) ฝ่ายที่ใช้สามารถเลือกรองรับผู้ให้บริการข้อมูลประจำตัวอย่างน้อย 1 ราย และ UI ของ FedCM จะแสดงแบบมีเงื่อนไขเท่านั้น
นักพัฒนาแอปสามารถเลือกระหว่างโหมดแอ็กทีฟหรือโหมดพาสซีฟได้ โดยขึ้นอยู่กับความต้องการ โดยโหมดแอ็กทีฟจะทริกเกอร์กระบวนการเข้าสู่ระบบหลังจากผู้ใช้ดำเนินการ เช่น คลิกปุ่มชำระเงิน ส่วนโหมดพาสซีฟจะแสดงข้อความแจ้งของ FedCM โดยอัตโนมัติเมื่อผู้ใช้เข้าสู่ระบบด้วยผู้ให้บริการข้อมูลประจำตัว
นอกจากนี้ FedCM ยังทำหน้าที่เป็นสัญญาณความน่าเชื่อถือสำหรับ Storage Access API (SAA) ซึ่งช่วยให้การฝังเข้าถึงคุกกี้ระดับบนสุดที่ไม่ได้แบ่งพาร์ติชันได้หลังจากที่ผู้ใช้ตกลงที่จะลงชื่อเข้าใช้ด้วยผู้ให้บริการของการฝังโดยไม่ต้องมีการแจ้งเตือนเพิ่มเติมแก่ผู้ใช้
โซลูชันที่เน้นการเข้าถึงพื้นที่เก็บข้อมูล
API อีกรายการที่ควรพิจารณาคือ Storage Access API (SAA)
เมื่อใช้ SAA ระบบจะแจ้งให้ผู้ใช้อนุญาตให้ payment-provider.example
ฝังเพื่อเข้าถึงคุกกี้ระดับบนสุดของตนเอง หากผู้ใช้อนุมัติการเข้าถึง แบบฟอร์มจะแสดงผลได้เช่นเดียวกับเมื่อมีคุกกี้ของบุคคลที่สาม
เช่นเดียวกับ FedCM ผู้ใช้จะต้องอนุมัติคําขอในเว็บไซต์ใหม่ทุกแห่งที่ฝัง payment-provider.example
ดูการสาธิต SAA เพื่อทำความเข้าใจวิธีการทำงานของ API
หากพรอมต์ SAA เริ่มต้นไม่ตรงกับความต้องการของคุณ ให้ลองใช้ FedCM เพื่อประสบการณ์การใช้งานที่ปรับแต่งได้มากขึ้น
ลดปัญหาที่ผู้ใช้พบในเว็บไซต์ที่เกี่ยวข้องจำนวนน้อย
หากทั้งเว็บไซต์ของผู้ขายและผู้ให้บริการชำระเงินเป็นของ บริษัทเดียวกัน คุณสามารถใช้ Related Website Sets (RWS) API เพื่อประกาศความสัมพันธ์ระหว่างโดเมน ซึ่งจะช่วยลดความยุ่งยากของผู้ใช้ เช่น หาก insurance.example
และ payment-portal-insurance.example
อยู่ใน RWS เดียวกัน payment-portal-insurance.example
จะได้รับสิทธิ์เข้าถึงคุกกี้ระดับบนสุดของตนเองโดยอัตโนมัติเมื่อมีคำขอสิทธิ์เข้าถึงพื้นที่เก็บข้อมูลภายในการฝัง payment-portal-insurance.example
โซลูชันอื่นๆ ที่ใช้ทดสอบ
API ทดลองอีกรายการที่อาจมีประโยชน์ในสถานการณ์นี้คือ ป๊อปอัปที่มีการแบ่งพาร์ติชัน ปัจจุบัน API นี้อยู่ในขั้นการพัฒนา
เมื่อใช้ป๊อปอัปที่มีการแบ่งพาร์ติชัน ระบบจะขอให้ผู้ใช้ป้อนข้อมูลเข้าสู่ระบบเพื่อลงชื่อเข้าใช้ payment-provider.example
ภายในป๊อปอัปที่เปิดโดย merchant.example
merchant.example
ผู้เปิดจะแบ่งพาร์ติชันพื้นที่เก็บข้อมูล ในกรณีนี้ payment-provider.example
embed จะมีสิทธิ์เข้าถึงค่าพื้นที่เก็บข้อมูลที่กําหนดไว้ในป๊อปอัป เมื่อใช้โซลูชันนี้ ผู้ใช้จะต้องลงชื่อเข้าใช้ผู้ให้บริการชำระเงินในทุกเว็บไซต์
การชำระเงินผ่านลิงก์การชำระเงิน
ผู้ให้บริการการชำระเงินบางรายมีบริการที่สร้างลิงก์การชำระเงิน ซึ่งจะแสดงผลหน้าชำระเงินที่กำหนดเองสำหรับเว็บไซต์ของผู้ขาย บริการลิงก์การชำระเงินและพอร์ทัลผู้ใช้สำหรับผู้ให้บริการการชำระเงินมักติดตั้งใช้งานในโดเมนที่แตกต่างกัน เช่น payment-provider.example
และ payment-link.example
payment-link.example
ฝังแบบฟอร์มการชำระเงินจาก
payment-provider.example
รูปแบบนี้เป็นรูปแบบหนึ่งของแบบฟอร์มการชำระเงินที่ฝัง
FedCM,
SAA
และ
RWS
ก็เป็นตัวเลือกที่ดีสำหรับกรณีนี้เช่นกัน
แดชบอร์ดการชำระเงิน
แอปพลิเคชันบางรายการแสดงแดชบอร์ดธุรกรรมต่อผู้ใช้ในเว็บไซต์หลายแห่ง ซึ่งให้มุมมองแบบรวมเกี่ยวกับกิจกรรมทางการเงิน ซึ่งทำให้แดชบอร์ดเข้าถึงข้อมูลเฉพาะผู้ใช้ในหลายโดเมนได้
ลองพิจารณาโดเมนต่อไปนี้
earnings.example
มีหน้าแดชบอร์ดการชำระคืนที่ฝังลงในเว็บแอปพลิเคชันต่างๆ ได้ บริการนี้จะจัดเก็บข้อมูลรายได้ของผู้ใช้และข้อมูลเซสชันcatsitting.example
และdogsitting.example
เป็นเว็บไซต์แยกต่างหากที่ฝังแดชบอร์ดearnings.example
ทั้งคู่
ผู้ใช้เข้าสู่ระบบบัญชี earnings.example
เมื่อเข้าชม catsitting.example
หรือ dogsitting.example
ผู้ใช้จะดูรายได้ของตนเองได้ แดชบอร์ด earnings.example
ที่ฝังไว้ใช้คุกกี้ระดับบนสุดและแสดงข้อมูลรายได้ที่ปรับเปลี่ยนในแบบของผู้ใช้
เช่นเดียวกับตัวอย่างอื่นๆ ชิ้นงาน earnings.example
จะไม่มีสิทธิ์เข้าถึงคุกกี้ระดับบนสุดเมื่อปิดใช้คุกกี้ของบุคคลที่สาม

หน้าแดชบอร์ดของบุคคลที่หนึ่ง
ในกรณีที่โดเมนทั้ง 3 รายการเป็นของบุคคลเดียวกัน ให้พิจารณาใช้ SAA ร่วมกับ RWS
เมื่อใช้ SAA earnings.example
จะสามารถเข้าถึงคุกกี้ระดับบนสุดได้ด้วยสิทธิ์ของผู้ใช้ หากบุคคลนี้ใช้ earnings.example
ในโดเมนไม่เกิน 4 โดเมน การประกาศความสัมพันธ์ระหว่างโดเมนด้วย RWS จะช่วยให้ผู้ใช้ได้รับประสบการณ์การใช้งานที่ราบรื่นยิ่งขึ้น
หากบุคคลเดียวกันฝังวิดเจ็ตในโดเมนมากกว่า 5 รายการ บุคคลดังกล่าวจะประกาศความสัมพันธ์ระหว่างเว็บไซต์ที่ฝังทั้งหมดกับโดเมนของวิดเจ็ตไม่ได้ เนื่องจาก RWS รองรับเว็บไซต์ได้สูงสุด 6 รายการในชุด โดยแบ่งเป็นเว็บไซต์หลัก 1 รายการและเว็บไซต์ที่เกี่ยวข้อง 5 รายการ
การเผยแพร่แดชบอร์ดที่ปรับขนาด
SAA และ RWS อาจไม่ใช่โซลูชันที่ดีที่สุดในกรณีต่อไปนี้
- คุณจัดจำหน่ายโซลูชันแดชบอร์ดสำหรับเว็บไซต์ของบุคคลที่สาม
- คุณมีเว็บไซต์ที่ฝังวิดเจ็ตหน้าแดชบอร์ดมากกว่า 5 เว็บไซต์
ในกรณีนี้ earnings.example
ควรพิจารณาใช้ FedCM เพื่อทำหน้าที่เป็นผู้ให้บริการข้อมูลประจำตัว ซึ่งหมายความว่าผู้ใช้จะต้องเข้าสู่ระบบ dogsitting.example
ด้วยบัญชีที่จัดการโดย earnings.example
FedCM มี UI ที่ปรับแต่งได้ซึ่งช่วยสื่อสารกับผู้ใช้อย่างชัดเจนว่ามีการแชร์ข้อมูลใดบ้าง เมื่อใช้ FedCM dogsitting.example
สามารถขอให้ earnings.example
แชร์สิทธิ์ที่กำหนดเอง เช่น เพื่อเข้าถึงข้อมูลธุรกรรม
นอกจากนี้ FedCM ยังทำหน้าที่เป็นสัญญาณความน่าเชื่อถือสําหรับ Storage Access API และแทรก earnings.example
จะได้รับสิทธิ์เข้าถึงพื้นที่เก็บข้อมูลคุกกี้ระดับบนสุดของตนเองโดยไม่ต้องแจ้งให้ผู้ใช้ทราบเพิ่มเติมในการเรียกใช้ SAA API
การตั้งค่าแดชบอร์ดเฉพาะเว็บไซต์
หากไม่จําเป็นต้องแชร์ข้อมูลในหลายเว็บไซต์ ให้พิจารณาแบ่งพาร์ติชันคุกกี้ด้วย CHIPS CHIPS อาจมีประโยชน์ในการเก็บค่ากําหนดเฉพาะเว็บไซต์ เช่น เลย์เอาต์หน้าแดชบอร์ดหรือตัวกรอง
จัดการวิธีการชำระเงิน
ขั้นตอนทั่วไปอีกอย่างหนึ่งคือให้ผู้ใช้ดูและแก้ไขวิธีการชำระเงินภายในการฝังโดยไม่ต้องออกจากเว็บไซต์โฮสต์
ลองดูขั้นตอนต่อไปนี้
payments.example
มีเครื่องมือการจัดการการชำระเงินที่ฝังลงในเว็บไซต์ได้ บริการนี้จะจัดเก็บข้อมูลการชำระเงินและข้อมูลเซสชันของผู้ใช้shop.example
เป็นเว็บไซต์ที่ฝังเครื่องมือpayments.example
เพื่ออนุญาตให้ผู้ใช้ดู แก้ไข หรือเลือกวิธีการชำระเงินที่ต้องการซึ่งเชื่อมโยงกับบัญชีshop.example
ผู้ให้บริการชำระเงินที่ใช้การจัดการวิธีการชำระเงินควรพิจารณาเป็นผู้ให้บริการข้อมูลประจำตัวด้วย FedCM เมื่อใช้ FedCM ผู้ใช้จะเข้าสู่ระบบบุคคลที่เชื่อถือ (shop.example
) ได้โดยใช้บัญชีที่จัดการโดยผู้ให้บริการข้อมูลประจำตัว (payments.example
)
เมื่อได้รับสิทธิ์จากผู้ใช้แล้ว FedCM จะอนุญาตให้แชร์ข้อมูลที่กําหนดเองระหว่างบุคคลที่เชื่อถือกับผู้ให้บริการระบุตัวตน ประโยชน์หลักของการใช้ FedCM คือ UI จะให้บริบทเพิ่มเติมแก่ผู้ใช้เกี่ยวกับตัวเลือกต่างๆ และยังทำหน้าที่เป็นสัญญาณความน่าเชื่อถือสําหรับ Storage Access API ซึ่งช่วยให้การฝังเข้าถึงคุกกี้ระดับบนสุดได้
เมื่อปิดใช้คุกกี้ของบุคคลที่สาม แทรก payments.example
จะไม่มีสิทธิ์เข้าถึงคุกกี้ระดับบนสุด ในกรณีนี้ SAA ช่วยดูแลให้มีการดำเนินการอย่างถูกต้องได้โดยขอสิทธิ์เข้าถึงพื้นที่เก็บข้อมูล
บางครั้งคุณไม่จำเป็นต้องแชร์ข้อมูลที่ฝังไว้ในเว็บไซต์อื่นๆ payments.example
อาจต้องจัดเก็บค่ากําหนดของผู้ใช้ที่แตกต่างกันในแต่ละเว็บไซต์ที่ฝัง ในกรณีนี้ ให้พิจารณาแบ่งพาร์ติชันคุกกี้โดยใช้ CHIPS เมื่อใช้ CHIPS payments.example
ที่ฝังใน shop.example
จะเข้าถึงคุกกี้ที่ตั้งค่าภายใน payments.example
ที่ฝังใน another-shop.example
ไม่ได้
API ทดสอบอีกรายการที่อาจใช้ในขั้นตอนของผู้ใช้นี้ได้คือ ป๊อปอัปที่มีการแบ่งพาร์ติชัน
เมื่อผู้ใช้เข้าสู่ระบบ payments.example
ภายในป๊อปอินที่ shop.example
เปิดขึ้น ระบบจะแบ่งพื้นที่เก็บข้อมูลตามผู้เปิด และส่วนฝังของ payments.example
จะมีสิทธิ์เข้าถึงค่าพื้นที่เก็บข้อมูลที่กําหนดภายในป๊อปอิน อย่างไรก็ตาม แนวทางนี้กำหนดให้ผู้ใช้ป้อนข้อมูลเข้าสู่ระบบเพื่อลงชื่อเข้าใช้ผู้ให้บริการชำระเงินในทุกเว็บไซต์
การตรวจจับการประพฤติมิชอบ
ระบบการวิเคราะห์ความเสี่ยงจะวิเคราะห์ข้อมูลที่จัดเก็บไว้ในคุกกี้เพื่อระบุรูปแบบที่แตกต่างจากปกติ เช่น หากผู้ใช้เปลี่ยนที่อยู่สำหรับจัดส่งอย่างกะทันหันและทำการซื้อจำนวนมากโดยใช้อุปกรณ์ใหม่ คะแนนความเป็นไปได้ที่จะเกิดการประพฤติมิชอบอาจเพิ่มขึ้น คุกกี้ตรวจจับการประพฤติมิชอบมักจะเป็นคุกกี้ของบุคคลที่สาม ซึ่งตั้งค่าไว้ในเว็บไซต์ของผู้ขายโดยผู้ให้บริการชำระเงินหรือวิดเจ็ตบริการป้องกันการประพฤติมิชอบ
แม้ว่าข้อจำกัดคุกกี้ของบุคคลที่สามจะไม่ส่งผลกระทบต่อระบบตรวจจับการประพฤติมิชอบ แต่อาจทำให้เกิดความไม่สะดวกเพิ่มเติมแก่ผู้ใช้ หากระบบไม่สามารถยืนยันได้อย่างมั่นใจว่าผู้ใช้เป็นบุคคลที่ถูกต้องเนื่องจากคุกกี้ที่ถูกบล็อก ระบบอาจต้องดำเนินการตรวจสอบเพิ่มเติม เช่น การยืนยันตัวตนให้เสร็จสมบูรณ์
หากต้องการรองรับการตรวจจับการประพฤติมิชอบเมื่อมีการบล็อกคุกกี้ของบุคคลที่สาม ให้ลองผสานรวม Private State Tokens (PST) API เข้ากับโซลูชันการตรวจจับการประพฤติมิชอบ PST ช่วยให้ผู้ให้บริการชำระเงินสามารถลงทะเบียนเป็นผู้ออกโทเค็นและมอบโทเค็นแก่ผู้ใช้ที่ไม่ใช้คุกกี้ของบุคคลที่สาม จากนั้นสามารถแลกโทเค็นเหล่านี้ในเว็บไซต์ของผู้ขายเพื่อตรวจสอบความน่าเชื่อถือของผู้ใช้ ดูรายละเอียดการใช้งานได้ในเอกสารประกอบสำหรับนักพัฒนาซอฟต์แวร์ PST
Privacy Sandbox กําลังทดลองใช้ API อื่นๆ ในการป้องกันการประพฤติมิชอบ
ปุ่มชำระเงินที่ปรับเปลี่ยนในแบบของคุณ
ปุ่มการชำระเงิน (เช่น ชำระเงินด้วย <วิธีการชำระเงินที่ต้องการ>) ที่ฝังอยู่ในเว็บไซต์ของผู้ขายมักใช้ข้อมูลข้ามเว็บไซต์ที่ผู้ให้บริการการชำระเงินกำหนดไว้ ซึ่งช่วยให้คุณปรับเปลี่ยนในแบบของคุณได้ และผู้ใช้จะชำระเงินได้อย่างราบรื่นด้วยวิธีการชำระเงินที่ต้องการ หากมีการบล็อกคุกกี้ของบุคคลที่สามในเบราว์เซอร์ของผู้ใช้ การแสดงผลปุ่มการชำระเงินที่ปรับเปลี่ยนในแบบของคุณอาจได้รับผลกระทบ
แม้ว่า SAA จะอนุญาตให้เข้าถึงพื้นที่เก็บข้อมูลได้ แต่ข้อความแจ้งที่จำเป็นอาจไม่ทำให้ผู้ใช้ได้รับประสบการณ์การใช้งานที่ดีที่สุด
เรากําลังสํารวจโซลูชันที่เป็นไปได้ซึ่งมุ่งเน้นที่กรณีการใช้งานนี้โดยเฉพาะ ซึ่งก็คือเฟรมที่มีการกำหนดเขตข้อมูลที่มีการเข้าถึงข้อมูลในเครื่องแบบไม่แบ่งพาร์ติชัน ปัจจุบัน API นี้อยู่ในขั้นการพัฒนา และคุณสามารถกำหนดอนาคตของ API ได้ ลองใช้ด้วยตนเองและแสดงความคิดเห็น
รับความช่วยเหลือ
รายงานปัญหาการหยุดทำงานที่พบไปที่ goo.gle/report-3pc-broken นอกจากนี้ คุณยังส่งแบบฟอร์มความคิดเห็นหรือแจ้งปัญหาใน GitHub ในที่เก็บข้อมูลการสนับสนุนนักพัฒนาซอฟต์แวร์ของ Privacy Sandbox ได้ด้วย