บริการรวมข้อมูลจะสร้างรายงานสรุปของข้อมูล Conversion แบบละเอียดและการวัดการเข้าถึงจากรายงานแบบรวมที่ยังไม่ได้ประมวลผล บริการรวบรวมข้อมูลใช้เฟรมเวิร์กที่รองรับความเป็นส่วนตัวเชิงอนุพันธ์ (DP) เพื่อวัดปริมาณและจำกัดปริมาณข้อมูลที่รายงานเหล่านี้เปิดเผยเกี่ยวกับผู้ใช้แต่ละราย เพื่อรักษาความเป็นส่วนตัวและความปลอดภัยของข้อมูลผู้ใช้
คู่มือนี้จะกล่าวถึงเครื่องมือและกลยุทธ์ในการสร้างรายงานที่รวบรวมได้ ซึ่งจะช่วยรักษาข้อมูลเกี่ยวกับผู้ใช้แต่ละรายให้ปลอดภัย
- สร้างรายงานสรุปที่มีการเพิ่มสัญญาณรบกวน
- กำหนดงบประมาณการมีส่วนร่วม
- กลยุทธ์สําหรับการจัดกลุ่มรายงาน
- จัดการรายงานที่ซ้ำกันเป็นกลุ่ม
- จัดการรายงานด้วยรหัสที่แชร์ทั่วไป
- ใช้คีย์การรวมที่ประกาศไว้ล่วงหน้า
รายงานสรุปที่มีการเพิ่มสัญญาณรบกวน
เมื่อจัดกลุ่มรายงานที่รวมได้ บริการรวมข้อมูลจะสร้างรายงานสรุป รายงานสรุปนี้คือการรวบรวมการมีส่วนร่วมทั้งหมดของคีย์โดเมนที่กำหนดไว้ล่วงหน้าทั้งหมด โดยมีการเพิ่มสัญญาณรบกวนทางสถิติ
สัญญาณรบกวนที่เพิ่มลงในรายงานไม่ได้ขึ้นอยู่กับจำนวนรายงานที่รวบรวม มูลค่าของรายงานแต่ละรายการ หรือมูลค่าของรายงานที่รวบรวม ระบบจะดึงข้อมูลสัญญาณรบกวนจากการแจกแจงแบบลาปลาซเวอร์ชันแยก และปรับขนาดให้เป็นงบประมาณการมีส่วนร่วม (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 เดียวกัน และดำเนินการกับกลุ่มจนเสร็จสมบูรณ์
นอกจากนี้ กฎยังระบุว่ารหัสที่แชร์เดียวกันจะปรากฏในหลายชุดไม่ได้ หากมีการระบุรหัสที่แชร์ไว้แล้วในกลุ่มที่สำเร็จก่อนหน้านี้ กลุ่มที่ตามมาซึ่งมีรหัสที่แชร์เดียวกันจะล้มเหลว
หากไม่มีกฎ "ห้ามซ้ำ" ผู้โจมตีอาจได้รับข้อมูลเชิงลึกเกี่ยวกับเนื้อหาของกลุ่มข้อมูลที่เฉพาะเจาะจงโดยการดัดแปลงเนื้อหาของกลุ่มข้อมูลผ่านการรวมสำเนารายงานที่ซ้ำกันไว้ในกลุ่มข้อมูลเดียวหรือหลายกลุ่ม
ดูข้อมูลเพิ่มเติมเกี่ยวกับการบังคับใช้กฎ "ห้ามซ้ำ" ภายในกลุ่มรายงานหรือในหลายกลุ่มได้ที่รายงานที่ซ้ำกันภายในกลุ่ม
การประมวลผลแบบกลุ่มที่ไม่ต่อเนื่อง
บริการรวบรวมข้อมูลจะบังคับใช้ชุดข้อมูลที่ไม่ทับซ้อนกันเพื่อหลีกเลี่ยงสถานการณ์ที่ชุดข้อมูลทับซ้อนกัน ซึ่งหมายความว่าชุดข้อมูล 2 ชุดขึ้นไปต้องไม่มีรายงานที่มีรหัสที่แชร์ร่วมกัน รหัสที่ใช้ร่วมกันคือการรวมข้อมูลที่รวบรวมจากฟิลด์ shared_info ของรายงานที่รวบรวมได้เข้ากับรหัสการกรองจากคำของาน หากไม่ได้ระบุรหัสการกรอง ระบบจะใช้ค่าเริ่มต้นเป็น 0
ในshared_infoตัวอย่างฟิลด์attribution_destination (สําหรับการรายงานผลการระบุแหล่งที่มา) reporting_origin scheduled_report_time source_registration_time (สําหรับการรายงานผลการระบุแหล่งที่มา) และ version คุณจะเห็น API ฟิลด์เหล่านี้ ยกเว้น 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 รายงานมีรหัสที่แชร์เดียวกัน จึงต้องรวมไว้ในชุดเดียวกัน
หากมีการจัดกลุ่ม Report1 ในกลุ่มที่สำเร็จก่อนหน้านี้ และมีการประมวลผล Report2 ในกลุ่มถัดไป กลุ่มที่มี Report2 จะล้มเหลวโดยมีข้อผิดพลาด PRIVACY_BUDGET_EXHAUSTED หากเกิดกรณีนี้ ให้นำรายงานที่มีรหัสที่แชร์ซึ่งจัดกลุ่มสำเร็จในกลุ่มก่อนหน้านี้ออก แล้วลองอีกครั้ง ดูข้อมูลเพิ่มเติมเกี่ยวกับข้อผิดพลาดนี้ได้ที่รหัสข้อผิดพลาดและการลดผลกระทบสำหรับบริการรวบรวมข้อมูล
คีย์การรวบรวมที่ประกาศไว้ล่วงหน้า
เมื่อส่งกลุ่มไปยังบริการรวมข้อมูล กลุ่มดังกล่าวต้องมีทั้งรายงานที่รวมได้ซึ่งได้รับจากแหล่งที่มารายงานและไฟล์โดเมนเอาต์พุต โดเมนเอาต์พุตมีคีย์หรือที่เก็บข้อมูลที่ดึงมาจากรายงานที่รวบรวมได้
ในมุมมองด้านความเป็นส่วนตัว ระบบจะเพิ่มสัญญาณรบกวนลงในคีย์ทั้งหมดที่ประกาศล่วงหน้าในโดเมนเอาต์พุต แม้ว่าจะไม่มีรายงานจริงที่ตรงกับคีย์ใดคีย์หนึ่งก็ตาม การระบุโดเมนเอาต์พุตจะช่วยป้องกันการโจมตีที่การมีคีย์ในเอาต์พุตเผยให้เห็นข้อมูลเกี่ยวกับผู้ใช้หรือเหตุการณ์เดียว ตัวอย่างเช่น หากคุณแสดงแคมเปญต่อผู้ใช้เพียงคนเดียว การรับคีย์ในเอาต์พุตจะเผยให้เห็นว่าผู้ใช้ทำ Conversion ในภายหลัง แม้ว่าจะมีการเพิ่มสัญญาณรบกวนก็ตาม การระบุโดเมนนี้ก่อนจะช่วยให้มั่นใจได้ว่าโดเมนจะไม่เปิดเผยข้อมูลใดๆ เกี่ยวกับการมีส่วนร่วมของผู้ใช้
คุณประกาศคีย์ 128 บิตเหล่านี้ได้ทั้งใน Attribution Reporting API หรือ Private Aggregation API และใช้เพื่อเข้ารหัสมิติข้อมูลที่ต้องการติดตาม
ระบบจะพิจารณาเฉพาะคีย์ที่ประกาศไว้ล่วงหน้าสำหรับการรวบรวมและรวมไว้ในรายงานสรุป ค่ารวมของกลุ่มในรายงานสรุปจะมีการเพิ่มสัญญาณรบกวนทางสถิติ ซึ่งจะแสดงในรายงานสรุปที่สร้างขึ้น
หากรวมคีย์การรวมไว้ในไฟล์โดเมนเอาต์พุต แต่ไม่ได้อยู่ในรายงานกลุ่ม แม้ว่าค่ารวมจะเป็น 0 แต่รายงานสรุปขั้นสุดท้ายก็อาจไม่ใช่ 0 เนื่องจากมีการเพิ่มสัญญาณรบกวนเพื่อรักษาความเป็นส่วนตัว