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

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

ภาพรวม

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

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

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

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

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

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

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

รับสิทธิ์เข้าถึง 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 เปลี่ยนเส้นทาง ซึ่งอนุญาตให้เทคโนโลยีโฆษณาหลายรายการลงทะเบียนคำขอ

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

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

  1. SDK เทคโนโลยีโฆษณาเรียกใช้ API เพื่อเริ่มการลงทะเบียนแหล่งที่มาของการระบุแหล่งที่มา โดยระบุ URI สำหรับ API ที่จะเรียกใช้

    registerSource(
    Uri.parse("https://adtech.example/attribution_source?AD_TECH_PROVIDED_METADATA"),
    myClickEvent);

  2. API จะส่งคำขอไปยัง https://adtech.example/attribution_source?AD_TECH_PROVIDED_METADATA โดยใช้ส่วนหัวอย่างใดอย่างหนึ่งต่อไปนี้

    <!-- For click events -->
Attribution-Reporting-Source-Info: navigation

<!-- For view events -->
Attribution-Reporting-Source-Info: event

  3. เซิร์ฟเวอร์ 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

  4. API จะส่งคำขอไปยัง URL แต่ละรายการที่ระบุใน Attribution-Reporting-Redirect ในตัวอย่างนี้ มีการระบุ URL ของพาร์ทเนอร์เทคโนโลยีโฆษณา 2 ราย ดังนั้น API จึงส่งคำขอ 1 รายการไปยัง https://adtechpartner1.example?their_ad_click_id=567 และอีกคำขอไปยัง https://adtechpartner2.example?their_ad_click_id=890

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

    Attribution-Reporting-Register-Source: {
    "destination": "android-app://com.advertiser.example",
    "source_event_id": "789",
    "expiry": "120000",
    "priority": "2"
}

ระบบจะลงทะเบียนแหล่งที่มาของการระบุแหล่งที่มาของการนำทาง (คลิก) 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() หลายครั้ง เราขอแนะนำให้คุณใช้ฟิลด์คีย์การขจัดข้อมูลที่ซ้ำกัน เพื่อหลีกเลี่ยงการรวมทริกเกอร์ที่ซ้ำกันไว้ในรายงานในกรณีที่เทคโนโลยีโฆษณาเดียวกัน ให้การตอบกลับหลายรายการสำหรับเหตุการณ์ทริกเกอร์เดียวกัน ดูข้อมูลเพิ่มเติมเกี่ยวกับวิธีและเวลาในการใช้คีย์การกรองข้อมูลที่ซ้ำกันออก

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

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

  1. SDK เทคโนโลยีโฆษณาจะเรียกใช้ API เพื่อเริ่มการลงทะเบียนทริกเกอร์โดยใช้ URI ที่ลงทะเบียนไว้ล่วงหน้า ดูข้อมูลเพิ่มเติมได้ที่ลงทะเบียนบัญชี Privacy Sandbox

    registerTrigger(
    Uri.parse("https://adtech.example/attribution_trigger?AD_TECH_PROVIDED_METADATA"));

  2. API จะส่งคำขอไปยัง https://adtech.example/attribution_trigger?AD_TECH_PROVIDED_METADATA

  3. เซิร์ฟเวอร์ 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

  4. API จะส่งคำขอไปยัง URL แต่ละรายการที่ระบุใน Attribution-Reporting-Redirect ในตัวอย่างนี้ มีการระบุ URL เพียงรายการเดียว ดังนั้น API จึงส่งคำขอไปยัง https://adtechpartner.example?app_install=567

  5. เซิร์ฟเวอร์ 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 จะตรวจสอบช่วงย้อนกลับก่อน หากมี ระยะเวลาตั้งแต่ลงทะเบียนแหล่งที่มาต้องน้อยกว่าหรือเท่ากับระยะเวลาของ Lookback Window

แพลตฟอร์มเทคโนโลยีโฆษณายังเลือกข้อมูลทริกเกอร์ตามข้อมูลเหตุการณ์แหล่งที่มาได้ด้วย ตัวอย่างเช่น API จะสร้าง source_type โดยอัตโนมัติเป็น 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 อาจยังคงสูญเสียหรือถูกทิ้งหากมีการลงทะเบียนแหล่งที่มาของการระบุแหล่งที่มาที่มีลำดับความสำคัญสูงกว่า
  • หากถอนการติดตั้งและติดตั้งแอปผู้ลงโฆษณาอีกครั้ง ระบบจะนับการติดตั้งอีกครั้งเป็นการติดตั้งใหม่ที่ได้รับการยืนยัน
  • หากคลิก 1 เป็นเหตุการณ์การดูแทน ทั้งทริกเกอร์ "การเปิดครั้งแรก" และทริกเกอร์หลังการติดตั้ง จะยังคงได้รับการระบุแหล่งที่มาเป็นคลิก 1 API จำกัดการระบุแหล่งที่มาเป็นทริกเกอร์ 1 รายการต่อการดู 1 ครั้ง ยกเว้นในกรณีของการระบุแหล่งที่มาหลังการติดตั้ง ซึ่งอนุญาตให้มีทริกเกอร์ได้สูงสุด 2 รายการต่อการดู 1 ครั้ง ในกรณีการระบุแหล่งที่มาหลังการติดตั้ง เทคโนโลยีโฆษณาอาจได้รับกรอบเวลาการรายงาน 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 รายการตามอัลกอริทึมการระบุแหล่งที่มาที่ให้ความสำคัญกับแหล่งที่มา ซึ่งอธิบายไว้ในภายหลังในหน้านี้

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

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

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

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

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

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

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

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

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

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

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

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

ทริกเกอร์

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

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

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

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

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

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

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

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

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

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

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

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

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

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

API จะตอบกลับในลักษณะเดียวกับวันที่ 1 เพียงแต่จะมีการลงทะเบียนการดูสำหรับเทคโนโลยีโฆษณา A และ MMP

วันที่ 4: ผู้ใช้ติดตั้งแอปที่ใช้ MMP เพื่อวัด Conversion

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • การวัดผลจากแอปไปยังแอปที่อนุญาตให้ใช้ AdId
  • การวัดจากแอปไปยังเว็บที่อนุญาต 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 บิตของข้อมูลทริกเกอร์สําหรับการคลิก ซึ่งหมายความว่าสามารถกําหนดทริกเกอร์ให้เป็นหมวดหมู่ใดหมวดหมู่หนึ่งใน 8 หมวดหมู่ได้ และ 1 บิตสําหรับการดู นอกจากนี้ รายงานระดับเหตุการณ์ยังไม่รองรับการเข้ารหัส ข้อมูลฝั่งทริกเกอร์ที่มีความเที่ยงตรงสูง เช่น ราคาที่เฉพาะเจาะจงหรือเวลาทริกเกอร์ เนื่องจากการระบุแหล่งที่มาเกิดขึ้นในอุปกรณ์ รายงานระดับเหตุการณ์จึงไม่รองรับข้อมูลวิเคราะห์แบบข้ามอุปกรณ์

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

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

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

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

ขีดจำกัดของจำนวนเทคโนโลยีโฆษณา

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ความเที่ยงตรงของข้อมูลทริกเกอร์ที่จำกัด

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

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

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

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

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

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

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

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

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

ขีดจำกัดของทริกเกอร์ที่ใช้ได้ (Conversion)

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

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

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

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

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

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

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

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

เราจะเพิ่มความยืดหยุ่นนี้ลงใน Attribution Reporting API ใน 2 ระยะ ดังนี้

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. อุปกรณ์จะส่งรายงานข้อมูลที่รวบรวมมาที่เข้ารหัสไปยังเทคโนโลยีโฆษณา ใน สภาพแวดล้อมการใช้งานจริง เทคโนโลยีโฆษณาจะใช้รายงานเหล่านี้โดยตรงไม่ได้
  2. เทคโนโลยีโฆษณาส่งกลุ่มรายงานข้อมูลที่รวบรวมได้ไปยังบริการรวมข้อมูล เพื่อทำการรวม
  3. บริการรวบรวมข้อมูลจะอ่านรายงานที่รวบรวมได้เป็นกลุ่ม ถอดรหัส และ รวบรวมรายงานเหล่านั้น
  4. ระบบจะส่งข้อมูลรวมขั้นสุดท้ายกลับไปยังเทคโนโลยีโฆษณาในรายงานสรุป
กระบวนการที่ 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 บิต และคีย์ที่ยาวกว่านี้จะถูก ตัดทอน ซึ่งหมายความว่าสตริงเลขฐานสิบหกใน 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 แบบข้าม API ใน Protected Audience API และ 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 วันนับจากวันที่แสดงโฆษณาครั้งแรกในแอปของผู้เผยแพร่โฆษณา)

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

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

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

  • โดยค่าเริ่มต้น ระบบจะส่งทริกเกอร์ 3 รายการแรกที่ระบุแหล่งที่มาเป็นการคลิกและทริกเกอร์แรกที่ระบุแหล่งที่มาเป็นการดูหลังจากกรอบเวลาการรายงานที่เกี่ยวข้อง
  • ภายในกรอบเวลาการรายงาน หากมีการลงทะเบียนทริกเกอร์ที่มีลำดับความสำคัญสูงกว่า ทริกเกอร์เหล่านั้นจะมีลำดับความสำคัญสูงกว่าและจะแทนที่ทริกเกอร์ล่าสุด
  • ในตัวอย่างก่อนหน้า เทคโนโลยีโฆษณาจะได้รับรายงานเหตุการณ์ 3 รายการหลังจาก กรอบเวลารายงาน 2 วัน สําหรับ Conversion #2, Conversion #3 และ Conversion #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 ได้อย่างเต็มที่ในระหว่างการเปิดตัว ช่วยกำจัดข้อบกพร่อง และเปรียบเทียบประสิทธิภาพกับทางเลือกอื่นที่อิงตาม Advertising ID ได้ง่ายขึ้น รายงานการแก้ไขข้อบกพร่องมี 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_SourceAttribution-Reporting-Register-Trigger

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

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

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

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

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

ทำงานได้ตามที่ควรจะเป็น

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

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

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

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

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

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

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