Attribution Reporting API: คู่มือการผสานรวม

ขณะอ่านเอกสารประกอบเกี่ยวกับ Privacy Sandbox บน Android ให้ใช้ปุ่มDeveloper Preview หรือเบต้าเพื่อเลือก เวอร์ชันโปรแกรมที่คุณกำลังใช้งาน เนื่องจากวิธีการอาจแตกต่างกัน

---

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

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

คู่มือนี้จะช่วยคุณวางแผนการผสานรวมด้วยมุมมองที่ครอบคลุม ซึ่งอาจรวมถึงฟีเจอร์ที่ยังไม่ได้ใช้งานในระยะปัจจุบันของ Privacy Sandbox ใน Android Developer Preview ในกรณีเหล่านี้ เราจะให้คำแนะนำเกี่ยวกับไทม์ไลน์

ในหน้านี้ เราใช้แหล่งที่มาเพื่อแสดงถึงการคลิกหรือการดู และ ทริกเกอร์เพื่อแสดงถึง Conversion

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

ข้อกำหนดเบื้องต้นและการตั้งค่า

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

ทำความคุ้นเคยกับ API

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

ตั้งค่าและทดสอบแอปตัวอย่าง

1. เมื่อพร้อมที่จะเริ่มการผสานรวมแล้ว ให้ตั้งค่าด้วย Developer Preview ล่าสุดใน Android Studio
2. ตั้งค่าปลายทางเซิร์ฟเวอร์จำลองสำหรับการลงทะเบียนกิจกรรมและการนำส่งรายงาน เราได้จัดเตรียมข้อมูลจำลองไว้ให้คุณใช้ร่วมกับ เครื่องมือที่มีให้บริการทางออนไลน์
3. ดาวน์โหลดและเรียกใช้โค้ดในแอปตัวอย่างเพื่อทำความคุ้นเคย กับการลงทะเบียนแหล่งที่มาและทริกเกอร์
1. กำหนดกรอบเวลาสำหรับการส่งรายงาน API รองรับกรอบเวลา 2 วัน 7 วัน หรือระยะเวลาที่กำหนดเองระหว่าง 2 ถึง 30 วัน
2. เมื่อลงทะเบียนแหล่งที่มาและทริกเกอร์โดยการเรียกใช้และใช้ แอปตัวอย่าง และช่วงเวลาที่ตั้งค่าไว้ผ่านไปแล้ว ให้ตรวจสอบว่าคุณได้รับ รายงานระดับเหตุการณ์และรายงานที่รวบรวมได้ที่เข้ารหัส หากต้องการแก้ไขข้อบกพร่องของรายงาน คุณจะสร้างรายงานได้เร็วขึ้นโดยบังคับเรียกใช้ งานการรายงาน
3. ตรวจสอบผลลัพธ์สำหรับการระบุแหล่งที่มาแบบแอปต่อแอป ยืนยันว่าข้อมูลใน ผลลัพธ์เหล่านี้เป็นไปตามที่คาดไว้สําหรับทั้งกรณีการระบุแหล่งที่มาของการแปลงครั้งสุดท้ายและหลังการติดตั้ง
4. หลังจากทำความเข้าใจวิธีทำงานร่วมกันของไคลเอ็นต์ API และเซิร์ฟเวอร์แล้ว ให้ใช้ แอปตัวอย่างเป็นตัวอย่างเพื่อเป็นแนวทางในการผสานรวมของคุณเอง ตั้งค่าเซิร์ฟเวอร์ที่ใช้งานจริงของคุณเอง และเพิ่มการเรียกการลงทะเบียนกิจกรรมลงในแอป

การผสานรวมล่วงหน้า

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

การมีส่วนร่วมของพาร์ทเนอร์

พาร์ทเนอร์เทคโนโลยีโฆษณา (MMP/SSP/DSP) มักจะสร้างโซลูชันการระบุแหล่งที่มาแบบผสานรวม ขั้นตอนในส่วนนี้จะช่วยคุณเตรียมพร้อมรับความสําเร็จในการมีส่วนร่วมกับพาร์ทเนอร์เทคโนโลยีโฆษณา

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

การระบุแหล่งที่มาระดับเหตุการณ์จากแอปไปยังแอปเวอร์ชันต้นแบบ

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

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

การทดสอบการจำลอง

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

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

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

1. ตั้งค่าไลบรารีการจำลองการวัดในเครื่อง
2. อ่านข้อกำหนดเกี่ยวกับวิธีจัดรูปแบบข้อมูล Conversion เพื่อให้ เข้ากันได้กับเครื่องมือสร้างรายงานจำลอง
3. ออกแบบคีย์การรวบรวมตามข้อกำหนดทางธุรกิจ
   • ข้อควรพิจารณาที่สำคัญมีดังนี้
     • พิจารณาขนาดที่สําคัญซึ่งลูกค้าหรือพาร์ทเนอร์ของคุณต้อง รวบรวม และมุ่งเน้นการประเมินไปที่ขนาดเหล่านั้น
     • กำหนดจำนวนขั้นต่ำของมิติข้อมูลรวมและความคาร์ดินาลิตี ที่จำเป็นสำหรับข้อกำหนด
     • ตรวจสอบว่าคีย์ฝั่งแหล่งที่มาและฝั่งทริกเกอร์ไม่เกิน 128 บิต
     • หากโซลูชันของคุณเกี่ยวข้องกับการมีส่วนร่วมในค่าหลายค่าต่อทริกเกอร์ เหตุการณ์ โปรดปรับขนาดค่าเทียบกับงบประมาณการมีส่วนร่วมสูงสุด L1 ซึ่งจะช่วยลดผลกระทบจากสัญญาณรบกวน
     • ต่อไปนี้คือตัวอย่างที่แสดงรายละเอียดการตั้งค่าคีย์เพื่อรวบรวมจํานวน Conversion โดยรวมที่ระดับแคมเปญ และคีย์เพื่อรวบรวมมูลค่าการซื้อโดยรวมที่ระดับภูมิศาสตร์
4. เรียกใช้เครื่องมือสร้างรายงานเพื่อสร้างรายงานเหตุการณ์และรายงานที่รวบรวมได้
5. เรียกใช้รายงานข้อมูลที่รวบรวมได้ผ่านเซิร์ฟเวอร์การรวมข้อมูลจำลอง เพื่อรับรายงานสรุป
6. ทำการทดสอบยูทิลิตี
   • เปรียบเทียบยอดรวม Conversion จากรายงานระดับเหตุการณ์และรายงานสรุปกับ ข้อมูล Conversion ในอดีตเพื่อพิจารณาความแม่นยำของการรายงาน Conversion เพื่อผลลัพธ์ที่ดีที่สุด ให้ทำการทดสอบการรายงานและการเปรียบเทียบกับส่วนที่กว้างและเป็นตัวแทนของฐานผู้ลงโฆษณา
   • ฝึกโมเดลอีกครั้งโดยอิงตามข้อมูลรายงานระดับเหตุการณ์ และอาจรวมถึงข้อมูลรายงานสรุป เปรียบเทียบความแม่นยำกับโมเดลที่สร้างขึ้นจากข้อมูลการฝึก ย้อนหลัง
   • ลองใช้กลยุทธ์การประมวลผลเป็นกลุ่มแบบต่างๆ แล้วดูว่ากลยุทธ์เหล่านั้นส่งผลต่อผลลัพธ์อย่างไร
     • ข้อควรพิจารณาที่สำคัญมีดังนี้
     • ความตรงต่อเวลาของรายงานสรุปสำหรับการปรับราคาเสนอ
     • ความถี่เฉลี่ยของเหตุการณ์ที่มาจากการระบุแหล่งที่มาในอุปกรณ์ เช่น ผู้ใช้ที่หยุดใช้งานกลับมาโดยอิงตามข้อมูลเหตุการณ์การซื้อที่ผ่านมา
     • ระดับเสียงรบกวน ยิ่งมีกลุ่มมากเท่าใด การรวมก็จะยิ่งเล็กลง และการรวมที่เล็กลงหมายถึงการใช้สัญญาณรบกวนมากขึ้น

การระบุแหล่งที่มาของเซิร์ฟเวอร์การรวบรวมข้อมูลต้นแบบ: การตั้งค่า

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

1. ตั้งค่าเซิร์ฟเวอร์การรวบรวมข้อมูล โดยทำดังนี้
   • ตั้งค่าบัญชี AWS
   • ลงทะเบียนใช้บริการรวมข้อมูลกับผู้ประสานงาน
   • ตั้งค่าเซิร์ฟเวอร์รวบรวมข้อมูลใน AWS จากไบนารีที่ให้ไว้
2. ออกแบบคีย์การรวบรวมตามข้อกำหนดทางธุรกิจ หากคุณทํางานนี้เสร็จแล้วในส่วนระดับเหตุการณ์จากแอปสู่แอป คุณ อาจข้ามขั้นตอนนี้ได้
3. ตั้งค่าเซิร์ฟเวอร์รวบรวมข้อมูลสําหรับรายงานที่รวบรวมได้ หากสร้างไว้แล้วในส่วนระดับเหตุการณ์จากแอปสู่แอป คุณอาจนำกลับมาใช้ใหม่ได้

การระบุแหล่งที่มาของเซิร์ฟเวอร์การรวมข้อมูลต้นแบบ: การผสานรวม

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

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

ทำซ้ำการออกแบบด้วยฟีเจอร์ที่ไม่บังคับ

ต่อไปนี้เป็นฟีเจอร์เพิ่มเติมที่คุณสามารถรวมไว้ในโซลูชันการวัดผล

ใช้ Debug API เพื่อสร้างคีย์การแก้ไขข้อบกพร่อง (ขอแนะนำอย่างยิ่ง)

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

ปรับแต่งลักษณะการทำงานของการระบุแหล่งที่มา

1. การระบุแหล่งที่มาสำหรับทริกเกอร์หลังการติดตั้ง
   • คุณใช้ฟีเจอร์นี้ได้ในกรณีที่ต้องระบุแหล่งที่มาของการทริกเกอร์หลังการติดตั้งเป็นแหล่งที่มาของการระบุแหล่งที่มาเดียวกันที่กระตุ้นการติดตั้ง แม้ว่าจะมีแหล่งที่มาของการระบุแหล่งที่มาอื่นๆ ที่มีสิทธิ์ซึ่งเกิดขึ้นเมื่อเร็วๆ นี้ก็ตาม
   • ตัวอย่างเช่น อาจมีกรณีที่ผู้ใช้คลิกโฆษณาที่กระตุ้นให้เกิดการ ติดตั้ง เมื่อติดตั้งแล้ว ผู้ใช้จะคลิกโฆษณาอื่นและทำการซื้อ ในกรณีนี้ บริษัทเทคโนโลยีโฆษณาอาจต้องการให้ระบบระบุแหล่งที่มาของการซื้อเป็น คลิกแรกแทนที่จะเป็นคลิกการมีส่วนร่วมซ้ำ
2. ใช้ตัวกรองเพื่อปรับแต่งข้อมูลในรายงานระดับเหตุการณ์
   • คุณตั้งค่าตัวกรอง Conversion ให้ไม่สนใจทริกเกอร์ที่เลือกและยกเว้นออกจากรายงานเหตุการณ์ได้ เนื่องจากจำนวนทริกเกอร์ต่อแหล่งที่มาของการระบุแหล่งที่มามีข้อจำกัด ตัวกรองจึงช่วยให้คุณรวมเฉพาะทริกเกอร์ ที่ให้ข้อมูลที่เป็นประโยชน์มากที่สุดในรายงานเหตุการณ์
   • นอกจากนี้ยังใช้ตัวกรองเพื่อกรองทริกเกอร์บางรายการออกได้ด้วย ซึ่งเป็นการไม่สนใจทริกเกอร์เหล่านั้น เช่น หากมีแคมเปญที่กำหนดเป้าหมายการติดตั้งแอป คุณอาจต้องการกรองทริกเกอร์หลังการติดตั้งไม่ให้มีการระบุแหล่งที่มาเป็นแหล่งที่มาจากแคมเปญนั้น
   • นอกจากนี้ คุณยังใช้ตัวกรองเพื่อปรับแต่งข้อมูลทริกเกอร์ตามข้อมูลแหล่งที่มาได้ด้วย เช่น แหล่งที่มาอาจระบุ "product" : ["1234"] โดยที่ product คือคีย์ตัวกรองและ 1234 คือค่า ระบบจะไม่สนใจทริกเกอร์ที่มีคีย์ตัวกรองเป็น "product" ซึ่งมีค่าอื่นที่ไม่ใช่ "1234"
3. ลำดับความสำคัญของแหล่งที่มาและทริกเกอร์ที่กำหนดเอง
   • ในกรณีที่แหล่งที่มาของการระบุแหล่งที่มาหลายแหล่งเชื่อมโยงกับทริกเกอร์ได้ หรือทริกเกอร์หลายรายการระบุแหล่งที่มาเป็นแหล่งที่มาเดียวกันได้ คุณสามารถใช้จำนวนเต็ม 64 บิตที่ลงชื่อเพื่อจัดลําดับความสําคัญของการระบุแหล่งที่มาของแหล่งที่มาหรือทริกเกอร์บางรายการเหนือรายการอื่นๆ ได้

การทำงานร่วมกับ MMP และอื่นๆ

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

การทำงานกับการวัดผลข้ามแพลตฟอร์ม

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

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

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