เซสชั่นในการวิเคราะห์มือถือ: คืออะไร วัดอย่างไร และเมตริกส์ใดบ้าง

เซสชั่นในการวิเคราะห์มือถือคืออะไร?

เซสชั่น คือช่วงเวลาที่ผู้ใช้มีปฏิสัมพันธ์อย่างกระตือรือร้นกับแอปพลิเคชัน เซสชั่นเริ่มต้นเมื่อเปิดแอปพลิเคชัน (หรือกลับมาจากเบื้องหลัง) และสิ้นสุดหลังจากช่วงเวลาไม่มีการเคลื่อนไหวหรือการปิด

แพลตฟอร์มการวิเคราะห์ต่างๆ กำหนดขอบเขตของเซสชั่นแตกต่างกัน Firebase Analytics ถือว่าเซสชั่นสิ้นสุดหลังจากไม่มีการเคลื่อนไหว 30 นาที AppsFlyer หลังจาก 60 นาที Amplitude หลังจาก 5 นาทีหรือที่เหตุการณ์ session_end ไม่มีมาตรฐานเดียว

ทำไมเซสชั่นถึงสำคัญ

เมตริกที่อิงกับเซสชั่นเป็นพื้นฐานในการคำนวณอัตราการเก็บผู้ใช้ (Retention Rate) ความลึกของการมีส่วนร่วม (Stickiness Ratio) และการกระจายผู้ใช้ตามความถี่ในการใช้งาน (Session Frequency) หากไม่มีคำจำกัดความเซสชั่นที่ถูกต้อง เมตริกที่ได้มาจากการคำนวณทั้งหมดจะไม่ถูกต้อง

ตามข้อมูลจาก Mixpanel (2024) แอปพลิเคชันที่ปรับปรุง Session Duration ขึ้น 15% มีการเติบโตของ LTV ถึง 22% ภายในหนึ่งไตรมาส นี่คือความสัมพันธ์โดยตรงระหว่างเวลาในแอปพลิเคชันและการสร้างรายได้

วัดเซสชั่นอย่างไร?

การวัดเซสชั่นขึ้นอยู่กับเหตุการณ์วงจรชีวิตของแอปพลิเคชัน: เปิด (session_start) และปิด (session_end) ระหว่างนั้น การกระทำทั้งหมดของผู้ใช้จะถูกบันทึก

// ตัวติดตามเซสชันพื้นฐานสำหรับ Android
class SessionTracker {

    private var sessionStart: Long = 0L
    private val SESSION_TIMEOUT = 30 * 60 * 1000L

    fun onAppOpened() {
        sessionStart = System.currentTimeMillis()
        Analytics.logEvent("session_start")
    }

    fun onAppClosed() {
        val duration = System.currentTimeMillis() - sessionStart
        Analytics.logEvent("session_end") {
            param("duration_ms", duration)
        }
    }

    fun isNewSession(lastActive: Long): Boolean {
        return (System.currentTimeMillis() - lastActive) > SESSION_TIMEOUT
    }
}

โค้ดติดตามจุดเริ่มต้นและสิ้นสุดของเซสชั่นผ่านการเรียกกลับของระบบ พารามิเตอร์ SESSION_TIMEOUT (30 นาที) กำหนดเมื่อการกลับมาจากเบื้องหลังถือเป็นเซสชั่นใหม่ไม่ใช่การต่อเนื่องของเซสชั่นก่อนหน้า

กฎการหมดเวลาตามแพลตฟอร์ม

การเลือกระยะหมดเวลามีผลต่อเมตริก: หมดเวลาสั้น (5 นาที) สร้างเซสชั่นมากขึ้น หมดเวลายาว (60 นาที) รวมการโต้ตอบเข้าด้วยกัน สิ่งสำคัญคือการกำหนดกฎและไม่เปลี่ยนแปลงเมื่อเปรียบเทียบช่วงเวลา

เมตริกเซสชั่นหลัก

การวิเคราะห์เซสชั่นขึ้นอยู่กับเมตริกพื้นฐานสี่อย่าง แต่ละอย่างเผยแง่มุมเฉพาะของพฤติกรรมผู้ใช้

Session Duration

ระยะเวลาเซสชั่นคือเวลาเฉลี่ยที่ผู้ใช้ใช้ในแอปพลิเคชันต่อครั้ง สำหรับแอปข่าว ค่าปกติคือ 2–4 นาที สำหรับเกมส์ 8–15 นาที สำหรับบริการสตรีมมิ่ง 20+ นาที หาก Session Duration ลดลง แสดงถึงปัญหากับเนื้อหาหรือประสิทธิภาพ

Session Interval

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

Sessions Per User

จำนวนเซสชั่นต่อผู้ใช้ในช่วงเวลา (วัน สัปดาห์ เดือน) เป็นตัวชี้วัดความติดแน่น (Stickiness) สูตร: DAU / MAU (ผู้ใช้ที่เคลื่อนไหวระดับรายวัน / ผู้ใช้ที่เคลื่อนไหวระดับรายเดือน) ค่าที่สูงกว่า 20% ถือว่าดี สูงกว่า 50% — ยอดเยี่ยมสำหรับแอปพลิเคชันส่วนใหญ่

Session Depth

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

• Session Duration — เวลาในแอปต่อครั้ง
• Session Interval — ความถี่ในการกลับมา
• Sessions Per User — ระดับการมีส่วนร่วม
• Session Depth — คุณภาพการโต้ตอบ

เซสชั่นใน iOS และ Android

ความแตกต่างของแพลตฟอร์มในวงจรชีวิตของแอปพลิเคชันส่งผลโดยตรงต่อคำจำกัดความของเซสชั่น iOS และ Android จัดการสถานะเบื้องหลังและการแจ้งเตือนแตกต่างกัน

Android — วงจรชีวิตของ Activity

บน Android เซสชั่นเริ่มต้นเมื่อเรียกใช้ onStart() ของ Activity แรกและสิ้นสุดที่ onStop() ของ Activity สุดท้าย อย่างไรก็ตาม ระบบอาจจบกระบวนการในเบื้องหลัง ซึ่งทำให้เซสชั่นสิ้นสุดอย่างผิดพลาด แนะนำให้ใช้ Application.ActivityLifecycleCallbacks เพื่อการติดตามที่เชื่อถือได้

class AnalyticsApp : Application() {

    private var activityReferences = 0

    override fun onCreate() {
        super.onCreate()
        registerActivityLifecycleCallbacks(object : ActivityLifecycleCallbacks {
            override fun onActivityStarted(act: Activity) {
                if (++activityReferences == 1) {
                    Analytics.trackSessionStart()
                }
            }
            override fun onActivityStopped(act: Activity) {
                if (--activityReferences == 0) {
                    Analytics.trackSessionEnd()
                }
            }
        })
    }
}

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

iOS — UIApplicationDelegate

บน iOS เซสชั่นเชื่อมโยงกับเมธอด applicationDidBecomeActive และ applicationDidEnterBackground การแตะแจ้งเตือนแบบ push อาจทำให้จำนวนเซสชั่นเพิ่มขึ้นโดยประดิษฐ์ — สิ่งนี้ต้องนำมาพิจารณาในการวิเคราะห์

ตัวอย่างใน Swift:

import UIKit

class AppDelegate: UIResponder, UIApplicationDelegate {

    func applicationDidBecomeActive(_ application: UIApplication) {
        Analytics.trackSessionStart()
    }

    func applicationDidEnterBackground(_ application: UIApplication) {
        Analytics.trackSessionEnd()
    }
}

หมายเหตุ: บน iOS การสลับระหว่างแอปพลิเคชัน (App Switcher) ไม่ได้สิ้นสุดเซสชั่น — เฉพาะการเข้าสู่เบื้องหลังลึกหรือการปัดปิดเท่านั้นที่ทำให้เซสชั่นสิ้นสุด

วิเคราะห์เซสชั่นของผู้ใช้อย่างไร?

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

การวิเคราะห์โคฮอร์ตของเซสชั่น

จัดกลุ่มผู้ใช้ตาม สัปดาห์การติดตั้ง และดูจำนวนเซสชั่นโดยเฉลี่ยใน 7 วันแรก หากโคฮอร์ตการติดตั้งล่าสุดมี Sessions Per User ต่ำกว่าโคฮอร์ตเก่า นี่เป็นสัญญาณของการเสื่อมคุณภาพของการแนะนำหรือคุณภาพทราฟฟิก

• วันที่ 0 — การติดตั้ง + เซสชั่นแรก
• วันที่ 1–3 — ช่วงเริ่มต้นใช้งาน (คาดว่า 3+ เซสชั่น)
• วันที่ 7–30 — การสร้างนิสัย (1–2 เซสชั่นที่มั่นคงต่อวัน)
• วันที่ 30+ — การเก็บผู้ใช้ที่ภักดี

ความผิดปกติของเซสชั่น: วิธีตรวจจับ

ความผิดปกติในเมตริกเซสชั่นเป็นตัวชี้วัดแรกเริ่มของปัญหา การเพิ่มขึ้นอย่างกะทันหันของเซสชั่นสั้น (น้อยกว่า 5 วินาที) หลังการปล่อยระบุถึงบั๊กในการเริ่มงาน การลดลงของ Session Duration 30% ในหนึ่งวันอาจบ่งชี้ถึงเซิร์ฟเวอร์ขัดข้องหรือการเปลี่ยนแปลง API ตั้งค่าการตรวจสอบพร้อมเกณฑ์: หาก Session Duration โดยเฉลี่ยลดลงมากกว่า 2 ส่วนเบี่ยงเบนมาตรฐานจากค่าเฉลี่ยเคลื่อนที่ 7 วัน ให้เริ่มสัญญาณเตือน

ใช้การแบ่งกลุ่มตามเวอร์ชันของแอปพลิเคชันในรายงานเซสชั่น เวอร์ชัน 3.2.0 แสดง Session Duration 4 นาที เวอร์ชัน 3.2.1 แสดง 2 นาที สาเหตุคือการเปลี่ยนแปลงในกระบวนการแนะนำ การย้อนกลับเวอร์ชันจะคืนค่าเมตริก หากไม่มีการแบ่งกลุ่มตามเวอร์ชัน คุณจะเห็นการลดลงโดยเฉลี่ยแต่จะไม่พบสาเหตุที่แท้จริง

การแบ่งกลุ่มตามความถี่ของเซสชั่น

Power Users (5+ เซสชั่นต่อวัน) — กลุ่มผู้ชมหลักของคุณ Casual Users (1–2 เซสชั่นต่อสัปดาห์) — กลุ่มสำหรับการเปิดใช้งานอีกครั้ง Dormant Users (0 เซสชั่นใน 30 วัน) — ผู้มีสิทธิ์สำหรับการกำหนดเป้าหมายใหม่หรือการเลิกรับการแจ้งเตือนแบบ push

สำหรับแต่ละกลุ่ม ให้คำนวณเมตริกแยกต่างหาก: Session Duration สำหรับ Power Users แสดงความลึกของการใช้งาน ในขณะที่สำหรับ Casual Users แสดงอุปสรรคในการเข้า ตามข้อมูลจาก Amplitude (2024) แอปพลิเคชันที่ปรับแต่งเนื้อหาตามกลุ่มเซสชั่นจะเพิ่ม Session Duration โดยเฉลี่ย 18% ต่อเดือน

การใช้เซสชั่นในรายงานการเก็บผู้ใช้

การเก็บผู้ใช้จะคำนวณผ่านเซสชั่น: ผู้ใช้จะถูกเก็บไว้ในวันที่ N หากพวกเขามีอย่างน้อยหนึ่งเซสชั่นในวันนั้น อย่างไรก็ตาม ผลิตภัณฑ์ที่แตกต่างกันต้องการคำจำกัดความที่แตกต่างกัน สำหรับโซเชียลมีเดีย เซสชั่นอาจเป็น 1 วินาที สำหรับบริการสตรีมมิ่งอาจเป็น 15 นาที

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

การให้เสริมหาเหตุแก่ทราฟฟิกตามเซสชั่น

เชื่อมโยงเซสชั่นกับแหล่งทราฟฟิก: ผู้ใช้จากช่องทางแบบเสียค่าควรมีเซสชั่นมากกว่าและมี Session Duration ยาวกว่า หากทราฟฟิกอินทรีย์แสดง Session Duration สูงกว่าทราฟฟิกเสียค่า 40% แสดงว่ามีปัญหากับคุณภาพของการกำหนดเป้าหมาย การให้เสริมหาเหตุแก่เซสชั่น ช่วยปรับแต่งงบประมาณสำหรับการดึงดูด