การคุ้มครองความเป็นส่วนตัวสําหรับรายงานที่รวบรวมได้

บริการรวบรวมข้อมูลจะสร้างรายงานสรุปของข้อมูล Conversion แบบละเอียดและการวัดการเข้าถึงจากรายงานดิบแบบรวมได้ บริการรวบรวมข้อมูลใช้เฟรมเวิร์กที่รองรับความเป็นส่วนตัวแบบที่แตกต่างกัน (DP) เพื่อวัดและจํากัดปริมาณข้อมูลที่รายงานเหล่านี้เปิดเผยเกี่ยวกับผู้ใช้แต่ละราย เพื่อรักษาข้อมูลของผู้ใช้ให้เป็นส่วนตัวและปลอดภัย

คู่มือนี้จะกล่าวถึงเครื่องมือและกลยุทธ์ในการสร้างรายงานแบบรวมที่ช่วยรักษาข้อมูลเกี่ยวกับผู้ใช้แต่ละรายให้ปลอดภัย

• สร้างรายงานสรุปที่มีการเพิ่มข้อมูลรบกวน
• กำหนดงบประมาณการมีส่วนร่วม
• กลยุทธ์สำหรับการจัดกลุ่มรายงาน
  • จัดการรายงานที่ซ้ำกันทีละหลายรายการ
  • จัดการรายงานที่มีรหัสที่แชร์ร่วมกัน
• ใช้คีย์การรวมที่ประกาศไว้ล่วงหน้า

รายงานสรุปที่มีสัญญาณรบกวนเพิ่มเติม

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

ระดับความผันผวนที่เพิ่มลงในรายงานไม่ได้ขึ้นอยู่กับจํานวนรายงานที่รวบรวม ค่ารายงานแต่ละรายการ หรือค่ารายงานที่รวบรวม สัญญาณรบกวนจะดึงมาจากการแจกแจง Laplace เวอร์ชันแบบไม่ต่อเนื่อง และปรับขนาดตามงบประมาณการมีส่วนร่วม (ความไว L1) ที่ไคลเอ็นต์บังคับใช้ โดยขึ้นอยู่กับ API การวัดผลที่เกี่ยวข้องและพารามิเตอร์ความเป็นส่วนตัว epsilon

ดูข้อมูลเพิ่มเติมเกี่ยวกับสัญญาณรบกวนและความเกี่ยวข้องกับข้อมูลรายงานได้ที่การทำความเข้าใจสัญญาณรบกวนในรายงานสรุป

งบประมาณการมีส่วนร่วม

หากต้องการควบคุมความไวของรายงานสรุป จํานวนการมีส่วนร่วมที่ส่งในคอลจะเชื่อมโยงกับขีดจํากัดการจำกัดการมีส่วนร่วมที่เฉพาะเจาะจง หรือที่เรียกว่างบประมาณการมีส่วนร่วม งบประมาณการมีส่วนร่วมจะแตกต่างกันไป ขึ้นอยู่กับว่าคุณใช้ Attribution Reporting API หรือ Private Aggregation API

ดูข้อมูลเพิ่มเติมเกี่ยวกับวิธีตั้งงบประมาณการมีส่วนร่วมสำหรับ API แต่ละรายการได้ที่ส่วนเอกสารประกอบของ API ต่อไปนี้

• การกำหนดขอบเขตและการกําหนดงบประมาณการมีส่วนร่วมของ Attribution Reporting API
• ขีดจํากัดการมีส่วนร่วมของ Private Aggregation API
• การกำหนดขอบเขตและการกําหนดงบประมาณการมีส่วนร่วมของ Private Aggregation API

กลยุทธ์สำหรับการจัดกลุ่มรายงาน

เมื่อส่งรายงานแบบเป็นกลุ่มที่รวบรวมได้ คุณควรเพิ่มประสิทธิภาพกลยุทธ์การรวมกลุ่มเพื่อไม่ให้เกินขีดจํากัดด้านความเป็นส่วนตัว แนวคิดสําคัญ 2 ประการในการรวมรายงานอย่างถูกต้องคือกฎ"ไม่ซ้ำกัน" และแนวคิดเกี่ยวกับกลุ่มที่ไม่เกี่ยวข้องกัน

กฎ "ไม่ซ้ำกัน"

บริการรวมข้อมูลจะบังคับใช้กฎ "ไม่ซ้ำกัน" กฎนี้ระบุว่ารายงานที่รวบรวมได้ซึ่งระบุด้วย report_id ที่ไม่ซ้ำกันจะปรากฏได้เพียงครั้งเดียวในชุดเดียว หากรายงานที่รวบรวมได้ปรากฏมากกว่า 1 ครั้งต่อกลุ่ม ระบบจะรวมรายงานแรกไว้ในการรวม ทิ้งรายงานต่อๆ ไปที่มี report_id เดียวกัน และดำเนินการกลุ่มให้เสร็จสมบูรณ์

กฎนี้ยังระบุว่ารายงานเดียวกันต้องไม่ปรากฏในหลายกลุ่ม หากรายงานรวมอยู่ในชุดก่อนหน้าที่ดำเนินการสำเร็จแล้ว ชุดถัดไปที่รวมรายงานเดียวกันจะดำเนินการไม่สำเร็จ

รูปที่ 1 หากรายงานปรากฏมากกว่า 1 ครั้งในชุด การรวมจะรวมอินสแตนซ์แรกและทิ้งรายงานที่ตามมาซึ่งมีรหัสเดียวกัน

หากไม่มีกฎ "ไม่ซ้ำกัน" ผู้โจมตีอาจได้รับข้อมูลเชิงลึกเกี่ยวกับเนื้อหาของกลุ่มหนึ่งๆ โดยการดัดแปลงเนื้อหาของกลุ่มนั้นๆ ผ่านการรวมสำเนารายงานที่ซ้ำกันไว้ในกลุ่มเดียวหรือหลายกลุ่ม

ดูข้อมูลเพิ่มเติมเกี่ยวกับการบังคับใช้กฎ "ไม่ซ้ำกัน" ภายในกลุ่มรายงานหรือหลายกลุ่มได้ที่รายงานที่ซ้ำกันภายในกลุ่ม

กลุ่มที่ไม่ต่อเนื่อง

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

ในตัวอย่างช่อง shared_info ต่อไปนี้ คุณจะเห็น API, attribution_destination (สําหรับการรายงานการระบุแหล่งที่มา), reporting_origin, scheduled_report_time, source_registration_time (สําหรับการรายงานการระบุแหล่งที่มา) และ version ฟิลด์เหล่านี้ (ยกเว้น report_id) จะเป็นองค์ประกอบของรหัสที่แชร์

"shared_info": {
  "API": "attribution-reporting",
  "attribution_destination": "https://privacy-sandbox-demos-shop.dev",
  "report_id": "5b052748-f5fb-4f14-b291-de03484ed59e",
  "reporting_origin": "https://privacy-sandbox-demos-dsp.dev",
  "scheduled_report_time": "1707786751",
  "source_registration_time": "0",
  "version": "0.1"
}

เนื่องจาก source_registration_time ถูกตัดให้เหลือตามวันและ scheduled_report_time ถูกตัดให้เหลือตามชั่วโมง จึงมีรายงานที่มีรหัสที่แชร์เดียวกัน ในตัวอย่างนี้ Report1 และ Report2 มีช่องข้อมูลที่ใช้ร่วมกัน รายงานทั้ง 2 ฉบับมี API, เวอร์ชัน, attribution_destination, reporting_origin และ source_registration_time เดียวกัน คุณไม่ต้องสนใจความแตกต่างนี้เนื่องจาก report_id ไม่ได้เป็นส่วนหนึ่งของรหัสที่แชร์

ในตัวอย่างต่อไปนี้สําหรับ Report1 และ Report2 ค่า scheduled_report_time จะเหมือนกัน

ข้อมูล Report1 ที่แชร์:

"shared_info": {
  "API": "attribution-reporting",
  "attribution_destination": "https://shop.dev",
  "report_id": "5b052748-...",
  "reporting_origin": "https://dsp.dev",
  "scheduled_report_time": "1708376890",
  "source_registration_time": "0",
  "version": "0.1"
}

ข้อมูล Report2 ที่แชร์

"shared_info": {
  "API": "attribution-reporting",
  "attribution_destination": "https://shop.dev",
  "report_id": "5b052748-...",
  "reporting_origin": "https://dsp.dev",
  "scheduled_report_time": "1708376890",
  "source_registration_time": "0",
  "version": "0.1"
}

เวลาที่ตั้งเวลารายงานไว้คือ "19 กุมภาพันธ์ 2024 เวลา 21:08:10 น." สำหรับ Report1 และ "19 กุมภาพันธ์ 2024 เวลา 21:55:10 น." สำหรับ Report2 เนื่องจากระบบตัดค่าของช่อง scheduled_report_time ไว้ที่ระดับชั่วโมง รายงานทั้ง 2 ฉบับจึงมีค่า 1708376890 (ค่าที่เข้ารหัสสำหรับ "19 กุมภาพันธ์ 2024 เวลา 21:00 น.") เป็นค่าของช่อง scheduled_report_time

ช่องอื่นๆ ทั้งหมดเหมือนกัน ดังนั้นรายงานทั้ง 2 ฉบับจึงมีรหัสที่แชร์เดียวกัน และเนื่องจากทั้ง 2 รายงานมีรหัสที่แชร์เดียวกัน จึงต้องรวมอยู่ในกลุ่มเดียวกัน

หากรายงาน 1 จัดกลุ่มอยู่ในกลุ่มที่ดำเนินการสำเร็จก่อนหน้านี้ และรายงาน 2 ได้รับการประมวลผลในกลุ่มถัดไป กลุ่มที่มีรายงาน 2 จะดำเนินการไม่สำเร็จพร้อมข้อผิดพลาด PRIVACY_BUDGET_EXHAUSTED หากเกิดเหตุการณ์เช่นนี้ ให้นำรายงานที่มีรหัสที่แชร์ซึ่งจัดกลุ่มเรียบร้อยแล้วในก่อนหน้านี้ออก แล้วลองอีกครั้ง ดูข้อมูลเพิ่มเติมเกี่ยวกับข้อผิดพลาดนี้ได้ที่รหัสข้อผิดพลาดและการบรรเทาปัญหาสําหรับบริการรวบรวมข้อมูล

รูปที่ 2 กลุ่มที่ 2 มีรายงานที่มีรหัสที่แชร์เหมือนกันกับรายงานในกลุ่มที่ 1 กลุ่มที่ 2 จึงดำเนินการไม่สำเร็จ

คีย์การรวมข้อมูลที่ประกาศไว้ล่วงหน้า

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

จากมุมมองด้านความเป็นส่วนตัว ระบบจะเพิ่มข้อมูลซอร์สโค้ดลงในคีย์ทั้งหมดที่ประกาศไว้ล่วงหน้าในโดเมนเอาต์พุต แม้ว่าจะไม่มีรายงานจริงที่ตรงกับคีย์หนึ่งๆ ก็ตาม การระบุโดเมนเอาต์พุตจะช่วยป้องกันจากการโจมตีที่การปรากฏของคีย์ในเอาต์พุตจะเปิดเผยข้อมูลเกี่ยวกับผู้ใช้หรือเหตุการณ์เดียว ตัวอย่างเช่น หากคุณแสดงแคมเปญต่อผู้ใช้เพียงรายเดียว การได้รับคีย์ในเอาต์พุตจะแสดงให้เห็นว่าผู้ใช้ทํา Conversion ในภายหลัง แม้ว่าจะมีการเพิ่มสัญญาณรบกวนก็ตาม การระบุโดเมนนี้ก่อนจะช่วยให้มั่นใจได้ว่าโดเมนดังกล่าวจะไม่เปิดเผยข้อมูลใดๆ เกี่ยวกับการมีส่วนร่วมของผู้ใช้

คุณสามารถประกาศคีย์ 128 บิตเหล่านี้ใน Attribution Reporting API หรือ Private Aggregation API และใช้คีย์ดังกล่าวเพื่อเข้ารหัสมิติข้อมูลที่ต้องการติดตาม

ระบบจะพิจารณาเฉพาะคีย์ที่ประกาศไว้ล่วงหน้าสำหรับการรวมและรวมไว้ในรายงานสรุป ค่ารวมของกลุ่มในรายงานสรุปจะมีการเพิ่มสัญญาณรบกวนทางสถิติ ซึ่งจะแสดงในรายงานสรุปที่สร้างขึ้น

รูปที่ 3 รายงานสรุปมีเฉพาะคีย์ที่ประกาศไว้ล่วงหน้า หรือที่เรียกว่าที่เก็บ

หากคีย์การรวมรวมอยู่ในไฟล์โดเมนเอาต์พุตแต่ไม่อยู่ในรายงานกลุ่ม แม้ว่าค่ารวมจะเท่ากับ 0 แต่รายงานสรุปสุดท้ายก็อาจมีค่าที่ไม่ใช่ 0 เนื่องจากมีการเพิ่มข้อมูลรบกวนเพื่อรักษาความเป็นส่วนตัว