เทคโนโลยี Privacy Sandbox บางอย่างกำลังจะเลิกใช้งาน

ดูข้อมูลอัปเดตเกี่ยวกับแผนสำหรับเทคโนโลยี Privacy Sandbox

สถานะฟีเจอร์ Privacy Sandbox ให้ข้อมูลเพิ่มเติมเกี่ยวกับสถานะของ API และฟีเจอร์แพลตฟอร์มแต่ละรายการ

หน้านี้ได้รับการแปลโดย Cloud Translation API

ตั้งค่ารายงานการแก้ไขข้อบกพร่องสำหรับ Attribution Reporting

ส่วนที่ 2 จาก 3 เกี่ยวกับการแก้ไขข้อบกพร่องของการรายงานการระบุแหล่งที่มา ตั้งค่ารายงานการแก้ไขข้อบกพร่อง

อภิธานศัพท์

ต้นทางการรายงานคือต้นทาง ที่ตั้งค่าส่วนหัวแหล่งที่มาและทริกเกอร์ของ Attribution Reporting ระบบจะส่งรายงานทั้งหมดที่สร้างโดยเบราว์เซอร์ไปยังต้นทางนี้ ในคำแนะนำนี้ เราใช้ https://adtech.example เป็นตัวอย่างที่มาของการรายงาน
รายงานการระบุแหล่งที่มา (รายงานสั้นๆ) คือรายงานสุดท้าย (ระดับเหตุการณ์หรือที่รวบรวมไว้) ที่มีข้อมูลการวัดที่คุณขอไว้
รายงานการแก้ไขข้อบกพร่องมีข้อมูลเพิ่มเติมเกี่ยวกับรายงานการระบุแหล่งที่มา หรือเกี่ยวกับเหตุการณ์แหล่งที่มาหรือทริกเกอร์ การได้รับรายงานการแก้ไขข้อบกพร่องไม่ได้หมายความว่ามีบางอย่างทำงานผิดปกติเสมอไป รายงานการแก้ไขข้อบกพร่องมี 2 ประเภท
รายงานการแก้ไขข้อบกพร่องแบบเปลี่ยนผ่านคือรายงานการแก้ไขข้อบกพร่องที่จำเป็นต้องตั้งค่าคุกกี้เพื่อสร้างและส่ง รายงานแก้ไขข้อบกพร่องในช่วงเปลี่ยนผ่านจะใช้งานไม่ได้หากไม่มีการตั้งค่าคุกกี้และเมื่อเลิกใช้งานคุกกี้ของบุคคลที่สามแล้ว รายงานแก้ไขข้อบกพร่องทั้งหมดที่อธิบายไว้ในคู่มือนี้เป็นรายงานแก้ไขข้อบกพร่องในช่วงเปลี่ยนผ่าน
รายงานการแก้ไขข้อบกพร่องสําเร็จจะติดตามการสร้างรายงานการระบุแหล่งที่มาที่สําเร็จ ซึ่งเกี่ยวข้องโดยตรงกับรายงานการระบุแหล่งที่มา รายงานแก้ไขข้อบกพร่องสำเร็จพร้อมให้ใช้งานแล้วตั้งแต่ Chrome 101 (เมษายน 2022)
รายงานการแก้ไขข้อบกพร่องอย่างละเอียดจะติดตามรายงานที่หายไปและช่วยคุณหาสาเหตุที่รายงานหายไปได้ โดยจะระบุกรณีที่เบราว์เซอร์ไม่ได้บันทึกเหตุการณ์แหล่งที่มาหรือทริกเกอร์ (ซึ่งหมายความว่าจะไม่สร้างรายงานการระบุแหล่งที่มา) และกรณีที่สร้างหรือส่งรายงานการระบุแหล่งที่มาไม่ได้ด้วยเหตุผลบางอย่าง รายงานการแก้ไขข้อบกพร่องแบบละเอียดมีช่อง type ที่อธิบายเหตุผลที่ไม่มีการสร้างเหตุการณ์แหล่งที่มา เหตุการณ์ทริกเกอร์ หรือรายงานการระบุแหล่งที่มา รายงานการแก้ปัญหาแบบละเอียดจะพร้อมให้บริการใน Chrome 109 เป็นต้นไป (เสถียรในเดือนมกราคม 2023)
คีย์การแก้ไขข้อบกพร่องคือตัวระบุที่ไม่ซ้ำกันซึ่งตั้งค่าได้ทั้งในด้านแหล่งที่มาและฝั่งทริกเกอร์ คีย์การแก้ไขข้อบกพร่องช่วยให้คุณแมป Conversion ที่อิงตามคุกกี้และ Conversion ที่อิงตามการระบุแหล่งที่มาได้ เมื่อตั้งค่าระบบให้สร้างรายงานการแก้ไขข้อบกพร่องและตั้งค่าคีย์การแก้ไขข้อบกพร่องแล้ว เบราว์เซอร์จะรวมคีย์การแก้ไขข้อบกพร่องเหล่านี้ไว้ในรายงานการระบุแหล่งที่มาและรายงานการแก้ไขข้อบกพร่องทั้งหมด

โปรดอ่านอภิธานศัพท์ของ Privacy Sandbox เพื่อดูแนวคิดและคําสําคัญอื่นๆ ที่ใช้ในเอกสารประกอบของเรา

หากมีคำถามเกี่ยวกับการติดตั้งใช้งาน

หากพบปัญหาขณะตั้งค่ารายงานข้อบกพร่อง โปรดสร้างปัญหาใน ที่เก็บการสนับสนุนนักพัฒนาแอป ของเรา และเราจะช่วยคุณแก้ปัญหา

เตรียมตั้งค่ารายงานการแก้ไขข้อบกพร่อง

ก่อนตั้งค่ารายงานการแก้ไขข้อบกพร่อง ให้ทำตามขั้นตอนต่อไปนี้

ตรวจสอบว่าคุณได้ใช้แนวทางปฏิบัติแนะนำสำหรับการผสานรวม API แล้ว

ตรวจสอบว่าโค้ดของคุณได้รับการควบคุมโดยการตรวจหาฟีเจอร์ หากต้องการตรวจสอบว่า API ไม่ถูกบล็อกโดย Permissions-Policy ให้เรียกใช้โค้ดต่อไปนี้
```
if (document.featurePolicy.allowsFeature('attribution-reporting')) {
// the Attribution Reporting API is enabled
}
```
หากการตรวจสอบการตรวจหาฟีเจอร์นี้แสดงผลเป็น "จริง" ระบบจะอนุญาตให้ใช้ API ในบริบท (หน้าเว็บ) ที่มีการเรียกใช้การตรวจสอบ
(ไม่จำเป็นในระหว่างระยะการทดสอบ: ตรวจสอบว่าคุณได้ตั้งค่าPermissions-Policy)

แก้ไขปัญหาการผสานรวมพื้นฐาน

แม้ว่ารายงานข้อบกพร่องจะมีประโยชน์ในการช่วยตรวจหาและวิเคราะห์การสูญเสียในวงกว้าง แต่ปัญหาการผสานรวมบางอย่างก็ตรวจหาได้ในเครื่อง ปัญหาการกำหนดค่าส่วนหัวแหล่งที่มาและทริกเกอร์ไม่ถูกต้อง ปัญหาการแยกวิเคราะห์ JSON บริบทที่ไม่ปลอดภัย (ไม่ใช่ HTTPS) และปัญหาอื่นๆ ที่ทำให้ API ทำงานไม่ได้จะปรากฏในแท็บปัญหาของ DevTools

ปัญหาใน DevTools อาจมีหลายประเภท หากพบinvalid header ปัญหา ให้คัดลอกส่วนหัวลงในเครื่องมือตรวจสอบส่วนหัว ซึ่งจะช่วยให้คุณระบุและแก้ไขฟิลด์ที่ทำให้เกิดปัญหาได้

ตรวจสอบส่วนหัวการรายงานการระบุแหล่งที่มา

คุณสามารถใช้เครื่องมือตรวจสอบส่วนหัวเพื่อตรวจสอบส่วนหัวที่เกี่ยวข้องกับ Attribution Reporting API คุณสามารถตรวจสอบข้อผิดพลาดในการตรวจสอบที่มาจากเบราว์เซอร์เพื่อช่วยในการแก้ไขข้อบกพร่องของ API

หากต้องการเลือกรับรายงานการแก้ไขข้อบกพร่อง ให้ตอบกลับด้วย report-header-errors เป็นส่วนหนึ่งของส่วนหัวการตอบกลับ Attribution-Reporting-Info

Attribution-Reporting-Info: report-header-errors

โปรดทราบว่า Attribution-Reporting-Info เป็นส่วนหัวที่มีโครงสร้างแบบพจนานุกรมAttribution-Reporting-Info ดังนั้นการระบุคีย์บูลีน report-header-errors จะหมายถึงค่าเป็นจริง

ระบบจะส่งรายงานการแก้ไขข้อบกพร่องไปยังปลายทางการรายงานทันที

https://<reporting origin>/.well-known/attribution-reporting/debug/verbose

ข้อมูลรายงานจะรวมอยู่ในเนื้อหาของคำขอในรูปแบบรายการออบเจ็กต์ JSON ที่มีรูปแบบดังนี้

[{
  "type": "header-parsing-error",
  "body": {
    "context_site": "https://source.example",
    "header": "Attribution-Reporting-Register-Source",
    "value": "!!!", // header value received in the response
    "error": "invalid JSON" // optional error details that may vary across browsers or different versions of the same browser
  }
}]

ตั้งค่ารายงานการแก้ไขข้อบกพร่อง: ขั้นตอนที่ใช้ร่วมกันในรายงานความสำเร็จและรายงานแบบละเอียด

ตั้งค่าคุกกี้ต่อไปนี้ในต้นทางการรายงาน

Set-Cookie: ar_debug=1; SameSite=None; Secure; Path=/; HttpOnly

เบราว์เซอร์จะตรวจสอบว่ามีคุกกี้นี้ในทั้งแหล่งที่มาและ การลงทะเบียนทริกเกอร์หรือไม่ ระบบจะสร้างรายงานการแก้ไขข้อบกพร่องที่สำเร็จก็ต่อเมื่อมีคุกกี้ทั้ง 2 ครั้ง

โค้ดสาธิต: debug cookie

โปรดทราบว่ารายงานการแก้ไขข้อบกพร่องสามารถเปิดใช้ได้สำหรับเบราว์เซอร์ในโหมด B ซึ่งจะปิดใช้คุกกี้ของบุคคลที่สามเพื่ออำนวยความสะดวกในการทดสอบและการเตรียมพร้อมสำหรับการเลิกใช้งานคุกกี้ของบุคคลที่สาม สำหรับเบราว์เซอร์ในโหมด B คุณไม่จำเป็นต้องตั้งค่า คุกกี้แก้ไขข้อบกพร่องเพื่อเปิดใช้รายงานการแก้ไขข้อบกพร่อง ข้ามไปขั้นตอนที่ 2 เพื่อตั้งค่าคีย์การแก้ไขข้อบกพร่อง สำหรับรายงานการแก้ไขข้อบกพร่องที่สำเร็จ

ขั้นตอนที่ 2: ตั้งค่าคีย์แก้ไขข้อบกพร่อง

คีย์การแก้ไขข้อบกพร่องแต่ละรายการต้องเป็นจำนวนเต็มแบบไม่มีเครื่องหมาย 64 บิตที่จัดรูปแบบเป็นสตริงฐาน 10 กำหนดให้คีย์การแก้ไขข้อบกพร่องแต่ละรายการเป็นรหัสที่ไม่ซ้ำกัน ระบบจะสร้างรายงานการแก้ไขข้อบกพร่องที่สําเร็จก็ต่อเมื่อตั้งค่าคีย์การแก้ไขข้อบกพร่อง

แมปคีย์การแก้ไขข้อบกพร่องฝั่งแหล่งที่มากับข้อมูลเพิ่มเติมในเวลาแหล่งที่มาที่คุณ คิดว่าเกี่ยวข้องกับการแก้ไขข้อบกพร่อง
แมปคีย์การแก้ไขข้อบกพร่องฝั่งทริกเกอร์กับข้อมูลเพิ่มเติมเกี่ยวกับเวลาทริกเกอร์ที่คุณ คิดว่าเกี่ยวข้องกับการแก้ไขข้อบกพร่อง

ตัวอย่างเช่น คุณตั้งค่าคีย์การแก้ไขข้อบกพร่องต่อไปนี้ได้

รหัสคุกกี้ + การประทับเวลาแหล่งที่มาเป็นคีย์การแก้ไขข้อบกพร่องของแหล่งที่มา (และบันทึกการประทับเวลาเดียวกันนั้น ในระบบที่ใช้คุกกี้)
รหัสคุกกี้ + การประทับเวลาของทริกเกอร์เป็นคีย์การแก้ไขข้อบกพร่องของทริกเกอร์ (และบันทึกการประทับเวลาเดียวกันนั้นในระบบที่ใช้คุกกี้)

ด้วยวิธีนี้ คุณจะใช้ข้อมูล Conversion ที่อิงตามคุกกี้เพื่อค้นหารายงานการแก้ไขข้อบกพร่องหรือรายงานการระบุแหล่งที่มาที่เกี่ยวข้องได้ ดูข้อมูลเพิ่มเติมได้ในส่วนที่ 3: Cookbook

ทําให้คีย์การแก้ไขข้อบกพร่องฝั่งแหล่งที่มาแตกต่างจาก source_event_id เพื่อให้คุณ แยกความแตกต่างของรายงานแต่ละรายการที่มีรหัสเหตุการณ์แหล่งที่มาเดียวกันได้

Attribution-Reporting-Register-Source:
{
// … Usual fields for Attribution-Reporting-Register-Source
"debug_key":"647775351539539"
}

Attribution-Reporting-Register-Trigger:
{
// … Usual fields for Attribution-Reporting-Register-Trigger
"debug_key":"938321351539743"
}

รหัสสาธิต: source debug key รหัสสาธิต: trigger debug key

หมายเหตุ: ในโค้ดตัวอย่าง เราจะกำหนดค่าคุกกี้ของบุคคลที่สามสำหรับการวัดผลเดิมให้กับทั้งคีย์การแก้ไขข้อบกพร่อง ในระบบจริง คุณจะต้องกำหนดให้แต่ละคีย์เป็นรหัสที่ไม่ซ้ำกัน และแมปคีย์กับข้อมูลเพิ่มเติมในเวลาแหล่งที่มาที่คุณเห็นว่ามีประโยชน์สำหรับการแก้ไขข้อบกพร่อง ตามที่แนะนำในตัวอย่างคีย์การแก้ไขข้อบกพร่อง

ตั้งค่ารายงานการแก้ไขข้อบกพร่องที่สําเร็จ

โค้ดตัวอย่างในส่วนนี้จะสร้างรายงานการแก้ไขข้อบกพร่องที่สําเร็จสําหรับทั้ง รายงานระดับเหตุการณ์และรายงานที่รวบรวมได้ รายงานระดับเหตุการณ์และรายงานที่รวบรวมได้ใช้ คีย์แก้ไขข้อบกพร่องเดียวกัน

ขั้นตอนที่ 3: ตั้งค่าปลายทางเพื่อรวบรวมรายงานการแก้ไขข้อบกพร่องที่สำเร็จ

ตั้งค่าปลายทางเพื่อรวบรวมรายงานการแก้ไขข้อบกพร่อง ปลายทางนี้ควรคล้ายกับปลายทางการระบุแหล่งที่มาหลัก โดยมีสตริง debug เพิ่มเติมในเส้นทาง ดังนี้

ปลายทางสำหรับรายงานการแก้ไขข้อบกพร่องของความสำเร็จระดับเหตุการณ์ https://adtech.example/.well-known/attribution-reporting/debug/report-event-attribution
- ปลายทางสำหรับรายงานการแก้ไขข้อบกพร่องที่สำเร็จของ aggregatable https://adtech.example/.well-known/attribution-reporting/debug/report-aggregate-attribution

เมื่อมีการทริกเกอร์การระบุแหล่งที่มา เบราว์เซอร์จะส่งรายงานการแก้ไขข้อบกพร่องทันทีโดยใช้คำขอ POST ไปยังปลายทางนี้ โค้ดของเซิร์ฟเวอร์เพื่อจัดการรายงานการแก้ไขข้อบกพร่องที่สําเร็จซึ่งเข้ามาอาจมีลักษณะดังนี้ (ที่นี่ในปลายทางของโหนด)

// Handle incoming event-Level Success Debug reports
adtech.post(
  '/.well-known/attribution-reporting/debug/report-event-attribution',
  async (req, res) => {
    // Debug report is in req.body
    res.sendStatus(200);
  }
);

// Handle incoming aggregatable Success Debug reports
adtech.post(
  '/.well-known/attribution-reporting/debug/report-aggregate-attribution',
  async (req, res) => {
    // Debug report is in req.body
    res.sendStatus(200);
  }
);

โค้ดสาธิต: รายงานการแก้ไขข้อบกพร่องระดับเหตุการณ์ ปลายทาง

โค้ดสาธิต: รายงานการแก้ไขข้อบกพร่องที่รวบรวมได้ ปลายทาง

ขั้นตอนที่ 4: ยืนยันว่าการตั้งค่าจะสร้างรายงานการแก้ไขข้อบกพร่องที่สําเร็จ

เปิด chrome://attribution-internals ในเบราว์เซอร์
ตรวจสอบว่าได้เลือกช่องทําเครื่องหมายแสดงรายงานการแก้ไขข้อบกพร่องแล้ว ทั้งในแท็บรายงานระดับเหตุการณ์และแท็บรายงานที่รวบรวมได้
เปิดเว็บไซต์ที่คุณใช้การรายงานการระบุแหล่งที่มา ทำตาม ขั้นตอนที่คุณใช้สร้างรายงานการระบุแหล่งที่มา โดยขั้นตอนเดียวกันนี้จะ สร้างรายงานการแก้ไขข้อบกพร่องที่สำเร็จ
ใน chrome://attribution-internals
- ตรวจสอบว่าระบบสร้างรายงานการระบุแหล่งที่มาอย่างถูกต้อง
- ในแท็บรายงานระดับเหตุการณ์และแท็บรายงานที่รวบรวมได้ ให้ตรวจสอบว่าระบบสร้างรายงานการแก้ไขข้อบกพร่องที่สําเร็จด้วย คุณจะเห็นไฟล์เหล่านั้นในรายการพร้อมเส้นทางสีน้ำเงิน debug

การระบุแหล่งที่มาภายใน — รายละเอียดการระบุแหล่งที่มา

ในเซิร์ฟเวอร์ ให้ตรวจสอบว่าอุปกรณ์ปลายทางได้รับรายงานการแก้ไขข้อบกพร่องที่ระบุว่าสำเร็จเหล่านี้ทันที โปรดตรวจสอบรายงานการแก้ไขข้อบกพร่องของความสําเร็จทั้งระดับเหตุการณ์และระดับที่รวบรวมได้

การรายงานบันทึกเซิร์ฟเวอร์ต้นทาง — การรายงานบันทึกของเซิร์ฟเวอร์ต้นทาง

ขั้นตอนที่ 5: ดูรายงานการแก้ไขข้อบกพร่องที่สำเร็จ

รายงานการแก้ไขข้อบกพร่องที่สําเร็จจะเหมือนกับรายงานการระบุแหล่งที่มา และมีทั้ง คีย์การแก้ไขข้อบกพร่องฝั่งแหล่งที่มาและฝั่งทริกเกอร์

{
  "attribution_destination": "https://advertiser.example",
  "randomized_trigger_rate": 0.0000025,
  "report_id": "7d76ef29-d59e-4954-9fff-d97a743b4715",
  "source_debug_key": "647775351539539",
  "source_event_id": "760938763735530",
  "source_type": "event",
  "trigger_data": "0",
  "trigger_debug_key": "156477391437535"
}

{
  "aggregation_service_payloads": [
    {
      "debug_cleartext_payload": "omRkYXRhgqJldmFsdWVEAACAAGZidWNrZXRQPPhnkD+7c+wm1RjAlowp3KJldmFsdWVEAAARMGZidWNrZXRQJFJl9DLxbnMm1RjAlowp3GlvcGVyYXRpb25paGlzdG9ncmFt",
      "key_id": "d5f32b96-abd5-4ee5-ae23-26490d834012",
      "payload": "0s9mYVIuznK4WRV/t7uHKquHPYCpAN9mZHsUGNiYd2G/9cg87Y0IjlmZkEtiJghMT7rmg3GtWVPWTJU5MvtScK3HK3qR2W8CVDmKRAhqqlz1kPZfdGUB4NsXGyVCy2UWapklE/r7pmRDDP48b4sQTyDMFExQGUTE56M/8WFVQ0qkc7UMoLI/uwh2KeIweQCEKTzw"
    }
  ],
  "shared_info": "{\"api\":\"attribution-reporting\",\"attribution_destination\":\"https://advertiser.example\",\"debug_mode\":\"enabled\",\"report_id\":\"4a04f0ff-91e7-4ef6-9fcc-07d000c20495\",\"reporting_origin\":\"https://adtech.example\",\"scheduled_report_time\":\"1669888617\",\"source_registration_time\":\"1669852800\",\"version\":\"0.1\"}",
  "source_debug_key": "647775351539539",
  "trigger_debug_key": "156477391437535"
}

ตั้งค่ารายงานการแก้ไขข้อบกพร่องแบบละเอียด

ขั้นตอนที่ 3: เลือกใช้การแก้ไขข้อบกพร่องแบบละเอียดในส่วนหัวของแหล่งที่มาและทริกเกอร์

ตั้งค่า debug_reporting เป็น true ในทั้ง Attribution-Reporting-Register-Source และ Attribution-Reporting-Register-Trigger

Attribution-Reporting-Register-Source:
{
// … Usual fields for Attribution-Reporting-Register-Source
"debug_key":"938321351539743",
"debug_reporting": true // defaults to false if not present
}

Attribution-Reporting-Register-Trigger:
{
// … Usual fields for Attribution-Reporting-Register-Trigger
"debug_key":"938321351539743",
"debug_reporting": true // defaults to false if not present
}

โค้ดตัวอย่าง: source header

โค้ดตัวอย่าง: trigger header

ขั้นตอนที่ 4: ตั้งค่าปลายทางเพื่อรวบรวมรายงานการแก้ไขข้อบกพร่องแบบละเอียด

ตั้งค่าปลายทางเพื่อรวบรวมรายงานการแก้ไขข้อบกพร่อง ปลายทางนี้ควรคล้ายกับปลายทางการระบุแหล่งที่มาหลัก โดยมีสตริง debug/verbose เพิ่มเติมในเส้นทาง

https://adtech.example/.well-known/attribution-reporting/debug/verbose

เมื่อสร้างรายงานการแก้ไขข้อบกพร่องแบบละเอียด ซึ่งก็คือเมื่อไม่ได้ลงทะเบียนแหล่งที่มาหรือทริกเกอร์ เบราว์เซอร์จะส่งรายงานการแก้ไขข้อบกพร่องแบบละเอียดโดยใช้คำขอ POST ไปยังปลายทางนี้ทันที โค้ดของเซิร์ฟเวอร์เพื่อจัดการรายงานการแก้ไขข้อบกพร่องแบบละเอียดที่เข้ามาอาจมีลักษณะดังนี้ (ที่นี่ในปลายทางของโหนด)

// Handle incoming verbose debug reports
adtech.post(
  '/.well-known/attribution-reporting/debug/verbose',
  async (req, res) => {
    // List of verbose debug reports is in req.body
    res.sendStatus(200);
  }
);

รายงานแบบละเอียดมีปลายทางเดียวเท่านั้น ซึ่งต่างจากรายงานการแก้ไขข้อบกพร่องที่สำเร็จ รายงานแบบละเอียดที่เกี่ยวข้องกับรายงานระดับเหตุการณ์และรายงานแบบรวมจะถูกส่งไปยังปลายทางเดียวกันทั้งหมด

โค้ดสาธิต: รายงานการแก้ไขข้อบกพร่องแบบละเอียด ปลายทาง

ขั้นตอนที่ 5: ยืนยันว่าการตั้งค่าจะสร้างรายงานการแก้ไขข้อบกพร่องแบบละเอียด

แม้ว่ารายงานการแก้ไขข้อบกพร่องแบบละเอียดจะมีหลายประเภท แต่คุณก็สามารถ ตรวจสอบการตั้งค่าการแก้ไขข้อบกพร่องแบบละเอียดได้โดยใช้รายงานการแก้ไขข้อบกพร่องแบบละเอียดเพียงประเภทเดียว หากสร้างและรับรายงานการแก้ไขข้อบกพร่องแบบละเอียดประเภทนี้ได้อย่างถูกต้อง แสดงว่าระบบจะสร้างและรับรายงานการแก้ไขข้อบกพร่องแบบละเอียดทุกประเภทได้อย่างถูกต้องเช่นกัน เนื่องจากรายงานการแก้ไขข้อบกพร่องแบบละเอียดทั้งหมดใช้การกำหนดค่าเดียวกันและส่งไปยังปลายทางเดียวกัน

ประเด็นสำคัญ: เลือกรายงานการแก้ไขข้อบกพร่องแบบละเอียดที่ เห็นได้ชัดเจนเพื่อทดสอบ trigger-no-matching-source เป็นตัวเลือกที่ดี เนื่องจากคุณสร้างได้โดยการแปลง รายงานแบบละเอียดที่เกี่ยวข้อง กับเหตุการณ์ทริกเกอร์มักจะเป็นตัวเลือกที่ดีกว่า ส่วนประเภทรายงานแบบละเอียดที่ เกี่ยวข้องกับเหตุการณ์ต้นทางจะสร้างได้ยากกว่า

เปิด chrome://attribution-internals ในเบราว์เซอร์
ทริกเกอร์การระบุแหล่งที่มา (ทํา Conversion) ในเว็บไซต์ที่ตั้งค่าด้วย Attribution Reporting เนื่องจากไม่มีการมีส่วนร่วมกับโฆษณา (การแสดงผลหรือการคลิก) ก่อน Conversion นี้ คุณจึงควรคาดหวังว่าจะได้รับรายงานการแก้ไขข้อบกพร่องแบบละเอียดประเภท trigger-no-matching-source
ใน chrome://attribution-internals ให้เปิดแท็บรายงานการแก้ไขข้อบกพร่องแบบละเอียด และตรวจสอบว่าได้สร้างรายงานการแก้ไขข้อบกพร่องแบบละเอียดประเภท trigger-no-matching-source แล้ว
ในเซิร์ฟเวอร์ ให้ตรวจสอบว่าปลายทางได้รับรายงานการแก้ไขข้อบกพร่องแบบละเอียดนี้ทันที

ขั้นตอนที่ 6: ดูรายงานการแก้ไขข้อบกพร่องแบบละเอียด

รายงานการแก้ไขข้อบกพร่องแบบละเอียดที่สร้างขึ้นในเวลาที่ทริกเกอร์จะรวมทั้งคีย์การแก้ไขข้อบกพร่องฝั่งแหล่งที่มาและฝั่งทริกเกอร์ (หากมีแหล่งที่มาที่ตรงกันสำหรับทริกเกอร์) รายงานการแก้ไขข้อบกพร่องแบบละเอียดที่สร้างขึ้นในเวลาต้นทางจะมีคีย์การแก้ไขข้อบกพร่องฝั่งต้นทาง

ตัวอย่างคำขอที่มีรายงานการแก้ไขข้อบกพร่องแบบละเอียดซึ่งเบราว์เซอร์ส่งมา

[
  {
    "body": {
      "attribution_destination": "http://arapi-advertiser.localhost",
      "randomized_trigger_rate": 0.0000025,
      "report_id": "92b7f4fd-b157-4925-999e-aad6361de759",
      "source_debug_key": "282273499788483",
      "source_event_id": "480041649210491",
      "source_type": "event",
      "trigger_data": "1",
      "trigger_debug_key": "282273499788483"
    },
    "type": "trigger-event-low-priority"
  },
  {
    "body": {
      "attribution_destination": "http://arapi-advertiser.localhost",
      "limit": "65536",
      "source_debug_key": "282273499788483",
      "source_event_id": "480041649210491",
      "source_site": "http://arapi-publisher.localhost",
      "trigger_debug_key": "282273499788483"
    },
    "type": "trigger-aggregate-insufficient-budget"
  }
]

รายงานแบบละเอียดแต่ละรายการจะมีช่องต่อไปนี้

Type: สาเหตุที่ทำให้ระบบสร้างรายงาน หากต้องการดูข้อมูลเกี่ยวกับรายงานแบบละเอียดทุกประเภทและสิ่งที่ควรทำตามรายงานแต่ละประเภท โปรดดูข้อมูลอ้างอิงรายงานแบบละเอียดในส่วนที่ 3: คู่มือการแก้ไขข้อบกพร่อง
Body: เนื้อหาของรายงาน โดยจะขึ้นอยู่กับประเภทของวิดีโอ ดูข้อมูลอ้างอิงรายงานแบบละเอียด ในส่วนที่ 3: คู่มือการแก้ไขข้อบกพร่อง

เนื้อหาของคำขอจะมีรายงานแบบละเอียดอย่างน้อย 1 รายการและอย่างมาก 2 รายการ

รายงานแบบละเอียด 1 รายการหากความล้มเหลวส่งผลต่อรายงานระดับเหตุการณ์เท่านั้น (หรือหากส่งผลต่อรายงานที่รวบรวมได้เท่านั้น) แหล่งที่มาหรือการลงทะเบียนทริกเกอร์ล้มเหลวมีเหตุผลเดียว จึงสร้างรายงานแบบละเอียดได้ 1 รายการต่อความล้มเหลว 1 ครั้ง และต่อประเภทรายงาน (ระดับเหตุการณ์หรือแบบรวบรวมได้)
รายงานแบบละเอียด 2 ฉบับหากความล้มเหลวส่งผลต่อทั้งรายงานระดับเหตุการณ์และรายงานที่รวบรวมได้ โดยมีข้อยกเว้นดังนี้ หากเหตุผลที่ทำให้เกิดความล้มเหลวเหมือนกันสำหรับรายงานระดับเหตุการณ์และรายงานที่รวบรวมได้ ระบบจะสร้างรายงานแบบละเอียดเพียงฉบับเดียว (ตัวอย่าง:trigger-no-matching-source)

ส่วนที่ 3: คู่มือการแก้ไขข้อบกพร่อง