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

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

คุกกี้ของบุคคลที่สามอาจถูกบล็อกโดยข้อจํากัดของเบราว์เซอร์ การตั้งค่าของผู้ใช้ การแจ้งของนักพัฒนาแอป หรือนโยบายขององค์กร

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

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

เส้นทางของผู้ใช้ที่พบบ่อย

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

เส้นทางของผู้ใช้	API ที่แนะนํา
การชำระเงินข้ามเว็บไซต์	FedCM ชุดเว็บไซต์ที่เกี่ยวข้อง Storage Access API (SAA) scienceป๊อปอัปที่มีการแบ่งพาร์ติชัน
แดชบอร์ดการชำระเงิน	FedCM Storage Access API (SAA) ชุดเว็บไซต์ที่เกี่ยวข้อง CHIPS
จัดการวิธีการชำระเงิน	FedCM Storage Access API (SAA) ชุดเว็บไซต์ที่เกี่ยวข้อง CHIPS scienceป๊อปอัปที่มีการแบ่งพาร์ติชัน
การตรวจจับการประพฤติมิชอบ	โทเค็นสถานะส่วนตัว
ปุ่มชำระเงินที่ปรับเปลี่ยนในแบบของคุณ	scienceเฟรมที่มีการปิดกั้นที่มีการเข้าถึงข้อมูลแบบไม่แบ่งพาร์ติชันในพื้นที่

ทดสอบเส้นทางของผู้ใช้ที่เกี่ยวข้องกับการชำระเงิน

วิธีที่ดีที่สุดในการทดสอบว่าเส้นทางของผู้ใช้ได้รับผลกระทบจากข้อจํากัดของคุกกี้ของบุคคลที่สามหรือไม่คือให้ตรวจสอบเส้นทางเหล่านั้นโดยเปิดใช้การแจ้งว่ากําลังทดสอบคุกกี้ของบุคคลที่สาม

โปรดทดสอบขั้นตอนต่อไปนี้โดยจํากัดคุกกี้ของบุคคลที่สามเพื่อให้แน่ใจว่าเว็บไซต์ทํางานตามที่คาดไว้

• การชำระเงินข้ามเว็บไซต์: ทดสอบขั้นตอนการชำระเงินที่ใช้ผู้ให้บริการชำระเงินบุคคลที่สาม (เช่น ชำระเงินด้วย <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 เพื่อประสบการณ์การใช้งานที่ปรับแต่งได้มากขึ้น

ลดปัญหาที่ผู้ใช้พบในเว็บไซต์ที่เกี่ยวข้องจำนวนน้อย

หากทั้งเว็บไซต์ของผู้ขายและผู้ให้บริการชำระเงินเป็นของ บริษัทเดียวกัน คุณสามารถใช้ ชุดเว็บไซต์ที่เกี่ยวข้อง (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 ได้ด้วย