ส่วนที่ 2 จาก 3 เกี่ยวกับการแก้ไขข้อบกพร่อง Attribution Reporting ตั้งค่ารายงานการแก้ไขข้อบกพร่อง
อภิธานศัพท์
- ต้นทางการรายงานคือต้นทาง
ที่ตั้งค่าส่วนหัวแหล่งที่มาและทริกเกอร์ของ 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 ในบริบท (หน้า) ที่ดำเนินการตรวจสอบ
(ไม่จำเป็นในช่วงทดสอบ: ตรวจสอบว่าคุณได้ตั้งค่านโยบายสิทธิ์แล้ว)
แก้ไขปัญหาการผสานรวมพื้นฐาน
แม้ว่ารายงานการแก้ไขข้อบกพร่องจะมีประโยชน์ในการช่วยให้คุณตรวจจับและวิเคราะห์การสูญเสียในวงกว้าง แต่คุณก็สามารถตรวจพบปัญหาการผสานรวมบางอย่างในเครื่องได้ ปัญหาการกำหนดค่าส่วนหัวและแหล่งที่มาไม่ถูกต้อง, ปัญหาการแยกวิเคราะห์ JSON, บริบทที่ไม่ปลอดภัย (ไม่ใช่ HTTPS) และปัญหาอื่นๆ ที่ขัดขวางไม่ให้ API ทำงานจะปรากฏในแท็บปัญหาของ DevTools
ปัญหาเกี่ยวกับเครื่องมือสำหรับนักพัฒนาเว็บอาจแตกต่างกันได้หลายประเภท หากพบปัญหา invalid header
ให้คัดลอกส่วนหัวไปยังเครื่องมือตรวจสอบส่วนหัว ซึ่งจะช่วยให้คุณระบุและแก้ไขช่องที่ทำให้เกิดปัญหาได้
ตั้งค่ารายงานการแก้ไขข้อบกพร่อง: ขั้นตอนทั่วไปสำหรับรายงานความสำเร็จและรายงานแบบละเอียด
ตั้งค่าคุกกี้ต่อไปนี้ในต้นทางการรายงาน
Set-Cookie: ar_debug=1; SameSite=None; Secure; Path=/; HttpOnly
เบราว์เซอร์จะตรวจหาคุกกี้นี้ทั้งในแหล่งที่มาและการลงทะเบียนทริกเกอร์ ระบบจะสร้างรายงานการแก้ไขข้อบกพร่องสำเร็จก็ต่อเมื่อมีคุกกี้ทั้งสองเวลา
โค้ดสาธิต: คุกกี้การแก้ไขข้อบกพร่อง
โปรดทราบว่าคุณเปิดใช้รายงานการแก้ไขข้อบกพร่องสำหรับเบราว์เซอร์ในโหมด B ได้ ซึ่งจะปิดใช้คุกกี้ของบุคคลที่สามเพื่ออำนวยความสะดวกในการทดสอบและเตรียมพร้อมสำหรับการเลิกใช้งานคุกกี้ของบุคคลที่สาม สำหรับเบราว์เซอร์ในโหมด B คุณไม่จำเป็นต้องตั้งค่าคุกกี้การแก้ไขข้อบกพร่องเพื่อเปิดใช้รายงานการแก้ไขข้อบกพร่อง ข้ามไปที่ขั้นตอนที่ 2 เพื่อตั้งค่าคีย์การแก้ไขข้อบกพร่อง สำหรับรายงานการแก้ไขข้อบกพร่องที่สำเร็จ
ขั้นตอนที่ 2: ตั้งค่าคีย์การแก้ไขข้อบกพร่อง
คีย์การแก้ไขข้อบกพร่องแต่ละรายการต้องเป็นจำนวนเต็มที่ไม่มีเครื่องหมาย 64 บิต ซึ่งอยู่ในรูปแบบสตริงฐาน 10 ทำให้คีย์การแก้ไขข้อบกพร่องแต่ละรายการเป็นรหัสที่ไม่ซ้ำกัน ระบบจะสร้างรายงานการแก้ปัญหาสำเร็จเมื่อตั้งค่าคีย์การแก้ไขข้อบกพร่องไว้เท่านั้น
- แมปคีย์การแก้ไขข้อบกพร่องฝั่งเซิร์ฟเวอร์กับข้อมูลเกี่ยวกับเวลาแหล่งที่มาเพิ่มเติมที่คุณคิดว่าเกี่ยวข้องกับการแก้ไขข้อบกพร่อง
- แมปคีย์การแก้ไขข้อบกพร่องฝั่งทริกเกอร์กับข้อมูลเวลาทริกเกอร์เพิ่มเติมที่คุณคิดว่าเกี่ยวข้องกับการแก้ไขข้อบกพร่อง
เช่น คุณอาจตั้งค่าคีย์การแก้ไขข้อบกพร่องดังต่อไปนี้
- รหัสคุกกี้ + การประทับเวลาของแหล่งที่มาเป็นคีย์การแก้ไขข้อบกพร่องของแหล่งที่มา (และเก็บการประทับเวลาเดียวกันไว้ในระบบที่ใช้คุกกี้)
- รหัสคุกกี้ + การประทับเวลาทริกเกอร์เป็นคีย์การแก้ไขข้อบกพร่องสำหรับทริกเกอร์ (และบันทึกการประทับเวลาเดียวกันในระบบที่ใช้คุกกี้)
คุณสามารถใช้ข้อมูล Conversion ที่อิงกับคุกกี้เพื่อค้นหารายงานการแก้ไขข้อบกพร่องที่เกี่ยวข้องหรือรายงานการระบุแหล่งที่มาได้ ดูข้อมูลเพิ่มเติมในส่วนที่ 3: ตำราอาหาร
ทำให้คีย์การแก้ไขข้อบกพร่องฝั่งแหล่งที่มาแตกต่างจาก 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"
}
รหัสสาธิต: คีย์การแก้ไขข้อบกพร่องต้นทาง โค้ดสาธิต: ทริกเกอร์คีย์การแก้ไขข้อบกพร่อง
ตั้งค่ารายงานการแก้ไขข้อบกพร่องที่สำเร็จ
โค้ดตัวอย่างในส่วนนี้จะสร้างรายงานการแก้ไขข้อบกพร่องที่สำเร็จสำหรับทั้งรายงานระดับเหตุการณ์และรายงานที่รวบรวมได้ รายงานระดับเหตุการณ์และรายงานที่รวบรวมได้จะใช้คีย์การแก้ไขข้อบกพร่องเดียวกัน
ขั้นตอนที่ 3: ตั้งค่าปลายทางเพื่อรวบรวมรายงานการแก้ไขข้อบกพร่องที่ทำสำเร็จ
ตั้งค่าปลายทางเพื่อรวบรวมรายงานการแก้ไขข้อบกพร่อง ปลายทางนี้ควรคล้ายกับปลายทางการระบุแหล่งที่มาหลัก โดยมีสตริง debug
เพิ่มเติมในเส้นทางดังนี้
- ปลายทางสำหรับรายงานการแก้ไขข้อบกพร่องที่สำเร็จระดับเหตุการณ์
https://adtech.example/.well-known/attribution-reporting/debug/report-event-attribution
- ปลายทางสำหรับรายงานแก้ไขข้อบกพร่องแบบรวบรวมข้อมูลได้ ได้แก่
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
ในเบราว์เซอร์ - ตรวจสอบให้แน่ใจว่าได้เลือกช่องทำเครื่องหมายแสดงรายงานการแก้ไขข้อบกพร่องทั้งในแท็บรายงานระดับเหตุการณ์และรายงานที่รวบรวมได้
- เปิดเว็บไซต์ที่คุณใช้ Attribution Reporting ทําตามขั้นตอนที่คุณใช้เพื่อสร้างรายงานการระบุแหล่งที่มา ขั้นตอนเดียวกันเหล่านี้จะสร้างรายงานการแก้ไขข้อบกพร่องสําเร็จ
- ใน
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
}
รหัสสาธิต: ส่วนหัวของทริกเกอร์
ขั้นตอนที่ 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: ยืนยันว่าการตั้งค่าจะสร้างรายงานการแก้ไขข้อบกพร่องแบบละเอียด
แม้ว่ารายงานการแก้ไขข้อบกพร่องแบบละเอียดจะมีหลายประเภท แต่ก็เพียงพอแล้วที่จะตรวจสอบการตั้งค่าการแก้ไขข้อบกพร่องแบบละเอียดโดยใช้รายงานการแก้ไขข้อบกพร่องแบบละเอียดเพียงประเภทเดียว หากมีการสร้างและรับรายงานการแก้ไขข้อบกพร่องแบบละเอียดทุกประเภทนี้ หมายความว่าระบบจะสร้างและรับรายงานการแก้ไขข้อบกพร่องแบบละเอียดทุกประเภทอย่างถูกต้อง เนื่องจากรายงานการแก้ไขข้อบกพร่องแบบละเอียดทั้งหมดใช้การกําหนดค่าเดียวกันและส่งไปยังปลายทางเดียวกัน
- เปิด
chrome://attribution-internals
ในเบราว์เซอร์ - เรียกให้แสดงการระบุแหล่งที่มา (Conversion) ในเว็บไซต์ที่ตั้งค่าการรายงานการระบุแหล่งที่มา
และเนื่องจากไม่มีการมีส่วนร่วมกับโฆษณา (การแสดงผลหรือการคลิก) ก่อนเกิด 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 ฉบับหากความล้มเหลวส่งผลต่อทั้งรายงานระดับเหตุการณ์และรายงานที่รวบรวมได้ โดยมีข้อยกเว้นคือ หากสาเหตุของความล้มเหลวเหมือนกันสำหรับรายงานระดับเหตุการณ์และรายงานที่รวบรวมได้ จะมีการสร้างรายงานแบบละเอียดเพียง 1 รายการ (เช่น
trigger-no-matching-source
)