Dịch vụ tổng hợp tạo báo cáo tóm tắt về dữ liệu chi tiết về lượt chuyển đổi và số liệu đo lường phạm vi tiếp cận từ các báo cáo tổng hợp thô. Để đảm bảo quyền riêng tư và tính bảo mật của dữ liệu người dùng, Dịch vụ tổng hợp sử dụng một khung hỗ trợ quyền riêng tư biệt lập (DP) để định lượng và giới hạn lượng thông tin mà các báo cáo này tiết lộ về từng người dùng.
Hướng dẫn này thảo luận về các công cụ và chiến lược để tạo báo cáo tổng hợp giúp bảo mật dữ liệu về từng người dùng:
- Tạo báo cáo tóm tắt có thêm tạp âm
- Đặt ngân sách đóng góp
- Chiến lược tạo báo cáo theo lô
- Sử dụng khoá tổng hợp được khai báo trước
Báo cáo tóm tắt có thêm tiếng ồn
Khi bạn phân nhóm các báo cáo tổng hợp, Dịch vụ tổng hợp sẽ tạo một báo cáo tóm tắt. Báo cáo tóm tắt này là tổng hợp tất cả các giá trị đóng góp của tất cả khoá miền được xác định trước, cùng với độ nhiễu thống kê.
Độ nhiễu được thêm vào báo cáo không phụ thuộc vào số lượng báo cáo được tổng hợp, giá trị báo cáo riêng lẻ hoặc giá trị báo cáo tổng hợp. Độ nhiễu được lấy từ một phiên bản rời rạc của phân phối Laplace và được điều chỉnh theo ngân sách đóng góp (độ nhạy L1) do ứng dụng thực thi tuỳ thuộc vào API đo lường tương ứng và tham số quyền riêng tư epsilon.
Để tìm hiểu thêm về tạp âm và tác động của tạp âm đối với dữ liệu báo cáo, hãy xem bài viết Tìm hiểu về tạp âm trong báo cáo tóm tắt.
Ngân sách đóng góp
Để kiểm soát độ nhạy của báo cáo tóm tắt, số lượng đóng góp được truyền trong một lệnh gọi được liên kết với một giới hạn đóng góp cụ thể, còn gọi là ngân sách đóng góp. Ngân sách đóng góp sẽ khác nhau tuỳ thuộc vào việc bạn đang sử dụng API Báo cáo phân bổ hay API Tổng hợp riêng tư.
Để tìm hiểu thêm về cách đặt ngân sách đóng góp cho từng API, hãy xem các phần tài liệu sau về API:
- Giới hạn và lập ngân sách cho mức đóng góp của Attribution Reporting API
- Giới hạn đóng góp của Private Aggregation API
- Giới hạn và lập ngân sách cho khoản đóng góp API Tổng hợp riêng tư
Chiến lược tạo báo cáo theo lô
Khi bạn tạo báo cáo tổng hợp theo lô, điều quan trọng là bạn phải tối ưu hoá chiến lược tạo lô để không vượt quá các giới hạn về quyền riêng tư. Có hai khái niệm quan trọng để tạo báo cáo theo lô một cách chính xác là quy tắc"không có bản sao" và ý tưởng về các lô không liên kết.
Quy tắc "Không trùng lặp"
Dịch vụ tổng hợp thực thi quy tắc "không trùng lặp". Quy tắc này nêu rõ rằng một báo cáo tổng hợp (được xác định duy nhất bằng report_id) chỉ có thể xuất hiện một lần trong một lô. Nếu một báo cáo tổng hợp xuất hiện nhiều lần trong mỗi lô, thì báo cáo đầu tiên sẽ được đưa vào quá trình tổng hợp, các báo cáo tiếp theo có cùng report_id sẽ bị loại bỏ và lô sẽ hoàn tất thành công.
Quy tắc này cũng nêu rõ rằng cùng một báo cáo không được xuất hiện trong nhiều lô. Nếu một báo cáo đã có trong một lô trước đó đã thành công, thì lô sau đó cũng có cùng báo cáo đó sẽ không thành công.
Nếu không có quy tắc "không có bản sao", kẻ tấn công có thể nắm được thông tin chi tiết về nội dung của một lô cụ thể bằng cách thao túng nội dung của các lô thông qua việc đưa các bản sao trùng lặp của một báo cáo vào một lô hoặc nhiều lô.
Để tìm hiểu thêm về cách thực thi quy tắc "không trùng lặp" trong một lô báo cáo hoặc trên nhiều lô, hãy xem bài viết Báo cáo trùng lặp trong lô.
Các lô không liên kết
Để tránh tình huống các lô bị trùng lặp, Dịch vụ tổng hợp sẽ thực thi các lô không liên kết. Điều này có nghĩa là hai hoặc nhiều lô không được chứa các báo cáo có cùng một mã nhận dạng dùng chung. Mã nhận dạng dùng chung là tổ hợp dữ liệu được thu thập từ trường shared_info của một báo cáo tổng hợp.
Trong ví dụ về trường shared_info sau đây, bạn có thể thấy API, attribution_destination (dành cho Báo cáo phân bổ), reporting_origin, scheduled_report_time, source_registration_time (dành cho Báo cáo phân bổ) và version. Các trường này, ngoại trừ report_id, sẽ góp phần tạo nên mã nhận dạng dùng chung.
"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"
}
Vì source_registration_time bị cắt bớt theo ngày và scheduled_report_time bị cắt bớt theo giờ, nên có một số báo cáo có cùng mã nhận dạng được chia sẻ. Trong ví dụ này, Report1 và Report2 có các trường thông tin dùng chung. Cả hai báo cáo đều có cùng API, phiên bản, attribution_destination, reporting_origin và source_registration_time. Vì report_id không phải là một phần của mã nhận dạng dùng chung, nên bạn có thể bỏ qua sự khác biệt này.
Trong các ví dụ sau đây cho Report1 và Report2, giá trị scheduled_report_time giống nhau.
Report1 đã chia sẻ thông tin:
"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 đã chia sẻ thông tin:
"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"
}
Thời gian gửi báo cáo định kỳ là "21:08:10 ngày 19 tháng 2 năm 2024" đối với Báo cáo 1 và "21:55:10 ngày 19 tháng 2 năm 2024" đối với Báo cáo 2. Vì giá trị của trường scheduled_report_time bị cắt bớt thành giờ, nên cả hai báo cáo đều có 1708376890 (giá trị được mã hoá cho "9 giờ tối ngày 19 tháng 2 năm 2024") làm giá trị cho trường scheduled_report_time.
Tất cả các trường khác đều giống nhau, vì vậy, cả hai báo cáo đều có cùng mã nhận dạng dùng chung. Và vì cả hai báo cáo đều có cùng một mã nhận dạng dùng chung, nên cả hai báo cáo đều phải nằm trong cùng một lô.
Nếu Report1 được tạo lô trong một lô trước đó đã thành công và Report2 được xử lý trong một lô tiếp theo, thì lô có Report2 sẽ không thành công với lỗi PRIVACY_BUDGET_EXHAUSTED. Nếu điều này xảy ra, hãy xoá những báo cáo có mã nhận dạng dùng chung đã được tạo thành lô thành công trong các lô trước đó rồi thử lại. Để biết thêm thông tin về lỗi này, hãy xem phần Mã lỗi và biện pháp giảm thiểu cho Dịch vụ tổng hợp.
Khoá tổng hợp được khai báo trước
Khi bạn gửi một lô báo cáo đến Dịch vụ tổng hợp, lô báo cáo đó phải bao gồm cả các báo cáo tổng hợp nhận được từ nguồn báo cáo và tệp miền đầu ra. Miền đầu ra chứa các khoá hoặc nhóm được truy xuất từ các báo cáo tổng hợp.
Từ quan điểm về quyền riêng tư, nhiễu được thêm vào tất cả các khoá được khai báo trước trong miền đầu ra, ngay cả khi không có báo cáo thực nào khớp với một khoá cụ thể. Việc chỉ định miền đầu ra giúp bảo vệ khỏi một cuộc tấn công trong đó sự hiện diện của khoá trong đầu ra cho biết thông tin về một người dùng hoặc sự kiện. Ví dụ: nếu bạn chỉ hiển thị một chiến dịch cho một người dùng, thì việc nhận được khoá trong kết quả sẽ cho biết rằng người dùng đó đã chuyển đổi sau đó, ngay cả khi có thêm nhiễu. Bằng cách chỉ định miền này trước, bạn có thể chắc chắn rằng miền này không tiết lộ bất kỳ thông tin nào về nội dung đóng góp của người dùng.
Bạn có thể khai báo các khoá 128 bit này trong Attribution Reporting API hoặc Private Aggregation API và sử dụng các khoá này để mã hoá các phương diện mà bạn muốn theo dõi.
Chỉ các khoá được khai báo trước mới được xem xét để tổng hợp và đưa vào báo cáo tóm tắt. Các giá trị tổng hợp của các bộ chứa trong báo cáo tóm tắt có thêm nhiễu thống kê, được phản ánh trong báo cáo tóm tắt đã tạo.
Nếu một khoá tổng hợp có trong tệp miền đầu ra nhưng không nằm trong báo cáo theo lô, thì ngay cả khi giá trị tổng hợp bằng 0, báo cáo tóm tắt cuối cùng có thể sẽ không bằng 0 do có thêm nhiễu để bảo vệ quyền riêng tư.