Attribution Reporting API เปิดใช้การระบุแหล่งที่มาข้ามแอปและเว็บสำหรับแหล่งที่มา และทริกเกอร์ที่เกิดขึ้นในอุปกรณ์เดียวกัน เบราว์เซอร์อย่าง Chrome สามารถมอบสิทธิ์ทั้งแหล่งที่มาและทริกเกอร์การลงทะเบียนให้กับ Attribution Reporting ได้ API สำหรับ Android แทนการจัดการการลงทะเบียนเหล่านั้นในเบราว์เซอร์ วิธีนี้จะช่วยให้ Android จับคู่แหล่งที่มาและทริกเกอร์ทั้งในเว็บไซต์และแอป
คู่มือนี้จะสอนวิธีตั้งค่าการระบุแหล่งที่มาข้ามแอปและเว็บ
เมื่อคุณตั้งค่าการระบุแหล่งที่มาข้ามแอปและเว็บ เราขอแนะนำเป็นอย่างยิ่งให้ ทำความคุ้นเคยกับโซลูชันการแก้ไขข้อบกพร่องที่มีอยู่เพื่อให้แน่ใจว่า การตั้งค่าทำงานตามที่ต้องการ
ลงทะเบียนแหล่งที่มาและทริกเกอร์ด้วยระบบปฏิบัติการ Android
การระบุแหล่งที่มาข้ามแอปและเว็บจะใช้ได้ต่อเมื่อการระบุแหล่งที่มา Reporting API เปิดใช้ทั้งในเบราว์เซอร์และระบบปฏิบัติการ Android ในอุปกรณ์เดียวกัน อุปกรณ์ ส่งความพร้อมใช้งานของ Android Attribution Reporting API แล้ว ผ่านส่วนหัว Attribution-Reporting-Support ส่วนหัวนี้จะแสดงระบบปฏิบัติการ เว็บ หรือทั้ง 2 อย่าง ทั้งนี้ขึ้นอยู่กับสิ่งที่ใช้ได้ในอุปกรณ์นั้น หากทั้ง 2 แบบ เทคโนโลยีโฆษณาจะมีตัวเลือกในการลงทะเบียนแหล่งข้อมูลเว็บและเว็บ ทริกเกอร์ด้วยเบราว์เซอร์หรือระบบปฏิบัติการ
เทคโนโลยีโฆษณาต้องตัดสินใจว่าจะลงทะเบียนแหล่งที่มาเว็บหรือเว็บทริกเกอร์ กับเบราว์เซอร์หรือระบบปฏิบัติการ
- สำหรับแคมเปญบนเว็บเท่านั้น เทคโนโลยีโฆษณาจะยังบันทึกทั้งแหล่งที่มาและทริกเกอร์ได้ ด้วย Attribution Reporting API ของ Chrome หรือเลือกมอบสิทธิ์ทั้ง 2 อย่างให้กับระบบปฏิบัติการ สำหรับแคมเปญเว็บเท่านั้น ซึ่งมีแหล่งที่มาหรือทริกเกอร์ที่เกิดขึ้นใน WebView เทคโนโลยีโฆษณาจะต้องมอบสิทธิ์ทั้งต้นทางและทริกเกอร์การลงทะเบียนเพื่อ ระบบปฏิบัติการ ดูส่วนนี้ใน WebView สำหรับข้อมูลเพิ่มเติม
- เทคโนโลยีโฆษณาควรหลีกเลี่ยงการลงทะเบียนแหล่งที่มาและตัวทริกเกอร์กับทั้ง Chrome และ Android API พร้อมกัน เพื่อหลีกเลี่ยงการสร้างการระบุแหล่งที่มาที่ซ้ำกัน รายงาน
- การระบุแหล่งที่มาจะเกิดขึ้นแยกต่างหากสำหรับเบราว์เซอร์และระบบปฏิบัติการ หากแหล่งที่มาคือ ลงทะเบียนกับเบราว์เซอร์แล้ว แต่ทริกเกอร์จะลงทะเบียนกับระบบปฏิบัติการ กล่าวคือ ไม่สามารถจับคู่ได้ และยังในทางกลับกัน
- สำหรับแหล่งที่มาที่อาจส่งผลให้เกิดแอปหรือทริกเกอร์เว็บ แนะนำสำหรับเทคโนโลยีโฆษณาเพื่อมอบสิทธิ์แหล่งข้อมูลเว็บและทริกเกอร์การลงทะเบียน Android Attribution Reporting API
- สำหรับทริกเกอร์ที่อาจขับเคลื่อนด้วยแหล่งที่มาที่อิงตามแอป เทคโนโลยีโฆษณาจะ เลือกมอบสิทธิ์การลงทะเบียนเว็บทริกเกอร์ให้กับ Android Attribution Reporting API
- สำหรับแคมเปญที่ทั้งแหล่งที่มาและทริกเกอร์เกิดขึ้นในแอป ทั้ง 2 อย่างนี้จะ ต้องลงทะเบียนกับ OS Attribution Reporting API
ลงทะเบียนแหล่งที่มาของแอปและทริกเกอร์เว็บ
ในบางแคมเปญ แหล่งที่มาอาจเกิดขึ้นในแอปขณะที่ทริกเกอร์จะเกิดขึ้น บนเว็บไซต์ในเบราว์เซอร์บนอุปกรณ์เคลื่อนที่บนอุปกรณ์เดียวกัน
ตัวอย่าง
ผู้ใช้กำลังอ่านบทความในแอปข่าวที่ตนชื่นชอบ ลูกค้าเห็นโฆษณาในราคาถูก เที่ยวบินสู่ปารีสและตื่นเต้นเลยคลิกเพื่อจอง เทคโนโลยีโฆษณาที่ใช้แสดงโฆษณา แอปข่าวจะลงทะเบียนแหล่งที่มาของคลิกกับ Android Attribution Reporting API ระบบจะนำผู้ใช้ไปที่หน้าเว็บของผู้ลงโฆษณาใน Chrome ซึ่งพวกเขาจะสามารถ ทำให้เกิด Conversion เทคโนโลยีโฆษณาในเว็บไซต์ของผู้ลงโฆษณาจะตรวจสอบว่า API ระดับระบบปฏิบัติการ และพร้อมใช้งานทันที เทคโนโลยีโฆษณาจะบันทึกการทริกเกอร์ Conversion ตาม การสั่งให้ Chrome มอบสิทธิ์การลงทะเบียนในระบบปฏิบัติการแทนที่จะลงทะเบียน ด้วย Attribution Reporting API ของ Chrome โดยตรง การระบุแหล่งที่มาระดับระบบปฏิบัติการ จากนั้น Reporting API จะจับคู่แหล่งที่มาของแอปและทริกเกอร์เว็บ แล้วส่งออก รายงานที่เกี่ยวข้อง
![ขั้นตอนการระบุแหล่งที่มาจากแอปไปยังเว็บ](https://developers.google.cn/static/privacy-sandbox/private-advertising/attribution-reporting/cross-web-app/a2w_diagram.png?hl=th)
การลงทะเบียนแหล่งที่มาของแอป
SDK เทคโนโลยีโฆษณาในแอป Android News ประจำวันบันทึกการคลิกโดยใช้
registerSource()
Attribution Reporting API ใน Android จะส่งคำขอไปยังเซิร์ฟเวอร์เทคโนโลยีโฆษณา ระบุ URL ให้กับ
registerSource()
แล้วเซิร์ฟเวอร์เทคโนโลยีโฆษณาตอบสนองด้วย Attribution-Reporting-register-Source เพื่อลงทะเบียนต้นทางให้เสร็จสมบูรณ์
การลงทะเบียนเว็บทริกเกอร์
เทคโนโลยีโฆษณาจะลงทะเบียนทริกเกอร์และตรวจสอบความพร้อมใช้งานของระบบปฏิบัติการใน API การรายงานการระบุแหล่งที่มา
ARA บนเว็บแสดงข้อมูลเกี่ยวกับแพลตฟอร์มที่รองรับ
ส่วนหัว
OS-Trigger
บอก ARA API ในเว็บให้เรียกใช้ OS ARA API ฟังก์ชันregisterWebTrigger()
การโทรหา
registerWebTrigger()
เกิดขึ้นในเบื้องหลังและนักพัฒนาแอป ไม่จำเป็นต้องโทรหาregisterWebTrigger()
ด้วยระบบปฏิบัติการโดยตรงOS ARA จะเข้ามาแทนที่และส่งคำขอไปยัง URL ของเซิร์ฟเวอร์เทคโนโลยีโฆษณาที่ให้ไว้โดย ส่วนหัว
Attribution-Reporting-Register-OS-Trigger
เทคโนโลยีโฆษณาจะลงทะเบียนทริกเกอร์การลงทะเบียนด้วย OS API
OS ARA จะทำการระบุแหล่งที่มาตามตรรกะเดียวกันกับที่ใช้ การระบุแหล่งที่มาของแอป<>และส่งรายงานเดียวกัน
ขั้นตอนการทำงาน
ขั้นตอนต่อไปนี้มีรายละเอียดเพิ่มเติมเกี่ยวกับวิธีทำงานให้เสร็จสมบูรณ์
เทคโนโลยีโฆษณาจากแอปลงทะเบียนแหล่งที่มากับการระบุแหล่งที่มาของ Android Reporting API ที่มีการปรับต่อไปนี้
- ในการลงทะเบียนแหล่งที่มาของแอปซึ่งคาดว่าจะเกิด Conversion บนเว็บไซต์
ส่วนหัวการตอบกลับ
Attribution-Reporting-Register-Source
ควรมีเว็บ ปลายทาง (eTLD+1) แทนที่จะเป็นปลายทางแอป
Attribution-Reporting-Register-Source: { "web_destination": "https://advertiser.example", ... }
- ผู้ลงโฆษณาบางรายอาจใช้ผู้ให้บริการการวัดผลหลายราย (เช่น เครื่องมือวัดของบุคคลที่สามหรือเครื่องมือวิเคราะห์) โดยใช้เชนการเปลี่ยนเส้นทาง 302 ในบางกรณี Attribution Reporting API จะทำตามเส้นทางการเปลี่ยนเส้นทาง ที่ระบุไว้ในส่วนหัว Attribution-Reporting-Redirect ในเบื้องหลังและที่ ขณะเดียวกันที่เส้นทางการเปลี่ยนเส้นทาง 302 ดำเนินการในเบื้องหน้าสำหรับ คำขอการนำทาง คำขอเหล่านี้จะไปยัง URL เดียวกันและอาจส่งผลให้ ในผู้ให้บริการวัดผลบุคคลที่สามที่นับการลงทะเบียนซ้ำ ถึง ป้องกันการลงทะเบียนซ้ำ เทคโนโลยีโฆษณาสามารถปรับเปลี่ยนพฤติกรรมการเปลี่ยนเส้นทาง เพื่อส่งการลงทะเบียน Attribution Reporting API ไปยังทางเลือกอื่น URL เชิงกำหนด
หากต้องการเปิดลักษณะการทำงานนี้ เทคโนโลยีโฆษณาจะต้องใส่ส่วนหัว HTTP ใหม่เมื่อ ตอบกลับคำขอลงทะเบียน:
- ส่วนหัวคือ
Attribution-Reporting-Redirect-Config
- ค่าของส่วนหัวควรเป็น redirect-302-to-well-known
"Attribution-Reporting-Redirect-Config": "redirect-302-to-well-known"
- ส่วนหัวคือ
กระบวนการลงทะเบียนแหล่งที่มาที่เหลือจะเหมือนกับ การลงทะเบียนต้นทางแบบแอปต่อแอป
- ในการลงทะเบียนแหล่งที่มาของแอปซึ่งคาดว่าจะเกิด Conversion บนเว็บไซต์
ส่วนหัวการตอบกลับ
เทคโนโลยีโฆษณาในเว็บไซต์ของผู้ลงโฆษณาจะลงทะเบียนทริกเกอร์โดยถาม Chrome ที่จะใช้มอบสิทธิ์การลงทะเบียนไปยัง Android Attribution Reporting API
เมื่อผู้ใช้ทำ Conversion ในเว็บไซต์เสร็จแล้ว เทคโนโลยีโฆษณาจะ ขอลงทะเบียนทริกเกอร์กับ Chrome
สามารถใช้พิกเซลหรือคำขอ
fetch()
เพื่อส่งคำขอลงทะเบียน ทริกเกอร์Chrome แสดงผลส่วนหัวของคำขอ
Attribution-Reporting-Support
กับเทคโนโลยีโฆษณา หากเปิดใช้ API ทั้งในเบราว์เซอร์ Chrome และ อุปกรณ์ Android ส่วนหัวจะแสดงos, web
"Attribution-Reporting-Support": "os, web"
เทคโนโลยีโฆษณาควรแจ้งให้ Chrome มอบสิทธิ์ให้กับระบบปฏิบัติการโดยใช้
Attribution-Reporting-Register-OS-Trigger
ส่วนหัวซึ่งมีสิ่งต่อไปนี้แจ้ง Chrome ให้มอบสิทธิ์การลงทะเบียนในระบบปฏิบัติการ
Chrome มอบสิทธิ์การลงทะเบียนให้กับระบบปฏิบัติการโดยการเรียกใช้ฟังก์ชัน API ของระบบปฏิบัติการ
registerWebTrigger()
- การโทรหา
registerWebTrigger()
เกิดขึ้นภายในเบื้องหลัง เทคโนโลยีโฆษณา ไม่จำเป็นต้องโทรหาregisterWebTrigger()
โดยตรง
- การโทรหา
OS API จะเริ่มการเรียก API รองไปยัง URI เทคโนโลยีโฆษณาที่ส่งต่อ จากเบราว์เซอร์
"Attribution-Reporting-Register-OS-Trigger": "https://adtech.example/register-trigger", "https://other-adtech.example/register-trigger"
ในบางกรณี ส่วนหัว
Attribution-Reporting-Support
ไม่พร้อมใช้งานและ ไม่สามารถส่งได้ ในกรณีนี้ เทคโนโลยีโฆษณายังคงสามารถตั้งค่า ในการจัดการการลงทะเบียนทริกเกอร์โดยการรวม ส่วนหัวAttribution-Reporting-Info
คีย์คือแพลตฟอร์มที่ต้องการและ ค่าที่อนุญาตคือos
และweb
เบราว์เซอร์จะใช้แพลตฟอร์มที่ต้องการ (หากมี) และจะกลับไปใช้แพลตฟอร์มเว็บเมื่อระบบปฏิบัติการ ไม่พร้อมใช้งาน
Attribution-Reporting-Info: preferred-platform=os
- ปลายทางของเทคโนโลยีโฆษณาควรตอบสนองเพื่อลงทะเบียนทริกเกอร์ให้เสร็จสมบูรณ์ ไปยังคำขอ Android Attribution Reporting API โดยใช้ส่วนหัวการตอบกลับ
Attribution-Reporting-Register-Trigger { "event_trigger_data": [{"trigger_data":"1"}], "aggregatable_trigger_data": [ {"key_piece":"0x400","source_keys":["campaignCounts"]}, {"key_piece":"0xA80","source_keys":["geoValue"]} ], ... }
- ช่วงเวลาที่เหลือของการลงทะเบียนทริกเกอร์จะยังคงเหมือนเดิม
ลงทะเบียนแหล่งข้อมูลเว็บและทริกเกอร์แอป
สำหรับบางแคมเปญ แหล่งที่มาอาจเกิดขึ้นในเว็บไซต์ในเบราว์เซอร์บนอุปกรณ์เคลื่อนที่ขณะที่ เกิดขึ้นในแอปในอุปกรณ์เดียวกัน
ตัวอย่าง
ผู้ใช้กำลังเรียกดูเว็บไซต์โดยใช้เบราว์เซอร์ Chrome ในโทรศัพท์ Android เขาเห็นโฆษณาเสื้อสเวตเตอร์จากร้านโปรดแห่งหนึ่ง ผู้ใช้คลิก โฆษณา และจะถูกนำไปยังแอปพลิเคชันที่พวกเขาได้ดาวน์โหลดไว้แล้ว เทคโนโลยีโฆษณา เว็บไซต์ที่แสดงโฆษณาจะลงทะเบียนแหล่งที่มาของคลิกโดยแจ้ง Chrome ในการมอบสิทธิ์การลงทะเบียนไปยัง Android Attribution Reporting API แทน ที่ใช้ Attribution Reporting API ใน Chrome ผู้ใช้ซื้อเสื้อกันหนาว แอปช็อปปิ้ง จากนั้นเทคโนโลยีโฆษณาในแอปของผู้ลงโฆษณาจะลงทะเบียน Conversion ที่มี Android Attribution Reporting API ระดับระบบปฏิบัติการ Attribution Reporting API สามารถจับคู่กับแหล่งที่มาของเว็บและทริกเกอร์แอป และ ให้ส่งรายงานที่เกี่ยวข้อง
![ขั้นตอนการระบุแหล่งที่มาจากเว็บไปยังแอป](https://developers.google.cn/static/privacy-sandbox/private-advertising/attribution-reporting/cross-web-app/w2a_diagram.png?hl=th)
การลงทะเบียนแหล่งข้อมูลเว็บ
เทคโนโลยีโฆษณาจะลงทะเบียนแหล่งที่มาและตรวจสอบความพร้อมใช้งานของระบบปฏิบัติการใน API การรายงานการระบุแหล่งที่มา
ARA บนเว็บแสดงข้อมูลเกี่ยวกับแพลตฟอร์มที่รองรับ
ส่วนหัว
OS-Source
บอก ARA API ในเว็บให้เรียกใช้ OS ARA API ฟังก์ชันregisterWebSource()
การโทรหา
registerWebSource()
เกิดขึ้นในเบื้องหลังและนักพัฒนาแอป ไม่จำเป็นต้องโทรหาregisterWebSource()
ด้วยระบบปฏิบัติการโดยตรงOS ARA จะเข้ามาแทนที่และส่งคำขอไปยัง URL ของเซิร์ฟเวอร์เทคโนโลยีโฆษณาที่ระบุไว้ โดยส่วนหัว
Attribution-Reporting-Register-OS-Source
เทคโนโลยีโฆษณาจะลงทะเบียนแหล่งที่มาด้วย OS API
การลงทะเบียนทริกเกอร์แอป
SDK เทคโนโลยีโฆษณาในแอปเสื้อผ้า Android ของ Android จะลงทะเบียนทริกเกอร์กับ OS ARA
Attribution Reporting API ใน Android จะส่งคำขอไปยังเซิร์ฟเวอร์เทคโนโลยีโฆษณา ระบุ URL ให้กับ
registerTrigger()
แล้วเซิร์ฟเวอร์เทคโนโลยีโฆษณาตอบสนองด้วย
Attribution-Reporting-Register-Trigger
ส่วนหัวเพื่อลงทะเบียนทริกเกอร์ให้เสร็จสมบูรณ์OS ARA จะทำการระบุแหล่งที่มาตามตรรกะเดียวกันกับที่ใช้ การระบุแหล่งที่มาของแอป<>และส่งรายงานเดียวกัน
ขั้นตอนการทำงาน
ขั้นตอนต่อไปนี้มีรายละเอียดเพิ่มเติมเกี่ยวกับวิธีทำงานให้เสร็จสมบูรณ์
เทคโนโลยีโฆษณาในเว็บไซต์ของผู้เผยแพร่โฆษณาลงทะเบียนแหล่งที่มาโดยสอน Chrome ที่จะใช้มอบสิทธิ์การลงทะเบียนไปยัง Android Attribution Reporting API
- สำหรับกรณีการใช้งานจากเว็บไปแอป การระบุแหล่งที่มาเมื่อลงทะเบียนแหล่งที่มา
ต้องระบุพารามิเตอร์แหล่งที่มาโดยตรง โดยใช้พารามิเตอร์
แท็ก
attributionsrc
หรือใช้การลงทะเบียน JavaScript - ตัวอย่างต่อไปนี้ใช้แท็ก
attributionsrc
เพื่อระบุพารามิเตอร์ พารามิเตอร์แหล่งที่มา:
<img src="https://adtech.example/conversionpixel" attributionsrc="https://adtech.example/register-source?purchase=12">
- สำหรับกรณีการใช้งานจากเว็บไปแอป การระบุแหล่งที่มาเมื่อลงทะเบียนแหล่งที่มา
ต้องระบุพารามิเตอร์แหล่งที่มาโดยตรง โดยใช้พารามิเตอร์
แท็ก
Chrome จะส่งกลับส่วนหัวของคำขอ
Attribution-Reporting-Support
ไปยัง ของ Ad Exchange หากเปิดใช้ API ทั้งในเบราว์เซอร์ Chrome และอุปกรณ์ Android ส่วนหัวจะแสดงos, web
"Attribution-Reporting-Support": "os, web"
เทคโนโลยีโฆษณาควรแจ้ง Chrome ให้มอบสิทธิ์ API ระดับระบบปฏิบัติการโดยใช้
Attribution-Reporting-Register-OS-Source
ส่วนหัวซึ่งมีสิ่งต่อไปนี้- แจ้ง Chrome ให้มอบสิทธิ์การลงทะเบียนในระบบปฏิบัติการ
- Chrome มอบสิทธิ์การลงทะเบียนให้กับระบบปฏิบัติการโดยการเรียกใช้ฟังก์ชัน API ของระบบปฏิบัติการ
registerWebSource()
- การโทรหา
registerWebSource()
เกิดขึ้นภายในเบื้องหลัง เทคโนโลยีโฆษณา ไม่จำเป็นต้องโทรหาregisterWebSource()
โดยตรง - OS API จะเริ่มการเรียก API รองไปยัง URI เทคโนโลยีโฆษณาที่ส่งผ่านจาก เบราว์เซอร์
"Attribution-Reporting-Register-OS-Source": "https://adtech.example/register-source"
- ในบางกรณี ส่วนหัว
Attribution-Reporting-Support
อาจไม่พร้อมใช้งาน เมื่อเกิดกรณีนี้ขึ้น เทคโนโลยีโฆษณาจะยังคงตั้งค่าแพลตฟอร์มที่ต้องการให้จัดการได้ การลงทะเบียนแหล่งที่มาโดยรวมส่วนหัวAttribution-Reporting-Info
ไว้ด้วย คีย์เป็นแพลตฟอร์มที่ต้องการและค่าที่อนุญาตคือos
และweb
จะใช้แพลตฟอร์มที่ต้องการเมื่อพร้อมใช้งาน และจะสำรองเป็น แพลตฟอร์มเว็บเมื่อระบบปฏิบัติการไม่พร้อมใช้งาน
Attribution-Reporting-Info: preferred-platform=os
- ปลายทางของเทคโนโลยีโฆษณาควรตอบสนองเพื่อให้การลงทะเบียนแหล่งที่มาเสร็จสมบูรณ์
ไปยังคําขอ Android Attribution Reporting API ที่มีส่วนหัวการตอบกลับ
Attribution-Reporting-Register-Source
การตอบกลับควรระบุ ปลายทางของแอป ในช่องปลายทาง
Attribution-Reporting-Register-Source { "source_event_id":"123001", "destination":"android-app://com.example.advertiser", ... }
- เพื่อรองรับการเปลี่ยนเส้นทางสำหรับการลงทะเบียนต้นทาง Chrome จะปฏิบัติตาม จะเปลี่ยนเส้นทางและเรียกใช้ API บริบทเว็บสำหรับฮอพการเปลี่ยนเส้นทางแต่ละรายการ
- ส่วนที่เหลือของการลงทะเบียนแหล่งที่มาจะยังคงเหมือนเดิม
เทคโนโลยีโฆษณาในแอปของผู้ลงโฆษณาจะลงทะเบียนทริกเกอร์กับ Android Attribution Reporting API
- สำหรับทริกเกอร์ที่เกิดขึ้นในแอป แอปจะลงทะเบียนทริกเกอร์ด้วยฟังก์ชัน Android Attribution Reporting API ตามปกติ
แคมเปญซึ่งมีปลายทางที่เป็นไปได้ทั้งแอปและเว็บ
ตั้งค่าปลายทางแบบ 2 ขั้นตอน
- บางแคมเปญอาจถูกตั้งค่าให้ทำให้เกิด Conversion ในแอปของผู้ลงโฆษณาหรือ ในหน้าเว็บของผู้ลงโฆษณา โดยขึ้นอยู่กับปัจจัยต่างๆ เช่น หากผู้ใช้ ติดตั้งแอปไว้
- ในกรณีเหล่านี้ ขอแนะนําให้มอบสิทธิ์การลงทะเบียนต้นทางให้กับ ระบบปฏิบัติการเมื่อพร้อมใช้งานเพื่อให้ระบุแหล่งที่มาได้อย่างถูกต้องไม่ว่าจะ ตำแหน่งที่ทริกเกอร์เกิดขึ้น เมื่อลงทะเบียนแหล่งที่มากับระบบปฏิบัติการ ทั้ง คุณสามารถระบุปลายทางของแอปและเว็บในพารามิเตอร์ที่เกี่ยวข้องได้
- ปลายทางของแอปควรอยู่ในช่อง
destination
- ปลายทางเว็บควรอยู่ในช่อง
web_destination
- นักพัฒนาซอฟต์แวร์ Chrome โปรดทราบว่าช่อง
destination
สำหรับระบบปฏิบัติการ Attribution Reporting API ควรเป็นแพ็กเกจแอป ไม่ใช่ URL
Attribution-Reporting-Register-Source { "source_event_id":"123001", "destination":"android-app://com.example.advertiser", "web_destination": "https://example.advertiser" ... }
- ส่วนถัดไปเกี่ยวกับการรายงานคร่าวๆ จะอธิบายวิธีการใช้ปลายทางคู่ อาจส่งผลต่อสิ่งรบกวนในรายงานของคุณ
ใช้การรายงานคร่าวๆ เพื่อลดเสียงรบกวนในรายงานระดับเหตุการณ์สำหรับคู่ แหล่งที่มาปลายทาง:
- หากมีการระบุทั้งระบบปฏิบัติการ (แอป) และปลายทางเว็บไว้ในต้นทาง การลงทะเบียน รายงานระดับเหตุการณ์จะระบุว่าทริกเกอร์เกิดขึ้นหรือไม่ ในปลายทางเว็บหรือปลายทางแอปโดยค่าเริ่มต้น แต่หากต้องการรักษา ขีดจำกัดด้านความเป็นส่วนตัว จะมีการเพิ่มสัญญาณรบกวนเพิ่มเติมลงในรายงานเหล่านี้
- เทคโนโลยีโฆษณาสามารถใช้ช่อง
coarse_event_report_destinations
ใต้Attribution-Reporting-Register-Source
ส่วนหัวเพื่อเปิดการรายงานคร่าวๆ และลดเสียงรบกวน หากแหล่งที่มาที่มีcoarse_event_report_destinations
ฟิลด์ที่ระบุชนะการระบุแหล่งที่มา รายงานที่ได้จะรวมทั้งแอป และเว็บปลายทางโดยไม่มีความแตกต่างว่าทริกเกอร์จริงที่ใด เกิดขึ้นแต่มีความผันผวนน้อยกว่ารายงานตำแหน่งที่แอปหรือเว็บปลายทาง ที่ระบุไว้ - รายงานสรุปจะไม่มีการเปลี่ยนแปลง
สำหรับแอปที่ใช้แท็บที่กำหนดเองของ Chrome
บางแอปอาจใช้แท็บที่กำหนดเองเพื่อแสดงเนื้อหาเว็บ การทำงานของแท็บที่กำหนดเอง คล้ายกับหน้าเว็บปกติเมื่อวัดผลข้ามแอปและเว็บไซต์บนอุปกรณ์เคลื่อนที่
- ลงทะเบียนแหล่งที่มาของแอปและทริกเกอร์แท็บที่กำหนดเอง ดังนี้
- ทำตามวิธีการเพื่อลงทะเบียนแหล่งที่มาของแอปและทริกเกอร์เว็บ
- ลงทะเบียนแหล่งที่มาของแท็บที่กำหนดเองและทริกเกอร์แอป
- ทำตามวิธีการเพื่อลงทะเบียนทริกเกอร์เว็บและทริกเกอร์แอป
- ลงทะเบียนแหล่งที่มา CCT และทริกเกอร์ CCT
- ซึ่งจะถือว่าเหมือนกับการระบุแหล่งที่มาจากเว็บในเว็บไซต์ใน Chrome
สำหรับแอปที่ใช้ WebView
บางแอปอาจใช้ WebView เพื่อแสดงเนื้อหา กรณีการใช้งานที่หลากหลาย สำหรับ WebView เช่น การแสดงโฆษณา การโฮสต์เนื้อหาเว็บ หรือแอปที่กำหนดเอง เหมาะกับรูปแบบเว็บมากกว่า
เฉพาะการระบุแหล่งที่มาระดับระบบปฏิบัติการเท่านั้นที่มีให้ใช้งานใน WebView ส่วนหัว Attribution-Reporting-Support จะแสดงผลเป็นระบบปฏิบัติการเท่านั้น และเฉพาะในกรณีที่ Android Attribution Reporting API พร้อมใช้งานแล้ว
WebView อาจใช้
registerSource
หรือเมื่อมอบสิทธิ์ให้กับระบบปฏิบัติการregisterWebSource
และregisterTrigger
หรือregisterWebTrigger
วิธีการใดที่ WebView ที่ใช้นั้นกำหนดโดยการแสดงผลแอปบน WebView และจะกำหนดตาม ต่อ WebView- ความแตกต่างระหว่าง
registerSource
และregisterWebSource
คือ แหล่งที่มาจะถูกบันทึกในฐานะผู้เผยแพร่โฆษณา เมื่อใช้registerSource
ระบบจะบันทึกแอปไว้ ในฐานะผู้เผยแพร่โฆษณา ตัวอย่างกรณีที่ควรใช้registerSource
จะเป็น แอปของผู้เผยแพร่ที่แสดงโฆษณาที่แสดงผลโดยใช้ WebView ด้วยregisterWebSource
ระบบจะบันทึกเว็บไซต์ที่โฮสต์ใน WebView เป็น ผู้เผยแพร่โฆษณา ตัวอย่างของกรณีที่ควรใช้registerWebSource
จะเป็นแอปที่ โฮสต์ WebView และเว็บไซต์ที่ WebView จะแสดงผล ที่กำลังแสดงโฆษณาอยู่registerTrigger
และregisterWebTrigger
มีพฤติกรรมคล้ายกัน แผนภูมิในรายการที่ 3 จะแสดงรายละเอียดของสถานการณ์ต่างๆ ที่นักพัฒนาแอปหรือนักพัฒนาแอป SDK ต้องการกำหนดค่า API ให้ใช้registerSource
หรือregisterWebSource
และregisterTrigger
หรือregisterWebTrigger
- ความแตกต่างระหว่าง
โดยค่าเริ่มต้น WebView จะใช้
registerSource
และregisterWebTrigger
เมื่อ กำลังเรียกใช้ Android Attribution Reporting API ซึ่งจะเชื่อมโยงแหล่งที่มากับ แอปและทริกเกอร์ที่มีต้นทางระดับบนสุดของ URL ใน WebView เมื่อ เกิดขึ้น- หากแอปต้องใช้ลักษณะการทำงานอื่น ก็ต้องใช้วิธีการใหม่
setAttributionRegistrationBehavior ใน androidx.webkit.WebViewSettingsCompat
วิธีนี้จะระบุว่า WebView ควรเรียกใช้
registerWebSource()
หรือไม่ หรือregisterWebTrigger()
แทนที่จะเป็นregisterSource()
หรือregisterTrigger()
- คุณต้องตั้งค่าลักษณะการทำงานนี้สำหรับ WebView แต่ละรายการที่เริ่มต้น
- หาก SDK เทคโนโลยีโฆษณาเป็นผู้เริ่ม WebView จะต้องตั้งค่า SDK ลักษณะการทำงานเริ่มต้นนี้
- สำหรับแอปที่ต้องการใช้
registerWebSource()
ในการเชื่อมโยงแหล่งที่มา ที่ลงทะเบียนกับเว็บไซต์ใน WebView แทนที่จะเป็นแอป เข้าร่วมรายการที่อนุญาตของเว็บแอป กรอกแบบฟอร์มนี้เพื่อเข้าร่วมรายการที่อนุญาต เพื่อช่วยลดการพิจารณาเรื่องความเป็นส่วนตัว การสร้างความน่าเชื่อถือสำหรับบริบทของเว็บ
- ตัวเลือกสำหรับ setAttributionRegistrationBehavior
ค่า คำอธิบาย ตัวอย่างกรณีการใช้งาน APP_SOURCE_AND_WEB_TRIGGER (ค่าเริ่มต้น) อนุญาตให้แอปลงทะเบียนแหล่งที่มาของแอป (แหล่งที่มาที่เชื่อมโยงกับชื่อแพ็กเกจของแอป) และทริกเกอร์เว็บ (ทริกเกอร์ที่เชื่อมโยงกับ eTLD+1) จาก WebView ได้ แอปที่ใช้ WebView เพื่อแสดงโฆษณาแทนที่จะเปิดใช้การท่องเว็บ WEB_SOURCE_AND_WEB_TRIGGER อนุญาตให้แอปลงทะเบียนแหล่งที่มาเว็บและทริกเกอร์เว็บจาก WebView แอปเบราว์เซอร์แบบ WebView ซึ่งทั้งการแสดงโฆษณาและ Conversion อาจเกิดขึ้นบนเว็บไซต์ใน WebView APP_SOURCE_AND_APP_TRIGGER อนุญาตให้แอปลงทะเบียนแหล่งที่มาของแอปและทริกเกอร์แอปจาก WebView แอปแบบ WebView ซึ่งการแสดงโฆษณาและ Conversion ควรเชื่อมโยงกับแอปเสมอ ไม่ใช่ eTLD+1 ของ WebView ปิดใช้อยู่ ปิดใช้การลงทะเบียนต้นทางและทริกเกอร์จาก WebView - หากแอปต้องใช้ลักษณะการทำงานอื่น ก็ต้องใช้วิธีการใหม่
setAttributionRegistrationBehavior ใน androidx.webkit.WebViewSettingsCompat
วิธีนี้จะระบุว่า WebView ควรเรียกใช้
แหล่งที่มาและทริกเกอร์การลงทะเบียนจาก WebView
เทคโนโลยีโฆษณาควรตอบสนองต่อการลงทะเบียนแหล่งที่มาโดยใช้ ส่วนหัว
Attribution-Reporting-Register-OS-Source
อิงตามลักษณะการทำงานที่ตั้งไว้ สำหรับ WebView ระบบจะเรียกใช้registerSource()
หรือregisterWebSource()
กับระบบปฏิบัติการและเริ่มการเรียก API รองจากการระบุแหล่งที่มาของ Android Reporting API ไปยัง URI เทคโนโลยีโฆษณา- เพื่อให้การลงทะเบียนแหล่งที่มาเสร็จสมบูรณ์ อุปกรณ์ปลายทางของเทคโนโลยีโฆษณาควร ตอบกลับคำขอ Android Attribution Reporting API ด้วย ส่วนหัวการตอบกลับ
Attribution-Reporting-Register-OS-Source { "source_event_id":"123001", "destination":"android-app://com.example.advertiser", ... }
ส่วนที่เหลือของการลงทะเบียนแหล่งที่มาจะยังคงเหมือนเดิม
เทคโนโลยีโฆษณาควรตอบสนองต่อการเรียกการลงทะเบียนโดยใช้ ส่วนหัว
Attribution-Reporting-Register-OS-Trigger
อิงตามลักษณะการทำงานที่ตั้งไว้ สำหรับ WebView ซึ่งจะเรียกใช้registerTrigger()
หรือregisterWebTrigger()
กับระบบปฏิบัติการและเริ่มการเรียก API รองจาก Rb ไปยัง URI เทคโนโลยีโฆษณา- เพื่อให้การลงทะเบียนทริกเกอร์เสร็จสมบูรณ์ ปลายทางของเทคโนโลยีโฆษณาควร ตอบกลับคำขอ Android Attribution Reporting API ด้วยการตอบกลับ ส่วนหัว
Attribution-Reporting-Register-OS-Trigger { "event_trigger_data": [{"trigger_data":"1"}], "aggregatable_trigger_data": [ {"key_piece":"0x400","source_keys":["campaignCounts"]}, {"key_piece":"0xA80","source_keys":["geoValue"]} ], ... }
- ส่วนขั้นตอนการลงทะเบียนทริกเกอร์จะยังคงเหมือนเดิม
แก้ไขข้อบกพร่อง
เมื่อตั้งค่าการติดตั้งใช้งานแอปกับเว็บ ขอแนะนำให้ตั้งค่าการแก้ไขข้อบกพร่อง รายงานเพื่อยืนยันว่ามีการลงทะเบียนแหล่งที่มาและทริกเกอร์อย่างถูกต้องหรือไม่ ไม่ได้จดทะเบียน หากต้องการข้อมูลสาเหตุ
โปรดดูขั้นตอนการแก้ไขข้อบกพร่องทั่วไปของการรายงานการระบุแหล่งที่มาในตำราอาหารการแก้ไขข้อบกพร่อง