سرویس تجمیع، گزارشهای خلاصهای از دادههای تبدیل دقیق و اندازهگیریهای دسترسی را از گزارشهای خام قابل تجمیع تولید میکند. برای حفظ حریم خصوصی و امنیت دادههای کاربر، سرویس تجمیع از چارچوبی استفاده میکند که از حریم خصوصی تفاضلی (DP) پشتیبانی میکند تا میزان اطلاعاتی را که این گزارشها در مورد کاربران منفرد فاش میکنند، تعیین و محدود کند.
این راهنما ابزارها و استراتژیهایی را برای ایجاد گزارشهای تجمیعی که به ایمن نگه داشتن دادههای مربوط به کاربران شخصی کمک میکنند، مورد بحث قرار میدهد:
- گزارشهای خلاصه با نویز اضافه ایجاد کنید
- بودجه مشارکت را تعیین کنید
- استراتژیهایی برای دستهبندی گزارشها
- گزارشهای تکراری را به صورت دستهای مدیریت کنید
- گزارشها را با یک شناسه مشترک مدیریت کنید
- از کلیدهای تجمیع از پیش اعلامشده استفاده کنید
گزارشهای خلاصه با نویز اضافه
وقتی گزارشهای قابل تجمیع را دستهبندی میکنید، سرویس تجمیع یک گزارش خلاصه ایجاد میکند. این گزارش خلاصه، مجموعهای از تمام سهمهای تمام کلیدهای دامنه از پیش تعریف شده، به همراه نویز آماری اضافه شده است.
نویز اضافه شده به گزارشها به تعداد گزارشهای تجمیعشده، مقادیر گزارشهای منفرد یا مقادیر گزارش تجمیعشده بستگی ندارد. نویز از یک نسخه گسسته از توزیع لاپلاس استخراج میشود و به بودجه مشارکت (حساسیت L1 ) که توسط کلاینت اعمال میشود، وابسته به API اندازهگیری مربوطه و پارامتر حریم خصوصی epsilon مقیاسبندی میشود.
برای کسب اطلاعات بیشتر در مورد نویز و پیامدهای آن برای دادههای گزارش، به درک نویز در گزارشهای خلاصه مراجعه کنید.
بودجه مشارکت
برای کنترل حساسیت یک گزارش خلاصه، تعداد مشارکتهای ارسالی در یک فراخوانی به یک محدودیت خاص برای مشارکت گره خورده است که به عنوان بودجه مشارکت نیز شناخته میشود. بودجه مشارکت بسته به اینکه از API گزارشدهی انتسابی یا API تجمیع خصوصی استفاده میکنید، متفاوت است.
برای کسب اطلاعات بیشتر در مورد نحوه تعیین بودجه مشارکت برای هر API، به بخشهای زیر از مستندات API مراجعه کنید:
- API گزارشدهی تخصیص، محدودسازی مشارکت و بودجهبندی
- محدودیتهای مشارکت API خصوصی Aggregation
- محدودسازی و بودجهبندی مشارکتها در API خصوصی Aggregation
استراتژیهایی برای دستهبندی گزارشها
وقتی گزارشهای قابل جمعآوری را دستهبندی میکنید، بهینهسازی استراتژیهای دستهبندی به گونهای که از محدودیتهای حریم خصوصی تجاوز نشود، مهم است. دو مفهوم مهم برای دستهبندی صحیح گزارشها ، قانون «عدم تکرار» و ایده دستهبندیهای مجزا هستند.
قانون «تکراری ممنوع»
سرویس تجمیع، قانون «عدم تکرار» را اجرا میکند. این قانون بیان میکند که یک گزارش تجمیعپذیر، که به طور منحصر به فرد با report_id مشخص میشود، فقط میتواند یک بار در یک دسته ظاهر شود. اگر یک گزارش تجمیعپذیر بیش از یک بار در هر دسته ظاهر شود، اولین گزارش در تجمیع گنجانده میشود، گزارشهای بعدی با report_id یکسان کنار گذاشته میشوند و دسته با موفقیت تکمیل میشود.
این قانون همچنین بیان میکند که یک شناسه مشترک نمیتواند در بیش از یک دسته ظاهر شود. اگر یک شناسه مشترک قبلاً در یک دسته موفق قبلی گنجانده شده باشد، دسته بعدی که شامل همان شناسه مشترک نیز باشد، ناموفق خواهد بود.
بدون قانون «عدم وجود نسخههای تکراری»، یک مهاجم میتواند با دستکاری محتویات یک دسته از طریق گنجاندن نسخههای تکراری یک گزارش در یک یا چند دسته، به محتوای یک دسته خاص دسترسی پیدا کند.
برای کسب اطلاعات بیشتر در مورد اجرای قانون «عدم تکرار» در یک دسته از گزارشها یا در چندین دسته، به بخش «گزارشهای تکراری در دستهها» مراجعه کنید.
دستههای جدا از هم
برای جلوگیری از موقعیتهایی که در آنها بین دستهها همپوشانی وجود دارد، سرویس تجمیع، دستههای مجزا را اعمال میکند. این بدان معناست که دو یا چند دسته نمیتوانند شامل گزارشهایی باشند که یک شناسه مشترک مشترک دارند. یک شناسه مشترک ترکیبی از دادههای جمعآوریشده از فیلد 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 فیلدهای اطلاعات مشترکی دارند. هر دو گزارش دارای API، نسخه، attribution_destination ، reporting_origin و source_registration_time یکسانی هستند. از آنجایی که report_id بخشی از شناسه مشترک نیست، میتوانید این تفاوت را نادیده بگیرید.
در مثالهای زیر برای Report1 و Report2 ، مقدار scheduled_report_time یکسان است.
اطلاعات به اشتراک گذاشته شده در گزارش ۱ :
"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"
}
زمانهای گزارش زمانبندیشده برای Report1 «۱۹ فوریه ۲۰۲۴، ساعت ۹:۰۸:۱۰ شب» و برای Report2 «۱۹ فوریه ۲۰۲۴، ساعت ۹:۵۵:۱۰ شب» است. از آنجایی که مقدار فیلد scheduled_report_time به ساعت خلاصه شده است، هر دو گزارش دارای 1708376890 (مقدار کدگذاریشده برای «۱۹ فوریه ۲۰۲۴، ساعت ۹ شب») به عنوان مقدار فیلد scheduled_report_time هستند.
با یکسان بودن سایر فیلدها و شناسه فیلتر، هر دو گزارش دارای شناسه مشترک یکسانی هستند. و از آنجایی که هر دو گزارش دارای شناسه مشترک یکسانی هستند، هر دو باید در یک دسته قرار گیرند.
اگر Report1 در یک دستهی موفق قبلی دستهبندی شده باشد و Report2 در یک دستهی بعدی پردازش شود، دستهای که Report2 در آن قرار دارد با خطای PRIVACY_BUDGET_EXHAUSTED مواجه میشود. در این صورت، گزارشهایی را که با شناسهی مشترک در دستههای قبلی با موفقیت دستهبندی شدهاند، حذف کرده و دوباره امتحان کنید. برای اطلاعات بیشتر در مورد این خطا، به کدهای خطا و راهکارهای کاهش آن برای سرویس تجمیع مراجعه کنید.
کلیدهای تجمیع از پیش اعلامشده
وقتی یک دسته (batch) را به سرویس تجمیع (Aggregation Service) ارسال میکنید، باید شامل گزارشهای تجمیعی دریافتی از مبدا گزارش و فایل دامنه خروجی باشد. دامنه خروجی شامل کلیدها یا سطلهایی (buckets) است که از گزارشهای تجمیعپذیر بازیابی میشوند.
از دیدگاه حریم خصوصی، حتی زمانی که هیچ گزارش واقعی با یک کلید خاص مطابقت نداشته باشد، به تمام کلیدهای از پیش اعلام شده در دامنه خروجی نویز اضافه میشود. مشخص کردن دامنه خروجی در برابر حملهای محافظت میکند که در آن وجود یک کلید در خروجی چیزی در مورد یک کاربر یا رویداد واحد را فاش میکند. به عنوان مثال، اگر فقط یک کمپین را به یک کاربر نشان داده باشید، دریافت یک کلید در خروجی نشان میدهد که کاربر بعداً تبدیل شده است، حتی با وجود نویز اضافه شده. با مشخص کردن این دامنه در ابتدا، میتوانید مطمئن باشید که چیزی در مورد مشارکتهای کاربر فاش نمیشود.
شما میتوانید این کلیدهای ۱۲۸ بیتی را در API گزارشدهی نسبتدهی یا API تجمیع خصوصی اعلام کنید و از آنها برای رمزگذاری ابعادی که میخواهید ردیابی کنید استفاده کنید.
فقط کلیدهای از پیش اعلامشده برای تجمیع در نظر گرفته میشوند و در گزارش خلاصه گنجانده میشوند. مقادیر تجمیعشدهی باکتها در گزارش خلاصه دارای نویز آماری اضافه هستند که در گزارش خلاصهی ایجاد شده منعکس میشود.
اگر یک کلید تجمیع در فایل دامنه خروجی گنجانده شده باشد اما در گزارش دستهای قرار نداشته باشد، حتی اگر مقدار تجمیع شده صفر باشد، گزارش خلاصه نهایی احتمالاً به دلیل نویز اضافه شده برای حفظ حریم خصوصی، غیر صفر خواهد بود.