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