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

ภาพรวมการรายงานการระบุแหล่งที่มาสําหรับอุปกรณ์เคลื่อนที่

อัปเดตล่าสุด

อัปเดตรายการการเปลี่ยนแปลงที่กําลังจะเกิดขึ้นและปัญหาที่ทราบ
เปิดตัวการกําหนดค่าระดับเหตุการณ์แบบยืดหยุ่นเวอร์ชัน Lite เพื่อใช้เป็นบริดจ์ไปยังการกําหนดค่าระดับเหตุการณ์แบบยืดหยุ่นเวอร์ชันเต็ม
ตั้งแต่เดือนกันยายน 2023 เป็นต้นไป registerWebSource, registerWebTrigger, registerAppSource และ registerAppTrigger ต้องใช้สตริงสำหรับช่องที่คาดหวังค่าตัวเลข (เช่น priority, source_event_id, debug_key, trigger_data, deduplication_key ฯลฯ)
ในไตรมาสที่ 4 ปี 2023 เราจะเพิ่มการรองรับ Google Cloud ใน Attribution Reporting API ของ Android เพื่อสร้างรายงานสรุปโดยใช้บริการรวบรวมข้อมูลใน Google Cloud โดยดูเวลาโดยละเอียดได้ที่ด้านล่าง ดูข้อมูลเพิ่มเติมเกี่ยวกับการตั้งค่าบริการรวบรวมข้อมูลด้วย Google Cloud ได้ในคู่มือการใช้งาน
ขีดจํากัดอัตราการรักษาความเป็นส่วนตัวใหม่สําหรับจํานวนปลายทางที่ไม่ซ้ำ
ฟังก์ชันการทํางานที่อัปเดตแล้วสําหรับตัวกรองทริกเกอร์กรอบเวลามองย้อนกลับจะพร้อมใช้งานในไตรมาสที่ 1 ปี 2024 ดูข้อมูลเพิ่มเติมได้ในหมายเหตุ

ภาพรวม

ปัจจุบัน การที่โซลูชันการระบุแหล่งที่มาและโซลูชันการวัดผลบนอุปกรณ์เคลื่อนที่จะพึ่งพาตัวระบุข้ามฝ่ายต่างๆ เช่น รหัสโฆษณา นั้นถือเป็นเรื่องปกติ Attribution Reporting API ได้รับการออกแบบมาเพื่อปรับปรุงความเป็นส่วนตัวของผู้ใช้โดยยกเลิกการพึ่งพาตัวระบุผู้ใช้ข้ามฝ่ายต่างๆ รวมถึงเพื่อรองรับ Use Case ที่สำคัญๆ สำหรับการวัดการระบุแหล่งที่มาและการวัด Conversion ในแอปและเว็บ

API นี้มีกลไกโครงสร้างต่อไปนี้ซึ่งนำเสนอเฟรมเวิร์กสำหรับการปรับปรุงความเป็นส่วนตัว ซึ่งจะอธิบายอย่างละเอียดในส่วนต่อๆ ไปในหน้านี้

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

กลไกข้างต้นจะจํากัดความสามารถในการลิงก์ข้อมูลประจำตัวของผู้ใช้ในแอปหรือโดเมนที่แตกต่างกัน 2 แอปหรือโดเมน

Attribution Reporting API รองรับกรณีการใช้งานต่อไปนี้

การรายงาน Conversion: ช่วยให้ผู้ลงโฆษณาวัดประสิทธิภาพของแคมเปญได้ด้วยการแสดงจํานวน Conversion (ทริกเกอร์) และมูลค่า Conversion (ทริกเกอร์) ในมิติข้อมูลต่างๆ เช่น ตามแคมเปญ กลุ่มโฆษณา และครีเอทีฟโฆษณา
การเพิ่มประสิทธิภาพ: แสดงรายงานระดับเหตุการณ์ที่รองรับการเพิ่มประสิทธิภาพการใช้จ่ายค่าโฆษณา โดยระบุข้อมูลการระบุแหล่งที่มาต่อการแสดงผลที่นําไปใช้ฝึกโมเดล ML ได้
การตรวจหากิจกรรมที่ไม่ถูกต้อง: ให้รายงานที่ใช้ในการตรวจหาและวิเคราะห์การเข้าชมที่ไม่ถูกต้องและการประพฤติมิชอบในโฆษณาได้

ในระดับสูง Attribution Reporting API ทํางานดังนี้ ซึ่งส่วนต่างๆ ของเอกสารนี้จะอธิบายอย่างละเอียด

เทคโนโลยีโฆษณาทําตามขั้นตอนการลงทะเบียนให้เสร็จสมบูรณ์เพื่อใช้ Attribution Reporting API
เทคโนโลยีโฆษณาจะลงทะเบียนแหล่งที่มาของการระบุแหล่งที่มา ซึ่งได้แก่ การคลิกหรือยอดดูโฆษณา กับ Attribution Reporting API
เทคโนโลยีโฆษณาจะลงทะเบียนทริกเกอร์ ซึ่งก็คือ Conversion ของผู้ใช้ในแอปหรือเว็บไซต์ของผู้ลงโฆษณา โดยใช้ Attribution Reporting API
Attribution Reporting API จะจับคู่ทริกเกอร์กับแหล่งที่มาของการระบุแหล่งที่มา ซึ่งเป็นการระบุแหล่งที่มาของ Conversion และส่งทริกเกอร์อย่างน้อย 1 รายการออกจากอุปกรณ์ผ่านรายงานระดับเหตุการณ์และที่รวบรวมได้ไปยังเทคโนโลยีโฆษณา

หมายเหตุ: ดูข้อมูลเพิ่มเติมเกี่ยวกับวิธีใช้การออกแบบนี้สําหรับ Use Case การระบุแหล่งที่มาแบบแอปต่อแอปได้ที่ส่วนการระบุแหล่งที่มาข้ามเครือข่ายในคู่มือนักพัฒนาซอฟต์แวร์ของ Attribution Reporting API หากต้องการดูวิธีติดตั้งใช้งานกรณีการใช้งานจากแอปไปยังเว็บหรือจากเว็บไปยังแอป โปรดอ่านข้อเสนอการออกแบบการวัดผลข้ามแอปและเว็บ

รับสิทธิ์เข้าถึง Attribution Reporting API

แพลตฟอร์มเทคโนโลยีโฆษณาต้องลงทะเบียนเพื่อเข้าถึง Attribution Reporting API ดูข้อมูลเพิ่มเติมที่หัวข้อลงทะเบียนบัญชี Privacy Sandbox

ลงทะเบียนแหล่งที่มาของการระบุแหล่งที่มา (คลิกหรือดู)

Attribution Reporting API เรียกการคลิกและยอดดูโฆษณาว่าแหล่งที่มาของการระบุแหล่งที่มา หากต้องการบันทึกการคลิกโฆษณาหรือการดูโฆษณา ให้โทรหา registerSource() API นี้คาดหวังว่าจะได้รับพารามิเตอร์ต่อไปนี้

URI แหล่งที่มาของการระบุแหล่งที่มา: แพลตฟอร์มจะส่งคำขอไปยัง URI นี้เพื่อดึงข้อมูลเมตาที่เชื่อมโยงกับแหล่งที่มาของการระบุแหล่งที่มา
เหตุการณ์อินพุต: ออบเจ็กต์ InputEvent (สําหรับเหตุการณ์การคลิก) หรือ null (สําหรับเหตุการณ์การดู)

เมื่อ API ส่งคําขอไปยัง URI แหล่งที่มาของการระบุแหล่งที่มา เทคโนโลยีโฆษณาควรตอบกลับด้วยข้อมูลเมตาแหล่งที่มาของการระบุแหล่งที่มาในส่วนหัว HTTP ใหม่Attribution-Reporting-Register-Source โดยมีช่องต่อไปนี้

รหัสเหตุการณ์แหล่งที่มา: ค่านี้แสดงข้อมูลระดับเหตุการณ์ที่เชื่อมโยงกับแหล่งที่มาของการระบุแหล่งที่มานี้ (การคลิกหรือดูโฆษณา) ต้องเป็นจำนวนเต็มแบบไม่ลงนาม 64 บิตที่จัดรูปแบบเป็นสตริง
ปลายทาง: ต้นทางที่มี eTLD+1 หรือชื่อแพ็กเกจแอปที่เหตุการณ์เรียกให้แสดงเกิดขึ้น
เวลาหมดอายุ (ไม่บังคับ): เวลาหมดอายุ (เป็นวินาที) สำหรับเวลาที่ควรลบแหล่งที่มาออกจากอุปกรณ์ ค่าเริ่มต้นคือ 30 วัน โดยมีค่าต่ำสุด 1 วัน และค่าสูงสุด 30 วัน ระบบจะปัดเศษเป็นวันที่ที่ใกล้ที่สุด อยู่ในรูปแบบจำนวนเต็มแบบไม่ระบุเครื่องหมาย 64 บิตหรือสตริงก็ได้
กรอบเวลาของรายงานเหตุการณ์ (ไม่บังคับ): ระยะเวลาเป็นวินาทีหลังจากการลงทะเบียนแหล่งที่มา ซึ่งระบบอาจสร้างรายงานเหตุการณ์สําหรับแหล่งที่มานี้ หากกรอบเวลาของรายงานเหตุการณ์ผ่านไปแล้ว แต่ยังไม่หมดอายุ ระบบจะยังคงจับคู่ทริกเกอร์กับแหล่งที่มาได้ แต่จะไม่มีการส่งรายงานเหตุการณ์สําหรับทริกเกอร์นั้น ต้องไม่มากกว่า "วันหมดอายุ" อาจมีการจัดรูปแบบเป็นจำนวนเต็มแบบไม่ระบุเครื่องหมาย 64 บิตหรือสตริงก็ได้
กรอบเวลารายงานที่รวบรวมได้ (ไม่บังคับ): ระยะเวลาเป็นวินาทีหลังจากการลงทะเบียนแหล่งที่มา ซึ่งระบบอาจสร้างรายงานที่รวบรวมได้สําหรับแหล่งที่มานี้ ต้องไม่มากกว่า "วันหมดอายุ" จัดรูปแบบเป็นจำนวนเต็มแบบไม่ลงนามหรือสตริง 64 บิตก็ได้
ลําดับความสําคัญของแหล่งที่มา (ไม่บังคับ): ใช้เพื่อเลือกแหล่งที่มาของการระบุแหล่งที่มาที่ควรเชื่อมโยงกับทริกเกอร์หนึ่งๆ ในกรณีที่มีการเชื่อมโยงแหล่งที่มาของการระบุแหล่งที่มาหลายแหล่งกับทริกเกอร์ ต้องเป็นจำนวนเต็มแบบมีเครื่องหมาย 64 บิตที่จัดรูปแบบเป็นสตริง

เมื่อได้รับทริกเกอร์ API จะค้นหาแหล่งที่มาของการระบุแหล่งที่มาที่ตรงกันซึ่งมีค่าลําดับความสําคัญของแหล่งที่มาสูงสุด และสร้างรายงาน แพลตฟอร์มเทคโนโลยีโฆษณาแต่ละแพลตฟอร์มสามารถกำหนดกลยุทธ์การจัดลําดับความสําคัญของตนเองได้ ดูรายละเอียดเพิ่มเติมเกี่ยวกับผลกระทบของลําดับความสําคัญต่อการระบุแหล่งที่มาได้ที่ส่วนตัวอย่างลําดับความสําคัญ

ค่าที่สูงขึ้นบ่งบอกถึงลําดับความสําคัญที่สูงขึ้น
กรอบเวลาการระบุแหล่งที่มาของการติดตั้งและหลังการติดตั้ง (ไม่บังคับ): ใช้เพื่อระบุแหล่งที่มาของเหตุการณ์หลังการติดตั้ง ซึ่งอธิบายไว้ภายหลังในหน้านี้
กรองข้อมูล (ไม่บังคับ): ใช้เพื่อกรองทริกเกอร์บางรายการ ซึ่งจะละเว้นทริกเกอร์เหล่านั้นอย่างมีประสิทธิภาพ ดูรายละเอียดเพิ่มเติมได้ที่ส่วนตัวกรองทริกเกอร์ในหน้านี้
คีย์การรวม (ไม่บังคับ): ระบุการแบ่งกลุ่มที่จะใช้กับรายงานที่รวมได้

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

คู่มือนักพัฒนาแอปมีตัวอย่างที่แสดงวิธียอมรับการลงทะเบียนแหล่งที่มา

ขั้นตอนต่อไปนี้แสดงเวิร์กโฟลว์ตัวอย่าง

SDK เทคโนโลยีโฆษณาเรียก API เพื่อเริ่มการลงทะเบียนแหล่งที่มาของการระบุแหล่งที่มา โดยระบุ URI ให้ API เรียกใช้
```
registerSource(
    Uri.parse("https://adtech.example/attribution_source?AD_TECH_PROVIDED_METADATA"),
    myClickEvent);
```
API จะส่งคําขอไปยัง https://adtech.example/attribution_source?AD_TECH_PROVIDED_METADATA โดยใช้ส่วนหัวอย่างใดอย่างหนึ่งต่อไปนี้
```

Attribution-Reporting-Source-Info: navigation


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

เซิร์ฟเวอร์ HTTPS ของเทคโนโลยีโฆษณานี้จะตอบกลับด้วยส่วนหัวที่มีข้อมูลต่อไปนี้

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

API จะส่งคำขอไปยัง URL แต่ละรายการที่ระบุใน Attribution-Reporting-Redirect ในตัวอย่างนี้ มีการกำหนด URL ของพาร์ทเนอร์เทคโนโลยีโฆษณา 2 รายการ ดังนั้น API จึงส่งคำขอ 1 รายการไปยัง https://adtechpartner1.example?their_ad_click_id=567 และอีก 1 รายการไปยัง https://adtechpartner2.example?their_ad_click_id=890
เซิร์ฟเวอร์ HTTPS ของเทคโนโลยีโฆษณานี้จะตอบกลับด้วยส่วนหัวที่มีข้อมูลต่อไปนี้
```
Attribution-Reporting-Register-Source: {
    "destination": "android-app://com.advertiser.example",
    "source_event_id": "789",
    "expiry": "120000",
    "priority": "2"
}
```
หมายเหตุ: การตอบกลับของเทคโนโลยีโฆษณาสามารถระบุข้อมูลเมตาอื่นในส่วนหัวAttribution-Reporting-Register-Source

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

ลงทะเบียนแหล่งที่มาของการระบุแหล่งที่มาจาก WebView

WebView รองรับกรณีการใช้งานที่แอปแสดงผลโฆษณาภายใน WebView การดำเนินการนี้จัดการโดย WebView ที่เรียก registerSource() โดยตรงเป็นคำขอเบื้องหลัง การเรียกใช้นี้จะเชื่อมโยงแหล่งที่มาของการระบุแหล่งที่มากับแอปแทนที่จะเป็นต้นทางระดับบนสุด ระบบยังรองรับการลงทะเบียนแหล่งที่มาจากเนื้อหาเว็บที่ฝังภายในบริบทของเบราว์เซอร์ด้วย โดยทั้งผู้เรียก API และแอปจะต้องปรับการตั้งค่าเพื่อดำเนินการดังกล่าว ดูวิธีการสําหรับผู้เรียก API ได้ที่ลงทะเบียนแหล่งที่มาของการระบุแหล่งที่มาและทริกเกอร์จาก WebView และดูวิธีการสําหรับแอปได้ที่การลงทะเบียนแหล่งที่มาของการระบุแหล่งที่มาและทริกเกอร์จาก WebView

เนื่องจากเทคโนโลยีโฆษณาใช้โค้ดทั่วไปในเว็บและ WebView WebView จึงทําตามการเปลี่ยนเส้นทาง HTTP 302 และส่งการลงทะเบียนที่ถูกต้องไปยังแพลตฟอร์ม เราไม่มีแผนที่จะรองรับส่วนหัว Attribution-Reporting-Redirect สำหรับสถานการณ์นี้ แต่โปรดติดต่อเราหากคุณมีกรณีการใช้งานที่ได้รับผลกระทบ

ลงทะเบียนทริกเกอร์ (Conversion)

แพลตฟอร์มเทคโนโลยีโฆษณาสามารถลงทะเบียนทริกเกอร์ได้ ซึ่งก็คือ Conversion เช่น การติดตั้งหรือเหตุการณ์หลังการติดตั้ง โดยใช้เมธอด registerTrigger()

เมธอด registerTrigger() ต้องการพารามิเตอร์ Trigger URI API จะส่งคําขอไปยัง URI นี้เพื่อดึงข้อมูลเมตาที่เชื่อมโยงกับทริกเกอร์

API จะติดตามการเปลี่ยนเส้นทาง การตอบกลับจากเซิร์ฟเวอร์เทคโนโลยีโฆษณาควรมีส่วนหัว HTTP ที่ชื่อ Attribution-Reporting-Register-Trigger ซึ่งแสดงข้อมูลเกี่ยวกับทริกเกอร์ที่ลงทะเบียนอย่างน้อย 1 รายการ เนื้อหาของส่วนหัวควรเข้ารหัส JSON และประกอบด้วยฟิลด์ต่อไปนี้

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

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

เทคโนโลยีโฆษณาหลายรายการสามารถลงทะเบียนเหตุการณ์ทริกเกอร์เดียวกันได้โดยใช้การเปลี่ยนเส้นทางในช่อง Attribution-Reporting-Redirect หรือการเรียกใช้เมธอด registerTrigger() หลายครั้ง เราขอแนะนําให้ใช้ช่องคีย์การกรองข้อมูลที่ซ้ำกันออกเพื่อหลีกเลี่ยงการรวมทริกเกอร์ที่ซ้ำกันในรายงานในกรณีที่เทคโนโลยีโฆษณาเดียวกันให้คําตอบหลายรายการสําหรับเหตุการณ์ทริกเกอร์เดียวกัน ดูข้อมูลเพิ่มเติมเกี่ยวกับวิธีและเวลาที่ควรใช้คีย์การกรองข้อมูลที่ซ้ำกันออก

คู่มือสําหรับนักพัฒนาซอฟต์แวร์มีตัวอย่างที่แสดงวิธียอมรับการลงทะเบียนทริกเกอร์

ขั้นตอนต่อไปนี้แสดงเวิร์กโฟลว์ตัวอย่าง

SDK เทคโนโลยีโฆษณาจะเรียก API เพื่อเริ่มการลงทะเบียนทริกเกอร์โดยใช้ URI ที่ลงทะเบียนไว้ล่วงหน้า ดูข้อมูลเพิ่มเติมที่ลงทะเบียนบัญชี Privacy Sandbox
```
registerTrigger(
    Uri.parse("https://adtech.example/attribution_trigger?AD_TECH_PROVIDED_METADATA"));
```
API ส่งคําขอไปยัง https://adtech.example/attribution_trigger?AD_TECH_PROVIDED_METADATA
เซิร์ฟเวอร์ HTTPS ของเทคโนโลยีโฆษณานี้จะตอบกลับด้วยส่วนหัวที่มีข้อมูลต่อไปนี้
```
Attribution-Reporting-Register-Trigger: {
    "event_trigger_data": [{
    "trigger_data": "1122",
    // This returns 010 for click-through conversions (CTCs) and 0 for
    // view-through conversions (VTCs) in reports
    "priority": "3",
    "deduplication_key": "3344"
    }],
}
Attribution-Reporting-Redirect: https://adtechpartner.example?app_install=567
```
หมายเหตุ: มีเพียงเทคโนโลยีโฆษณาที่เริ่มการเรียก API เท่านั้นที่จะระบุพาร์ทเนอร์ใน Attribution-Reporting-Redirect ได้
API จะส่งคำขอไปยัง URL แต่ละรายการที่ระบุใน Attribution-Reporting-Redirect ในตัวอย่างนี้ มีการกำหนด URL เพียงรายการเดียว ดังนั้น API จึงส่งคำขอไปยัง https://adtechpartner.example?app_install=567
เซิร์ฟเวอร์ HTTPS ของเทคโนโลยีโฆษณานี้จะตอบกลับด้วยส่วนหัวที่มีข้อมูลต่อไปนี้
```
Attribution-Reporting-Register-Trigger: {
"event_trigger_data":[{
  "trigger_data": "5566",
  "priority": "3",
  "deduplication_key": "3344"
}]
}
```
ระบบจะลงทะเบียนทริกเกอร์ 2 รายการตามคําขอในขั้นตอนก่อนหน้า

ความสามารถในการระบุแหล่งที่มา

ส่วนต่อไปนี้จะอธิบายวิธีที่ Attribution Reporting API จับคู่ทริกเกอร์ Conversion กับแหล่งที่มาของการระบุแหล่งที่มา

ใช้อัลกอริทึมการระบุแหล่งที่มาตามลําดับความสําคัญ

Attribution Reporting API ใช้อัลกอริทึมการระบุแหล่งที่มาตามลําดับความสําคัญเพื่อจับคู่ทริกเกอร์ (Conversion) กับแหล่งที่มาของการระบุแหล่งที่มา

พารามิเตอร์ลําดับความสําคัญมีวิธีปรับแต่งการระบุแหล่งที่มาของทริกเกอร์ ดังนี้

คุณสามารถระบุแหล่งที่มาของทริกเกอร์ให้กับเหตุการณ์โฆษณาบางรายการได้ เช่น คุณอาจเลือกเน้นที่การคลิกมากกว่าการดู หรือเน้นที่เหตุการณ์จากแคมเปญบางรายการ
คุณสามารถกําหนดค่าแหล่งที่มาของการระบุแหล่งที่มาและทริกเกอร์เพื่อให้มีแนวโน้มที่จะได้รับรายงานที่สําคัญกับคุณมากกว่าหากถึงขีดจํากัดอัตรา เช่น คุณอาจต้องการตรวจสอบว่า Conversion ที่เสนอราคาได้หรือ Conversion มูลค่าสูงมีแนวโน้มที่จะปรากฏในรายงานเหล่านี้มากกว่า

ในกรณีที่เทคโนโลยีโฆษณาหลายรายการลงทะเบียนแหล่งที่มาของการระบุแหล่งที่มาตามที่อธิบายไว้ภายหลังในหน้านี้ การระบุแหล่งที่มานี้จะเกิดขึ้นแยกกันสําหรับเทคโนโลยีโฆษณาแต่ละรายการ สําหรับเทคโนโลยีโฆษณาแต่ละรายการ แหล่งที่มาของการระบุแหล่งที่มาที่มีลําดับความสําคัญสูงสุดจะได้รับการระบุแหล่งที่มาของเหตุการณ์ทริกเกอร์ หากมีแหล่งที่มาของการระบุแหล่งที่มาหลายแหล่งที่มีลําดับความสําคัญเดียวกัน API จะเลือกแหล่งที่มาของการระบุแหล่งที่มาที่ลงทะเบียนล่าสุด ระบบจะทิ้งแหล่งที่มาของการระบุแหล่งที่มาอื่นๆ ที่ไม่ได้เลือกและแหล่งที่มาเหล่านั้นจะไม่มีสิทธิ์ได้รับการระบุแหล่งที่มาของทริกเกอร์ในอนาคตอีก

ตัวกรองทริกเกอร์

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

กรองทริกเกอร์บางรายการโดยเลือกเพื่อละเว้นอย่างมีประสิทธิภาพ
เลือกข้อมูลทริกเกอร์สําหรับรายงานระดับเหตุการณ์ตามข้อมูลต้นทาง
เลือกยกเว้นทริกเกอร์จากรายงานระดับเหตุการณ์

หากต้องการกรองทริกเกอร์แบบเลือก เทคโนโลยีโฆษณาจะระบุข้อมูลตัวกรองได้ ซึ่งประกอบด้วยคีย์และค่า ในระหว่างการลงทะเบียนแหล่งที่มาและทริกเกอร์ หากระบุคีย์เดียวกันสําหรับทั้งแหล่งที่มาและทริกเกอร์ ระบบจะไม่สนใจทริกเกอร์หากจุดตัดว่างเปล่า ตัวอย่างเช่น แหล่งที่มาอาจระบุ "product": ["1234"] โดยที่ product คือคีย์ตัวกรองและ 1234 คือค่า หากตั้งค่าตัวกรองทริกเกอร์เป็น "product": ["1111"] ระบบจะไม่สนใจทริกเกอร์ หากไม่มีคีย์ตัวกรองทริกเกอร์ที่ตรงกับ product ระบบจะไม่สนใจตัวกรอง

อีกสถานการณ์หนึ่งที่แพลตฟอร์มเทคโนโลยีโฆษณาอาจต้องการกรองทริกเกอร์แบบเลือกคือการบังคับให้กรอบเวลาหมดอายุสั้นลง ในการลงทะเบียนทริกเกอร์ เทคโนโลยีโฆษณาจะระบุกรอบเวลามองย้อนกลับ (เป็นวินาที) นับจากวันที่เกิด Conversion ได้ เช่น กรอบเวลามองย้อนกลับ 7 วันจะกําหนดเป็น "_lookback_window": 604800 // 7d

หากต้องการตัดสินใจว่าตัวกรองตรงกันหรือไม่ API จะตรวจสอบกรอบเวลามองย้อนกลับก่อน หากมี ระยะเวลานับตั้งแต่มีการบันทึกแหล่งที่มาต้องน้อยกว่าหรือเท่ากับระยะเวลาของกรอบเวลามองย้อนกลับ

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

แพลตฟอร์มเทคโนโลยีโฆษณายังเลือกข้อมูลทริกเกอร์ตามข้อมูลเหตุการณ์แหล่งที่มาได้ด้วย ตัวอย่างเช่น source_type จะสร้างขึ้นโดยอัตโนมัติโดย API เป็น navigation หรือ event ในระหว่างการลงทะเบียนทริกเกอร์ คุณสามารถตั้งค่า trigger_data เป็นค่าหนึ่งสำหรับ "source_type": ["navigation"] และเป็นค่าอื่นสำหรับ "source_type": ["event"]

ระบบจะยกเว้นทริกเกอร์จากรายงานระดับเหตุการณ์ในกรณีต่อไปนี้

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

การระบุแหล่งที่มาหลังการติดตั้ง

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

API รองรับกรณีการใช้งานนี้โดยอนุญาตให้นักเทคโนโลยีโฆษณาตั้งค่าระยะเวลาการระบุแหล่งที่มาหลังการติดตั้ง

เมื่อลงทะเบียนแหล่งที่มาของการระบุแหล่งที่มา ให้ระบุกรอบเวลาการระบุแหล่งที่มาของการติดตั้งที่คาดว่าจะมีการติดตั้ง (โดยทั่วไปคือ 2-7 วัน โดยยอมรับช่วง 1-30 วัน) ระบุกรอบเวลานี้เป็นจำนวนวินาที
เมื่อลงทะเบียนแหล่งที่มาของการระบุแหล่งที่มา ให้ระบุกรอบเวลาการระบุแหล่งที่มาหลังการติดตั้งแบบผูกขาด ซึ่งเหตุการณ์ทริกเกอร์หลังการติดตั้งควรเชื่อมโยงกับแหล่งที่มาของการระบุแหล่งที่มาที่ทําให้เกิดการติดตั้ง (โดยทั่วไปคือ 7-30 วัน โดยช่วงที่เรายอมรับคือ 0-30 วัน) ระบุกรอบเวลานี้เป็นจํานวนวินาที
Attribution Reporting API จะตรวจสอบเมื่อเกิดการติดตั้งแอปขึ้น และระบุแหล่งที่มาของการติดตั้งเป็นการภายในไปยังแหล่งที่มาของการระบุแหล่งที่มาตามลําดับความสําคัญ อย่างไรก็ตาม ระบบจะไม่ส่งการติดตั้งไปยังเทคโนโลยีโฆษณาและจะไม่นับรวมในขีดจํากัดอัตราของแพลตฟอร์มที่เกี่ยวข้อง
การตรวจสอบการติดตั้งแอปใช้ได้กับแอปที่ดาวน์โหลดมาทั้งหมด
ทริกเกอร์ในอนาคตที่เกิดขึ้นภายในกรอบเวลาการระบุแหล่งที่มาหลังการติดตั้งจะมาจากแหล่งที่มาเดียวกันกับการระบุแหล่งที่มาของการติดตั้งที่ตรวจสอบแล้ว ตราบใดที่แหล่งที่มาของการระบุแหล่งที่มานั้นมีสิทธิ์

ในอนาคต เราอาจขยายการออกแบบเพื่อรองรับรูปแบบการระบุแหล่งที่มาขั้นสูงมากขึ้น

ตารางต่อไปนี้แสดงตัวอย่างวิธีที่เทคโนโลยีโฆษณาอาจใช้การระบุแหล่งที่มาหลังการติดตั้ง สมมติว่าเครือข่ายเทคโนโลยีโฆษณาเดียวกันเป็นผู้บันทึกแหล่งที่มาและทริกเกอร์การระบุแหล่งที่มาทั้งหมด และลําดับความสําคัญทั้งหมดเหมือนกัน

กิจกรรม	วันที่เกิดเหตุการณ์	หมายเหตุ
คลิก 1	1	`install_attribution_window` ตั้งค่าเป็น `172800` (2 วัน) และ `post_install_exclusivity_window` ตั้งค่าเป็น `864000` (10 วัน)
การติดตั้งที่ได้รับการยืนยัน	2	API จะระบุแหล่งที่มาของการติดตั้งที่ยืนยันแล้วภายใน แต่การติดตั้งเหล่านั้นจะไม่ถือว่าเป็นทริกเกอร์ ดังนั้น ระบบจะไม่ส่งรายงานในขณะนี้
ทริกเกอร์ 1 (เปิดครั้งแรก)	2	ทริกเกอร์แรกที่เทคโนโลยีโฆษณาบันทึกไว้ ในตัวอย่างนี้ แสดงถึงการเปิดครั้งแรก แต่อาจเป็นทริกเกอร์ประเภทใดก็ได้ มีการระบุแหล่งที่มาเป็นคลิก 1 ครั้ง (ตรงกับการระบุแหล่งที่มาของการติดตั้งที่ยืนยันแล้ว)
คลิก 2	4	ใช้ค่าเดียวกันสําหรับ `install_attribution_window` และ `post_install_exclusivity_window` กับคลิก 1
ทริกเกอร์ 2 (หลังการติดตั้ง)	5	ทริกเกอร์ที่ 2 ที่เทคโนโลยีโฆษณาบันทึกไว้ ในตัวอย่างนี้ แสดงถึง Conversion หลังการติดตั้ง เช่น การซื้อ มีการระบุแหล่งที่มาเป็นคลิก 1 ครั้ง (ตรงกับการระบุแหล่งที่มาของการติดตั้งที่ยืนยันแล้ว) ระบบจะทิ้งคลิกที่ 2 และไม่ให้มีสิทธิ์รับการระบุแหล่งที่มาในอนาคต

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

หากการติดตั้งที่ยืนยันแล้วไม่เกิดขึ้นภายในจํานวนวันที่ install_attribution_window ระบุไว้ ระบบจะไม่ใช้การระบุแหล่งที่มาหลังการติดตั้ง
เทคโนโลยีโฆษณาจะไม่บันทึกการติดตั้งที่ยืนยันแล้วและจะไม่ส่งในรายงาน และไม่นับรวมในขีดจํากัดอัตราของเทคโนโลยีโฆษณา ระบบจะใช้การติดตั้งที่ยืนยันแล้วเพื่อระบุแหล่งที่มาของการระบุแหล่งที่มาที่ได้รับเครดิตสำหรับการติดตั้งเท่านั้น
ในตัวอย่างจากตารางก่อนหน้า ทริกเกอร์ 1 และทริกเกอร์ 2 แสดงถึงการเปิดครั้งแรกและ Conversion หลังการติดตั้งตามลําดับ แต่แพลตฟอร์มเทคโนโลยีโฆษณาจะลงทะเบียนทริกเกอร์ประเภทใดก็ได้ กล่าวคือ ทริกเกอร์แรกไม่จำเป็นต้องเป็นทริกเกอร์เปิดแรก
หากมีการลงทะเบียนทริกเกอร์เพิ่มเติมหลังจากที่ post_install_exclusivity_window หมดอายุแล้ว คลิกที่ 1 จะยังคงมีสิทธิ์ได้รับการระบุแหล่งที่มา ในกรณีที่ยังไม่ได้หมดอายุและยังไม่ถึงขีดจํากัดอัตรา
- คลิก 1 อาจยังคงสูญหายหรือถูกทิ้งหากมีการลงทะเบียนแหล่งที่มาของการระบุแหล่งที่มาที่มีลําดับความสําคัญสูงกว่า
หากมีการถอนการติดตั้งแอปของผู้ลงโฆษณาและติดตั้งอีกครั้ง ระบบจะนับการติดตั้งอีกครั้งเป็นการยืนยันการติดตั้งใหม่
หากคลิกที่ 1 เป็นเหตุการณ์การดูแทน ทั้งทริกเกอร์ "การเปิดครั้งแรก" และหลังการติดตั้งจะยังคงมีการระบุแหล่งที่มาเป็นเหตุการณ์ดังกล่าว API จํากัดการระบุแหล่งที่มาไว้ที่ทริกเกอร์ 1 รายการต่อยอดดู ยกเว้นในกรณีที่มีการระบุแหล่งที่มาหลังการติดตั้ง ซึ่งอนุญาตให้ใช้ทริกเกอร์ได้สูงสุด 2 รายการต่อยอดดู ในกรณีการระบุแหล่งที่มาหลังการติดตั้งใช้งาน เทคโนโลยีโฆษณาอาจได้รับกรอบเวลาการรายงาน 2 กรอบเวลาที่แตกต่างกัน (เมื่อครบ 2 วันหรือเมื่อแหล่งที่มาหมดอายุ)

รองรับชุดค่าผสมทั้งหมดของเส้นทางทริกเกอร์ที่อิงตามแอปและเว็บ

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

App-to-app: ผู้ใช้เห็นโฆษณาในแอป จากนั้นทํา Conversion ในแอปนั้นหรือแอปอื่นที่ติดตั้งไว้
App-to-web: ผู้ใช้เห็นโฆษณาในแอป แล้วทํา Conversion ในเบราว์เซอร์บนอุปกรณ์เคลื่อนที่หรือเบราว์เซอร์ในแอป
Web-to-app: ผู้ใช้เห็นโฆษณาในเบราว์เซอร์บนอุปกรณ์เคลื่อนที่หรือเบราว์เซอร์ของแอป แล้วทํา Conversion ในแอป
Web-to-web: ผู้ใช้เห็นโฆษณาในเบราว์เซอร์ในอุปกรณ์เคลื่อนที่หรือเบราว์เซอร์ของแอป จากนั้นทํา Conversion ในเบราว์เซอร์เดียวกันหรือเบราว์เซอร์อื่นในอุปกรณ์เครื่องเดียวกัน

เราอนุญาตให้เว็บเบราว์เซอร์รองรับฟีเจอร์ใหม่ๆ ที่แสดงในเว็บ เช่น ฟังก์ชันการทำงานที่คล้ายกับ Attribution Reporting API ของ Privacy Sandbox สําหรับเว็บ ซึ่งสามารถเรียกใช้ Android API เพื่อเปิดใช้การระบุแหล่งที่มาในแอปและเว็บ

ดูข้อมูลเกี่ยวกับการเปลี่ยนแปลงที่เทคโนโลยีโฆษณาและแอปต้องทำเพื่อรองรับเส้นทางทริกเกอร์สําหรับการวัดผลข้ามแอปและเว็บ

จัดลําดับความสําคัญของทริกเกอร์หลายรายการสําหรับแหล่งที่มาของการระบุแหล่งที่มาแหล่งเดียว

แหล่งที่มาของการระบุแหล่งที่มาแหล่งเดียวอาจทริกเกอร์ได้หลายรายการ เช่น ขั้นตอนการซื้ออาจเกี่ยวข้องกับทริกเกอร์ "การติดตั้งแอป" ทริกเกอร์ "เพิ่มลงในรถเข็น" อย่างน้อย 1 รายการ และทริกเกอร์ "การซื้อ" ทริกเกอร์แต่ละรายการจะมาจากแหล่งที่มาของการระบุแหล่งที่มาอย่างน้อย 1 แหล่งตามอัลกอริทึมการระบุแหล่งที่มาแบบให้ความสําคัญกับแหล่งที่มาที่อธิบายไว้ภายหลังในหน้านี้

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

ในกรณีที่ทริกเกอร์มีมากกว่าขีดจํากัดเหล่านี้ คุณควรใช้ตรรกะการจัดลําดับความสําคัญเพื่อเรียกคืนทริกเกอร์ที่มีคุณค่ามากที่สุด ตัวอย่างเช่น นักพัฒนาเทคโนโลยีโฆษณาอาจต้องการให้ความสําคัญกับทริกเกอร์ "purchase" มากกว่าทริกเกอร์ "add-to-cart"

คุณสามารถตั้งค่าช่องลําดับความสําคัญแยกต่างหากในทริกเกอร์เพื่อรองรับตรรกะนี้ และระบบจะเลือกทริกเกอร์ที่มีลําดับความสําคัญสูงสุดก่อนที่จะใช้ขีดจํากัดภายในกรอบเวลาการรายงานที่ระบุ

อนุญาตให้เทคโนโลยีโฆษณาหลายรายการลงทะเบียนแหล่งที่มาหรือทริกเกอร์การระบุแหล่งที่มา

การที่เทคโนโลยีโฆษณามากกว่า 1 รายการได้รับรายงานการระบุแหล่งที่มานั้นเป็นเรื่องปกติ ซึ่งโดยทั่วไปแล้วเพื่อทำการกรองข้อมูลที่ซ้ำกันออกข้ามเครือข่าย ดังนั้น API จึงอนุญาตให้เทคโนโลยีโฆษณาหลายรายการลงทะเบียนแหล่งที่มาหรือการทริกเกอร์การระบุแหล่งที่มาเดียวกันได้ เทคโนโลยีโฆษณาต้องลงทะเบียนทั้งแหล่งที่มาของการระบุแหล่งที่มาและทริกเกอร์เพื่อรับการรายงานผล Conversion จาก API และการระบุแหล่งที่มาจะดำเนินการกับแหล่งที่มาของการระบุแหล่งที่มาและทริกเกอร์ที่เทคโนโลยีโฆษณาได้ลงทะเบียนไว้กับ API

ผู้ลงโฆษณาที่ต้องการใช้บุคคลที่สามเพื่อกรองข้อมูลที่ซ้ำกันออกข้ามเครือข่ายจะยังทําเช่นนั้นได้โดยใช้เทคนิคที่คล้ายกับต่อไปนี้

การตั้งค่าเซิร์ฟเวอร์ในบ้านเพื่อลงทะเบียนและรับรายงานจาก API
ใช้พาร์ทเนอร์การวัดผลบนอุปกรณ์เคลื่อนที่ที่มีอยู่ต่อไป

แหล่งที่มาของการระบุแหล่งที่มา

การเปลี่ยนเส้นทางแหล่งที่มาของการระบุแหล่งที่มาที่รองรับในวิธีการ registerSource() มีดังนี้

เทคโนโลยีโฆษณาที่เรียกใช้เมธอด registerSource() สามารถระบุช่อง Attribution-Reporting-Redirect เพิ่มเติมในการตอบกลับ ซึ่งแสดงชุด URL เปลี่ยนเส้นทางของเทคโนโลยีโฆษณาของพาร์ทเนอร์
จากนั้น API จะเรียกใช้ URL เปลี่ยนเส้นทางเพื่อให้เทคโนโลยีโฆษณาของพาร์ทเนอร์ลงทะเบียนแหล่งที่มาของการระบุแหล่งที่มาได้

คุณระบุ URL เทคโนโลยีโฆษณาของพาร์ทเนอร์ได้หลายรายการในช่อง Attribution-Reporting-Redirect แต่เทคโนโลยีโฆษณาของพาร์ทเนอร์จะระบุช่อง Attribution-Reporting-Redirect ของตนเองไม่ได้

นอกจากนี้ API ยังอนุญาตให้เทคโนโลยีโฆษณาต่างๆ โทรหาแต่ละรายการ registerSource()

ทริกเกอร์

สําหรับการลงทะเบียนทริกเกอร์ ระบบจะรองรับบุคคลที่สามในลักษณะที่คล้ายกัน นั่นคือ เทคโนโลยีโฆษณาจะใช้ช่อง Attribution-Reporting-Redirect เพิ่มเติม หรือเรียกใช้เมธอด registerTrigger() แต่ละรายการก็ได้

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

จัดการทริกเกอร์ที่ซ้ำกัน

เทคโนโลยีโฆษณาอาจลงทะเบียนทริกเกอร์เดียวกันกับ API หลายครั้ง สถานการณ์ต่างๆ ประกอบด้วย

ผู้ใช้ดําเนินการเดียวกัน (ทริกเกอร์) หลายครั้ง ตัวอย่างเช่น ผู้ใช้เรียกดูผลิตภัณฑ์เดียวกันหลายครั้งในกรอบเวลาการรายงานเดียวกัน
แอปของผู้ลงโฆษณาใช้ SDK หลายรายการสําหรับการวัด Conversion ซึ่งทั้งหมดเปลี่ยนเส้นทางไปยังเทคโนโลยีโฆษณาเดียวกัน เช่น แอปของผู้ลงโฆษณาใช้พาร์ทเนอร์การวัดผล 2 ราย ได้แก่ MMP #1 และ MMP #2 MMP ทั้ง 2 รายการเปลี่ยนเส้นทางไปยังเทคโนโลยีโฆษณา #3 เมื่อทริกเกอร์เกิดขึ้น MMP ทั้ง 2 รายจะลงทะเบียนทริกเกอร์นั้นกับ Attribution Reporting API จากนั้น AdTech #3 จะได้รับการเปลี่ยนเส้นทางแยกกัน 2 รายการ รายการหนึ่งจาก MMP #1 และอีกรายการจาก MMP #2 สําหรับทริกเกอร์เดียวกัน

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

วิธีที่แนะนำ: คีย์การกรองข้อมูลที่ซ้ำกันออก

วิธีที่เราแนะนําคือให้แอปของผู้ลงโฆษณาส่งคีย์การกรองข้อมูลที่ซ้ำกันออกที่ไม่ซ้ำกันไปยังเทคโนโลยีโฆษณาหรือ SDK ที่ใช้วัด Conversion เมื่อเกิด Conversion แอปจะส่งคีย์การกรองข้อมูลที่ซ้ำกันออกไปยังเทคโนโลยีโฆษณาหรือ SDK จากนั้นเทคโนโลยีโฆษณาหรือ SDK ดังกล่าวจะส่งคีย์การกรองข้อมูลที่ซ้ำกันออกไปยังการเปลี่ยนเส้นทางโดยใช้พารามิเตอร์ใน URL ที่ระบุใน Attribution-Reporting-Redirect

ผู้เชี่ยวชาญด้านเทคโนโลยีโฆษณาสามารถเลือกลงทะเบียนเฉพาะทริกเกอร์แรกด้วยคีย์การกรองข้อมูลที่ซ้ำกันออกที่กำหนด หรือเลือกลงทะเบียนทริกเกอร์หลายรายการหรือทุกรายการก็ได้ ผู้เชี่ยวชาญด้านเทคโนโลยีโฆษณาจะระบุ deduplication_key ได้เมื่อลงทะเบียนทริกเกอร์ที่ซ้ำกัน

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

วิธีการอื่น: เทคโนโลยีโฆษณาตกลงกันเรื่องประเภททริกเกอร์ต่อผู้ลงโฆษณา

ในกรณีที่เทคโนโลยีโฆษณาไม่ต้องการใช้คีย์การกรองข้อมูลที่ซ้ำกันออก หรือในกรณีที่แอปของผู้ลงโฆษณาส่งคีย์การกรองข้อมูลที่ซ้ำกันออกไม่ได้ ก็มีตัวเลือกอื่นให้ เทคโนโลยีโฆษณาทั้งหมดที่วัด Conversion สำหรับผู้ลงโฆษณารายหนึ่งๆ ต้องทํางานร่วมกันเพื่อกําหนดประเภททริกเกอร์ที่แตกต่างกันสําหรับผู้ลงโฆษณาแต่ละราย

เทคโนโลยีโฆษณาที่เริ่มการเรียกใช้การลงทะเบียนทริกเกอร์ เช่น SDK จะใส่พารามิเตอร์ใน URL ที่ระบุใน Attribution-Reporting-Redirect เช่น duplicate_trigger_id พารามิเตอร์ duplicate_trigger_id นั้นอาจมีข้อมูล เช่น ชื่อ SDK และประเภททริกเกอร์สําหรับผู้ลงโฆษณารายนั้น จากนั้นเทคโนโลยีโฆษณาจะส่งชุดย่อยของทริกเกอร์ที่ซ้ำกันเหล่านี้ไปยังรายงานระดับเหตุการณ์ได้ เทคโนโลยีโฆษณายังใส่ duplicate_trigger_id นี้ไว้ในคีย์การรวบรวมข้อมูลได้ด้วย

ตัวอย่างการระบุแหล่งที่มาข้ามเครือข่าย

ในตัวอย่างที่อธิบายในส่วนนี้ ผู้ลงโฆษณาใช้แพลตฟอร์มเทคโนโลยีโฆษณาที่แสดงโฆษณา 2 แพลตฟอร์ม (เทคโนโลยีโฆษณา ก และเทคโนโลยีโฆษณา ข) และพาร์ทเนอร์การวัดผล 1 ราย (MMP)

ในการเริ่มต้นใช้งาน AdTech A, AdTech B และ MMP แต่ละรายต้องลงทะเบียนให้เสร็จสมบูรณ์เพื่อใช้ Attribution Reporting API ดูข้อมูลเพิ่มเติมที่ลงทะเบียนบัญชี Privacy Sandbox

รายการต่อไปนี้แสดงชุดการกระทําของผู้ใช้สมมติที่เกิดขึ้นห่างกัน 1 วัน และวิธีที่ Attribution Reporting API จัดการการกระทําเหล่านั้นที่เกี่ยวข้องกับ Ad Tech A, Ad Tech B และ MMP

วันที่ 1: ผู้ใช้คลิกโฆษณาที่แสดงโดยเทคโนโลยีโฆษณา ก

เทคโนโลยีโฆษณา ก โทรหา registerSource() ด้วย URI ของตน API จะส่งคําขอไปยัง URI และระบบจะบันทึกการคลิกพร้อมกับข้อมูลเมตาจากการตอบกลับของเซิร์ฟเวอร์ AdTech A

เทคโนโลยีโฆษณา ก. ยังมี URI ของ MMP ในAttribution-Reporting-Redirect ส่วนหัวด้วย API จะส่งคําขอไปยัง URI ของ MMP และระบบจะบันทึกการคลิกพร้อมข้อมูลเมตาจากการตอบกลับของเซิร์ฟเวอร์ MMP

วันที่ 2: ผู้ใช้คลิกโฆษณาที่แสดงโดย Ad Tech B

เทคโนโลยีโฆษณา ข. เรียก registerSource() ด้วย URI ของตน API จะส่งคําขอไปยัง URI และระบบจะบันทึกการคลิกพร้อมกับข้อมูลเมตาจากการตอบกลับของเซิร์ฟเวอร์ AdTech B

เช่นเดียวกับ Ad Tech A เทคโนโลยีโฆษณา ข. ยังได้ใส่ URI ของ MMP ไว้ในส่วนหัว Attribution-Reporting-Redirect ด้วย API จะส่งคําขอไปยัง URI ของ MMP และระบบจะบันทึกการคลิกพร้อมกับข้อมูลเมตาจากการตอบกลับของเซิร์ฟเวอร์ MMP

วันที่ 3: ผู้ใช้ดูโฆษณาที่แสดงโดยเทคโนโลยีโฆษณา ก

API จะตอบกลับในลักษณะเดียวกับที่ตอบกลับในวันแรก ยกเว้นมีการบันทึกมุมมองสําหรับ Ad Tech A และ MMP

วันที่ 4: ผู้ใช้ติดตั้งแอปซึ่งใช้ MMP ในการวัด Conversion

MMP โทรหา registerTrigger() ด้วย URI API จะส่งคําขอไปยัง URL และระบบจะบันทึก Conversion ด้วยข้อมูลเมตาจากการตอบกลับของเซิร์ฟเวอร์ MMP

MMP ยังมี URI สําหรับเทคโนโลยีโฆษณา ก และเทคโนโลยีโฆษณา ข ในส่วนหัวAttribution-Reporting-Redirect ด้วย API จะส่งคําขอไปยังเซิร์ฟเวอร์ของ Ad Tech A และ Ad Tech B และระบบจะบันทึก Conversion ตามความเหมาะสมด้วยข้อมูลเมตาจากการตอบกลับของเซิร์ฟเวอร์

แผนภาพต่อไปนี้แสดงกระบวนการที่อธิบายไว้ในรายการก่อนหน้า

ตัวอย่างวิธีที่ Attribution Reporting API ตอบสนองต่อชุดการดําเนินการของผู้ใช้

การระบุแหล่งที่มาทํางานดังนี้

AdTech กําหนดลําดับความสําคัญของการคลิกให้สูงกว่ายอดดู จึงได้รับการติดตั้งที่มาจากคลิกในวันที่ 1
เทคโนโลยีโฆษณา ข. ได้รับการระบุแหล่งที่มาของการติดตั้งในวันที่ 2
MMP ตั้งค่าลําดับความสําคัญของคลิกให้สูงกว่าการดู และได้รับการติดตั้งที่มาจากคลิกในวันที่ 2 คลิกของวันที่ 2 เป็นเหตุการณ์โฆษณาล่าสุดที่มีลำดับความสำคัญสูงสุด

การระบุแหล่งที่มาข้ามเครือข่ายโดยไม่มีการเปลี่ยนเส้นทาง

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

ขั้นตอนการดําเนินการระดับสูง

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

การจดทะเบียนแหล่งที่มา

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

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

การลงทะเบียนทริกเกอร์

ในการลงทะเบียนทริกเกอร์ เทคโนโลยีโฆษณาการวัดผลจะเลือกชิ้นส่วนคีย์ฝั่งแหล่งที่มาที่จะใช้กับชิ้นส่วนคีย์ทริกเกอร์แต่ละรายการ รวมถึงชิ้นส่วนที่แชร์โดยเทคโนโลยีโฆษณาที่แสดง

นอกจากนี้ เทคโนโลยีโฆษณาการวัดผลยังต้องระบุตรรกะการระบุแหล่งที่มาตามลำดับขั้นโดยใช้การเรียก API การกําหนดค่าการระบุแหล่งที่มาใหม่ด้วย ในการกำหนดค่านี้ เทคโนโลยีโฆษณาจะระบุลําดับความสําคัญของแหล่งที่มา การหมดอายุ และตัวกรองสําหรับแหล่งที่มาที่ตนไม่มีสิทธิ์เข้าถึงได้ (เช่น แหล่งที่มาที่ไม่ได้ใช้การเปลี่ยนเส้นทาง)

การระบุแหล่งที่มา

Attribution Reporting API จะทําการระบุแหล่งที่มาที่ให้ความสําคัญกับการทํางานครั้งล่าสุดสําหรับเทคโนโลยีโฆษณาการวัดผลตามการกําหนดค่าการระบุแหล่งที่มา คีย์ที่แชร์ และแหล่งที่มาที่ลงทะเบียนไว้ เช่น

ผู้ใช้คลิกโฆษณาที่แสดงโดยเทคโนโลยีโฆษณา A, B, C และ D จากนั้นผู้ใช้ได้ติดตั้งแอปของผู้ลงโฆษณา ซึ่งใช้พาร์ทเนอร์เทคโนโลยีโฆษณาเพื่อวัดผล (MMP)
เทคโนโลยีโฆษณา ก. จะเปลี่ยนเส้นทางแหล่งที่มาไปยัง MMP
เทคโนโลยีโฆษณา ข. และ ค. ไม่ได้เปลี่ยนเส้นทาง แต่แชร์คีย์การรวบรวมข้อมูล
เทคโนโลยีโฆษณา ค. ไม่ได้เปลี่ยนเส้นทางหรือแชร์คีย์การรวบรวมข้อมูล

MMP จะลงทะเบียนแหล่งที่มาจากเทคโนโลยีโฆษณา ก และกำหนดการกำหนดค่าการระบุแหล่งที่มาซึ่งรวมเทคโนโลยีโฆษณา ข และเทคโนโลยีโฆษณา ค

การระบุแหล่งที่มาสําหรับ MMP ประกอบด้วยรายการต่อไปนี้

เทคโนโลยีโฆษณา ก เนื่องจาก MMP ลงทะเบียนแหล่งที่มาจากการเปลี่ยนเส้นทางของเทคโนโลยีโฆษณาดังกล่าว
เทคโนโลยีโฆษณา ข เนื่องจากเทคโนโลยีโฆษณา ข แชร์คีย์และ MMP รวมไว้ในการกำหนดค่าการระบุแหล่งที่มา

การระบุแหล่งที่มาของ MMP จะไม่รวมข้อมูลต่อไปนี้

เทคโนโลยีโฆษณา ค. เนื่องจาก MMP ไม่ได้รวมไว้ในการกำหนดค่าการระบุแหล่งที่มา
เทคโนโลยีโฆษณา ค. เนื่องจากไม่ได้เปลี่ยนเส้นทางหรือแชร์คีย์การรวบรวมข้อมูล

การแก้ไขข้อบกพร่อง

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

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

การวัดผลจากแอปหนึ่งไปยังอีกแอปหนึ่งที่อนุญาตรหัสโฆษณา
การวัดผลจากแอปไปยังเว็บที่อนุญาต AdId และจับคู่ทั้งแหล่งที่มาของแอปและทริกเกอร์ของเว็บ
การวัดผลจากเว็บหนึ่งไปยังอีกเว็บหนึ่ง (ในแอปเบราว์เซอร์เดียวกัน) เมื่อ ar_debug` แสดงอยู่ในทั้งแหล่งที่มาและทริกเกอร์

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

การค้นพบคีย์มีจุดประสงค์เพื่อปรับปรุงวิธีที่เทคโนโลยีโฆษณา (มักเป็น MMP) ใช้การกําหนดค่าการระบุแหล่งที่มาเพื่อวัตถุประสงค์ในการระบุแหล่งที่มาข้ามเครือข่ายเมื่อเทคโนโลยีโฆษณาที่แสดงผลอย่างน้อย 1 รายการใช้คีย์การรวมข้อมูลร่วมกัน (ตามที่อธิบายไว้ในการระบุแหล่งที่มาข้ามเครือข่ายโดยไม่มีการเปลี่ยนเส้นทางด้านบน)

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

รายการคีย์ที่เป็นไปได้ทั้งหมดมีขนาดใหญ่เกินไป
- เครือข่ายโฆษณาที่แสดงโฆษณากําลังดําเนินการริเริ่มการได้ผู้ใช้ใหม่ที่ซับซ้อน ซึ่งประกอบด้วยแคมเปญ 20 แคมเปญ โดยแต่ละแคมเปญมีกลุ่มโฆษณา 10 กลุ่ม และแต่ละกลุ่มโฆษณามีครีเอทีฟโฆษณา 5 รายการที่รีเฟรชทุกสัปดาห์ตามประสิทธิภาพ
รายการคีย์ที่เป็นไปได้ทั้งหมดที่ไม่รู้จักมีดังนี้
- เครือข่ายโฆษณาที่แสดงโฆษณาจะแสดงโฆษณาในแอปบนอุปกรณ์เคลื่อนที่หลายแอปที่ไม่ทราบรายการรหัสแอปของผู้เผยแพร่โฆษณาทั้งหมดเมื่อเปิดตัวแคมเปญ
- ผู้ลงโฆษณาทํางานกับเครือข่ายโฆษณาที่แสดงหลายเครือข่ายซึ่งไม่ได้เปลี่ยนเส้นทางไปยัง MMP ในการลงทะเบียนแหล่งที่มา เครือข่ายโฆษณาที่แสดงแต่ละเครือข่ายมีโครงสร้างและค่าคีย์ที่แตกต่างกัน ซึ่งอาจไม่แชร์กับ MMP ล่วงหน้า

การเปิดตัวการค้นพบคีย์จะทําสิ่งต่อไปนี้

บริการรวมข้อมูลไม่จําเป็นต้องระบุคีย์การรวมข้อมูลทั้งหมดที่เป็นไปได้อีกต่อไป
MMP สามารถสร้างชุดคีย์ว่าง (หรือว่างบางส่วน) และตั้งค่าเกณฑ์ได้โดยไม่ต้องระบุรายการคีย์ที่เป็นไปได้ทั้งหมด เพื่อให้เฉพาะคีย์ (ที่ไม่ได้ประกาศไว้ล่วงหน้า) ที่มีค่าเกินเกณฑ์เท่านั้นที่รวมอยู่ในเอาต์พุต
MMP จะได้รับรายงานสรุปที่มีค่าที่มีสัญญาณรบกวนสำหรับคีย์ที่มีค่าที่ส่งผลสูงกว่าเกณฑ์ที่ตั้งไว้ รายงานนี้ยังอาจรวมคำค้นหาที่ไม่มีข้อมูลผู้ใช้จริงที่เกี่ยวข้องและมีความผันผวนสูง
MMP ใช้ช่อง x_network_bit_mapping ในการลงทะเบียนทริกเกอร์เพื่อระบุว่าเทคโนโลยีโฆษณาใดสอดคล้องกับคีย์ใด
จากนั้น MMP สามารถติดต่อเทคโนโลยีโฆษณาที่แสดงที่เหมาะสมเพื่อทำความเข้าใจค่าในคีย์แหล่งที่มา

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

การเปลี่ยนเส้นทางแบบสร้อยดอกเดซี่

การให้ส่วนหัว Attribution-Reporting-Redirect หลายรายการในแหล่งที่มาหรือการตอบกลับเซิร์ฟเวอร์ HTTPS ของทริกเกอร์การลงทะเบียนจะช่วยให้เทคโนโลยีโฆษณาสามารถใช้ Attribution Reporting API เพื่อดำเนินการกับแหล่งที่มาหลายแหล่งและทริกเกอร์การลงทะเบียนด้วยการเรียก API การลงทะเบียนเพียงครั้งเดียว

ในการตอบกลับของเซิร์ฟเวอร์ เทคโนโลยีโฆษณายังอาจรวมส่วนหัว Location (การเปลี่ยนเส้นทาง 302) รายการเดียวที่มี URL ซึ่งจะนำไปสู่การลงทะเบียนอื่นได้สูงสุดตามขีดจํากัดที่กำหนด

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

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

ดูข้อมูลการวัดผลในรายงานการระบุแหล่งที่มา

Attribution Reporting API เปิดใช้รายงานประเภทต่อไปนี้ ซึ่งจะอธิบายอย่างละเอียดในภายหลังในหน้านี้

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

รายงานทั้ง 2 ประเภทนี้ช่วยเสริมกันและใช้ได้พร้อมกัน

รายงานระดับเหตุการณ์

หลังจากมีการระบุแหล่งที่มาของการระบุแหล่งที่มาของทริกเกอร์แล้ว ระบบจะสร้างและจัดเก็บรายงานระดับเหตุการณ์ไว้ในอุปกรณ์จนกว่าจะส่งกลับไปยัง URL การรายงานผล Conversion ของเทคโนโลยีโฆษณาแต่ละรายการได้ในช่วงกรอบเวลาการส่งรายงาน ซึ่งจะอธิบายไว้อย่างละเอียดในหน้านี้

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

รายงานระดับเหตุการณ์มีข้อมูลต่อไปนี้

ปลายทาง: ชื่อแพ็กเกจแอปของผู้ลงโฆษณาหรือ eTLD+1 ที่ทริกเกอร์เกิดขึ้น
รหัสแหล่งที่มาของการระบุแหล่งที่มา: รหัสแหล่งที่มาของการระบุแหล่งที่มาเดียวกันกับที่ใช้สำหรับการลงทะเบียนแหล่งที่มาของการระบุแหล่งที่มา
ประเภททริกเกอร์: ข้อมูลทริกเกอร์ความแม่นยำต่ำ 1 หรือ 3 บิต โดยขึ้นอยู่กับประเภทแหล่งที่มาของการระบุแหล่งที่มา

กลไกการรักษาความเป็นส่วนตัวที่ใช้กับรายงานทั้งหมด

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

จํากัดจํานวนเทคโนโลยีโฆษณา

จำนวนเทคโนโลยีโฆษณาที่ลงทะเบียนหรือรับรายงานจาก API ได้มีขีดจํากัด โดยข้อเสนอปัจจุบันมีดังนี้

เทคโนโลยีโฆษณา 100 รายการที่มีแหล่งที่มาของการระบุแหล่งที่มาต่อ {source app, destination app, 30 days, device}
เทคโนโลยีโฆษณา 10 รายการที่มีทริกเกอร์ที่มีการระบุแหล่งที่มาต่อ {source app, destination app, 30 days, device}
เทคโนโลยีโฆษณา 20 รายการสามารถลงทะเบียนแหล่งที่มาหรือทริกเกอร์การระบุแหล่งที่มารายการเดียวได้ (ผ่าน Attribution-Reporting-Redirect)

ขีดจํากัดของจํานวนปลายทางที่ไม่ซ้ำกัน

ขีดจํากัดเหล่านี้ทําให้ชุดเทคโนโลยีโฆษณาดำเนินการร่วมกันได้ยากโดยการค้นหาแอปจํานวนมากเพื่อทำความเข้าใจพฤติกรรมการใช้งานแอปของผู้ใช้รายหนึ่งๆ

API รองรับปลายทางที่ไม่ซ้ำกันไม่เกิน 200 รายการต่อแอปแหล่งที่มาต่อนาทีในแหล่งที่มาที่ลงทะเบียนทั้งหมดในเทคโนโลยีโฆษณาทั้งหมด
สําหรับแหล่งที่มาที่ลงทะเบียนทั้งหมด สําหรับเทคโนโลยีโฆษณาเดียว API จะรองรับปลายทางที่ไม่ซ้ำกันไม่เกิน 50 รายการต่อแอปแหล่งที่มาต่อนาที ขีดจํากัดนี้ป้องกันไม่ให้เทคโนโลยีโฆษณาหนึ่งใช้งบประมาณทั้งหมดจากขีดจํากัดอัตราที่กล่าวถึงก่อนหน้านี้

แหล่งที่มาที่หมดอายุจะไม่นับรวมในขีดจํากัดอัตรา

ต้นทางการรายงาน 1 รายการต่อแอปแหล่งที่มาต่อวัน

แพลตฟอร์มเทคโนโลยีโฆษณาหนึ่งๆ สามารถใช้แหล่งที่มาของการรายงานเพียงแหล่งเดียวในการลงทะเบียนแหล่งที่มาในแอปของผู้เผยแพร่โฆษณาสําหรับอุปกรณ์หนึ่งๆ ในวันเดียวกัน การจํากัดอัตรานี้จะช่วยป้องกันไม่ให้เทคโนโลยีโฆษณาใช้แหล่งที่มาของการรายงานหลายแห่งเพื่อเข้าถึงงบประมาณความเป็นส่วนตัวเพิ่มเติม

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

ต้นทางการรายงาน 1 ของเทคโนโลยีโฆษณา ก ลงทะเบียนแหล่งที่มาในแอป ข
12 ชั่วโมงต่อมา แหล่งที่มาของการรายงาน 2 ของเทคโนโลยีโฆษณา ก. พยายามจดทะเบียนแหล่งที่มาในแอป ข.

แหล่งที่มาที่ 2 สําหรับแหล่งที่มาของการรายงาน 2 ของ AdTech A จะถูกปฏิเสธโดย API แหล่งที่มา 2 ของการรายงานของ AdTech A จะลงทะเบียนแหล่งที่มาในอุปกรณ์เครื่องเดียวกันบนแอป B ไม่สําเร็จจนกว่าจะถึงวันถัดไปตาม

ระยะเวลาพักและขีดจำกัดอัตรา

API จะจำกัดปริมาณข้อมูลทั้งหมดที่ส่งในระยะเวลาหนึ่งๆ ให้กับผู้ใช้เพื่อจำกัดการเปิดเผยข้อมูลระบุตัวตนของผู้ใช้ระหว่างคู่ {source, destination}

ข้อเสนอปัจจุบันคือจํากัดเทคโนโลยีโฆษณาแต่ละรายการให้มีทริกเกอร์ที่มีการระบุแหล่งที่มาได้ 100 รายการต่อ {source app, destination app, 30 days, device}

จํานวนปลายทางที่ไม่ซ้ำกัน

API จะจํากัดจํานวนปลายทางที่เทคโนโลยีโฆษณาจะพยายามวัดได้ ยิ่งการจำกัดต่ำลงเท่าใด เทคโนโลยีโฆษณาก็ยิ่งใช้ API เพื่อพยายามวัดกิจกรรมการท่องเว็บของผู้ใช้ที่ไม่ได้เชื่อมโยงกับการแสดงโฆษณาได้ยากขึ้นเท่านั้น

ข้อเสนอปัจจุบันคือจำกัดเทคโนโลยีโฆษณาแต่ละรายการให้มีปลายทางที่แตกต่างกัน 100 รายการซึ่งมีแหล่งที่มาที่ยังไม่หมดอายุต่อแอปแหล่งที่มา

กลไกการรักษาความเป็นส่วนตัวที่ใช้กับรายงานระดับเหตุการณ์

ข้อมูลทริกเกอร์มีความถูกต้องแบบจํากัด

API มี 1 บิตสําหรับทริกเกอร์การดูผ่าน และ 3 บิตสําหรับทริกเกอร์การคลิกผ่าน แหล่งที่มาของการระบุแหล่งที่มาจะยังคงรองรับข้อมูลเมตาแบบ 64 บิตเต็มรูปแบบต่อไป

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

เฟรมเวิร์กสำหรับข้อผิดพลาดเกี่ยวกับ Differential Privacy

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

ระบบจะใช้สัญญาณรบกวนกับการพิจารณาว่ามีการรายงานเหตุการณ์แหล่งที่มาของการระบุแหล่งที่มาอย่างตรงไปตรงมาหรือไม่ แหล่งที่มาของการระบุแหล่งที่มาได้รับการบันทึกไว้ในอุปกรณ์โดยมีแนวโน้ม $ 1-p $ ที่แหล่งที่มาของการระบุแหล่งที่มาได้รับการบันทึกตามปกติ และแนวโน้ม $ p $ ที่อุปกรณ์จะสุ่มเลือกสถานะเอาต์พุตที่เป็นไปได้ทั้งหมดของ API (รวมถึงไม่รายงานอะไรเลย หรือรายงานหลายรายการปลอม)

การตอบกลับแบบสุ่ม k คืออัลกอริทึมที่มีความเป็นส่วนตัวแบบต่างอัตราการเพิ่ม epsilon หากสมการต่อไปนี้เป็นจริง

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

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

p=0.24% สําหรับแหล่งที่มาของการนําทาง
p=0.00025% สําหรับแหล่งที่มาของเหตุการณ์

ขีดจํากัดของทริกเกอร์ (Conversion) ที่พร้อมใช้งาน

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

ทริกเกอร์ 1-2 รายการสําหรับแหล่งที่มาของการระบุแหล่งที่มาของยอดดูโฆษณา (ทริกเกอร์ 2 รายการใช้ได้เฉพาะในกรณีการระบุแหล่งที่มาหลังการติดตั้งเท่านั้น)
ทริกเกอร์ 3 รายการสําหรับแหล่งที่มาของการระบุแหล่งที่มาของโฆษณาแบบคลิก

หมายเหตุ: ข้อมูลนี้อธิบายลักษณะการทํางานเริ่มต้นของ API สําหรับจํานวนการระบุแหล่งที่มาต่อแหล่งที่มาโดยใช้การรายงานระดับเหตุการณ์ เราได้เปิดตัวการรายงานระดับเหตุการณ์ที่ยืดหยุ่นในเดือนตุลาคม 2023 ซึ่งช่วยให้นักเทคโนโลยีโฆษณากําหนดค่ามิติข้อมูลการรายงานนี้ตามสิ่งที่เหมาะกับกรณีการใช้งานของตนมากที่สุดได้แล้ว

กรอบเวลาเฉพาะสําหรับการส่งรายงาน (ลักษณะการทํางานเริ่มต้น)

ระบบจะส่งรายงานระดับเหตุการณ์สําหรับแหล่งที่มาของการระบุแหล่งที่มาของยอดดูโฆษณา 1 ชั่วโมงหลังจากที่แหล่งที่มาหมดอายุ คุณกําหนดค่าวันที่หมดอายุนี้ได้ แต่ต้องไม่น้อยกว่า 1 วันหรือมากกว่า 30 วัน หากทริกเกอร์ 2 รายการมีการระบุแหล่งที่มาของการระบุแหล่งที่มาของการแสดงโฆษณา (ผ่านการระบุแหล่งที่มาหลังการติดตั้ง) ระบบจะส่งรายงานระดับเหตุการณ์เป็นช่วงๆ ตามกรอบเวลาการรายงานที่ระบุไว้ดังนี้

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

2 วัน: อุปกรณ์จะรวบรวมทริกเกอร์ทั้งหมดที่เกิดขึ้นไม่เกิน 2 วันหลังจากลงทะเบียนแหล่งที่มาของการระบุแหล่งที่มา ระบบจะส่งรายงานภายใน 2 วันและ 1 ชั่วโมงหลังจากลงทะเบียนแหล่งที่มาของการระบุแหล่งที่มา
7 วัน: อุปกรณ์จะรวบรวมทริกเกอร์ทั้งหมดที่เกิดขึ้นนานกว่า 2 วันแต่ไม่เกิน 7 วันหลังจากที่บันทึกแหล่งที่มาของการระบุแหล่งที่มา ระบบจะส่งรายงานหลังจากลงทะเบียนแหล่งที่มาของการระบุแหล่งที่มา 7 วันและ 1 ชั่วโมง
ระยะเวลาที่กำหนดเอง ซึ่งกำหนดโดยแอตทริบิวต์ "expiry" ของแหล่งข้อมูลการระบุที่มา ระบบจะส่งรายงาน 1 ชั่วโมงหลังจากเวลาหมดอายุที่ระบุ ค่านี้ต้องไม่น้อยกว่า 1 วันหรือมากกว่า 30 วัน

การกําหนดค่าระดับเหตุการณ์ที่ยืดหยุ่น

เราขอแนะนําให้นักเทคโนโลยีโฆษณาเริ่มใช้การกําหนดค่าเริ่มต้นสําหรับการรายงานระดับเหตุการณ์เมื่อเริ่มการทดสอบยูทิลิตี แต่อาจไม่เหมาะสําหรับกรณีการใช้งานบางกรณี Attribution Reporting API จะรองรับการกำหนดค่าที่ไม่บังคับและยืดหยุ่นมากขึ้นเพื่อให้เทคโนโลยีโฆษณามีการควบคุมโครงสร้างของรายงานระดับเหตุการณ์ได้มากขึ้นและใช้ประโยชน์จากข้อมูลได้สูงสุด

เราจะเปิดตัวความยืดหยุ่นเพิ่มเติมนี้ใน Attribution Reporting API โดยแบ่งเป็น 2 ระยะ ดังนี้

ระยะที่ 1: การกําหนดค่าระดับกิจกรรมแบบยืดหยุ่นแบบ Lite
- เวอร์ชันนี้มีฟีเจอร์บางส่วนของฟีเจอร์ทั้งหมด และสามารถใช้งานแยกจากระยะที่ 2 ได้
ระยะที่ 2: การกําหนดค่าระดับเหตุการณ์แบบยืดหยุ่นเวอร์ชันเต็ม

ระยะที่ 1 (ระดับเหตุการณ์แบบยืดหยุ่นแบบ Lite) สามารถใช้เพื่อดำเนินการต่อไปนี้

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

ระยะที่ 2 (ระดับเหตุการณ์แบบยืดหยุ่นทั้งหมด) ใช้เพื่อทําความสามารถทั้งหมดในระยะที่ 1 และดำเนินการต่อไปนี้ได้

เปลี่ยน Cardinality ของข้อมูลทริกเกอร์ในรายงาน
ลดปริมาณสัญญาณรบกวนทั้งหมดโดยการลด Cardinality ของข้อมูลทริกเกอร์

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

นอกจากการตั้งค่าระดับสัญญาณรบกวนแบบไดนามิกตามการกำหนดค่าที่เทคโนโลยีโฆษณาเลือกแล้ว เราจะจำกัดพารามิเตอร์บางอย่างเพื่อหลีกเลี่ยงค่าใช้จ่ายในการประมวลผลที่สูงและการกำหนดค่าที่มีสถานะเอาต์พุตมากเกินไป (ซึ่งจะทำให้สัญญาณรบกวนเพิ่มขึ้นอย่างมาก) ต่อไปนี้เป็นตัวอย่างชุดข้อจำกัด เราขอแนะนำให้แสดงความคิดเห็นเกี่ยวกับ [การออกแบบที่เสนอ][50] ดังนี้

รายงานทั้งหมดสูงสุด 20 รายการทั่วโลกและต่อ trigger_data
กรอบเวลาการรายงานสูงสุด 5 กรอบเวลาต่อ trigger_data
Cardinality ของข้อมูลทริกเกอร์สูงสุด 32 รายการ (ใช้ไม่ได้กับระยะที่ 1: ระดับเหตุการณ์แบบยืดหยุ่นใน Lite)

เมื่อเทคโนโลยีโฆษณาเริ่มใช้ฟีเจอร์นี้ โปรดทราบว่าการใช้ค่าสุดขั้วอาจส่งผลให้มีสัญญาณรบกวนจำนวนมาก หรือการลงทะเบียนไม่สำเร็จหากไม่เป็นไปตามระดับความเป็นส่วนตัว

รายงานที่รวมได้

ก่อนใช้รายงานแบบรวม คุณต้องตั้งค่าบัญชีระบบคลาวด์และเริ่มรับรายงานแบบรวม

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

รายงานสําหรับมูลค่าทริกเกอร์ เช่น รายได้
การจัดการทริกเกอร์ประเภทอื่นๆ

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

การออกแบบโดยรวมของวิธีที่ Attribution Reporting API เตรียมและส่งรายงานที่รวบรวมได้ดังที่แสดงในแผนภาพมีดังนี้

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

กระบวนการที่ Attribution Reporting API ใช้เพื่อเตรียมและส่งรายงานที่รวบรวมได้

รายงานที่รวบรวมได้มีข้อมูลต่อไปนี้ที่เกี่ยวข้องกับแหล่งที่มาของการระบุแหล่งที่มา

ปลายทาง: ชื่อแพ็กเกจของแอปหรือ URL ของเว็บ eTLD+1 ที่ทริกเกอร์เกิดขึ้น
วันที่: วันที่เกิดเหตุการณ์ที่แหล่งที่มาของการระบุแหล่งที่มาแสดง
เพย์โหลด: ค่าทริกเกอร์ที่รวบรวมเป็นคู่คีย์/ค่าที่เข้ารหัส ซึ่งใช้ในบริการรวบรวมข้อมูลที่เชื่อถือได้เพื่อคํานวณการรวบรวมข้อมูล

บริการรวมข้อมูล

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

บริการเหล่านี้จัดการโดยบุคคลอื่น ซึ่งจะอธิบายอย่างละเอียดในหน้านี้

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

บริการรวมข้อมูล

แพลตฟอร์มเทคโนโลยีโฆษณาต้องติดตั้งใช้งานบริการรวบรวมข้อมูลล่วงหน้าโดยอิงตามไบนารีที่ Google ให้มา

บริการรวบรวมข้อมูลนี้ทำงานในสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE) ที่โฮสต์ในระบบคลาวด์ TEE มีข้อดีด้านความปลอดภัยดังต่อไปนี้

ซึ่งช่วยให้มั่นใจได้ว่าโค้ดที่ทำงานใน TEE นั้นเป็นไบนารีที่ Google นำเสนอ เว้นแต่ว่าเงื่อนไขนี้จะเป็นไปตามข้อกำหนด บริการรวบรวมข้อมูลจะไม่สามารถเข้าถึงคีย์การถอดรหัสที่จําเป็นต่อการใช้งาน
ซึ่งจะมอบความปลอดภัยให้กับกระบวนการที่ทำงานอยู่ โดยแยกกระบวนการดังกล่าวจากการเฝ้าติดตามหรือการแทรกแซงจากภายนอก

ประโยชน์ด้านความปลอดภัยเหล่านี้ทําให้บริการรวบรวมข้อมูลทําการดําเนินการที่มีความละเอียดอ่อนได้ปลอดภัยยิ่งขึ้น เช่น การเข้าถึงข้อมูลที่เข้ารหัส

ดูข้อมูลเพิ่มเติมเกี่ยวกับการออกแบบ เวิร์กโฟลว์ และข้อควรพิจารณาด้านความปลอดภัยของบริการรวบรวมข้อมูลได้ที่เอกสารบริการรวบรวมข้อมูลใน GitHub

บริการจัดการคีย์

บริการนี้จะยืนยันว่าบริการรวบรวมข้อมูลทํางานอยู่ในรูปแบบไบนารีที่ได้รับอนุมัติ จากนั้นจะให้บริการรวบรวมข้อมูลในเทคโนโลยีโฆษณาด้วยคีย์การถอดรหัสที่ถูกต้องสําหรับข้อมูลทริกเกอร์

การบัญชีรายงานที่รวบรวมได้

บริการนี้จะติดตามความถี่ที่บริการรวบรวมข้อมูลของเทคโนโลยีโฆษณาเข้าถึงทริกเกอร์ที่เฉพาะเจาะจง ซึ่งอาจมีคีย์การรวบรวมข้อมูลหลายรายการ และจำกัดการเข้าถึงจำนวนการถอดรหัสที่เหมาะสม โปรดดูรายละเอียดในข้อเสนอการออกแบบบริการรวบรวมข้อมูลสําหรับ Attribution Reporting API

Aggregatable Reports API

API สําหรับการสร้างการมีส่วนร่วมในรายงานที่รวบรวมได้จะใช้ API พื้นฐานเดียวกับเมื่อลงทะเบียนแหล่งที่มาของการระบุแหล่งที่มาสําหรับรายงานระดับเหตุการณ์ ส่วนต่อไปนี้จะอธิบายส่วนขยายของ API

ลงทะเบียนข้อมูลต้นฉบับที่รวบรวมได้

เมื่อ API ส่งคําขอไปยัง URI แหล่งที่มาของการระบุแหล่งที่มา เทคโนโลยีโฆษณาจะลงทะเบียนรายการคีย์การรวมข้อมูลชื่อ histogram_contributions ได้โดยตอบกลับด้วยช่องใหม่ชื่อ aggregation_keys ในส่วนหัว HTTP Attribution-Reporting-Register-Source โดยที่คีย์คือ key_name และค่าคือ key_piece

(คีย์) ชื่อคีย์: สตริงสำหรับชื่อคีย์ ใช้เป็นตัวคีย์การรวมเพื่อรวมเข้ากับคีย์ฝั่งทริกเกอร์เพื่อสร้างคีย์สุดท้าย
(ค่า) ชิ้นส่วนคีย์: ค่าบิตสตริงสําหรับคีย์

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

คีย์สุดท้ายถูกจํากัดไว้ที่ไม่เกิน 128 บิต โดยระบบจะตัดคีย์ที่ยาวกว่านี้ ซึ่งหมายความว่าสตริงฐาน 16 ใน JSON ควรมีความยาวไม่เกิน 32 หลัก

ดูข้อมูลเพิ่มเติมเกี่ยวกับโครงสร้างของคีย์การรวมและวิธีกําหนดค่าคีย์การรวม

ในตัวอย่างต่อไปนี้ เทคโนโลยีโฆษณาใช้ API เพื่อรวบรวมข้อมูลต่อไปนี้

จํานวน Conversion แบบรวมที่ระดับแคมเปญ
มูลค่าการซื้อรวมในระดับภูมิศาสตร์

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

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

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

ลงทะเบียนทริกเกอร์ที่รวบรวมข้อมูลได้

การลงทะเบียนทริกเกอร์จะมีช่องเพิ่มเติม 2 ช่อง

ช่องแรกใช้เพื่อลงทะเบียนรายการคีย์รวมในฝั่งทริกเกอร์ เทคโนโลยีโฆษณาควรตอบกลับด้วยช่อง aggregatable_trigger_data ในส่วนหัว HTTP Attribution-Reporting-Register-Trigger โดยมีช่องต่อไปนี้สําหรับคีย์รวมแต่ละรายการในรายการ

ชิ้นส่วนคีย์: ค่าบิตสตริงสำหรับคีย์
คีย์แหล่งที่มา: รายการสตริงที่มีชื่อคีย์ฝั่งแหล่งที่มาของการระบุแหล่งที่มา ซึ่งควรรวมกับคีย์ทริกเกอร์เพื่อสร้างคีย์สุดท้าย

ช่องที่ 2 ใช้เพื่อลงทะเบียนรายการค่าที่ควรมีส่วนช่วยในการระบุคีย์แต่ละรายการ เทคโนโลยีโฆษณาควรตอบกลับด้วยช่อง aggregatable_values ในหัว HTTP Attribution-Reporting-Register-Trigger ช่องที่ 2 ใช้เพื่อลงทะเบียนรายการค่าที่ควรมีส่วนทำให้เกิดแต่ละคีย์ ซึ่งอาจเป็นจำนวนเต็มในช่วง $ [1, 2^{16}] $

ทริกเกอร์แต่ละรายการจะมีส่วนร่วมในรายงานที่รวบรวมได้หลายรายการ จํานวนการมีส่วนร่วมทั้งหมดในเหตุการณ์แหล่งที่มาหนึ่งๆ จะจํากัดด้วยพารามิเตอร์ $ L1 $ ซึ่งเป็นผลรวมสูงสุดของการมีส่วนร่วม (ค่า) ในทุกคีย์รวมสําหรับแหล่งที่มาหนึ่งๆ $ L1 $ หมายถึงความไวหรือค่าปกติ L1 ของส่วนที่เป็นฮิสโตแกรมต่อเหตุการณ์ต้นทาง การมีส่วนร่วมที่เกินขีดจำกัดเหล่านี้จะทำให้การมีส่วนร่วมในอนาคตลดลงโดยอัตโนมัติ ข้อเสนอเริ่มต้นคือการตั้งค่า $ L1 $ เป็น $ 2^{16} $ (65536)

ระบบจะปรับขนาดสัญญาณรบกวนในบริการการรวมตามสัดส่วนกับพารามิเตอร์นี้ ด้วยเหตุนี้ เราขอแนะนําให้ปรับขนาดค่าที่รายงานสําหรับคีย์การรวมข้อมูลหนึ่งๆ ให้เหมาะสม โดยอิงตามส่วนของงบประมาณ $ L1 $ ที่จัดสรรให้กับคีย์นั้น แนวทางนี้ช่วยให้รายงานรวมมีความถูกต้องมากที่สุดเมื่อใช้สัญญาณรบกวน กลไกนี้มีความยืดหยุ่นสูงและรองรับกลยุทธ์การรวมข้อมูลได้หลายกลยุทธ์

ในตัวอย่างนี้ ระบบจะแบ่งงบประมาณด้านความเป็นส่วนตัวเท่าๆ กันระหว่าง campaignCounts กับ geoValue โดยแบ่งการมีส่วนร่วม $ L1 $ ให้กับแต่ละรายการดังนี้

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

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

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

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

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

ตัวอย่างก่อนหน้านี้สร้างการมีส่วนร่วมของฮิสโตแกรมดังต่อไปนี้

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

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

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

Differential Privacy

เป้าหมายของ API นี้คือการมีเฟรมเวิร์กซึ่งรองรับการวัดผลแบบรวมที่แยกความแตกต่าง ซึ่งทำได้โดยการเพิ่มสัญญาณรบกวนตามสัดส่วนงบประมาณ $ L1 $ เช่น การเลือกสัญญาณรบกวนที่มีการแจกแจงต่อไปนี้

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

การผสานรวม Protected Audience API กับ Attribution Reporting API

การผสานรวมข้าม API ของ Protected Audience และ Attribution Reporting API ช่วยให้เทคโนโลยีโฆษณาประเมินประสิทธิภาพการระบุแหล่งที่มาในกลยุทธ์รีมาร์เก็ตติ้งต่างๆ เพื่อให้ทราบว่ากลุ่มเป้าหมายประเภทใดให้ ROI สูงสุด

การผสานรวมข้าม API นี้ช่วยให้เทคโนโลยีโฆษณาทําสิ่งต่อไปนี้ได้

สร้างการแมปค่าคีย์ของ URI เพื่อใช้สําหรับทั้ง 1) การรายงานการโต้ตอบ และ 2) การลงทะเบียนแหล่งที่มา
รวม CustomAudience ในการแมปคีย์ฝั่งแหล่งที่มาสำหรับการรายงานสรุปแบบรวม (โดยใช้ Attribution Reporting API)

เมื่อผู้ใช้เห็นหรือคลิกโฆษณา

นอกจากนี้ URL ที่ใช้รายงานการโต้ตอบเหล่านั้นโดยใช้ Protected Audience จะใช้ในการลงทะเบียนการดูหรือการคลิกเป็นแหล่งที่มาที่มีสิทธิ์ด้วย Attribution Reporting API ด้วย
เทคโนโลยีโฆษณาอาจเลือกส่ง CustomAudience (หรือข้อมูลตามบริบทอื่นๆ ที่เกี่ยวข้องเกี่ยวกับโฆษณา เช่น ตําแหน่งโฆษณาหรือระยะเวลาในการดู) โดยใช้ URL ดังกล่าวเพื่อให้ระบบส่งต่อข้อมูลเมตานี้ไปยังรายงานสรุปเมื่อเทคโนโลยีโฆษณาตรวจสอบประสิทธิภาพแคมเปญรวม

ดูข้อมูลเพิ่มเติมเกี่ยวกับวิธีเปิดใช้ฟีเจอร์นี้ภายใน Protected Audience ได้ที่ส่วนที่เกี่ยวข้องของคําอธิบาย Protected Audience API

ตัวอย่างลําดับความสําคัญของการลงทะเบียน การระบุแหล่งที่มา และการรายงาน

ตัวอย่างนี้แสดงชุดการโต้ตอบของผู้ใช้ และวิธีที่เทคโนโลยีโฆษณากําหนดแหล่งที่มาของการระบุแหล่งที่มาและลําดับความสําคัญของทริกเกอร์อาจส่งผลต่อรายงานที่มีการระบุแหล่งที่มา ในตัวอย่างนี้ เราจะสมมติดังนี้

แหล่งที่มาและทริกเกอร์การระบุแหล่งที่มาทั้งหมดได้รับการลงทะเบียนโดยเทคโนโลยีโฆษณาเดียวกันสําหรับผู้ลงโฆษณารายเดียวกัน
แหล่งที่มาและทริกเกอร์การระบุแหล่งที่มาทั้งหมดเกิดขึ้นในช่วงกรอบเวลาการรายงานเหตุการณ์แรก (ภายใน 2 วันหลังจากแสดงโฆษณาในแอปของผู้เผยแพร่โฆษณาเป็นครั้งแรก)

ลองพิจารณากรณีที่ผู้ใช้ทําสิ่งต่อไปนี้

ผู้ใช้เห็นโฆษณา เทคโนโลยีโฆษณาลงทะเบียนแหล่งที่มาของการระบุแหล่งที่มากับ API โดยมีลําดับความสําคัญเป็น 0 (มุมมอง #1)
ผู้ใช้เห็นโฆษณาที่ลงทะเบียนโดยมีลําดับความสําคัญเป็น 0 (การดู #2)
ผู้ใช้คลิกโฆษณาที่ลงทะเบียนโดยมีลําดับความสําคัญ 1 (คลิก #1)
ผู้ใช้ทํา Conversion (ไปถึงหน้า Landing Page) ในแอปของผู้ลงโฆษณา เทคโนโลยีโฆษณาจะลงทะเบียนทริกเกอร์กับ API โดยมีลําดับความสําคัญเป็น 0 (Conversion #1)
- เมื่อลงทะเบียนทริกเกอร์แล้ว API จะทำการระบุแหล่งที่มาก่อนสร้างรายงาน
- แหล่งที่มาของการระบุแหล่งที่มามี 3 แหล่ง ได้แก่ การดู #1 การดู #2 และการคลิก #1 API จะระบุแหล่งที่มาของทริกเกอร์นี้เป็นคลิก #1 เนื่องจากมีลําดับความสําคัญสูงสุดและเป็นรายการล่าสุด
- ระบบจะทิ้งมุมมอง #1 และมุมมอง #2 และจะไม่มีสิทธิ์รับการระบุแหล่งที่มาในอนาคตอีกต่อไป
ผู้ใช้เพิ่มสินค้าลงในรถเข็นในแอปของผู้ลงโฆษณา ซึ่งลงทะเบียนโดยมีลําดับความสําคัญเป็น 1 (Conversion #2)
- คลิก #1 เป็นแหล่งที่มาของการระบุแหล่งที่มาที่มีสิทธิ์เพียงแหล่งเดียว แอตทริบิวต์ API นี้ทริกเกอร์ให้คลิก #1
ผู้ใช้เพิ่มสินค้าลงในรถเข็นในแอปของผู้ลงโฆษณา ซึ่งลงทะเบียนโดยมีลําดับความสําคัญเป็น 1 (Conversion #3)
- คลิก #1 เป็นแหล่งที่มาของการระบุแหล่งที่มาที่มีสิทธิ์เพียงแหล่งเดียว แอตทริบิวต์ API นี้ทริกเกอร์ให้คลิก #1
ผู้ใช้เพิ่มสินค้าลงในรถเข็นในแอปของผู้ลงโฆษณา ซึ่งลงทะเบียนโดยมีลําดับความสําคัญเป็น 1 (Conversion หมายเลข 4)
- คลิก #1 เป็นแหล่งที่มาของการระบุแหล่งที่มาที่มีสิทธิ์เพียงแหล่งเดียว แอตทริบิวต์ API นี้ทริกเกอร์ให้คลิก #1
ผู้ใช้ทําการซื้อในแอปของผู้ลงโฆษณาที่ลงทะเบียนโดยมีลําดับความสําคัญเป็น 2 (Conversion #5)
- คลิก #1 เป็นแหล่งที่มาของการระบุแหล่งที่มาที่มีสิทธิ์เพียงแหล่งเดียว แอตทริบิวต์ API นี้ทริกเกอร์ให้คลิก #1

รายงานระดับเหตุการณ์มีลักษณะดังนี้

โดยค่าเริ่มต้น ระบบจะส่งทริกเกอร์ 3 รายการแรกที่มีการระบุแหล่งที่มาเป็นคลิก และทริกเกอร์แรกที่มีการระบุแหล่งที่มาเป็นยอดดูหลังจากกรอบเวลาการรายงานที่เกี่ยวข้อง
ภายในกรอบเวลาการรายงาน หากมีการบันทึกทริกเกอร์ที่มีลําดับความสําคัญสูงกว่า รายการเหล่านั้นจะมีลําดับความสําคัญเหนือกว่าและแทนที่ทริกเกอร์ล่าสุด
ในตัวอย่างก่อนหน้านี้ เทคโนโลยีโฆษณาได้รับรายงานเหตุการณ์ 3 รายการหลังจากกรอบเวลาการรายงาน 2 วันสําหรับ Conversion หมายเลข 2, 3 และ 5
- ทริกเกอร์ทั้ง 5 รายการมาจากคลิก #1 โดยค่าเริ่มต้น API จะส่งรายงานสําหรับทริกเกอร์ 3 รายการแรก ได้แก่ Conversion #1, Conversion #2 และ Conversion #3
- อย่างไรก็ตาม ลําดับความสําคัญของ Conversion 4 (1) สูงกว่าลําดับความสําคัญของ Conversion 1 (0) รายงานเหตุการณ์ของ Conversion 4 จะแทนที่รายงานเหตุการณ์ของ Conversion 1 ที่จะส่ง
- นอกจากนี้ ลําดับความสําคัญของ Conversion #5 (2) ยังสูงกว่าทริกเกอร์อื่นๆ รายงานเหตุการณ์ของ Conversion หมายเลข 5 จะแทนที่รายงานของ Conversion หมายเลข 4 ที่จะส่ง

รายงานที่รวบรวมได้มีลักษณะดังนี้

ระบบจะส่งรายงานแบบรวมที่เข้ารหัสไปยังเทคโนโลยีโฆษณาทันทีที่ประมวลผลเสร็จสิ้น ซึ่งใช้เวลา 2-3 ชั่วโมงหลังจากลงทะเบียนทริกเกอร์

ในฐานะผู้ให้บริการด้านเทคโนโลยีโฆษณา คุณสร้างกลุ่มตามข้อมูลที่ไม่มีการเข้ารหัสในรายงานที่รวบรวมได้ ข้อมูลนี้จะอยู่ในช่อง shared_info ในรายงานที่รวบรวมได้ รวมถึงการประทับเวลาและแหล่งที่มาของการรายงาน คุณไม่สามารถจัดกลุ่มตามข้อมูลที่เข้ารหัสในคู่คีย์-ค่าการรวม กลยุทธ์ง่ายๆ ที่ทําได้ เช่น การรวมรายงานเป็นกลุ่มรายวันหรือรายสัปดาห์ โดยแต่ละกลุ่มควรมีรายงานอย่างน้อย 100 รายการ
เทคโนโลยีโฆษณาจะเป็นผู้กำหนดเวลาและวิธีจัดกลุ่มรายงานที่รวบรวมได้ และส่งไปยังบริการรวบรวม
รายงานแบบรวมที่เข้ารหัสสามารถระบุแหล่งที่มาของทริกเกอร์ได้มากกว่าเมื่อเทียบกับรายงานระดับเหตุการณ์
ในตัวอย่างก่อนหน้านี้ ระบบจะส่งรายงานที่รวบรวมได้ 5 ฉบับ โดยส่ง 1 ฉบับสําหรับทริกเกอร์ที่ลงทะเบียนแต่ละรายการ

รายงานการแก้ไขข้อบกพร่องในช่วงเปลี่ยนผ่าน

Attribution Reporting API เป็นวิธีใหม่ในการวัดการระบุแหล่งที่มาที่ค่อนข้างซับซ้อนโดยไม่มีตัวระบุข้ามแอป ด้วยเหตุนี้ เราจึงรองรับกลไกการเปลี่ยนผ่านเพื่อดูข้อมูลเพิ่มเติมเกี่ยวกับรายงานการระบุแหล่งที่มาเมื่อรหัสโฆษณาพร้อมใช้งาน (ผู้ใช้ไม่ได้เลือกไม่ใช้การปรับตามโปรไฟล์ของผู้ใช้โดยใช้รหัสโฆษณา และแอปของผู้เผยแพร่โฆษณาหรือผู้ลงโฆษณาได้ประกาศสิทธิ์ AdID) วิธีนี้ช่วยให้มั่นใจได้ว่า API จะเข้าใจได้อย่างเต็มที่ในระหว่างการเปิดตัว ช่วยแก้ไขข้อบกพร่อง และเปรียบเทียบประสิทธิภาพกับทางเลือกอื่นๆ ที่อิงตามรหัสโฆษณาได้ง่ายขึ้น รายงานการแก้ไขข้อบกพร่องมี 2 ประเภท ได้แก่ attribution-success และ verbose

อ่านคู่มือเกี่ยวกับรายงานการแก้ไขข้อบกพร่องในช่วงเปลี่ยนผ่านเพื่อดูรายละเอียดเกี่ยวกับรายงานการแก้ไขข้อบกพร่องที่มีการวัดผลจากแอปไปยังเว็บและจากเว็บไปยังแอป

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

ทั้งการลงทะเบียนแหล่งที่มาและทริกเกอร์จะยอมรับช่อง debug_key 64 บิตใหม่ (รูปแบบเป็นสตริง) ซึ่งเทคโนโลยีโฆษณาจะป้อนข้อมูล ระบบจะส่ง source_debug_key และ trigger_debug_key โดยไม่เปลี่ยนแปลงทั้งในรายงานระดับเหตุการณ์และรายงานรวม

หากสร้างรายงานโดยใช้ทั้งคีย์การแก้ไขข้อบกพร่องของแหล่งที่มาและทริกเกอร์ ระบบจะส่งรายงานการแก้ไขข้อบกพร่องที่ซ้ำกันโดยมีความล่าช้าแบบจำกัดไปยังปลายทาง .well-known/attribution-reporting/debug/report-event-attribution รายงานการแก้ไขข้อบกพร่องจะเหมือนกับรายงานปกติทุกประการ รวมถึงช่องคีย์การแก้ไขข้อบกพร่องทั้ง 2 ช่อง การใส่คีย์เหล่านี้ในทั้ง 2 รายการช่วยให้คุณเชื่อมโยงรายงานปกติกับสตรีมรายงานข้อบกพร่องแยกต่างหากได้

สําหรับรายงานระดับเหตุการณ์ ให้ทําดังนี้
- ระบบจะส่งรายงานการแก้ไขข้อบกพร่องที่ซ้ำกันโดยมีความล่าช้าแบบจํากัด จึงไม่มีการระงับโดยขีดจํากัดของทริกเกอร์ที่ใช้ได้ ซึ่งช่วยให้เทคโนโลยีโฆษณาเข้าใจผลกระทบของขีดจํากัดเหล่านั้นสําหรับรายงานระดับเหตุการณ์
- รายงานระดับเหตุการณ์ที่เชื่อมโยงกับเหตุการณ์ทริกเกอร์เท็จจะไม่มีtrigger_debug_key ซึ่งช่วยให้เทคโนโลยีโฆษณาเข้าใจวิธีใช้สัญญาณรบกวนใน API มากขึ้น
สําหรับรายงานที่รวบรวมได้ ให้ทําดังนี้
- เราจะรองรับฟิลด์ debug_cleartext_payload ใหม่ซึ่งมีเพย์โหลดที่ถอดรหัสแล้วก็ต่อเมื่อตั้งค่าทั้ง source_debug_key และ trigger_debug_key ไว้เท่านั้น

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

รายงานการแก้ไขข้อบกพร่องแบบละเอียดช่วยให้นักพัฒนาแอปตรวจสอบความล้มเหลวบางอย่างในแหล่งที่มาของการระบุแหล่งที่มาหรือทริกเกอร์การลงทะเบียนได้ ระบบจะส่งรายงานการแก้ไขข้อบกพร่องเหล่านี้โดยมีความล่าช้าแบบจํากัดหลังจากแหล่งที่มาของการระบุแหล่งที่มาหรือการลงทะเบียนทริกเกอร์ปลายทาง well-known/attribution-reporting/debug/verbose

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

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

ผู้เชี่ยวชาญด้านเทคโนโลยีโฆษณาต้องเลือกใช้เพื่อรับรายงานการแก้ไขข้อบกพร่องแบบละเอียดโดยใช้debug_reportingช่องพจนานุกรมใหม่ในส่วนหัว Attribution-Reporting-Register_Source และ Attribution-Reporting-Register-Trigger

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

วิธีใช้รายงานข้อบกพร่อง

หากเกิด Conversion (ตามระบบการวัดที่มีอยู่) และได้รับรายงานการแก้ไขข้อบกพร่องสําหรับ Conversion นั้น แสดงว่าระบบได้ลงทะเบียนทริกเกอร์สําเร็จแล้ว

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

ในกรณีที่ไม่ตรงกัน อาจเกิดจากสาเหตุหลายประการ

ทำงานได้ตามที่ตั้งใจไว้

ลักษณะการทํางานของ API ที่รักษาความเป็นส่วนตัว
- ผู้ใช้ส่งรายงานถึงขีดจำกัดอัตรารายงาน ซึ่งทำให้ระบบส่งรายงานต่อๆ ไปทั้งหมดไม่ได้ภายในระยะเวลาดังกล่าว หรือระบบนำแหล่งที่มาออกเนื่องจากขีดจํากัดปลายทางที่รอดำเนินการ
- สําหรับรายงานระดับเหตุการณ์: รายงานจะขึ้นอยู่กับการตอบกลับแบบสุ่ม (สัญญาณรบกวน) และถูกระงับ หรือคุณอาจได้รับรายงานแบบสุ่ม
- สําหรับรายงานระดับเหตุการณ์: มีรายงานถึงขีดจํากัด 3 รายการ (สําหรับการคลิก) หรือ 1 รายการ (สําหรับยอดดู) และรายงานต่อๆ ไปไม่ได้ตั้งค่าลําดับความสําคัญไว้อย่างชัดเจน หรือมีลําดับความสําคัญต่ำกว่ารายงานที่มีอยู่
- เกินขีดจํากัดการมีส่วนร่วมของรายงานที่รวบรวมได้
ตรรกะทางธุรกิจที่เทคโนโลยีโฆษณากําหนด
- เงื่อนไขเริ่มต้นถูกกรองออกผ่านตัวกรองหรือกฎลําดับความสําคัญ
ความล่าช้าหรือการทำงานร่วมกับความพร้อมใช้งานของเครือข่าย (เช่น ผู้ใช้ปิดอุปกรณ์เป็นเวลานาน)

สาเหตุที่ไม่ได้ตั้งใจ

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

สิ่งที่ควรพิจารณาในอนาคตและคำถามที่ยังค้างคา

Attribution Reporting API ยังอยู่ระหว่างการพัฒนา นอกจากนี้ เรายังกําลังสํารวจฟีเจอร์ที่อาจเกิดขึ้นในอนาคต เช่น รูปแบบการระบุแหล่งที่มาที่ไม่ใช่คลิกสุดท้ายและกรณีการใช้งานการวัดผลข้ามอุปกรณ์

นอกจากนี้ เราต้องการความคิดเห็นจากชุมชนเกี่ยวกับปัญหา 2-3 ข้อต่อไปนี้

มี Use Case ใดบ้างที่คุณต้องการให้ API ส่งรายงานสําหรับการติดตั้งที่ยืนยันแล้ว รายงานเหล่านี้จะนับรวมอยู่ในขีดจํากัดอัตราของแพลตฟอร์มเทคโนโลยีโฆษณา
คุณคาดการณ์ว่าจะมีปัญหาในการส่ง InputEvent จากแอปไปยังเทคโนโลยีโฆษณาสำหรับการจดทะเบียนแหล่งที่มาไหม
คุณมี Use Case การระบุแหล่งที่มาพิเศษสําหรับแอปที่โหลดไว้ล่วงหน้าหรือแอปที่ติดตั้งใหม่ไหม