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

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

ตามที่อธิบายไว้ในข้อเสนอการออกแบบ Attribution Reporting API ทาง API จะเปิดใช้การระบุแหล่งที่มาของเส้นทางทริกเกอร์ต่อไปนี้ในอุปกรณ์ 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 การจดทะเบียนเซิร์ฟเวอร์รายการใดรายการหนึ่ง

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

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

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

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

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

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

Attribution Reporting API ของ Android สามารถส่งรายงานสําหรับทั้ง Conversion ของแอปและ 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 เพื่อให้การวัดผลที่แม่นยําเมื่อผู้ใช้คลิกโฆษณาทั้งในแอปเบราว์เซอร์และแอปที่ไม่ใช่เบราว์เซอร์

ตัวอย่างการคลิกของผู้ใช้และ Conversion ในช่วง 3 วัน
ตัวอย่างการลงทะเบียนแหล่งที่มาและทริกเกอร์ในเบราว์เซอร์และแอป
  • ในวันที่ 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 เดียวกัน (ที่ถูกต้อง) ไปยังฝั่งเว็บ ดูตัวอย่างจากแอปไปยังเว็บได้ที่ด้านล่าง ซึ่งแหล่งที่มาเกิดขึ้นในแอปของผู้เผยแพร่โฆษณา แต่ทริกเกอร์เกิดขึ้นในเว็บไซต์ของผู้ลงโฆษณาภายในแอปเบราว์เซอร์

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

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

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

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

    แอปควรตรวจสอบปลายทางของเว็บก่อนเรียกใช้ Web Context 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

ค่า คำอธิบาย ตัวอย่าง Use Case
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 ของทริกเกอร์อาจยังคงเกิดขึ้น แต่ระบบจะทิ้งการตอบกลับและจะไม่จัดเก็บข้อมูลใดๆ ในอุปกรณ์

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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