90 ngày đầu sau khi ra mắt ứng dụng: nên đo lường điều gì
Vì sao không nên coi lượt tải ngay sau khi ra mắt là kết quả
Lượt tải trong tuần đầu không phải là kết quả, đó chỉ là quy mô của sự chú ý. Phần lớn sự chú ý đó đến từ người quen, thông báo nội bộ và hoạt động truyền thông lúc khai trương. Nó không cho biết sản phẩm có dùng được hay không. Trong 90 ngày đầu, điều cần xác nhận không phải là bao nhiêu người đã tải, mà bao nhiêu người trong số đó đã mở lại.
Lý do lượt tải trông hấp dẫn rất đơn giản. Nó hiện sẵn trong bảng điều khiển của kho ứng dụng, không cần gắn công cụ đo nào cả, con số lại lớn và chỉ đi lên. Vì là số cộng dồn nên nó không bao giờ giảm, và không có con số nào dễ đưa vào báo cáo hàng tuần hơn thế. Nhưng một chỉ số không bao giờ giảm thì cũng không nói lên tình trạng hiện tại. Sản phẩm có xấu đi thì đường biểu diễn vẫn tiếp tục đi lên.
Cùng là một nghìn lượt cài đặt, ý nghĩa thay đổi hoàn toàn tùy theo nguồn. Lượt cài từ thông báo nội bộ phản ánh chỉ đạo của tổ chức chứ không phản ánh sự yêu thích sản phẩm. Lượt cài quét mã tại sự kiện là sản phẩm của không khí tại chỗ, và thường biến mất khỏi màn hình ngay tối hôm đó. Lượt cài từ quảng cáo mang theo kỳ vọng do mẫu quảng cáo tạo ra, và nếu kỳ vọng đó lệch với ứng dụng thì tỷ lệ rời bỏ ngày đầu sẽ rất cao. Gộp cả ba trường hợp vào một dòng thì không đọc được gì.
Vì vậy hãy coi lượt tải là mẫu số chứ không phải kết quả. Khi dùng làm mẫu số thì nó hữu ích. Muốn tính bao nhiêu phần trăm lượt cài trong tuần đã hoàn tất phần giới thiệu ban đầu, bao nhiêu phần trăm quay lại vào hôm sau, ta cần một mẫu số. Khoảnh khắc nhầm mẫu số thành kết quả là lúc cả đội chỉ còn chạy theo việc tăng lượt vào, còn chỗ rò rỉ ở đáy vẫn nguyên như cũ.
Ngay sau khi ra mắt vẫn có một con số đáng xem trước lượt tải: tỷ lệ chuyển đổi từ lượt hiển thị trang kho ứng dụng sang lượt cài đặt. Tỷ lệ này nói về chất lượng trang giới thiệu chứ không nói về sản phẩm. Biểu tượng, hai ảnh chụp màn hình đầu tiên, tiêu đề và dòng mô tả đầu quyết định phần lớn kết quả ở đây. Nếu tỷ lệ chuyển đổi thấp mà lại tăng chi quảng cáo thì chẳng khác nào đổ thêm nước vào thùng thủng.
Còn một điểm nữa cần nói rõ. Hai tuần đầu là giai đoạn dữ liệu bị bóp méo nhiều nhất. Đội phát triển, người kiểm thử nội bộ, đối tác và những người phản ứng với đợt truyền thông đầu tiên trộn lẫn vào nhau. Lấy nhóm người dùng của giai đoạn này làm mốc chuẩn thì mọi phán đoán về sau đều lệch. Nên tách riêng tài khoản nội bộ và thiết bị kiểm thử ngay từ đầu, và lấy mốc chuẩn từ nhóm người dùng vào từ tuần thứ ba trở đi.
Vì sao nhìn giữ chân trước: D1, D7, D30 nói lên điều gì
Giữ chân là chỉ số cho biết sản phẩm có giữ đúng lời hứa hay không. D1 phản ánh ấn tượng đầu tiên, D7 phản ánh mầm mống của thói quen sử dụng lặp lại, D30 cho biết sản phẩm đã có chỗ đứng trong nếp sinh hoạt hay chưa. Ba con số chỉ ra ba kiểu thất bại khác nhau, nên chỉ nhìn một con số thì không biết phải sửa ở đâu.
Trước hết cả đội phải thống nhất định nghĩa. Khi nói giữ chân D1, con số sẽ khác hẳn tùy theo ta hiểu đó là tỷ lệ mở lại đúng ngày hôm sau, hay tỷ lệ quay lại vào bất kỳ lúc nào sau ngày cài đặt. Mỗi công cụ có mặc định riêng, và khi đổi công cụ thì việc so sánh với số liệu cũ bị đứt. Ghi định nghĩa vào một tài liệu và kiểm tra xem mã đo lường với bảng điều khiển có dùng chung định nghĩa đó không, việc này phải làm trước cả việc tìm cách nâng con số lên.
Nếu D1 thấp thì nguyên nhân thường nằm ở đoạn vào. Bắt buộc đăng ký tài khoản, xin quá nhiều quyền, màn hình đầu tiên không cho biết phải làm gì, và độ lệch giữa điều quảng cáo hứa hẹn với điều ứng dụng thực sự mang lại. Đoạn này gần như không liên quan đến chiều sâu của sản phẩm. Tính năng bên trong có hay đến mấy thì người dùng cũng không đi tới đó.
Nếu D7 thấp thì nghĩa là không có lý do để mở lại. Với một tiện ích dùng một lần là xong việc, con số này thấp là chuyện tự nhiên, và sản phẩm kiểu đó nên được đánh giá bằng chu kỳ quay lại và tỷ lệ hoàn thành thay vì bằng giữ chân. Ngược lại, với sản phẩm thiết kế cho việc dùng lặp lại mà D7 sụp xuống thì đó là tín hiệu thiếu vòng lặp cốt lõi. Nhiều đội quy cho việc thiếu thông báo đẩy, nhưng thông báo không tạo ra lý do. Phải có lý do trước thì thông báo mới phát huy tác dụng.
Nếu D30 thấp thì nghĩa là có hứng thú ban đầu nhưng không có giá trị bền. Nội dung cạn nhanh, thiết lập một lần rồi hết việc để làm, hoặc dữ liệu tích lũy mà người dùng không nhận lại được gì. Cải thiện ở đoạn này thường không đến từ việc thêm tính năng, mà đến từ thiết kế trả dữ liệu đã tích lũy về cho chính người dùng.
Bài này sẽ không đưa ra con số kiểu giữ chân trung bình ngành là bao nhiêu phần trăm. Số liệu chuẩn không nêu được nguồn rõ ràng thường được dùng để trấn an hơn là để phán đoán, và kỳ vọng thay đổi tận gốc tùy theo bản chất của ứng dụng. Thay vào đó hãy so sánh với chính mình. Nhóm người dùng vào trong tháng này có tốt hơn nhóm tháng trước không, nhóm vào sau khi sửa phần giới thiệu ban đầu có tốt hơn nhóm vào trước khi sửa không, đó là tiêu chí đáng tin hơn nhiều.
Chu kỳ sử dụng khác nhau thì kỳ vọng cũng phải khác nhau. Với ứng dụng ghi nhận chấm công, việc mở mỗi ngày làm việc là bình thường nên giữ chân theo ngày có ý nghĩa. onSpots mà Yeowubie Interaction vận hành là dịch vụ thuộc nhóm này. Ngược lại, dịch vụ tuyển dụng và tìm việc được dùng tập trung trong giai đoạn tìm việc, và người dùng tự nhiên rời xa khi đã có việc. Áp giữ chân theo ngày lên một dịch vụ như Job Connect VN sẽ cho ra kết luận sai. Hãy định nghĩa chu kỳ sử dụng bình thường của ứng dụng mình trước, rồi nhìn giữ chân bằng cửa sổ thời gian phù hợp với chu kỳ đó.
Cuối cùng, giữ chân bắt buộc phải được tách nhỏ để xem. Tách theo kênh thu hút, theo hệ điều hành, theo phân khúc cấu hình máy, và với sản phẩm đa ngôn ngữ thì tách theo ngôn ngữ hiển thị. Với cấu trúc hỗ trợ đồng thời tiếng Hàn, tiếng Việt và tiếng Anh như Langtori, mỗi ngôn ngữ có đường vào và bối cảnh sử dụng khác nhau, nên một con số trung bình chung không cho thấy bên nào đang có vấn đề. Số trung bình rất giỏi trong việc che đi hai sự thật trái ngược nhau.
Xác định điểm kích hoạt: khoảnh khắc người dùng lần đầu cảm nhận giá trị
Kích hoạt là khoảnh khắc người dùng lần đầu cảm nhận được giá trị cốt lõi của sản phẩm. Nếu không định nghĩa khoảnh khắc này thành một sự kiện cụ thể thì không thể giải thích vì sao giữ chân thấp. Định nghĩa có thể bắt đầu từ giả thuyết của đội, nhưng phải được kiểm chứng bằng dữ liệu trong 90 ngày và viết lại nếu cần.
Cách định nghĩa đơn giản hơn ta tưởng. Viết một câu về lý do tồn tại của ứng dụng, rồi chọn hành động tối thiểu chứng minh được rằng câu đó đã thực sự xảy ra. Với ứng dụng chấm công, đó là thời điểm bản ghi vào ca đầu tiên được lưu không lỗi. Với dịch vụ kết nối người học và người dạy, đó là thời điểm người dùng hoàn thiện hồ sơ và gửi liên hệ đầu tiên. Với dịch vụ tuyển dụng, đó là thời điểm nộp hồ sơ ứng tuyển đầu tiên. Điểm chung là người dùng nhận được thứ gì đó, chứ không phải chúng ta thu được thứ gì đó.
Vì vậy hoàn tất đăng ký tài khoản không phải là kích hoạt. Đăng ký là thủ tục phục vụ sự tiện lợi của chúng ta, và với người dùng thì đó là chi phí. Tải ảnh đại diện, cho phép thông báo, xem hết hướng dẫn cũng vậy. Nếu lấy những mục này làm mốc kích hoạt thì con số lên rất dễ nhưng giữ chân không đi theo, và cả đội không giải thích được vì sao.
Khi đã chốt điểm kích hoạt, hãy đo hai thứ cùng lúc. Một là tỷ lệ đạt tới, tức bao nhiêu phần trăm người dùng mới chạm được sự kiện đó. Hai là thời gian cần để chạm tới. Tỷ lệ đạt tới thấp nghĩa là đường đi bị chặn, còn tỷ lệ đạt tới cao mà thời gian dài nghĩa là đường đi bị vòng vèo. Hai vấn đề này có cách chữa khác nhau.
Cũng có cách kiểm chứng xem định nghĩa có đúng không. Hãy so sánh giữ chân D7 của nhóm đã đạt kích hoạt với nhóm chưa đạt. Nếu khoảng cách giãn ra rõ rệt thì đó là bằng chứng cho thấy định nghĩa đã chạm đúng điểm giá trị thật. Nếu khoảng cách không đáng kể thì định nghĩa sai, và phải đưa một hành động khác vào làm ứng viên rồi lặp lại đúng phép so sánh đó. Phép kiểm chứng này nhất định phải chạy ít nhất một lần trong 90 ngày đầu.
Nên chia hành trình thành khoảng ba đến năm bước. Quá ít bước thì không thấy chỗ tắc, quá nhiều bước thì nhiễu tăng lên và phán đoán bị mờ. Hãy xem tỷ lệ rời bỏ ở từng bước, nhưng chỉ chọn một đoạn rời bỏ lớn nhất để sửa rồi kiểm tra kết quả ở nhóm người dùng tiếp theo. Sửa nhiều chỗ cùng lúc thì không biết điều gì đã tạo ra hiệu quả.
Về mặt kỹ thuật, phần chuẩn bị quan trọng nhất phải xong trước khi ra mắt. Hãy chốt quy tắc đặt tên sự kiện, các thuộc tính bắt buộc và chính sách định danh người dùng thành tài liệu, rồi ra mắt trong trạng thái bộ phận phát triển và bộ phận sản phẩm cùng nhìn một bảng. Gắn công cụ đo sau thì không hồi tố được. Dữ liệu 90 ngày đầu không thể tạo lại, và nhóm người dùng đầu tiên không thể được thay thế bằng bất kỳ nhóm nào về sau. Khi tự làm và tự vận hành sản phẩm của mình, ta thấy rõ mình mất gì nếu đảo lộn thứ tự này. Phát triển xong rồi mới nghĩ đến chỉ số thì đã muộn.
Bốn câu hỏi phải trả lời trong 90 ngày
Mục đích của 90 ngày đầu là học chứ không phải tăng trưởng. Ai ở lại, họ làm gì rồi ở lại, họ rời đi ở đâu, và ta đã trả chi phí thế nào để đưa họ về. Trả lời được bốn câu này có căn cứ thì quyết định của quý tiếp theo thoát khỏi phỏng đoán. Không có câu trả lời thì làm gì cũng là phó mặc cho may rủi.
Thứ nhất, hãy xem ai ở lại. Đây là công việc tìm thuộc tính chung của những người dùng còn trụ lại. Chia theo kênh thu hút, khu vực, thiết bị, nhóm nghề và ngôn ngữ sử dụng rồi so sánh giữ chân. Nếu chỉ một phân khúc trụ lại rõ rệt thì phân khúc đó chính là thị trường thật của sản phẩm lúc này. Nó có thể khác với nhóm mục tiêu đã đặt ra ở giai đoạn lập kế hoạch, và nếu khác thì phần đúng thuộc về dữ liệu. Sau 90 ngày, thứ cần điều chỉnh không phải là người dùng mà là định nghĩa nhóm mục tiêu của chúng ta.
Thứ hai, hãy xem họ làm gì rồi ở lại. Kiểm tra phân bố các màn hình được mở lặp lại và các tính năng được dùng lặp lại của nhóm còn trụ. Ở đây thường xuất hiện một độ lệch quen thuộc: tính năng tốn nhiều công phát triển nhất lại không nằm trong nhóm được dùng nhiều, còn tính năng làm thêm bên lề lại vươn lên nhóm đầu. Đừng bỏ qua tín hiệu này. Căn cứ để viết lại lộ trình sản phẩm của quý sau nằm ở đúng chỗ đó.
Thứ ba, hãy xem họ rời đi ở đâu. Ngoài tỷ lệ rời bỏ theo từng bước, hãy kiểm tra màn hình cuối cùng trong phiên cuối cùng của những người đã rời đi. Và phải đưa chất lượng kỹ thuật vào trong câu hỏi này. Sự cố treo ứng dụng, tình trạng không phản hồi, màn hình chỉ chậm trên một số dòng máy, và các lỗi xảy ra khi mạng không ổn định không phải là vấn đề kỹ thuật tách rời, chúng là nguyên nhân trực tiếp khiến giữ chân thấp. Với thị trường có tỷ lệ máy cấu hình thấp cao, hạng mục này cần được đặt trọng số lớn hơn.
Thứ tư, hãy xem đã trả chi phí thế nào để đưa họ về. Chi phí thu hút theo từng kênh chỉ có ý nghĩa khi được đặt cạnh giữ chân của chính kênh đó. Nếu người dùng đưa về với chi phí rẻ mà hôm sau biến mất hết thì đó là kênh đắt nhất. Muốn so sánh được như vậy thì phải gắn thông tin kênh vào nhóm người dùng ngay tại thời điểm cài đặt, và phần chuẩn bị này cũng phải xong trước khi ra mắt.
Những việc không nên làm trong cùng giai đoạn cũng rất rõ ràng: chạy quảng cáo quy mô lớn và mở rộng tính năng ồ ạt. Tăng mạnh lượng người vào khi hệ thống chỉ số chưa dựng xong thì không thể diễn giải kết quả, còn thêm nhiều tính năng cùng lúc thì vĩnh viễn không biết thay đổi nào đã tạo ra chuyển động nào. Chín mươi ngày không phải giai đoạn mở rộng mà là giai đoạn định vị tọa độ.
Cũng nên chốt nhịp vận hành. Mỗi tuần một lần, vào cùng thứ trong tuần và theo cùng một khuôn mẫu, hãy rà soát các nhóm người dùng, và giới hạn số chỉ số theo dõi thường xuyên ở mức ba đến năm. Dựng vài chục bảng điều khiển thì không ai mở ra xem. Đội nhìn cùng ba con số ở cùng một chỗ mỗi tuần sẽ học nhanh hơn nhiều so với đội tuần nào cũng xem một màn hình hào nhoáng khác nhau.
Không có chỉ số thì không thể tiêu ngân sách marketing
Ngân sách marketing là công cụ để cho nhiều người biết nhanh về một sản phẩm tốt, chứ không phải công cụ khiến một sản phẩm không giữ được người trở nên giữ được người. Tiêu ngân sách khi giữ chân và kích hoạt chưa được kiểm chứng thì chẳng khác nào bỏ tiền đưa về những người sẽ rời đi. Đo lường trước, mở rộng sau.
Thứ tự không khó. Gắn công cụ đo, kiểm chứng định nghĩa kích hoạt bằng dữ liệu, xác nhận giữ chân giữa các nhóm người dùng không dao động thất thường, rồi chia nhỏ kênh để thử nghiệm quy mô nhỏ, và chỉ nhân rộng những kênh sống sót. Bỏ qua thứ tự này thì ngân sách trở thành hao mòn chứ không phải học hỏi. Ngược lại, giữ đúng thứ tự thì cùng một khoản ngân sách sẽ đi được xa hơn nhiều.
Ở giai đoạn đầu ta không thể biết giá trị vòng đời của người dùng, đơn giản vì dữ liệu chưa tích lũy đủ. Điều đó có nghĩa là cũng không thể chốt trần chi phí thu hút, nên trong thực tế người ta phán đoán bằng chỉ số thay thế. Tỷ lệ đạt kích hoạt theo từng kênh và mức trụ lại ở mốc 30 ngày đảm nhiệm vai trò đó. Nếu một kênh đưa người dùng tới điểm kích hoạt tốt và họ vẫn còn ở lại sau một tháng thì đó là căn cứ để chi thêm cho kênh đó, ngay cả khi ta chưa biết chính xác giá trị vòng đời.
Độ khớp giữa mẫu quảng cáo và sản phẩm cũng có thể quản lý bằng chỉ số. Khi lời quảng cáo bị thổi phồng, lượt nhấp và lượt cài tăng lên còn giữ chân ngày đầu tụt xuống. Khoảnh khắc hai con số này nằm trên cùng một bảng là lúc marketing và sản phẩm bắt đầu nói cùng một câu chuyện. Ở tổ chức chỉ nhìn chi phí trên mỗi lượt cài, cuộc trao đổi đó không diễn ra, và vòng lặp quen thuộc lặp lại: đội sản phẩm trách chất lượng người dùng mà marketing đưa về, đội marketing trách độ hoàn thiện của sản phẩm.
Chỉ số phải có chủ. Một người phụ trách rút số theo cùng một định nghĩa mỗi tuần, chia sẻ theo cùng một khuôn mẫu, và ghi lại thời điểm nếu định nghĩa thay đổi. Khi vị trí này bỏ trống, vài tuần sau một chỉ số cùng tên sẽ có hai giá trị khác nhau, và cuộc họp bị dùng để khớp số thay vì để diễn giải số.
Thứ còn lại sau 90 ngày không phải là biểu đồ lượt tải. Thứ còn lại là một câu trả lời có dữ liệu chống lưng, về việc ứng dụng của chúng ta phục vụ ai và làm được gì cho họ. Có câu trả lời đó thì việc chi ngân sách vào đâu, quý sau xây gì, từ chối yêu cầu nào sẽ tự nhiên sáng tỏ. Đây cũng là lý do Yeowubie Interaction vừa tự làm và tự vận hành sản phẩm của mình vừa phát triển sản phẩm cho khách hàng. Những câu hỏi phải đặt ra sau khi ra mắt khác với câu hỏi ở giai đoạn phát triển, và chỉ đội đã từng vận hành mới đưa được khác biệt đó vào thiết kế ngay từ đầu.
Nếu bạn sắp ra mắt, thứ cần rà soát lúc này không phải danh sách tính năng mà là danh sách sự kiện cần đo. Nếu đã ra mắt rồi, hãy thử viết điểm kích hoạt của sản phẩm thành một câu tính đến hôm nay. Nếu câu đó không bật ra ngay, thì việc gấp nhất trong 90 ngày đầu cũng đã được xác định luôn.
