อัปเดตล่าสุด
- อัปเดตรายการการเปลี่ยนแปลงที่กำลังจะเกิดขึ้นและปัญหาที่ทราบ
- เปิดตัวการกำหนดค่าระดับเหตุการณ์ที่ยืดหยุ่นแบบ Lite เพื่อเป็นสะพานเชื่อมไปยังการกำหนดค่าระดับเหตุการณ์ที่ยืดหยุ่นเต็มรูปแบบ
- ตั้งแต่เดือนกันยายน 2023 เป็นต้นไป
registerWebSource,registerWebTrigger,registerAppSourceและregisterAppTriggerต้องใช้สตริงสำหรับช่องที่ตรงกับค่าตัวเลข (เช่นpriority,source_event_id,debug_key,trigger_data,deduplication_keyฯลฯ) - ในไตรมาสที่ 4 ปี 2023 จะมีการเพิ่มการรองรับ Google Cloud ใน Android Attribution Reporting API เพื่อสร้างรายงานสรุปโดยใช้บริการรวบรวมใน Google Cloud โดยจะมีเวลาที่เจาะจงมากขึ้นซึ่งแสดงไว้ที่นี่ ดูข้อมูลเพิ่มเติมเกี่ยวกับการตั้งค่าบริการรวบรวมข้อมูลด้วย Google Cloud ได้ในคู่มือการทำให้ใช้งานได้
- ขีดจำกัดอัตราการรักษาความเป็นส่วนตัวใหม่สำหรับจำนวนปลายทางที่ไม่ซ้ำกัน
- ฟังก์ชันการทำงานที่ได้รับการอัปเดตสำหรับตัวกรองทริกเกอร์กรอบเวลามองย้อนกลับจะพร้อมใช้งานในไตรมาสที่ 1 ปี 2024 โปรดดูข้อมูลเพิ่มเติมในหมายเหตุ
ภาพรวม
ปัจจุบัน การที่โซลูชันการระบุแหล่งที่มาและโซลูชันการวัดผลบนอุปกรณ์เคลื่อนที่จะพึ่งพาตัวระบุข้ามฝ่ายต่างๆ เช่น รหัสโฆษณา นั้นถือเป็นเรื่องปกติ Attribution Reporting API ได้รับการออกแบบมาเพื่อปรับปรุงความเป็นส่วนตัวของผู้ใช้โดยยกเลิกการพึ่งพาตัวระบุผู้ใช้ข้ามฝ่ายต่างๆ รวมถึงเพื่อรองรับ Use Case ที่สำคัญๆ สำหรับการระบุแหล่งที่มาและการวัด Conversion ในแอปและเว็บ
โดย API นี้มีกลไกเชิงโครงสร้างต่อไปนี้ซึ่งจะมีเฟรมเวิร์กในการปรับปรุงความเป็นส่วนตัว ซึ่งส่วนถัดไปในหน้านี้จะอธิบายรายละเอียดเพิ่มเติม
- จำกัดจำนวนบิตที่ใช้ได้สำหรับรายงานระดับเหตุการณ์
- เปิดใช้ข้อมูล Conversion ที่มีความแม่นยำสูงเฉพาะในรายงานที่รวบรวมได้เท่านั้น
- เปิดตัวขีดจำกัดอัตราสำหรับทริกเกอร์ที่มีอยู่ (Conversion) และจำนวนเทคโนโลยีโฆษณาที่เชื่อมโยงกับแหล่งที่มาของการระบุแหล่งที่มาแหล่งเดียวได้
- ผสมผสานเทคนิคการเพิ่มสัญญาณรบกวนที่หลากหลาย
กลไกก่อนหน้านี้จะจำกัดความสามารถในการลิงก์ข้อมูลประจำตัวของผู้ใช้ในแอปหรือโดเมน 2 รายการ
Attribution Reporting API รองรับกรณีการใช้งานต่อไปนี้
- การรายงาน Conversion: ช่วยผู้ลงโฆษณาวัดประสิทธิภาพของแคมเปญด้วยการแสดงจํานวน Conversion (ทริกเกอร์) และมูลค่า Conversion (ทริกเกอร์) ในมิติข้อมูลต่างๆ เช่น ตามแคมเปญ กลุ่มโฆษณา และครีเอทีฟโฆษณา
- การเพิ่มประสิทธิภาพ: มอบรายงานระดับเหตุการณ์ที่รองรับการเพิ่มประสิทธิภาพค่าโฆษณา โดยให้ข้อมูลการระบุแหล่งที่มาต่อการแสดงผลที่สามารถใช้ในการฝึกโมเดล ML
- การตรวจหากิจกรรมที่ไม่ถูกต้อง: ให้รายงานที่สามารถใช้ในการตรวจจับและการวิเคราะห์การประพฤติมิชอบเกี่ยวกับโฆษณาและการเข้าชมที่ไม่ถูกต้อง
Attribution Reporting API จะทำงานในระดับสูงดังต่อไปนี้ ซึ่งส่วนต่อไปของเอกสารนี้จะอธิบายรายละเอียดเพิ่มเติม
- เทคโนโลยีโฆษณาได้ผ่านขั้นตอนการลงทะเบียนเพื่อใช้ Attribution Reporting API
- เทคโนโลยีโฆษณาจะลงทะเบียนแหล่งที่มาของการระบุแหล่งที่มา (จำนวนคลิกหรือการดูโฆษณา) ด้วย Attribution Reporting API
- เทคโนโลยีโฆษณาจะลงทะเบียนทริกเกอร์ ซึ่งเป็น Conversion ของผู้ใช้ในแอปหรือเว็บไซต์ของผู้ลงโฆษณาโดยใช้ Attribution Reporting API
- Attribution Reporting API จะจับคู่ทริกเกอร์กับแหล่งที่มาของการระบุแหล่งที่มา ซึ่งก็คือการระบุแหล่งที่มา Conversion โดยมีการส่งทริกเกอร์อย่างน้อย 1 รายการนอกอุปกรณ์ผ่านรายงานระดับเหตุการณ์และรายงานแบบรวมได้ไปยังเทคโนโลยีโฆษณา
รับสิทธิ์เข้าถึง Attribution Reporting API
แพลตฟอร์มเทคโนโลยีโฆษณาจะต้องลงทะเบียนเพื่อเข้าถึง Attribution Reporting API โปรดดูข้อมูลเพิ่มเติมที่หัวข้อลงทะเบียนบัญชี Privacy Sandbox
ลงทะเบียนแหล่งที่มาของการระบุแหล่งที่มา (คลิกหรือดู)
Attribution Reporting API จะเรียกการคลิกโฆษณาและการดูเป็นแหล่งที่มาของการระบุแหล่งที่มา หากต้องการลงทะเบียนการคลิกโฆษณาหรือดูโฆษณา โปรดโทร registerSource() API นี้คาดหวังพารามิเตอร์ต่อไปนี้
- URI แหล่งที่มาของการระบุแหล่งที่มา: แพลตฟอร์มจะส่งคำขอไปยัง URI นี้เพื่อดึงข้อมูลเมตาที่เชื่อมโยงกับแหล่งที่มาของการระบุแหล่งที่มา
- ป้อนเหตุการณ์: ออบเจ็กต์
InputEvent(สําหรับเหตุการณ์การคลิก) หรือnull(สําหรับเหตุการณ์การดู)
เมื่อ API ส่งคำขอไปยัง URI แหล่งที่มาของการระบุแหล่งที่มา เทคโนโลยีโฆษณาควรตอบสนองกับข้อมูลเมตาแหล่งที่มาของการระบุแหล่งที่มาในส่วนหัว HTTP ใหม่ Attribution-Reporting-Register-Source พร้อมช่องต่อไปนี้
- รหัสเหตุการณ์แหล่งที่มา: ค่านี้จะแสดงข้อมูลระดับเหตุการณ์ที่เชื่อมโยงกับแหล่งที่มาของการระบุแหล่งที่มานี้ (การคลิกโฆษณาหรือการดู) ต้องเป็นจำนวนเต็มที่ไม่มีเครื่องหมาย 64 บิตซึ่งจัดรูปแบบเป็นสตริง
- ปลายทาง: ต้นทางที่มี eTLD+1 หรือชื่อแพ็กเกจแอปที่เกิดเหตุการณ์ทริกเกอร์
- หมดอายุ (ไม่บังคับ): หมดอายุเป็นวินาทีสำหรับกรณีที่ควรลบแหล่งที่มาออกจากอุปกรณ์ ค่าเริ่มต้นคือ 30 วัน โดยมีค่าขั้นต่ำ 1 วันและค่าสูงสุด 30 วัน ระบบจะปัดเศษเป็นวันที่ใกล้ที่สุด สามารถจัดรูปแบบเป็นจำนวนเต็มหรือสตริงที่ไม่มีเครื่องหมาย 64 บิตก็ได้
- หน้าต่างรายงานเหตุการณ์ (ไม่บังคับ): ระยะเวลาเป็นวินาทีหลังจากการลงทะเบียนแหล่งที่มา ซึ่งในระหว่างนี้ระบบจะสร้างรายงานเหตุการณ์ของแหล่งที่มานี้ หากเลยกรอบเวลารายงานเหตุการณ์ไปแล้วแต่ยังไม่หมดอายุ ทริกเกอร์จะยังคงจับคู่กับแหล่งที่มาได้ แต่จะไม่มีการส่งรายงานเหตุการณ์สำหรับทริกเกอร์นั้น ต้องไม่มากกว่า "หมดอายุ" สามารถจัดรูปแบบเป็นจำนวนเต็มหรือสตริงที่ไม่มีเครื่องหมาย 64 บิตก็ได้
- กรอบเวลารายงานที่รวบรวมได้ (ไม่บังคับ): ระยะเวลาเป็นวินาทีหลังจากการลงทะเบียนแหล่งที่มา ซึ่งระหว่างนี้อาจมีการสร้างรายงานที่รวบรวมได้สำหรับแหล่งที่มานี้ ต้องไม่มากกว่า "หมดอายุ" สามารถจัดรูปแบบเป็นจำนวนเต็มหรือสตริงที่ไม่มีเครื่องหมาย 64 บิตก็ได้
- ลำดับความสำคัญของแหล่งที่มา (ไม่บังคับ): ใช้เพื่อเลือกแหล่งที่มาของการระบุแหล่งที่มาที่ควรเชื่อมโยงกับทริกเกอร์ที่ระบุ ในกรณีที่แหล่งที่มาของการระบุแหล่งที่มาหลายรายการเชื่อมโยงกับทริกเกอร์ได้ ต้องเป็นจำนวนเต็มที่มีเครื่องหมาย 64 บิต
ซึ่งจัดรูปแบบเป็นสตริง
เมื่อได้รับทริกเกอร์ API จะค้นหาแหล่งที่มาของการระบุแหล่งที่มาที่ตรงกันซึ่งมีค่าลำดับความสำคัญของแหล่งที่มาสูงสุดและสร้างรายงาน แพลตฟอร์มเทคโนโลยีโฆษณาแต่ละแพลตฟอร์มสามารถกำหนดกลยุทธ์ การจัดลำดับความสำคัญของตนเองได้ ดูรายละเอียดเพิ่มเติมว่าลำดับความสำคัญส่งผลต่อการระบุแหล่งที่มาอย่างไรได้ที่ส่วนตัวอย่างการจัดลำดับความสำคัญ
ค่าที่สูงบ่งบอกถึงลำดับความสำคัญที่สูงกว่า - กรอบเวลาการระบุแหล่งที่มาหลังการติดตั้งและการติดตั้ง (ไม่บังคับ): ใช้เพื่อระบุการระบุแหล่งที่มาสำหรับเหตุการณ์หลังการติดตั้ง ซึ่งจะอธิบายไว้ภายหลังในหน้านี้
- กรองข้อมูล (ไม่บังคับ): ใช้เพื่อเลือกกรองทริกเกอร์บางรายการโดยไม่สนใจทริกเกอร์นั้นอย่างมีประสิทธิภาพ ดูรายละเอียดเพิ่มเติมได้ที่ส่วนตัวกรองทริกเกอร์ในหน้านี้
- คีย์การรวม (ไม่บังคับ): ระบุการแบ่งกลุ่มที่จะใช้สำหรับรายงานแบบรวมได้
(ไม่บังคับ) การตอบกลับข้อมูลเมตาของแหล่งที่มาของการระบุแหล่งที่มาอาจมีข้อมูลเพิ่มเติมในส่วนหัวการเปลี่ยนเส้นทางการรายงานการระบุแหล่งที่มา ข้อมูลมี URL การเปลี่ยนเส้นทางที่อนุญาตให้เทคโนโลยีโฆษณาหลายรายลงทะเบียนคำขอ
คู่มือนักพัฒนาซอฟต์แวร์มีตัวอย่างที่แสดงวิธียอมรับการลงทะเบียนแหล่งที่มา
ขั้นตอนต่อไปนี้จะแสดงตัวอย่างเวิร์กโฟลว์
SDK เทคโนโลยีโฆษณานี้เรียกใช้ API เพื่อเริ่มการลงทะเบียนแหล่งที่มาของการระบุแหล่งที่มา โดยระบุ URI สำหรับ API ที่จะเรียกใช้
registerSource( Uri.parse("https://adtech.example/attribution_source?AD_TECH_PROVIDED_METADATA"), myClickEvent);API จะส่งคำขอไปยัง
https://adtech.example/attribution_source?AD_TECH_PROVIDED_METADATAโดยใช้ส่วนหัวแบบใดแบบหนึ่งต่อไปนี้<!-- For click events --> Attribution-Reporting-Source-Info: navigation <!-- For view events --> Attribution-Reporting-Source-Info: eventเซิร์ฟเวอร์ HTTPS ของเทคโนโลยีโฆษณานี้ตอบกลับด้วยส่วนหัวที่มีข้อมูลต่อไปนี้
Attribution-Reporting-Register-Source: { "destination": "android-app://com.advertiser.example", "source_event_id": "234", "expiry": "60000", "priority": "5" } Attribution-Reporting-Redirect: https://adtechpartner1.example?their_ad_click_id=567 Attribution-Reporting-Redirect: https://adtechpartner2.example?their_ad_click_id=890API จะส่งคำขอไปยัง URL แต่ละรายการที่ระบุใน
Attribution-Reporting-Redirectในตัวอย่างนี้ มีการระบุ URL ของพาร์ทเนอร์เทคโนโลยีโฆษณา 2 รายการ ดังนั้น API จะสร้างคำขอหนึ่งไปยังhttps://adtechpartner1.example?their_ad_click_id=567และอีกคำขอหนึ่งไปยังhttps://adtechpartner2.example?their_ad_click_id=890เซิร์ฟเวอร์ HTTPS ของเทคโนโลยีโฆษณานี้ตอบกลับด้วยส่วนหัวที่มีข้อมูลต่อไปนี้
Attribution-Reporting-Register-Source: { "destination": "android-app://com.advertiser.example", "source_event_id": "789", "expiry": "120000", "priority": "2" }
แหล่งที่มาของการระบุแหล่งที่มา (คลิก) ของการระบุแหล่งที่มา 3 รายการจะได้รับการบันทึกโดยอิงตามคำขอที่แสดงในขั้นตอนก่อนหน้า
ลงทะเบียนแหล่งที่มาของการระบุแหล่งที่มาจาก WebView
WebView รองรับกรณีการใช้งานที่แอปแสดงโฆษณาภายใน WebView การดำเนินการนี้ได้รับการจัดการโดย WebView ที่เรียกใช้ registerSource() โดยตรงเป็นคำขอในเบื้องหลัง การเรียกนี้จะเชื่อมโยงแหล่งที่มาของการระบุแหล่งที่มากับแอป ไม่ใช่ต้นทางระดับบนสุด นอกจากนี้ ระบบยังรองรับการลงทะเบียนแหล่งที่มาจากเนื้อหาเว็บที่ฝังอยู่ภายในบริบทของเบราว์เซอร์อีกด้วย โดยทั้งผู้โทร API และแอปต้องปรับการตั้งค่าเพื่อดำเนินการดังกล่าว โปรดดูวิธีสำหรับแอปต่างๆ ที่ลงทะเบียนแหล่งที่มาของการระบุแหล่งที่มาและทริกเกอร์จาก WebView สำหรับวิธีการสำหรับผู้โทร API และแหล่งที่มาของการระบุแหล่งที่มาและทริกเกอร์การลงทะเบียนจาก WebView
เนื่องจากเทคโนโลยีโฆษณาใช้โค้ดทั่วไปในเว็บและ WebView ระบบ WebView จึงติดตามการเปลี่ยนเส้นทาง HTTP 302 และส่งผ่านการลงทะเบียนที่ถูกต้องไปยังแพลตฟอร์ม เราไม่มีแผนที่จะรองรับส่วนหัว Attribution-Reporting-Redirect สำหรับสถานการณ์นี้ แต่ติดต่อเราหากคุณมี Use Case ที่ได้รับผลกระทบ
ลงทะเบียนทริกเกอร์ (Conversion)
แพลตฟอร์มเทคโนโลยีโฆษณาสามารถลงทะเบียนทริกเกอร์ ซึ่งเป็น Conversion เช่น เหตุการณ์การติดตั้งหรือเหตุการณ์หลังการติดตั้ง โดยใช้เมธอด registerTrigger()
เมธอด registerTrigger() ต้องการพารามิเตอร์ URI ทริกเกอร์ API ส่งคำขอไปยัง URI นี้เพื่อดึงข้อมูลเมตาที่เชื่อมโยงกับทริกเกอร์
API จะติดตามการเปลี่ยนเส้นทาง การตอบกลับของเซิร์ฟเวอร์เทคโนโลยีโฆษณาควรมีส่วนหัว HTTP ชื่อ Attribution-Reporting-Register-Trigger ซึ่งแสดงข้อมูลของทริกเกอร์ที่ลงทะเบียนอย่างน้อย 1 รายการ เนื้อหาของส่วนหัวควรเข้ารหัส JSON
และมีช่องต่อไปนี้
- ข้อมูลทริกเกอร์: ข้อมูลที่จะระบุเหตุการณ์ทริกเกอร์ (3 บิตสำหรับการคลิก และ 1 บิตสำหรับข้อมูลพร็อพเพอร์ตี้) ต้องเป็นจำนวนเต็มแบบมีเครื่องหมาย 64 บิตที่จัดรูปแบบเป็นสตริง
- ลำดับความสำคัญของทริกเกอร์ (ไม่บังคับ): แสดงลำดับความสำคัญของทริกเกอร์นี้เมื่อเทียบกับทริกเกอร์อื่นๆ สำหรับแหล่งที่มาเดียวกัน ต้องเป็นจำนวนเต็มแบบมีเครื่องหมาย 64 บิตที่จัดรูปแบบเป็นสตริง ดูรายละเอียดเพิ่มเติมว่าลำดับความสำคัญส่งผลต่อการรายงานอย่างไรได้ที่ส่วนการจัดลำดับความสำคัญ
- คีย์การกรองข้อมูลที่ซ้ำกันออก (ไม่บังคับ): ใช้เพื่อระบุกรณีที่แพลตฟอร์มเทคโนโลยีโฆษณาเดียวกันลงทะเบียนทริกเกอร์เดียวกันหลายครั้งสำหรับแหล่งที่มาของการระบุแหล่งที่มาเดียวกัน ต้องเป็นจำนวนเต็มแบบมีเครื่องหมาย 64 บิตที่จัดรูปแบบเป็นสตริง
- คีย์การรวม (ไม่บังคับ): คือรายการพจนานุกรมที่ระบุคีย์การรวม และรายงานแบบรวมที่ควรมีการรวมค่า
- ค่าการรวม (ไม่บังคับ): รายการจำนวนค่าที่เกี่ยวข้องกับแต่ละคีย์
- ตัวกรอง (ไม่บังคับ): ใช้เพื่อเลือกกรองทริกเกอร์หรือทริกเกอร์ข้อมูล ดูรายละเอียดเพิ่มเติมได้ที่ส่วนตัวกรองทริกเกอร์ในหน้านี้
การตอบกลับของเซิร์ฟเวอร์เทคโนโลยีโฆษณาอาจมีข้อมูลเพิ่มเติมในส่วนหัวการเปลี่ยนเส้นทางการรายงานการระบุแหล่งที่มา (ไม่บังคับ) ข้อมูลมี URL เปลี่ยนเส้นทาง ซึ่งอนุญาตให้เทคโนโลยีโฆษณาหลายรายการลงทะเบียนคำขอได้
เทคโนโลยีโฆษณาหลายรายการจะบันทึกเหตุการณ์ทริกเกอร์เดียวกันได้โดยใช้การเปลี่ยนเส้นทางในช่อง Attribution-Reporting-Redirect หรือเรียกใช้เมธอด registerTrigger() หลายครั้ง เราขอแนะนำให้ใช้ช่องคีย์การกรองข้อมูลที่ซ้ำกันเพื่อหลีกเลี่ยงไม่ให้รวมทริกเกอร์ที่ซ้ำกันในรายงานในกรณีที่เทคโนโลยีโฆษณาเดียวกันให้การตอบกลับหลายครั้งสำหรับเหตุการณ์ทริกเกอร์เดียวกัน ดูข้อมูลเพิ่มเติมเกี่ยวกับวิธีและเวลาในการใช้คีย์การกรองข้อมูลที่ซ้ำกันออก
คู่มือนักพัฒนาซอฟต์แวร์มีตัวอย่างที่แสดงวิธียอมรับการลงทะเบียนทริกเกอร์
ขั้นตอนต่อไปนี้จะแสดงตัวอย่างเวิร์กโฟลว์
SDK เทคโนโลยีโฆษณาเรียกใช้ API เพื่อเริ่มการลงทะเบียนทริกเกอร์โดยใช้ URI ที่ลงทะเบียนล่วงหน้า ดูลงทะเบียนบัญชี Privacy Sandbox สำหรับข้อมูลเพิ่มเติม
registerTrigger( Uri.parse("https://adtech.example/attribution_trigger?AD_TECH_PROVIDED_METADATA"));API ส่งคำขอไปยัง
https://adtech.example/attribution_trigger?AD_TECH_PROVIDED_METADATAเซิร์ฟเวอร์ HTTPS ของเทคโนโลยีโฆษณานี้ตอบกลับด้วยส่วนหัวที่มีข้อมูลต่อไปนี้
Attribution-Reporting-Register-Trigger: { "event_trigger_data": [{ "trigger_data": "1122", // This returns 010 for click-through conversions (CTCs) and 0 for // view-through conversions (VTCs) in reports "priority": "3", "deduplication_key": "3344" }], } Attribution-Reporting-Redirect: https://adtechpartner.example?app_install=567API จะส่งคำขอไปยัง URL แต่ละรายการที่ระบุใน
Attribution-Reporting-Redirectในตัวอย่างนี้ มีการระบุ URL เพียง 1 รายการ API จึงจะส่งคำขอไปยังhttps://adtechpartner.example?app_install=567เซิร์ฟเวอร์ HTTPS ของเทคโนโลยีโฆษณานี้ตอบกลับด้วยส่วนหัวที่มีข้อมูลต่อไปนี้
Attribution-Reporting-Register-Trigger: { "event_trigger_data":[{ "trigger_data": "5566", "priority": "3", "deduplication_key": "3344" }] }จะมีการลงทะเบียนทริกเกอร์ 2 รายการตามคำขอในขั้นตอนก่อนหน้า
ความสามารถในการระบุแหล่งที่มา
ส่วนต่อไปนี้จะอธิบายวิธีที่ Attribution Reporting API จับคู่ทริกเกอร์ Conversion กับแหล่งที่มาของการระบุแหล่งที่มา
ใช้อัลกอริทึมการระบุแหล่งที่มาแบบจัดลำดับความสำคัญแหล่งที่มา
Attribution Reporting API ใช้อัลกอริทึมการระบุแหล่งที่มาตามลำดับความสำคัญในการจับคู่ทริกเกอร์ (Conversion) กับแหล่งที่มาของการระบุแหล่งที่มา
พารามิเตอร์ลำดับความสำคัญให้วิธีปรับแต่งการระบุแหล่งที่มาของทริกเกอร์เป็นแหล่งที่มา ดังนี้
- คุณกำหนดแหล่งที่มาของทริกเกอร์ให้กับเหตุการณ์โฆษณาบางอย่างมากกว่าเหตุการณ์อื่นๆ ได้ เช่น คุณอาจเลือกเน้นที่จำนวนคลิกมากกว่ายอดดู หรือเน้นเหตุการณ์จากบางแคมเปญ
- คุณสามารถกำหนดค่าแหล่งที่มาของการระบุแหล่งที่มาและทริกเกอร์ให้ทำเช่นนั้นได้ หากถึงขีดจำกัดของอัตราแล้ว คุณก็มีแนวโน้มที่จะได้รับรายงานที่สำคัญกับคุณมากกว่า ตัวอย่างเช่น คุณอาจต้องการทำให้แน่ใจว่า Conversion ที่เสนอราคาได้หรือ Conversion ที่มีมูลค่าสูงมีแนวโน้มที่จะปรากฏในรายงานเหล่านี้มากกว่า
ในกรณีที่เทคโนโลยีโฆษณาหลายรายการได้ลงทะเบียนแหล่งที่มาของการระบุแหล่งที่มา ตามที่อธิบายไว้ภายหลังในหน้านี้ การระบุแหล่งที่มานี้จะเกิดขึ้นแยกกันสำหรับเทคโนโลยีโฆษณาแต่ละชนิด สำหรับเทคโนโลยีโฆษณาแต่ละรายการ แหล่งที่มาของการระบุแหล่งที่มาที่มีลำดับความสำคัญสูงสุดจะได้รับการระบุแหล่งที่มาให้กับเหตุการณ์ทริกเกอร์ หากมีแหล่งที่มาของการระบุแหล่งที่มาหลายแห่งที่มีลำดับความสำคัญเหมือนกัน API จะเลือกแหล่งที่มาของการระบุแหล่งที่มาที่จดทะเบียนล่าสุด แหล่งที่มาของการระบุแหล่งที่มาอื่นๆ ที่ไม่ได้เลือกจะถูกทิ้งไป และจะไม่มีสิทธิ์ใช้การระบุแหล่งที่มาของทริกเกอร์ในอนาคตอีกต่อไป
ตัวกรองทริกเกอร์
การลงทะเบียนแหล่งที่มาและทริกเกอร์มีฟังก์ชันการทำงานเพิ่มเติมที่ไม่บังคับเพื่อทำสิ่งต่อไปนี้
- เลือกกรองทริกเกอร์บางรายการ โดยไม่สนใจทริกเกอร์นั้นอย่างมีประสิทธิภาพ
- เลือกข้อมูลทริกเกอร์สำหรับรายงานระดับเหตุการณ์ตามข้อมูลแหล่งที่มา
- เลือกยกเว้นทริกเกอร์จากรายงานระดับเหตุการณ์
หากต้องการเลือกกรองทริกเกอร์ เทคโนโลยีโฆษณาสามารถระบุข้อมูลตัวกรอง ซึ่งประกอบด้วยคีย์และค่าระหว่างการลงทะเบียนต้นทางและทริกเกอร์ หากมีการระบุคีย์เดียวกันสำหรับทั้งแหล่งที่มาและทริกเกอร์ ทริกเกอร์จะถูกละเว้นหากสี่แยกว่างเปล่า เช่น แหล่งที่มาสามารถระบุ "product": ["1234"] โดยที่ product คือคีย์ตัวกรอง และ 1234 คือค่า หากตั้งค่าตัวกรองทริกเกอร์เป็น "product": ["1111"] ระบบจะไม่สนใจทริกเกอร์ หากไม่มีคีย์ตัวกรองทริกเกอร์ที่ตรงกับ product ระบบจะไม่สนใจตัวกรอง
อีกสถานการณ์หนึ่งที่แพลตฟอร์มเทคโนโลยีโฆษณาอาจต้องการกรองทริกเกอร์บางรายการคือการบังคับให้กรอบเวลาหมดอายุสั้นลง ในการลงทะเบียนทริกเกอร์ เทคโนโลยีโฆษณาสามารถระบุกรอบเวลามองย้อนกลับ (เป็นวินาที) จากเวลาที่เกิด Conversion เช่น กรอบเวลามองย้อนกลับ 7 วันจะหมายถึง "_lookback_window":
604800 // 7d
หากต้องการตัดสินว่าตัวกรองตรงกันหรือไม่ API จะตรวจสอบกรอบเวลามองย้อนกลับก่อน หากมี ระยะเวลาตั้งแต่ที่มีการลงทะเบียนแหล่งที่มาจะต้องน้อยกว่าหรือเท่ากับระยะเวลาของกรอบเวลามองย้อนกลับ
แพลตฟอร์มเทคโนโลยีโฆษณายังเลือกข้อมูลทริกเกอร์โดยอิงตามข้อมูลเหตุการณ์แหล่งที่มาได้ด้วย เช่น 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 จะตรวจสอบเมื่อเกิดการติดตั้งแอปและระบุแหล่งที่มาของการติดตั้งเป็นแหล่งที่มาภายในที่มีแหล่งที่มาเป็นแหล่งที่มา แต่จะไม่ส่งการติดตั้งไปยังเทคโนโลยีโฆษณา และจะไม่นับรวมในขีดจำกัดอัตราที่เกี่ยวข้องของแพลตฟอร์ม
- การตรวจสอบการติดตั้งแอปใช้ได้กับแอปที่ดาวน์โหลดมา
- ทริกเกอร์ใดๆ ในอนาคตที่เกิดขึ้นภายในกรอบเวลาการระบุแหล่งที่มาหลังการติดตั้งจะมาจากแหล่งที่มาของการระบุแหล่งที่มาเดียวกันกับการติดตั้งที่ผ่านการตรวจสอบ ตราบใดที่แหล่งที่มาของการระบุแหล่งที่มานั้นมีสิทธิ์
ในอนาคต เราอาจพิจารณาขยายเวลาการออกแบบเพื่อรองรับรูปแบบการระบุแหล่งที่มาขั้นสูงยิ่งขึ้น
ตารางต่อไปนี้แสดงตัวอย่างวิธีที่เทคโนโลยีโฆษณาอาจใช้การระบุแหล่งที่มาหลังการติดตั้ง สมมติว่าเครือข่ายเทคโนโลยีโฆษณาเดียวกันลงทะเบียนแหล่งที่มาของการระบุแหล่งที่มาและทริกเกอร์ทั้งหมด และลำดับความสำคัญทั้งหมดเหมือนกัน
| เหตุการณ์ | วันที่เกิดเหตุการณ์ | Notes |
|---|---|---|
| คลิก 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 ที่ลงทะเบียนโดยเทคโนโลยีโฆษณา ในตัวอย่างนี้ ทริกเกอร์ที่ 2 แสดงถึง Conversion หลังการติดตั้ง เช่น การซื้อ ระบุแหล่งที่มาว่าคลิก 1 (ตรงกับการระบุแหล่งที่มาของการติดตั้งที่ยืนยันแล้ว) ระบบทิ้งคลิก 2 และจะไม่มีสิทธิ์ใช้การระบุแหล่งที่มาในอนาคต |
รายการต่อไปนี้แสดงหมายเหตุเพิ่มเติมเกี่ยวกับการระบุแหล่งที่มาหลังการติดตั้ง
- หากการติดตั้งที่ยืนยันแล้วไม่ได้เกิดขึ้นภายในจำนวนวันที่ระบุโดย
install_attribution_windowจะไม่มีการระบุแหล่งที่มาหลังการติดตั้ง - เทคโนโลยีโฆษณาไม่ได้ลงทะเบียนการติดตั้งที่ยืนยันแล้ว และจะไม่มีการส่งออกไปในรายงาน ระบบจะไม่นับรวมในขีดจำกัดอัตราของเทคโนโลยีโฆษณา การติดตั้งที่ยืนยันแล้วจะใช้ในการระบุแหล่งที่มาของการระบุแหล่งที่มาที่รับเครดิตจากการติดตั้งเท่านั้น
- ในตัวอย่างจากตารางก่อนหน้านี้ ทริกเกอร์ 1 และทริกเกอร์ 2 แสดงถึง Conversion การเปิดครั้งแรกและ Conversion หลังการติดตั้งตามลำดับ แต่แพลตฟอร์มเทคโนโลยีโฆษณา จะใช้ทริกเกอร์ประเภทใดก็ได้ กล่าวคือ ทริกเกอร์แรกไม่จำเป็นต้องเป็นทริกเกอร์เปิดแรก
- หากมีการบันทึกทริกเกอร์เพิ่มเติมหลังจากที่
post_install_exclusivity_windowหมดอายุ คลิก 1 จะยังคงมีสิทธิ์สำหรับการระบุแหล่งที่มา ในกรณีที่ทริกเกอร์นั้นยังไม่หมดอายุและยังไม่ถึงขีดจำกัดอัตรา- คลิก 1 อาจยังคงสูญเสียหรือถูกยกเลิก หากมีการลงทะเบียนแหล่งที่มาของการระบุแหล่งที่มาที่มีลำดับความสำคัญสูงกว่า
- หากแอปของผู้ลงโฆษณาถูกถอนการติดตั้งและติดตั้งอีกครั้ง ระบบจะนับการติดตั้งอีกครั้งเป็นการติดตั้งใหม่ที่ยืนยันแล้ว
- หากคลิก 1 เป็นเหตุการณ์การดูแทน ทั้งทริกเกอร์ "การเปิดครั้งแรก" และทริกเกอร์หลังการติดตั้งจะยังถือว่าเป็นเหตุการณ์ดังกล่าว API จะจำกัดการระบุแหล่งที่มาไว้ที่ 1 ทริกเกอร์ต่อข้อมูลพร็อพเพอร์ตี้ ยกเว้นในกรณีการระบุแหล่งที่มาหลังการติดตั้งที่อนุญาตให้ใช้ทริกเกอร์ได้สูงสุด 2 รายการต่อข้อมูลพร็อพเพอร์ตี้ ในกรณีการระบุแหล่งที่มาหลังการติดตั้ง เทคโนโลยีโฆษณาอาจได้รับกรอบเวลาการรายงาน 2 ช่วง (ที่ 2 วันหรือที่ต้นทางหมดอายุ)
ระบบรองรับชุดค่าผสมของเส้นทางทริกเกอร์แบบแอปและเว็บทั้งหมด
Attribution Reporting API เปิดใช้การระบุแหล่งที่มาของเส้นทางทริกเกอร์ต่อไปนี้ในอุปกรณ์ Android เครื่องเดียว
- App-to-app: ผู้ใช้เห็นโฆษณาในแอป แล้วทำ Conversion ในแอปนั้นหรือในแอปอื่นๆ ที่ติดตั้ง
- App-to-web: ผู้ใช้เห็นโฆษณาในแอป แล้วทํา Conversion ในเบราว์เซอร์ในอุปกรณ์เคลื่อนที่หรือในแอป
- Web-to-app: ผู้ใช้เห็นโฆษณาในเบราว์เซอร์ในอุปกรณ์เคลื่อนที่หรือของแอป แล้วทำ Conversion ในแอป
- Web-to-web: ผู้ใช้เห็นโฆษณาในเบราว์เซอร์ในอุปกรณ์เคลื่อนที่หรือของแอป แล้วทำ Conversion ในเบราว์เซอร์เดียวกันหรือเบราว์เซอร์อื่นในอุปกรณ์เดียวกัน
เราอนุญาตให้เว็บเบราว์เซอร์รองรับฟังก์ชันการทำงานใหม่ๆ ในเว็บ เช่น ฟังก์ชันการทำงานที่คล้ายกับ Privacy Sandbox สำหรับ Attribution Reporting API ของเว็บ ซึ่งเรียกใช้ Android API ได้เพื่อเปิดใช้การระบุแหล่งที่มาในแอปและเว็บ
ดูข้อมูลเกี่ยวกับการเปลี่ยนแปลงที่เทคโนโลยีโฆษณาและแอปต้องทำเพื่อรองรับเส้นทางทริกเกอร์สำหรับการวัดผลข้ามแอปและเว็บ
ให้ความสำคัญกับทริกเกอร์หลายรายการสำหรับแหล่งที่มาของการระบุแหล่งที่มาเดียว
แหล่งที่มาของการระบุแหล่งที่มาเดียวอาจทำให้เกิดทริกเกอร์หลายรายการ เช่น ขั้นตอนการซื้ออาจเกี่ยวข้องกับทริกเกอร์ "การติดตั้งแอป" ทริกเกอร์ "เพิ่มลงในรถเข็น" อย่างน้อย 1 รายการ และทริกเกอร์ "การซื้อ" ทริกเกอร์แต่ละรายการจะมาจากแหล่งที่มาของการระบุแหล่งที่มา 1 รายการขึ้นไปตามอัลกอริทึมการระบุแหล่งที่มาแบบจัดลำดับความสำคัญตามแหล่งที่มา ซึ่งจะอธิบายไว้ภายหลังในหน้านี้
เรามีข้อจํากัดเกี่ยวกับจํานวนทริกเกอร์ที่สามารถระบุแหล่งที่มาไปยังแหล่งที่มาของการระบุแหล่งที่มาแหล่งเดียว อ่านรายละเอียดเพิ่มเติมได้ที่ส่วนการดูข้อมูลการวัดผลในรายงานการระบุแหล่งที่มาภายหลังในหน้านี้ ในกรณีที่มีตัวทริกเกอร์จำนวนมากเกินขีดจำกัดเหล่านี้ การใช้ตรรกะการจัดลำดับความสำคัญเพื่อดึงทริกเกอร์ที่มีค่าที่สุดกลับมาก็มีประโยชน์ เช่น นักพัฒนาเทคโนโลยีโฆษณาอาจต้องการให้ความสำคัญกับการได้รับทริกเกอร์ "การซื้อ" มากกว่าทริกเกอร์ "เพิ่มลงในรถเข็น"
เพื่อรองรับตรรกะนี้ คุณสามารถกำหนดช่องลำดับความสำคัญแยกต่างหากให้กับทริกเกอร์ได้ และจะเลือกทริกเกอร์ที่มีลำดับความสำคัญสูงสุดก่อนใช้ขีดจำกัดภายในกรอบเวลาการรายงานที่กำหนด
อนุญาตให้เทคโนโลยีโฆษณาหลายรายการลงทะเบียนแหล่งที่มาของการระบุแหล่งที่มาหรือทริกเกอร์
การที่เทคโนโลยีโฆษณามากกว่า 1 อย่างนั้นมักจะได้รับรายงานการระบุแหล่งที่มา ซึ่งมักจะทำการกรองข้อมูลที่ซ้ำกันออกข้ามเครือข่าย ดังนั้น API จึงช่วยให้เทคโนโลยีโฆษณาหลายรายการลงทะเบียนแหล่งที่มาของการระบุแหล่งที่มาหรือทริกเกอร์เดียวกันได้ เทคโนโลยีโฆษณาต้องลงทะเบียนทั้งแหล่งที่มาของการระบุแหล่งที่มาและทริกเกอร์เพื่อรับระบบรายงานผล Conversion จาก API และการระบุแหล่งที่มาจะดำเนินการในแหล่งที่มาของการระบุแหล่งที่มาและทริกเกอร์ที่เทคโนโลยีโฆษณาได้ลงทะเบียนไว้กับ API
ผู้ลงโฆษณาที่ต้องการใช้บุคคลที่สามในการกรองข้อมูลข้ามเครือข่ายที่ซ้ำกันออกสามารถดำเนินการดังกล่าวต่อไปได้ โดยใช้เทคนิคที่คล้ายกับตัวอย่างต่อไปนี้
- การตั้งค่าเซิร์ฟเวอร์ภายในองค์กรเพื่อลงทะเบียนและรับรายงานจาก API
- การใช้พาร์ทเนอร์การวัดผลบนอุปกรณ์เคลื่อนที่ที่มีอยู่ต่อไป
แหล่งที่มาของการระบุแหล่งที่มา
การเปลี่ยนเส้นทางแหล่งที่มาของการระบุแหล่งที่มาใช้งานได้ในเมธอด registerSource() ดังนี้
- เทคโนโลยีโฆษณาที่เรียกใช้เมธอด
registerSource()จะมีช่องAttribution-Reporting-Redirectเพิ่มเติมในการตอบกลับ ซึ่งแสดงถึงชุด URL เปลี่ยนเส้นทางของเทคโนโลยีโฆษณาของพาร์ทเนอร์ - จากนั้น API จะเรียก URL เปลี่ยนเส้นทางเพื่อให้เทคโนโลยีโฆษณาของพาร์ทเนอร์ลงทะเบียนแหล่งที่มาของการระบุแหล่งที่มาได้
คุณแสดง URL เทคโนโลยีโฆษณาของพาร์ทเนอร์หลายรายการในช่อง Attribution-Reporting-Redirect ได้ และเทคโนโลยีโฆษณาของพาร์ทเนอร์จะระบุช่อง Attribution-Reporting-Redirect ของตนเองไม่ได้
นอกจากนี้ API ยังรองรับเทคโนโลยีโฆษณาที่แตกต่างกันสำหรับการเรียก registerSource() แต่ละครั้งด้วย
ทริกเกอร์
สำหรับการลงทะเบียนทริกเกอร์ บุคคลที่สามจะได้รับการสนับสนุนในลักษณะที่คล้ายกัน คือ เทคโนโลยีโฆษณาจะใช้ช่อง Attribution-Reporting-Redirect เพิ่มเติมหรือเรียกใช้เมธอด registerTrigger() ก็ได้
เมื่อผู้ลงโฆษณาใช้เทคโนโลยีโฆษณาหลายรูปแบบในการลงทะเบียนเหตุการณ์ทริกเกอร์เดียวกัน คุณควรใช้คีย์การกรองข้อมูลที่ซ้ำกันออก คีย์การกรองข้อมูลที่ซ้ำกันออกช่วยแยกแยะรายงานที่ซ้ำกันเหล่านี้ของเหตุการณ์เดียวกันที่ลงทะเบียนไว้โดยแพลตฟอร์มเทคโนโลยีโฆษณาเดียวกัน เช่น เทคโนโลยีโฆษณาอาจให้ SDK เรียกใช้ API โดยตรงเพื่อลงทะเบียนทริกเกอร์ และมี URL ในช่องการเปลี่ยนเส้นทางของการเรียกของเทคโนโลยีโฆษณาอื่น หากไม่ได้ให้คีย์การกรองข้อมูลที่ซ้ำกันออก ระบบอาจรายงานทริกเกอร์ที่ซ้ำกันกลับไปยังเทคโนโลยีโฆษณาแต่ละรายการว่าไม่ซ้ำกัน
จัดการทริกเกอร์ที่ซ้ำกัน
เทคโนโลยีโฆษณาอาจบันทึกทริกเกอร์เดียวกันหลายครั้งกับ API สถานการณ์มีดังนี้
- ผู้ใช้ดำเนินการ (ทริกเกอร์) เดียวกันหลายครั้ง เช่น ผู้ใช้เรียกดูผลิตภัณฑ์เดียวกันหลายครั้งในหน้าต่างการรายงานเดียวกัน
- แอปของผู้ลงโฆษณาใช้ SDK หลายรายการสำหรับการวัด Conversion ซึ่งทั้งหมดเปลี่ยนเส้นทางไปยังเทคโนโลยีโฆษณาเดียวกัน เช่น แอปของผู้ลงโฆษณาใช้พาร์ทเนอร์การวัดผล 2 ราย คือ MMP #1 และ MMP #2 MMP ทั้ง 2 รายการเปลี่ยนเส้นทางไปยังเทคโนโลยีโฆษณา #3 เมื่อทริกเกอร์เกิดขึ้น MMP ทั้ง 2 ตัวจะลงทะเบียนที่ทริกเกอร์ด้วย Attribution Reporting API จากนั้นเทคโนโลยีโฆษณา #3 จะได้รับการเปลี่ยนเส้นทาง 2 รายการแยกกัน โดยครั้งแรกจาก MMP #1 และครั้งที่ 2 จาก 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 รายการ (เทคโนโลยีโฆษณา A และเทคโนโลยีโฆษณา B) และพาร์ทเนอร์การวัดผล (MMP) 1 ราย
ในการเริ่มต้น เทคโนโลยีโฆษณา 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: ผู้ใช้คลิกโฆษณาที่แสดงโดยเทคโนโลยีโฆษณา B
เทคโนโลยีโฆษณา B เรียกใช้
registerSource()ด้วย URI API จะส่งคำขอไปยัง URI และการคลิกดังกล่าวจะได้รับการลงทะเบียนกับข้อมูลเมตาจากการตอบกลับของเซิร์ฟเวอร์เทคโนโลยีโฆษณา Bเทคโนโลยีโฆษณา B ก็รวม URI ของ MMP ในส่วนหัว
Attribution-Reporting-Redirectด้วยเช่นกัน เช่นเดียวกับเทคโนโลยีโฆษณา A API จะส่งคำขอไปยัง URI ของ MMP และการคลิกจะได้รับการลงทะเบียนกับข้อมูลเมตาจากการตอบกลับของเซิร์ฟเวอร์ของ MMP- วันที่ 3: ผู้ใช้ดูโฆษณาที่แสดงโดยเทคโนโลยีโฆษณา A
API จะตอบสนองในแบบเดียวกับที่เกิดขึ้นในวันที่ 1 ยกเว้นว่ามีการลงทะเบียนข้อมูลพร็อพเพอร์ตี้สำหรับเทคโนโลยีโฆษณา A และ MMP
- วันที่ 4: ผู้ใช้ติดตั้งแอป ซึ่งใช้ MMP ในการวัด Conversion
MMP เรียกใช้
registerTrigger()ด้วย URI API จะส่งคำขอไปยัง URL และระบบจะลงทะเบียน Conversion พร้อมกับข้อมูลเมตาจากการตอบกลับของเซิร์ฟเวอร์ของ MMPนอกจากนี้ MMP ยังมี URI สำหรับเทคโนโลยีโฆษณา A และเทคโนโลยีโฆษณา B ในส่วนหัว
Attribution-Reporting-Redirectด้วย API จะส่งคำขอไปยังเซิร์ฟเวอร์ของเทคโนโลยีโฆษณา A และเทคโนโลยีโฆษณา B และ Conversion จะได้รับการลงทะเบียนให้สอดคล้องกับข้อมูลเมตาจากการตอบสนองของเซิร์ฟเวอร์
แผนภาพต่อไปนี้แสดงกระบวนการที่อธิบายไว้ในรายการก่อนหน้านี้
การระบุแหล่งที่มามีการทำงานดังนี้
- เทคโนโลยีโฆษณา A กำหนดลำดับความสำคัญของการคลิกสูงกว่ายอดดู จึงได้รับการติดตั้งที่มาจากคลิกในวันที่ 1
- เทคโนโลยีโฆษณา B ได้รับการระบุแหล่งที่มาจากการติดตั้งในวันที่ 2
- MMP กำหนดลำดับความสำคัญของคลิกสูงกว่ายอดดู และรับการติดตั้งที่ระบุมาจากการคลิกในวันที่ 2 คลิกของวันที่ 2 มีลำดับความสำคัญสูงสุด เหตุการณ์โฆษณาล่าสุด
การระบุแหล่งที่มาข้ามเครือข่ายโดยไม่มีการเปลี่ยนเส้นทาง
แม้ว่าเราจะแนะนำให้ใช้การเปลี่ยนเส้นทางเพื่ออนุญาตให้เทคโนโลยีโฆษณาจำนวนมากลงทะเบียนแหล่งที่มาและทริกเกอร์การระบุแหล่งที่มาได้ แต่เราก็ตระหนักดีว่าอาจมีสถานการณ์ที่การใช้การเปลี่ยนเส้นทางไม่สามารถทำได้ ส่วนนี้จะแสดงรายละเอียดวิธีรองรับ การระบุแหล่งที่มาข้ามเครือข่ายโดยไม่ต้องเปลี่ยนเส้นทาง
โฟลว์ระดับสูง
- ในการลงทะเบียนแหล่งที่มา เครือข่ายเทคโนโลยีโฆษณาที่แสดงจะแชร์คีย์การรวมแหล่งที่มา
- ในการลงทะเบียนทริกเกอร์ ผู้ลงโฆษณาหรือพาร์ทเนอร์การวัดผลจะเลือกชิ้นส่วนสำคัญของฝั่งแหล่งที่มาที่จะใช้และระบุการกําหนดค่าการระบุแหล่งที่มา
- การระบุแหล่งที่มาจะอิงตามการกําหนดค่าการระบุแหล่งที่มา คีย์ที่แชร์ และแหล่งที่มาใดๆ ที่ได้ลงทะเบียนไว้โดยผู้ลงโฆษณาหรือพาร์ทเนอร์การวัดผลนั้นๆ (เช่น จากเครือข่ายเทคโนโลยีโฆษณาอื่นที่แสดงโฆษณาซึ่งเปิดใช้การเปลี่ยนเส้นทาง)
- หากทริกเกอร์ได้รับการระบุแหล่งที่มาว่ามาจากแหล่งที่มาจากเทคโนโลยีโฆษณาที่ไม่เปลี่ยนเส้นทาง ผู้ลงโฆษณาหรือพาร์ทเนอร์การวัดผลจะได้รับรายงานที่รวบรวมได้ ซึ่งจะรวมส่วนสำคัญของแหล่งที่มาและทริกเกอร์ซึ่งกำหนดไว้ในขั้นตอนที่ 2
การลงทะเบียนแหล่งที่มา
ในการลงทะเบียนแหล่งที่มา เครือข่ายเทคโนโลยีโฆษณาที่แสดงโฆษณาสามารถเลือกแชร์คีย์การรวมแหล่งที่มาหรือคีย์การรวมแหล่งที่มาบางส่วนแทนการเปลี่ยนเส้นทางได้ เทคโนโลยีโฆษณาสำหรับการแสดงโฆษณาไม่จำเป็นต้องใช้คีย์แหล่งที่มาเหล่านี้ในรายงานที่รวบรวมได้ของตนเอง และจะประกาศคีย์ดังกล่าวในนามของผู้ลงโฆษณาหรือพาร์ทเนอร์การวัดผลได้เมื่อจำเป็นเท่านั้น
คีย์การรวมข้อมูลที่แชร์ใช้ได้กับเทคโนโลยีโฆษณาทั้งหมดที่ลงทะเบียนทริกเกอร์สำหรับผู้ลงโฆษณารายเดียวกัน แต่การจะทำงานร่วมกันในด้านประเภทของคีย์การรวมที่จำเป็นต้องใช้ ชื่อคีย์ และวิธีถอดรหัสคีย์ให้เป็นมิติข้อมูลที่อ่านได้นั้นจะขึ้นอยู่กับเทคโนโลยีโฆษณาการแสดงโฆษณาและทริกเกอร์การวัดผล
การลงทะเบียนทริกเกอร์
ในการลงทะเบียนทริกเกอร์ เทคโนโลยีโฆษณาเพื่อการวัดผลจะเลือกชิ้นส่วนสำคัญด้านแหล่งที่มาที่จะใช้กับแต่ละคีย์ของทริกเกอร์ ซึ่งรวมถึงส่วนที่แชร์โดยเทคโนโลยีโฆษณาสำหรับการแสดงโฆษณา
นอกจากนี้ เทคโนโลยีโฆษณาเพื่อการวัดผลต้องระบุตรรกะการระบุแหล่งที่มาของ Waterfall โดยใช้การเรียก API การกําหนดค่าการระบุแหล่งที่มาใหม่ด้วย ในการกำหนดค่านี้ เทคโนโลยีโฆษณาสามารถระบุลำดับความสำคัญของแหล่งที่มา วันหมดอายุ และตัวกรองสำหรับแหล่งที่มาที่มองไม่เห็น (เช่น แหล่งที่มาที่ไม่ได้ใช้การเปลี่ยนเส้นทาง)
การระบุแหล่งที่มา
Attribution Reporting API ทำการระบุแหล่งที่มาที่มีการโต้ตอบสุดท้ายซึ่งให้ความสำคัญกับแหล่งที่มาเป็นสำคัญสำหรับเทคโนโลยีโฆษณาเพื่อการวัดผลโดยอิงจากการกำหนดค่าการระบุแหล่งที่มา คีย์ที่แชร์ และแหล่งที่มาที่ได้ลงทะเบียนไว้ เช่น
- ผู้ใช้คลิกที่โฆษณาที่แสดงโดยเทคโนโลยีโฆษณา A, B, C และ D จากนั้นผู้ใช้จึงติดตั้งแอปของผู้ลงโฆษณา ซึ่งใช้พาร์ทเนอร์เทคโนโลยีโฆษณา (MMP)
- เทคโนโลยีโฆษณา A เปลี่ยนเส้นทางแหล่งที่มาไปยัง MMP
- เทคโนโลยีโฆษณา B และ C จะไม่เปลี่ยนเส้นทาง แต่แชร์คีย์การรวม
- เทคโนโลยีโฆษณา D ไม่ได้เปลี่ยนเส้นทางหรือใช้คีย์การรวม
MMP จะลงทะเบียนแหล่งที่มาจากเทคโนโลยีโฆษณา A และกำหนดการกําหนดค่าการระบุแหล่งที่มาที่รวมเทคโนโลยีโฆษณา B และเทคโนโลยีโฆษณา D
การระบุแหล่งที่มาของ MMP ประกอบด้วยรายการต่อไปนี้
- เทคโนโลยีโฆษณา A เนื่องจาก MMP ได้ลงทะเบียนแหล่งที่มาจากการเปลี่ยนเส้นทางของเทคโนโลยีโฆษณานั้น
- เทคโนโลยีโฆษณา B เนื่องจากเทคโนโลยีโฆษณา B ได้แชร์คีย์และ MMP ได้รวมคีย์ดังกล่าวไว้ในการกําหนดค่าการระบุแหล่งที่มา
การระบุแหล่งที่มาของ MMP ไม่รวมถึงสิ่งต่อไปนี้
- เทคโนโลยีโฆษณา C เนื่องจาก MMP ไม่ได้รวมไว้ในการกําหนดค่าการระบุแหล่งที่มา
- เทคโนโลยีโฆษณา D เนื่องจากไม่ได้เปลี่ยนเส้นทางหรือแชร์คีย์การรวม
การแก้ไขข้อบกพร่อง
ช่องเพิ่มเติมคือ shared_debug_key ซึ่งมีไว้สำหรับเทคโนโลยีโฆษณาที่จะตั้งค่าเมื่อลงทะเบียนแหล่งที่มาเพื่อรองรับการแก้ไขข้อบกพร่องสำหรับการระบุแหล่งที่มาข้ามเครือข่ายโดยไม่มีการเปลี่ยนเส้นทาง หากตั้งค่าการลงทะเบียนแหล่งที่มาเดิม ระบบจะตั้งค่าแหล่งที่มาที่ดึงมาที่เกี่ยวข้องเป็น debug_key ระหว่างการลงทะเบียนทริกเกอร์สำหรับการระบุแหล่งที่มาข้ามเครือข่ายโดยไม่มีการเปลี่ยนเส้นทาง คีย์การแก้ไขข้อบกพร่องนี้จะแนบเป็น source_debug_key ในรายงานเหตุการณ์และรายงานสรุป
ฟีเจอร์การแก้ไขข้อบกพร่องนี้จะรองรับการระบุแหล่งที่มาข้ามเครือข่ายเท่านั้นโดยไม่มีการเปลี่ยนเส้นทางในสถานการณ์ต่อไปนี้
- การวัดผลระหว่างแอปกับแอปที่อนุญาต รหัสโฆษณา
- การวัดผลระหว่างแอปกับเว็บที่อนุญาตให้ใช้ AdId และจับคู่ ทั้งแหล่งที่มาของแอปและทริกเกอร์เว็บ
- การวัดผลจากเว็บไปยังเว็บ (ในแอปเบราว์เซอร์เดียวกัน) เมื่อ
ar_debugแสดงอยู่ในทั้งแหล่งที่มาและทริกเกอร์
การค้นพบหลักสำหรับการระบุแหล่งที่มาข้ามเครือข่ายโดยไม่มีการเปลี่ยนเส้นทาง
การค้นพบหลักมีจุดประสงค์เพื่อปรับปรุงวิธีที่เทคโนโลยีโฆษณา (โดยทั่วไปคือ MMP) นำการกำหนดค่าการระบุแหล่งที่มาไปใช้เพื่อวัตถุประสงค์ในการระบุแหล่งที่มาข้ามเครือข่าย เมื่อเทคโนโลยีโฆษณาที่แสดงอย่างน้อย 1 รายการใช้คีย์การรวมที่ใช้ร่วมกัน (ตามที่อธิบายไว้ในการระบุแหล่งที่มาข้ามเครือข่ายโดยไม่มีการเปลี่ยนเส้นทางด้านบน)
เมื่อ MMP ค้นหาบริการการรวมเพื่อสร้างรายงานสรุปสำหรับแคมเปญที่มีแหล่งที่มาที่ได้รับ บริการการรวมจำเป็นต้องใช้ MMP ระบุรายการคีย์ที่เป็นไปได้เป็นอินพุตสำหรับงานการรวม ในบางกรณี รายการคีย์การรวมแหล่งที่มาที่เป็นไปได้อาจมีขนาดใหญ่มากหรือไม่รู้จัก รายการคีย์ที่เป็นไปได้จำนวนมากนั้นยากที่จะติดตาม และมีแนวโน้มที่จะค่อนข้างซับซ้อนและมีค่าใช้จ่ายสูงในการประมวลผล ลองดูตัวอย่างต่อไปนี้
- รายการคีย์ที่เป็นไปได้ทั้งหมดมีขนาดใหญ่ ดังนี้
- เครือข่ายโฆษณาที่แสดงโฆษณากำลังดำเนินโครงการริเริ่มด้านการได้ผู้ใช้ใหม่ที่ซับซ้อน ซึ่งประกอบด้วย 20 แคมเปญ โดยแต่ละแคมเปญมีกลุ่มโฆษณา 10 กลุ่ม และแต่ละกลุ่มมีครีเอทีฟโฆษณา 5 รายการที่ได้รับการรีเฟรชทุกสัปดาห์ตามประสิทธิภาพ
- ไม่รู้จักรายการคีย์ที่เป็นไปได้ทั้งหมด:
- เครือข่ายโฆษณาที่แสดงโฆษณากำลังแสดงโฆษณาในแอปบนอุปกรณ์เคลื่อนที่หลายแอป ซึ่งเราไม่ทราบรายการรหัสแอปของผู้เผยแพร่โฆษณาทั้งหมดเมื่อเปิดตัวแคมเปญ
- ผู้ลงโฆษณารายหนึ่งกำลังทำงานในเครือข่ายโฆษณาหลายเครือข่ายที่แสดงโฆษณาอยู่ ซึ่งไม่ได้เปลี่ยนเส้นทางไปยัง MMP ในการลงทะเบียนแหล่งที่มา เครือข่ายโฆษณาที่แสดงแต่ละเครือข่ายมีโครงสร้างสำคัญและค่าต่างๆ ซึ่งไม่สามารถแชร์ล่วงหน้ากับ MMP ได้
ด้วยการเปิดตัวการค้นพบที่สำคัญ:
- บริการการรวมไม่ต้องใช้การแจกแจงคีย์การรวมที่เป็นไปได้ทั้งหมดอีกต่อไป
- แทนที่จะต้องระบุรายการทั้งหมดของคีย์ที่เป็นไปได้ MMP จะสร้างชุดคีย์เปล่า (หรือว่างเปล่าบางส่วน) และกำหนดเกณฑ์เพื่อให้เอาต์พุตรวมเฉพาะคีย์ (ที่ไม่ได้ประกาศล่วงหน้า) ที่มีค่าเกินเกณฑ์เท่านั้น
- MMP จะได้รับรายงานสรุปที่มีค่ารบกวนสำหรับคีย์ที่มีค่ามากกว่าเกณฑ์ที่ตั้งไว้ รายงานยังอาจรวมถึงคีย์ที่ไม่มีการมีส่วนร่วมของผู้ใช้จริงที่เกี่ยวข้องและเป็นคีย์ที่ส่งเสียงอย่างเดียว
- MMP จะใช้ช่อง
x_network_bit_mappingในการลงทะเบียนทริกเกอร์เพื่อระบุว่าเทคโนโลยีโฆษณาสอดคล้องกับคีย์ใด - จากนั้น MMP สามารถติดต่อเทคโนโลยีโฆษณาที่เกี่ยวข้องสำหรับการแสดงโฆษณาเพื่อทำความเข้าใจค่าในคีย์แหล่งที่มา
กล่าวโดยสรุป การค้นพบคีย์ช่วยให้ MMP ได้รับคีย์การรวมได้โดยไม่ต้องทราบล่วงหน้า และหลีกเลี่ยงการประมวลผลคีย์แหล่งที่มาจำนวนมากโดยสูญเสียไปจากสัญญาณรบกวนที่เพิ่มเข้ามา
ดูข้อมูลการวัดผลในรายงานการระบุแหล่งที่มา
Attribution Reporting API เปิดใช้รายงานประเภทต่อไปนี้ ซึ่งจะอธิบายรายละเอียดเพิ่มเติมภายหลังในหน้านี้
- รายงานระดับเหตุการณ์เชื่อมโยงแหล่งที่มาของการระบุแหล่งที่มาที่เฉพาะเจาะจง (คลิกหรือดู) กับข้อมูลทริกเกอร์ที่มีความแม่นยำสูงบางส่วน
- รายงานแบบรวมได้ไม่จำเป็นต้องผูกกับแหล่งที่มาของการระบุแหล่งที่มาที่เฉพาะเจาะจงเสมอไป รายงานเหล่านี้จะให้ข้อมูลทริกเกอร์ที่สมบูรณ์และแม่นยํามากกว่ารายงานระดับเหตุการณ์ แต่ข้อมูลนี้จะใช้ได้เฉพาะในรูปแบบรวมเท่านั้น
รายงานทั้ง 2 ประเภทเป็นส่วนเสริมซึ่งกันและกันและนำไปใช้พร้อมกันได้
รายงานระดับเหตุการณ์
หลังจากระบุแหล่งที่มาของทริกเกอร์ไปยังแหล่งที่มาของการระบุแหล่งที่มาแล้ว ระบบจะสร้างรายงานระดับเหตุการณ์และจัดเก็บไว้ในอุปกรณ์จนกว่าจะส่งกลับไปยัง URL ระบบรายงานผล Conversion ของเทคโนโลยีโฆษณาแต่ละรายการได้ในกรอบเวลาในการส่งรายงานช่วงใดช่วงหนึ่ง ซึ่งจะอธิบายรายละเอียดเพิ่มเติมภายหลังในหน้านี้
รายงานระดับเหตุการณ์จะมีประโยชน์ในกรณีที่ต้องการข้อมูลเกี่ยวกับทริกเกอร์น้อยมาก ข้อมูลทริกเกอร์ระดับเหตุการณ์ถูกจำกัดไว้ที่ข้อมูลทริกเกอร์ 3 บิตสำหรับการคลิก ซึ่งหมายความว่าคุณสามารถกำหนดทริกเกอร์หนึ่งใน 8 หมวดหมู่ และ 1 บิตสำหรับการดู นอกจากนี้ รายงานระดับเหตุการณ์ไม่รองรับการเข้ารหัสข้อมูลฝั่งทริกเกอร์ที่มีความแม่นยำสูง เช่น ราคาหรือเวลาทริกเกอร์ที่เจาะจง เนื่องจากการระบุแหล่งที่มาเกิดขึ้นในอุปกรณ์ จึงไม่มีการรองรับการวิเคราะห์จากหลายอุปกรณ์ในรายงานระดับเหตุการณ์
รายงานระดับเหตุการณ์มีข้อมูลอย่างเช่นข้อมูลต่อไปนี้
- ปลายทาง: ชื่อแพ็กเกจของแอปของผู้ลงโฆษณาหรือ eTLD+1 ที่เกิดทริกเกอร์
- รหัสแหล่งที่มาของการระบุแหล่งที่มา: รหัสแหล่งที่มาของการระบุแหล่งที่มาเดียวกันกับที่ใช้ในการลงทะเบียนแหล่งที่มาของการระบุแหล่งที่มา
- ประเภททริกเกอร์: ข้อมูลทริกเกอร์ความแม่นยำต่ำ 1 หรือ 3 บิต ขึ้นอยู่กับประเภทแหล่งที่มาของการระบุแหล่งที่มา
กลไกการรักษาความเป็นส่วนตัวที่ใช้กับรายงานทั้งหมด
ขีดจํากัดต่อไปนี้จะมีผลหลังจากคํานึงถึงลําดับความสําคัญเกี่ยวกับแหล่งที่มาของการระบุแหล่งที่มาและทริกเกอร์
ขีดจำกัดของจำนวนเทคโนโลยีโฆษณา
มีการจํากัดจํานวนเทคโนโลยีโฆษณาที่สามารถลงทะเบียนหรือรับรายงานจาก API ได้ โดยมีข้อเสนอปัจจุบันดังนี้
- เทคโนโลยีโฆษณา 100 แห่งที่มีแหล่งที่มาของการระบุแหล่งที่มาต่อ {source app, destination app, 30 days, device}
- เทคโนโลยีโฆษณา 10 อย่างที่มีทริกเกอร์ระบุแหล่งที่มาต่อ {source app, destination app, 30 days, device}
- เทคโนโลยีโฆษณา 20 รายการลงทะเบียนแหล่งที่มาของการระบุแหล่งที่มาหรือทริกเกอร์เดียวได้ (ผ่าน
Attribution-Reporting-Redirect)
ขีดจำกัดของจำนวนปลายทางที่ไม่ซ้ำกัน
ขีดจำกัดเหล่านี้ทำให้เทคโนโลยีโฆษณาชุดหนึ่งทำความเข้าใจได้ยากโดยการค้นหาแอปจำนวนมากเพื่อทำความเข้าใจพฤติกรรมการใช้งานแอปของผู้ใช้ที่ระบุ
- ในแหล่งที่มาที่ลงทะเบียนทั้งหมดและเทคโนโลยีโฆษณาทั้งหมด API รองรับปลายทางที่ไม่ซ้ำกันไม่เกิน 200 รายการต่อแอปแหล่งที่มาต่อนาที
- ในแหล่งที่มาที่ลงทะเบียนทั้งหมด API จะรองรับปลายทางที่ไม่ซ้ำกันไม่เกิน 50 ปลายทางต่อแอปแหล่งที่มาต่อนาที ขีดจํากัดนี้ป้องกันไม่ให้เทคโนโลยีโฆษณา 1 รายการใช้งบประมาณทั้งหมดจากขีดจํากัดอัตราที่กล่าวไว้ก่อนหน้านี้
แหล่งที่มาที่หมดอายุจะไม่นับรวมในขีดจำกัดอัตรา
ต้นทางการรายงาน 1 รายการต่อแอปแหล่งที่มาต่อวัน
แพลตฟอร์มเทคโนโลยีโฆษณาหนึ่งๆ จะใช้ต้นทางการรายงานได้เพียง 1 แหล่งเพื่อลงทะเบียนแหล่งที่มาในแอปของผู้เผยแพร่โฆษณาในอุปกรณ์หนึ่งๆ ในวันเดียวกัน การจำกัดอัตรานี้จะป้องกันไม่ให้เทคโนโลยีโฆษณาใช้ต้นทางการรายงานหลายแห่งเพื่อเข้าถึงงบประมาณความเป็นส่วนตัวเพิ่มเติม
พิจารณาสถานการณ์ต่อไปนี้ซึ่งเทคโนโลยีโฆษณารายเดียวต้องการใช้ต้นทางการรายงานหลายแหล่งเพื่อลงทะเบียนแหล่งที่มาในแอปของผู้เผยแพร่โฆษณาสําหรับอุปกรณ์เดียว
- ต้นทางการรายงาน 1 ของเทคโนโลยีโฆษณา A ลงทะเบียนแหล่งที่มาในแอป B
- 12 ชั่วโมงต่อมา ต้นทางการรายงานของเทคโนโลยีโฆษณา A พยายามลงทะเบียนแหล่งที่มา ในแอป B
แหล่งที่มาที่ 2 สําหรับต้นทางการรายงาน 2 ของเทคโนโลยีโฆษณา A จะถูกปฏิเสธโดย API ต้นทางการรายงาน 2 ของเทคโนโลยีโฆษณา A จะลงทะเบียนแหล่งที่มาในอุปกรณ์เดียวกันในแอป B ไม่สำเร็จจนกว่าจะถึงวันถัดไป
ระยะเวลาพักและการจำกัดอัตรา
หากต้องการจำกัดปริมาณการรั่วไหลของข้อมูลประจำตัวผู้ใช้ระหว่างคู่ {source, destination} ทาง API จะควบคุมปริมาณข้อมูลทั้งหมดที่ส่งในระยะเวลาที่กำหนดสำหรับผู้ใช้
ข้อเสนอปัจจุบันคือการจำกัดเทคโนโลยีโฆษณาแต่ละรายการไว้ที่ทริกเกอร์ที่มีการระบุแหล่งที่มา 100 รายการต่อ {source app, destination app, 30 days, device}
จำนวนปลายทางที่ไม่ซ้ำกัน
API จะจำกัดจำนวนปลายทางที่เทคโนโลยีโฆษณาสามารถลองวัดได้ ยิ่งขีดจำกัดต่ำลงเท่าใด เทคโนโลยีโฆษณาจะใช้ API เพื่อพยายามวัดกิจกรรมการท่องเว็บของผู้ใช้ที่ไม่ได้เชื่อมโยงกับโฆษณาที่แสดงได้ยากขึ้นเท่านั้น
ข้อเสนอปัจจุบันคือการจำกัดเทคโนโลยีโฆษณาแต่ละรายการให้มีปลายทางที่ไม่ซ้ำกัน 100 แห่งโดยมีแหล่งที่มาที่ยังไม่หมดอายุต่อแอปแหล่งที่มา 1 แอป
กลไกการรักษาความเป็นส่วนตัวที่ใช้กับรายงานระดับเหตุการณ์
ความแม่นยำจำกัดของข้อมูลทริกเกอร์
API จะมี 1 บิตสำหรับทริกเกอร์การดูผ่าน และ 3 บิตสำหรับทริกเกอร์การคลิกผ่าน แหล่งที่มาของการระบุแหล่งที่มายังคงรองรับข้อมูลเมตา 64 บิตที่สมบูรณ์ต่อไป
คุณควรประเมินว่าจะลดข้อมูลที่แสดงในทริกเกอร์หรือไม่และอย่างไร เพื่อให้เหมาะกับจำนวนบิตที่จำกัดที่มีอยู่ในรายงานระดับเหตุการณ์
เฟรมเวิร์กสำหรับเสียงรบกวนเกี่ยวกับความเป็นส่วนตัว
เป้าหมายของ API นี้คือช่วยให้การวัดระดับเหตุการณ์เป็นไปตามข้อกําหนดด้านความเป็นส่วนตัวที่แตกต่างในพื้นที่โดยใช้คำตอบแบบสุ่ม k เพื่อสร้างเอาต์พุตเสียงรบกวนสําหรับเหตุการณ์ต้นทางแต่ละเหตุการณ์
ระบบจะใช้ Noise เพื่อระบุว่ามีการรายงานเหตุการณ์แหล่งที่มาของการระบุแหล่งที่มาตามความจริงหรือไม่ ระบบจะลงทะเบียนแหล่งที่มาของการระบุแหล่งที่มาในอุปกรณ์ซึ่งมีความน่าจะเป็น $ 1-p $ ซึ่ง มีการลงทะเบียนแหล่งที่มาของการระบุแหล่งที่มาตามปกติ และความน่าจะเป็นคือ $ p $ ที่อุปกรณ์สุ่มเลือกจากสถานะเอาต์พุตที่เป็นไปได้ทั้งหมดของ API (รวมถึงการไม่รายงานใดๆ เลยหรือการรายงานรายงานปลอมหลายรายการ)
การตอบสนอง k-randomized คืออัลกอริทึมที่เป็น epsilon Differentially แบบส่วนตัว ถ้าเป็นไปตามสมการต่อไปนี้
สำหรับค่า GMT ที่ต่ำ เอาต์พุตจริงจะได้รับการปกป้องโดยกลไกการตอบสนองแบบ k-randomized พารามิเตอร์สัญญาณรบกวนที่แน่นอนกําลังดําเนินการอยู่และอาจมีการเปลี่ยนแปลงตามความคิดเห็น โดยปัจจุบันได้เสนอสิ่งต่อไปนี้
- 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 ชั่วโมงหลังจากลงทะเบียนแหล่งที่มาของการระบุแหล่งที่มา
- ระยะเวลาที่กำหนดเอง ซึ่งระบุโดยแอตทริบิวต์ "expiry" ของแหล่งที่มาของการระบุแหล่งที่มา ระบบจะส่งรายงาน 1 ชั่วโมงหลังเวลาหมดอายุที่ระบุไว้ ค่านี้ต้องไม่น้อยกว่า 1 วันหรือมากกว่า 30 วัน
การกำหนดค่าระดับเหตุการณ์ที่ยืดหยุ่น
การกำหนดค่าเริ่มต้นสำหรับการรายงานระดับเหตุการณ์คือสิ่งที่แนะนำให้เทคโนโลยีโฆษณาเริ่มใช้เมื่อเริ่มทดสอบยูทิลิตี แต่อาจไม่เหมาะสำหรับกรณีการใช้งานทั้งหมด Attribution Reporting API จะรองรับการกำหนดค่าที่ไม่บังคับและยืดหยุ่นมากขึ้น เพื่อให้เทคโนโลยีโฆษณาควบคุมโครงสร้างของรายงานระดับเหตุการณ์ได้มากขึ้นและใช้ประโยชน์จากข้อมูลได้สูงสุด
เราจะเพิ่มความยืดหยุ่นเพิ่มเติมนี้ใน Attribution Reporting API ใน 2 ระยะ ดังนี้
- ระยะที่ 1: การกำหนดค่าระดับเหตุการณ์ที่ยืดหยุ่นของ Lite
- เวอร์ชันนี้จะมีชุดย่อยของฟีเจอร์ทั้งหมด และใช้งานได้อย่างอิสระจากระยะที่ 2
- ระยะที่ 2: การกำหนดค่าระดับเหตุการณ์แบบยืดหยุ่นเวอร์ชันแบบเต็ม
ระยะที่ 1 (ระดับเหตุการณ์ที่ยืดหยุ่น Lite) สามารถใช้เพื่อวัตถุประสงค์ต่อไปนี้
- เปลี่ยนแปลงความถี่ของรายงานด้วยการระบุจำนวนกรอบเวลาการรายงาน
- เปลี่ยนแปลงจำนวนการระบุแหล่งที่มาต่อการลงทะเบียนแหล่งที่มา
- ลดจำนวนสัญญาณรบกวนทั้งหมดโดยลดพารามิเตอร์ข้างต้นลง
- กำหนดค่ากรอบเวลาการรายงานแทนการใช้ค่าเริ่มต้น
ระยะที่ 2 (ระดับเหตุการณ์ที่ยืดหยุ่นเต็มรูปแบบ) สามารถใช้ความสามารถทั้งหมดในระยะที่ 1 รวมถึงความสามารถดังต่อไปนี้
- เปลี่ยนแปลงจำนวนสมาชิกในเซ็ตของข้อมูลทริกเกอร์ในรายงาน
- ลดจำนวนสัญญาณรบกวนทั้งหมดด้วยการลด Cardinality ของทริกเกอร์
การลดมิติข้อมูลของการกำหนดค่าเริ่มต้นลงหนึ่งช่วยให้เทคโนโลยีโฆษณาเพิ่มมิติข้อมูลอื่นได้ หรือจำนวนสัญญาณรบกวนทั้งหมดในรายงานระดับเหตุการณ์อาจลดลงโดยการลดพารามิเตอร์ที่กล่าวถึงข้างต้นลง
นอกจากการตั้งค่าระดับสัญญาณรบกวนแบบไดนามิกตามการกำหนดค่าที่เทคโนโลยีโฆษณาเลือกแล้ว เรายังจำกัดพารามิเตอร์บางอย่างเพื่อหลีกเลี่ยงค่าใช้จ่ายในการคำนวณจำนวนมากและการกำหนดค่าที่มีสถานะเอาต์พุตมากเกินไป (ซึ่งการพิจารณาเรื่องนี้จะเพิ่มขึ้นด้วย) นี่คือตัวอย่างชุดข้อจำกัด โปรดแสดงความคิดเห็นใน [ข้อเสนอการออกแบบ][50]:
- รายงานทั้งหมดสูงสุด 20 รายการทั่วโลกและต่อtrigger_data
- กรอบเวลาการรายงานที่เป็นไปได้สูงสุด 5 หน้าต่างต่อtrigger_data
- จำนวนสมาชิกในเซ็ตข้อมูลทริกเกอร์สูงสุด 32 รายการ (ใช้ไม่ได้กับเฟส 1: ระดับเหตุการณ์แบบยืดหยุ่น Lite)
ในขณะที่เทคโนโลยีโฆษณาเริ่มใช้ฟีเจอร์นี้ โปรดทราบว่าการใช้ค่า Extrema อาจทำให้เกิดข้อผิดพลาดจำนวนมากหรือลงทะเบียนไม่สำเร็จหากไม่เป็นไปตามระดับความเป็นส่วนตัว
รายงานที่รวบรวมได้
ก่อนที่จะใช้รายงานรวบรวมข้อมูลได้ คุณต้องตั้งค่าบัญชีระบบคลาวด์และเริ่มรับรายงานแบบรวม
รายงานที่รวบรวมได้จะให้ข้อมูลทริกเกอร์ที่มีความแม่นยำสูงจากอุปกรณ์อย่างรวดเร็วยิ่งขึ้น นอกเหนือจากที่นำเสนอสำหรับรายงานระดับเหตุการณ์ ข้อมูลความแม่นยำสูงนี้จะเรียนรู้ได้ในข้อมูลรวมเท่านั้น และจะไม่เชื่อมโยงกับทริกเกอร์หรือผู้ใช้ที่เฉพาะเจาะจง คีย์การรวมมีขนาดสูงสุด 128 บิต ซึ่งช่วยให้รายงานที่รวบรวมได้รองรับกรณีการใช้งานการรายงาน ดังตัวอย่างต่อไปนี้
- รายงานสำหรับค่าทริกเกอร์ เช่น รายได้
- การจัดการประเภททริกเกอร์เพิ่มเติม
นอกจากนี้ รายงานที่รวบรวมได้จะใช้ตรรกะการระบุแหล่งที่มาตามลำดับความสำคัญเดียวกับรายงานระดับเหตุการณ์ แต่รองรับ Conversion ที่เกิดจากการคลิกหรือการดูจำนวนมากขึ้น
การออกแบบโดยรวมของวิธีจัดเตรียมและส่งรายงานแบบสรุปรวมได้ของ Attribution Reporting API ที่แสดงในแผนภาพมีดังนี้
- อุปกรณ์จะส่งรายงานแบบรวบรวมข้อมูลได้ที่เข้ารหัสไปยังเทคโนโลยีโฆษณา ในสภาพแวดล้อมการใช้งานจริง เทคโนโลยีโฆษณาจะใช้รายงานเหล่านี้โดยตรงไม่ได้
- เทคโนโลยีโฆษณาจะส่งรายงานที่รวบรวมไว้ได้ไปยังบริการรวบรวมข้อมูลเพื่อรวบรวมข้อมูล
- บริการรวบรวมข้อมูลจะอ่านชุดรายงานที่รวบรวมได้ รวมถึงถอดรหัสและรวบรวมรายงาน
- ระบบจะส่งข้อมูลรวมขั้นสุดท้ายกลับไปยังเทคโนโลยีโฆษณาในรายงานสรุป
รายงานที่รวบรวมได้จะมีข้อมูลต่อไปนี้ซึ่งเกี่ยวข้องกับแหล่งที่มาของการระบุแหล่งที่มา
- ปลายทาง: ชื่อแพ็กเกจหรือ URL เว็บ eTLD+1 ของแอปที่เกิดทริกเกอร์ขึ้น
- วันที่: วันที่เกิดเหตุการณ์ซึ่งแหล่งที่มาของการระบุแหล่งที่มาแสดง
- เพย์โหลด: ค่าทริกเกอร์ที่รวบรวมเป็นคู่คีย์/ค่าที่เข้ารหัส ซึ่งใช้ในบริการรวบรวมที่เชื่อถือได้เพื่อคำนวณการรวม
บริการรวบรวมข้อมูล
บริการต่อไปนี้มีฟังก์ชันการรวมและช่วยปกป้อง การเข้าถึงข้อมูลการรวมอย่างไม่เหมาะสม
บริการเหล่านี้ได้รับการจัดการโดยบุคคลอื่นๆ ซึ่งจะอธิบายรายละเอียดเพิ่มเติมภายหลังในหน้านี้:
- บริการรวบรวมข้อมูลเป็นบริการเดียวที่เทคโนโลยีโฆษณาคาดว่าจะติดตั้งใช้งาน
- บริการการจัดการคีย์และการบัญชีรายงานรวมได้จะดำเนินการโดยฝ่ายที่เชื่อถือได้ซึ่งเรียกว่าผู้ประสานงาน ผู้ประสานงานเหล่านี้ยืนยันว่าโค้ดที่ทำงานในบริการการรวมเป็นโค้ดที่ Google เผยแพร่ต่อสาธารณะ และผู้ใช้บริการรวบรวมข้อมูลทั้งหมดมีคีย์เดียวกันและบริการบัญชีรายงานแบบสรุปรวมที่ใช้กับบริการดังกล่าว
บริการรวบรวมข้อมูล
แพลตฟอร์มเทคโนโลยีโฆษณาจะต้องติดตั้งใช้งานบริการรวบรวมข้อมูลที่อิงตามไบนารีของ Google ไว้ล่วงหน้า
บริการรวบรวมข้อมูลนี้ทำงานในสภาพแวดล้อมของ Trusted Execution Environment (TEE) ซึ่งโฮสต์ในระบบคลาวด์ TEE มีประโยชน์ด้านความปลอดภัยดังต่อไปนี้
- โดยจะทำให้โค้ดที่ทำงานใน TEE เป็นไบนารีที่ Google มีให้ หากไม่เป็นไปตามเงื่อนไขนี้ บริการการรวมจะไม่สามารถเข้าถึงคีย์การถอดรหัสที่ต้องใช้ในการทำงาน
- ผลิตภัณฑ์นี้มีการรักษาความปลอดภัยในกระบวนการที่ทำงานอยู่ โดยแยกออกจากการตรวจสอบหรือการปลอมแปลงจากภายนอก
ประโยชน์ด้านความปลอดภัยเหล่านี้ช่วยให้บริการรวบรวมข้อมูลดำเนินการที่ละเอียดอ่อน เช่น การเข้าถึงข้อมูลที่เข้ารหัส ได้อย่างปลอดภัยยิ่งขึ้น
สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการออกแบบ เวิร์กโฟลว์ และการรักษาความปลอดภัยของบริการรวบรวมข้อมูล โปรดดูเอกสารบริการรวบรวมข้อมูลใน GitHub
บริการการจัดการคีย์
บริการนี้จะยืนยันว่าบริการการรวมกำลังใช้งานไบนารีเวอร์ชันที่ได้รับอนุมัติ จากนั้นจึงให้บริการการรวมในเทคโนโลยีโฆษณาพร้อมกับคีย์การถอดรหัสที่ถูกต้องสำหรับข้อมูลทริกเกอร์
การทำบัญชีรายงานแบบรวมได้
บริการนี้ติดตามความถี่ที่บริการรวบรวมของเทคโนโลยีโฆษณาเข้าถึงทริกเกอร์ที่เจาะจง ซึ่งมีคีย์การรวมหลายรายการ และจำกัดการเข้าถึงตามจำนวนการถอดรหัสที่เหมาะสม โปรดดูรายละเอียดในข้อเสนอการออกแบบของบริการรวบรวมสำหรับ Attribution Reporting API
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 $ เช่น การเลือกสัญญาณรบกวนด้วยการกระจายต่อไปนี้
การผสานรวม Protected Audience API และ Attribution Reporting API
การผสานรวมข้าม API ใน Protected Audience และ Attribution Reporting API ช่วยให้ AdTech ประเมินประสิทธิภาพการระบุแหล่งที่มาในกลยุทธ์รีมาร์เก็ตติ้งต่างๆ เพื่อทำความเข้าใจว่ากลุ่มเป้าหมายประเภทใดที่ให้ ROI สูงสุด
ด้วยการผสานรวมข้าม API นี้ AdTech จะทําสิ่งต่อไปนี้ได้
- สร้างแผนที่คีย์-ค่าของ URI ที่จะใช้สำหรับทั้ง 1) การรายงานการโต้ตอบ และ 2) การลงทะเบียนแหล่งที่มา
- รวม
CustomAudienceในการแมปคีย์ฝั่งแหล่งที่มาเพื่อการรายงานสรุปแบบรวม (โดยใช้ Attribution Reporting API)
เมื่อผู้ใช้เห็นหรือคลิกที่โฆษณา
- นอกจากนี้ URL ที่ใช้ในการรายงานการโต้ตอบเหล่านั้นโดยใช้ Protected Audience ยังจะใช้เพื่อลงทะเบียนข้อมูลพร็อพเพอร์ตี้หรือคลิกเป็นแหล่งที่มาที่มีสิทธิ์กับ Attribution Reporting API ด้วย
- เทคโนโลยีโฆษณาอาจเลือกส่ง CustomAudience (หรือข้อมูลบริบทที่เกี่ยวข้องอื่นๆ เกี่ยวกับโฆษณา เช่น ตำแหน่งโฆษณาหรือระยะเวลาการดู) โดยใช้ URL ดังกล่าว เพื่อให้ข้อมูลเมตานี้เผยแพร่ไปยังรายงานสรุปได้เมื่อเทคโนโลยีโฆษณากำลังตรวจสอบประสิทธิภาพแคมเปญโดยรวม
ดูข้อมูลเพิ่มเติมเกี่ยวกับวิธีเปิดใช้ฟีเจอร์นี้ใน Protected Audience ได้ในส่วนที่เกี่ยวข้องของคำอธิบายเกี่ยวกับ Protected Audience API
ลำดับความสำคัญของการลงทะเบียน การระบุแหล่งที่มา และตัวอย่างการรายงาน
ตัวอย่างนี้แสดงชุดการโต้ตอบของผู้ใช้ และวิธีที่แหล่งที่มาของการระบุแหล่งที่มาและลำดับความสำคัญของทริกเกอร์ที่กำหนดโดยเทคโนโลยีโฆษณาส่งผลต่อรายงานที่มีการระบุแหล่งที่มา ในตัวอย่างนี้เราใช้สมมติฐานต่อไปนี้
- แหล่งที่มาของการระบุแหล่งที่มาและทริกเกอร์ทั้งหมดจดทะเบียนโดยเทคโนโลยีโฆษณาเดียวกันสำหรับผู้ลงโฆษณารายเดียวกัน
- แหล่งที่มาของการระบุแหล่งที่มาและทริกเกอร์ทั้งหมดจะเกิดขึ้นในช่วงกรอบเวลาการรายงานเหตุการณ์แรก (ภายใน 2 วันนับจากที่แสดงโฆษณาในแอปของผู้เผยแพร่โฆษณาเป็นครั้งแรก)
พิจารณากรณีที่ผู้ใช้ทำสิ่งต่อไปนี้
- ผู้ใช้เห็นโฆษณา เทคโนโลยีโฆษณาจะบันทึกแหล่งที่มาของการระบุแหล่งที่มาด้วย API โดยมีลําดับความสําคัญเป็น
0(ดู #1) - ผู้ใช้เห็นโฆษณา ซึ่งลงทะเบียนด้วยลำดับความสำคัญ
0(มุมมอง #2) - ผู้ใช้คลิกโฆษณาที่มีลำดับความสำคัญ
1(คลิก #1) - ผู้ใช้ทำ Conversion (เข้าถึงหน้า Landing Page) ในแอปของผู้ลงโฆษณา เทคโนโลยีโฆษณาจะบันทึกทริกเกอร์กับ API โดยมีลำดับความสำคัญเป็น
0(Conversion #1)- เมื่อมีการลงทะเบียนทริกเกอร์ API จะระบุแหล่งที่มาก่อนที่จะสร้างรายงาน
- แหล่งที่มาของการระบุแหล่งที่มาที่ใช้ได้มี 3 แหล่ง ได้แก่ การดูที่ 1, การดูที่ 2 และ คลิกที่ 1 API จะระบุแหล่งที่มาของทริกเกอร์นี้ให้เป็นคลิกที่ 1 เนื่องจากเป็นลำดับความสำคัญสูงสุดและลำดับล่าสุด
- ข้อมูลพร็อพเพอร์ตี้ที่ 1 และข้อมูลพร็อพเพอร์ตี้ที่ 2 ถูกยกเลิกและไม่มีสิทธิ์ในการระบุที่มาในอนาคตอีกต่อไป
- ผู้ใช้เพิ่มสินค้าลงในรถเข็นในแอปของผู้ลงโฆษณา ซึ่งมีลำดับความสำคัญเป็น
1(Conversion #2)- คลิกที่ 1 เป็นแหล่งที่มาของการระบุแหล่งที่มาที่มีสิทธิ์เพียงแหล่งเดียว API จะระบุแหล่งที่มา ของทริกเกอร์นี้เพื่อคลิก #1
- ผู้ใช้เพิ่มสินค้าลงในรถเข็นในแอปของผู้ลงโฆษณา ซึ่งมีลำดับความสำคัญเป็น
1(Conversion #3)- คลิกที่ 1 เป็นแหล่งที่มาของการระบุแหล่งที่มาที่มีสิทธิ์เพียงแหล่งเดียว API จะระบุแหล่งที่มา ของทริกเกอร์นี้เพื่อคลิก #1
- ผู้ใช้เพิ่มสินค้าลงในรถเข็นในแอปของผู้ลงโฆษณา ซึ่งมีลำดับความสำคัญเท่ากับ
1(Conversion #4)- คลิกที่ 1 เป็นแหล่งที่มาของการระบุแหล่งที่มาที่มีสิทธิ์เพียงแหล่งเดียว API จะระบุแหล่งที่มา ของทริกเกอร์นี้เพื่อคลิก #1
- ผู้ใช้ทำการซื้อในแอปของผู้ลงโฆษณา ซึ่งลงทะเบียนด้วยลำดับความสำคัญ
2(Conversion #5)- คลิกที่ 1 เป็นแหล่งที่มาของการระบุแหล่งที่มาที่มีสิทธิ์เพียงแหล่งเดียว API จะระบุแหล่งที่มา ของทริกเกอร์นี้เพื่อคลิก #1
รายงานระดับเหตุการณ์มีลักษณะต่อไปนี้
- โดยค่าเริ่มต้น ระบบจะส่งทริกเกอร์ 3 รายการแรกที่มาจากคลิกและทริกเกอร์แรกที่เกิดจากข้อมูลพร็อพเพอร์ตี้หลังกรอบเวลาการรายงานที่เกี่ยวข้อง
- ภายในหน้าต่างการรายงาน หากมีทริกเกอร์ที่มีลำดับความสำคัญสูงกว่า ทริกเกอร์เหล่านั้นจะมีความสำคัญเหนือกว่าทริกเกอร์ล่าสุดและแทนที่ทริกเกอร์ล่าสุด
- ในตัวอย่างก่อนหน้านี้ เทคโนโลยีโฆษณาได้รับรายงานเหตุการณ์ 3 รายการหลังจากกรอบเวลาการรายงาน 2 วันสำหรับ Conversion #2, 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 เป็นวิธีที่ใหม่และค่อนข้างซับซ้อนในการวัดผลการระบุแหล่งที่มาโดยไม่ต้องใช้ตัวระบุข้ามแอป ด้วยเหตุนี้ เราจึงสนับสนุนกลไกเปลี่ยนผ่านเพื่อดูข้อมูลเพิ่มเติมเกี่ยวกับรายงานการระบุแหล่งที่มาเมื่อมีรหัสโฆษณา (ผู้ใช้ไม่ได้เลือกไม่ใช้การปรับโฆษณาตามโปรไฟล์ของผู้ใช้โดยใช้รหัสโฆษณา และแอปผู้เผยแพร่โฆษณาหรือผู้ลงโฆษณาได้ประกาศสิทธิ์รหัสโฆษณาแล้ว) วิธีนี้จะช่วยให้มั่นใจได้ว่า API จะเข้าใจอย่างถ่องแท้ระหว่างการเปิดตัว ช่วยกำจัดข้อบกพร่อง และเปรียบเทียบประสิทธิภาพกับทางเลือกอื่นๆ ตามรหัสโฆษณาได้ง่ายขึ้น รายงานการแก้ไขข้อบกพร่องมี 2 ประเภท ได้แก่ การระบุแหล่งที่มาสำเร็จและแบบละเอียด
อ่านคู่มือเกี่ยวกับรายงานการแก้ไขข้อบกพร่องการเปลี่ยนผ่าน เพื่อดูรายละเอียดเกี่ยวกับรายงานการแก้ไขข้อบกพร่องด้วยการวัดผลจากแอปไปยังเว็บและจากแอป
รายงานการแก้ไขข้อบกพร่องของการระบุแหล่งที่มาสำเร็จ
ทั้งการลงทะเบียนต้นทางและทริกเกอร์จะยอมรับช่อง debug_key แบบ 64 บิตใหม่ (จัดรูปแบบเป็นสตริง) ที่เทคโนโลยีโฆษณาสร้างขึ้น ระบบจะส่ง source_debug_key และ trigger_debug_key โดยไม่มีการเปลี่ยนแปลงทั้งในรายงานระดับเหตุการณ์และรายงานสรุปรวม
หากสร้างรายงานที่มีทั้งคีย์การแก้ไขข้อบกพร่องแหล่งที่มาและคีย์การแก้ไขข้อบกพร่อง ระบบจะส่งรายงานการแก้ไขข้อบกพร่องที่ซ้ำกันไปยังปลายทาง .well-known/attribution-reporting/debug/report-event-attribution ด้วยการหน่วงเวลาที่จำกัด รายงานการแก้ไขข้อบกพร่องจะเหมือนกับรายงานปกติ ซึ่งรวมถึงช่องคีย์การแก้ไขข้อบกพร่องทั้ง 2 ช่อง
การรวมคีย์เหล่านี้ไว้ในทั้ง 2 อย่างจะช่วยเชื่อมโยงรายงานปกติเข้ากับสตรีมที่แยกต่างหากของรายงานการแก้ไขข้อบกพร่อง
- สำหรับรายงานระดับเหตุการณ์
- ระบบจะส่งรายงานการแก้ไขข้อบกพร่องที่ซ้ำกันโดยมีความล่าช้าที่จำกัด จึงไม่ถูกระงับโดยขีดจำกัดของทริกเกอร์ที่ใช้ได้ ซึ่งช่วยให้เทคโนโลยีโฆษณาเข้าใจผลกระทบของขีดจำกัดเหล่านั้นสำหรับรายงานระดับเหตุการณ์
- รายงานระดับเหตุการณ์ที่เชื่อมโยงกับเหตุการณ์ทริกเกอร์เท็จจะไม่มี
trigger_debug_keyวิธีนี้จะช่วยให้เทคโนโลยีโฆษณาเข้าใจวิธีนำสัญญาณรบกวนใน API ไปใช้มากขึ้น
- สำหรับรายงานรวมได้
- เราจะรองรับช่อง
debug_cleartext_payloadใหม่ซึ่งมีเพย์โหลดที่ถอดรหัสแล้ว เฉพาะในกรณีที่ตั้งค่าทั้งsource_debug_keyและtrigger_debug_keyไว้
- เราจะรองรับช่อง
รายงานการแก้ไขข้อบกพร่องแบบละเอียด
รายงานการแก้ไขข้อบกพร่องแบบละเอียดช่วยให้นักพัฒนาซอฟต์แวร์ตรวจสอบความล้มเหลวบางอย่างในแหล่งที่มาของการระบุแหล่งที่มาหรือการลงทะเบียนทริกเกอร์ ระบบจะส่งรายงานการแก้ไขข้อบกพร่องเหล่านี้โดยมีการหน่วงเวลาที่จำกัดหลังจากแหล่งที่มาของการระบุแหล่งที่มาหรือการลงทะเบียนทริกเกอร์ไปยังปลายทาง well-known/attribution-reporting/debug/verbose
รายงานแบบละเอียดแต่ละรายการจะมีช่องต่อไปนี้
- ประเภท: สาเหตุที่สร้างรายงาน ดูรายการประเภทรายงานแบบละเอียดทั้งหมด
- โดยทั่วไปจะมีรายงานแบบละเอียดของแหล่งที่มาและทริกเกอร์รายงานแบบละเอียด
- รายงานแบบละเอียดของแหล่งที่มากำหนดให้รหัสโฆษณาต้องพร้อมใช้งานสำหรับแอปของผู้เผยแพร่โฆษณา และการทริกเกอร์รายงานแบบละเอียดกำหนดให้รหัสโฆษณาต้องพร้อมใช้งานสำหรับแอปของผู้ลงโฆษณา
- รายงานแบบละเอียด (ยกเว้น
trigger-no-matching-source) ของทริกเกอร์จะรวมsource_debug_keyหรือไม่ก็ได้ ค่านี้รวมไว้เฉพาะในกรณีที่มีรหัสโฆษณาในแอปของผู้เผยแพร่โฆษณาด้วย
- เนื้อหา: เนื้อหาของรายงาน ซึ่งขึ้นอยู่กับประเภทของรายงาน
เทคโนโลยีโฆษณาจำเป็นต้องเลือกใช้เพื่อรับรายงานการแก้ไขข้อบกพร่องแบบละเอียดโดยใช้ช่องพจนานุกรม debug_reporting ใหม่ในส่วนหัว Attribution-Reporting-Register_Source และ Attribution-Reporting-Register-Trigger
- รายงานแบบละเอียดของแหล่งที่มากำหนดให้เลือกใช้ในส่วนหัวของการลงทะเบียนแหล่งที่มาเท่านั้น
- รายงานการแก้ไขข้อบกพร่องของทริกเกอร์ต้องใช้การเลือกใช้ในส่วนหัวการลงทะเบียนทริกเกอร์เท่านั้น
วิธีใช้รายงานการแก้ไขข้อบกพร่อง
หากเกิด Conversion (ตามระบบการวัดที่มีอยู่) และได้รับรายงานการแก้ไขข้อบกพร่องสําหรับ Conversion นั้น แสดงว่าทริกเกอร์ได้รับการลงทะเบียนเรียบร้อยแล้ว
สำหรับรายงานการระบุแหล่งที่มาของการแก้ไขข้อบกพร่องแต่ละรายการ ให้ตรวจสอบว่าคุณได้รับรายงานการระบุแหล่งที่มาปกติที่ตรงกับคีย์การแก้ไขข้อบกพร่อง 2 คีย์หรือไม่
หากไม่มีผลลัพธ์ที่ตรงกัน อาจเกิดจากสาเหตุหลายประการ
ทำงานได้ตามที่ตั้งใจไว้:
- การทำงานของ API การรักษาความเป็นส่วนตัว
- ผู้ใช้มีจำนวนรายงานถึงขีดจำกัดอัตราที่กำหนด ทำให้ไม่ได้ส่งรายงานครั้งต่อๆ มาทั้งหมดในระยะเวลาดังกล่าว หรือนำแหล่งที่มาออกเนื่องจากขีดจำกัดของปลายทางที่รอดำเนินการ
- สำหรับรายงานระดับเหตุการณ์: รายงานอาจมีการตอบสนองแบบสุ่ม (เสียงรบกวน) และถูกระงับ หรือคุณอาจได้รับรายงานแบบสุ่ม
- สำหรับรายงานระดับเหตุการณ์: ถึงจำนวนรายงานสูงสุด 3 รายการ (สำหรับคลิก) หรือ 1 รายการ (สำหรับการดู) แล้ว และรายงานที่ตามมาไม่มีชุดลำดับความสำคัญที่ชัดเจนหรือลำดับความสำคัญต่ำกว่ารายงานที่มีอยู่
- เกินขีดจำกัดการร่วมให้ข้อมูลสำหรับรายงานที่รวบรวมได้แล้ว
- ตรรกะทางธุรกิจที่เทคโนโลยีโฆษณากำหนด:
- ทริกเกอร์จะถูกกรองออกผ่านตัวกรองหรือกฎลำดับความสำคัญ
- ความล่าช้าของเวลาหรือการโต้ตอบกับความพร้อมใช้งานของเครือข่าย (เช่น ผู้ใช้ปิดอุปกรณ์เป็นระยะเวลานาน)
สาเหตุที่ไม่ได้ตั้งใจ:
- ปัญหาการติดตั้งใช้งาน
- ส่วนหัวของแหล่งที่มากำหนดค่าไม่ถูกต้อง
- ส่วนหัวของทริกเกอร์มีการกำหนดค่าไม่ถูกต้อง
- ปัญหาอื่นๆ เกี่ยวกับการกำหนดค่า
- ปัญหาเกี่ยวกับอุปกรณ์หรือเครือข่าย
- การทำงานล้มเหลวเนื่องจากสภาวะของเครือข่าย
- การตอบกลับการลงทะเบียนแหล่งที่มาหรือทริกเกอร์ไม่เข้าถึงลูกค้า
- ข้อบกพร่อง API
ข้อควรพิจารณาในอนาคตและคำถามแบบเปิด
Attribution Reporting API อยู่ระหว่างดำเนินการ นอกจากนี้ เรายังจะสำรวจฟีเจอร์ที่มีศักยภาพในอนาคตด้วย เช่น รูปแบบการระบุแหล่งที่มาแบบไม่ใช่คลิกสุดท้ายและกรณีการใช้งานการวัดผลข้ามอุปกรณ์
นอกจากนี้ เราอยากทราบความคิดเห็นจากชุมชนเกี่ยวกับปัญหาบางประการดังต่อไปนี้
- มีกรณีการใช้งานต่างๆ ที่คุณต้องการให้ API ส่งรายงานสำหรับการติดตั้งที่ยืนยันแล้วหรือไม่ รายงานเหล่านี้จะนับรวมในขีดจำกัดอัตราที่เกี่ยวข้องของแพลตฟอร์มเทคโนโลยีโฆษณา
- คุณคาดว่าจะพบปัญหาในการส่ง
InputEventจากแอปไปยังเทคโนโลยีโฆษณาสำหรับการลงทะเบียนแหล่งที่มาไหม - คุณมีกรณีการใช้งานการระบุแหล่งที่มาพิเศษสำหรับแอปที่โหลดไว้ล่วงหน้าหรือแอปที่ติดตั้งอีกครั้งไหม