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

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

• เพิ่มส่วนเกี่ยวกับรายงานการแก้ไขข้อบกพร่องชั่วคราว
• เพิ่มวิธีการเข้าร่วมรายการที่อนุญาตเพื่อลงทะเบียนแหล่งที่มาของเว็บ

เส้นทางทริกเกอร์

ดังที่อธิบายไว้ในข้อเสนอการออกแบบ Attribution Reporting API นั้น API ช่วยให้ระบุแหล่งที่มาของเส้นทางการทริกเกอร์ต่อไปนี้ในอุปกรณ์ที่ใช้ Android เครื่องเดียวได้ ในที่นี้ เราจะกำหนดเว็บเป็น (1) เบราว์เซอร์แบบสแตนด์อโลนที่ทำงานบน Android (เช่น Chrome) หรือ (2) WebView ที่ทำงานภายในแอป Android

• App-to-app: ผู้ใช้เห็นโฆษณาในแอป แล้วทำ Conversion ในแอปนั้นหรือแอปอื่นที่ติดตั้งไว้
• App-to-web: ผู้ใช้เห็นโฆษณาในแอป แล้วทำ Conversion บนเว็บ
• Web-to-app: ผู้ใช้เห็นโฆษณาบนเว็บ แล้วทำ Conversion ในแอป
• Web-to-web: ผู้ใช้เห็นโฆษณาบนเว็บ แล้วทำ Conversion บนเว็บ

เส้นทางการทริกเกอร์ก่อนหน้าจะแปลเป็นข้อกำหนดต่อไปนี้

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

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

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

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

เมื่อกระบวนการลงทะเบียนเสร็จสมบูรณ์แล้ว API จะทิ้งการลงทะเบียน หากได้รับคำขอลงทะเบียนที่ไม่ได้ลงทะเบียน

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

การเปลี่ยนแปลงสำหรับเทคโนโลยีโฆษณา

ส่วนนี้จะกล่าวถึงการเปลี่ยนแปลงสำหรับเทคโนโลยีโฆษณาที่ใช้ Attribution Reporting API

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

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

เมื่อลงทะเบียนแหล่งที่มาของการระบุแหล่งที่มาบนเว็บหรือทริกเกอร์ API จะไม่รองรับการเปลี่ยนเส้นทางเนื่องจากแอปแต่ละแอปที่โฮสต์เนื้อหาเว็บอาจมีรูปแบบสิทธิ์ของตนเอง แอปแต่ละแอปมีหน้าที่เปลี่ยนเส้นทาง (หากรองรับ) และเรียกใช้API บริบทของเว็บสำหรับการเปลี่ยนเส้นทางแต่ละครั้ง

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

รับรายงานแอปและเว็บ

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

• สําหรับรายงานระดับเหตุการณ์ เราจะรองรับฟิลด์ปลายทางที่ ระบุว่าทริกเกอร์เกิดขึ้นบนเว็บ (ปลายทางคือ eTLD+1) หรือแอป (ปลายทางคือชื่อแพ็กเกจแอป)
• สำหรับรายงานที่รวบรวมได้ ระบบจะส่งปลายทางเป็นข้อความธรรมดา

ผลกระทบของการวัดจากเว็บไปยังเว็บ

แอปจะเลือกเวลาที่จะส่งการลงทะเบียนไปยัง Attribution Reporting API โดยมีข้อควรพิจารณาดังนี้

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

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

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

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

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

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

WebView รองรับการลงทะเบียนกับระบบปฏิบัติการภายในส่วนหัว Attribution-Reporting-Eligibleก็ต่อเมื่อ Attribution Reporting API ของ Android พร้อมใช้งานเท่านั้น ซึ่งต่างจากเบราว์เซอร์ หาก Attribution Reporting API ของ Android ไม่พร้อมใช้งาน WebView จะไม่ตั้งค่าส่วนหัว Attribution-Reporting-Eligible และจะไม่มีการลงทะเบียน

วิธีลงทะเบียนแหล่งที่มาของการระบุแหล่งที่มา / ทริกเกอร์โดยใช้ระบบปฏิบัติการ

• เทคโนโลยีโฆษณาควรตอบกลับการลงทะเบียนแหล่งที่มาโดยใช้ส่วนหัว Attribution-Reporting-Register-OS-Source ซึ่งจะเริ่มการเรียก API รองจาก WebView ไปยัง registerSource() หรือ registerWebSource()
• เทคโนโลยีโฆษณายังตอบกลับการลงทะเบียนทริกเกอร์ได้โดยใช้ส่วนหัว Attribution-Reporting-Register-OS-Trigger ซึ่งจะเริ่มต้นการเรียก API รองจาก WebView ไปยัง registerWebTrigger() หรือ registerTrigger()

โปรดทราบว่าหากการตอบกลับไม่มีส่วนหัวก่อนหน้า หรือมีส่วนหัว Attribution-Reporting-Register-Source / Attribution-Reporting-Register-Trigger แม้ว่าจะไม่รองรับเว็บก็ตาม การลงทะเบียนทั้งหมดจะล้มเหลว

ดูรายละเอียดว่า WebView จะใช้ registerSource() / registerWebSource() และ registerTrigger() / registerWebTrigger() หรือไม่ (รวมถึงวิธีเปลี่ยนลักษณะการทำงานนี้) ได้ที่แหล่งที่มาของการระบุแหล่งที่มาและการลงทะเบียนทริกเกอร์จาก WebView

รายงานการแก้ไขข้อบกพร่องชั่วคราว

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

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

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

ในตัวอย่างแอปไปยังเว็บในภายหลัง แหล่งที่มาจะอยู่ในแอปของผู้เผยแพร่โฆษณา แต่ทริกเกอร์จะอยู่ในเว็บไซต์ของผู้ลงโฆษณาภายในแอปเบราว์เซอร์

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

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

วิธีเปิดใช้รายงานการแก้ไขข้อบกพร่องแบบละเอียดสำหรับแอปไปยังเว็บ

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

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

การเปลี่ยนแปลงสำหรับแอป

เราจะรองรับการระบุแหล่งที่มาในแพลตฟอร์มแอปและเว็บโดยอนุญาตให้แอปส่งการลงทะเบียนแหล่งที่มาของการระบุแหล่งที่มาบนเว็บและทริกเกอร์บนเว็บไปยัง Attribution Reporting API ใน Android โดยใช้ชุดการเรียก API ของบริบทเว็บชุดใหม่

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

ดูตัวอย่างวิธีที่เบราว์เซอร์ผสานรวมกับ Attribution Reporting API ของ Android เพื่อเปิดใช้การวัดผลในแอปและเว็บได้ในข้อเสนอของ Privacy Sandbox สำหรับเว็บ ในข้อเสนอ เบราว์เซอร์จะเพิ่มส่วนหัวของคำขอต่อไปนี้

• Attribution-Reporting-Eligible ออกอากาศว่ามีการรองรับระดับระบบปฏิบัติการสำหรับการระบุแหล่งที่มาหรือไม่ ในกรณีนี้ ส่วนหัวจะระบุว่า Attribution Reporting API ของ Android พร้อมใช้งานหรือไม่
• หากมี ผู้ให้บริการด้านเทคโนโลยีโฆษณาสามารถเลือกตอบโดยใช้ Attribution-Reporting-Register-OS-Source ซึ่งจะเริ่มการเรียก API รอง จากแอปเบราว์เซอร์ไปยัง registerWebSource()
• เทคโนโลยีโฆษณายังตอบสนองต่อการลงทะเบียนทริกเกอร์ได้โดยใช้ส่วนหัว Attribution-Reporting-Register-OS-Trigger ซึ่งจะเริ่มการเรียก API รองจากแอปเบราว์เซอร์ไปยัง registerWebTrigger()

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

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

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

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

• API จะตรวจสอบปลายทางที่ระบุโดยเทคโนโลยีโฆษณากับ ปลายทางที่ระบุโดยแอป หากปลายทางแตกต่างกัน API จะ ทิ้งการลงทะเบียนแหล่งที่มาของการระบุแหล่งที่มา
  
  แอปควรตรวจสอบปลายทางเว็บก่อนเรียกใช้ API บริบทเว็บ สำหรับการคลิก แอปควรตรวจสอบว่าปลายทางที่ระบุ ตรงกับปลายทางที่ผู้ใช้ไปยัง
• API จะไม่สนใจ URI การเปลี่ยนเส้นทางที่ระบุใน Attribution-Reporting-Redirects แอปควรติดตามการเปลี่ยนเส้นทางด้วยตนเอง และเรียกใช้ registerWebSource() สำหรับการเปลี่ยนเส้นทางแต่ละรายการ เพื่อให้แอปสามารถใช้นโยบายสิทธิ์ของตนเองได้ตามต้องการ

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

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

เมื่อลงทะเบียนทริกเกอร์ แอปจะเรียกใช้ registerWebTrigger() ได้ ซึ่งคาดหวังพารามิเตอร์ต่อไปนี้

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

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

โดยค่าเริ่มต้น WebView จะใช้ registerSource() และ registerWebTrigger() ซึ่งจะเชื่อมโยงแหล่งที่มากับแอปและทริกเกอร์กับต้นทางระดับบนสุดของ WebView เมื่อเกิดทริกเกอร์

หากแอปต้องการลักษณะการทำงานที่แตกต่างกัน (เช่น แอปที่โฮสต์เนื้อหาเว็บใน WebView) แอปจะต้องใช้วิธี setAttributionRegistrationBehavior ในคลาส androidx.webkit.WebViewSettingsCompat เมธอดนี้จะระบุว่า WebView ควรเรียกใช้ registerWebSource() หรือ registerSource() และ registerWebTrigger() หรือ registerTrigger() หรือไม่

ตัวเลือกที่ใช้ได้สำหรับ setAttributionRegistrationBehavior มีดังนี้

ค่า	คำอธิบาย	ตัวอย่างกรณีการใช้งาน
APP_SOURCE_AND_WEB_TRIGGER (ค่าเริ่มต้น)	อนุญาตให้แอปจดทะเบียนแหล่งที่มาของแอป (แหล่งที่มาที่เชื่อมโยงกับชื่อแพ็กเกจของแอป) และทริกเกอร์เว็บ (ทริกเกอร์ที่เชื่อมโยงกับ eTLD+1) จาก WebView	แอปที่ใช้ WebView เพื่อแสดงโฆษณาแทนที่จะเปิดใช้การท่องเว็บ
WEB_SOURCE_AND_WEB_TRIGGER	อนุญาตให้แอปบันทึกแหล่งที่มาของเว็บและทริกเกอร์เว็บจาก WebView หมายเหตุ: แอปที่ใช้ตัวเลือกนี้จะต้องสมัครเข้าร่วมรายการที่อนุญาตเพื่อใช้ registerWebSource()	แอปเบราว์เซอร์ที่ใช้ WebView ซึ่งการแสดงโฆษณาและ Conversion อาจเกิดขึ้นทั้งในเว็บไซต์ใน WebView
APP_SOURCE_AND_APP_TRIGGER	อนุญาตให้แอปจดทะเบียนแหล่งที่มาของแอปและทริกเกอร์ของแอปจาก WebView	แอปที่ใช้ WebView ซึ่งการแสดงโฆษณาและ Conversion ควรเชื่อมโยงกับแอปเสมอ ไม่ใช่ eTLD+1 ของ WebView
ปิดใช้อยู่	ปิดใช้การลงทะเบียนแหล่งที่มาและทริกเกอร์จาก WebView โปรดทราบว่าการเรียกเครือข่ายครั้งแรกไปยัง URI ของแหล่งที่มาของการระบุแหล่งที่มาหรือทริกเกอร์อาจยังคงเกิดขึ้น แต่ระบบจะทิ้งการตอบกลับและจะไม่จัดเก็บสิ่งใดไว้ในอุปกรณ์

ข้อควรพิจารณาด้านความเป็นส่วนตัวและความปลอดภัย

ส่วนนี้จะกล่าวถึงข้อควรพิจารณาด้านความเป็นส่วนตัวและความปลอดภัยสำหรับแอปที่ใช้ Attribution Reporting API

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

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

หากแอปมีขีดจำกัดอัตราแยกต่างหาก ผู้ไม่ประสงค์ดีจะใช้ขีดจำกัดอัตราเฉพาะของแอปนอกเหนือจากขีดจำกัดอัตราของ API ได้ เพื่อ ลดปัญหานี้ แอปควรยืนยันว่าแหล่งที่มาของการระบุแหล่งที่มาที่ระบุไม่ได้ ลงทะเบียนทั้งในโซลูชันการวัดผลของแอปและ Android Attribution Reporting API

สร้างความน่าเชื่อถือสำหรับบริบทของเว็บ

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

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

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

แอปใดก็ได้ที่เรียกใช้ registerWebTrigger() เนื่องจากข้อควรพิจารณาด้านความเป็นส่วนตัวและความปลอดภัย ในฝั่งทริกเกอร์ไม่เกี่ยวข้องหากไม่มีการสมรู้ร่วมคิดฝั่งแหล่งที่มา

การควบคุมของผู้ใช้

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

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

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

การทำงานร่วมกันระหว่างแอปกับเว็บสำหรับ Attribution Reporting API อยู่ระหว่างดำเนินการ เราอยากขอความคิดเห็นจากชุมชนเกี่ยวกับแนวคิด 2-3 อย่างต่อไปนี้

1. ในอุปกรณ์ที่รองรับ Privacy Sandbox ของ Android คุณจะใช้โซลูชันการวัดผลในเบราว์เซอร์กับ Android Attribution Reporting API ได้อย่างไร คุณต้องการส่งทุกอย่างไปยัง Android ไหม
2. มีข้อกังวลเกี่ยวกับการรับการปิง 2 ครั้งสำหรับแหล่งที่มาของการระบุแหล่งที่มาและทริกเกอร์แต่ละรายการหรือไม่ โดยครั้งหนึ่งมาจากเบราว์เซอร์หรือแอป และอีกครั้งมาจาก Attribution Reporting API
3. เราจะช่วยให้การแก้ไขข้อบกพร่องใน API ต่างๆ ง่ายขึ้นสำหรับคุณได้อย่างไร
4. ข้อเสนอไม่มีการตรวจสอบว่าปลายทางของแอปและเว็บมีความเกี่ยวข้องหรือไม่ ในอนาคต เราอาจตรวจสอบปลายทางเหล่านี้ได้โดย ตรวจสอบการเชื่อมโยงโดยใช้ Digital Asset Links การดำเนินการดังกล่าวจะบล็อก Use Case ใดๆ ของคุณไหม การใช้ Digital Asset Links เพื่อทำการตรวจสอบนี้สมเหตุสมผลหรือไม่
5. เมื่อลงทะเบียนแหล่งที่มาของการระบุแหล่งที่มา คุณต้องระบุปลายทาง ในกรณีเว็บไปยังแอป คุณอาจต้องการระบุ App Link คุณใช้รูปแบบใดในการระบุ App Link นี้
6. เมื่อลงทะเบียนแหล่งที่มาของการระบุแหล่งที่มาแอปไปยังเว็บ เหตุการณ์แหล่งที่มานั้นจะต้องลงทะเบียนจากแอปด้วย Android Attribution Reporting API เช่น หากผู้ใช้คลิกโฆษณาและเปิดการคลิกใน เบราว์เซอร์หรือแท็บที่กำหนดเองของเบราว์เซอร์ การคลิกนั้น (เหตุการณ์ต้นทาง) ควร ลงทะเบียนจากแอปแทนที่จะอยู่ในบริบทของเบราว์เซอร์ โปรดติดต่อเรา หากคุณมีข้อกังวลเกี่ยวกับเรื่องนี้ หรือหากมีกรณีการใช้งานอื่นๆ ที่ไม่ได้ อยู่ในหมวดหมู่ที่ครอบคลุมในปัญหาที่อธิบายโฟลว์ที่รองรับนี้

แนะนำสำหรับคุณ

• หมายเหตุ: ข้อความลิงก์จะแสดงเมื่อ JavaScript ปิดอยู่
• การรายงานการระบุแหล่งที่มา
• คู่มือสำหรับนักพัฒนาซอฟต์แวร์ Attribution Reporting API
• บันทึกประจำรุ่น