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

bookmark_border با مجموعه‌ها، منظم بمانید ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.

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

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

مسیرها را راه اندازی کنید

همانطور که در پیشنهاد طراحی API Reporting Attribution توضیح داده شد، API انتساب مسیرهای ماشه زیر را در یک دستگاه مجهز به Android امکان پذیر می کند. در اینجا ما وب را به عنوان یکی تعریف می کنیم. (1) یک مرورگر مستقل در حال اجرا بر روی Android (مانند کروم) یا (2) یک WebView در حال اجرا در داخل یک برنامه Android.

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

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

• برای فناوری های تبلیغاتی: به روز رسانی تماس های API و گزارش برای فعال کردن مسیرهای برنامه به وب.
• برای برنامه‌ها و مرورگرها: امکان ارسال ثبت منابع اسناد وب و راه‌اندازهای وب به Android.

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

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

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

پس از نهایی شدن فرآیند ثبت نام، در صورت دریافت تماس ثبت نام نشده، API از ثبت نام صرفنظر می کند.

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

تغییرات برای فناوری های تبلیغاتی

این بخش تغییرات مربوط به فناوری های تبلیغاتی را با استفاده از API گزارش انتساب مورد بحث قرار می دهد.

تغییرات در ثبت و اسناد

هنگام ثبت منبع انتساب ، متخصصان تبلیغات یک فیلد مقصد را مشخص می‌کنند که نام بسته برنامه است که رویداد راه‌اندازی در آن رخ می‌دهد. برای فعال کردن اندازه‌گیری برنامه به وب، قصد داریم از یک قسمت مقصد برنامه (نام بسته برنامه) و یک قسمت مقصد وب (eTLD+1) پشتیبانی کنیم.

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

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

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

Android Attribution Reporting API می‌تواند گزارش‌هایی را برای تبدیل برنامه و وب ارسال کند. اگر فناوری‌های تبلیغاتی نمی‌خواهند داده‌های راه‌انداز و کلید-مقدارهای انباشته را در سطح وب و برنامه‌ها تراز کنند، می‌توانند بین تبدیل وب و تبدیل برنامه تفاوت قائل شوند:

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

مفاهیم اندازه گیری وب به وب

برنامه‌ها انتخاب می‌کنند که چه زمانی ثبت نام را به API گزارش Attribution ارسال کنند. در اینجا چند ملاحظه وجود دارد:

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

مثال زیر نشان می‌دهد که چگونه برنامه‌های مرورگر می‌توانند با API گزارش Attribution کار کنند تا زمانی که کاربر روی تبلیغی در برنامه مرورگر و برنامه غیر مرورگر کلیک می‌کند، اندازه‌گیری دقیقی را ارائه دهد:

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

منبع اسناد و ماشه را از WebView ثبت کنید

در مواردی که برنامه از WebView برای نمایش محتوای وب به جای تبلیغات اندرویدی استفاده می‌کند، برنامه می‌تواند برای پیوستن به لیست مجاز برای registerWebSource() درخواست دهد و مبدأ سطح بالای وب‌سایت را ارائه دهد تا به جای نام بسته برنامه، با منبع انتساب مرتبط شود.

مشابه مرورگرها، WebView از registerWebTrigger() برای ثبت‌های تریگر پشتیبانی می‌کند، که ماشه را با مبدا سطح بالا مرتبط می‌کند. هیچ پشتیبانی برای WebView برای ثبت ماشه برنامه وجود ندارد. اگر مورد استفاده ای برای این کار دارید، تماس بگیرید . برای لیست کامل ترکیبات پشتیبانی شده توسط WebView، به منبع Attribution و ثبت ماشه از WebView مراجعه کنید.

برخلاف مرورگرها، WebView فقط در صورتی از ثبت نام با سیستم عامل در سربرگ Attribution-Reporting-Eligible پشتیبانی می کند که API گزارش Attribution Android در دسترس باشد. اگر API گزارش Attribution Android در دسترس نباشد، WebView سرصفحه Attribution-Reporting-Eligible تنظیم نمی کند و هیچ ثبت نامی انجام نمی شود.

برای ثبت منبع / ماشه انتساب با استفاده از سیستم عامل:

• فن‌آوران تبلیغات باید با استفاده از سرصفحه Attribution-Reporting-Register-OS-Source به ثبت‌های منبع پاسخ دهند، که یک فراخوانی API ثانویه از WebView به registerSource() یا registerWebSource() آغاز می‌کند.
• فناوری‌های تبلیغاتی همچنین می‌توانند با استفاده از هدر Attribution-Reporting-Register-OS-Trigger به ثبت‌های راه‌اندازی پاسخ دهند، که یک فراخوانی API ثانویه از WebView به registerWebTrigger() یا registerTrigger() آغاز می‌کند.

توجه داشته باشید که اگر پاسخ شامل سرصفحه‌های قبلی نباشد، یا شامل سرصفحه‌های Attribution-Reporting-Register-Source / Attribution-Reporting-Register-Trigger باشد، حتی اگر وب پشتیبانی نشود، کل ثبت نام با شکست مواجه خواهد شد.

برای جزئیات در مورد اینکه آیا WebView از registerSource() / registerWebSource() و registerTrigger() / registerWebTrigger() (و همچنین نحوه تغییر این رفتار استفاده می کند) به منبع Attribution و ثبت ماشه از WebView مراجعه کنید.

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

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

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

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

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

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

• کاربر نباید با استفاده از شناسه تبلیغاتی از شخصی سازی انصراف داده باشد
• برنامه ناشر باید مجوزهای AdID را اعلام کرده باشد
• فناوری تبلیغات باید مقدار AdID را در ثبت راه‌اندازی ارسال کند (از یک زمینه وب)

برای فعال کردن گزارش‌های اشکال‌زدایی کامل برای برنامه به وب:

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

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

تغییرات برای برنامه ها

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

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

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

• Attribution-Reporting-Eligible پخش می کند که آیا پشتیبانی در سطح سیستم عامل برای انتساب در دسترس است یا خیر. در این مورد، هدر نشان می‌دهد که آیا API گزارش اسناد Android در دسترس است یا خیر.
• در صورت وجود، فن‌آوران تبلیغات می‌توانند به صورت اختیاری با استفاده از Attribution-Reporting-Register-OS-Source پاسخ دهند، که یک تماس API ثانویه را از برنامه مرورگر برای registerWebSource() آغاز می‌کند.
• فناوری‌های تبلیغاتی همچنین می‌توانند با استفاده از هدر Attribution-Reporting-Register-OS-Trigger به ثبت‌های راه‌انداز پاسخ دهند، که یک تماس API ثانویه از برنامه مرورگر برای registerWebTrigger() آغاز می‌کند.

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

هنگام ثبت منبع انتساب، برنامه‌ها می‌توانند registerWebSource() فراخوانی کنند، که انتظار پارامترهای زیر را دارد:

• URIهای منبع انتساب : پلتفرم درخواستی را برای هر یک از URIهای موجود در این فهرست به منظور واکشی فراداده مرتبط با منبع انتساب صادر می کند.
  
  هر URI باید یک پرچم Boolean Debug را همراهی کند تا مشخص کند آیا کلیدهای اشکال زدایی ارائه شده توسط فناوران باید در گزارش گنجانده شوند یا خیر.
• رویداد ورودی : یا یک شی InputEvent (برای یک رویداد کلیک) یا null (برای یک رویداد مشاهده)
• مبدا منبع : مبدایی که منبع در آن آمده است (وب سایت ناشر).
• مقصد سیستم عامل : نام بسته برنامه که در آن رویداد ماشه اتفاق می افتد.
• مقصد وب : یک eTLD+1 که در آن رویداد ماشه اتفاق می افتد.
• مقصد تأیید شده : سیستم عامل یا هدف URI مقصد وب که برای پیمایش با کلیک کاربر استفاده می‌شود.

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

• API مقاصد مشخص شده توسط فناوری تبلیغات را با مقاصدی که توسط برنامه مشخص شده است تأیید می کند. اگر مقصدها متفاوت باشند، API از ثبت منبع انتساب صرف نظر می کند.
  
  انتظار می رود برنامه ها قبل از فراخوانی API زمینه وب، مقصدهای وب را تأیید کنند. برای کلیک‌ها، برنامه‌ها باید بررسی کنند که مقصد مشخص‌شده با مقصدی که کاربر در حال پیمایش است مطابقت داشته باشد.
• API هر URI تغییر مسیر ارائه شده در Attribution-Reporting-Redirects را نادیده می گیرد. برنامه‌ها باید ریدایرکت‌ها را خودشان دنبال کنند و برای هر ریدایرکت، registerWebSource() فراخوانی کنند تا بتوانند سیاست‌های مجوزهای خود را در صورت نیاز اعمال کنند.

برنامه ها برای فراخوانی registerWebSource() باید به یک لیست مجاز بپیوندند. برای پیوستن به لیست مجاز، این فرم را تکمیل کنید . هدف از لیست مجاز کاهش ملاحظات حفظ حریم خصوصی در مورد ایجاد اعتماد برای زمینه وب است.

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

هنگام ثبت تریگر، برنامه‌ها می‌توانند registerWebTrigger() فراخوانی کنند، که انتظار پارامترهای زیر را دارد:

• URI‌های راه‌انداز : پلتفرم برای هر URI در این فهرست درخواستی صادر می‌کند تا متادیتا مرتبط با راه‌انداز را واکشی کند.
• مبدا مقصد : مبدایی که راه‌انداز در آن رخ داده است (وب‌سایت تبلیغ‌کننده)

منبع انتساب و شروع ثبت نام از WebView

به طور پیش فرض، WebView از registerSource() و registerWebTrigger() استفاده می کند. این منابع را با برنامه مرتبط می‌کند و هنگامی که راه‌اندازی رخ می‌دهد، با مبدا سطح بالای WebView فعال می‌شود.

اگر برنامه‌ای به رفتارهای متفاوتی نیاز دارد (مانند مواردی که محتوای وب را در WebView میزبانی می‌کنند)، باید از متد setAttributionRegistrationBehavior در کلاس androidx.webkit.WebViewSettingsCompat استفاده کنند. این متد مشخص می‌کند که WebView باید registerWebSource() یا registerSource() و registerWebTrigger() یا registerTrigger() فراخوانی کند.

گزینه های موجود برای setAttributionRegistrationBehavior به شرح زیر است:

ملاحظات حفظ حریم خصوصی و امنیتی

این بخش در مورد ملاحظات حریم خصوصی و امنیتی برای برنامه‌هایی که از API گزارش Attribution استفاده می‌کنند بحث می‌کند.

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

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

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

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

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

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

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

هر برنامه ای می تواند registerWebTrigger() فراخوانی کند زیرا ملاحظات حریم خصوصی و امنیتی در سمت ماشه بدون تبانی سمت منبع قابل اعمال نیستند.

کنترل های کاربر

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

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

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

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

1. در دستگاهی که Android Privacy Sandbox را پشتیبانی می‌کند، چگونه از راه‌حل‌های اندازه‌گیری مرورگر با API گزارش انتساب Android استفاده می‌کنید؟ آیا ترجیح می دهید همه چیز را به اندروید منتقل کنید؟
2. آیا نگرانی در مورد دریافت احتمالی 2 پینگ برای هر منبع و راه‌انداز انتساب، یکی از مرورگر یا برنامه و دیگری از API گزارش Attribution وجود دارد؟
3. چگونه می توانیم به شما کمک کنیم که اشکال زدایی در میان API های مختلف برای شما آسان تر شود؟
4. این پیشنهاد شامل تأییدیه مرتبط بودن مقصدهای برنامه و وب نیست. در آینده، ممکن است بتوانیم این مقاصد را با بررسی ارتباط با استفاده از پیوندهای دارایی دیجیتال تأیید کنیم. آیا این کار هر یک از موارد استفاده شما را مسدود می کند؟ آیا استفاده از پیوندهای دارایی دیجیتال برای انجام این اعتبارسنجی منطقی است؟
5. هنگام ثبت منبع انتساب، باید مقصدی را مشخص کنید. در مورد وب به برنامه، ممکن است بخواهید پیوند برنامه را مشخص کنید. از چه فرمت هایی برای تعیین پیوند این برنامه استفاده می کنید؟
6. هنگام ثبت منبع انتساب برنامه به وب، آن رویداد منبع باید از برنامه با API گزارش Attribution Android ثبت شود. به عنوان مثال، اگر کاربر روی یک تبلیغ کلیک کند و کلیک در یک مرورگر یا برگه سفارشی مرورگر باز شود، آن کلیک (رویداد منبع) باید از برنامه ثبت شود نه در زمینه مرورگر. اگر در این مورد نگرانی دارید، یا موارد استفاده دیگری وجود دارد که در دسته بندی های این شماره که جریان های پشتیبانی شده را توصیف می کنند، قرار نمی گیرند، تماس بگیرید.

{% کلمه به کلمه %}

برای شما توصیه می شود

• توجه: وقتی جاوا اسکریپت خاموش است، متن پیوند نمایش داده می شود
• گزارش اسناد
• راهنمای توسعه‌دهنده API Reporting Attribution
• یادداشت های انتشار

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

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

مسیرها را راه اندازی کنید

همانطور که در پیشنهاد طراحی API Reporting Attribution توضیح داده شد، API انتساب مسیرهای ماشه زیر را در یک دستگاه مجهز به Android امکان پذیر می کند. در اینجا ما وب را به عنوان یکی تعریف می کنیم. (1) یک مرورگر مستقل در حال اجرا بر روی Android (مانند کروم) یا (2) یک WebView در حال اجرا در داخل یک برنامه Android.

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

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

• برای فناوری های تبلیغاتی: به روز رسانی تماس های API و گزارش برای فعال کردن مسیرهای برنامه به وب.
• برای برنامه‌ها و مرورگرها: امکان ارسال ثبت منابع اسناد وب و راه‌اندازهای وب به Android.

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

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

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

پس از نهایی شدن فرآیند ثبت نام، در صورت دریافت تماس ثبت نام نشده، API از ثبت نام صرفنظر می کند.

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

تغییرات برای فناوری های تبلیغاتی

این بخش تغییرات مربوط به فناوری های تبلیغاتی را با استفاده از API گزارش انتساب مورد بحث قرار می دهد.

تغییرات در ثبت و اسناد

هنگام ثبت منبع انتساب ، متخصصان تبلیغات یک فیلد مقصد را مشخص می‌کنند که نام بسته برنامه است که رویداد راه‌اندازی در آن رخ می‌دهد. برای فعال کردن اندازه‌گیری برنامه به وب، قصد داریم از یک قسمت مقصد برنامه (نام بسته برنامه) و یک قسمت مقصد وب (eTLD+1) پشتیبانی کنیم.

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

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

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

Android Attribution Reporting API می‌تواند گزارش‌هایی را برای تبدیل برنامه و وب ارسال کند. اگر فناوری‌های تبلیغاتی نمی‌خواهند داده‌های راه‌انداز و کلید-مقدارهای انباشته را در سطح وب و برنامه‌ها تراز کنند، می‌توانند بین تبدیل وب و تبدیل برنامه تفاوت قائل شوند:

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

مفاهیم اندازه گیری وب به وب

برنامه‌ها انتخاب می‌کنند که چه زمانی ثبت نام را به API گزارش Attribution ارسال کنند. در اینجا چند ملاحظه وجود دارد:

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

مثال زیر نشان می‌دهد که چگونه برنامه‌های مرورگر می‌توانند با API گزارش Attribution کار کنند تا زمانی که کاربر روی تبلیغی در برنامه مرورگر و برنامه غیر مرورگر کلیک می‌کند، اندازه‌گیری دقیقی را ارائه دهد:

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

منبع اسناد و ماشه را از WebView ثبت کنید

در مواردی که برنامه از WebView برای نمایش محتوای وب به جای تبلیغات اندرویدی استفاده می‌کند، برنامه می‌تواند برای پیوستن به لیست مجاز برای registerWebSource() درخواست دهد و مبدأ سطح بالای وب‌سایت را ارائه دهد تا به جای نام بسته برنامه، با منبع انتساب مرتبط شود.

مشابه مرورگرها، WebView از registerWebTrigger() برای ثبت‌های تریگر پشتیبانی می‌کند، که ماشه را با مبدا سطح بالا مرتبط می‌کند. هیچ پشتیبانی برای WebView برای ثبت ماشه برنامه وجود ندارد. اگر مورد استفاده ای برای این کار دارید، تماس بگیرید . برای لیست کامل ترکیبات پشتیبانی شده توسط WebView، به منبع Attribution و ثبت ماشه از WebView مراجعه کنید.

برخلاف مرورگرها، WebView فقط در صورتی از ثبت نام با سیستم عامل در سربرگ Attribution-Reporting-Eligible پشتیبانی می کند که API گزارش Attribution Android در دسترس باشد. اگر API گزارش Attribution Android در دسترس نباشد، WebView سرصفحه Attribution-Reporting-Eligible تنظیم نمی کند و هیچ ثبت نامی انجام نمی شود.

برای ثبت منبع / ماشه انتساب با استفاده از سیستم عامل:

• فن‌آوران تبلیغات باید با استفاده از سرصفحه Attribution-Reporting-Register-OS-Source به ثبت‌های منبع پاسخ دهند، که یک فراخوانی API ثانویه از WebView به registerSource() یا registerWebSource() آغاز می‌کند.
• فناوری‌های تبلیغاتی همچنین می‌توانند با استفاده از هدر Attribution-Reporting-Register-OS-Trigger به ثبت‌های راه‌اندازی پاسخ دهند، که یک فراخوانی API ثانویه از WebView به registerWebTrigger() یا registerTrigger() آغاز می‌کند.

توجه داشته باشید که اگر پاسخ شامل سرصفحه‌های قبلی نباشد، یا شامل سرصفحه‌های Attribution-Reporting-Register-Source / Attribution-Reporting-Register-Trigger باشد، حتی اگر وب پشتیبانی نشود، کل ثبت نام با شکست مواجه خواهد شد.

برای جزئیات در مورد اینکه آیا WebView از registerSource() / registerWebSource() و registerTrigger() / registerWebTrigger() (و همچنین نحوه تغییر این رفتار استفاده می کند) به منبع Attribution و ثبت ماشه از WebView مراجعه کنید.

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

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

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

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

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

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

• کاربر نباید با استفاده از شناسه تبلیغاتی از شخصی سازی انصراف داده باشد
• برنامه ناشر باید مجوزهای AdID را اعلام کرده باشد
• فناوری تبلیغات باید مقدار AdID را در ثبت راه‌اندازی ارسال کند (از یک زمینه وب)

برای فعال کردن گزارش‌های اشکال‌زدایی کامل برای برنامه به وب:

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

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

تغییرات برای برنامه ها

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

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

برای نمونه ای از چگونگی ادغام مرورگرها با API گزارش انتساب Android ، برای فعال کردن برنامه Cross و اندازه گیری وب ، به Sandbox Privacy Sandbox برای پیشنهاد وب مراجعه کنید. در این پیشنهاد ، مرورگر عنوان های درخواست زیر را اضافه می کند:

• برنامه های Attribution-Reporting-Eligible آیا پشتیبانی از سطح سیستم عامل از انتساب در دسترس است یا خیر. در این حالت ، هدر نشان می دهد که آیا API گزارش انتساب Android در دسترس است یا خیر.
• در صورت وجود ، فناوری های تبلیغاتی می توانند به صورت اختیاری با استفاده از Attribution-Reporting-Register-OS-Source پاسخ دهند ، که یک تماس API ثانویه را از برنامه مرورگر برای registerWebSource() .
• فناوری های تبلیغاتی همچنین می توانند با استفاده از عنوان Attribution-Reporting-Register-OS-Trigger ، به ثبت نام های ماشه پاسخ دهند ، که یک تماس API ثانویه از برنامه مرورگر برای registerWebTrigger() آغاز می کند.

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

هنگام ثبت یک منبع انتساب ، برنامه ها می توانند با registerWebSource() تماس بگیرند ، که انتظار پارامترهای زیر را دارد:

• منبع Attribution URIS : این پلتفرم به منظور واکشی ابرداده های مرتبط با منبع انتساب ، درخواست هر URI را در این لیست صادر می کند.
  
  هر URI باید یک پرچم اشکال زدایی بولی را همراهی کند تا نشان دهد آیا کلیدهای اشکال زدایی ارائه شده توسط تکنیک ها باید در گزارش گنجانده شوند.
• رویداد ورودی : یا یک شیء InputEvent (برای یک رویداد کلیک) یا null (برای یک رویداد مشاهده)
• مبدا منبع : منشأی که ​​منبع در آن رخ داده است (وب سایت ناشر).
• مقصد سیستم عامل : نام بسته برنامه ای که در آن رویداد ماشه اتفاق می افتد.
• مقصد وب : ETLD+1 که در آن رویداد ماشه اتفاق می افتد.
• مقصد تأیید شده : OS یا مقصد وب URI قصد استفاده شده برای پیمایش بر روی کلیک کاربر است.

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

• API مقصد مشخص شده توسط فناوری تبلیغ را با مقصد مشخص شده توسط برنامه تأیید می کند. اگر مقصد متفاوت باشد ، API ثبت نام منبع انتساب را کنار می گذارد.
  
  انتظار می رود برنامه ها قبل از فراخوانی API زمینه وب ، مقصد وب را تأیید کنند. برای کلیک ، برنامه ها باید بررسی کنند که مقصد مشخص شده با مقصدی که کاربر در آن حرکت می کند مطابقت دارد.
• API هرگونه URI های تغییر مسیر ارائه شده در Attribution-Reporting-Redirects را نادیده می گیرد. برنامه ها باید به تنهایی از تغییر مسیر پیروی کنند و برای هر تغییر مسیر registerWebSource() تماس بگیرند تا بتوانند در صورت لزوم سیاست های مجوز خود را اعمال کنند.

برنامه ها باید برای تماس با registerWebSource() به یک لیست اجازه بپیوندند. این فرم را برای پیوستن به لیست مجاز تکمیل کنید . هدف از لیست اجازه ، کاهش ملاحظات حریم خصوصی در مورد ایجاد اعتماد به زمینه وب است.

ثبت (تبدیل) ثبت نام

در هنگام ثبت نام ، برنامه ها می توانند با registerWebTrigger() تماس بگیرند ، که انتظار پارامترهای زیر را دارد:

• Trigger URIS : این بستر به منظور واکشی ابرداده های مرتبط با ماشه ، درخواست هر URI در این لیست را صادر می کند
• مبدا مقصد : مبدا که ماشه روی آن رخ داده است (وب سایت تبلیغ کننده)

منبع انتساب و ثبت نام از WebView

به طور پیش فرض ، WebView از registerSource() و registerWebTrigger() استفاده می کند. این منابع را با برنامه مرتبط می کند و هنگام وقوع ماشه با منشأ سطح بالای وب سایت ایجاد می شود.

اگر یک برنامه به رفتار متفاوتی نیاز داشته باشد (مانند مواردی که محتوای وب را در یک وب سایت میزبانی می کنند) ، باید از روش setAttributionRegistrationBehavior در کلاس androidx.webkit.WebViewSettingsCompat استفاده کنند. این روش مشخص می کند که آیا WebView باید با registerWebSource() یا registerSource() و registerWebTrigger() یا registerTrigger() تماس بگیرد.

گزینه های موجود برای setAttributionRegistrationBehavior موارد زیر است:

ملاحظات حریم خصوصی و امنیتی

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

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

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

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

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

در تماس های API زمینه وب ، API به برنامه اعتماد می کند تا منشأ منبع و مقصد را شناسایی و مشخص کند. این می تواند ملاحظات احتمالی حریم خصوصی و امنیتی را باز کند:

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

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

هر برنامه می تواند با registerWebTrigger() تماس بگیرد زیرا ملاحظات حریم خصوصی و امنیتی در سمت ماشه بدون تبانی سمت منبع قابل اجرا نیست.

کنترل های کاربر

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

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

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

قابلیت همکاری برنامه به WEB برای API گزارش دهنده انتساب یک کار در حال انجام است. ما می خواهیم در مورد چند ایده از جامعه بازخورد بگیریم:

1. در دستگاه پشتیبانی شده از جعبه ماسه ای Android ، چگونه می توانید از راه حل های اندازه گیری مرورگر با API گزارش انتساب Android استفاده کنید؟ آیا ترجیح می دهید همه چیز را به Android منتقل کنید؟
2. آیا نگرانی هایی در مورد دریافت بالقوه 2 پینگ برای هر منبع انتساب و ماشه وجود دارد ، یکی از مرورگر یا برنامه و دیگری از API گزارش دهنده انتساب؟
3. چگونه می توانیم به اشکال زدایی در API های مختلف برای شما کمک کنیم؟
4. این پیشنهاد شامل اعتبارسنجی نمی شود که برنامه و مقصد وب وابسته هستند. در آینده ، ما ممکن است بتوانیم با بررسی انجمن ها با استفاده از پیوندهای دارایی دیجیتال ، این مقصد ها را تأیید کنیم. آیا این موارد مورد استفاده شما را مسدود می کند؟ آیا استفاده از پیوندهای دارایی دیجیتال برای انجام این اعتبار سنجی منطقی است؟
5. هنگام ثبت یک منبع انتساب ، باید یک مقصد را مشخص کنید. در مورد Web-to-App ، ممکن است بخواهید یک لینک برنامه را مشخص کنید. برای مشخص کردن این لینک برنامه از چه فرمت هایی استفاده می کنید؟
6. هنگام ثبت یک منبع انتساب برنامه به WEB ، آن رویداد منبع باید از برنامه با API گزارش Android Attribution API ثبت شود. به عنوان مثال ، اگر کاربر روی یک آگهی کلیک کند و کلیک در یک مرورگر یا برگه سفارشی مرورگر باز شود ، آن کلیک (رویداد منبع) باید از برنامه به جای در متن مرورگر ثبت شود. اگر نگرانی در مورد این موضوع دارید ، یا اینکه موارد استفاده دیگری وجود دارد که در این شماره قرار نمی گیرند که در این شماره توصیف می شود که جریان های پشتیبانی شده را توصیف می کند ، دسترسی پیدا کنید.

{٪ کلمه ٪}

برای شما توصیه می شود

• توجه: هنگام خاموش بودن جاوا اسکریپت ، متن پیوند نمایش داده می شود
• گزارش انتساب
• راهنمای گزارشگر API راهنمای توسعه دهنده API
• یادداشت های انتشار

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

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

مسیرهای ماشه

همانطور که در پیشنهاد طراحی API گزارشگر APTIBATION توضیح داده شده است ، API انتساب مسیرهای ماشه زیر را در یک دستگاه با اندرویدی واحد امکان پذیر می کند. در اینجا ما وب را به عنوان هر یک تعریف می کنیم. (1) یک مرورگر مستقل که روی Android (به عنوان مثال Chrome) اجرا می شود ، یا (2) یک وب سایت در داخل یک برنامه Android اجرا می شود.

• APP-APP: کاربر یک تبلیغ را در یک برنامه مشاهده می کند ، سپس در آن برنامه یا برنامه نصب شده دیگر تبدیل می شود.
• App-to-Web: کاربر یک تبلیغ را در یک برنامه مشاهده می کند ، سپس در وب تبدیل می کند.
• Web-to-App: کاربر تبلیغی را در وب مشاهده می کند ، سپس در یک برنامه تبدیل می کند.
• Web-to-Web: کاربر تبلیغی را در وب مشاهده می کند ، سپس در وب تبدیل می کند.

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

• برای فناوری های تبلیغاتی: به روزرسانی در تماس ها و گزارش های API برای فعال کردن مسیرهای برنامه به WEB.
• برای برنامه ها و مرورگرها: امکان انتقال ثبت نام منابع انتساب وب و محرک های وب به Android.

این سند توضیح می دهد که چگونه API گزارش انتساب برای پشتیبانی از مسیرهای ماشه برنامه به WEB ، WEB-TO-APP و وب به WEB گسترش می یابد. همچنین تغییراتی را که فناوری ها و برنامه های تبلیغاتی برای برآورده کردن الزامات پشتیبانی از این مسیرهای محرک نیاز دارند ، توصیف می کند.

دسترسی به API های گزارشگر Attribution را دریافت کنید

سیستم عامل های AD Tech برای دسترسی به API های گزارشگری Attribution باید ثبت نام کنند ، برای اطلاعات بیشتر به حساب Sandbox Privacy Account Account Sandbox مراجعه کنید .

پس از نهایی شدن روند ثبت نام ، در صورت دریافت تماس ثبت نام بدون ثبت ، API از ثبت نام دور می شود.

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

تغییرات برای فناوری های تبلیغاتی

در این بخش تغییرات در فن آوری های تبلیغاتی با استفاده از API گزارش انتساب مورد بحث قرار می گیرد.

تغییر در ثبت نام و انتساب

هنگام ثبت یک منبع انتساب ، AD Techs یک قسمت مقصد را مشخص می کند که نام بسته برنامه در جایی که رویداد ماشه رخ می دهد. برای فعال کردن اندازه گیری برنامه به WEB ، ما قصد داریم از یک قسمت مقصد برنامه (نام بسته برنامه) و یک قسمت مقصد وب (ETLD+1) پشتیبانی کنیم.

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

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

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

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

• برای گزارش های سطح رویداد ، ما از یک قسمت مقصد پشتیبانی خواهیم کرد که مشخص می کند که آیا ماشه در وب اتفاق افتاده است (مقصد یک ETLD+1 است) یا برنامه (مقصد یک نام بسته برنامه است)
• برای گزارش های قابل جمع ، مقصد به صورت ClearText ارسال می شود.

پیامدهای اندازه گیری وب به وب

برنامه ها انتخاب می کنند چه موقع ثبت نام را به API گزارش انتساب منتقل کنند. در اینجا چند ملاحظه وجود دارد:

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

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

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

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

در موردی که برنامه از WebView برای نشان دادن محتوای وب به جای یک آگهی Android استفاده می کند ، برنامه می تواند برای پیوستن به لیست Allist برای registerWebSource() استفاده کند و منشأ سطح بالای وب سایت را فراهم کند تا به جای نام بسته برنامه ، با منبع انتساب همراه باشد.

مشابه مرورگرها ، WebView از registerWebTrigger() برای ثبت نام های ماشه پشتیبانی می کند ، که ماشه را با منشأ سطح بالا مرتبط می کند. هیچ پشتیبانی برای WebView برای ثبت یک ماشه برنامه وجود ندارد. اگر مورد استفاده برای این کار دارید ، دسترسی پیدا کنید . برای لیست کامل ترکیبات پشتیبانی شده توسط WebView ، به منبع Attribution مراجعه کنید و از WebView ثبت نام کنید .

بر خلاف مرورگرها ، WebView فقط در صورتی که API گزارش دهنده انتساب Android در دسترس باشد ، از ثبت نام با سیستم عامل در عنوان Attribution-Reporting-Eligible پشتیبانی می کند. اگر API گزارش انتساب Android در دسترس نباشد ، WebView یک عنوان Attribution-Reporting-Eligible تعیین نمی کند و هیچ ثبت نام ایجاد نمی شود.

برای ثبت یک منبع / ماشه انتساب با استفاده از سیستم عامل:

• فناوری های تبلیغاتی باید با استفاده از عنوان Attribution-Reporting-Register-OS-Source ، که یک تماس API ثانویه را از طریق وب سایت به registerSource() یا registerWebSource() آغاز می کند ، به ثبت نام های منبع پاسخ دهند.
• فناوری های تبلیغاتی همچنین می توانند با استفاده از عنوان Attribution-Reporting-Register-OS-Trigger ، به ثبت نام های ماشه پاسخ دهند ، که یک تماس API ثانویه از WebView را برای registerWebTrigger() یا registerTrigger() آغاز می کند.

توجه داشته باشید که اگر پاسخ عنوان های قبلی را شامل نشود ، یا همچنین شامل Attribution-Reporting-Register-Source / Attribution-Reporting-Register-Trigger حتی اگر وب پشتیبانی نشود ، پس کل ثبت نام شکست خواهد خورد.

برای جزئیات بیشتر در مورد اینکه آیا WebView از registerSource() / registerWebSource() و registerTrigger() / registerWebTrigger() (و همچنین نحوه تغییر این رفتار) استفاده خواهد کرد ، به منبع انتساب و ثبت نام از WebView مراجعه کنید.

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

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

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

در صورتی که ADID در سمت برنامه در دسترس باشد و فناوری تبلیغ می تواند همان (صحیح) ADID را در سمت وب قرار دهد ، برای برنامه های برنامه به WEB ، Web-To-App و Web-To-Web Aptribution ، Attribution-Success و Verbose در دسترس است.

در مثال برنامه بعدی به WEB منبع در یک برنامه ناشر اتفاق می افتد ، اما ماشه در یک سایت تبلیغ کننده در داخل یک برنامه مرورگر اتفاق می افتد.

برای فعال کردن گزارش اشکال زدایی انتساب-موفقیت برای برنامه به WEB ، شرایط زیر باید برآورده شود:

• کاربر نباید با استفاده از شناسه تبلیغاتی از شخصی سازی خودداری کند
• برنامه ناشر باید مجوزهای ADID را اعلام کرده باشد
• فناوری تبلیغی باید مقدار adid را در ثبت Trigger (از زمینه وب) منتقل کند

برای فعال کردن گزارش های اشکال زدایی Verbose برای برنامه به WEB:

• گزارش های Verbose منبع فقط به مجوزهای جانبی ناشر بستگی دارد. برای ارسال گزارش های Verbose منبع ، کاربر نباید از شخصی سازی adid خودداری کند ، و برنامه ناشر باید مجوزهای ADID را اعلام کرده باشد.
• گزارش های Verbose Trigger به مجوزهای سمت ماشه (در این مثال ، وب) بستگی دارد. کوکی های شخص ثالث باید در مرورگر برای ارسال گزارش های Verbose Trigger در دسترس باشند.
• برای گزارش های Verbose Trigger که می تواند به صورت اختیاری شامل یک source_debug_key باشد ، اگر شناسه تبلیغاتی در اختیار برنامه ناشر باشد ، source_debug_key گنجانده شده است.

توجه داشته باشید که در همه موارد ، فناوری AD هنوز هم باید با استفاده از زمینه فرهنگ لغت debug_reporting در عنوان منبع ، گزارش های اشکال زدایی Verbose را انتخاب کند.

تغییرات برای برنامه ها

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

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

برای نمونه ای از چگونگی ادغام مرورگرها با API گزارش انتساب Android ، برای فعال کردن برنامه Cross و اندازه گیری وب ، به Sandbox Privacy Sandbox برای پیشنهاد وب مراجعه کنید. در این پیشنهاد ، مرورگر عنوان های درخواست زیر را اضافه می کند:

• برنامه های Attribution-Reporting-Eligible آیا پشتیبانی از سطح سیستم عامل از انتساب در دسترس است یا خیر. در این حالت ، هدر نشان می دهد که آیا API گزارش انتساب Android در دسترس است یا خیر.
• در صورت وجود ، فناوری های تبلیغاتی می توانند به صورت اختیاری با استفاده از Attribution-Reporting-Register-OS-Source پاسخ دهند ، که یک تماس API ثانویه را از برنامه مرورگر برای registerWebSource() .
• فناوری های تبلیغاتی همچنین می توانند با استفاده از عنوان Attribution-Reporting-Register-OS-Trigger ، به ثبت نام های ماشه پاسخ دهند ، که یک تماس API ثانویه از برنامه مرورگر برای registerWebTrigger() آغاز می کند.

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

هنگام ثبت یک منبع انتساب ، برنامه ها می توانند با registerWebSource() تماس بگیرند ، که انتظار پارامترهای زیر را دارد:

• منبع Attribution URIS : این پلتفرم به منظور واکشی ابرداده های مرتبط با منبع انتساب ، درخواست هر URI را در این لیست صادر می کند.
  
  هر URI باید یک پرچم اشکال زدایی بولی را همراهی کند تا نشان دهد آیا کلیدهای اشکال زدایی ارائه شده توسط تکنیک ها باید در گزارش گنجانده شوند.
• رویداد ورودی : یا یک شیء InputEvent (برای یک رویداد کلیک) یا null (برای یک رویداد مشاهده)
• مبدا منبع : منشأی که ​​منبع در آن رخ داده است (وب سایت ناشر).
• مقصد سیستم عامل : نام بسته برنامه ای که در آن رویداد ماشه اتفاق می افتد.
• مقصد وب : ETLD+1 که در آن رویداد ماشه اتفاق می افتد.
• مقصد تأیید شده : OS یا مقصد وب URI قصد استفاده شده برای پیمایش بر روی کلیک کاربر است.

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

• API مقصد مشخص شده توسط فناوری تبلیغ را با مقصد مشخص شده توسط برنامه تأیید می کند. اگر مقصد متفاوت باشد ، API ثبت نام منبع انتساب را کنار می گذارد.
  
  انتظار می رود برنامه ها قبل از فراخوانی API زمینه وب ، مقصد وب را تأیید کنند. برای کلیک ، برنامه ها باید بررسی کنند که مقصد مشخص شده با مقصدی که کاربر در آن حرکت می کند مطابقت دارد.
• API هرگونه URI های تغییر مسیر ارائه شده در Attribution-Reporting-Redirects را نادیده می گیرد. برنامه ها باید به تنهایی از تغییر مسیر پیروی کنند و برای هر تغییر مسیر registerWebSource() تماس بگیرند تا بتوانند در صورت لزوم سیاست های مجوز خود را اعمال کنند.

برنامه ها باید برای تماس با registerWebSource() به یک لیست اجازه بپیوندند. این فرم را برای پیوستن به لیست مجاز تکمیل کنید . هدف از لیست اجازه ، کاهش ملاحظات حریم خصوصی در مورد ایجاد اعتماد به زمینه وب است.

ثبت (تبدیل) ثبت نام

در هنگام ثبت نام ، برنامه ها می توانند با registerWebTrigger() تماس بگیرند ، که انتظار پارامترهای زیر را دارد:

• Trigger URIS : این بستر به منظور واکشی ابرداده های مرتبط با ماشه ، درخواست هر URI در این لیست را صادر می کند
• مبدا مقصد : مبدا که ماشه روی آن رخ داده است (وب سایت تبلیغ کننده)

منبع انتساب و ثبت نام از WebView

به طور پیش فرض ، WebView از registerSource() و registerWebTrigger() استفاده می کند. این منابع را با برنامه مرتبط می کند و هنگام وقوع ماشه با منشأ سطح بالای وب سایت ایجاد می کند.

اگر یک برنامه به رفتار متفاوتی نیاز داشته باشد (مانند مواردی که محتوای وب را در یک وب سایت میزبانی می کنند) ، باید از روش setAttributionRegistrationBehavior در کلاس androidx.webkit.WebViewSettingsCompat استفاده کنند. این روش مشخص می کند که آیا WebView باید با registerWebSource() یا registerSource() و registerWebTrigger() یا registerTrigger() تماس بگیرد.

گزینه های موجود برای setAttributionRegistrationBehavior موارد زیر است:

ملاحظات حریم خصوصی و امنیتی

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

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

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

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

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

در تماس های API زمینه وب ، API به برنامه اعتماد می کند تا منشأ منبع و مقصد را شناسایی و مشخص کند. این می تواند ملاحظات احتمالی حریم خصوصی و امنیتی را باز کند:

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

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

هر برنامه می تواند با registerWebTrigger() تماس بگیرد زیرا ملاحظات حریم خصوصی و امنیتی در سمت ماشه بدون تبانی سمت منبع قابل اجرا نیست.

کنترل های کاربر

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

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

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

قابلیت همکاری برنامه به WEB برای API گزارش دهنده انتساب یک کار در حال انجام است. ما می خواهیم در مورد چند ایده از جامعه بازخورد بگیریم:

1. در دستگاه پشتیبانی شده از جعبه ماسه ای Android ، چگونه می توانید از راه حل های اندازه گیری مرورگر با API گزارش انتساب Android استفاده کنید؟ آیا ترجیح می دهید همه چیز را به Android منتقل کنید؟
2. آیا نگرانی هایی در مورد دریافت بالقوه 2 پینگ برای هر منبع انتساب و ماشه وجود دارد ، یکی از مرورگر یا برنامه و دیگری از API گزارش دهنده انتساب؟
3. چگونه می توانیم به اشکال زدایی در API های مختلف برای شما کمک کنیم؟
4. این پیشنهاد شامل اعتبارسنجی نمی شود که برنامه و مقصد وب وابسته هستند. در آینده ، ما ممکن است بتوانیم با بررسی انجمن ها با استفاده از پیوندهای دارایی دیجیتال ، این مقصد ها را تأیید کنیم. آیا این موارد مورد استفاده شما را مسدود می کند؟ آیا استفاده از پیوندهای دارایی دیجیتال برای انجام این اعتبار سنجی منطقی است؟
5. هنگام ثبت یک منبع انتساب ، باید یک مقصد را مشخص کنید. در مورد Web-to-App ، ممکن است بخواهید یک لینک برنامه را مشخص کنید. برای مشخص کردن این لینک برنامه از چه فرمت هایی استفاده می کنید؟
6. هنگام ثبت یک منبع انتساب برنامه به WEB ، آن رویداد منبع باید از برنامه با API گزارش Android Attribution API ثبت شود. به عنوان مثال ، اگر کاربر روی یک آگهی کلیک کند و کلیک در یک مرورگر یا برگه سفارشی مرورگر باز شود ، آن کلیک (رویداد منبع) باید از برنامه به جای در متن مرورگر ثبت شود. اگر نگرانی در مورد این موضوع دارید ، یا اینکه موارد استفاده دیگری وجود دارد که در این شماره قرار نمی گیرند که در این شماره توصیف می شود که جریان های پشتیبانی شده را توصیف می کند ، دسترسی پیدا کنید.

{٪ کلمه ٪}

برای شما توصیه می شود

• توجه: هنگام خاموش بودن جاوا اسکریپت ، متن پیوند نمایش داده می شود
• گزارش انتساب
• راهنمای گزارشگر API راهنمای توسعه دهنده API
• یادداشت های انتشار

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

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

مسیرهای ماشه

As described in the Attribution Reporting API design proposal , the API enables attribution of the following trigger paths on a single Android-powered device. Here we define Web as either; (1) A standalone browser running on Android (eg Chrome) or, (2) A WebView running inside an Android app.

• App-to-app: The user sees an ad in an app, then converts in either that app or another installed app.
• App-to-web: The user sees an ad in an app, then converts on the web.
• Web-to-app: The user sees an ad on the web, then converts in an app.
• Web-to-web: The user sees an ad on the web, then converts on the web.

The preceding trigger paths translate to the following requirements:

• For ad techs: updates to API calls and reporting to enable app-to-web paths.
• For apps and browsers: ability to pass registration of web attribution sources and web triggers to Android.

This document explains how the Attribution Reporting API is extended to support app-to-web, web-to-app, and web-to-web trigger paths. It also describes the changes that ad techs and apps need to make to satisfy the requirements for supporting these trigger paths.

Get access to Attribution Reporting APIs

Ad tech platforms need to enroll to access the Attribution Reporting APIs, see Enroll for a Privacy Sandbox account for more information.

Once the enrollment process is finalized, the API will discard the registration if an unenrolled registration call is received.

When enrolling, ad tech platforms should ensure they are enrolling with all the server URLs that they might use across app and web to register attribution sources and triggers. Multiple server registration URLs are supported, but only one reporting origin is supported. This reporting origin is derived from the domain of one of the server registration URLs.

Changes for ad techs

This section discusses changes for ad techs using the Attribution Reporting API.

Changes to registration & attribution

When registering an attribution source , ad techs specify a destination field which is the app package name where the trigger event occurs. To enable app-to-web measurement, we plan to support one app destination field (app package name) and one web destination field (eTLD+1).

When registering web attribution sources or triggers, the API does not support redirects because each app hosting web content could have its own permissions model. Each app is responsible for following redirects (if supported) and calling the web context APIs for each redirect hop.

Additionally, this integration enables ad techs to use app-specific attribution logic on web attribution sources. For example, you can now specify post-install attribution windows on a web attribution source.

Receive app and web reports

The Android Attribution Reporting API can send reports for both app and web conversions. If ad techs don't want to align trigger data and aggregation key-values across web and app surfaces, they can differentiate between a web and an app conversion:

• For event-level reports , we will support a destination field that specifies whether the trigger happened on web (destination is a eTLD+1) or app (destination is an app package name)
• For aggregatable reports , the destination is sent in cleartext.

Web-to-web measurement implications

Apps choose when to pass registration to the Attribution Reporting API. در اینجا چند ملاحظه وجود دارد:

• Is the Attribution Reporting API available on that device? We will expose a new signal to apps which returns whether the Attribution Reporting API is available on that device. See the app changes section for more details on how apps can pass registration to the Attribution Reporting API.
• What portion of attribution sources and triggers should be passed to the API? This will be a decision made by each app, or the ad tech if the app permits a choice. If the app has their own measurement solution, they may want to consider using that instead. Ultimately, passing all source and trigger registrations to the Android Attribution Reporting API, when available, enables the most accurate attribution across app and web.

The following example shows how browser apps can work with the Attribution Reporting API to provide accurate measurement when the user clicks on an ad in both a browser app and a non-browser app:

• On day 1, the user clicks on an ad in the browser app.
  • The browser app can choose to use their own measurement solution or pass registration of the web ad click to the Attribution Reporting API.
• On day 2, the user clicks on an ad in a non-browser app.
  • The click is registered as an attribution source with the API. The browser app has no visibility into this click because the event occurred within a different app.
• On day 3, the user converts in the browser app.
  • If the browser app both registers the click and conversion using their own measurement solution and passes that information to the Attribution Reporting API, it's unlikely that an ad tech can deduplicate conversion reports across measurement solutions. Additionally, an ad tech could consume both the browser app rate limits and the Attribution Reporting API rate limits. Therefore, we recommend that apps pass all ad events and conversions to be registered on the API, when the API is available.

Register attribution source and trigger from WebView

In the case where the app is using WebView to show web content rather than an Android ad, the app can apply to join the allowlist for registerWebSource() and provide the top-level origin of the website to be associated with the attribution source rather than the app package name.

Similar to browsers, WebView supports registerWebTrigger() for trigger registrations, which associates the trigger with the top-level origin. There is no support for WebView to register an app trigger; reach out if you have a use case for this. For the full list of combinations supported by WebView, refer to Attribution source and trigger registration from WebView .

Unlike browsers, WebView only supports registration with the OS within the Attribution-Reporting-Eligible header if Android's Attribution Reporting API is available. If Android's Attribution Reporting API is unavailable, WebView doesn't set an Attribution-Reporting-Eligible header and no registrations are made.

To register an attribution source / trigger using the OS:

• Ad techs should respond to source registrations using the Attribution-Reporting-Register-OS-Source header, which initiates a secondary API call from the WebView to registerSource() or registerWebSource() .
• Ad techs can also respond to trigger registrations using the Attribution-Reporting-Register-OS-Trigger header, which initiates a secondary API call from the WebView to registerWebTrigger() or registerTrigger() .

Note that if the response does not include the previous headers, or it also includes the Attribution-Reporting-Register-Source / Attribution-Reporting-Register-Trigger headers even though web is not supported, then the entire registration will fail.

For details on whether WebView will use registerSource() / registerWebSource() and registerTrigger() / registerWebTrigger() (as well as how to change this behavior) refer to Attribution source and trigger registration from WebView .

Transitional debugging reports

The Attribution Reporting API supports an optional feature called transitional debugging reports , which allows ad techs to learn more information about attribution reports when an advertising ID is available. There are two types of debugging reports: attribution-success and verbose . These reports are supported for cross app and web attribution, and both report types contain the same information; the only difference being around permissions that gate when debugging reports are sent out.

For web-to-web attribution that happens within a single app (for example, within the same browser app), attribution-success and verbose reports are available only when third-party cookies are available, and are not based on advertising ID availability.

For app-to-web, web-to-app, and web-to-web cross-app attribution, attribution-success and verbose reports are available if AdID is available on the app side and the ad tech can pass the same (correct) AdID on the web side.

In a later app-to-web example the source happens in a publisher app, but the trigger happens on an advertiser site inside a browser app.

To enable an attribution-success debugging report for app-to-web, the following conditions must be met:

• The user must not have opted out of personalization using the advertising ID
• The publisher app must have declared AdID permissions
• The ad tech must pass the AdID value in trigger registration (from a web context)

To enable verbose debugging reports for app-to-web:

• Source verbose reports depend on the publisher side permissions only. For source verbose reports to be sent, the user must not have opted out of AdID personalization, and the publisher app must have declared AdID permissions.
• Trigger verbose reports depend on the trigger side (in this example, web) permissions only. Third-party cookies must be available in the browser for trigger verbose reports to be sent.
• For trigger verbose reports that can optionally include a source_debug_key , the source_debug_key is included if the advertising ID is available to the publisher app.

Note that in all cases, the ad tech still needs to opt in to receiving verbose debugging reports using the debug_reporting dictionary field in source and trigger registration headers.

Changes for apps

We will support attribution across app and web surfaces by allowing apps to pass registration of web attribution sources and web triggers to the Attribution Reporting API on Android using a new set of web context API calls.

After completing the registration steps in the following sections, app and web attribution sources and triggers are stored on the device, and the Attribution Reporting API can perform source-prioritized, last-touch attribution across app and web surfaces.

See Privacy Sandbox for the Web's proposal for an example of how browsers can integrate with Android's Attribution Reporting API to enable cross app and web measurement. In the proposal, the browser will add the following request headers:

• Attribution-Reporting-Eligible broadcasts whether OS-level support for attribution is available. In this case, the header indicates whether Android's Attribution Reporting API is available.
• If available, ad techs can optionally respond using Attribution-Reporting-Register-OS-Source , which initiates a secondary API call from the browser app to registerWebSource() .
• Ad techs can also respond to trigger registrations using the Attribution-Reporting-Register-OS-Trigger header, which initiates a secondary API call from the browser app to registerWebTrigger() .

Attribution source registration

When registering an attribution source, apps can call registerWebSource() , which expects the following parameters:

• Attribution source URIs : The platform issues a request to each URI in this list in order to fetch metadata associated with the attribution source.
  
  Each URI should accompany a boolean Debug flag to indicate if the debug keys provided by the techs should be included in the report.
• Input event : Either an InputEvent object (for a click event) or null (for a view event)
• Source origin : Origin on which the source occurred (publisher website).
• OS destination : An app package name where the trigger event happens.
• Web destination : An eTLD+1 where the trigger event happens.
• Verified destination : OS or web destination URI intent used for navigation on user click.

When the API makes a request to the Attribution Source URI, the ad tech should respond with the attribution source metadata in an HTTP header, Attribution-Reporting-Register-Source . This header uses the same fields as app-to-app attribution source registration , with a few changes:

• The API validates the destinations specified by the ad tech with the destinations specified by the app. If destinations are different, the API discards the attribution source registration.
  
  Apps are expected to validate web destinations before calling the web context API. For clicks, apps should check that the destination specified matches the destination to which the user is navigating.
• The API ignores any redirect URIs provided in Attribution-Reporting-Redirects . Apps should follow redirects on their own and call registerWebSource() for each redirect, so that they can apply their own permissions policies as needed.

Apps must join an allowlist to call registerWebSource() . Complete this form to join the allowlist. The intent of the allowlist is to mitigate privacy considerations around establishing trust for web context .

Trigger (conversion) registration

On trigger registration, apps can call registerWebTrigger() , which expects the following parameters:

• Trigger URIs : The platform issues a request to each URI in this list in order to fetch metadata associated with the trigger
• Destination origin : Origin on which the trigger occurred (advertiser website)

Attribution source and trigger registration from WebView

By default, WebView will use registerSource() and registerWebTrigger() . This associates sources with the app and triggers with the top-level origin of the WebView when the trigger occurs.

If an app requires different behavior (such as those that host web content in a WebView) they need to use the setAttributionRegistrationBehavior method on the androidx.webkit.WebViewSettingsCompat class. This method will specify whether WebView should call registerWebSource() or registerSource() and registerWebTrigger() or registerTrigger() .

The available options for setAttributionRegistrationBehavior are the following:

Privacy and security considerations

This section discusses privacy and security considerations for apps using the Attribution Reporting API.

Impact on privacy-preserving mechanisms applied to reports

As described in the main design proposal, the API applies privacy-preserving rate limits to reports . Some limits are partitioned across source and destination apps. When a web attribution source or trigger is registered, the rate limit is partitioned by the source or destination site instead of the app.

If the app maintains separate rate limits, it would be possible for an adversary to consume app-specific rate limits in addition to the API rate limits. To mitigate this, apps should ensure that a given attribution source isn't registered on both the app's measurement solution and the Android Attribution Reporting API.

Establish trust for web context

In the web context API calls, the API places trust in the app to detect and specify the source and destination origins. This can open up potential privacy and security considerations:

• An adversary can claim to be hosting websites it owns in an attempt to bypass rate limits around the amount of information any source can transfer.
• Multiple adversaries can collude to register separate attribution sources, claiming the same source site. This could cause the source site to hit ad tech platform rate limits and prevent the actual source site from registering legitimate attribution sources.

To mitigate this, we will limit which browsers or apps can call registerWebSource() to browsers or apps that attest that the source site used in registration represents the actual site being shown to the user. Fill out the Web-to-App Attribution Reporting registration form to join the allowlist to call registerWebSource() .

Any app could call registerWebTrigger() because the privacy and security considerations on the trigger side aren't applicable without source-side collusion.

کنترل های کاربر

Apps can continue to support user controls or permissions policies as long as they can be defined at registration time. For example, if apps allow any site-level or user-level permissions, the app should evaluate those and determine whether to call the web context APIs.

Additionally, we will support a new API call from apps to delete any attribution sources, triggers, and pending reports stored for that app on the device. For example, if apps allow the user to clear their browsing history, they may want to call the API to delete attribution sources, triggers, and pending reports stored for that app on the user's device.

Future considerations & open questions

The app-to-web interoperability for the Attribution Reporting API is a work in progress. We'd like to seek feedback from the community on a few ideas:

1. On an Android Privacy Sandbox supported device, how will you use browser measurement solutions with the Android Attribution Reporting API? Will you prefer to pass everything to Android?
2. Are there any concerns with potentially receiving 2 pings for each attribution source and trigger, one from the browser or app and one from the Attribution Reporting API?
3. How can we help make debugging across different APIs easier for you?
4. The proposal does not include validation that app and web destinations are affiliated. In the future, we may be able to validate these destinations by checking associations using Digital Asset Links . Would that block any of your use cases? Does it make sense to use Digital Asset Links to do this validation?
5. When registering an attribution source, you must specify a destination. In the web-to-app case, you may want to specify an app link. What formats do you use to specify this app link?
6. When registering an app-to-web attribution source, that source event would need to be registered from the app with the Android Attribution Reporting API. For example, if the user clicks on an ad and the click is opened in a browser or a browser's custom tab, that click (source event) should be registered from the app rather than in the browser context. Reach out if you have concerns about this, or if there are other use cases that don't fall into the categories covered in this issue describing supported flows .

{% verbatim %}

برای شما توصیه می شود

• Note: link text is displayed when JavaScript is off
• Attribution reporting
• Attribution Reporting API developer's guide
• یادداشت های انتشار