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

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

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

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

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

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

แผนภาพเวิร์กโฟลว์การผสานรวมการระบุแหล่งที่มา

รูปที่ 1 เวิร์กโฟลว์การผสานรวมการระบุแหล่งที่มา

ข้อกําหนดและการตั้งค่า

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

ทำความเข้าใจ API

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ปรับปรุงการออกแบบด้วยฟีเจอร์เสริม

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

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

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

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

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

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

การใช้การวัดผลข้ามแพลตฟอร์ม

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