پیشنهاد گزارش انتساب در ژانویه 2022 به روز می شود

پیشنهاد Attribution Reporting برای رسیدگی به بازخورد جامعه، از تغییرات مکانیسم API تا عملکرد جدید، دستخوش تغییراتی شده است.

تغییرات

این پست برای کیست؟

این پست برای شماست:

  • اگر قبلاً API را می‌دانید - برای مثال، اگر در حال مشاهده یا شرکت در بحث‌های مربوط به مخزن WICG بوده‌اید و می‌خواهید دسته‌ای از تغییرات ایجاد شده در پیشنهاد در ژانویه 2022 را درک کنید.
  • اگر از Attribution Reporting API در نسخه آزمایشی یا آزمایشی در تولید استفاده می‌کنید.

اگر به تازگی با این API شروع کرده اید و/یا هنوز آن را آزمایش نکرده اید، به جای آن مستقیماً به مقدمه API بروید.

مهاجرت در پیش است

هنگامی که این تغییرات در Chrome پیاده‌سازی شدند: اگر از گزارش‌های سطح رویداد از API گزارش Attribution در یک نسخه آزمایشی یا در آزمایشی در تولید (آزمایش اولیه) استفاده می‌کنید، باید کد خود را ویرایش کنید تا API به کار خود ادامه دهد. همچنین می توانید از ویژگی های جدید استفاده کنید.

این مقاله همچنین تغییرات را برای گزارش‌های جمع‌آوری‌شده فهرست می‌کند. با این حال، اگر این تغییرات اجرا شوند، نیازی به هیچ اقدام یا انتقالی نخواهند داشت، زیرا هنوز هیچ مرورگری برای گزارش‌های جمع‌آوری‌شده در زمان نوشتن این مقاله پیاده‌سازی نشده است.

تغییر نام

گزارش های خلاصه و گزارش های جمع آوری

آنچه شما ممکن است دیده باشید که به عنوان گزارش های انبوه توصیف می شود، اکنون به عنوان گزارش های خلاصه نامیده می شود.

گزارش‌های خلاصه خروجی نهایی از تجمیع گزارش‌های چندتایی جمع‌آوری‌شده است که قبلاً مشارکت یا مشارکت هیستوگرام نامیده می‌شد.

مکانیسم API تغییر می کند

ثبت منبع مبتنی بر سربرگ (گزارش‌های سطح رویداد)

چه چیزی در حال تغییر است و چرا؟

وقتی کاربر یک تبلیغ را مشاهده یا کلیک می‌کند، مرورگر - به صورت محلی در دستگاه کاربر - این رویداد را در کنار پارامترهایی که مختص گزارش انتساب هستند (مانند attributionsourceeventid ، attributiondestination ، attributionexpiry و سایر پارامترها) ثبت می‌کند. مقادیر این پارامترها توسط adtech تنظیم می شود.

نحوه تنظیم این پارامترها در حال تغییر است.

در پیشنهاد قبلی، پارامترها باید در سمت کلاینت گنجانده می شدند: یا در تگ های لنگر به عنوان ویژگی های HTML، یا به عنوان آرگومان های فراخوانی مبتنی بر JS. پارامترها باید در زمان کلیک یا مشاهده شناخته می شدند.

در پروپوزال جدید، مقدار این پارامترها به جای آن بر روی سرور adtech تعریف شده است.

نمودار ثبت منبع مبتنی بر هدر

این دارای چندین مزیت است، به ویژه از نظر امنیت: مکانیسم سرصفحه به منشاء گزارش -معمولاً یک adtech- کنترل مستقیم روی ثبت منبع انتساب در محدوده آنها می دهد. این تا حدی نگرانی های مربوط به تقلب را کاهش می دهد، زیرا با این تغییر یک مرورگر واقعی هرگز منبعی را بدون انتخاب منبع گزارش ثبت نمی کند.

ثبت منبع چگونه کار می کند؟

  1. برای یک تبلیغ مشخص، adtech اکنون باید یک ویژگی خاص سمت مشتری attributionsrc را تعریف کند. مقدار این ویژگی یک URL است که مرورگر به آن درخواست ارسال می کند. این درخواست شامل یک سرصفحه جدید HTTP Attribution-Reporting-Source-Info است که مقدار، navigation یا event, آن مشخص می کند که منبع به ترتیب یک کلیک یا یک نمایش است.
  2. به محض دریافت این درخواست، سرور ردیابی کلیک/مشاهده باید با یک سربرگ HTTP، Attribution-Reporting-Register-Source که حاوی پارامترهای انتساب مورد نظر است، پاسخ دهد.

  3. منبعی که این سرصفحه را برمی گرداند، اکنون مبدا گزارش است (که قبلاً به عنوان attributionreportto تعریف می شد).

    HTTP Response Header Attribution-Reporting-Register-Source :

    {
  "source_event_id": "267630968326743374",
  "destination": "https://toasters.example",
  "expiry": "604800000"
}

در توضیح فنی بیشتر بدانید

ثبت منابع انتساب

به بحث عمومی بپیوندید

شماره ۲۶۱

راه‌انداز اسناد مبتنی بر سرصفحه (گزارش‌های سطح رویداد)

چه چیزی در حال تغییر است و چرا؟

دقیقاً مانند کلیک کردن یا مشاهده ثبت نام، پیشنهاد جدید عامل تخصیص را - زمانی که یک adtech به مرورگر دستور می دهد تا یک تبدیل را ثبت کند - به یک رویکرد مبتنی بر هدر تغییر می دهد.
این مکانیسم با ثبت منبع مبتنی بر سرصفحه هماهنگ است و نسبت به مکانیزم تغییر مسیر که قبلاً استفاده می شد، متعارف تر است.

علاوه بر این، در پیشنهاد جدید، ویژگی attributionsrc در صفحه تبدیل مورد نیاز است.

دلیل منطقی مربوط به مجوزها است: در پیشنهاد قبلی، سایت سمت ماشه - معمولاً یک سایت تبلیغ‌کننده - کنترل کلی ویژگی را از طریق سرصفحه Permissions-Policy داشت، اما کنترل ریز و در سطح عنصر را نداشت. آیا یک عنصر می تواند درخواستی را برای یک طرف ارسال کند که در نهایت یک انتساب را ایجاد کند. attributionsrc این را تغییر می‌دهد: این نشانگر اجباری به تبلیغ‌کننده این امکان را می‌دهد که نظارت کند و از این رو کنترل کند که کدام عناصر می‌توانند یک انتساب را ایجاد کنند.

توجه داشته باشید که در سمت منبع - معمولاً یک سایت ناشر - یک کنترل در سطح صفحه از طریق Permissions-Policy و همچنین یک کنترل گسترده عنصر از طریق attributionsrc وجود دارد.

راه‌اندازی اسناد چگونه کار می‌کند؟

پس از دریافت یک درخواست پیکسل و تصمیم گیری در مورد طبقه بندی آن به عنوان تبدیل، یک adtech باید با یک HTTP جدید پاسخ دهد.
header Attribution-Reporting-Register-Event-Trigger .

مقدار این هدر نحوه برخورد با رویداد ماشه را به عنوان یک شی JSON مشخص می کند. این همان اطلاعاتی است که به عنوان پارامترهای پرس و جو در پیشنهاد قبلی تعریف شده بود.

HTTP Response Header Attribution-Reporting-Register-Event-Trigger :

    [{
        trigger_data: (unsigned 3-bit integer),
        trigger_priority: (signed 64-bit integer),
        deduplication_key: (signed 64-bit integer)
    }]

تغییر مسیر (اختیاری)

به صورت اختیاری، سرور adtech می‌تواند پاسخی را که حاوی Attribution-Reporting-Register-Event-Trigger است، یک پاسخ تغییر مسیر دهد. با این کار، اشخاص ثالث را قادر می سازد تا رویداد تبدیل را مشاهده کنند و به مرورگر دستور دهند تا آن را نسبت دهد.

تغییر مسیر اختیاری است. زمانی که هم یک adtech و هم شخص ثالث پیکسل در صفحه دارند، به آن نیازی نیست.

جزئیات بیشتر در گزارش شخص ثالث .

در توضیح فنی بیشتر بدانید

ایجاد اسناد

به بحث عمومی بپیوندید

شماره 91

بدون کارنامه (گزارش های جمع آوری)

چه چیزی در حال تغییر است و چرا؟

در پیشنهاد قبلی برای گزارش‌های انبوه، دسترسی جاوا اسکریپت برای فراخوانی یک Worklet - مکانیزم مبتنی بر جاوا اسکریپت - که این گزارش‌ها را تولید می‌کند، مورد نیاز بود.

در پروپوزال جدید نیازی به کارنامه نیست. در عوض، یک adtech قوانینی را که مرورگر باید برای تولید گزارش‌های جمع‌آوری استفاده کند، از طریق سرصفحه‌های HTTP، به صورت اعلامی تعریف می‌کند.

پیشنهاد جدید چندین مزیت را ارائه می دهد:

  • پیاده سازی مرورگر: طراحی جدید، بر خلاف طراحی Worklet، به طور قابل ملاحظه ای ساده تر است، زیرا به یک محیط اجرایی جدید در مرورگرها نیاز ندارد.
  • تجربه توسعه‌دهنده: طراحی جدید بر هدرها متکی است که معمولاً توسط توسعه‌دهندگان استفاده می‌شوند و به‌طور گسترده‌ای شناخته می‌شوند—بر خلاف worklets. همچنین برای ثبت منبع با سطح API هماهنگ است و یادگیری و استفاده از API را آسان‌تر می‌کند.
  • پذیرش: طراحی جدید سیستم‌های اندازه‌گیری موجود بیشتری را قادر می‌سازد تا از گزارش‌های جمع‌آوری استفاده کنند. بسیاری از راه‌حل‌های اندازه‌گیری فقط HTTP هستند: آنها به درخواست‌های تصویر - درخواست‌های پیکسل - که نیازی به دسترسی جاوا اسکریپت ندارند متکی هستند. اما از آنجایی که رویکرد Worklet به دسترسی جاوا اسکریپت نیاز داشت، ممکن است مهاجرت به برخی از سیستم‌های اندازه‌گیری موجود دشوار باشد.
  • استحکام: طراحی جدید به کاهش از دست دادن داده ها کمک می کند زیرا ادغام با معنایی keepalive آسان تر است، به عنوان مثال اگر یک کلیک یا مشاهده در هنگام خروج کاربر از صفحه ثبت شود.

مکانیسم بدون کار چگونه کار می کند؟

این مکانیسم اعلامی مبتنی بر سرصفحه‌های HTTP است - درست مانند ثبت منبع در سطح رویداد و سرصفحه ماشه انتساب. جزئیات بیشتر در این مورد در بخش های بعدی.

به بحث عمومی بپیوندید

شماره 194

ثبت منبع مبتنی بر سربرگ (گزارش‌های جمع‌آوری‌شده)

مکانیزم جدیدی برای ثبت منبع برای گزارش انبوه پیشنهاد شده است. این مکانیسم همانند ثبت منبع در سطح رویداد است.

فقط نام سرصفحه متفاوت است: Attribution-Reporting-Register-Aggregatable-Source .

در توضیح فنی بیشتر بدانید

ثبت منبع انتساب

راه‌انداز اسناد مبتنی بر سرصفحه (گزارش‌های جمع‌آوری‌شده)

مکانیزم جدیدی برای ثبت منبع برای گزارش انبوه پیشنهاد شده است. این مکانیسم همان عامل انتساب سطح رویداد است.

فقط نام سرصفحه متفاوت است: Attribution-Reporting-Register-Aggregatable-Trigger-Data .

در توضیح فنی بیشتر بدانید

ثبت نام عامل انتساب

ویژگی های جدید

گزارش شخص ثالث (گزارش‌های سطح رویداد و گزارش‌های جمع‌آوری‌شده)

چه چیزی در حال تغییر است و چرا؟

دو جنبه از پیشنهاد جدید به حمایت بهتر از موارد استفاده از گزارش شخص ثالث کمک می کند:

  • به صورت اختیاری، adtech ها می توانند درخواست های شبکه را به سرورهای adtechs دیگر هدایت کنند ، که به آن adtech های دیگر اجازه می دهد منبع خود را انجام دهند و ثبت نام را آغاز کنند. امروزه این یک روش معمول پیکربندی اشخاص ثالث است. این باعث می‌شود که API در میان سایر موارد در سیستم‌های گزارش‌دهی شخص ثالث موجود آسان‌تر شود.
  • منشاء گزارش - معمولاً Adtechs - دیگر محدودیت های حریم خصوصی را به اشتراک نمی گذارند . این از موارد استفاده پشتیبانی می کند که در آن چندین adtech با ناشران یا تبلیغ کنندگان یکسان کار می کنند.

گزارش شخص ثالث چگونه کار می کند؟

در پیشنهاد جدید، ثبت منبع مبتنی بر پاسخ و تریگر به هدرهای HTTP متکی است. یک adtech می تواند از تغییر مسیرهای HTTP برای این درخواست ها استفاده کند.

اگر درخواست کلیک/مشاهده در یک سایت ناشر (ثبت منبع) متعاقباً به چندین طرف هدایت شود، هر یک از این طرف‌ها می‌توانند این نما یا کلیک (رویداد منبع) را ثبت کنند.
به طور مشابه، یک adtech می‌تواند درخواست انتساب خاصی را که از یک سایت تبلیغ‌کننده ارسال شده است، تغییر مسیر دهد، و به چندین طرف دیگر اجازه می‌دهد یک تبدیل را ثبت کنند (محرک انتساب).

هر یک از طرفین می توانند به گزارش های جداگانه خود دسترسی داشته باشند و آنها را با داده های جداگانه پیکربندی کنند.

چندین عامل را بدون تغییر مسیر ثبت کنید

همچنین می توان چندین عامل انتساب را بدون استفاده از تغییر مسیر، با افزودن چندین عنصر پیکسل در سمت تبدیل (یکی در هر ماشه) ثبت کرد.

به بحث عمومی بپیوندید

شماره 91 شماره 261

اندازه‌گیری از طریق نمایش (گزارش‌های سطح رویداد و گزارش‌های جمع‌آوری‌شده)

چه چیزی در حال تغییر است و چرا؟

در پیشنهاد جدید، اندازه‌گیری از طریق نمایش و اندازه‌گیری کلیک به‌صورت یکپارچه کار می‌کنند:

  • registerattributionsrc ، ویژگی خاص view که به مرورگر دستور می‌دهد بازدیدها را در کنار کلیک‌ها ثبت کند، دیگر بخشی از پیشنهاد نیست .
  • مکانیسم‌های حفظ حریم خصوصی اکنون در بین کلیک و مشاهده یکپارچه شده‌اند. در این مورد، جزئیات را در نویز و شفافیت ببینید.

این تغییر برای همسویی با مکانیسم ثبت نام مبتنی بر سرصفحه جدید پیشنهاد شده است. همچنین زمانی که قصد پشتیبانی از اندازه گیری کلیک و نمایش از طریق را دارید، تجربه توسعه دهنده را ساده می کند.

اندازه گیری نمای از طریق چگونه کار می کند؟

اندازه‌گیری نمایش از طریق و اندازه‌گیری کلیک هر دو به ثبت بر اساس سربرگ متکی هستند.

در توضیح فنی بیشتر بدانید

گزارش‌های سطح رویداد (هم برای کلیک‌ها و هم برای بازدیدها)

به بحث عمومی بپیوندید

شماره ۲۶۱

اشکال زدایی / تجزیه و تحلیل عملکرد (گزارش های سطح رویداد و گزارش های جمع آوری)

چه چیزی در حال تغییر است و چرا؟

یک مکانیسم اشکال زدایی به پیشنهاد اضافه شده است تا به توسعه دهندگان کمک کند تا اشکالات را شناسایی کنند، و همچنین عملکرد گزارش Attribution را با راه حل های اندازه گیری مبتنی بر کوکی های موجود مقایسه کنند.

نمودار سیستم جدید اشکال زدایی مبتنی بر کوکی

اشکال زدایی چگونه کار می کند؟

هر دو ثبت منبع و ماشه یک پارامتر جدید debug_key را می پذیرند، یک عدد صحیح بدون علامت 64 بیتی (یعنی یک عدد بزرگ).

اگر گزارشی با کلیدهای اشکال‌زدایی منبع و راه‌انداز ایجاد شود و اگر یک کوکی Samesite=None ar_debug=1 در ظرف کوکی منبع گزارش در زمان ثبت منبع و راه‌انداز وجود داشته باشد، یک گزارش اشکال‌زدایی (JSON) به یک .well-known/attribution-reporting/debug ارسال می‌شود. نقطه پایانی .well-known/attribution-reporting/debug :

{
  "source_debug_key": 1234567890987,
  "trigger_debug_key": 4567654345028
}

گزارش‌های سطح رویداد و جمع‌آوری‌شده نیز شامل این دو پارامتر جدید می‌شوند تا بتوان آنها را با گزارش اشکال‌زدایی صحیح مرتبط کرد.

در توضیح فنی بیشتر بدانید

اختیاری: گزارش های اشکال زدایی گسترده

به بحث عمومی بپیوندید

شماره 174

قابلیت‌های فیلتر کردن (گزارش‌های سطح رویداد و گزارش‌های جمع‌آوری‌شده)

چه چیزی در حال تغییر است و چرا؟

از آنجایی که آنها از موارد استفاده مهم در اکوسیستم تبلیغاتی امروزی پشتیبانی می کنند، تعدادی از موارد استفاده اکنون در هر دو سطح رویداد و گزارش های انبوه پشتیبانی می شوند:

  • فیلتر تبدیل: یک تبدیل را بر اساس اطلاعات سمت منبع فیلتر کنید. برای مثال، داده‌های راه‌اندازی مختلف (داده‌های تبدیل) را برای کلیک‌ها و بازدیدهای تبلیغاتی انتخاب کنید.
  • عدم تطابق انتساب: فیلتر تبدیل هایی که به اشتباه نسبت داده شده اند. این یک نوع خاص از فیلتر تبدیل است. به‌عنوان مثال، تبدیل‌هایی را که با کلیک/مشاهده اشتباه آگهی مطابقت دارند، به دلیل محدوده مقصد etld+1 در API فیلتر کنید.

قابلیت های فیلترینگ چگونه کار می کنند؟ (برای گزارش های سطح رویداد)

یک فیلد source_data اختیاری در شیء JSON سمت منبع می‌تواند مواردی را تعریف کند که متعاقباً توسط مرورگر در زمان تبدیل برای اعمال منطق فیلتر استفاده می‌شوند.

  {
    source_event_id: "267630968326743374",
    destination: "https://toasters.example",
    expiry: "604800000"
    source_data: {
      conversion_subdomain: ["electronics.megastore"
                              "electronics2.megastore"],
      product: "198764",
      // Note that "source_type" will be automatically generated as one of {"navigation", "event"}
    }
  }

ثبت ماشه اکنون یک سرصفحه اختیاری Attribution-Reporting-Filters می پذیرد.

هدر پاسخ HTTP Attribution-Reporting-Filters :

{
  "conversion_subdomain": "electronics.megastore",
  "directory": "/store/electronics"
}

از طرف دیگر، سرصفحه Attribution-Reporting-Register-Event-Trigger را می توان با یک فیلد filters برای انجام فیلترهای انتخابی برای تنظیم trigger_data بر اساس source_data گسترش داد.

اگر کلیدهای موجود در فیلترهای JSON با کلیدهای source_data مطابقت داشته باشند، محرک است
در صورت خالی بودن تقاطع کاملاً نادیده گرفته می شود.

در توضیح فنی بیشتر بدانید

فیلترهای اسناد اختیاری

به بحث عمومی بپیوندید

شماره 194
شماره 201

حفاظت از حریم خصوصی تغییر می کند

نویز و شفافیت (گزارش‌های سطح رویداد و گزارش‌های جمع‌آوری‌شده)

چه چیزی در حال تغییر است و چرا؟

در پیشنهاد جدید، یکی از مکانیسم‌های حفظ حریم خصوصی برای گزارش‌ها بهبود یافته است: گزارش‌ها در معرض پاسخ‌های تصادفی هستند.
این بدان معنی است که برخی از تبدیل های واقعی به درستی گزارش می شوند. و در درصد معینی از مواقع، برخی از تبدیل‌های واقعی سرکوب می‌شوند یا برخی از تبدیل‌های جعلی اضافه می‌شوند .

این تکنیک جدید چند مزیت دارد:

  • مکانیزم حریم خصوصی را برای کلیک ها و بازدیدها یکپارچه می کند .
  • استدلال در مورد آن ساده تر از مکانیزمی است که در آن داده های ماشه (داده های تبدیل) و نویز پیوند منبع ماشه از هم جدا می شوند.
  • این یک چارچوب حریم خصوصی ایجاد می‌کند که می‌تواند با تنظیمات نویز مناسب، اطمینان حاصل کند که هیچ طرفی نمی‌تواند به API اعتماد کند تا با اطمینان بداند که یک کاربر خاص برای یک تبلیغ خاص تبدیل (یا نه) را انجام داده است.

این مکانیسم جدید جایگزین مکانیسم قبلی می شود که در آن 5 درصد از مواقع، داده های ماشه (داده های تبدیل) با یک مقدار تصادفی جایگزین می شدند.

علاوه بر این، مقدار احتمال پاسخ تصادفی شده به بدنه گزارش اضافه شده است (فیلد randomized_trigger_rate ). این فیلد احتمال (0 تا 1) را مشخص می کند که منبعی در معرض پاسخ تصادفی قرار گیرد.

این دو فایده اصلی دارد:

  • این باعث می‌شود که رفتار زیربنایی مرورگر برای طرف‌هایی که گزارش‌ها را دریافت می‌کنند (معمولاً adtechs) شفاف باشد .
  • برای آینده‌ای که API در مرورگرها پشتیبانی می‌شود مفید است: مرورگرهای مختلف ممکن است تصمیم بگیرند سطوح مختلفی از نویز را بسته به اهداف حریم خصوصی خود اعمال کنند، و طرف‌هایی که گزارش را مدیریت می‌کنند باید در این مورد قابل مشاهده باشند.

نویز چگونه کار می کند؟

در پروپوزال جدید، در زمان ثبت منبع (به عنوان مثال یک کلیک یا مشاهده آگهی ثبت می‌شود)، مرورگر به‌طور تصادفی تصمیم می‌گیرد که آیا به درستی تبدیل‌ها را نسبت می‌دهد و گزارش‌هایی را برای این کلیک/نمایش آگهی ارسال می‌کند یا اینکه آیا یک جعلی ایجاد می‌کند. خروجی در عوض

خروجی جعلی می تواند باشد:

  • هیچ گزارشی وجود ندارد — صرف نظر از اینکه کاربر تبدیل می کند یا خیر.
  • یک یا چند گزارش جعلی - صرف نظر از اینکه کاربر تبدیل می کند یا خیر.

در گزارش های جعلی، داده های ماشه (داده های تبدیل) تصادفی هستند: یک مقدار تصادفی 3 بیتی برای کلیک ها (هر عددی بین 0 تا 7) و یک مقدار تصادفی 1 بیتی برای بازدیدها (0 یا 1).

مانند گزارش های واقعی، گزارش های جعلی بلافاصله پس از تبدیل کاربر ارسال نمی شود. آنها در انتهای یک پنجره گزارش تصادفی ارسال می شوند.

سه پنجره گزارش برای کلیک وجود دارد (2 روز، 7 روز یا 30 روز پس از کلیک). هر گزارش جعلی به طور تصادفی به یکی از پنجره های گزارش اختصاص داده می شود.

به طور جداگانه، همانطور که پیشنهاد قبلی قبلاً گفته شد، ترتیب گزارش ها در یک پنجره تصادفی است.

در توضیح فنی بیشتر بدانید

نمونه های تبدیل جعلی پر سر و صدا

به بحث عمومی بپیوندید

شماره 84
شماره ۲۷۳

محدودیت های گزارش دهی (گزارش های سطح رویداد و گزارش های جمع آوری)

گزارش محدودیت مبدا

چه چیزی در حال تغییر است و چرا؟

پیشنهاد جدید به صراحت تعداد طرفین را که می توانند رویدادها را بین دو سایت اندازه گیری کنند محدود می کند .

  • حداکثر تعداد مبداهای گزارش‌دهی منحصربه‌فرد (معمولاً adtechs) که می‌توانند منابع را برای هر {ناشر، تبلیغ‌کننده} ثبت کنند، به 100 در 30 روز پیشنهاد می‌شود. این شمارنده برای هر کلیک یا مشاهده آگهی (رویداد منبع)، حتی مواردی که نسبت داده نشده اند، افزایش می یابد.
  • حداکثر تعداد مبداهای گزارش‌دهی منحصربه‌فرد (معمولاً adtechs) که می‌توانند گزارش‌ها را برای هر {ناشر، تبلیغ‌کننده} ارسال کنند، به 10 در 30 روز پیشنهاد می‌شود. این شمارنده برای هر تبدیل نسبت داده شده افزایش می یابد.

این محدودیت‌ها به اندازه‌ای بالا هستند که توانایی هیچ بازیگری را برای اندازه‌گیری تبدیل‌ها محدود نمی‌کنند، اما به اندازه‌ای کم هستند که به کاهش برخی از اشکال سوء استفاده از API کمک می‌کنند.

گزارش محدودیت های خنک کننده / نرخ

چه چیزی در حال تغییر است و چرا؟

گزارش سرد کردن یک مکانیسم حفظ حریم خصوصی است که مقدار کل اطلاعات ارسال شده از طریق این API را در یک دوره زمانی معین برای یک کاربر کاهش می دهد.

در پیشنهاد جدید، 100 گزارش به ازای هر {منبع سایت، مقصد، مبدا گزارش} (معمولاً {ناشر، تبلیغ‌کننده، تبلیغ‌کننده}) می‌تواند در مدت 30 روز برنامه‌ریزی شود.

فراتر از این محدودیت، مرورگر برنامه‌ریزی گزارش‌هایی را که با {source site, destination, reporting origin} (معمولاً {publisher, advertiser, adtech}) مطابقت دارند متوقف می‌کند—تا زمانی که تعداد گزارش‌های متحرک 30 روزه برای آن {source site به زیر 100 برسد. ، مقصد، مبدا گزارش}.

در توضیح فنی بیشتر بدانید

گزارش محدودیت های خنک کننده / نرخ

محدودیت مقصد (فقط گزارش‌های سطح رویداد)

چه چیزی در حال تغییر است و چرا؟

محدودیت مقصد اصلاح می‌شود تا مبدأ گزارش (معمولاً یک adtech) را شامل شود: 100 مقصد معلق منحصربه‌فرد (معمولاً، سایت‌های تبلیغ‌کننده یا سایت‌هایی که انتظار می‌رود تبدیل‌ها در آنها انجام شود) برای هر {publisher, adtech} مجاز است.

این یک محافظت از حریم خصوصی برای محدود کردن بازسازی تاریخچه مرور است.

در توضیح فنی بیشتر بدانید

محدود کردن تعداد مقصدهای منحصر به فرد تحت پوشش منابع معلق

همه منابع

تصویر هدر از دیانا پولخینا در Unsplash است.