300 Data Challenges Thực Chiến

Data Challenge #171125: Organic Habit Loop

84 Views
13 min read

Business Domain

Công Thức Tạo Ra Sự Gắn Bó

Để xây dựng Sự Tương Tác (Engagement) bền vững, cốt lõi là phải tạo ra được các vòng lặp thói quen (Habit Loops). Đây là cỗ máy vô hình khiến người dùng quay lại sản phẩm một cách tự nhiên. Hai công cụ chính để làm điều này: Organic Habit Loop và Use Case Map.

Vòng Lặp Thói Quen Tự Nhiên (Organic Habit Loop)
  • Đây là một chu trình 3 bước đơn giản nhưng cực kỳ mạnh mẽ:
    • Tác Nhân Kích Hoạt Tự Nhiên (Organic Trigger): 
      • Một tình huống, một vấn đề trong đời thực của user thôi thúc họ hành động. 
      • Ví dụ: “Tới ngày đóng tiền điện rồi.”
    • Hành Động (Action): 
      • User thực hiện một hành động cốt lõi trên sản phẩm của bạn để giải quyết vấn đề. 
      • Ví dụ: Mở App và thanh toán hóa đơn điện.
    • Phần Thưởng (Reward): 
      • User nhận được một giá trị, một cảm giác thỏa mãn ngay sau khi hành động. 
      • Ví dụ: Hóa đơn được thanh toán ngay lập tức, không cần đi đâu cả.
  • Khi vòng lặp này được củng cố, hành động sẽ trở thành một phản xạ gần như vô thức mỗi khi tác nhân kích hoạt xuất hiện.
    • Ví dụ: User có một Organic Trigger là “đến kỳ đóng tiền điện”. Action của anh là mở App để thanh toán, và Reward là cảm giác nhẹ nhõm khi hoàn thành nghĩa vụ ngay lập tức. Vòng lặp này biến App thành công cụ không thể thiếu hàng tháng của họ.
Use Case Map
  • Làm thế nào để thiết kế một vòng lặp thói quen hiệu quả? Use Case Map chính là công cụ để làm điều đó. Nó giúp chúng ta vạch ra chiến lược bằng cách trả lời các câu hỏi cốt lõi.
    • Vấn Đề (Problem) của user sẽ định hình nên Tác Nhân Kích Hoạt (Trigger).
    • Lý Do (Why) user chọn sản phẩm của bạn sẽ định hình nên Phần Thưởng (Reward).
    • Chỉ Số Giữ Chân (Retention Metric) sẽ định nghĩa Hành Động (Action) cốt lõi mà chúng ta muốn user thực hiện.
  • Tóm lại: Để xây dựng một thói quen, bạn phải xác định đúng Vấn Đề, đưa ra đúng Lý Do, và đo lường đúng Hành Động.
    • Ví dụ: User thất bại trong việc hình thành thói quen vì App đã không giải quyết một Problem thực sự của họ. Problem của user là “sợ bỏ lỡ khuyến mãi”, là một nhu cầu yếu. Do đó, Why (“lấy voucher 1 lần”) không đủ mạnh để tạo ra Reward bền vững, dẫn đến Action không được lặp lại.
    • Ngược lại, chiến dịch “hồi sinh” của user khác đã thành công khi nhắm vào một Problem có thật (“thanh toán hóa đơn điện”), tạo ra một Why mới (“tiện lợi và tiết kiệm”), và từ đó thúc đẩy một Action có khả năng lặp lại.
Câu Chuyện Của Tèo Đầu To, Tý Đít Lép & Tủn Bụng Bự

Tèo Đầu To:

Tèo là một Power User điển hình. App không chỉ là một ứng dụng, mà là một công cụ mặc định trong cuộc sống hàng ngày của anh.

Use Case Map của Tèo:

  • Problem: “Cuộc sống của tôi có quá nhiều thứ lặt vặt phải lo: trả hóa đơn, chuyển tiền cho bạn bè, trả tiền cafe, đặt đồ ăn… Tôi cần một cách để xử lý tất cả chúng một cách nhanh chóng, ngay trên điện thoại.”
  • Persona: Người thành thị, 30 tuổi, bận rộn, rành công nghệ, coi trọng sự tiện lợi hơn một vài đồng khuyến mãi.
  • Alternative: Dùng tiền mặt (chậm), Internet Banking (giao diện phức tạp, chuyển tiền lâu).
  • Why: “App gom tất cả các nhu cầu của tôi vào một chỗ. Giao diện nhanh, trải nghiệm mượt mà, và đáng tin cậy.”
  • Frequency: Hàng ngày (trả tiền QR, đặt đồ ăn), hàng tháng (hóa đơn).
  • Retention Metric: Thực hiện >10 giao dịch đa dạng (chuyển tiền, thanh toán, dịch vụ) mỗi tháng.

App đã thành công với Tèo không phải vì một vòng lặp, mà vì đã xây dựng một hệ sinh thái các vòng lặp thói quen:

  • Vòng lặp Hóa đơn: Trigger (Thông báo tới kỳ) -> Action (Thanh toán 1 chạm) -> Reward (Cảm giác hoàn thành nghĩa vụ).
  • Vòng lặp Chuyển tiền: Trigger (Bạn bè đòi nợ) -> Action (Quét QR/Nhập SĐT) -> Reward (Tiền đi ngay lập tức, không cần chờ).
  • Vòng lặp Ăn trưa: Trigger (Đến giờ ăn trưa) -> Action (Mở mục Đặt đồ ăn) -> Reward (Đồ ăn được giao tới, không cần ra ngoài).

Sự thành công này đến từ việc App đã xác định đúng Problem cốt lõi của Tèo (sự tiện lợi) và mang lại một Why vượt trội so với các giải pháp thay thế. Điều này tạo ra Chiều Sâu Tương Tác (Engagement Depth), khiến việc rời bỏ App trở nên khó khăn vì Tèo sẽ phải xây dựng lại toàn bộ hệ thống thói quen của mình trên các nền tảng khác.

Tý Đít Lép:

Tý là một Churned Activated User – một ví dụ về thất bại trong việc xây dựng thói quen sau khi đã kích hoạt người dùng thành công.

Use Case Map của Tý:

  • Problem: “Tý thấy quảng cáo App tặng 100.000đ cho người dùng mới, Tý không muốn bỏ lỡ cơ hội này.” (Problem yếu, chỉ tồn tại một lần).
  • Persona: Sinh viên, nhạy cảm về giá, dễ bị thu hút bởi khuyến mãi lớn, chưa có nhiều nhu cầu chi tiêu online.
  • Alternative: Không dùng app nào cả.
  • Why: “Để lấy được 100.000đ.” (Why cực kỳ nông và chỉ có giá trị một lần).
  • Frequency: Một lần duy nhất.
  • Retention Metric: (App muốn) Tý thực hiện giao dịch đầu tiên và quay lại. (Tý muốn) Dùng xong 100.000đ rồi… xóa app.

Phân tích sự thất bại:

  • Trigger (Manufactured): Tý thấy quảng cáo “Người mới nhận 100k”. Đây là một tác nhân kích hoạt “nhân tạo”, không xuất phát từ nhu cầu thực của Tý.
  • Action: Tý tải app, liên kết ngân hàng (một hành động có độ ma sát cao), và mua một thẻ game 100.000đ (thực chất là miễn phí).
  • Reward: Cảm giác “hời” khi có được thẻ game miễn phí.

Vòng lặp bị phá vỡ ngay tại đây. App đã mắc một sai lầm kinh điển:

  • Đầu tư sai chỗ: Dùng một phần thưởng quá lớn (100k) để kích hoạt một người dùng không có Problem thực sự.
  • Không có cầu nối: Sau khi Tý hoàn thành Action, App đã không làm gì để kết nối anh ta đến một vòng lặp thói quen thực sự. Lẽ ra, ngay sau giao dịch, App phải hiển thị: “Bạn thấy không, thanh toán thật dễ dàng! Thử thanh toán hóa đơn tiền nước tháng này xem sao?” hoặc “Bạn bè của bạn cũng đang dùng App, chuyển 1.000đ cho họ để nhận thêm voucher nhé?”

Bài học: Activation chỉ là bước đầu. Nếu không nhanh chóng dẫn dắt người dùng từ một Trigger nhân tạo sang một Trigger tự nhiên, họ sẽ rời đi ngay khi phần thưởng kết thúc. Tiền đốt cho việc thu hút người dùng như Tý đã hoàn toàn lãng phí.

Tủn Bụng Bự:

Tủn là một Dormant User (người dùng ngủ đông) đã được Hồi Sinh (Resurrected) thành công.

Giai đoạn 1: Ngủ Đông

  • Tủn cài App cách đây 6 tháng chỉ để nhận 200.000đ từ Tèo. Anh nhận tiền xong, rút về tài khoản ngân hàng và quên bẵng đi sự tồn tại của app.
  • Giống như Tý, Action ban đầu của Tủn không gắn với một Problem lặp lại. App chỉ là một công cụ trung gian.

Giai đoạn 2: Chiến Dịch Hồi Sinh

Một ngày, Tủn nhận được email từ App với tiêu đề: “Hóa đơn tiền điện EVN tháng 10 của bạn là 450.000đ. Thanh toán ngay để nhận hoàn tiền 50.000đ.”

  • Trigger (Manufactured, nhưng thông minh): Email này không phải là một quảng cáo chung chung. Nó nhắm chính xác vào một Problem có thật, định kỳ và gây đau đầu cho Tủn (đóng tiền điện). Việc cá nhân hóa (nêu rõ tên nhà cung cấp và số tiền) làm cho tác nhân này trở nên cực kỳ mạnh mẽ.
  • Action: Tủn, bị thôi thúc bởi sự tiện lợi và món hời, quyết định thử. Anh mở lại app, tìm tính năng thanh toán hóa đơn và hoàn thành giao dịch.
  • Reward: Anh nhận được 2 lợi ích: sự nhẹ nhõm vì đã giải quyết xong một việc phải làm, và niềm vui khi tiết kiệm được 50.000đ.

Chiến dịch này đã thành công vì nó đã tái thiết lập một vòng lặp mới một cách khôn ngoan. Nó đã gieo vào đầu Tủn một Why mới và mạnh mẽ hơn: “Dùng MoMo để trả hóa đơn thì vừa nhanh, vừa có lợi.”

Sự hồi sinh mới chỉ là bước đầu. App đã thành công trong việc đưa Tủn thực hiện Action một lần. Câu hỏi quan trọng là: Tháng sau, khi Organic Trigger (“đến hạn đóng tiền điện”) xuất hiện, liệu Tủn có tự mình mở App để thanh toán mà không cần voucher hay không? Việc chuyển đổi Tủn từ một người dùng được “hồi sinh” thành một Casual User (người dùng thường xuyên) sẽ là thước đo thành công thật sự.

Challenge SQL

Ban lãnh đạo muốn biết tổ hợp dịch vụ (service combo) nào mà user sử dụng trong 30 ngày đầu tiên có khả năng biến họ thành người dùng giá trị cao (Power User, Casual User) nhất sau 6 tháng? Ví dụ: combo ‘Chuyển tiền + Nạp điện thoại’ hiệu quả hơn hay combo ‘Thanh toán hóa đơn’ đứng một mình hiệu quả hơn?”

Một số quy tắc:

  • Quy tắc “Service Combo“:
    • Được định nghĩa là tập hợp tất cả các dịch vụ duy nhất mà một user sử dụng trong vòng 30 ngày kể từ ngày có giao dịch đầu tiên.
    • Tên các dịch vụ phải được nối thành một chuỗi.
    • Chuỗi này phải được sắp xếp theo thứ tự bảng chữ cái để đảm bảo tính nhất quán.
  • Quy tắc “Ngày Phân Tích”:
    • Để so sánh công bằng, mỗi user sẽ được đánh giá tại một “ngày phân tích” cố định.
    • Ngày này được xác định là 180 ngày sau ngày giao dịch đầu tiên của user đó.
  • Quy tắc “Phân Khúc Người Dùng sau 6 tháng”:
    • Tại “ngày phân tích”, mỗi user sẽ được gán vào MỘT trong các phân khúc sau, dựa trên hành vi của họ tính đến ngày đó. Logic được áp dụng tuần tự từ trên xuống dưới:
      • Power User: recency_days <= 30 VÀ frequency >= 15 VÀ service_variety >= 3.
      • Casual User: recency_days <= 60.
      • At-Risk User: recency_days <= 120.
      • Churned User: recency_days > 120.
  • Quy tắc “Báo Cáo Tổng Hợp”:
    • Kết quả cuối cùng phải là một bảng tổng hợp.Mỗi hàng đại diện cho một “Service Combo“.
    • Các cột bao gồm các phân khúc người dùng (Power User, Casual User, At-Risk User, Churned User) và tổng số user cho mỗi tổ hợp.

Viết truy vấn SQL Server để có báo cáo tổng hợp tuân thử các quy tắc trên:

service_comboPower UserCasual UserAt-Risk UserChurned UserTotal Users
Bill Payment, P2P Transfer801504063333
Mobile Top-up4018090142452
………………

SQL Coding

-- Bước 1: Tìm ngày giao dịch đầu tiên của mỗi người dùng.
WITH first_transaction_date AS (
    -- WHY: Nền tảng để xác định "cửa sổ 30 ngày" cho mỗi người dùng.
    SELECT
        user_id,
        MIN(transaction_date) AS first_date
    FROM transactions
    GROUP BY user_id
),

-- Bước 2: Xác định "tổ hợp dịch vụ" trong 30 ngày đầu tiên.
user_service_combo AS (
    -- WHY: Thu thập tất cả các dịch vụ mà người dùng thử trong "thời gian vàng" và tạo ra một định danh duy nhất cho nhóm hành vi này.
    SELECT
        t_unique.user_id,
        -- HOW: STRING_AGG để nối tên các dịch vụ DUY NHẤT thành một chuỗi.
        STRING_AGG(s.service_name, ', ') WITHIN GROUP (ORDER BY s.service_name) AS service_combo,
        t_unique.first_date,
        DATEADD(day, 180, t_unique.first_date) AS analysis_date
    FROM (
        SELECT DISTINCT
            ftd.user_id,
            t.service_id,
            ftd.first_date
        FROM first_transaction_date ftd
        JOIN transactions t ON ftd.user_id = t.user_id
        WHERE t.transaction_date BETWEEN ftd.first_date AND DATEADD(day, 30, ftd.first_date)
    ) AS t_unique
    JOIN services s ON t_unique.service_id = s.service_id
    GROUP BY t_unique.user_id, t_unique.first_date
),

-- Bước 3: Tính toán các chỉ số hành vi của người dùng tại "ngày phân tích".
user_profile_metrics AS (
    -- WHY: Tổng hợp các hoạt động thô (raw activities) của người dùng cho đến ngày phân tích.
    SELECT
        usc.user_id,
        usc.service_combo,
        usc.analysis_date,
        COUNT(t.transaction_id) AS frequency,
        MAX(t.transaction_date) AS last_transaction_date,
        COUNT(DISTINCT t.service_id) AS service_variety
    FROM user_service_combo usc
    -- HOW: LEFT JOIN để bao gồm cả những người dùng không có giao dịch nào trong khoảng thời gian phân tích.
    LEFT JOIN transactions t ON usc.user_id = t.user_id AND t.transaction_date <= usc.analysis_date
    GROUP BY usc.user_id, usc.service_combo, usc.analysis_date
),
user_profile_at_analysis_date AS (
    -- WHY: Chuyển đổi các chỉ số thô thành các thước đo có ý nghĩa hơn như "recency".
    SELECT
        upm.user_id,
        upm.service_combo,
        upm.frequency,
        upm.service_variety,
        -- HOW: Nếu không có giao dịch nào, coi như họ đã "churn" (recency rất lớn = 999 ngày).
        COALESCE(DATEDIFF(day, upm.last_transaction_date, upm.analysis_date), 999) AS recency_days
    FROM user_profile_metrics upm
),

-- Bước 4: Gán phân khúc người dùng dựa trên các chỉ số đã tính toán.
final_segments AS (
    -- WHY: Chuẩn hóa hành vi người dùng thành các nhóm chiến lược, giúp tập trung nỗ lực marketing.
    SELECT
        up.user_id,
        up.service_combo,
        -- HOW: Sử dụng một hệ thống phân cấp rõ ràng dựa trên recency và engagement.
        CASE
            -- 1. Power User: Gần đây, tần suất cao, đa dạng. Xương sống của sản phẩm.
            WHEN up.recency_days <= 30 AND up.frequency >= 15 AND up.service_variety >= 3 THEN 'Power User'
            -- 2. Casual User: Gần đây nhưng ít hoạt động hơn. Có tiềm năng trở thành Power User.
            WHEN up.recency_days <= 60 THEN 'Casual User'
            -- 3. At-Risk User: Đã không hoạt động trong 2-4 tháng. Cần được kích hoạt lại.
            WHEN up.recency_days <= 120 THEN 'At-Risk User'
            -- 4. Churned User: Không hoạt động > 4 tháng hoặc không có hoạt động nào. Khả năng cao đã rời bỏ sản phẩm.
            ELSE 'Churned User'
        END AS segment_after_6_months
    FROM user_profile_at_analysis_date up
)

-- Bước 5: Xây dựng bảng tổng hợp cuối cùng.
-- WHY: Trình bày kết quả dưới dạng ma trận dễ đọc để ban lãnh đạo so sánh hiệu quả của các "service_combo".
SELECT
    fs.service_combo,
    -- HOW: Dùng COUNT và CASE WHEN để "xoay" dữ liệu, mỗi phân khúc một cột.
    COUNT(CASE WHEN fs.segment_after_6_months = 'Power User' THEN 1 END) AS [Power User],
    COUNT(CASE WHEN fs.segment_after_6_months = 'Casual User' THEN 1 END) AS [Casual User],
    COUNT(CASE WHEN fs.segment_after_6_months = 'At-Risk User' THEN 1 END) AS [At-Risk User],
    COUNT(CASE WHEN fs.segment_after_6_months = 'Churned User' THEN 1 END) AS [Churned User],
    COUNT(fs.user_id) AS Total_Users
FROM final_segments fs
GROUP BY fs.service_combo
ORDER BY Total_Users DESC;

Với mô hình Challenge-based Learning, bạn sẽ không chỉ học Business Domain, mà được giải các bài toán như trong doanh nghiệp, rèn tư duy phân tích và tạo Portfolio ngay trong các khóa học phân tích dữ liệu thực chiến. Inbox mình TẠI ĐÂY nếu bạn muốn đăng ký nhé!

You may also like