วิธีเพิ่มจำนวนการแสดงผลของ Web Push

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

ตกลงนิยามให้ตรงกันก่อน: การแสดงผลอยู่ชั้นใดของ Funnel

EngageLab บันทึกสถิติของแต่ละ Push ตามขั้นตอนต่อไปนี้ นิยามของแต่ละขั้นดูได้ที่ สถิติการส่ง Push และ API สถิติ:

flowchart LR
    plan["เป้าหมายตามแผน"]
    targets["เป้าหมายที่ถูกต้อง<br/>อุปกรณ์ที่ใช้งานใน 365 วันล่าสุด"]
    sent["จำนวนที่ส่ง<br/>เซิร์ฟเวอร์สร้างงานส่งสำเร็จ"]
    delivered["จำนวนที่ส่งถึง<br/>ส่งถึงฝั่ง Web จริง"]
    impressions["จำนวนการแสดงผล<br/>แสดงบนอุปกรณ์สำเร็จ"]
    clicks["จำนวนการคลิก"]

    plan --> targets --> sent --> delivered --> impressions --> clicks

ตัวชี้วัด	นิยาม	วิธีคำนวณ
จำนวนเป้าหมายที่ถูกต้อง	จำนวนอุปกรณ์ที่เหลืออยู่หลังกลุ่มเป้าหมายที่เลือกในงาน Push ผ่านการกรองความถูกต้อง	—
จำนวนที่ส่ง	จำนวนอุปกรณ์เป้าหมายที่ถูกต้องซึ่งเซิร์ฟเวอร์ EngageLab สร้างงานส่งสำเร็จจริง	—
จำนวนที่ส่งถึง	จำนวนการแจ้งเตือนที่ส่งถึงฝั่ง Web จริงหลังการส่ง	—
จำนวนการแสดงผล	จำนวนการแจ้งเตือนที่แสดงบนอุปกรณ์สำเร็จจริงหลังส่งถึง	—
อัตราการส่งถึง	—	จำนวนที่ส่งถึง / จำนวนที่ส่ง
อัตราการแสดงผล	—	จำนวนการแสดงผล / จำนวนที่ส่งถึง
อัตราการคลิก	—	จำนวนการคลิก / จำนวนที่ส่งถึง

เกี่ยวกับ "การแสดงผล" มี 3 ประเด็นที่ต้องทำความเข้าใจก่อน มิฉะนั้นอาจเข้าใจผิดว่าปัญหานิยามทางสถิติเป็นปัญหาการส่ง Push:

การแสดงผลรายงานโดย SDK ใน API Callback สถานะ Impression นิยามว่า "การแจ้งเตือน Web Push และข้อความในแอปที่ SDK รายงานว่าแสดงผลสำเร็จ" ดู API Callback การแสดงผลที่ไม่ได้รายงานผ่าน SDK จะไม่ถูกนับเป็นจำนวนการแสดงผล
ข้อความกำหนดเองไม่นับการแสดงผลโดยค่าเริ่มต้น message (ข้อความกำหนดเอง) ใน API สร้าง Push จะไม่แสดงบนเบราว์เซอร์ แต่ส่งผ่านไปยังหน้าเว็บของคุณ หากต้องการนับการแสดงผล คุณต้องเรียก customDisplayReport จากหน้าเว็บเพื่อรายงานเอง ดู Web SDK API
ช่วงเวลาเก็บสถิติคือ 5 วัน การส่งถึงและการแสดงผลที่เกิดขึ้นหลังจากส่งสำเร็จเกิน 5 วันจะไม่ถูกนับรวมและไม่มี Callback อีก

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

ส่วนที่ 1: วิธีค้นหาสาเหตุเมื่อจำนวนการแสดงผลต่ำ

แนะนำให้ตรวจสอบตาม Funnel จากต้นน้ำไปปลายน้ำทีละชั้น โดยดูข้อมูลของแต่ละชั้นก่อนแล้วจึงระบุสาเหตุ

1.1 ฐานผู้สมัครรับใหญ่พอหรือไม่

เพดานของจำนวนการแสดงผลถูกกำหนดด้วยขนาดของผู้ใช้ที่สมัครรับ หากผู้สมัครรับมีน้อยตั้งแต่ต้น อัตราการส่งถึงและอัตราการแสดงผลที่สูงเพียงใดก็ไม่สามารถสร้างจำนวนการแสดงผลที่มีนัยสำคัญได้

ดูที่ไหน:

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

สาเหตุที่พบบ่อย (ดู FAQ และ การตั้งค่าพื้นฐาน):

ใช้วิธี "ขอสิทธิ์โดยตรง" ซึ่งแสดงกล่องขอสิทธิ์แบบเนทีฟของเบราว์เซอร์ เมื่อผู้ใช้คลิก Block / Don't Allow แล้วจะไม่สามารถขอสิทธิ์อีกได้ เว้นแต่ผู้ใช้จะแก้ไขการตั้งค่าเบราว์เซอร์เอง
เว็บไซต์ไม่ได้ใช้ HTTPS หรือยังไม่ได้ตั้งค่าโดเมนในคอนโซล ทำให้ไม่สามารถแสดงกล่องขอสิทธิ์แบบเนทีฟและสมัครรับไม่ได้
Service Worker ไม่ได้อยู่ที่ Root ของเว็บไซต์ หรือขอบเขตชนกับ Service Worker ของ PWA ที่มีอยู่ ทำให้การสมัครรับล้มเหลว
ผู้ใช้ iOS ยังไม่ได้เพิ่มเว็บไซต์ไปยังหน้าจอหลัก หรือคำขอสิทธิ์ไม่ได้ถูกเรียกจากการกระทำของผู้ใช้
ผู้ใช้ใช้โหมดไม่ระบุตัวตน โหมดส่วนตัว หรือโหมดผู้เยี่ยมชม ซึ่งไม่รองรับ Web Push
เมื่อ user_str เดียวกันสมัครรับบนหลายเบราว์เซอร์หรือหลายอุปกรณ์ การสมัครรับใหม่จะแทนที่ของเดิม และมีเพียงอุปกรณ์ที่สมัครรับล่าสุดเท่านั้นที่ได้รับข้อความ

1.2 มีการสูญเสียจำนวนมากจากเป้าหมายที่ถูกต้องไปยังจำนวนที่ส่งหรือไม่

ดูที่ไหน:

ประวัติการส่ง Push: เปรียบเทียบจำนวนเป้าหมายที่ถูกต้องกับจำนวนที่ส่งของ Push แต่ละรายการ และดูสาเหตุความล้มเหลวในรายละเอียดข้อความ
การสอบถามวงจรชีวิตของ Push ใน API สถิติ: สถานะ target_invalid และ sent_failed ช่วยระบุขั้นตอนที่สูญเสียของอุปกรณ์แต่ละเครื่อง

สาเหตุที่พบบ่อย:

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

1.3 มีการสูญเสียจำนวนมากจากจำนวนที่ส่งไปยังจำนวนที่ส่งถึงหรือไม่

นี่คือชั้นที่มักถูกเข้าใจผิดว่าเป็น "การแสดงผลต่ำ" มากที่สุด หากจำนวนที่ส่งถึงต่ำ จำนวนการแสดงผลย่อมต่ำตาม แต่อัตราการแสดงผลในกรณีนี้อาจปกติ

ดูที่ไหน:

อัตราการส่งถึงของ Push แต่ละรายการในประวัติการส่ง Push; ข้อมูลการส่งถึงแยกตามเบราว์เซอร์ (Chrome, Safari, Firefox, Edge, ช่องทาง EngageLab ฯลฯ) ในสถิติการส่ง Push
ฟิลด์ sub ที่ API สถิติส่งกลับสามารถดูการส่งถึงและการแสดงผลของ notification และ message แยกกัน และฟิลด์ engageLab_web, chrome, safari, firefox, edge ช่วยแยกตามช่องทาง

สาเหตุที่พบบ่อย (ดู API สร้าง Push และ FAQ):

ตั้ง time_to_live เป็น 0: ไม่เก็บข้อความออฟไลน์ มีเพียงผู้ใช้ที่ออนไลน์ในขณะนั้นเท่านั้นที่ได้รับ ค่าเริ่มต้นคือ 86400 วินาที (1 วัน) สูงสุด 15 วัน
ความแตกต่างของช่องทาง: ช่องทาง EngageLab ต้องให้ผู้ใช้เปิดหน้าเว็บไซต์ของคุณอยู่จึงจะรับได้; ช่องทางระบบ (Chrome, Edge, Firefox ฯลฯ) รับได้ตราบใดที่โปรเซสของเบราว์เซอร์ยังอยู่ในระบบปฏิบัติการ แต่หากปิดเบราว์เซอร์สมบูรณ์จะไม่ได้รับ; ช่องทางระบบของ Safari ไม่ต้องให้เบราว์เซอร์ทำงานอยู่
ผู้ใช้ล้าง Cookie / แคชของเบราว์เซอร์ ทำให้ข้อมูลการสมัครรับของช่องทางผู้ให้บริการหายไปด้วย หากสิทธิ์การแจ้งเตือนยังเป็น "อนุญาต" เมื่อผู้ใช้กลับมายังเว็บไซต์และ SDK เริ่มต้นทำงาน จะสมัครรับใหม่อัตโนมัติและได้ Registration ID ใหม่ แต่หากสิทธิ์ถูกเปลี่ยนเป็น "ถาม" หรือ "บล็อก" จะไม่สมัครรับใหม่อัตโนมัติ
กลยุทธ์ third_party_channel.w3push.distribution ไม่สอดคล้องกับพฤติกรรมผู้ใช้ เช่น บังคับใช้ mtpush (ช่องทาง EngageLab เท่านั้น) ทั้งที่ผู้ใช้แทบไม่อยู่บนเว็บไซต์
ช่องทางของผู้ให้บริการเบราว์เซอร์ไม่เสถียร FAQ แนะนำให้สลับไปส่งโดยให้ช่องทาง EngageLab มาก่อนในกรณีนี้

1.4 มีการสูญเสียจากจำนวนที่ส่งถึงไปยังการแสดงผลหรือไม่ (อัตราการแสดงผลต่ำ)

เมื่อจำนวนที่ส่งถึงปกติแต่จำนวนการแสดงผลต่ำอย่างชัดเจน จึงเป็นปัญหา "อัตราการแสดงผล" ที่แท้จริง

ดูที่ไหน:

"จำนวนที่ส่งถึง / จำนวนการแสดงผล" และอัตราส่วนแยกตามแพลตฟอร์มในรายละเอียดของประวัติการส่ง Push
อีเวนต์ Impression และ impression_failed ของ API Callback

สาเหตุที่พบบ่อย:

อาการ	สาเหตุที่เป็นไปได้	ตำแหน่งตรวจสอบ
จำนวนการแสดงผลของข้อความกำหนดเองใกล้ 0	`message` ไม่แสดงบนเบราว์เซอร์ และไม่ได้เรียก `customDisplayReport` เพื่อรายงาน	API สถิติ `sub.message`; โค้ดหน้าเว็บ
จำนวนการแสดงผลของช่องทาง Safari เป็น 0 หรือต่ำอย่างชัดเจน	Safari ส่งผ่านช่องทางระบบ SDK ไม่สามารถรับ Callback การแสดงผลและการคลิก	สถิติการส่ง Push แยกตามเบราว์เซอร์
ส่งหลายการแจ้งเตือนถึงผู้ใช้เดิมในเวลาสั้นๆ แต่นับการแสดงผลได้เพียง 1	Chrome, Edge, Firefox มีกลไกเขียนทับ การแจ้งเตือนแต่ละรายการจะถูกแทนที่ด้วยรายการใหม่กว่า แสดงเพียงรายการล่าสุด; ช่องทาง EngageLab และ Safari ไม่มีกลไกเขียนทับ	FAQ "ส่งหลายข้อความถึงผู้ใช้เดียวกันในเวลาเดียวกัน จะแสดงทั้งหมดหรือไม่"
ข้อความในแอปเกิด Callback `impression_failed`	แยกวิเคราะห์ล้มเหลว เกินระยะเวลาการแสดงผล ถูกลบเพราะแคชในเครื่องเกินขีดจำกัด หรือดาวน์โหลดรูปภาพล้มเหลว	API Callback; การตั้งค่าระยะเวลาการแสดงผลใน สร้าง Push
กลุ่มผู้ใช้บางกลุ่มไม่แสดงผลเลย	สิทธิ์การแจ้งเตือนของหน้าเว็บหรือของแอปเบราว์เซอร์ถูกปิด; Focus Assist ของ Windows หรือห้ามรบกวน / โหมดโฟกัสของ macOS ทำงานอยู่	FAQ "วิธีตรวจสอบเมื่อไม่ได้รับการแจ้งเตือน"
ตัวเลขไม่ตรงกัน	นับเฉพาะการแสดงผลภายใน 5 วันหลังส่งสำเร็จ; หลายอุปกรณ์ของผู้ใช้เดียวกันนับเป็นผู้ใช้ที่สมัครรับ 1 ราย	นิยามในสถิติการส่ง Push

1.5 เช็กลิสต์การตรวจสอบ

แนะนำให้ตรวจสอบตามลำดับในตารางด้านล่าง โดยตัดปัญหาด้านนิยามและต้นน้ำออกก่อน แล้วจึงดูการแสดงผลเอง:

ลำดับ	รายการตรวจสอบ	เกณฑ์ตัดสิน	อ้างอิง
1	ประเภทข้อความ	เป็นการแจ้งเตือนหรือข้อความกำหนดเอง? ข้อความกำหนดเองรายงานการแสดงผลแล้วหรือไม่	Web SDK API
2	ขนาดฐานผู้สมัครรับ	ผู้ใช้ที่สมัครรับ / ผู้ใช้ที่ใช้งาน ต่ำอย่างชัดเจนหรือไม่	ภาพรวมผู้ใช้, ภาพรวม
3	วิธีขอสิทธิ์	ใช้การขอสิทธิ์แบบแนะนำ (Soft Prompt) หรือไม่	การตั้งค่าพื้นฐาน
4	HTTPS, โดเมน, Service Worker	ครบทุกข้อและไม่มีขอบเขตชนกันหรือไม่	คู่มือการผสานรวม Web SDK
5	เป้าหมายที่ถูกต้อง → จำนวนที่ส่ง	ถูกทิ้งเพราะการควบคุมความถี่หรือช่วงเวลาที่อนุญาตหรือไม่	การตั้งค่าขั้นสูง, ประวัติการส่ง Push
6	`time_to_live`	เป็น 0 หรือสั้นเกินไปหรือไม่	API สร้าง Push
7	กลยุทธ์ `distribution`	สอดคล้องกับพฤติกรรมการใช้งานเว็บไซต์ของผู้ใช้หรือไม่	API สร้าง Push
8	แยกตามช่องทาง	การส่งถึง / การแสดงผลของ Safari, ช่องทาง EngageLab, Chrome ฯลฯ แตกต่างกันมากหรือไม่	สถิติการส่ง Push, API สถิติ
9	ความถี่การส่ง	ส่งหลายข้อความถึงผู้ใช้เดียวกันในเวลาสั้นๆ หรือไม่	FAQ
10	การตั้งค่าระบบฝั่งผู้ใช้	สิทธิ์การแจ้งเตือน, Focus Assist, ห้ามรบกวน	FAQ

ส่วนที่ 2: เมื่อพบสาเหตุแล้ว จะปรับปรุงให้ตรงจุดอย่างไร

2.1 ขยายฐานผู้สมัครรับ

เปลี่ยนมาใช้การขอสิทธิ์แบบแนะนำ (Soft Prompt) ในสิทธิ์การแจ้งเตือนของ การตั้งค่าพื้นฐาน เลือก "การขอสิทธิ์แบบแนะนำ": อธิบายคุณค่าของการแจ้งเตือนให้ผู้ใช้ทราบด้วยรูปแบบที่กำหนดเองก่อน แล้วจึงเรียกกล่องขอสิทธิ์แบบเนทีฟเมื่อผู้ใช้แสดงความต้องการ เพื่อหลีกเลี่ยงการที่ผู้ใช้คลิก Block โดยยังไม่เข้าใจคุณค่า ซึ่งจะทำให้ไม่สามารถขอสิทธิ์ได้อีกถาวร Soft Prompt รองรับการตั้งค่าช่วงเวลาแจ้งครั้งแรก (ค่าเริ่มต้น 3 วัน) และช่วงเวลาแจ้งครั้งถัดไป (ค่าเริ่มต้น 7 วัน) จนกว่าผู้ใช้จะสมัครรับ
ตรวจสอบเงื่อนไขเบื้องต้นให้ครบ เว็บไซต์ต้องใช้ HTTPS และตั้งค่าโดเมนใน [การตั้งค่าการผสานรวม] - [โดเมนเว็บไซต์] (สูงสุด 100 รายการ); วางไฟล์ Service Worker ที่ Root ของเว็บไซต์เพื่อให้ได้ขอบเขตสูงสุด; หากเว็บไซต์มี Service Worker ของ PWA อยู่แล้ว ให้รวมทั้งสองเข้าด้วยกันหรือทำให้ขอบเขตไม่ซ้อนทับกัน ดู คู่มือการผสานรวม Web SDK และ FAQ
แนะนำผู้ใช้ iOS Safari บน iOS / iPadOS 16.4 ขึ้นไป ผู้ใช้ต้องเพิ่มเว็บไซต์ไปยังหน้าจอหลักและเปิดจากหน้าจอหลักก่อน แล้วจึงเรียกขอสิทธิ์ผ่านการกระทำของผู้ใช้ (เช่น แตะปุ่มสมัครรับ) แนะนำให้วางแบนเนอร์แนะนำบนหน้าเว็บ
หลีกเลี่ยงอุปกรณ์แทนที่กันเอง หากคุณใช้ user_str ระบุตัวผู้ใช้ โปรดทราบว่าเมื่อ user_str เดียวกันสมัครรับบนหลายเบราว์เซอร์ / หลายอุปกรณ์ จะมีเพียงอุปกรณ์ที่สมัครรับล่าสุดเท่านั้นที่ได้รับข้อความ หากต้องการครอบคลุมทุกอุปกรณ์ของผู้ใช้ อย่าใช้ user_str เดียวกันซ้ำบนอุปกรณ์ต่างเครื่อง
อย่าสูญเสียการสมัครรับระหว่างการย้ายระบบ เมื่อย้ายจากผู้ให้บริการอื่นมายัง EngageLab ให้จัดการ Service Worker เดิมตาม วิธีป้องกันการสูญเสียผู้สมัครรับระหว่างการย้าย Web Push ผู้ใช้ที่ให้สิทธิ์แล้วจะไม่เห็นกล่องขอสิทธิ์อีกหลังเริ่มต้นทำงาน

2.2 ลดการสูญเสียจากเป้าหมายที่ถูกต้องไปยังจำนวนที่ส่ง

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

2.3 เพิ่มการส่งถึง

ตั้งค่า time_to_live ให้เหมาะสม อย่าใช้ 0; คงค่าเริ่มต้น 1 วันหรือขยายตามความทันเวลาของเนื้อหา สูงสุด 15 วัน สำหรับเนื้อหาที่ไม่เร่งด่วน การขยายเวลาเก็บข้อความออฟไลน์จะช่วยให้ผู้ใช้ที่ออฟไลน์ยังได้รับเมื่อเปิดเบราว์เซอร์อีกครั้ง
เลือกกลยุทธ์การกระจายที่เหมาะสม ใน third_party_channel.w3push.distribution:
- first_ospush (ค่าเริ่มต้น): ใช้ช่องทางระบบก่อน หากใช้ไม่ได้จึงใช้ช่องทาง EngageLab
- secondary_push: ใช้ช่องทาง EngageLab ก่อน หากผู้ใช้ไม่ออนไลน์จึงใช้ช่องทางระบบ; API สร้าง Push แนะนำวิธีนี้
- mtpush: บังคับใช้ช่องทาง EngageLab เหมาะเฉพาะกรณีที่ผู้ใช้อยู่บนเว็บไซต์เป็นเวลานาน
- ospush: บังคับใช้ช่องทางระบบเท่านั้น
เมื่อช่องทางของผู้ให้บริการเบราว์เซอร์ไม่เสถียร สามารถสลับไปให้ช่องทาง EngageLab มาก่อนเป็นการชั่วคราวได้
ใช้ override_msg_id อย่างระมัดระวัง การเขียนทับการแจ้งเตือนก่อนหน้าที่ยังไม่ถูกล้างจะทำให้ผู้ใช้เห็นเพียงรายการล่าสุด เหมาะกับสถานการณ์อัปเดตเนื้อหา ไม่เหมาะกับกรณีที่ต้องการให้หลายการแจ้งเตือนแสดงพร้อมกัน
ใช้การส่งแบบควบคุมอัตราสำหรับแคมเปญหรือการส่งจำนวนมาก ใช้ big_push_duration เพื่อกระจายการส่งอย่างสม่ำเสมอภายในจำนวนนาทีที่กำหนด (สูงสุด 1440 นาที) หลีกเลี่ยงจุดพีกชั่วขณะ

2.4 เพิ่มการแสดงผล

ใช้ข้อความแจ้งเตือนเป็นหลัก เนื้อหาที่ต้องแสดงในแถบการแจ้งเตือนและนับการแสดงผล ให้ใช้ notification แทน message; หากธุรกิจจำเป็นต้องใช้ข้อความกำหนดเองจริง ให้เรียก customDisplayReport('msg_id') หลังแสดงบนหน้าเว็บ และเรียก customClickReport('msg_id') เมื่อคลิก
หลีกเลี่ยงการส่งหลายการแจ้งเตือนติดกันถึงผู้ใช้เดียวกันในเวลาสั้นๆ บน Chrome, Edge, Firefox การแจ้งเตือนที่มาทีหลังจะแทนที่รายการก่อนหน้า ผู้ใช้จึงเห็นเพียงรายการล่าสุดและนับการแสดงผลได้เพียง 1 ให้รวมเนื้อหาหลายรายการเป็นหนึ่งการแจ้งเตือน หรือเว้นช่วงเวลาการส่ง
ใส่ใจความเข้ากันได้ของสื่อและข้อความกับเบราว์เซอร์ icon แนะนำ 192×192 ไม่เกิน 1 MB รองรับไอคอนกำหนดเองเฉพาะ Chrome และ Firefox ส่วน Safari และ Edge ใช้ไอคอนเริ่มต้นของระบบ; image แนะนำ 360×180 ไม่เกิน 1 MB รองรับเฉพาะ Chrome และ Edge ไม่รองรับ Firefox และ Safari ช่องทางระบบจำกัดความยาวหัวเรื่อง (ภาษาจีนน้อยกว่า 20 ตัวอักษร ภาษาอังกฤษน้อยกว่า 40 ตัวอักษร) หัวเรื่องยาวเกินอาจส่งผลต่อการแสดงผล
ตั้งระยะเวลาการแสดงผลที่เหมาะสมสำหรับข้อความในแอป เมื่อเกินระยะเวลาแล้วผู้ใช้กลับเข้าหน้าเว็บจะไม่แสดง และเกิด impression_failed เนื้อหาที่ไม่เร่งด่วนควรขยายระยะเวลา และควบคุมขนาดรูปภาพเพื่อหลีกเลี่ยงการดาวน์โหลดล้มเหลว
ส่งในช่วงเวลาที่ผู้ใช้ใช้งาน ใช้การส่งอัจฉริยะใน งานตามกำหนดเวลา หรือข้อมูลการจับคู่เวลาใช้งานในสถิติการส่ง Push เพื่อส่งในช่วงที่ผู้ใช้มีแนวโน้มเปิดเบราว์เซอร์อยู่ ลดการหมดอายุเพราะออฟไลน์
ตีความข้อมูล Safari ให้ถูกต้อง ช่องทางระบบของ Safari ไม่สามารถส่ง Callback การแสดงผลและการคลิก จำนวนการแสดงผลที่ต่ำในช่องทางนี้เป็นข้อจำกัดด้านสถิติ ไม่ได้หมายความว่าการแจ้งเตือนไม่แสดง เมื่อประเมินอัตราการแสดงผลควรแยก Safari ออกจากช่องทางอื่น

ส่วนที่ 3: แนวทางแบบองค์รวมเพื่อเพิ่มจำนวนการแสดงผลอย่างเป็นระบบ

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

3.1 สร้างมุมมองการติดตามแยกตามช่องทาง

ติดตาม Funnel การแปลงของ Push แนวโน้มอัตราการส่งถึง / การแสดงผล / การคลิก และจำนวนผู้ใช้ที่เปิด / ปิดสิทธิ์การแจ้งเตือนใน ภาพรวม ทุกวัน
ใน สถิติการส่ง Push ดูการส่งถึงและการแสดงผลแยกตามเบราว์เซอร์ โดยเน้น Chrome และช่องทาง EngageLab; ประเมิน Safari แยกต่างหาก
รับอีเวนต์ delivered, Impression, impression_failed, click ฯลฯ ผ่าน API Callback และจัดเก็บลงฐานข้อมูล เพื่อวิเคราะห์ระดับผู้ใช้และระดับข้อความได้ละเอียดกว่าคอนโซล (สถิติรายข้อความเก็บที่ฝั่ง EngageLab สูงสุดหนึ่งเดือน)
กำหนดเส้นฐานแยกกันสำหรับอัตราการส่งถึงและอัตราการแสดงผล: หากอัตราการส่งถึงลดลงผิดปกติ ให้ตรวจ time_to_live กลยุทธ์การกระจาย และช่องทางผู้ให้บริการก่อน; หากอัตราการแสดงผลลดลงผิดปกติ ให้ตรวจประเภทข้อความ การเขียนทับจากหลายการแจ้งเตือน และสิทธิ์ฝั่งผู้ใช้ก่อน

3.2 รายการดำเนินการแยกตามระยะ

ระยะเชื่อมต่อ (ก่อนและหลังเปิดใช้งาน)

ใช้ HTTPS ตั้งค่าโดเมน วาง Service Worker ที่ Root และยืนยันว่าไม่มีขอบเขตชนกัน
เลือก "การขอสิทธิ์แบบแนะนำ" สำหรับสิทธิ์การแจ้งเตือน ตั้งค่าข้อความและช่วงเวลาของ Soft Prompt
เตรียมคำแนะนำการเพิ่มไปยังหน้าจอหลักสำหรับผู้ใช้ iOS
ใช้ข้อความแจ้งเตือน (notification) แทนข้อความกำหนดเอง (message) เป็นช่องทางเข้าถึงหลัก
ระหว่างทดสอบร่วมกัน ใช้ประวัติการส่ง Push และค้นหาข้อมูลเพื่อยืนยันว่าสถานะออนไลน์ การส่งถึง และการแสดงผลของอุปกรณ์เป้าหมายนับได้ถูกต้อง

ระยะเติบโต (การดำเนินงานประจำวัน)

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

ระยะแคมเปญ (การส่งช่วงพีก)

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

3.3 สรุปในประโยคเดียว

จำนวนการแสดงผล = ผู้ใช้ที่สมัครรับ × สัดส่วนเป้าหมายที่ถูกต้อง × อัตราการส่งถึง × อัตราการแสดงผล ใช้ข้อมูล Funnel ตัดสินว่าการสูญเสียเกิดขึ้นชั้นใดก่อน แล้วปรับปรุงชั้นนั้น; สำหรับชั้น "การแสดงผล" เอง หัวใจสำคัญคือใช้ข้อความแจ้งเตือนและทำให้ SDK รายงานได้ หลีกเลี่ยงการเขียนทับจากหลายการแจ้งเตือน และตีความข้อมูลแยกตามช่องทาง

ตกลงนิยามให้ตรงกันก่อน: การแสดงผลอยู่ชั้นใดของ Funnel

ส่วนที่ 1: วิธีค้นหาสาเหตุเมื่อจำนวนการแสดงผลต่ำ

1.1 ฐานผู้สมัครรับใหญ่พอหรือไม่

1.2 มีการสูญเสียจำนวนมากจากเป้าหมายที่ถูกต้องไปยังจำนวนที่ส่งหรือไม่

1.3 มีการสูญเสียจำนวนมากจากจำนวนที่ส่งไปยังจำนวนที่ส่งถึงหรือไม่

1.4 มีการสูญเสียจากจำนวนที่ส่งถึงไปยังการแสดงผลหรือไม่ (อัตราการแสดงผลต่ำ)

1.5 เช็กลิสต์การตรวจสอบ

ส่วนที่ 2: เมื่อพบสาเหตุแล้ว จะปรับปรุงให้ตรงจุดอย่างไร

2.1 ขยายฐานผู้สมัครรับ

2.2 ลดการสูญเสียจากเป้าหมายที่ถูกต้องไปยังจำนวนที่ส่ง

2.3 เพิ่มการส่งถึง

2.4 เพิ่มการแสดงผล

ส่วนที่ 3: แนวทางแบบองค์รวมเพื่อเพิ่มจำนวนการแสดงผลอย่างเป็นระบบ

3.1 สร้างมุมมองการติดตามแยกตามช่องทาง

3.2 รายการดำเนินการแยกตามระยะ

3.3 สรุปในประโยคเดียว

เอกสารอ้างอิง