Screen View ในการวิเคราะห์มือถือ — คืออะไร ตัวชี้วัดหลัก และวิธีติดตาม

Screen View คืออะไร?

Screen View คือเหตุการณ์การวิเคราะห์ที่ส่งเมื่อเปิดหน้าจอของแอปพลิเคชันมือถือ เหตุการณ์ประกอบด้วยชื่อหน้าจอ (screen_name) คลาส (screen_class) และการประทับเวลา ต่างจากการวิเคราะห์เว็บที่ page_view ผูกกับ URL ในแอปพลิเคชันมือถือ หน้าจอจะถูกระบุโดยชื่อของ Activity, Fragment, ViewController หรือ Custom View

โครงสร้างของเหตุการณ์ Screen View

พารามิเตอร์ previous_screen มีความสำคัญเป็นพิเศษ: มันช่วยให้สามารถกู้คืนลำดับการเปลี่ยนและสร้าง Screen Flow — แผนที่เส้นทางของผู้ใช้ผ่านแอปพลิเคชัน

Screen View vs Page View: ความแตกต่างหลัก

Screen View และ Page View แก้ปัญหาเดียวกัน — การบันทึกการดู — แต่ในสภาพแวดล้อมที่แตกต่างกัน บนเว็บ URL ระบุหน้าเว็บได้อย่างเฉพาะเจาะจง และ Page View ผูกกับการโหลดเอกสาร ในแอปพลิเคชันมือถือ หน้าจอคือสถานะ UI ที่ไม่จำเป็นต้องสอดคล้องกับที่อยู่แยกต่างหาก

• Page View ผูกกับคำขอ HTTP และ URL — Screen View ผูกกับเหตุการณ์วงจรชีวิตของ Activity/ViewController
• Page View ไม่ซ้ำเมื่อกลับไป (ใช้แคช) — Screen View จะถูกส่งอีกครั้งทุกครั้งที่เปิดหน้าจอ
• Page View โดยทั่วไปสั้นกว่า — ผู้ใช้ดูหน้าเว็บได้เร็วกว่าหน้าจอมือถือที่มีองค์ประกอบแบบโต้ตอบ

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

ข้อผิดพลาดทั่วไปเมื่อทำงานกับ Screen View

ข้อผิดพลาดแรก — การส่ง screen_view ทุกครั้งที่มีการเปลี่ยนแปลงสถานะภายในหน้าจอ (การสลับแท็บ การเปิดป๊อปอัป) Screen View ควรบันทึกเฉพาะการเปลี่ยนไปยังหน้าจอใหม่อย่างสมบูรณ์ ไม่ใช่การโต้ตอบระดับย่อย

ข้อผิดพลาดที่สอง — การใช้ชื่อคลาสทางเทคนิคแทนชื่อที่อ่านได้ “ProductDetailActivityKt” ไร้ประโยชน์สำหรับนักวิเคราะห์ — ใช้ “Product Details” ใน screen_name

ข้อผิดพลาดที่สาม — การส่ง screen_view โดยไม่มีฟิลด์ที่เกี่ยวข้อง screen_name ที่ว่างเปล่าสร้างชุดระเบียนขยะที่ไม่สามารถจัดกลุ่มได้ ส่ง screen_name และ screen_class อย่างน้อยเสมอ แม้บนหน้าจอทดสอบ

วิธีติดตาม Screen View?

การดำเนินการติดตาม Screen View ขึ้นอยู่กับสถาปัตยกรรมการนำทาง มาดูวิธีการแบบอัตโนมัติและแบบด้วยตนเองโดยใช้ Jetpack Compose และ SwiftUI เป็นตัวอย่าง

Android: การติดตามอัตโนมัติใน Jetpack Compose

ใช้ LifecycleEventObserver ที่ระดับ NavigationComponent ทุกครั้งที่ผู้ใช้ไปยัง route ใหม่ เหตุการณ์ screen_view จะถูกเรียก

class ScreenTrackingObserver(
    private val analytics: AnalyticsProvider
) : LifecycleEventObserver {

    override fun onStateChanged(
        source: LifecycleOwner,
        event: Lifecycle.Event
    ) {
        if (event == Lifecycle.Event.ON_RESUME) {
            val route = source.getRouteFromLifecycleOwner()
            analytics.logScreenView(
                screenName = route.screenName,
                screenClass = source.getLocalClassName()
            )
        }
    }
}

// การเชื่อมต่อใน NavHost
fun NavBackStackEntry.trackScreenView(analytics: AnalyticsProvider) {
    lifecycle.addObserver(ScreenTrackingObserver(analytics))
}

วิธีการนี้รับประกันว่า screen_view จะถูกส่งทุกครั้งที่หน้าจอกลับมาไว้ที่พื้นหน้า รวมถึงการกลับมาจากพื้นหลัง Lifecycle.Event.ON_RESUME เป็นช่วงเวลาที่เหมาะสมสำหรับการติดตาม ไม่ใช่ ON_START หรือ ON_CREATE

iOS: การติดตามอัตโนมัติใน SwiftUI

ใน SwiftUI จะใช้ตัวปรับแต่ง onAppear ที่มีอยู่ในทุก View สำหรับระบบอัตโนมัติ จะสร้าง ViewModifier

struct ScreenTrackingModifier: ViewModifier {

    let screenName: String

    func body(content: Content) -> some View {
        content.onAppear {
            Analytics.shared().logScreenView(
                name: screenName,
                className: "\(Self.self)"
            )
        }
    }
}

extension View {
    func trackScreen(_ name: String) -> some View {
        modifier(ScreenTrackingModifier(screenName: name))
    }
}

// การใช้งาน:
ProductDetailView()
    .trackScreen("Product Details")

ตัวปรับแต่ง trackScreen ถูกเพิ่มไปยัง View ใด ๆ ด้วยบรรทัดเดียว นี่เป็นโซลูชันที่สะอาดและปรับขนาดได้สำหรับโปรเจกต์ SwiftUI

Screen View ในโปรเจกต์แบบหลายโมดูล

ในโปรเจกต์ที่มีสถาปัตยกรรมแบบโมดูลาร์ แต่ละโมดูลอาจใช้การตั้งชื่อหน้าจอของตัวเอง ซึ่งนำไปสู่การซ้ำซ้อนของ screen_name enum ScreenName แบบรวมศูนย์ แก้ปัญหา — หน้าจอทั้งหมดถูกตั้งชื่อตามมาตรฐานเดียวในที่เดียว การเพิ่มหน้าจอใหม่ต้องการเพียงค่าคงที่ใหม่ใน enum แทนที่จะค้นหาทั่วทั้งโค้ด

ใช้ sealed class เพื่ออธิบาย screen_name พร้อมการจัดกลุ่มตามฟีเจอร์: ProfileScreen.CHANGE_PASSWORD, OrdersScreen.ORDER_HISTORY, CatalogScreen.SEARCH_RESULTS ซึ่งช่วยให้การกรองในรายงานการวิเคราะห์ง่ายขึ้น

Screen Flow: การวิเคราะห์การเปลี่ยนระหว่างหน้าจอ

Screen Flow (หรือการวิเคราะห์เส้นทาง) คือการแสดงภาพลำดับของหน้าจอที่ผู้ใช้ผ่าน เป็นเครื่องมือหลักในการระบุคอขวดในการนำทาง

การสร้าง Screen Flow

Screen View แต่ละรายการที่มีพารามิเตอร์ previous_screen ให้ขอบของกราฟ: CatalogScreen → ProductDetails → CartScreen โดยการรวมการเปลี่ยนทั้งหมด จะสร้างแผนที่เส้นทาง ฟunnel สามขั้นตอน ที่อิงตาม Screen Flow แสดงว่าผู้ใช้ออกจากที่ใด

• ขั้นตอนที่ 1: HomeScreen → CatalogScreen (95% ดำเนินต่อ)
• ขั้นตอนที่ 2: CatalogScreen → ProductDetails (65% ดำเนินต่อ — 35% ออก)
• ขั้นตอนที่ 3: ProductDetails → AddToCart (30% ดำเนินต่อ — เราสูญเสียอีก 35%)

ตามข้อมูลของ Mixpanel (2024) การวิเคราะห์ Screen Flow เผยให้เห็นปัญหา UX มากถึง 40% ที่ไม่สามารถมองเห็นได้เมื่อวิเคราะห์เหตุการณ์แต่ละรายการ ตัวอย่างเช่น การเปลี่ยน ProductDetails → HomeScreen บ่อยครั้งโดยไม่มีการซื้อบ่งชี้ปัญหากับราคาหรือคำอธิบายสินค้า

การวิเคราะห์การออก (Drop-off)

Drop-off คือจุดที่ผู้ใช้ออกจากสถานการณ์ หาก 60% ของผู้ใช้ออกจากหลังหน้าจอโหลด ปัญหาอยู่ที่ความเร็วในการโหลดหรือแอนิเมชัน หากหลังจาก Paywall — อยู่ในต้นทุนหรือมูลค่าของการสมัครรับข้อมูล

Screen Flow ใน Firebase และ BigQuery

Firebase ไม่มีรายงาน Screen Flow สำเร็จรูป แต่ข้อมูล screen_view พร้อมใช้งานใน BigQuery สร้างคำค้นหาที่จัดกลุ่มการเปลี่ยนตามคู่ (previous_screen, screen_name) และนับความถี่ ผลลัพธ์คือเมทริกซ์การเปลี่ยนที่สามารถแสดงเป็นภาพใน Looker Studio เป็นแผนภาพ Sankey

เสริม Screen Flow ด้วยการแบ่งกลุ่ม: แยกสำหรับผู้ใช้ใหม่ (7 วันแรก) และผู้ใช้ที่กลับมา ผู้ใช้ใหม่มักติดอยู่บนหน้าจอ onboarding ในขณะที่ผู้ใช้ที่มีประสบการณ์ไปถึงการกระทำเป้าหมายได้เร็วกว่า การเปรียบเทียบสองโฟลว์เผยให้เห็นคอขวดในการปรับตัว

เครื่องมือสำหรับการวิเคราะห์ Screen View

การเลือกเครื่องมือ สำหรับการวิเคราะห์ Screen View ขึ้นอยู่กับงบประมาณ สแต็ก และระดับรายละเอียดที่ต้องการ มาดูสามโซลูชันยอดนิยม

Firebase Analytics (ฟรี)

Firebase ติดตามหน้าจอโดยอัตโนมัติผ่านพารามิเตอร์ screen_view ในทุกเหตุการณ์ ไม่ต้องใช้โค้ดเพิ่มเติมหลังจากการรวม SDK ข้อจำกัด: screen_name ถูกสร้างจาก Activity/ViewController ซึ่งไม่ได้ให้ชื่อที่อ่านได้เสมอไป

Amplitude (ระดับมืออาชีพ)

Amplitude มี Pathfinder ในตัว — ตัวสร้าง Screen Flow แบบภาพ รองรับคุณสมบัติผู้ใช้และการแบ่งกลุ่มตามกลุ่ม อนุญาตให้เปลี่ยนชื่อหน้าจอฝั่งเซิร์ฟเวอร์โดยไม่ต้องเปลี่ยนแปลงโค้ดแอปพลิเคชัน

Mixpanel (กลุ่มกลาง)

Mixpanel ให้รายงาน Flows แบบเรียลไทม์ สามารถแสดงไม่เพียงแต่การเปลี่ยนเชิงเส้น แต่ยังรวมถึงการแตกแขนง — หน้าจอใดที่เข้าชมหลังจากหน้าจอเฉพาะ ผสานรวมกับ iOS, Android, Flutter และ React Native SDK

ผลกระทบของ Screen View ต่อประสิทธิภาพ

แต่ละเหตุการณ์ screen_view คือการส่งข้อมูลผ่านเครือข่าย หากแอปส่ง screen_view ทุกครั้งที่เปลี่ยนแท็บ (20+ ต่อนาที) จะสร้างภาระที่ไม่จำเป็น การเพิ่มประสิทธิภาพ: บัฟเฟอร์ screen_view และส่งเป็นชุดทุก 5 วินาที Firebase รวบรวมเหตุการณ์โดยอัตโนมัติ แต่ SDK ที่กำหนดเองอาจส่งแต่ละการเรียกทันที

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