این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

گزارش اسناد برای نمای کلی تلفن همراه

به روز رسانی های اخیر

لیست تغییرات آتی و مشکلات شناخته شده را به روز کرد
معرفی درخواست، یک ویژگی جدید با هدف انتشار برای H2 2025. درخواست به فن‌آوران تبلیغات امکان می‌دهد چندین بار گزارش‌های سرویس تجمیع را پردازش کنند، و از تجزیه و تحلیل انعطاف‌پذیر برای نیازهای اندازه‌گیری مختلف پشتیبانی می‌کند. برای کسب اطلاعات بیشتر و ارائه بازخورد به بحث در GitHub بپیوندید.

نمای کلی

امروزه، استفاده از شناسه های بین طرفی، مانند شناسه تبلیغات، برای راه حل های اسناد و اندازه گیری تلفن همراه رایج است. Attribution Reporting API برای ارائه بهبود حریم خصوصی کاربر با حذف اتکا به شناسه‌های کاربر بین حزبی و پشتیبانی از موارد استفاده کلیدی برای اندازه‌گیری اسناد و تبدیل در برنامه‌ها و وب طراحی شده است.

این API دارای مکانیسم‌های ساختاری زیر است که چارچوبی را برای بهبود حریم خصوصی ارائه می‌دهد که در بخش‌های بعدی این صفحه با جزئیات بیشتر توضیح داده می‌شود:

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

مکانیسم های قبلی توانایی پیوند دادن هویت کاربر را بین دو برنامه یا دامنه متفاوت محدود می کند.

Attribution Reporting API موارد استفاده زیر را پشتیبانی می کند:

گزارش تبدیل: به تبلیغ‌کنندگان کمک کنید عملکرد کمپین‌های خود را با نشان دادن تعداد تبدیل (محرک) و مقادیر تبدیل (محرک) در ابعاد مختلف، مانند کمپین، گروه تبلیغات، و خلاقیت تبلیغاتی اندازه‌گیری کنند.
بهینه‌سازی: گزارش‌های سطح رویداد را ارائه می‌کند که از بهینه‌سازی هزینه‌های تبلیغات پشتیبانی می‌کند، با ارائه داده‌های انتساب هر نمایش که می‌تواند برای آموزش مدل‌های ML استفاده شود.
تشخیص فعالیت نامعتبر: گزارش هایی ارائه می دهد که می تواند در ترافیک نامعتبر و شناسایی و تجزیه و تحلیل تقلب در تبلیغات استفاده شود.

در سطح بالا، API گزارش انتساب به شرح زیر عمل می کند، که بخش های بعدی این سند با جزئیات بیشتر توضیح می دهد:

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

به APIهای Attribution Reporting دسترسی پیدا کنید

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

ثبت منبع انتساب (کلیک کنید یا مشاهده کنید)

Attribution Reporting API به کلیک ها و بازدیدهای تبلیغاتی به عنوان منابع انتساب اشاره می کند. برای ثبت کلیک یا مشاهده آگهی، با registerSource() تماس بگیرید. این API پارامترهای زیر را انتظار دارد:

URI منبع انتساب: پلتفرم درخواستی را به این URI صادر می کند تا متادیتا مرتبط با منبع انتساب را واکشی کند.
رویداد ورودی: یا یک شی InputEvent (برای یک رویداد کلیک) یا null (برای یک رویداد مشاهده).

هنگامی که API درخواستی به URI منبع منبع می‌دهد، فناوری تبلیغات باید با فراداده منبع انتساب در یک عنوان HTTP جدید Attribution-Reporting-Register-Source با فیلدهای زیر پاسخ دهد:

شناسه رویداد منبع : این مقدار داده‌های سطح رویداد مرتبط با این منبع انتساب (کلیک یا مشاهده آگهی) را نشان می‌دهد. باید یک عدد صحیح بدون علامت 64 بیتی باشد که به صورت رشته فرمت شده است.
مقصد : مبدایی که eTLD+1 یا نام بسته برنامه آن در آن رویداد ماشه رخ می دهد.
انقضا (اختیاری) : انقضا، در چند ثانیه، برای زمانی که منبع باید از دستگاه حذف شود. پیش‌فرض 30 روز با حداقل مقدار 1 روز و حداکثر مقدار 30 روز است. این به نزدیکترین روز گرد می شود. می تواند به عنوان یک عدد صحیح بدون علامت 64 بیتی یا رشته ای قالب بندی شود.
پنجره گزارش رویداد (اختیاری) : مدت زمان بر حسب ثانیه پس از ثبت منبع که طی آن ممکن است گزارش رویداد برای این منبع ایجاد شود. اگر پنجره گزارش رویداد گذشته باشد، اما انقضا هنوز به پایان نرسیده است، باز هم می‌توان یک راه‌انداز را با یک منبع مطابقت داد، اما گزارش رویداد برای آن راه‌انداز ارسال نمی‌شود. نمی تواند بزرگتر از Expiry باشد. می تواند به عنوان یک عدد صحیح بدون علامت 64 بیتی یا رشته ای قالب بندی شود.
پنجره گزارش انبوه (اختیاری) : مدت زمان بر حسب ثانیه پس از ثبت منبع که طی آن ممکن است گزارش های انبوهی برای این منبع ایجاد شود. نمی تواند بزرگتر از Expiry باشد. می تواند به عنوان یک عدد صحیح بدون علامت 64 بیتی یا رشته ای قالب بندی شود.
اولویت منبع (اختیاری) : برای انتخاب منبع انتساب که یک راه‌انداز معین باید با کدام منبع انتساب مرتبط باشد، استفاده می‌شود، در صورتی که چندین منبع انتساب می‌تواند با محرک مرتبط باشد. باید یک عدد صحیح امضا شده 64 بیتی باشد که به صورت رشته فرمت شده است.

هنگامی که یک ماشه دریافت می شود، API منبع انتساب منطبق را با بالاترین مقدار اولویت منبع پیدا می کند و یک گزارش ایجاد می کند. هر پلتفرم فناوری تبلیغاتی می تواند استراتژی اولویت بندی خود را تعریف کند. برای جزئیات بیشتر در مورد چگونگی تأثیر اولویت بر انتساب، به بخش مثال اولویت بندی مراجعه کنید.

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

به صورت اختیاری، پاسخ ابرداده منبع انتساب ممکن است شامل داده‌های اضافی در سرصفحه تغییر مسیرهای گزارش Attribution باشد. این داده ها حاوی URL های تغییر مسیر هستند که به چندین فناوری تبلیغات اجازه می دهد درخواستی را ثبت کنند .

راهنمای توسعه دهنده شامل نمونه هایی است که نحوه پذیرش ثبت منبع را نشان می دهد.

مراحل زیر یک نمونه گردش کار را نشان می دهد:

SDK فناوری تبلیغات، API را فراخوانی می‌کند تا ثبت منبع انتساب را آغاز کند، و یک URI برای API برای فراخوانی مشخص می‌کند:
```
registerSource(
    Uri.parse("https://adtech.example/attribution_source?AD_TECH_PROVIDED_METADATA"),
    myClickEvent);
```
API از https://adtech.example/attribution_source? AD_TECH_PROVIDED_METADATA ، با استفاده از یکی از سرصفحه‌های زیر:
```

Attribution-Reporting-Source-Info: navigation


Attribution-Reporting-Source-Info: event
```

سرور HTTPS این فناوری تبلیغاتی با سرصفحه هایی حاوی موارد زیر پاسخ می دهد:

Attribution-Reporting-Register-Source: {
    "destination": "android-app://com.advertiser.example",
    "source_event_id": "234",
    "expiry": "60000",
    "priority": "5"
}
Attribution-Reporting-Redirect:
https://adtechpartner1.example?their_ad_click_id=567
Attribution-Reporting-Redirect:
https://adtechpartner2.example?their_ad_click_id=890

API برای هر URL مشخص شده در Attribution-Reporting-Redirect درخواست می کند. در این مثال، دو URL شریک فناوری تبلیغاتی مشخص شده‌اند، بنابراین API یک درخواست به https://adtechpartner1.example?their_ad_click_id=567 و یک درخواست دیگر به https://adtechpartner2.example?their_ad_click_id=890 .
سرور HTTPS این فناوری تبلیغاتی با سرصفحه هایی حاوی موارد زیر پاسخ می دهد:
```
Attribution-Reporting-Register-Source: {
    "destination": "android-app://com.advertiser.example",
    "source_event_id": "789",
    "expiry": "120000",
    "priority": "2"
}
```
توجه: پاسخ‌های متخصصان تبلیغات می‌توانند ابرداده‌های مختلفی را در سرصفحه Attribution-Reporting-Register-Source مشخص کنند.

سه منبع انتساب ناوبری (کلیک کنید) بر اساس درخواست های نشان داده شده در مراحل قبلی ثبت می شود.

یک منبع انتساب از WebView ثبت کنید

WebView از حالت استفاده پشتیبانی می کند که در آن یک برنامه تبلیغاتی را در WebView ارائه می دهد. این کار توسط WebView انجام می شود که مستقیماً registerSource() فراخوانی می کند. این تماس منبع انتساب را به جای مبدا سطح بالا به برنامه مرتبط می کند. ثبت منابع از محتوای وب جاسازی شده در یک زمینه مرورگر نیز پشتیبانی می شود. هم تماس گیرندگان API و هم برنامه ها برای انجام این کار باید تنظیمات را انجام دهند. برای دستورالعمل‌های مربوط به تماس‌گیرندگان API و منبع Attribution و برای دستورالعمل‌های برنامه‌ها ، ثبت منبع و راه‌انداز انتساب از WebView را ببینید.

از آنجایی که فناوری‌های تبلیغاتی از کدهای مشترک در وب و WebView استفاده می‌کنند، WebView از تغییر مسیرهای HTTP 302 پیروی می‌کند و ثبت‌های معتبر را به پلتفرم منتقل می‌کند. ما قصد نداریم از سرصفحه Attribution-Reporting-Redirect برای این سناریو پشتیبانی کنیم، اما اگر مورد استفاده شما تأثیرگذار است، تماس بگیرید .

ثبت یک ماشه (تبدیل)

پلتفرم‌های فناوری تبلیغات می‌توانند با استفاده از روش registerTrigger() تریگرها را ثبت کنند - تبدیل‌هایی مانند نصب یا رویدادهای پس از نصب.

متد registerTrigger() انتظار پارامتر Trigger URI را دارد. API درخواستی برای این URI برای واکشی ابرداده مرتبط با راه‌انداز صادر می‌کند.

API از تغییر مسیرها پیروی می کند. پاسخ سرور فناوری تبلیغات باید شامل یک هدر HTTP به نام Attribution-Reporting-Register-Trigger باشد که اطلاعات یک یا چند محرک ثبت شده را نشان می دهد. محتوای هدر باید با کد JSON باشد و شامل فیلدهای زیر باشد:

داده های ماشه: داده هایی برای شناسایی رویداد ماشه (3 بیت برای کلیک، 1 بیت برای بازدید). باید یک عدد صحیح امضا شده 64 بیتی باشد که به صورت رشته فرمت شده است.
اولویت راه‌اندازی (اختیاری): نشان‌دهنده اولویت این راه‌انداز در مقایسه با سایر محرک‌ها برای همان منبع انتساب است. باید یک عدد صحیح امضا شده 64 بیتی باشد که به صورت رشته فرمت شده است. برای جزئیات بیشتر در مورد چگونگی تأثیر اولویت بر گزارش، به بخش اولویت بندی مراجعه کنید.
کلید Deduplication (اختیاری): برای شناسایی مواردی استفاده می شود که در آن یک ماشه چندین بار توسط یک پلت فرم فناوری تبلیغاتی یکسان، برای منبع انتساب یکسانی ثبت شده است. باید یک عدد صحیح امضا شده 64 بیتی باشد که به صورت رشته فرمت شده است.
کلیدهای تجمیع (اختیاری): فهرستی از فرهنگ لغت که کلیدهای تجمیع را مشخص می کند و گزارش های انباشته باید دارای ارزش تجمیع شوند.
مقادیر تجمیع (اختیاری): فهرستی از مقادیری که به هر کلید کمک می کند.
فیلترها (اختیاری): برای فیلتر کردن محرک ها یا داده های ماشه استفاده می شود. برای جزئیات بیشتر، بخش فیلترهای ماشه را در این صفحه ببینید.

به صورت اختیاری، پاسخ سرور فناوری تبلیغات ممکن است شامل داده‌های اضافی در سرصفحه تغییر مسیرهای گزارش انتساب باشد. این داده ها حاوی URL های تغییر مسیر هستند که به چندین فناوری تبلیغات اجازه می دهد درخواستی را ثبت کنند .

چندین فناوری تبلیغاتی می‌توانند با استفاده از تغییر مسیرها در قسمت Attribution-Reporting-Redirect یا تماس‌های متعدد با متد registerTrigger() یک رویداد ماشه را ثبت کنند. توصیه می‌کنیم از فیلد کلید deduplication استفاده کنید تا از قرار دادن محرک‌های تکراری در گزارش‌ها در مواردی که فناوری تبلیغاتی یکسان برای یک رویداد راه‌اندازی پاسخ‌های متعددی ارائه می‌دهد، خودداری کنید. در مورد نحوه و زمان استفاده از کلید حذف مجدد اطلاعات بیشتری کسب کنید.

راهنمای توسعه‌دهنده شامل نمونه‌هایی است که نحوه پذیرش ثبت ماشه را نشان می‌دهد.

مراحل زیر یک نمونه گردش کار را نشان می دهد:

Ad tech SDK API را فراخوانی می‌کند تا با استفاده از یک URI از پیش ثبت‌نام‌شده، ثبت راه‌اندازی را آغاز کند. برای اطلاعات بیشتر به ثبت نام برای یک حساب Sandbox حریم خصوصی مراجعه کنید.
```
registerTrigger(
    Uri.parse("https://adtech.example/attribution_trigger?AD_TECH_PROVIDED_METADATA"));
```
API درخواستی به https://adtech.example/attribution_trigger? AD_TECH_PROVIDED_METADATA .

سرور HTTPS این فناوری تبلیغاتی با سرصفحه هایی حاوی موارد زیر پاسخ می دهد:

Attribution-Reporting-Register-Trigger: {
    "event_trigger_data": [{
    "trigger_data": "1122",
    // This returns 010 for click-through conversions (CTCs) and 0 for
    // view-through conversions (VTCs) in reports
    "priority": "3",
    "deduplication_key": "3344"
    }],
}
Attribution-Reporting-Redirect: https://adtechpartner.example?app_install=567

API برای هر URL مشخص شده در Attribution-Reporting-Redirect درخواست می کند. در این مثال، تنها یک URL مشخص شده است، بنابراین API یک درخواست به https://adtechpartner.example?app_install=567 ارسال می کند.
سرور HTTPS این فناوری تبلیغاتی با سرصفحه هایی حاوی موارد زیر پاسخ می دهد:
```
Attribution-Reporting-Register-Trigger: {
"event_trigger_data":[{
  "trigger_data": "5566",
  "priority": "3",
  "deduplication_key": "3344"
}]
}
```
دو تریگر بر اساس درخواست های مراحل قبل ثبت می شود.

قابلیت های اسناد

بخش‌های زیر توضیح می‌دهند که چگونه API گزارش Attribution با محرک‌های تبدیل به منابع انتساب مطابقت دارد.

الگوریتم انتساب با اولویت منبع اعمال شد

Attribution Reporting API از یک الگوریتم انتساب با اولویت منبع برای تطبیق یک محرک (تبدیل) به منبع انتساب استفاده می کند.

پارامترهای اولویت راه هایی را برای سفارشی کردن انتساب محرک ها به منابع ارائه می دهند:

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

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

فیلترهای ماشه ای

ثبت منبع و ماشه شامل ویژگی های اختیاری اضافی برای انجام موارد زیر است:

برخی از محرک ها را به صورت انتخابی فیلتر کنید و به طور موثر آنها را نادیده بگیرید.
داده‌های راه‌انداز را برای گزارش‌های سطح رویداد بر اساس داده‌های منبع انتخاب کنید.
حذف یک ماشه از گزارش‌های سطح رویداد را انتخاب کنید.

برای فیلتر کردن محرک‌های انتخابی، فناوری تبلیغات می‌تواند داده‌های فیلتر، متشکل از کلیدها و مقادیر را در طول ثبت منبع و ماشه مشخص کند. اگر کلید یکسانی برای منبع و ماشه مشخص شده باشد، در صورت خالی بودن تقاطع، ماشه نادیده گرفته می شود. به عنوان مثال، یک منبع می تواند "product": ["1234"] ، جایی که product کلید فیلتر و 1234 مقدار است. اگر فیلتر ماشه روی "product": ["1111"] تنظیم شده باشد، ماشه نادیده گرفته می شود. اگر product مطابق با کلید فیلتر ماشه وجود نداشته باشد، فیلترها نادیده گرفته می شوند.

سناریوی دیگری که در آن پلتفرم‌های فناوری تبلیغات ممکن است بخواهند به طور انتخابی محرک‌ها را فیلتر کنند، مجبور کردن یک پنجره انقضا کوتاه‌تر است. در ثبت ماشه، یک فناوری تبلیغاتی می‌تواند (در چند ثانیه) یک پنجره بازبینی از زمانی که تبدیل اتفاق افتاد را مشخص کند. به عنوان مثال، یک پنجره بازبینی 7 روزه به این صورت تعریف می شود: "_lookback_window": 604800 // 7d

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

پلتفرم‌های فناوری تبلیغات همچنین می‌توانند داده‌های راه‌اندازی را بر اساس داده‌های رویداد منبع انتخاب کنند. برای مثال، source_type به طور خودکار توسط API به عنوان navigation یا event ایجاد می‌شود. در طول ثبت ماشه، trigger_data می توان به عنوان یک مقدار برای "source_type": ["navigation"] و به عنوان یک مقدار متفاوت برای "source_type": ["event"] تنظیم کرد.

در صورت صحت هر یک از موارد زیر، راه‌اندازها از گزارش‌های سطح رویداد حذف می‌شوند:

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

انتساب پس از نصب

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

API می‌تواند با اجازه دادن به فناوری‌های تبلیغاتی برای تنظیم دوره انتساب پس از نصب، از این مورد استفاده پشتیبانی کند:

هنگام ثبت منبع انتساب، یک پنجره انتساب نصب را مشخص کنید که در طی آن نصب ها مورد انتظار است (معمولاً 2-7 روز، محدوده پذیرفته شده 1 تا 30 روز). این پنجره زمانی را به صورت چند ثانیه مشخص کنید.
هنگام ثبت منبع انتساب، یک پنجره انحصاری انتساب پس از نصب را مشخص کنید که در آن رویدادهای راه‌اندازی پس از نصب باید با منبع انتسابی که باعث نصب شده است مرتبط شود (معمولاً 7-30 روز، محدوده پذیرفته شده 0 تا 30 روز). این پنجره زمانی را به صورت چند ثانیه مشخص کنید.
Attribution Reporting API زمانی که نصب برنامه اتفاق می‌افتد اعتبارسنجی می‌کند و به صورت داخلی نصب را به منبع انتساب با اولویت منبع نسبت می‌دهد. با این حال، نصب برای فن‌آوری‌های تبلیغاتی ارسال نمی‌شود و در محدودیت‌های نرخ مربوطه پلتفرم حساب نمی‌شود.
اعتبار سنجی نصب برنامه برای هر برنامه دانلود شده در دسترس است.
هر راه‌اندازی آتی که در پنجره انتساب پس از نصب اتفاق می‌افتد، تا زمانی که منبع انتساب واجد شرایط باشد، به همان منبع انتساب نصب معتبر نسبت داده می‌شود.

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

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

رویداد	روزی که رویداد رخ می دهد	یادداشت ها
1 را کلیک کنید	1	`install_attribution_window` روی `172800` (2 روز) و `post_install_exclusivity_window` روی `864000` (10 روز) تنظیم شده است.
نصب تایید شده	2	API به صورت داخلی به نصب‌های تأیید شده مشخص می‌شود، اما این نصب‌ها به عنوان محرک در نظر گرفته نمی‌شوند. بنابراین گزارشی در این مرحله ارسال نمی شود.
ماشه 1 (اولین باز)	2	اولین ماشه توسط فناوری تبلیغات ثبت شد. در این مثال، یک اولین باز را نشان می دهد اما می تواند هر نوع ماشه ای باشد. منتسب به کلیک 1 (منطبق با انتساب نصب تأیید شده).
روی 2 کلیک کنید	4	از مقادیر یکسانی برای `install_attribution_window` و `post_install_exclusivity_window` استفاده می کند.
Trigger 2 (پست نصب)	5	عامل دوم توسط فناوری تبلیغات ثبت شده است. در این مثال، یک تبدیل پس از نصب را مانند خرید نشان می دهد. منتسب به کلیک 1 (منطبق با انتساب نصب تأیید شده). کلیک 2 کنار گذاشته شده است و برای انتساب بعدی واجد شرایط نیست.

لیست زیر نکات دیگری را در مورد انتساب پس از نصب ارائه می دهد:

اگر نصب تأیید شده در تعداد روزهای مشخص شده توسط install_attribution_window انجام نشود، انتساب پس از نصب اعمال نمی‌شود.
نصب های تأیید شده توسط فناوری های تبلیغاتی ثبت نمی شوند و در گزارش ها ارسال نمی شوند. آنها در مقابل محدودیت های نرخ یک فناوری تبلیغات حساب نمی شوند. نصب‌های تأیید شده فقط برای شناسایی منبع انتساب استفاده می‌شوند که به نصب اعتبار داده شده است.
در مثال جدول قبل، تریگر 1 و تریگر 2 به ترتیب اولین تبدیل باز و تبدیل پس از نصب را نشان می دهند. با این حال، پلتفرم های فناوری تبلیغات می توانند هر نوع محرکی را ثبت کنند. به عبارت دیگر، اولین ماشه نباید اولین ماشه باز باشد.
اگر پس از انقضای post_install_exclusivity_window ، محرک‌های بیشتری ثبت شوند، با این فرض که منقضی نشده است و به محدودیت‌های نرخ خود نرسیده است، کلیک 1 همچنان واجد شرایط است.
- اگر منبع انتساب با اولویت بالاتر ثبت شده باشد، کلیک 1 همچنان ممکن است از دست برود، یا نادیده گرفته شود.
اگر برنامه تبلیغ‌کننده حذف نصب و مجدداً نصب شود، نصب مجدد به‌عنوان یک نصب تأیید شده جدید محاسبه می‌شود.
اگر کلیک 1 در عوض یک رویداد مشاهده بود، هر دو راه‌انداز «اولین باز» و پس از نصب همچنان به آن نسبت داده می‌شوند. API انتساب را به یک راه‌انداز در هر نما محدود می‌کند، مگر در مورد انتساب پس از نصب که حداکثر دو راه‌انداز در هر نما مجاز است. در مورد انتساب پس از نصب، فناوری تبلیغات می‌تواند ۲ پنجره گزارش متفاوت (در ۲ روز یا در انقضای منبع) دریافت کند.

همه ترکیبی از مسیرهای ماشه مبتنی بر برنامه و وب پشتیبانی می شوند

Attribution Reporting API انتساب مسیرهای راه‌اندازی زیر را در یک دستگاه Android فعال می‌کند:

برنامه به برنامه: کاربر یک تبلیغ را در یک برنامه می بیند، سپس در آن برنامه یا برنامه نصب شده دیگری تبدیل می کند.
برنامه به وب: کاربر یک تبلیغ را در یک برنامه می بیند، سپس در مرورگر موبایل یا برنامه تبدیل می کند.
وب به برنامه: کاربر یک تبلیغ را در مرورگر موبایل یا برنامه می بیند، سپس در یک برنامه تبدیل می کند.
وب به وب: کاربر یک تبلیغ را در مرورگر تلفن همراه یا برنامه می بیند، سپس در همان مرورگر یا مرورگر دیگری در همان دستگاه تبدیل می کند.

ما به مرورگرهای وب اجازه می‌دهیم از ویژگی‌های جدید تحت وب پشتیبانی کنند، مانند عملکردی که شبیه به Privacy Sandbox برای Web's Attribution Reporting API است، که می‌تواند APIهای Android را برای فعال کردن انتساب در برنامه و وب فراخوانی کند.

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

برای یک منبع انتساب، چندین محرک را اولویت بندی کنید

یک منبع انتساب واحد می تواند به چندین محرک منجر شود. به عنوان مثال، یک جریان خرید می‌تواند شامل یک راه‌انداز «نصب برنامه»، یک یا چند عامل «افزودن به سبد خرید» و یک راه‌انداز «خرید» باشد. طبق الگوریتم انتساب اولویت‌بندی شده منبع که در ادامه این صفحه توضیح داده می‌شود، هر عامل به یک یا چند منبع اسناد نسبت داده می‌شود.

محدودیت هایی وجود دارد که چه تعداد محرک را می توان به یک منبع انتساب نسبت داد . برای جزئیات بیشتر، بخش مشاهده داده‌های اندازه‌گیری در گزارش‌های انتساب را در ادامه این صفحه بخوانید.

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

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

به چندین فناوری تبلیغات اجازه دهید منابع یا محرک‌های انتساب را ثبت کنند

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

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

راه اندازی یک سرور داخلی برای ثبت نام و دریافت گزارش از API.
ادامه استفاده از شریک اندازه گیری تلفن همراه موجود.

منابع انتساب

تغییر مسیرهای منبع انتساب در روش registerSource() پشتیبانی می شود:

فناوری تبلیغاتی که متد registerSource() را فراخوانی می‌کند، می‌تواند یک فیلد Attribution-Reporting-Redirect اضافی را در پاسخ خود ارائه دهد، که نشان‌دهنده مجموعه URL‌های تغییر مسیر شرکت فناوری تبلیغات شریک است.
سپس API URL های تغییر مسیر را فراخوانی می کند تا منبع انتساب توسط متخصصان تبلیغات شریک ثبت شود.

آدرس‌های اینترنتی فناوری تبلیغات شریک چندگانه را می‌توان در قسمت Attribution-Reporting-Redirect فهرست کرد، و شرکت‌های فناوری تبلیغات شریک نمی‌توانند قسمت Attribution-Reporting-Redirect خود را مشخص کنند.

API همچنین به فناوری‌های تبلیغاتی مختلف اجازه می‌دهد تا هر call registerSource() .

محرک ها

برای ثبت تریگر، اشخاص ثالث به روشی مشابه پشتیبانی می‌شوند: فناوری‌های تبلیغاتی می‌توانند از فیلد Attribution-Reporting-Redirect اضافی استفاده کنند، یا هر کدام می‌توانند متد registerTrigger() فراخوانی کنند.

هنگامی که یک تبلیغ‌کننده از فناوری‌های تبلیغاتی متعدد برای ثبت یک رویداد محرک استفاده می‌کند، باید از یک کلید حذف تکراری استفاده شود. کلید deduplication برای ابهام‌زدایی از این گزارش‌های مکرر از همان رویداد ثبت‌شده توسط همان پلت‌فرم فناوری تبلیغاتی استفاده می‌کند. به عنوان مثال، یک فناوری تبلیغاتی می‌تواند از SDK خود مستقیماً با API تماس بگیرد تا یک راه‌انداز را ثبت کند و URL خود را در قسمت تغییر مسیر تماس یک فناوری تبلیغاتی دیگر قرار دهد. اگر کلید حذف مجدد ارائه نشده باشد، ممکن است محرک های تکراری به عنوان منحصر به فرد به هر فناوری تبلیغاتی گزارش شود.

محرک های تکراری را مدیریت کنید

یک فناوری تبلیغاتی ممکن است یک ماشه را چندین بار با API ثبت کند. سناریوها شامل موارد زیر است:

کاربر یک عمل (تریگر) را چندین بار انجام می دهد. به عنوان مثال، کاربر یک محصول را چندین بار در یک پنجره گزارش یکسان مرور می کند.
برنامه تبلیغ‌کننده از چند SDK برای اندازه‌گیری تبدیل استفاده می‌کند که همگی به یک فناوری تبلیغات هدایت می‌شوند. برای مثال، اپلیکیشن تبلیغ‌کننده از دو شریک اندازه‌گیری، MMP #1 و MMP #2 استفاده می‌کند. هر دو MMP به فناوری تبلیغات شماره 3 هدایت می شوند. هنگامی که یک ماشه اتفاق می افتد، هر دو MMP آن ماشه را با API گزارش Attribution ثبت می کنند. سپس فناوری تبلیغات شماره 3 دو تغییر مسیر جداگانه - یکی از MMP شماره 1 و دیگری از MMP شماره 2 - برای همان ماشه دریافت می کند.

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

روش پیشنهادی: کلید deduplication

روش پیشنهادی این است که برنامه تبلیغ‌کننده یک کلید تکراری منحصر به فرد را به هر فناوری تبلیغات یا SDK که برای اندازه‌گیری تبدیل استفاده می‌کند، ارسال کند. هنگامی که یک تبدیل اتفاق می افتد، برنامه یک کلید حذف مجدد را به فناوری های تبلیغاتی یا SDK ها ارسال می کند. آن فناوری‌های تبلیغاتی یا SDK‌ها سپس با استفاده از پارامتری در آدرس‌های اینترنتی مشخص‌شده در Attribution-Reporting-Redirect کلید حذف‌سازی را به تغییرمسیرها ارسال می‌کنند.

متخصصان تبلیغات می توانند انتخاب کنند که فقط اولین ماشه را با یک کلید حذف تکراری مشخص ثبت کنند، یا می توانند چندین محرک یا همه محرک ها را ثبت کنند. فناوری‌های تبلیغاتی می‌توانند هنگام ثبت تریگرهای تکراری، deduplication_key مشخص کنند.

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

روش جایگزین: فن‌آوران تبلیغات در مورد انواع محرک هر تبلیغ‌کننده توافق دارند

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

فن‌آوری‌های تبلیغاتی که تماس ثبت‌نام راه‌انداز را آغاز می‌کنند - برای مثال، SDKها - شامل یک پارامتر در URLهای مشخص شده در Attribution-Reporting-Redirect ، مانند duplicate_trigger_id . این پارامتر duplicate_trigger_id می‌تواند شامل اطلاعاتی مانند نام SDK و نوع راه‌انداز برای آن تبلیغ‌کننده باشد. سپس فناوری‌های تبلیغاتی می‌توانند زیرمجموعه‌ای از این محرک‌های تکراری را به گزارش‌های سطح رویداد ارسال کنند. فناوری‌های تبلیغاتی همچنین می‌توانند این duplicate_trigger_id در کلیدهای تجمیع خود بگنجانند.

نمونه اسناد بین شبکه ای

در مثالی که در این بخش توضیح داده شد، تبلیغ‌کننده از دو پلتفرم فناوری تبلیغاتی (Ad tech A و Ad tech B) و یک شریک اندازه‌گیری (MMP) استفاده می‌کند.

برای شروع، Ad tech A، Ad tech B و MMP باید ثبت نام خود را تکمیل کنند تا از Attribution Reporting API استفاده کنند. برای اطلاعات بیشتر به ثبت نام برای یک حساب Sandbox حریم خصوصی مراجعه کنید.

فهرست زیر مجموعه‌ای فرضی از اقدامات کاربر را ارائه می‌کند که هرکدام به فاصله یک روز از هم انجام می‌شوند، و اینکه چگونه API گزارش انتساب آن اقدامات را با توجه به Ad tech A، Ad tech B و MMP انجام می‌دهد:

روز 1: کلیک کاربر روی تبلیغی که توسط Ad tech A ارائه شده است

Ad tech A با URI خود registerSource() فرا می خواند. API درخواستی به URI می‌کند و کلیک با ابرداده از پاسخ سرور Ad tech A ثبت می‌شود.

Ad tech A همچنین شامل URI MMP در سرصفحه Attribution-Reporting-Redirect . API درخواستی را به URI MMP ارسال می کند و کلیک با فراداده از پاسخ سرور MMP ثبت می شود.

روز 2: کلیک کاربر روی تبلیغی که توسط Ad tech B ارائه شده است

Ad tech B، registerSource() با URI خود فرا می خواند. API درخواستی به URI می‌کند و کلیک با ابرداده از پاسخ سرور Ad tech B ثبت می‌شود.

مانند Ad tech A، Ad tech B نیز URI MMP را در هدر Attribution-Reporting-Redirect گنجانده است. API درخواستی به URI MMP می دهد و کلیک با فراداده از پاسخ سرور MMP ثبت می شود.

روز 3: کاربر آگهی ارائه شده توسط Ad tech A را مشاهده می کند

API به همان روشی که در روز اول انجام داد پاسخ می‌دهد، با این تفاوت که یک نما برای Ad tech A و MMP ثبت می‌شود.

روز 4: کاربر برنامه را نصب می کند که از MMP برای اندازه گیری تبدیل استفاده می کند

MMP registerTrigger() را با URI خود فرا می خواند. API یک درخواست به URL ارسال می کند و تبدیل با فراداده از پاسخ سرور MMP ثبت می شود.

MMP همچنین شامل URI برای Ad tech A و Ad tech B در سرصفحه Attribution-Reporting-Redirect است. API به سرورهای Ad tech A و Ad tech B درخواست می کند و تبدیل مطابق با فراداده پاسخ های سرور ثبت می شود.

نمودار زیر روند شرح داده شده در لیست قبلی را نشان می دهد:

نمونه ای از نحوه پاسخ API گزارش Attribution به مجموعه ای از اقدامات کاربر.

Attribution به شرح زیر عمل می کند:

Ad tech A اولویت کلیک‌ها را بالاتر از بازدیدها تنظیم می‌کند و بنابراین نصب منتسب به کلیک در روز اول را دریافت می‌کند.
Ad tech B نصب منتسب در روز 2 را دریافت می کند.
MMP اولویت کلیک‌ها را بالاتر از بازدیدها تنظیم می‌کند و نصب منتسب به کلیک در روز 2 را دریافت می‌کند. کلیک روز 2 بالاترین اولویت، آخرین رویداد تبلیغاتی است.

انتساب بین شبکه ای بدون تغییر مسیر

در حالی که توصیه می‌کنیم از تغییرمسیرها برای اجازه دادن به چندین فناوری تبلیغاتی برای ثبت منابع اسناد و محرک‌ها استفاده کنید، اما می‌دانیم که ممکن است سناریوهایی وجود داشته باشد که استفاده از تغییرمسیر امکان‌پذیر نباشد. در این بخش نحوه پشتیبانی از انتساب بین شبکه ای بدون تغییر مسیر توضیح داده می شود.

جریان سطح بالا

هنگام ثبت منبع، شبکه فناوری تبلیغات ارائه دهنده کلیدهای تجمیع منبع خود را به اشتراک می گذارد.
هنگام ثبت ماشه، تبلیغ‌کننده یا شریک اندازه‌گیری انتخاب می‌کند که از کدام قطعات کلیدی سمت منبع استفاده کند و پیکربندی انتساب آن‌ها را مشخص می‌کند.
Attribution بر اساس پیکربندی انتساب، کلیدهای مشترک، و هر منبعی است که واقعاً توسط آن تبلیغ‌کننده یا شریک اندازه‌گیری ثبت شده است (مثلاً از شبکه فناوری تبلیغاتی دیگری که تغییر مسیرها را فعال کرده است).
اگر راه‌انداز به منبعی از فناوری تبلیغات ارائه‌دهنده بدون تغییر مسیر نسبت داده شود، تبلیغ‌کننده یا شریک اندازه‌گیری می‌تواند گزارش جمع‌آوری‌شده‌ای دریافت کند که منبع و بخش‌های کلیدی راه‌انداز تعریف‌شده در مرحله ۲ را ترکیب می‌کند.

ثبت منبع

هنگام ثبت منبع، شبکه فناوری تبلیغاتی ارائه دهنده می‌تواند کلیدهای تجمیع منبع یا زیرمجموعه‌ای از کلیدهای تجمیع منبع خود را به‌جای هدایت مجدد به اشتراک بگذارد. فناوری تبلیغاتی ارائه‌دهنده نیازی به استفاده از این کلیدهای منبع در گزارش‌های جمع‌آوری‌شده خود ندارد و در صورت نیاز می‌تواند آنها را فقط از طرف تبلیغ‌کننده یا شریک اندازه‌گیری اعلام کند.

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

ماشه ثبت نام

در ثبت ماشه، فناوری تبلیغات اندازه‌گیری انتخاب می‌کند که کدام قسمت‌های کلید سمت منبع را برای هر قطعه کلید ماشه اعمال کند، از جمله مواردی که توسط فناوری‌های تبلیغاتی به اشتراک گذاشته شده است.

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

انتساب

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

کاربر روی تبلیغات ارائه شده توسط فناوری‌های تبلیغاتی A، B، C و D کلیک کرد. سپس کاربر برنامه تبلیغ‌کننده را نصب کرد که از شریک فناوری تبلیغات اندازه‌گیری (MMP) استفاده می‌کند.
Ad tech A منابع خود را به MMP هدایت می کند.
فناوری های تبلیغاتی B و C تغییر مسیر نمی دهند، بلکه کلیدهای تجمیع خود را به اشتراک می گذارند.
Ad tech D نه کلیدهای تجمیع را هدایت می کند و نه به اشتراک می گذارد.

MMP منبعی را از Ad tech A ثبت می‌کند و یک پیکربندی انتساب را تعریف می‌کند که شامل Ad tech B و Ad tech D می‌شود.

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

فناوری تبلیغات A، از آنجایی که MMP منبعی را از تغییر مسیر آن فناوری تبلیغات ثبت کرده است.
Ad tech B، از آنجایی که Ad tech B کلیدهای مشترک را به اشتراک می گذارد و MMP آن را در پیکربندی انتساب خود گنجانده است.

انتساب برای MMP شامل موارد زیر نیست:

فناوری تبلیغاتی C، زیرا MMP آن را در پیکربندی انتساب خود لحاظ نکرده است.
فناوری تبلیغات D، زیرا آنها کلیدهای تجمیع را تغییر مسیر نداده و به اشتراک نمی گذارند.

اشکال زدایی

برای پشتیبانی از اشکال‌زدایی برای تخصیص بین شبکه‌ای بدون تغییر مسیر، یک فیلد اضافی به نام shared_debug_key برای فناوری‌های تبلیغاتی در دسترس است تا پس از ثبت منبع تنظیم شود. اگر روی ثبت منبع اصلی تنظیم شود، در هنگام ثبت راه‌اندازی برای انتساب بین شبکه‌ای بدون تغییر مسیر، در منبع مشتق شده مربوطه نیز به‌عنوان debug_key تنظیم می‌شود. این کلید اشکال‌زدایی به‌عنوان source_debug_key در گزارش‌های رویداد و انبوه پیوست شده است.

این ویژگی اشکال‌زدایی فقط برای انتساب بین شبکه‌ای بدون تغییر مسیر تحت سناریوهای زیر پشتیبانی می‌شود:

اندازه گیری برنامه به برنامه در جایی که AdId مجاز است
اندازه‌گیری برنامه به وب که در آن AdId مجاز است و هم در منبع برنامه و هم در راه‌انداز وب مطابقت دارد
اندازه‌گیری وب به وب (در همان برنامه مرورگر) زمانی که ar_debug ` هم در منبع و هم در راه‌انداز وجود دارد

کشف کلیدی برای انتساب بین شبکه ای بدون تغییر مسیر

هدف از کشف کلید ساده‌سازی نحوه اجرای پیکربندی اسناد تبلیغاتی (معمولاً MMPها) برای اهداف انتساب بین شبکه‌ای است، زمانی که یک یا چند فناوری تبلیغاتی ارائه‌دهنده از کلیدهای تجمیع مشترک استفاده می‌کنند (همانطور که در اسناد بین شبکه‌ای بدون تغییر مسیر در بالا توضیح داده شد).

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

لیست تمام کلیدهای ممکن بزرگ است:
- یک شبکه تبلیغاتی ارائه دهنده یک ابتکار پیچیده جذب کاربر را اجرا می کند که شامل 20 کمپین، هرکدام با 10 گروه تبلیغاتی، و هر گروه تبلیغاتی با 5 خلاقیت است که هر هفته بر اساس عملکرد، به روز می شوند.
لیست تمام کلیدهای ممکن ناشناخته است:
- یک شبکه تبلیغاتی در حال ارائه تبلیغات در بسیاری از برنامه‌های تلفن همراه است که لیست کامل شناسه‌های برنامه ناشر در زمان راه‌اندازی کمپین مشخص نیست.
- یک تبلیغ‌کننده در حال کار روی چندین شبکه تبلیغاتی است که در ثبت منبع به MMP هدایت نمی‌شوند. هر شبکه تبلیغاتی ارائه دهنده ساختار و مقادیر کلیدی متفاوتی دارد که ممکن است از قبل با MMP به اشتراک گذاشته نشود.

با معرفی کشف کلیدی:

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

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

تغییر مسیرهای زنجیره ای دیزی

با ارائه چندین سرصفحه Attribution-Reporting-Redirect در یک پاسخ سرور HTTPS ثبت منبع یا راه‌اندازی، یک فناوری تبلیغاتی می‌تواند از API گزارش انتساب برای انجام چندین منبع و شروع ثبت‌ها با یک تماس API ثبت استفاده کند.

در پاسخ سرور، فناوری تبلیغات همچنین می‌تواند شامل یک سرصفحه Location (302 تغییر مسیر) با یک URL باشد که به نوبه خود منجر به ثبت نام دیگر تا سقف تعیین شده می‌شود.

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

تغییر مسیر برای registerWebSource و registerWebTrigger مورد استفاده مرورگرها پذیرفته نمی شود. جزئیات بیشتر را می توانید در Cross Web and App Implementation Guide پیدا کنید.

مشاهده داده های اندازه گیری در گزارش های اسناد

Attribution Reporting API انواع گزارش‌های زیر را فعال می‌کند که در ادامه این صفحه با جزئیات بیشتر توضیح داده می‌شوند:

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

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

گزارش های سطح رویداد

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

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

گزارش سطح رویداد حاوی داده هایی مانند موارد زیر است:

مقصد: نام بسته برنامه تبلیغ‌کننده یا eTLD+1 جایی که راه‌اندازی رخ داده است
شناسه منبع انتساب: همان شناسه منبع انتساب که برای ثبت منبع انتساب استفاده شده است
نوع راه‌انداز: 1 یا 3 بیت داده راه‌انداز با وفاداری پایین، بسته به نوع منبع انتساب

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

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

محدودیت در تعداد فناوری های تبلیغاتی

محدودیت‌هایی برای تعداد فناوری‌های تبلیغاتی وجود دارد که می‌توانند گزارش‌هایی را از API ثبت یا دریافت کنند، با پیشنهاد فعلی موارد زیر:

100 فن‌آوری تبلیغات با منابع اسناد در هر {برنامه منبع، برنامه مقصد، 30 روز، دستگاه}.
10 فن‌آوری تبلیغات با محرک‌های منتسب در هر {برنامه منبع، برنامه مقصد، 30 روز، دستگاه}.
20 تکنسین تبلیغاتی می توانند یک منبع تخصیص یا محرک ثبت کنند (از طریق Attribution-Reporting-Redirect )

محدودیت در تعداد مقاصد منحصر به فرد

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

در همه منابع ثبت‌شده، در تمامی فناوری‌های تبلیغاتی، API بیش از 200 مقصد منحصربه‌فرد را، در هر برنامه منبع، در دقیقه پشتیبانی نمی‌کند.
در همه منابع ثبت شده، برای یک فناوری تبلیغاتی، API بیش از 50 مقصد منحصر به فرد را، در هر برنامه منبع، در دقیقه پشتیبانی نمی کند. این محدودیت مانع از استفاده یک فناوری تبلیغات از کل بودجه از حد نرخ ذکر شده قبلی می شود.

منابع منقضی شده در محدودیت نرخ حساب نمی شوند.

یک منبع گزارش برای هر برنامه منبع در روز

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

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

مبدا گزارش فناوری آگهی A 1 منبعی را در برنامه B ثبت می کند
12 ساعت بعد، مبدا گزارش فناوری آگهی A 2 تلاش می کند منبعی را در برنامه B ثبت کند

منبع دوم، برای مبدا گزارش 2 Ad tech A، توسط API رد خواهد شد. مبدا گزارش فناوری آگهی A 2 تا روز بعد نمی‌تواند با موفقیت منبعی را در همان دستگاه در برنامه B ثبت کند.

محدودیت های خنک کننده و نرخ

برای محدود کردن میزان نشت هویت کاربر بین یک جفت {source, destination}، API مقدار کل اطلاعات ارسال شده در یک دوره زمانی معین را برای یک کاربر کاهش می‌دهد.

پیشنهاد فعلی این است که هر فناوری تبلیغات را به 100 محرک نسبت داده شده برای هر {برنامه منبع، برنامه مقصد، 30 روز، دستگاه} محدود کنید.

تعداد مقاصد منحصر به فرد

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

پیشنهاد فعلی این است که هر فناوری تبلیغاتی را به 100 مقصد متمایز با منابع منقضی نشده در هر برنامه منبع محدود کنید.

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

وفاداری محدود داده های ماشه

API 1 بیت را برای محرک های نمایش و 3 بیت برای محرک های کلیکی ارائه می دهد. منابع Attribution از 64 بیت کامل ابرداده پشتیبانی می کنند.

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

چارچوبی برای نویز حریم خصوصی دیفرانسیل

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

نویز در مورد اینکه آیا یک رویداد منبع اسناد به درستی گزارش شده است اعمال می شود. یک منبع انتساب در دستگاه با احتمال $ 1-p $ ثبت می شود که منبع انتساب به صورت عادی ثبت شده است، و با احتمال $ p $ که دستگاه به طور تصادفی از بین تمام حالت های خروجی ممکن API (از جمله گزارش نکردن هیچ چیزی یا گزارش چندین گزارش جعلی) انتخاب می کند.

پاسخ تصادفی k الگوریتمی است که اگر معادله زیر برآورده شود، به طور افسیلونی خصوصی است:

\[ p = \frac{k}{k + e^ε - 1} \]

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

p=0.24% برای منابع ناوبری
p=0.00025% برای منابع رویداد

محدودیت‌های محرک‌های موجود (تبدیل‌ها)

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

1-2 محرک برای منابع انتساب مشاهده آگهی (2 محرک فقط در مورد انتساب پس از نصب موجود است)
3 محرک برای منابع انتساب تبلیغات کلیکی

پنجره های زمانی خاص برای ارسال گزارش ها (رفتار پیش فرض)

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

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

2 روز: دستگاه تمام محرک هایی را که حداکثر 2 روز پس از ثبت منبع انتساب رخ داده اند جمع آوری می کند. گزارش 2 روز و 1 ساعت پس از ثبت منبع انتساب ارسال می شود.
7 روز: دستگاه تمام محرک هایی را که بیش از 2 روز رخ داده اند، اما حداکثر 7 روز پس از ثبت منبع انتساب، جمع آوری می کند. گزارش 7 روز و 1 ساعت پس از ثبت منبع انتساب ارسال می شود.
یک مدت زمان سفارشی، که با ویژگی "انقضا" منبع انتساب تعریف می شود. گزارش 1 ساعت پس از زمان انقضای مشخص شده ارسال می شود. این مقدار نمی تواند کمتر از 1 روز یا بیشتر از 30 روز باشد.

پیکربندی انعطاف پذیر در سطح رویداد

پیکربندی پیش‌فرض برای گزارش‌دهی سطح رویداد همان چیزی است که به فن‌آوران تبلیغات توصیه می‌شود با شروع آزمایش ابزار شروع به استفاده از آن کنند، اما ممکن است برای همه موارد استفاده ایده‌آل نباشد. Attribution Reporting API از پیکربندی‌های اختیاری و انعطاف‌پذیرتر پشتیبانی می‌کند تا فناوری‌های تبلیغاتی کنترل ساختار گزارش‌های سطح رویداد خود را افزایش دهند و بتوانند کاربرد داده‌ها را به حداکثر برسانند.

این انعطاف‌پذیری اضافی در دو مرحله به API گزارش اسناد معرفی می‌شود:

فاز 1: پیکربندی سطح رویداد انعطاف پذیر Lite
- این نسخه زیرمجموعه ای از ویژگی های کامل را ارائه می دهد و می تواند مستقل از فاز 2 استفاده شود.
فاز 2: نسخه کامل پیکربندی سطح رویداد انعطاف پذیر

فاز 1 (سطح رویداد انعطاف پذیر Lite) می تواند برای موارد زیر استفاده شود:

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

فاز 2 (سطح رویداد کامل انعطاف پذیر) می تواند برای انجام تمام قابلیت های فاز 1 و:

کاردینالیته داده های ماشه را در یک گزارش تغییر دهید
با کاهش کاردینالیته داده های ماشه، مقدار کل نویز را کاهش دهید

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

علاوه بر تنظیم پویا سطوح نویز بر اساس پیکربندی انتخابی یک فناوری تبلیغاتی، برای جلوگیری از هزینه‌های محاسباتی زیاد و تنظیمات با حالت‌های خروجی زیاد (که در آن نویز به میزان قابل توجهی افزایش می‌یابد) محدودیت‌های پارامتری خواهیم داشت. در اینجا یک مجموعه نمونه از محدودیت ها آورده شده است. بازخورد در مورد [پیشنهاد طراحی[50] تشویق می شود:

حداکثر 20 گزارش کل، در سطح جهانی و به ازای هر trigger_data
حداکثر 5 پنجره گزارش ممکن برای هر trigger_data
حداکثر 32 کاردینالیتی داده ماشه (برای فاز 1 قابل اجرا نیست: سطح رویداد انعطاف پذیر Lite)

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

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

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

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

گزارش‌هایی برای مقادیر محرک، مانند درآمد
مدیریت بیشتر انواع ماشه

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

طراحی کلی نحوه تهیه و ارسال گزارش‌های API گزارش انتساب، که در نمودار نشان داده شده است، به شرح زیر است:

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

فرآیندی که API گزارش Attribution برای تهیه و ارسال گزارش‌های انبوه استفاده می‌کند.

گزارش‌های جمع‌آوری‌شده حاوی داده‌های زیر مربوط به منابع انتساب است:

مقصد: نام بسته برنامه یا نشانی وب eTLD+1 که در آن راه‌اندازی رخ داده است.
تاریخ: تاریخی که رویداد نشان داده شده توسط منبع انتساب رخ داده است.
Payload: مقادیر ماشه، جمع آوری شده به صورت جفت کلید/مقدار رمزگذاری شده، که در سرویس تجمع مورد اعتماد برای محاسبه تجمیع ها استفاده می شود.

خدمات تجمیع

خدمات زیر قابلیت تجمیع داده ها و محافظت در برابر دسترسی غیرمجاز به داده های انباشته را فراهم می کند.

این خدمات توسط طرف های مختلفی مدیریت می شوند که در ادامه این صفحه با جزئیات بیشتر توضیح داده شده است:

سرویس تجمیع تنها سرویسی است که از فناوری های تبلیغاتی انتظار می رود آن را مستقر کنند.
خدمات حسابداری مدیریت کلید و گزارش انبوه توسط اشخاص مورد اعتماد به نام هماهنگ کننده اداره می شود. این هماهنگ‌کننده‌ها تأیید می‌کنند که کدی که سرویس تجمیع را اجرا می‌کند، کدی است که برای عموم در دسترس است که توسط Google ارائه می‌شود و همه کاربران سرویس تجمیع، خدمات حسابداری کلیدی و انبوهی یکسانی دارند که برای آنها اعمال می‌شود.

خدمات تجمیع

پلتفرم‌های فناوری تبلیغات باید از قبل، یک سرویس تجمیع را که مبتنی بر باینری‌های ارائه شده توسط Google است، راه‌اندازی کنند.

این سرویس تجمیع در یک محیط اجرای مورد اعتماد (TEE) که در فضای ابری میزبانی می‌شود، کار می‌کند. TEE مزایای امنیتی زیر را ارائه می دهد:

این تضمین می کند که کدی که در TEE کار می کند باینری خاص ارائه شده توسط Google است. تا زمانی که این شرط برآورده نشود، سرویس تجمیع نمی تواند به کلیدهای رمزگشایی که برای کار کردن نیاز دارد دسترسی پیدا کند.
این امنیت را در اطراف فرآیند در حال اجرا ارائه می دهد و آن را از نظارت یا دستکاری خارجی جدا می کند.

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

برای اطلاعات بیشتر در مورد طراحی، گردش کار و ملاحظات امنیتی سرویس تجمیع، به سند سرویس تجمیع در GitHub مراجعه کنید.

خدمات مدیریت کلید

این سرویس تأیید می‌کند که یک سرویس تجمیع نسخه تأیید شده باینری را اجرا می‌کند و سپس کلیدهای رمزگشایی صحیح را برای داده‌های راه‌اندازی به سرویس تجمیع در فناوری تبلیغات ارائه می‌دهد.

حسابداری گزارش انباشته

این سرویس تعداد دفعات دسترسی سرویس تجمیع فناوری تبلیغات به یک محرک خاص را ردیابی می‌کند - که می‌تواند حاوی چندین کلید تجمع باشد - و دسترسی به تعداد مناسب رمزگشایی را محدود می‌کند. برای جزئیات پیشنهاد طراحی API Reporting Attribution به سرویس Aggregation مراجعه کنید.

API گزارش های جمع آوری

API برای ایجاد مشارکت در گزارش‌های جمع‌آوری‌شده از همان API پایه استفاده می‌کند که هنگام ثبت منبع انتساب برای گزارش‌های سطح رویداد. بخش‌های زیر افزونه‌های API را توضیح می‌دهند.

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

هنگامی که API به URI منبع Attribution درخواست می‌کند، فناوری تبلیغات می‌تواند با پاسخ دادن با فیلد جدیدی به نام aggregation_keys در سرصفحه HTTP Attribution-Reporting-Register-Source ، فهرستی از کلیدهای تجمیع را به نام histogram_contributions ثبت کند، با کلید به‌عنوان key_name و مقدار به‌عنوان key_piece :

(کلید) نام کلید: رشته ای برای نام کلید. به عنوان یک کلید اتصال برای ترکیب با کلیدهای سمت ماشه برای تشکیل کلید نهایی استفاده می شود.
(Value) قطعه کلید: یک مقدار رشته بیت برای کلید.

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

کلیدهای نهایی به حداکثر 128 بیت محدود می شوند. کلیدهای طولانی تر از این کوتاه هستند. این بدان معنی است که رشته های هگز در JSON باید حداکثر به 32 رقم محدود شود.

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

در مثال زیر، یک فناوری تبلیغاتی از API برای جمع آوری موارد زیر استفاده می کند:

تعداد تبدیل کل در سطح کمپین
مجموع ارزش خرید در سطح جغرافیایی

// This is where the Attribution-Reporting-Register-Source object appears when
// an ad tech registers an attribution source.

// Attribution source metadata specifying histogram contributions in aggregate report.
Attribution-Reporting-Register-Source:
…
aggregation_keys: {
  // Generates a "0x159" key piece named (low order bits of the key) for the key
  // named "campaignCounts".
  // User saw an ad from campaign 345 (out of 511).

  "campaignCounts": "0x159",
  // Generates a "0x5" key piece (low order bits of the key) for the key name "geoValue"
  // Source-side geo region = 5 (US), out of a possible ~100 regions.
  "geoValue": "0x5"
}

ماشه تجمعی را ثبت کنید

ثبت ماشه شامل دو فیلد اضافی است.

فیلد اول برای ثبت لیستی از کلیدهای انبوه در سمت ماشه استفاده می شود. فناوری تبلیغات باید با فیلد aggregatable_trigger_data در سرصفحه HTTP Attribution-Reporting-Register-Trigger با فیلدهای زیر برای هر کلید انبوه در لیست پاسخ دهد:

قطعه کلید: یک مقدار رشته بیت برای کلید.
کلیدهای منبع: فهرستی از رشته ها با نام کلیدهای جانبی منبع انتساب که کلید ماشه باید با آنها ترکیب شود تا کلیدهای نهایی را تشکیل دهند.

فیلد دوم برای ثبت لیستی از مقادیری که باید به هر کلید کمک کند استفاده می شود. فناوری تبلیغات باید با فیلد aggregatable_values در سرصفحه HTTP Attribution-Reporting-Register-Trigger پاسخ دهد. فیلد دوم برای ثبت لیستی از مقادیری استفاده می شود که باید به هر کلید کمک کند، که می تواند اعداد صحیح در محدوده $ [1, 2^{16}] $ باشد.

هر ماشه می‌تواند مشارکت‌های متعددی در گزارش‌های انباشته داشته باشد. مقدار کل مشارکت‌ها در هر رویداد منبع معین با یک پارامتر L1 $ محدود می‌شود، که حداکثر مجموع مشارکت‌ها (مقادیر) در همه کلیدهای مجموع برای یک منبع معین است. $ L1 $ به حساسیت L1 یا هنجار مشارکت های هیستوگرام در هر رویداد منبع اشاره دارد. فراتر از این محدودیت ها باعث می شود که مشارکت های آتی بی سر و صدا کاهش یابد. پیشنهاد اولیه این است که L1 $ را به $ 2^{16} $ (65536) تنظیم کنید.

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

در مثال زیر، بودجه حریم خصوصی به طور مساوی بین campaignCounts و geoValue تقسیم می‌شود، با تقسیم مبلغ L1 $ به هر یک:

// This is where the Attribution-Reporting-Register-Trigger object appears
// when an ad tech registers a conversion trigger.

// Specify a list of dictionaries that generates aggregation keys.
Attribution-Reporting-Register-Trigger:{
    …
    "aggregatable_trigger_data":

    [
    // Each dictionary independently adds pieces to multiple source keys.
    {
    // Conversion type purchase = 2 at a 9-bit offset, i.e. 2 << 9.
    // A 9-bit offset is needed because there are 511 possible campaigns, which
    // will take up 9 bits in the resulting key.
        "key_piece": "0x400",// Conversion type purchase = 2
        // Apply this key piece to:
        "source_keys": ["campaignCounts"]
    },
    {
    // Purchase category shirts = 21 at a 7-bit offset, i.e. 21 << 7.
    // A 7-bit offset is needed because there are ~100 regions for the geo key,
    // which will take up 7 bits of space in the resulting key.
        "key_piece": "0xA80",
        // Apply this key piece to:
        "source_keys": ["geoValue", "nonMatchingIdsListedHereAreIgnored"]
    }
    ]

    // Specify an amount of an abstract value which can be integers in [1, 2^16] to
    // contribute to each key that is attached to aggregation keys in the order that
    // they're generated.
    aggregatable_values:
    {
    // Privacy budget for each key is L1 / 2 = 2^15 (32768).
    // Conversion count was 1.
    // Scale the count to use the full budget allocated: 1 * 32768 = 32768.
        "campaignCounts": 32768,

    // Purchase price was $52.
    // Purchase values for the app range from $1 to $1,024 (integers only).
    // Scaling factor applied is 32768 / 1024 = 32.
    // For $52 purchase, scale the value by 32 ($52 * 32 = $1,664).
        "geoValue": 1664
    }
}

مثال قبلی مشارکت های هیستوگرام زیر را ایجاد می کند:

[
  // campaignCounts:
  {
    "key": "0x559", // = 0x159 | 0x400
    "value": 32768
  },
  // geoValue:
  {
    "key": "0xA85",  // = 0x5 | 0xA80
    "value": 1664
  }
]

برای به دست آوردن مقادیر صحیح، نویز مدول که اعمال می شود، می توان فاکتورهای مقیاس بندی را معکوس کرد:

L1 = 65536
trueCampaignCounts = campaignCounts / (L1 / 2)
trueGeoValue = geoValue / (L1 / 2) * 1024

حریم خصوصی متفاوت

هدف این API داشتن چارچوبی است که بتواند از اندازه گیری مجموع خصوصی متفاوت پشتیبانی کند. این را می توان با اضافه کردن نویز متناسب با بودجه L1 $، مانند انتخاب نویز با توزیع زیر به دست آورد:

\[ Laplace(\frac{L1}{ε}) \]

API مخاطب محافظت شده و یکپارچه سازی API Reporting Attribution

یکپارچه‌سازی متقابل API در میان APIهای گزارش‌دهی اعتبار و مخاطب محافظت‌شده به Adtech‌ها این امکان را می‌دهد تا عملکرد اسناد خود را در تاکتیک‌های مختلف بازاریابی مجدد ارزیابی کنند تا بفهمند کدام نوع از مخاطبان بالاترین بازگشت سرمایه را ارائه می‌دهند.

از طریق این ادغام متقابل API، adtech ها می توانند:

یک نقشه کلید-مقدار از URI ها ایجاد کنید تا هم برای 1) گزارش تعامل و 2) برای ثبت منبع استفاده شود.
CustomAudience در نگاشت کلید سمت منبع برای گزارش خلاصه انبوه (با استفاده از Attribution Reporting API) وارد کنید.

هنگامی که کاربر یک تبلیغ را می بیند یا روی آن کلیک می کند:

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

برای اطلاعات بیشتر در مورد نحوه فعال کردن این مورد در مخاطب محافظت شده، به بخش مربوطه توضیح API مخاطب محافظت شده مراجعه کنید.

اولویت ثبت، اسناد و نمونه های گزارش

این مثال مجموعه‌ای از تعاملات کاربر را نشان می‌دهد و اینکه چگونه فناوری تبلیغات منبع انتساب و اولویت‌های راه‌اندازی تعریف‌شده می‌توانند بر گزارش‌های نسبت داده شده تأثیر بگذارند. در این مثال موارد زیر را فرض می کنیم:

همه منابع انتساب و محرک‌ها توسط فناوری تبلیغات یکسان، برای یک تبلیغ‌کننده ثبت می‌شوند.
همه منابع انتساب و محرک‌ها در اولین پنجره گزارش رویداد (در عرض 2 روز پس از نمایش اولیه تبلیغات در یک برنامه ناشر) اتفاق می‌افتند.

موردی را در نظر بگیرید که کاربر کارهای زیر را انجام می دهد:

کاربر یک تبلیغ را می بیند. فناوری تبلیغات یک منبع انتساب را با API با اولویت 0 ثبت می کند (نمایش شماره 1).
کاربر تبلیغی را می بیند که با اولویت 0 ثبت شده است (نمایش شماره 2).
کاربر روی تبلیغی که با اولویت 1 ثبت شده کلیک می کند (کلیک شماره 1).
کاربر در یک برنامه تبلیغ کننده تبدیل می کند (به صفحه فرود می رسد). فناوری تبلیغات یک ماشه را با API، با اولویت 0 (تبدیل شماره 1) ثبت می کند.
- همانطور که محرک‌ها ثبت می‌شوند، API ابتدا قبل از ایجاد گزارش، انتساب را انجام می‌دهد.
- 3 منبع انتساب در دسترس است: مشاهده #1، مشاهده #2 و کلیک بر #1. API این ماشه را به کلیک شماره 1 نسبت می دهد زیرا بالاترین اولویت و جدیدترین است.
- نمای شماره 1 و نمای شماره 2 نادیده گرفته شده اند و دیگر واجد شرایط انتساب آینده نیستند.
کاربر یک مورد را به سبد خرید خود در برنامه تبلیغ کننده اضافه می کند که با اولویت 1 ثبت شده است (تبدیل شماره 2).
- کلیک شماره 1 تنها منبع اسناد واجد شرایط است. API این ماشه را به کلیک #1 نسبت می دهد.
کاربر یک مورد را در برنامه تبلیغ‌کننده به سبد خرید خود اضافه می‌کند که با اولویت 1 ثبت شده است (تبدیل شماره 3).
- کلیک شماره 1 تنها منبع اسناد واجد شرایط است. API این ماشه را به کلیک #1 نسبت می دهد.
کاربر یک مورد را در برنامه تبلیغ‌کننده به سبد خرید خود اضافه می‌کند که با اولویت 1 ثبت شده است (تبدیل شماره 4).
- کلیک شماره 1 تنها منبع اسناد واجد شرایط است. API این ماشه را به کلیک #1 نسبت می دهد.
کاربر در اپلیکیشن آگهی دهنده، با اولویت 2 (تبدیل شماره 5) ثبت نام کرده، خرید می کند.
- کلیک شماره 1 تنها منبع اسناد واجد شرایط است. API این ماشه را به کلیک #1 نسبت می دهد.

گزارش‌های سطح رویداد دارای ویژگی‌های زیر هستند:

به طور پیش‌فرض، 3 محرک اول منتسب به یک کلیک و اولین محرک منتسب به یک نما پس از پنجره‌های گزارش کاربردی ارسال می‌شوند.
در پنجره گزارش‌دهی، اگر محرک‌هایی با اولویت بالاتر ثبت شده باشند، آن‌ها اولویت دارند و جایگزین جدیدترین محرک می‌شوند.
در مثال قبل، فناوری تبلیغات 3 گزارش رویداد را پس از پنجره گزارش 2 روزه برای تبدیل شماره 2، تبدیل شماره 3 و تبدیل شماره 5 دریافت می کند.
- همه 5 محرک به کلیک #1 نسبت داده می شوند. به طور پیش فرض، API گزارش هایی را برای 3 محرک اول ارسال می کند: تبدیل شماره 1، تبدیل شماره 2 و تبدیل شماره 3.
- با این حال، اولویت تبدیل شماره 4 ( 1 ) بالاتر از اولویت تبدیل شماره 1 ( 0 ) است. گزارش رویداد تبدیل شماره 4 جایگزین گزارش رویداد تبدیل شماره 1 برای ارسال می شود.
- علاوه بر این، اولویت تبدیل شماره 5 ( 2 ) بالاتر از هر محرک دیگری است. گزارش رویداد تبدیل شماره 5 جایگزین گزارش تبدیل شماره 4 برای ارسال می شود.

گزارش های انباشته دارای ویژگی های زیر است:

گزارش‌های جمع‌آوری‌شده رمزگذاری‌شده به محض پردازش، چند ساعت پس از ثبت محرک‌ها، به فناوری تبلیغات ارسال می‌شوند.
به‌عنوان یک فناوری تبلیغات، دسته‌های آن‌ها را بر اساس اطلاعاتی که بدون رمزگذاری در گزارش‌های جمع‌آوری‌شده شما آمده است، ایجاد می‌کنید. این اطلاعات در قسمت shared_info در گزارش انبوه شما موجود است و شامل مهر زمان و مبدا گزارش است. نمی‌توانید بر اساس اطلاعات رمزگذاری‌شده در جفت‌های کلید-مقدار انبوه خود دسته‌بندی کنید. برخی از استراتژی‌های ساده‌ای که می‌توانید دنبال کنید، جمع‌آوری گزارش‌های روزانه یا هفتگی است. در حالت ایده آل، دسته ها باید حداقل دارای 100 گزارش باشند.
این به فناوری تبلیغات بستگی دارد که چه زمانی و چگونه گزارش‌های جمع‌آوری‌شده را دسته‌بندی کند و به سرویس تجمیع ارسال کند.
در مقایسه با گزارش‌های سطح رویداد، گزارش‌های انبوه رمزگذاری‌شده می‌توانند محرک‌های بیشتری را به یک منبع نسبت دهند.
در مثال قبل، 5 گزارش جمع آوری ارسال می شود، یکی برای هر محرک ثبت شده.

گزارش های اشکال زدایی انتقالی

Attribution Reporting API یک روش جدید و نسبتاً پیچیده برای انجام اندازه‌گیری اسناد بدون شناسه‌های بین برنامه‌ای است. به این ترتیب، ما از یک مکانیسم انتقالی برای کسب اطلاعات بیشتر درباره گزارش‌های انتساب زمانی که شناسه تبلیغاتی در دسترس است پشتیبانی می‌کنیم (کاربر از شخصی‌سازی با استفاده از شناسه تبلیغاتی منصرف نشده است و ناشر یا برنامه تبلیغ‌کننده مجوزهای AdID را اعلام کرده است) . این تضمین می‌کند که API می‌تواند به طور کامل در حین انتشار قابل درک باشد، به رفع اشکالات کمک کند، و عملکرد را راحت‌تر با جایگزین‌های مبتنی بر شناسه تبلیغاتی مقایسه کند. دو نوع گزارش اشکال زدایی وجود دارد: Attribution-Success و Verbose.

راهنمای گزارش‌های اشکال‌زدایی انتقالی را برای جزئیات بیشتر در مورد گزارش‌های اشکال‌زدایی با اندازه‌گیری برنامه به وب و وب به برنامه بخوانید.

گزارش های اشکال زدایی انتساب-موفقیت

ثبت منبع و ماشه هر دو یک فیلد debug_key جدید 64 بیتی (قالب‌بندی شده به عنوان یک رشته) را می‌پذیرند که فناوری تبلیغات آن را پر می‌کند. source_debug_key و trigger_debug_key بدون تغییر در گزارش‌های سطح رویداد و انبوه ارسال می‌شوند.

اگر گزارشی با هر دو کلید اشکال‌زدایی منبع و راه‌انداز ایجاد شود، یک گزارش اشکال‌زدایی تکراری با تأخیر محدود به یک نقطه پایانی .well-known/attribution-reporting/debug/report-event-attribution ارسال می‌شود. گزارش‌های اشکال‌زدایی با گزارش‌های معمولی یکسان هستند، از جمله هر دو فیلد کلید اشکال‌زدایی. گنجاندن این کلیدها در هر دو اجازه می دهد تا گزارش های عادی را به جریان جداگانه گزارش های اشکال زدایی گره بزنید.

برای گزارش های سطح رویداد:
- گزارش های اشکال زدایی تکراری با تأخیر محدود ارسال می شوند و بنابراین با محدودیت های مربوط به محرک های موجود سرکوب نمی شوند ، که به AD Tech اجازه می دهد تا تأثیر آن محدودیت ها را برای گزارش های سطح رویداد درک کند.
- گزارش های سطح رویداد مرتبط با وقایع ماشه کاذب ، trigger_debug_key را ندارند. این به فناوری تبلیغی اجازه می دهد تا با دقت بیشتری درک کند که چگونه سر و صدا در API اعمال می شود.
برای گزارش های قابل جمع شدن:
- ما از یک قسمت جدید debug_cleartext_payload پشتیبانی خواهیم کرد که حاوی بار رمزگشایی شده است ، تنها در صورت تنظیم هر دو source_debug_key و trigger_debug_key .

گزارش های اشکال زدایی کلامی

گزارش های اشکال زدایی Verbose به توسعه دهندگان این امکان را می دهد تا برخی از خرابی ها را در منبع انتساب یا ثبت نام های شروع کنند. این گزارش های اشکال زدایی با تأخیر محدود پس از منبع انتساب یا ثبت نام های شروع به A به A ارسال می شوند. well-known/attribution-reporting/debug/verbose نقطه پایانی.

هر گزارش Verbose شامل زمینه های زیر است:

نوع : چه چیزی باعث شده گزارش تولید شود. لیست کامل انواع گزارش های Verbose را مشاهده کنید.
- به طور کلی ، گزارش های Verbose منبع و گزارش های Verbose وجود دارد.
- گزارش های Verbose منبع نیاز به شناسه تبلیغاتی در دسترس برنامه ناشر دارد و گزارش های Verbose Trrigger نیاز به شناسه تبلیغات در دسترس برنامه تبلیغات دارد.
- گزارش های Verbose Trigger (به استثنای trigger-no-matching-source ) می تواند به صورت اختیاری شامل source_debug_key باشد. این تنها در صورتی که شناسه تبلیغاتی نیز در دسترس برنامه ناشر باشد ، درج می شود.
بدن : بدن گزارش ، که به نوع آن بستگی دارد.

فناوری های تبلیغاتی برای دریافت گزارش های اشکال زدایی شفاف با استفاده از یک زمینه جدید debug_reporting در زمینه Attribution-Reporting-Register_Source و Attribution-Reporting-Register-Trigger باید انتخاب کنند.

گزارش های Verbose منبع فقط نیاز به انتخاب در هدر ثبت نام منبع دارد.
گزارش های اشکال زدایی Trigger فقط در هدر ثبت نام ماشه نیاز به انتخاب دارد.

نحوه استفاده از گزارش های اشکال زدایی

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

برای هر گزارش انتساب اشکال زدایی ، بررسی کنید که آیا گزارش انتساب منظم را دریافت می کنید که با دو کلید اشکال زدایی مطابقت دارد یا خیر.

هنگامی که هیچ تطبیقی وجود ندارد ، به دلایل مختلف می تواند باشد.

همانطور که در نظر گرفته شده است:

رفتارهای API حفظ حریم خصوصی:
- یک کاربر به حد نرخ گزارش رسید - ایجاد تمام گزارش های بعدی برای ارسال در دوره زمانی. یا منبع به دلیل محدودیت مقصد در انتظار حذف می شود.
- برای گزارش های سطح رویداد: گزارش منوط به پاسخ تصادفی (سر و صدا) است و سرکوب می شود ، یا ممکن است گزارش تصادفی دریافت کنید.
- برای گزارش های سطح رویداد: محدودیت سه (برای کلیک) یا یک گزارش (برای بازدید) به دست آمده است ، و گزارش های بعدی هیچ مجموعه اولویت صریح و یا اولویت ای پایین تر از گزارش های موجود ندارند.
- محدودیت سهم برای گزارش های قابل جمع شدن از آن فراتر رفته است.
منطق تجاری تعریف شده توسط فناوری:
- یک ماشه از طریق فیلترها یا قوانین اولویت فیلتر می شود.
تأخیر زمان یا تعامل با در دسترس بودن شبکه (به عنوان مثال ، کاربر برای مدت طولانی دستگاه خود را خاموش می کند).

علل ناخواسته:

مسائل مربوط به اجرای:
- هدر منبع اشتباه است.
- هدر ماشه به اشتباه تنظیم شده است.
- سایر موارد پیکربندی.
مشکلات دستگاه یا شبکه:
- خرابی به دلیل شرایط شبکه.
- پاسخ ثبت نام منبع یا ماشه به مشتری نمی رسد.
- اشکال API

ملاحظات آینده و سوالات باز

API گزارش انتساب یک کار در حال انجام است. ما همچنین در حال بررسی ویژگی های بالقوه آینده ، مانند مدل های انتساب بدون کلیک و موارد استفاده از اندازه گیری متقابل هستیم.

علاوه بر این ، ما می خواهیم در مورد چند موضوع به دنبال بازخورد جامعه باشیم:

آیا موارد استفاده ای وجود دارد که دوست دارید API گزارش هایی را برای نصب تأیید شده ارسال کند؟ این گزارش ها در برابر محدودیت های مربوط به سیستم عامل های فناوری تبلیغی حساب می شود.
آیا با عبور از InputEvent از برنامه به AD Tech برای ثبت نام منبع ، مشکلی پیش بینی می کنید؟
آیا موارد استفاده ویژه ای برای برنامه های از پیش بارگذاری شده یا برنامه های نصب مجدد دارید؟

به روز رسانی های اخیر

لیست تغییرات آتی و مشکلات شناخته شده را به روز کرد
معرفی درخواست، یک ویژگی جدید با هدف انتشار برای H2 2025. درخواست به فن‌آوران تبلیغات امکان می‌دهد چندین بار گزارش‌های سرویس تجمیع را پردازش کنند، و از تجزیه و تحلیل انعطاف‌پذیر برای نیازهای اندازه‌گیری مختلف پشتیبانی می‌کند. برای کسب اطلاعات بیشتر و ارائه بازخورد به بحث در GitHub بپیوندید.

نمای کلی

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

مکانیسم های قبلی توانایی پیوند دادن هویت کاربر را بین دو برنامه یا دامنه متفاوت محدود می کند.

Attribution Reporting API موارد استفاده زیر را پشتیبانی می کند:

گزارش تبدیل: به تبلیغ‌کنندگان کمک کنید عملکرد کمپین‌های خود را با نشان دادن تعداد تبدیل (محرک) و مقادیر تبدیل (محرک) در ابعاد مختلف، مانند کمپین، گروه تبلیغات، و خلاقیت تبلیغاتی اندازه‌گیری کنند.
بهینه‌سازی: گزارش‌های سطح رویداد را ارائه می‌کند که از بهینه‌سازی هزینه‌های تبلیغات پشتیبانی می‌کند، با ارائه داده‌های انتساب هر نمایش که می‌تواند برای آموزش مدل‌های ML استفاده شود.
تشخیص فعالیت نامعتبر: گزارش هایی ارائه می دهد که می تواند در ترافیک نامعتبر و شناسایی و تجزیه و تحلیل تقلب در تبلیغات استفاده شود.

در سطح بالا، API گزارش انتساب به شرح زیر عمل می کند، که بخش های بعدی این سند با جزئیات بیشتر توضیح می دهد:

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

به APIهای Attribution Reporting دسترسی پیدا کنید

ثبت منبع انتساب (کلیک کنید یا مشاهده کنید)

URI منبع انتساب: پلتفرم درخواستی را به این URI صادر می کند تا متادیتا مرتبط با منبع انتساب را واکشی کند.
رویداد ورودی: یا یک شیء InputEvent (برای یک رویداد کلیک) یا null (برای یک رویداد مشاهده).

شناسه رویداد منبع : این مقدار داده‌های سطح رویداد مرتبط با این منبع انتساب (کلیک یا مشاهده آگهی) را نشان می‌دهد. باید یک عدد صحیح بدون علامت 64 بیتی باشد که به صورت رشته فرمت شده است.
مقصد : مبدایی که eTLD+1 یا نام بسته برنامه آن در آن رویداد ماشه رخ می دهد.
انقضا (اختیاری) : انقضا، در چند ثانیه، برای زمانی که منبع باید از دستگاه حذف شود. پیش‌فرض 30 روز با حداقل مقدار 1 روز و حداکثر مقدار 30 روز است. این به نزدیکترین روز گرد می شود. می تواند به عنوان یک عدد صحیح بدون علامت 64 بیتی یا رشته ای قالب بندی شود.
پنجره گزارش رویداد (اختیاری) : مدت زمان بر حسب ثانیه پس از ثبت منبع که طی آن ممکن است گزارش رویداد برای این منبع ایجاد شود. اگر پنجره گزارش رویداد گذشته باشد، اما انقضا هنوز به پایان نرسیده است، باز هم می‌توان یک راه‌انداز را با یک منبع مطابقت داد، اما گزارش رویداد برای آن راه‌انداز ارسال نمی‌شود. نمی تواند بزرگتر از Expiry باشد. می تواند به عنوان یک عدد صحیح بدون علامت 64 بیتی یا رشته ای قالب بندی شود.
پنجره گزارش انبوه (اختیاری) : مدت زمان بر حسب ثانیه پس از ثبت منبع که طی آن ممکن است گزارش های انبوهی برای این منبع ایجاد شود. نمی تواند بزرگتر از Expiry باشد. می تواند به عنوان یک عدد صحیح بدون علامت 64 بیتی یا رشته ای قالب بندی شود.
اولویت منبع (اختیاری) : برای انتخاب منبع انتساب که یک راه‌انداز معین باید با کدام منبع انتساب مرتبط باشد، استفاده می‌شود، در صورتی که چندین منبع انتساب می‌تواند با محرک مرتبط باشد. باید یک عدد صحیح امضا شده 64 بیتی باشد که به صورت رشته فرمت شده است.

هنگامی که یک ماشه دریافت می شود، API منبع انتساب منطبق را با بالاترین مقدار اولویت منبع پیدا می کند و یک گزارش ایجاد می کند. هر پلتفرم فناوری تبلیغاتی می تواند استراتژی اولویت بندی خود را تعریف کند. برای جزئیات بیشتر در مورد چگونگی تأثیر اولویت بر انتساب، به بخش مثال اولویت بندی مراجعه کنید.

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

راهنمای توسعه دهنده شامل نمونه هایی است که نحوه پذیرش ثبت منبع را نشان می دهد.

مراحل زیر یک نمونه گردش کار را نشان می دهد:

SDK فناوری تبلیغات، API را فراخوانی می‌کند تا ثبت منبع انتساب را آغاز کند، و یک URI برای API برای فراخوانی مشخص می‌کند:
```
registerSource(
    Uri.parse("https://adtech.example/attribution_source?AD_TECH_PROVIDED_METADATA"),
    myClickEvent);
```
API از https://adtech.example/attribution_source? AD_TECH_PROVIDED_METADATA ، با استفاده از یکی از سرصفحه‌های زیر:
```

Attribution-Reporting-Source-Info: navigation


Attribution-Reporting-Source-Info: event
```

سرور HTTPS این فناوری تبلیغاتی با سرصفحه هایی حاوی موارد زیر پاسخ می دهد:

Attribution-Reporting-Register-Source: {
    "destination": "android-app://com.advertiser.example",
    "source_event_id": "234",
    "expiry": "60000",
    "priority": "5"
}
Attribution-Reporting-Redirect:
https://adtechpartner1.example?their_ad_click_id=567
Attribution-Reporting-Redirect:
https://adtechpartner2.example?their_ad_click_id=890

API برای هر URL مشخص شده در Attribution-Reporting-Redirect درخواست می کند. در این مثال، دو URL شریک فناوری تبلیغاتی مشخص شده‌اند، بنابراین API یک درخواست به https://adtechpartner1.example?their_ad_click_id=567 و یک درخواست دیگر به https://adtechpartner2.example?their_ad_click_id=890 .
سرور HTTPS این فناوری تبلیغاتی با سرصفحه هایی حاوی موارد زیر پاسخ می دهد:
```
Attribution-Reporting-Register-Source: {
    "destination": "android-app://com.advertiser.example",
    "source_event_id": "789",
    "expiry": "120000",
    "priority": "2"
}
```
توجه: پاسخ‌های متخصصان تبلیغات می‌توانند ابرداده‌های مختلفی را در سرصفحه Attribution-Reporting-Register-Source مشخص کنند.

سه منبع انتساب ناوبری (کلیک کنید) بر اساس درخواست های نشان داده شده در مراحل قبلی ثبت می شود.

یک منبع انتساب از WebView ثبت کنید

ثبت یک ماشه (تبدیل)

داده های ماشه: داده هایی برای شناسایی رویداد ماشه (3 بیت برای کلیک، 1 بیت برای بازدید). باید یک عدد صحیح امضا شده 64 بیتی باشد که به صورت رشته فرمت شده است.
اولویت راه‌اندازی (اختیاری): نشان‌دهنده اولویت این راه‌انداز در مقایسه با سایر محرک‌ها برای همان منبع انتساب است. باید یک عدد صحیح امضا شده 64 بیتی باشد که به صورت رشته فرمت شده است. برای جزئیات بیشتر در مورد چگونگی تأثیر اولویت بر گزارش، به بخش اولویت بندی مراجعه کنید.
کلید Deduplication (اختیاری): برای شناسایی مواردی استفاده می شود که در آن یک ماشه چندین بار توسط یک پلت فرم فناوری تبلیغاتی یکسان، برای منبع انتساب یکسانی ثبت شده است. باید یک عدد صحیح امضا شده 64 بیتی باشد که به صورت رشته فرمت شده است.
کلیدهای تجمیع (اختیاری): فهرستی از فرهنگ لغت که کلیدهای تجمیع را مشخص می کند و گزارش های انباشته باید دارای ارزش تجمیع شوند.
مقادیر تجمیع (اختیاری): فهرستی از مقادیری که به هر کلید کمک می کند.
فیلترها (اختیاری): برای فیلتر کردن محرک ها یا داده های ماشه استفاده می شود. برای جزئیات بیشتر، بخش فیلترهای ماشه را در این صفحه ببینید.

راهنمای توسعه‌دهنده شامل نمونه‌هایی است که نحوه پذیرش ثبت ماشه را نشان می‌دهد.

مراحل زیر یک نمونه گردش کار را نشان می دهد:

Ad tech SDK API را فراخوانی می‌کند تا با استفاده از یک URI از پیش ثبت‌نام‌شده، ثبت راه‌اندازی را آغاز کند. برای اطلاعات بیشتر به ثبت نام برای یک حساب Sandbox حریم خصوصی مراجعه کنید.
```
registerTrigger(
    Uri.parse("https://adtech.example/attribution_trigger?AD_TECH_PROVIDED_METADATA"));
```
API درخواستی به https://adtech.example/attribution_trigger? AD_TECH_PROVIDED_METADATA .

سرور HTTPS این فناوری تبلیغاتی با سرصفحه هایی حاوی موارد زیر پاسخ می دهد:

Attribution-Reporting-Register-Trigger: {
    "event_trigger_data": [{
    "trigger_data": "1122",
    // This returns 010 for click-through conversions (CTCs) and 0 for
    // view-through conversions (VTCs) in reports
    "priority": "3",
    "deduplication_key": "3344"
    }],
}
Attribution-Reporting-Redirect: https://adtechpartner.example?app_install=567

API برای هر URL مشخص شده در Attribution-Reporting-Redirect درخواست می کند. در این مثال، تنها یک URL مشخص شده است، بنابراین API یک درخواست به https://adtechpartner.example?app_install=567 ارسال می کند.
سرور HTTPS این فناوری تبلیغاتی با سرصفحه هایی حاوی موارد زیر پاسخ می دهد:
```
Attribution-Reporting-Register-Trigger: {
"event_trigger_data":[{
  "trigger_data": "5566",
  "priority": "3",
  "deduplication_key": "3344"
}]
}
```
دو تریگر بر اساس درخواست های مراحل قبل ثبت می شود.

قابلیت های اسناد

بخش‌های زیر توضیح می‌دهند که چگونه API گزارش Attribution با محرک‌های تبدیل به منابع انتساب مطابقت دارد.

الگوریتم انتساب با اولویت منبع اعمال شد

Attribution Reporting API از یک الگوریتم انتساب با اولویت منبع برای تطبیق یک محرک (تبدیل) به منبع انتساب استفاده می کند.

پارامترهای اولویت راه هایی را برای سفارشی کردن انتساب محرک ها به منابع ارائه می دهند:

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

فیلترهای ماشه ای

ثبت منبع و ماشه شامل ویژگی های اختیاری اضافی برای انجام موارد زیر است:

برخی از محرک ها را به صورت انتخابی فیلتر کنید و به طور موثر آنها را نادیده بگیرید.
داده‌های راه‌انداز را برای گزارش‌های سطح رویداد بر اساس داده‌های منبع انتخاب کنید.
حذف یک ماشه از گزارش‌های سطح رویداد را انتخاب کنید.

در صورت صحت هر یک از موارد زیر، راه‌اندازها از گزارش‌های سطح رویداد حذف می‌شوند:

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

انتساب پس از نصب

هنگام ثبت منبع انتساب، یک پنجره انتساب نصب را مشخص کنید که در طی آن نصب ها مورد انتظار است (معمولاً 2-7 روز، محدوده پذیرفته شده 1 تا 30 روز). این پنجره زمانی را به صورت چند ثانیه مشخص کنید.
هنگام ثبت منبع انتساب، یک پنجره انحصاری انتساب پس از نصب را مشخص کنید که در آن رویدادهای راه‌اندازی پس از نصب باید با منبع انتسابی که باعث نصب شده است مرتبط شود (معمولاً 7-30 روز، محدوده پذیرفته شده 0 تا 30 روز). این پنجره زمانی را به صورت چند ثانیه مشخص کنید.
Attribution Reporting API زمانی که نصب برنامه اتفاق می‌افتد اعتبارسنجی می‌کند و به صورت داخلی نصب را به منبع انتساب با اولویت منبع نسبت می‌دهد. با این حال، نصب برای فن‌آوری‌های تبلیغاتی ارسال نمی‌شود و در محدودیت‌های نرخ مربوطه پلتفرم حساب نمی‌شود.
اعتبار سنجی نصب برنامه برای هر برنامه دانلود شده در دسترس است.
هر راه‌اندازی آتی که در پنجره انتساب پس از نصب اتفاق می‌افتد، تا زمانی که منبع انتساب واجد شرایط باشد، به همان منبع انتساب نصب معتبر نسبت داده می‌شود.

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

رویداد	روزی که رویداد رخ می دهد	یادداشت ها
1 را کلیک کنید	1	`install_attribution_window` روی `172800` (2 روز) و `post_install_exclusivity_window` روی `864000` (10 روز) تنظیم شده است.
نصب تایید شده	2	API به صورت داخلی به نصب‌های تأیید شده مشخص می‌شود، اما این نصب‌ها به عنوان محرک در نظر گرفته نمی‌شوند. بنابراین گزارشی در این مرحله ارسال نمی شود.
ماشه 1 (اولین باز)	2	اولین ماشه توسط فناوری تبلیغات ثبت شد. در این مثال، یک اولین باز را نشان می دهد اما می تواند هر نوع ماشه ای باشد. منتسب به کلیک 1 (منطبق با انتساب نصب تأیید شده).
روی 2 کلیک کنید	4	از مقادیر یکسانی برای `install_attribution_window` و `post_install_exclusivity_window` استفاده می کند.
Trigger 2 (پست نصب)	5	عامل دوم توسط فناوری تبلیغات ثبت شده است. در این مثال، یک تبدیل پس از نصب را مانند خرید نشان می دهد. منتسب به کلیک 1 (منطبق با انتساب نصب تأیید شده). کلیک 2 کنار گذاشته شده است و برای انتساب بعدی واجد شرایط نیست.

لیست زیر نکات دیگری را در مورد انتساب پس از نصب ارائه می دهد:

اگر نصب تأیید شده در تعداد روزهای مشخص شده توسط install_attribution_window انجام نشود، انتساب پس از نصب اعمال نمی‌شود.
نصب های تأیید شده توسط فناوری های تبلیغاتی ثبت نمی شوند و در گزارش ها ارسال نمی شوند. آنها در مقابل محدودیت های نرخ یک فناوری تبلیغات حساب نمی شوند. نصب‌های تأیید شده فقط برای شناسایی منبع انتساب استفاده می‌شوند که به نصب اعتبار داده شده است.
در مثال جدول قبل، تریگر 1 و تریگر 2 به ترتیب اولین تبدیل باز و تبدیل پس از نصب را نشان می دهند. با این حال، پلتفرم های فناوری تبلیغات می توانند هر نوع محرکی را ثبت کنند. به عبارت دیگر، اولین ماشه نباید اولین ماشه باز باشد.
اگر پس از انقضای post_install_exclusivity_window ، محرک‌های بیشتری ثبت شوند، با این فرض که منقضی نشده است و به محدودیت‌های نرخ خود نرسیده است، کلیک 1 همچنان واجد شرایط است.
- اگر منبع انتساب با اولویت بالاتر ثبت شده باشد، کلیک 1 همچنان ممکن است از دست برود، یا نادیده گرفته شود.
اگر برنامه تبلیغ‌کننده حذف نصب و مجدداً نصب شود، نصب مجدد به‌عنوان یک نصب تأیید شده جدید محاسبه می‌شود.
اگر کلیک 1 در عوض یک رویداد مشاهده بود، هر دو راه‌انداز «اولین باز» و پس از نصب همچنان به آن نسبت داده می‌شوند. API انتساب را به یک راه‌انداز در هر نما محدود می‌کند، مگر در مورد انتساب پس از نصب که حداکثر دو راه‌انداز در هر نما مجاز است. در مورد انتساب پس از نصب، فناوری تبلیغات می‌تواند ۲ پنجره گزارش متفاوت (در ۲ روز یا در انقضای منبع) دریافت کند.

همه ترکیبی از مسیرهای ماشه مبتنی بر برنامه و وب پشتیبانی می شوند

Attribution Reporting API انتساب مسیرهای راه‌اندازی زیر را در یک دستگاه Android فعال می‌کند:

برنامه به برنامه: کاربر یک تبلیغ را در یک برنامه می بیند، سپس در آن برنامه یا برنامه نصب شده دیگری تبدیل می کند.
برنامه به وب: کاربر یک تبلیغ را در یک برنامه می بیند، سپس در مرورگر موبایل یا برنامه تبدیل می کند.
وب به برنامه: کاربر یک تبلیغ را در مرورگر موبایل یا برنامه می بیند، سپس در یک برنامه تبدیل می کند.
وب به وب: کاربر یک تبلیغ را در مرورگر تلفن همراه یا برنامه می بیند، سپس در همان مرورگر یا مرورگر دیگری در همان دستگاه تبدیل می کند.

برای یک منبع انتساب، چندین محرک را اولویت بندی کنید

به چندین فناوری تبلیغات اجازه دهید منابع یا محرک‌های انتساب را ثبت کنند

راه اندازی یک سرور داخلی برای ثبت نام و دریافت گزارش از API.
ادامه استفاده از شریک اندازه گیری تلفن همراه موجود.

منابع انتساب

تغییر مسیرهای منبع انتساب در روش registerSource() پشتیبانی می شود:

فناوری تبلیغاتی که متد registerSource() را فراخوانی می‌کند، می‌تواند یک فیلد Attribution-Reporting-Redirect اضافی را در پاسخ خود ارائه دهد، که نشان‌دهنده مجموعه URL‌های تغییر مسیر شرکت فناوری تبلیغات شریک است.
سپس API URL های تغییر مسیر را فراخوانی می کند تا منبع انتساب توسط متخصصان تبلیغات شریک ثبت شود.

API همچنین به فناوری‌های تبلیغاتی مختلف اجازه می‌دهد تا هر call registerSource() .

محرک ها

محرک های تکراری را مدیریت کنید

یک فناوری تبلیغاتی ممکن است یک ماشه را چندین بار با API ثبت کند. سناریوها شامل موارد زیر است:

کاربر یک عمل (تریگر) را چندین بار انجام می دهد. به عنوان مثال، کاربر یک محصول را چندین بار در یک پنجره گزارش یکسان مرور می کند.
برنامه تبلیغ‌کننده از چند SDK برای اندازه‌گیری تبدیل استفاده می‌کند که همگی به یک فناوری تبلیغات هدایت می‌شوند. برای مثال، اپلیکیشن تبلیغ‌کننده از دو شریک اندازه‌گیری، MMP #1 و MMP #2 استفاده می‌کند. هر دو MMP به فناوری تبلیغات شماره 3 هدایت می شوند. هنگامی که یک ماشه اتفاق می افتد، هر دو MMP آن ماشه را با API گزارش Attribution ثبت می کنند. سپس فناوری تبلیغات شماره 3 دو تغییر مسیر جداگانه - یکی از MMP شماره 1 و دیگری از MMP شماره 2 - برای همان ماشه دریافت می کند.

روش پیشنهادی: کلید deduplication

روش جایگزین: فن‌آوران تبلیغات در مورد انواع محرک هر تبلیغ‌کننده توافق دارند

نمونه اسناد بین شبکه ای

روز 1: کلیک کاربر روی تبلیغی که توسط Ad tech A ارائه شده است

Ad tech A با URI خود registerSource() فرا می خواند. API درخواستی به URI می‌کند و کلیک با ابرداده از پاسخ سرور Ad tech A ثبت می‌شود.

روز 2: کلیک کاربر روی تبلیغی که توسط Ad tech B ارائه شده است

روز 3: کاربر آگهی ارائه شده توسط Ad tech A را مشاهده می کند

API به همان روشی که در روز اول انجام داد پاسخ می‌دهد، با این تفاوت که یک نما برای Ad tech A و MMP ثبت می‌شود.

روز 4: کاربر برنامه را نصب می کند که از MMP برای اندازه گیری تبدیل استفاده می کند

نمودار زیر روند شرح داده شده در لیست قبلی را نشان می دهد:

Attribution به شرح زیر عمل می کند:

Ad tech A اولویت کلیک‌ها را بالاتر از بازدیدها تنظیم می‌کند و بنابراین نصب منتسب به کلیک در روز اول را دریافت می‌کند.
Ad tech B نصب منتسب در روز 2 را دریافت می کند.
MMP اولویت کلیک‌ها را بالاتر از بازدیدها تنظیم می‌کند و نصب منتسب به کلیک در روز 2 را دریافت می‌کند. کلیک روز 2 بالاترین اولویت، آخرین رویداد تبلیغاتی است.

انتساب بین شبکه ای بدون تغییر مسیر

جریان سطح بالا

هنگام ثبت منبع، شبکه فناوری تبلیغات ارائه دهنده کلیدهای تجمیع منبع خود را به اشتراک می گذارد.
هنگام ثبت ماشه، تبلیغ‌کننده یا شریک اندازه‌گیری انتخاب می‌کند که از کدام قطعات کلیدی سمت منبع استفاده کند و پیکربندی انتساب آن‌ها را مشخص می‌کند.
Attribution بر اساس پیکربندی انتساب، کلیدهای مشترک، و هر منبعی است که واقعاً توسط آن تبلیغ‌کننده یا شریک اندازه‌گیری ثبت شده است (مثلاً از شبکه فناوری تبلیغاتی دیگری که تغییر مسیرها را فعال کرده است).
اگر راه‌انداز به منبعی از فناوری تبلیغات ارائه‌دهنده بدون تغییر مسیر نسبت داده شود، تبلیغ‌کننده یا شریک اندازه‌گیری می‌تواند گزارش جمع‌آوری‌شده‌ای دریافت کند که منبع و بخش‌های کلیدی راه‌انداز تعریف‌شده در مرحله ۲ را ترکیب می‌کند.

ثبت منبع

ماشه ثبت نام

انتساب

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

کاربر روی تبلیغات ارائه شده توسط Ad Techs A ، B ، C و D. کلیک کرد و کاربر سپس برنامه تبلیغ کننده را نصب کرد که از یک شریک AD Tech Ad (MMP) استفاده می کند.
AD Tech A منابع خود را به MMP هدایت می کند.
AD Techs B و C تغییر مسیر نمی دهند ، اما کلیدهای جمع آوری آنها را به اشتراک می گذارند.
Ad Tech D نه تغییر مسیر و نه کلیدهای جمع آوری را به اشتراک می گذارد.

MMP یک منبع از Ad Tech A را ثبت می کند و پیکربندی انتساب را تعریف می کند که شامل Ad Tech B و Ad Tech D. D. است.

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

AD Tech A ، از آنجا که MMP منبع تغییر مسیر آن Ad Tech را ثبت کرد.
Ad Tech B ، از آنجا که AD Tech B کلیدهای مشترک و MMP آن را در پیکربندی انتساب آنها گنجانده است.

انتساب برای MMP شامل موارد زیر نیست:

AD Tech C ، از آنجا که MMP آن را در پیکربندی انتساب آنها درج نکرد.
AD Tech D ، از آنجا که آنها کلیدهای جمع آوری را تغییر نمی دهند و به اشتراک نمی گذارند.

اشکال زدایی

برای پشتیبانی از اشکال زدایی برای انتساب متقابل شبکه بدون تغییر مسیر ، یک زمینه اضافی ، shared_debug_key ، برای تکنیک های تبلیغاتی در دسترس است تا ثبت نام منبع را تنظیم کند. در صورت ثبت نام منبع اصلی ، در هنگام ثبت ماشه برای انتساب شبکه متقابل بدون تغییر مسیر ، منبع مشتق شده مربوطه را نیز به عنوان debug_key تنظیم می کند. این کلید اشکال زدایی در گزارش های رویداد و کل به عنوان source_debug_key پیوست شده است.

این ویژگی اشکال زدایی فقط برای انتساب شبکه متقابل بدون تغییر مسیر تحت سناریوهای زیر پشتیبانی می شود:

اندازه گیری برنامه به برنامه در جایی که ADID مجاز است
برنامه به اندازه گیری وب که در آن ADID مجاز است و هم در منبع برنامه و هم در ماشه وب مطابقت دارد
اندازه گیری وب به وب (در همان برنامه مرورگر) وقتی ar_debug `در هر دو منبع و ماشه وجود دارد

کشف کلیدی برای انتساب متقابل شبکه بدون تغییر مسیر

کشف کلیدی در نظر گرفته شده است تا چگونگی اجرای فناوری های تبلیغاتی (معمولاً MMP ها) پیکربندی انتساب خود را برای اهداف انتساب شبکه متقابل انجام دهد که یک یا چند فناوری تبلیغاتی در حال استفاده از کلیدهای جمع آوری مشترک (همانطور که در انتساب متقابل شبکه بدون تغییر مسیر فوق توضیح داده شده است).

هنگامی که یک MMP از خدمات جمع آوری برای تولید گزارش های خلاصه برای کمپین هایی که شامل منابع مشتق شده است ، پرس و جو می کند ، خدمات جمع آوری نیاز به MMP دارد تا لیست کلیدهای ممکن را به عنوان ورودی برای کار تجمع مشخص کند. در بعضی موارد ، لیست کلیدهای جمع آوری منبع بالقوه ممکن است بسیار بزرگ یا ناشناخته باشد. لیست های بزرگی از کلیدهای ممکن برای ردیابی چالش برانگیز هستند و همچنین احتمالاً برای پردازش کاملاً پیچیده و پرهزینه هستند. به مثال های زیر توجه کنید:

لیست تمام کلیدهای ممکن زیاد است:
- یک شبکه تبلیغاتی در حال اجرای یک ابتکار پیچیده دستیابی کاربر است که شامل 20 کمپین ، هر یک با 10 گروه تبلیغاتی است و هر گروه تبلیغاتی با 5 خلاق که هر هفته بر اساس عملکرد تازه می شوند.
لیست تمام کلیدهای ممکن ناشناخته است:
- یک شبکه تبلیغاتی در حال ارائه تبلیغات در بسیاری از برنامه های تلفن همراه است که در آن لیست کامل شناسه برنامه ناشر در راه اندازی کمپین مشخص نیست.
- یک تبلیغ کننده در حال کار در چندین شبکه تبلیغاتی در خدمت است که در ثبت نام منبع به MMP هدایت نمی شوند. هر شبکه تبلیغاتی دارای ساختار و مقادیر کلیدی متفاوتی است که ممکن است از قبل با MMP به اشتراک نگذاشته باشد.

با معرفی کلیدی کشف:

سرویس جمع آوری دیگر نیازی به شمارش کامل کلیدهای تجمع احتمالی ندارد.
به جای اینکه لیست کاملی از کلیدهای ممکن را مشخص کنید ، یک MMP می تواند مجموعه ای از کلیدهای خالی (یا جزئی خالی) ایجاد کرده و آستانه ای را تنظیم کند ، به طوری که فقط کلیدهای (بدون پیش بینی) با مقادیر بیش از آستانه در خروجی گنجانده شده است.
MMP گزارش خلاصه ای را دریافت می کند که شامل مقادیر پر سر و صدا برای کلیدهایی است که مقادیر آن را بالاتر از آستانه تنظیم می کنند. این گزارش همچنین ممکن است شامل کلیدهایی باشد که هیچ مشارکت کاربر واقعی ندارند و صرفاً بدون استفاده هستند.
MMP از قسمت x_network_bit_mapping در ثبت Trigger استفاده می کند تا تعیین کند که کدام فناوری تبلیغی با کدام کلید مطابقت دارد.
MMP سپس می تواند برای درک مقادیر موجود در کلید منبع با فناوری تبلیغاتی مناسب تماس بگیرد.

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

تغییر مسیر زنجیره ای دیزی

با ارائه چندین هدف Attribution-Reporting-Redirect در یک منبع یا ثبت نام HTTPS Server-Response ، یک فناوری تبلیغی می تواند از API گزارش دهی انتساب برای انجام چندین منبع استفاده کند و با یک تماس API ثبت نام واحد ثبت نام کند.

در پاسخ سرور ، فناوری AD همچنین می تواند یک هدر Location (302 تغییر مسیر) با URL را شامل شود که به نوبه خود منجر به ثبت نام دیگری می شود ، تا حد مشخصی.

هر دو نوع هدست اختیاری هستند و در صورت عدم نیاز به تغییر مسیر ، هیچ یک از آنها قابل ارائه نیست. ممکن است یک یا هر دو نوع هدست ارائه شود. درخواست های ثبت نام منبع و ماشه (از جمله تغییر مسیر) در صورت خرابی شبکه دوباره انجام می شوند. برای جلوگیری از تأثیر قابل توجه بر روی دستگاه ، تعداد قیام در هر درخواست به تعداد ثابت محدود می شود.

تغییر مسیر برای RegisterWebSource و RegisterWebTrigger مورد استفاده مرورگرها پذیرفته نمی شوند. جزئیات بیشتر را می توان در راهنمای Cross Web و Guide Appormation یافت.

مشاهده داده های اندازه گیری در گزارش های انتساب

API گزارش انتساب انواع گزارش های زیر را امکان پذیر می کند ، که بعداً در این صفحه با جزئیات بیشتری توضیح داده شده است:

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

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

گزارش های سطح رویداد

پس از اینکه یک ماشه به یک منبع انتساب نسبت داده می شود ، یک گزارش در سطح رویداد تولید می شود و در دستگاه ذخیره می شود تا زمانی که می توان در یکی از ویندوزهای زمان برای ارسال گزارش ها به آدرس اینترنتی هر فناوری تبلیغاتی ارسال شد ، که بعداً در این صفحه با جزئیات بیشتری توضیح داده شده است.

گزارش های سطح رویداد در صورت نیاز به اطلاعات بسیار کمی در مورد ماشه مفید هستند. داده های ماشه سطح رویداد به 3 بیت داده ماشه برای کلیک محدود می شود-این بدان معنی است که می توان یک ماشه را به یکی از هشت دسته و 1 بیت برای بازدید اختصاص داد. علاوه بر این ، گزارش های سطح رویداد از رمزگذاری داده های محرک با وفاداری بالا ، مانند قیمت خاص یا زمان محرک پشتیبانی نمی کنند. از آنجا که انتساب در دستگاه اتفاق می افتد ، در گزارش های سطح رویداد هیچ حمایتی برای تجزیه و تحلیل دستگاه های متقابل وجود ندارد.

گزارش سطح رویداد شامل داده هایی مانند موارد زیر است:

مقصد: نام بسته برنامه تبلیغاتی یا ETLD+1 که در آن ماشه اتفاق افتاده است
شناسه منبع Attribution: همان شناسه منبع انتساب که برای ثبت یک منبع انتساب استفاده شده است
نوع ماشه: بسته به نوع منبع انتساب ، 1 یا 3 بیت از داده های ماشه کم وفاداری

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

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

محدودیت در تعداد تکنیک های تبلیغاتی

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

100 فناوری تبلیغاتی با منابع انتساب در هر برنامه منبع ، برنامه مقصد ، 30 روز ، دستگاه.
10 تکنیک تبلیغاتی با محرک های نسبت داده شده در هر برنامه منبع ، برنامه مقصد ، 30 روز ، دستگاه.
20 فناوری تبلیغی می توانند یک منبع یا ماشه انتساب واحد را ثبت کنند (از طریق Attribution-Reporting-Redirect )

محدودیت در تعداد مقصد های منحصر به فرد

این محدودیت ها برای درک تعداد زیادی از برنامه ها برای درک رفتار استفاده از برنامه کاربر خاص ، مجموعه ای از فناوری های تبلیغاتی را دشوار می کند.

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

منابع منقضی شده به محدودیت نرخ حساب نمی شوند.

یک منشأ گزارش در هر برنامه منبع در روز

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

سناریوی زیر را در نظر بگیرید ، جایی که یک فناوری تبلیغاتی واحد می خواهد برای ثبت منابع در یک برنامه ناشر ، برای یک دستگاه واحد ، از منشاء گزارش دهی چندگانه استفاده کند.

گزارش Ad Tech A's Origin 1 منبع در برنامه B ثبت می کند
12 ساعت بعد ، گزارش گزارش AD Tech A در تلاش برای ثبت منبع در برنامه B

منبع دوم ، برای گزارش گزارش Ad Tech A در Origin 2 ، توسط API رد می شود. گزارش گزارش AD Tech A در Origin 2 قادر به ثبت موفقیت آمیز منبع در همان دستگاه در برنامه B نیست.

Cooldown و محدودیت نرخ

برای محدود کردن میزان نشت هویت کاربر بین یک جفت منبع ، مقصد} ، API میزان کل اطلاعات ارسال شده در یک دوره زمانی معین را برای یک کاربر کاهش می دهد.

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

تعداد مقصد های منحصر به فرد

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

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

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

وفاداری محدود داده های ماشه

API 1 بیت را برای محرک های نمایش و 3 بیت برای محرک های کلیک از طریق آن فراهم می کند. منابع انتساب به پشتیبانی از 64 بیت کامل ابرداده ادامه می دهند.

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

چارچوب سر و صدای حریم خصوصی دیفرانسیل

هدف از این API اجازه می دهد تا اندازه گیری سطح رویداد با استفاده از پاسخ های k-randomized برای تولید یک خروجی پر سر و صدا برای هر رویداد منبع ، الزامات حریم خصوصی دیفرانسیل محلی را برآورده سازد.

سر و صدا در مورد اینکه آیا یک رویداد منبع انتساب به حقیقت گزارش شده است ، اعمال می شود. یک منبع انتساب در دستگاه با احتمال 1-p $ ثبت شده است که منبع انتساب به صورت عادی ثبت شده است ، و با احتمال $ P $ که دستگاه به طور تصادفی در بین تمام حالت های خروجی احتمالی API انتخاب می کند (از جمله گزارش دادن به هیچ وجه ، یا گزارش چندین گزارش جعلی).

پاسخ k-randomized الگوریتمی است که در صورت رضایت از معادله زیر ، اپسیلون متفاوت است:

\[ p = \frac{k}{k + e^ε - 1} \]

برای مقادیر کم ε ، خروجی واقعی توسط مکانیسم پاسخ k-randomized محافظت می شود. پارامترهای دقیق نویز در حال انجام است و بر اساس بازخورد در معرض تغییر قرار می گیرد ، با یک پیشنهاد فعلی از موارد زیر:

P = 0.24 ٪ برای منابع ناوبری
P = 0.00025 ٪ برای منابع رویداد

محدودیت در محرک های موجود (تبدیل)

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

1-2 محرک برای منابع انتساب نمای تبلیغ (2 محرک فقط در مورد انتساب پس از نصب در دسترس است)
3 محرک برای منابع انتساب AD کلیک کنید

ویندوزهای زمان خاص برای ارسال گزارش ها (رفتار پیش فرض)

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

گزارش های سطح رویداد برای منابع انتساب کلیک آگهی قابل پیکربندی نیست و قبل یا هنگام انقضا منبع ارسال می شود ، در نقاط مشخص شده در زمان نسبت به زمان ثبت منبع. زمان بین منبع انتساب و انقضا به پنجره های گزارش دهی چندگانه تقسیم می شود. هر پنجره گزارش دهی مهلت دارد (از زمان منبع انتساب). در پایان هر پنجره گزارش ، دستگاه تمام محرک هایی را که از پنجره گزارش قبلی رخ داده است جمع می کند و گزارش برنامه ریزی شده را ارسال می کند. API از ویندوزهای گزارش زیر پشتیبانی می کند:

2 روز: دستگاه تمام محرک هایی را که حداکثر 2 روز پس از ثبت منبع انتساب رخ داده است ، جمع می کند. این گزارش 2 روز و 1 ساعت پس از ثبت منبع انتساب ارسال می شود.
7 روز: دستگاه تمام محرک هایی را که بیش از 2 روز رخ داده است جمع می کند اما بیش از 7 روز پس از ثبت منبع انتساب نیست. این گزارش 7 روز و 1 ساعت پس از ثبت منبع انتساب ارسال می شود.
مدت زمان سفارشی ، تعریف شده توسط ویژگی "انقضا" یک منبع انتساب. این گزارش 1 ساعت پس از زمان انقضا مشخص شده ارسال می شود. این مقدار نمی تواند کمتر از 1 روز یا بیشتر از 30 روز باشد.

پیکربندی سطح رویداد انعطاف پذیر

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

این انعطاف پذیری اضافی در دو مرحله به API گزارش انتساب معرفی می شود:

فاز 1: پیکربندی سطح رویداد انعطاف پذیر Lite
- این نسخه زیر مجموعه ای از ویژگی های کامل را ارائه می دهد و می تواند به طور مستقل از فاز 2 استفاده شود.
فاز 2: نسخه کامل پیکربندی سطح رویداد انعطاف پذیر

فاز 1 (سطح رویداد انعطاف پذیر Lite) می تواند مورد استفاده قرار گیرد:

با مشخص کردن تعداد ویندوزهای گزارش دهنده ، فرکانس گزارش ها را تغییر دهید
تعداد ویژگی های ثبت نام منبع را تغییر دهید
با کاهش پارامترهای فوق ، میزان سر و صدای کل را کاهش دهید
به جای استفاده از پیش فرض ، ویندوز گزارش را پیکربندی کنید

فاز 2 (سطح رویداد انعطاف پذیر کامل) می تواند برای انجام تمام قابلیت های موجود در فاز 1 و:

در یک گزارش ، کاردینال بودن داده های ماشه را تغییر دهید
با کاهش کاردینال بودن داده های ماشه ، میزان سر و صدای کل را کاهش دهید

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

علاوه بر تنظیم پویا سطح نویز بر اساس پیکربندی انتخاب شده یک فناوری تبلیغاتی ، ما برای جلوگیری از هزینه های محاسبات بزرگ و تنظیمات با حالت های خروجی بیش از حد ، محدودیت های پارامتر خواهیم داشت (جایی که نویز به میزان قابل توجهی افزایش می یابد). در اینجا نمونه ای از محدودیت ها آورده شده است. بازخورد در مورد [پیشنهاد طراحی] [50] تشویق می شود:

حداکثر 20 گزارش کل ، در سطح جهان و در هر ماشه_داتا
حداکثر 5 ویندوز گزارش ممکن در هر Trigger_Data
حداکثر 32 کاردینال بودن داده های ماشه (برای مرحله 1 قابل اجرا نیست: سطح رویداد انعطاف پذیر Lite)

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

گزارش های قابل جمع شدن

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

گزارش های قابل جمع شدن داده های محرک وفاداری بالاتری را از دستگاه سریعتر ارائه می دهند ، فراتر از آنچه برای گزارش های سطح رویداد ارائه می شود. این داده های وفاداری بالاتر فقط می توانند در کل آموخته شوند و با یک ماشه یا کاربر خاص همراه نیست. کلیدهای تجمیع تا 128 بیت هستند و این به گزارش های قابل جمع شدن اجازه می دهد تا از موارد استفاده از گزارش مانند موارد زیر پشتیبانی کنند:

گزارش برای مقادیر ماشه مانند درآمد
رسیدگی به انواع ماشه بیشتر

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

طراحی کلی نحوه تهیه API گزارش انتساب ، گزارش های قابل جمع ، که در نمودار نشان داده شده است ، به شرح زیر است:

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

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

گزارش های قابل جمع حاوی داده های زیر مربوط به منابع انتساب است:

مقصد: نام بسته برنامه یا URL ETLD+1 Web که در آن ماشه اتفاق افتاده است.
تاریخ: تاریخی که رویداد نمایش داده شده توسط منبع انتساب رخ داده است.
Payload: مقادیر ماشه ، جمع آوری شده به عنوان جفت کلید/ارزش رمزگذاری شده ، که در سرویس جمع آوری قابل اعتماد برای محاسبه تجمع استفاده می شود.

خدمات تجمیع

خدمات زیر قابلیت جمع آوری داده ها و محافظت در برابر دسترسی غیرمجاز به داده های جمع شده را ارائه می دهد ..

این خدمات توسط احزاب مختلف اداره می شوند ، که بعداً در این صفحه با جزئیات بیشتری توضیح داده می شوند:

سرویس جمع آوری تنها شخصی است که انتظار می رود فناوری های تبلیغاتی مستقر شوند.
خدمات حسابداری مدیریت کلیدی و گزارش قابل جمع توسط احزاب قابل اعتماد به نام هماهنگ کننده ها اداره می شود. این هماهنگ کنندگان گواهی می دهند که کدی که سرویس جمع آوری را اداره می کند ، کد در دسترس عموم است که توسط Google ارائه شده است و کلیه کاربران خدمات جمع آوری دارای همان خدمات حسابداری گزارش کلید و قابل جمع هستند که برای آنها اعمال می شود.

سرویس تجمیع

سیستم عامل های AD Tech از قبل باید یک سرویس جمع آوری را که مبتنی بر باینری های ارائه شده توسط Google است ، مستقر کنند.

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

این تضمین می کند که کد کار در TEE باینری خاصی است که توسط Google ارائه می شود. مگر در مواردی که این شرط برآورده نشود ، سرویس جمع آوری نمی تواند به کلیدهای رمزگشایی مورد نیاز برای کار کردن دسترسی پیدا کند.
این امنیت را در مورد فرآیند در حال اجرا ارائه می دهد و آن را از نظارت خارجی یا دستکاری جدا می کند.

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

برای کسب اطلاعات بیشتر در مورد طراحی ، گردش کار و ملاحظات امنیتی سرویس جمع آوری ، به سند خدمات جمع آوری در GitHub مراجعه کنید.

سرویس مدیریت کلیدی

این سرویس تأیید می کند که یک سرویس جمع آوری نسخه تأیید شده باینری را اجرا می کند و سپس خدمات جمع آوری را در فناوری تبلیغی با کلیدهای رمزگشایی صحیح برای داده های ماشه خود ارائه می دهد.

حسابداری گزارش قابل جمع شدن

این سرویس چند بار سرویس جمع آوری یک فناوری تبلیغاتی را به یک ماشه خاص دسترسی می دهد - که می تواند حاوی کلیدهای جمع آوری باشد - و دسترسی به تعداد مناسب رمزگشایی را محدود می کند. برای جزئیات بیشتر به پیشنهاد ارائه پیشنهاد API API Attribution مراجعه کنید.

گزارش های قابل جمع API

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

داده های منبع قابل جمع را ثبت کنید

هنگامی که API درخواستی را به منبع انتساب URI ارائه می دهد ، AD Tech می تواند با پاسخ دادن به یک زمینه جدید به نام Agregation_Keys در HTTP Attribution-Reporting-Register-Source ، با کلید aggregation_keys در HTTP ، با کلید به عنوان key_name و مقدار به عنوان key_piece : لیستی از کلیدهای جمع آوری شده با نام histogram_contributions ثبت کند.

(کلید) نام کلید: رشته ای برای نام کلید. به عنوان یک کلید پیوست برای ترکیب با کلیدهای سمت ماشه برای تشکیل کلید نهایی استفاده می شود.
(مقدار) قطعه کلید: یک مقدار بیتستر برای کلید.

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

کلیدهای نهایی به حداکثر 128 بیت محدود می شوند. کلیدهای طولانی تر از این کوتاه شده اند. این بدان معنی است که رشته های هگز در JSON باید حداکثر 32 رقم محدود شوند.

در مورد نحوه ساخت کلیدهای جمع آوری و چگونگی پیکربندی کلیدهای جمع آوری بیشتر بدانید .

در مثال زیر ، یک فناوری تبلیغی از API برای جمع آوری موارد زیر استفاده می کند:

تبدیل کل در سطح کمپین شمارش می شود
مقادیر خرید کل در سطح GEO

// This is where the Attribution-Reporting-Register-Source object appears when
// an ad tech registers an attribution source.

// Attribution source metadata specifying histogram contributions in aggregate report.
Attribution-Reporting-Register-Source:
…
aggregation_keys: {
  // Generates a "0x159" key piece named (low order bits of the key) for the key
  // named "campaignCounts".
  // User saw an ad from campaign 345 (out of 511).

  "campaignCounts": "0x159",
  // Generates a "0x5" key piece (low order bits of the key) for the key name "geoValue"
  // Source-side geo region = 5 (US), out of a possible ~100 regions.
  "geoValue": "0x5"
}

ماشه قابل جمع را ثبت کنید

ثبت نام ماشه شامل دو قسمت اضافی است.

قسمت اول برای ثبت لیستی از کلیدهای کل در سمت ماشه استفاده می شود. فناوری تبلیغی باید با قسمت aggregatable_trigger_data در HTTP Attribution-Reporting-Register-Trigger پاسخ دهد ، با زمینه های زیر برای هر کلید کل در لیست:

قطعه کلیدی: یک مقدار بیتستر برای کلید.
کلیدهای منبع: لیستی از رشته ها با نام کلیدهای جانبی منبع Attribution که باید کلید ماشه با آن ترکیب شود تا کلیدهای نهایی را تشکیل دهد.

قسمت دوم برای ثبت لیستی از مقادیر استفاده می شود که باید به هر کلید کمک کند. فناوری AD باید با قسمت aggregatable_values در HTTP Attribution-Reporting-Register-Trigger پاسخ دهد. قسمت دوم برای ثبت لیستی از مقادیر استفاده می شود که باید به هر کلید کمک کند ، که می تواند عدد صحیح در محدوده $ [1 ، 2^{16}] $ باشد.

هر ماشه می تواند چندین سهم در گزارش های قابل جمع شدن داشته باشد. مقدار کل مشارکت در هر رویداد منبع معین توسط یک پارامتر L1 $ $ محدود می شود ، که حداکثر مجموع سهم (مقادیر) در تمام کلیدهای کل برای یک منبع معین است. $ L1 $ به حساسیت L1 یا هنجار کمک های هیستوگرام در هر رویداد منبع اشاره دارد. فراتر از این محدودیت ها باعث می شود کمک های آینده به سکوت بیفتد. پیشنهاد اولیه تنظیم L1 $ $ 2 $ {16} $ (65536) است.

نویز در سرویس جمع آوری متناسب با این پارامتر اندازه گیری می شود. با توجه به این ، توصیه می شود مقادیر گزارش شده برای یک کلید کل را به طور مناسب ، بر اساس بخشی از بودجه L1 $ $ اختصاص داده شده به آن ، به طور مناسب مقیاس کنید. این رویکرد به اطمینان حاصل می شود که گزارش های کل در هنگام استفاده از سر و صدا بالاترین وفاداری ممکن را حفظ می کنند. این مکانیسم بسیار انعطاف پذیر است و می تواند بسیاری از استراتژی های جمع آوری را پشتیبانی کند.

در مثال زیر ، بودجه حریم خصوصی با تقسیم سهم L1 $ $ در هر یک به طور مساوی بین campaignCounts و geoValue تقسیم می شود:

// This is where the Attribution-Reporting-Register-Trigger object appears
// when an ad tech registers a conversion trigger.

// Specify a list of dictionaries that generates aggregation keys.
Attribution-Reporting-Register-Trigger:{
    …
    "aggregatable_trigger_data":

    [
    // Each dictionary independently adds pieces to multiple source keys.
    {
    // Conversion type purchase = 2 at a 9-bit offset, i.e. 2 << 9.
    // A 9-bit offset is needed because there are 511 possible campaigns, which
    // will take up 9 bits in the resulting key.
        "key_piece": "0x400",// Conversion type purchase = 2
        // Apply this key piece to:
        "source_keys": ["campaignCounts"]
    },
    {
    // Purchase category shirts = 21 at a 7-bit offset, i.e. 21 << 7.
    // A 7-bit offset is needed because there are ~100 regions for the geo key,
    // which will take up 7 bits of space in the resulting key.
        "key_piece": "0xA80",
        // Apply this key piece to:
        "source_keys": ["geoValue", "nonMatchingIdsListedHereAreIgnored"]
    }
    ]

    // Specify an amount of an abstract value which can be integers in [1, 2^16] to
    // contribute to each key that is attached to aggregation keys in the order that
    // they're generated.
    aggregatable_values:
    {
    // Privacy budget for each key is L1 / 2 = 2^15 (32768).
    // Conversion count was 1.
    // Scale the count to use the full budget allocated: 1 * 32768 = 32768.
        "campaignCounts": 32768,

    // Purchase price was $52.
    // Purchase values for the app range from $1 to $1,024 (integers only).
    // Scaling factor applied is 32768 / 1024 = 32.
    // For $52 purchase, scale the value by 32 ($52 * 32 = $1,664).
        "geoValue": 1664
    }
}

مثال قبلی سهم هیستوگرام زیر را ایجاد می کند:

[
  // campaignCounts:
  {
    "key": "0x559", // = 0x159 | 0x400
    "value": 32768
  },
  // geoValue:
  {
    "key": "0xA85",  // = 0x5 | 0xA80
    "value": 1664
  }
]

برای به دست آوردن مقادیر صحیح ، سر و صدای ماژول که اعمال می شود ، می توان فاکتورهای مقیاس گذاری را معکوس کرد:

L1 = 65536
trueCampaignCounts = campaignCounts / (L1 / 2)
trueGeoValue = geoValue / (L1 / 2) * 1024

حریم خصوصی متفاوت

هدف از این API داشتن چارچوبی است که می تواند از اندازه گیری کل خصوصی متفاوت پشتیبانی کند. این می تواند با افزودن سر و صدای متناسب با بودجه L1 $ ، مانند انتخاب نویز با توزیع زیر حاصل شود:

\[ Laplace(\frac{L1}{ε}) \]

API مخاطبان محافظت شده و انتساب گزارش API

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

از طریق این ادغام متقابل API ، AdTechs می تواند:

یک نقشه با ارزش کلیدی از URIS ایجاد کنید تا برای هر دو) گزارش تعامل و 2) ثبت منبع استفاده شود.
شامل CustomAudience در نقشه برداری کلید سمت منبع خود برای گزارش خلاصه کل (با استفاده از API گزارش انتساب).

وقتی کاربر روی یک تبلیغ می بیند یا کلیک می کند:

URL مورد استفاده برای گزارش آن تعامل با استفاده از مخاطبان محافظت شده نیز برای ثبت یک نمای یا کلیک به عنوان منبع واجد شرایط با API گزارش انتساب استفاده می شود.
AD Tech ممکن است با استفاده از آن URL ، تصویب CustomAudience (یا سایر اطلاعات متنی مربوطه در مورد تبلیغ مانند قرار دادن تبلیغ یا مدت زمان مشاهده) را انتخاب کند تا این ابرداده بتواند هنگام بررسی عملکرد کمپین ، به گزارش های خلاصه انتشار دهد.

برای کسب اطلاعات بیشتر در مورد چگونگی فعال کردن این در مخاطبان محافظت شده ، به بخش مربوط به توضیح دهنده API مخاطبان محافظت شده مراجعه کنید.

اولویت ، انتساب و نمونه های گزارش ثبت نام

این مثال مجموعه ای از تعامل کاربر را به نمایش می گذارد و اینکه چگونه منبع انتسابی تعریف شده و اولویت های تحریک شده می تواند بر گزارش های انتساب تأثیر بگذارد. در این مثال موارد زیر را فرض می کنیم:

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

موردی را در نظر بگیرید که کاربر موارد زیر را انجام دهد:

کاربر یک تبلیغ را می بیند. AD Tech یک منبع انتساب با API ، با اولویت 0 (مشاهده شماره 1) ثبت می کند.
کاربر یک تبلیغ را می بیند ، که با اولویت 0 ثبت شده است (مشاهده شماره 2).
کاربر روی یک تبلیغ کلیک می کند ، با اولویت 1 ثبت شده است (روی شماره 1 کلیک کنید).
کاربر در یک برنامه تبلیغاتی (به صفحه فرود می رسد) تبدیل می کند. AD Tech با اولویت 0 (تبدیل شماره 1) یک ماشه را با API ثبت می کند.
- با ثبت محرک ها ، API ابتدا قبل از تولید گزارش ، انتساب را انجام می دهد.
- 3 منبع انتساب در دسترس است: مشاهده شماره 1 ، مشاهده شماره 2 ، و روی شماره 1 کلیک کنید. API این ماشه را برای کلیک روی شماره 1 نسبت می دهد زیرا این بالاترین اولویت و جدیدترین است.
- مشاهده شماره 1 و مشاهده شماره 2 دور ریخته شده و دیگر واجد شرایط انتساب آینده نیستند.
کاربر در برنامه تبلیغات ، یک مورد را به سبد خرید خود اضافه می کند ، با اولویت 1 (تبدیل شماره 2) ثبت شده است.
- کلیک شماره 1 تنها منبع واجد شرایط واجد شرایط است. API این ماشه را برای کلیک روی شماره 1 ویژگی می کند.
کاربر در برنامه تبلیغاتی ، موردی را به سبد خرید خود اضافه می کند ، که با اولویت 1 (تبدیل شماره 3) ثبت شده است.
- کلیک شماره 1 تنها منبع واجد شرایط واجد شرایط است. API این ماشه را برای کلیک روی شماره 1 ویژگی می کند.
کاربر در برنامه تبلیغات ، یک مورد را به سبد خرید خود اضافه می کند ، با اولویت 1 (تبدیل شماره 4) ثبت شده است.
- کلیک شماره 1 تنها منبع واجد شرایط واجد شرایط است. API این ماشه را برای کلیک روی شماره 1 ویژگی می کند.
کاربر در برنامه تبلیغاتی که با اولویت 2 (تبدیل شماره 5) ثبت شده است ، خرید می کند.
- کلیک شماره 1 تنها منبع واجد شرایط واجد شرایط است. API این ماشه را برای کلیک روی شماره 1 ویژگی می کند.

گزارش های سطح رویداد ویژگی های زیر را دارند:

به طور پیش فرض ، 3 محرک اول منتسب به یک کلیک و اولین ماشه منتسب به یک نمای پس از ویندوزهای گزارشگر قابل استفاده ارسال می شوند.
در پنجره گزارش ، اگر محرک هایی با اولویت بالاتر ثبت شوند ، این موارد مقدم هستند و جدیدترین ماشه را جایگزین می کنند.
در مثال قبلی ، AD Tech 3 گزارش رویداد را پس از پنجره گزارش 2 روزه ، برای تبدیل شماره 2 ، تبدیل شماره 3 و تبدیل شماره 5 دریافت می کند.
- تمام 5 محرک به کلیک شماره 1 نسبت داده می شوند. به طور پیش فرض ، API گزارش هایی را برای 3 محرک اول ارسال می کند: تبدیل شماره 1 ، تبدیل شماره 2 و تبدیل شماره 3.
- با این حال ، اولویت تبدیل شماره 4 ( 1 ) بالاتر از اولویت تبدیل شماره 1 ( 0 ) است. گزارش رویداد شماره 4 جایگزین گزارش رویداد تبدیل شماره 1 برای ارسال شده است.
- علاوه بر این ، اولویت تبدیل شماره 5 ( 2 ) از هر محرک دیگری بالاتر است. گزارش رویداد شماره 5 جایگزین گزارش تبدیل شماره 4 برای ارسال شده است.

گزارش های قابل جمع ویژگی های زیر را دارند:

گزارش های قابل استفاده رمزگذاری شده به محض پردازش ، چند ساعت پس از ثبت نام ، به فناوری تبلیغاتی ارسال می شوند.
به عنوان یک فناوری تبلیغاتی ، شما دسته های آنها را بر اساس اطلاعاتی که در گزارش های قابل قبول شما رمزگذاری نشده است ، ایجاد می کنید. این اطلاعات در گزارش مشترک شما در قسمت shared_info موجود است و شامل زمان بندی و منشأ گزارش است. شما نمی توانید بر اساس هرگونه اطلاعات رمزگذاری شده در جفت های ارزش کلیدی خود ، دسته ای را دسته بندی کنید. برخی از استراتژی های ساده ای که می توانید دنبال کنید گزارش های روزانه یا هفتگی است. در حالت ایده آل ، دسته ها باید حداقل 100 گزارش داشته باشند.
این به فناوری تبلیغاتی در مورد زمان و چگونگی دسته بندی گزارش های قابل جمع شدن و ارسال به سرویس جمع آوری بستگی دارد.
در مقایسه با گزارش های سطح رویداد ، گزارش های قابل استفاده رمزگذاری شده می توانند محرک های بیشتری را به یک منبع نسبت دهند.
در مثال قبلی ، 5 گزارش قابل جمع شدن ارسال می شود ، یکی برای هر ماشه ثبت شده.

گزارش های اشکال زدایی انتقالی

API گزارش دهنده انتساب روشی جدید و نسبتاً پیچیده برای انجام اندازه گیری انتساب بدون شناسه های متقاطع است. به همین ترتیب ، ما از یک مکانیسم انتقالی برای کسب اطلاعات بیشتر در مورد گزارش های انتساب در هنگام موجود بودن شناسه تبلیغاتی پشتیبانی می کنیم (کاربر با استفاده از شناسه تبلیغاتی از شخصی سازی خودداری نکرده است و ناشر یا برنامه تبلیغ کننده مجوزهای ADID را اعلام کرده است) . این امر تضمین می کند که API را می توان به طور کامل در حین بازپرداخت درک کرد ، به بیرون کشیدن هرگونه اشکال کمک کرد و راحت تر عملکرد را با گزینه های مبتنی بر شناسه تبلیغاتی مقایسه کرد. دو نوع گزارش اشکال زدایی وجود دارد: انتساب-موفقیت و کلامی.

برای جزئیات بیشتر در مورد گزارش های اشکال زدایی با اندازه گیری برنامه به WEB و وب به برنامه ، راهنمای گزارش های اشکال زدایی انتقالی را بخوانید.

گزارش های اشکال زدایی انتزاعی

ثبت نام های منبع و ماشه هر دو یک قسمت جدید 64 بیتی debug_key (فرمت به عنوان یک رشته) را می پذیرند ، که فناوری تبلیغی جمع می شود. source_debug_key و trigger_debug_key در گزارش های سطح رویداد و کل بدون تغییر منتقل می شوند.

اگر گزارشی با کلیدهای اشکال زدایی منبع و ماشه ایجاد شود ، یک گزارش اشکال زدایی تکراری با تأخیر محدود به یک نقطه پایانی .well-known/attribution-reporting/debug/report-event-attribution ارسال می شود. گزارش های اشکال زدایی با گزارش های عادی یکسان است ، از جمله هر دو زمینه کلید اشکال زدایی. از جمله این کلیدها در هر دو اجازه می دهد تا گزارش های عادی را به جریان جداگانه گزارش های اشکال زدایی متصل کند.

برای گزارش های سطح رویداد:
- گزارش های اشکال زدایی تکراری با تأخیر محدود ارسال می شوند و بنابراین با محدودیت های مربوط به محرک های موجود سرکوب نمی شوند ، که به AD Tech اجازه می دهد تا تأثیر آن محدودیت ها را برای گزارش های سطح رویداد درک کند.
- گزارش های سطح رویداد مرتبط با وقایع ماشه کاذب ، trigger_debug_key را ندارند. این به فناوری تبلیغی اجازه می دهد تا با دقت بیشتری درک کند که چگونه سر و صدا در API اعمال می شود.
برای گزارش های قابل جمع شدن:
- ما از یک قسمت جدید debug_cleartext_payload پشتیبانی خواهیم کرد که حاوی بار رمزگشایی شده است ، تنها در صورت تنظیم هر دو source_debug_key و trigger_debug_key .

گزارش های اشکال زدایی کلامی

هر گزارش Verbose شامل زمینه های زیر است:

نوع : چه چیزی باعث شده گزارش تولید شود. لیست کامل انواع گزارش های Verbose را مشاهده کنید.
- به طور کلی ، گزارش های Verbose منبع و گزارش های Verbose وجود دارد.
- گزارش های Verbose منبع نیاز به شناسه تبلیغاتی در دسترس برنامه ناشر دارد و گزارش های Verbose Trrigger نیاز به شناسه تبلیغات در دسترس برنامه تبلیغات دارد.
- گزارش های Verbose Trigger (به استثنای trigger-no-matching-source ) می تواند به صورت اختیاری شامل source_debug_key باشد. این تنها در صورتی که شناسه تبلیغاتی نیز در دسترس برنامه ناشر باشد ، درج می شود.
بدن : بدن گزارش ، که به نوع آن بستگی دارد.

گزارش های Verbose منبع فقط نیاز به انتخاب در هدر ثبت نام منبع دارد.
گزارش های اشکال زدایی Trigger فقط در هدر ثبت نام ماشه نیاز به انتخاب دارد.

نحوه استفاده از گزارش های اشکال زدایی

هنگامی که هیچ تطبیقی وجود ندارد ، به دلایل مختلف می تواند باشد.

همانطور که در نظر گرفته شده است:

رفتارهای API حفظ حریم خصوصی:
- یک کاربر به حد نرخ گزارش رسید - ایجاد تمام گزارش های بعدی برای ارسال در دوره زمانی. یا منبع به دلیل محدودیت مقصد در انتظار حذف می شود.
- برای گزارش های سطح رویداد: گزارش منوط به پاسخ تصادفی (سر و صدا) است و سرکوب می شود ، یا ممکن است گزارش تصادفی دریافت کنید.
- برای گزارش های سطح رویداد: محدودیت سه (برای کلیک) یا یک گزارش (برای بازدید) به دست آمده است ، و گزارش های بعدی هیچ مجموعه اولویت صریح و یا اولویت ای پایین تر از گزارش های موجود ندارند.
- محدودیت سهم برای گزارش های قابل جمع شدن از آن فراتر رفته است.
منطق تجاری تعریف شده توسط فناوری:
- یک ماشه از طریق فیلترها یا قوانین اولویت فیلتر می شود.
تأخیر زمان یا تعامل با در دسترس بودن شبکه (به عنوان مثال ، کاربر برای مدت طولانی دستگاه خود را خاموش می کند).

علل ناخواسته:

مسائل مربوط به اجرای:
- هدر منبع اشتباه است.
- هدر ماشه به اشتباه تنظیم شده است.
- سایر موارد پیکربندی.
مشکلات دستگاه یا شبکه:
- خرابی به دلیل شرایط شبکه.
- پاسخ ثبت نام منبع یا ماشه به مشتری نمی رسد.
- اشکال API

ملاحظات آینده و سوالات باز

علاوه بر این ، ما می خواهیم در مورد چند موضوع به دنبال بازخورد جامعه باشیم:

آیا موارد استفاده ای وجود دارد که دوست دارید API گزارش هایی را برای نصب تأیید شده ارسال کند؟ این گزارش ها در برابر محدودیت های مربوط به سیستم عامل های فناوری تبلیغی حساب می شود.
آیا با عبور از InputEvent از برنامه به AD Tech برای ثبت نام منبع ، مشکلی پیش بینی می کنید؟
آیا موارد استفاده ویژه ای برای برنامه های از پیش بارگذاری شده یا برنامه های نصب مجدد دارید؟