ตรวจสอบผลกระทบของการเปลี่ยนแปลงคุกกี้ของบุคคลที่สามที่มีต่อเวิร์กโฟลว์การชำระเงิน

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 ในบริบทระดับบนสุด อย่างไรก็ตาม หากมีการบล็อกคุกกี้ของบุคคลที่สาม เนื้อหาที่ฝังจะไม่มีสิทธิ์เข้าถึงคุกกี้ระดับบนสุดของตนเอง

แผนภาพแสดงการโต้ตอบกับเว็บไซต์ของผู้ขาย (merchant.example) ที่ใช้วิดเจ็ตการชำระเงินจากผู้ให้บริการบุคคลที่สาม (payment-provider.example) เมื่อมีการบล็อกคุกกี้ของบุคคลที่สาม วิดเจ็ตจะเข้าถึงคุกกี้ระดับบนสุดไม่ได้ ซึ่งอาจส่งผลต่อประสบการณ์ของผู้ใช้
เมื่อปิดใช้คุกกี้ของบุคคลที่สาม วิดเจ็ต `payment-provider.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 จะไม่มีสิทธิ์เข้าถึงคุกกี้ระดับบนสุดเมื่อปิดใช้คุกกี้ของบุคคลที่สาม

แผนภาพที่แสดงสถานการณ์ที่ข้อมูลรายได้ของผู้ใช้ซึ่งโฮสต์ใน earnings.example แสดงในแดชบอร์ดที่ฝังใน dogsitting.example  เมื่อมีการบล็อกคุกกี้ของบุคคลที่สาม แดชบอร์ดแบบฝังจะเข้าถึงคุกกี้ระดับบนสุดไม่ได้ ซึ่งจะป้องกันไม่ให้แสดงข้อมูลรายได้ที่ปรับเปลี่ยนในแบบของผู้ใช้
เมื่อปิดใช้คุกกี้ของบุคคลที่สาม วิดเจ็ต `earnings.example` ที่ฝังใน `dogsitting.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 ได้ด้วย