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

کتاب آشپزی اشکال زدایی گزارش انتساب

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

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

واژه نامه

The reporting origin is the origin that sets the Attribution Reporting source and trigger headers. All reports generated by the browser are sent to this origin. In this guidance, we use https://adtech.example as the example reporting origin.
An attribution report (report for short) is the final report (event-level or aggregatable) that contains the measurement data you've requested.
A debug report contains additional data about an attribution report, or about a source or trigger event. Receiving a debug report does not necessarily mean that something is working incorrectly! There are two types of debug reports
A transitional debug report is a debug report that requires a cookie to be set in order to be generated and sent. Transitional debug reports will be unavailable if a cookie is not set, and once third-party cookies are deprecated. All debug reports described in this guide are transitional debug reports.
Success debug reports track successful generation of an attribution report. They relate directly to an attribution report. Success debug reports have been available since Chrome 101 (April 2022).
Verbose debug reports can track missing reports and help you determine why they're missing. They indicate cases where the browser did not record a source or trigger event, (which means it will not generate an attribution report), and cases where an attribution report can't be generated or sent for some reason. Verbose debug reports include a type field that describes the reason why a source event, trigger event or attribution report was not generated. Verbose debug reports are available starting in Chrome 109 (Stable in January 2023).
Debug keys are unique identifiers you can set on both the source side and the trigger side. Debug keys enable you to map cookie-based conversions and attribution-based conversions. When you've set up your system to generate debug reports and set debug keys, the browser will include these debug keys in all attribution reports and debug reports.

For more concepts and key terms used throughout our documentation, refer to the Privacy Sandbox glossary.

نحوه انجام: ادغام خود را در زمان واقعی بررسی کنید

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

نحوه انجام: ضرر را تجزیه و تحلیل کنید و ادغام خود را عیب یابی کنید

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

نمای کلی

از کلیدهای اشکال زدایی (جفت <source_debug_key, trigger_debug_key> ) برای نگاشت تبدیل کوکی ها به گزارش های اشکال زدایی موفقیت آمیز استفاده کنید. برای هر تبدیل کوکی، در زمان تبدیل، یک گزارش اشکال زدایی موفقیت آمیز مربوطه دریافت کردید؟

اگر بله : برای همه این گزارش‌های اشکال‌زدایی موفقیت آمیز، می‌توانید انتظار داشته باشید که بعداً یک گزارش انتساب دریافت کنید - به استثنای چند مورد. برای جزئیات ، سناریوی گزارش اشکال زدایی موفقیت آمیز را مرور کنید.

اگر نه : این بدان معناست که تبدیل در Attribution Reporting ثبت نشده است. از جفت <source_debug_key, trigger_debug_key> (یا کلید اشکال‌زدایی منبع در صورت وجود نداشتن کلید اشکال‌زدایی راه‌انداز) برای نگاشت تبدیل کوکی‌ها به گزارش‌های اشکال‌زدایی مفصل استفاده کنید. برای هر یک از این تبدیل‌ها، آیا در نقطه‌ای (منبع یا زمان راه‌اندازی) گزارش اشکال‌زدایی پرمخاطب مربوطه را دریافت کردید؟

اگر گزارش اشکال زدایی مفصلی دریافت نکردید: ممکن است به دلیل رفتار کاربر یا مشکل یکپارچه سازی باشد. برای جزئیات ، سناریوی گزارش بدون اشکال زدایی را مرور کنید.
اگر گزارش اشکال زدایی مفصل دریافت کردید، به فیلد type آن نگاه کنید.
- اگر type آن source-success باشد: این بدان معناست که منبع با موفقیت ثبت شده است، اما ماشه ثبت نشده است. برای محدود کردن دلیل عدم وجود گزارش اشکال زدایی موفقیت آمیز، به دنبال یک گزارش اشکال زدایی پرمخاطب متناظر با هر نوع دیگری بگردید⏤که گزارش مشکلی را در سمت ماشه نشان می دهد.
- اگر type آن چیز دیگری است: منبع یا ماشه ثبت نشده است. type به شما می گوید چرا گزارش اسناد مربوطه (و گزارش اشکال زدایی موفقیت آمیز) وجود ندارد. بسته به type گزارش اشکال زدایی پرمخاطب، ممکن است بخواهید این اطلاعات را فقط به عنوان نقطه داده تجزیه و تحلیل ضرر در نظر بگیرید (به عبارت دیگر، هیچ اقدامی برای شما انجام نمی شود)، یا ممکن است بخواهید یک اشکال را ثبت کنید یا پیاده سازی خود را عیب یابی کنید. برای جزئیات ، سناریوی گزارش اشکال زدایی مفصل را مرور کنید.

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

سناریوهای احتمالی

گزارش اشکال زدایی موفقیت آمیز

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

می‌توانید انتظار داشته باشید که بعداً یک گزارش انتساب برای این تبدیل دریافت کنید ⏤با چند استثنا:

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

گزارش اشکال زدایی کامل از نوع `source-success`

اگر برای منبع تبدیل کوکی معین، یک گزارش اشکال زدایی مفصل از نوع source-success دریافت کردید، به این معنی است که ثبت منبع با موفقیت انجام شده است. بسته به اینکه ثبت ماشه نیز بعداً موفقیت آمیز باشد، ممکن است گزارشی برای آن تبدیل دریافت کنید یا خیر.

در این مورد یک اخطار وجود دارد:

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

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

محدودیت های حریم خصوصی
محدودیت های ذخیره سازی
قوانین سفارشی
مشکل پیاده سازی در کد شما
اشکال مرورگر

برخی از اینها انتظار می رود! اینکه کدام اقدام باید انجام شود به type هر گزارش پرمخاطب بستگی دارد. مرجع گزارش های پرمخاطب را مرور کنید.

گزارش اشکال زدایی وجود ندارد

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

تنظیمات برگزیده کاربر (کاربر کوکی های شخص ثالث را خاموش کرده است)
کوکی از دست رفته یا کلیدهای اشکال زدایی از دست رفته است (کلید اشکال زدایی به دلیل وجود کوکی از دست رفته پاک شد). در chrome://attribution-internals ، برگه Logs را باز کنید و بررسی کنید که آیا مشکلی در آنجا وجود دارد یا خیر.
مشکلات شبکه که در زمان مبدا یا راه‌اندازی رخ داده‌اند، اما نه زمانی که گزارش انتساب ارسال شده است.

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

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

مسئله ادغام اساسی نحوه عیب‌یابی این موارد را در رفع مشکلات یکپارچه‌سازی اساسی مرور کنید.
مشکلات شبکه احتمالی
تنظیمات برگزیده کاربر در تنظیمات مرورگر مانند Privacy Sandbox خاموش است.

مرجع گزارش اشکال زدایی پرمخاطب

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

توجه: اگر type گزارش پرمخاطب با trigger-event شروع می‌شود، می‌توان آن را فقط برای رویدادهای منبع یا راه‌اندازی که با گزارش‌های سطح رویداد مرتبط هستند تولید کرد. اگر type گزارش پرمخاطب با trigger-aggregate شروع شود، می‌توان آن را فقط برای رویدادهای منبع یا راه‌اندازی که با گزارش‌های انبوه‌سازی مرتبط هستند تولید کرد. در تمام موارد دیگر، برای یک گزارش در سطح رویداد یا یک گزارش تجمیع‌پذیر است.

موفقیت ثبت منبع

یک منبع با موفقیت ثبت شد.

source-success: جزئیات و بدن گزارش

گزارش محدودیت های حریم خصوصی

این گزارش ها مورد انتظار است. آنها محدودیت های حریم خصوصی را برای کاهش نشت هویت کاربر بین سایت نشان می دهند.

source-destination-limit: جزئیات و بدن گزارش
source-noised: جزئیات و بدن گزارش
trigger-attributions-per-source-destination-limit: جزئیات و بدن گزارش
trigger-reporting-origin-limit: جزئیات و بدن گزارش
trigger-event-noise: جزئیات و بدن گزارش
trigger-event-excessive-reports: این در صورتی ایجاد می شود که تعداد گزارش بیش از حد باشد. می توانید حداکثر یک تبدیل برای بازدیدها و سه تبدیل برای کلیک ثبت کنید. توجه داشته باشید که می‌توانید با تنظیم اولویت‌ها ، گزارش‌های دریافتی را پیکربندی کنید. جزئیات و بدن گزارش

گزارش محدودیت های ذخیره سازی

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

source-storage-limit: جزئیات و بدن گزارش
trigger-event-storage-limit: جزئیات و بدن گزارش
trigger-aggregate-storage-limit: جزئیات و بدن گزارش

گزارش قوانین سفارشی

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

trigger-no-matching-filter-data: جزئیات و بدن گزارش
trigger-event-no-matching-configuration: جزئیات و بدن گزارش
trigger-event-deduplicated: جزئیات و بدن گزارش
trigger-aggregate-deduplicated: جزئیات و بدن گزارش
trigger-event-low-priority: جزئیات و بدن گزارش
trigger-event-report-window-passed: جزئیات و بدن گزارش
trigger-aggregate-report-window-passed: جزئیات و بدن گزارش

گزارش های پرمخاطب دیگر

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

trigger-no-matching-source: این ممکن است یک مشکل اجرایی باشد. بررسی کنید که پیکربندی نادرستی در تنظیم <reporting origin, destination> وجود نداشته باشد. همچنین ممکن است رفتار API مورد انتظار باشد. به عنوان مثال، کاربر پس از درگیر شدن با یک تبلیغ و قبل از تبدیل، داده ها را در مقطعی پاک کرده است، یا کاربر بدون مشاهده آگهی مرتبط، تبدیل را انجام داده است. جزئیات و بدن گزارش
trigger-aggregate-no-contributions: احتمالاً این رفتاری نیست که شما قصد دارید کدتان داشته باشد. کد ثبت ماشه خود را عیب یابی کنید. مطمئن شوید که پیکربندی مشارکت شما صحیح است. جزئیات و بدن گزارش
trigger-aggregate-insufficient-budget: احتمالاً این رفتاری نیست که شما قصد دارید کدتان داشته باشد. کد ثبت راه‌انداز خود را دوباره بررسی کنید تا مطمئن شوید که مجموع همه مشارکت‌ها از بودجه مشارکت تجاوز نمی‌کند. جزئیات و بدن گزارش

خطاهای غیرمنتظره (اشکالات احتمالی مرورگر)

این گزارش ها غیرمنتظره هستند . آنها ممکن است به دلیل یک اشکال مرورگر باشند! یک اشکال را ثبت کنید و در توضیحات خود مراحل بازتولید آن را مشخص کنید.

source-unknown-error: جزئیات و بدن گزارش
trigger-unknown-error: جزئیات و بدن گزارش

مثال تجزیه و تحلیل ضرر

مرحله 1: راه اندازی و نقشه برداری با کوکی ها

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

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

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

در این مثال، فرض کنید 100 تبدیل را با سیستم مبتنی بر کوکی خود ردیابی کرده اید.

هر بار که یک تبدیل مبتنی بر کوکی را ثبت می کنید، به دنبال گزارش اشکال زدایی موفقیت آمیز (ارسال فوری) باشید که دارای همان جفت <source_debug_key, trigger_debug_key> با این تبدیل مبتنی بر کوکی باشد.

بیایید فرض کنیم برای 70 مورد از این تبدیل کوکی ها، یک گزارش اشکال زدایی موفقیت آمیز دریافت کرده اید.

گزارش‌های موفقیت به این معنی است که انتساب با موفقیت ثبت شده است، بنابراین شما می‌توانید با خیال راحت فرض کنید که گزارش اسنادی را دریافت می‌کنید که با هر گزارش موفقیت مطابقت دارد - به استثنای برخی موارد.
شما می توانید تصمیم بگیرید که بر این استثناها نظارت کنید. برای انجام این کار، از آنجایی که گزارش‌های انتساب طی روزها/هفته‌های بعدی (بسته به انقضا) به نقطه پایانی شما ارسال می‌شود، به دنبال گزارش‌های انتساب باشید که دارای جفت کلیدهای اشکال‌زدایی یکسان با هر گزارش اشکال زدایی موفقیت آمیز هستند. مطمئن شوید که کمی صبر کنید: ممکن است گزارش‌ها بلافاصله در پایان هر پنجره ارسال نشود. بیایید فرض کنیم که شما فقط 60 گزارش انتساب پیدا می کنید. 10 گزارش ذکر منبع ممکن است به دلیل رفتار کاربر باشد.

توجه: ممکن است گزارش‌های انتساب در سطح رویداد داشته باشید که به یک تبدیل مبتنی بر کوکی نگاشت نمی‌شوند. اینها به احتمال زیاد گزارش های پر سر و صدایی هستند که به طور تصادفی توسط API تولید شده اند. می‌توانید این موضوع را با جستجوی گزارش‌های پرمخاطب اشکال‌زدایی از نوع source-noised که دارای کلید اشکال‌زدایی منبع مشابه با گزارش سطح رویداد شما هستند، تأیید کنید.

مرحله 3: ارزیابی مختصر ضرر

100-70 = 30 گزارش اشکال زدایی موفقیت آمیز وجود ندارد. این بدان معناست که این 30 تبدیل (که در اجرای مبتنی بر کوکی شما ردیابی شده‌اند) با گزارش Attribution ثبت نشده‌اند. شما گزارش های انتساب را برای این موارد دریافت نخواهید کرد.

از آنجایی که شما 100 تبدیل مبتنی بر کوکی و تنها 70 تبدیل مبتنی بر اسناد دارید، ضرر شما 30٪ است. اکنون یک ارزیابی مختصر از دست دادن دارید.

مرحله 4: علل را تجزیه و تحلیل کنید

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

بیایید فرض کنیم که 10 کلید وجود دارد که هیچ گزارش اشکال زدایی مفصلی برای آنها وجود ندارد. بررسی کنید که آیا مشکلی در ادغام وجود دارد. اگر نه، این ممکن است به دلیل رفتار کاربر باشد.
شما 20 گزارش اشکال زدایی مفصل دارید. اکنون می توانید تجزیه و تحلیل ضرر خود را اصلاح کنید. فیلد type هر گزارش مفصل را تجزیه و تحلیل کنید. برای مثال، ممکن است متوجه شوید که:
- 10 (= 10٪ در مثال ما) گزارش به دلیل pending destination limit وجود ندارد
- 5 (= 5%) گزارش به دلیل trigger-aggregate-no-contributions وجود ندارد.
- 5 (= 5%) گزارش به دلیل unknown-error وجود ندارد.

مرحله 5: اقدام و عیب یابی کنید

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

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

pending-destination-limit حفاظت از حریم خصوصی است. هیچ اقدامی برای انجام دادن وجود ندارد از این شماره به عنوان نقطه داده، برای مشاهده و نظارت خود استفاده کنید.
trigger-aggregate-no-contributions ممکن است نشانه ای از یک مشکل اجرایی در طرف شما باشد. این را بیشتر تحلیل کنید. برای عیب‌یابی و رفع آن در صورت نیاز، از جزئیات در بدنه گزارش پرمخاطب استفاده کنید.
unknown-error ممکن است نشانه یک اشکال مرورگر یا خطای شبکه باشد. اگر مکرراً با این مشکل مواجه شدید، یک اشکال برای توسعه دهندگان مرورگر ثبت کنید.