Analytics tối thiểu: ba sự kiện và một định danh người dùng

Không đo lường thì mất gì khi làm marketing

Thứ biến mất là quan hệ nhân quả. Bảng điều khiển quảng cáo và cửa hàng ứng dụng cho bạn biết đã chi bao nhiêu và có bao nhiêu lượt cài đặt. Nhưng người đã cài đặt mở ứng dụng lên rồi làm gì thì chỉ bên trong ứng dụng mới biết. Không ghi lại đoạn đó, mọi kết luận về kênh nào hiệu quả đều là phỏng đoán.

Bảng điều khiển của cửa hàng cho bạn lượt cài, lượt gỡ, điểm đánh giá và phân bố theo quốc gia. Bảng điều khiển quảng cáo cho bạn lượt hiển thị, lượt nhấp và chi phí cho mỗi lượt cài. Cả hai đều là con số bên ngoài ứng dụng. Người dùng dừng lại ở màn hình đầu tiên, đi đến bước đăng ký, hay đã dùng thử tính năng chính một lần, không màn hình nào trong hai nơi đó trả lời được. Khi bên trong ứng dụng trống rỗng mà vẫn tối ưu quảng cáo, mục tiêu sẽ tự động tụt xuống thành chi phí mỗi lượt cài. Chiến dịch nào tạo ra lượt cài rẻ nhất sẽ thắng, kể cả khi phần lớn số cài đó biến mất ngay trong ngày đầu.

Thứ hai bị mất là cơ sở để tranh luận về sản phẩm. Không có số liệu, lập luận trong cuộc họp được lấp đầy bằng cảm giác. Một bên nói quy trình khởi động quá dài, một bên nói ngắn rồi vẫn không ai dùng, và kết luận nghiêng về người nói to hơn. Sửa một màn hình xong cũng không biết có tốt lên hay không, nên không thể xếp thứ tự cho lần cải tiến tiếp theo. Kéo dài vài tháng, đội ngũ sẽ chọn cách thêm tính năng thay vì cải thiện, vì thứ nhìn thấy được luôn có vẻ an toàn hơn thứ không kiểm chứng được.

Mất mát thứ ba là lớn nhất. Đo lường không hồi tố. Sự kiện gắn hôm nay chỉ tích lũy từ hôm nay. Vài tuần ngay sau khi phát hành là quãng duy nhất người dùng gặp sản phẩm lần đầu, và nếu không có bản ghi thì quãng đó không thể dựng lại. Sau này khi đối tác hoặc nhà đầu tư hỏi về phản ứng ban đầu, bạn cũng không còn tài liệu để đưa ra. Mất dữ liệu không thể tái tạo là mất mát lớn hơn vài tuần ngân sách quảng cáo.

Trên thực tế, vấn đề phổ biến hơn không phải là quyết định không đo lường. Đó là bản thiết kế đo lường quá lớn nên cuối cùng không gắn được gì. Khi danh sách sự kiện lên tới bốn mươi mục, nó bị đẩy xuống cuối lịch phát triển, sản phẩm ra mắt trong tình trạng đó, và sau khi ra mắt thì không còn ai đụng vào nữa. Kể cả có gắn, một nửa sẽ kích hoạt sai chỗ, và nhiều tháng trôi qua mà không ai biết. Vì vậy điểm xuất phát nên là một thiết kế tối thiểu chắc chắn sống sót, chứ không phải một thiết kế hoàn chỉnh.

Mục tiêu của thiết kế tối thiểu không phải là thu thập ít dữ liệu. Mục tiêu là có được những con số đáng tin trước đã. Ba con số có định nghĩa rõ ràng hữu ích cho việc ra quyết định hơn nhiều so với bốn mươi con số không ai tin. Khi ba con số đó chạy ổn định, việc mở rộng sau này trở nên dễ dàng. Làm ngược thứ tự thì hầu hết các đội đều quay lại vạch xuất phát.

Tiêu chí để rút gọn còn ba sự kiện

Tiêu chí chỉ có một. Khi con số đó tăng hay giảm, đội ngũ có hành động khác đi không. Những sự kiện vượt qua câu hỏi này thường quy về ba: khoảnh khắc mở ứng dụng lần đầu, khoảnh khắc trải nghiệm giá trị cốt lõi một lần, và khoảnh khắc lặp lại trải nghiệm đó. Có thể gọi là thu hút, kích hoạt và lặp lại.

Sự kiện thứ nhất là lần mở ứng dụng đầu tiên. Phần lớn công cụ analytics tự thu thập lần chạy đầu và phiên làm việc, nên bạn ít phải tự định nghĩa. Tuy vậy phạm vi thu thập tự động khác nhau giữa các công cụ, nên hãy kiểm tra trước xem cái gì đã có sẵn rồi mới thiết kế phần còn lại. Nếu không kiểm tra mà gắn thêm thủ công một sự kiện trùng, con số sẽ phồng lên gấp đôi ngay từ bước đầu tiên.

Công việc thiết kế thật sự nằm ở sự kiện thứ hai. Kích hoạt là khoảnh khắc người dùng lần đầu cầm được giá trị mà sản phẩm hứa hẹn. Định nghĩa khác nhau theo từng sản phẩm. Với dịch vụ quản lý điểm danh, ứng viên là khoảnh khắc một lượt điểm danh được ghi lại. Với dịch vụ kết nối người học và người dạy, đó là khi một yêu cầu kết nối thực sự được gửi tới phía bên kia. Với dịch vụ tuyển dụng, đó là khi một hồ sơ ứng tuyển được tiếp nhận. Điểm chung là kết quả để lại dấu vết, chứ không phải việc xem một màn hình. Nếu đã có bản ghi được tạo ra hoặc có thứ gì đó được gửi đi, người đó đã dùng sản phẩm chứ không chỉ ngó qua.

Sự kiện thứ ba là hành động đó lặp lại. Sai lầm thường gặp ở đây là tạo riêng một sự kiện cho lượt quay lại. Đặt hai tên cho cùng một hành động sẽ làm định nghĩa tách đôi và tổng số không khớp. Hãy nhận lại chính sự kiện thứ hai, còn việc có phải cùng một người hay không thì để định danh xử lý. Khái niệm lặp lại sinh ra từ việc tổng hợp theo người, không phải từ tên sự kiện. Nói cách khác, sự kiện thứ ba gần với một câu hỏi mới hơn là một sự kiện mới.

Bỏ cái gì cũng quan trọng như thêm cái gì. Lượt chạm nút, lượt xem màn hình, độ sâu cuộn, lượt hiển thị banner, thao tác bật tắt đều nên nằm ngoài danh sách ban đầu. Chúng có thể được thêm sau, khi xuất hiện một câu hỏi cụ thể cần đến chúng. Đưa vào từ đầu sẽ làm quy tắc đặt tên lung lay, số điểm cần kiểm tra tăng lên, và mỗi lần phát hành lại phát sinh chi phí rà soát. Danh sách càng dài thì xác suất cả danh sách bị bỏ mặc càng cao.

Rút gọn còn ba không phải là việc kỹ thuật mà là việc thống nhất. Khi định nghĩa kích hoạt được viết thành một câu và bộ phận sản phẩm, lập trình, marketing cùng đồng ý với câu đó, một nửa công việc đo lường đã xong. Không có câu đó, mọi người sẽ nhìn cùng một bảng số mà kể hai câu chuyện khác nhau. Khi viết định nghĩa, hãy viết luôn cả điều kiện: yêu cầu bị hủy có tính không, tài khoản thử nghiệm có loại trừ không, lần thử thất bại xử lý ra sao. Có đủ những dòng đó thì câu định nghĩa mới hoàn chỉnh.

Vì sao cần định danh người dùng và xử lý thế nào

Không có định danh, ba sự kiện là ba người hay một người thì không phân biệt được. Lặp lại theo định nghĩa đòi hỏi cùng một chủ thể, nên thiếu định danh thì không tính được lượt quay lại lẫn mức giữ chân. Nhưng định danh chạm trực tiếp vào dữ liệu cá nhân. Phải xử lý trên nền tảng có sự đồng ý và thu thập tối thiểu, và yêu cầu pháp lý khác nhau theo từng khu vực.

Trong thực tế, định danh chia thành hai lớp. Một là định danh ẩn danh do công cụ tự cấp khi ứng dụng được cài. Nó gắn với lượt cài chứ không gắn với con người, nên gỡ ứng dụng rồi cài lại sẽ ra giá trị khác. Hai là định danh gắn với tài khoản đã đăng nhập, đi theo người dùng kể cả khi đổi thiết bị. Lý do dùng cả hai lớp là để nối hành vi trước đăng nhập với hành vi sau đăng nhập thành một dòng liên tục. Nếu không xử lý việc liên kết hai giá trị tại thời điểm đăng nhập, phần ghi nhận trước khi đăng ký sẽ nằm tách rời khỏi phần sau đó.

Trọng tâm của mục này là dùng cái gì làm định danh tài khoản. Không dùng trực tiếp địa chỉ email, số điện thoại, họ tên, mã nhân viên hay các số mang tính định danh công dân. Hãy tạo riêng một giá trị vô nghĩa chỉ có ý nghĩa trong hệ thống nội bộ. Lý do rất đơn giản: hệ thống analytics được nhiều người mở ra xem, được xuất sang công cụ khác, và đôi khi được nối vào bảng điều khiển bên ngoài. Một giá trị đã vào đó rất khó thu hồi hết. Nguyên tắc tương tự áp dụng cho tham số sự kiện. Đừng đưa từ khóa tìm kiếm, nội dung ghi chú, địa chỉ, thông tin liên hệ hay bất cứ giá trị nào có thể xác định một người vào tham số. Thói quen gửi nguyên văn ô nhập liệu tự do là con đường phổ biến nhất dẫn tới sự cố.

Sự đồng ý là điều kiện khởi động của việc đo lường. Trước khi có đồng ý thì không kích hoạt sự kiện, và cũng không nên tích trữ lại để gửi sau. Câu chữ trên màn hình xin đồng ý cần viết bằng ngôn ngữ người thường đọc được, nói rõ thu thập cái gì và cho mục đích gì. Trong ứng dụng cũng cần có đường để rút lại đồng ý. Khi rút lại thì cái gì dừng và cái gì còn lưu phải được quyết định từ trước. Ứng dụng không xây sẵn luồng rút lại sẽ không có công cụ nào để phản ứng khi vấn đề xảy ra.

Thu thập tối thiểu vừa là nguyên tắc vừa là tuyến phòng thủ. Thuộc tính nào không có mục đích rõ ràng thì không gắn. Vị trí chính xác, danh bạ liên hệ, định danh quảng cáo của thiết bị chỉ nên đụng tới khi câu hỏi cần trả lời đã rõ ràng. Thời hạn lưu trữ cũng cần được ấn định. Lưu vô thời hạn là trạng thái hoãn quyết định, không phải chính sách. Khi có yêu cầu xóa tài khoản, bạn phải tìm được định danh phía analytics, nên hãy quyết định trước bảng ánh xạ giữa tài khoản nội bộ và định danh phân tích nằm ở đâu và ở dạng nào. Bắt đầu đi tìm sau khi nhận yêu cầu là đã muộn.

Yêu cầu pháp lý khác nhau theo khu vực. Hàn Quốc, Việt Nam, châu Âu và các nơi khác không giống nhau về cách lấy đồng ý, hạng mục phải thông báo và thủ tục chuyển dữ liệu ra nước ngoài. Chính sách của các cửa hàng ứng dụng cũng đặt ra yêu cầu riêng, tách biệt với luật. Ứng dụng hướng tới trẻ em hoặc xử lý các nhóm dữ liệu nhạy cảm như sức khỏe, tài chính còn có thêm điều kiện. Bài viết này chỉ bàn nguyên tắc thiết kế và không khẳng định điều khoản cụ thể nào. Trước khi áp dụng thật, nên kiểm tra yêu cầu của khu vực phục vụ và chính sách cửa hàng, và rà soát pháp lý khi cần.

Quy ước tối thiểu để chặn trùng lặp và thất thoát

Bốn dòng là đủ để bắt đầu. Đặt tên theo một cách duy nhất, chốt thời điểm kích hoạt bằng một câu, chặn việc gửi hai lần khi thử lại hoặc quay lại màn hình, và xử lý để không mất dữ liệu khi mạng đứt. Viết bốn dòng đó thành một bảng một trang và đặt cùng chỗ với mã nguồn.

Quy tắc đặt tên trông vặt vãnh nhưng tồn tại lâu nhất. Hãy chọn một quy tắc, chẳng hạn chỉ dùng chữ thường và gạch dưới, cố định thứ tự đối tượng rồi tới hành động, và không tạo ngoại lệ. Mỗi công cụ có tên dành riêng, giới hạn độ dài và giới hạn số tham số khác nhau, nên hãy tra tài liệu của công cụ đó trước khi bắt đầu và đặt tên trong phạm vi đã tra. Đặt theo trí nhớ rồi sau này đổi tên sẽ làm dữ liệu trước và sau thời điểm đổi tách làm hai mảnh.

Sự cố nhiều nhất phát sinh ở thời điểm kích hoạt, khi hai sự việc khác nhau bị trộn dưới cùng một cái tên. Nếu không chốt là gửi lúc người dùng chạm nút hay lúc máy chủ trả về thành công, những lần thử thất bại cũng bị đếm như thành công. Với hành động để lại kết quả, lấy mốc phản hồi thành công sẽ dễ diễn giải hơn. Nếu muốn nhìn cả số lần thử thì đó là một câu hỏi khác, và có thể gắn thành sự kiện riêng sau này. Viết định nghĩa thành câu để vài tháng sau người sửa mã không phải phán đoán lại từ đầu.

Trùng lặp tăng lên trong im lặng. Các đường phổ biến là quay lại màn hình, nhấn nút lùi, trở lại từ chế độ nền, thử lại sau khi mạng lỗi, và người dùng chạm hai lần thật nhanh. Cách xử lý khá đơn giản: tạo một khóa duy nhất cho mỗi sự việc và chỉ gửi một lần với khóa đó. Khi khó chặn ở phía ứng dụng, có thể thu thập trước rồi loại bỏ khóa trùng ở bước tổng hợp. Dù chọn cách nào, cả đội cần biết điểm chặn trùng nằm ở đâu.

Thất thoát là vấn đề theo hướng ngược lại, khi sự kiện phát sinh lúc ứng dụng bị đóng đột ngột hoặc lúc mất mạng rồi biến mất. Nhiều công cụ giữ tạm dữ liệu ở máy rồi gửi lại sau. Tuy nhiên cách hoạt động và điều kiện lưu tạm khác nhau giữa các công cụ, nên hãy kiểm tra thực tế và đặt kỳ vọng trong phạm vi đó. Việc bảng số cập nhật chậm do gửi theo lô không phải là lỗi. Không nắm khác biệt này thì đội ngũ sẽ tốn thời gian truy tìm một lỗi không tồn tại.

Kiểm tra bằng mắt phải đi trước tự động hóa. Trước khi phát hành, hãy kích hoạt lần lượt ba sự kiện trên thiết bị thật và xem chúng có vào màn hình kiểm tra thời gian thực của công cụ hay không. Mã đo lường hỏng cũng không làm ứng dụng dừng lại, nên nhiều tháng có thể trôi qua mà không ai hay. Hãy để một từ điển sự kiện một trang gồm tên, thời điểm kích hoạt, tham số, người phụ trách và phiên bản ứng dụng ngay trong kho mã, và sửa nó cùng lúc mỗi khi thay đổi sự kiện. Tài liệu càng xa mã nguồn thì càng nhanh cũ.

Cần vững cái gì trước khi mở rộng

Điều kiện để mở rộng là trạng thái chứ không phải thời gian. Khi ba sự kiện chảy về đều đặn trong vài tuần, cả đội đọc con số đó theo cùng một nghĩa, và chúng vẫn kích hoạt đúng sau khi cập nhật ứng dụng, lúc đó hãy mở rộng. Mở rộng sớm hơn chỉ làm nhiễu tăng lên và rồi không ai mở bảng số nữa.

Điều kiện thứ nhất là độ ổn định. Đo lường hỏng trong im lặng. Đổi cấu trúc màn hình, nâng phiên bản thư viện hay sửa một câu điều kiện đều có thể làm sự kiện biến mất trong khi ứng dụng vẫn trông bình thường. Hãy thêm một dòng vào danh mục kiểm tra phát hành để xác nhận ba sự kiện còn sống sau mỗi bản. Khi biểu đồ theo tuần đột ngột có đoạn gần bằng không, nguyên nhân thường là đo lường bị đứt chứ không phải hành vi người dùng thay đổi.

Điều kiện thứ hai là sự thống nhất trong diễn giải. Viết định nghĩa kích hoạt thành câu và dán ở nơi cả đội cùng nhìn. Nếu buộc phải đổi định nghĩa, hãy ghi ngày đổi và không so sánh trực tiếp số liệu hai bên mốc đó. Nhìn hai đoạn có định nghĩa khác nhau như một đường xu hướng duy nhất sẽ khiến bạn thấy một thay đổi không hề tồn tại. Cố định ý nghĩa của con số quan trọng hơn việc tăng số lượng con số.

Điều kiện thứ ba là sự tồn tại của câu hỏi. Khi thêm sự kiện mới, hãy viết kèm câu hỏi mà nó dùng để trả lời và hành động sẽ thay đổi theo câu trả lời. Không viết được hai dòng đó thì sự kiện đó chưa cần thiết. Sau khi đủ điều kiện, những thứ đáng thêm gồm phân biệt nguồn vào, thời điểm thanh toán hoặc chuyển đổi, các bước có nhiều người rời bỏ, và thử nghiệm so sánh. Mỗi thứ kéo theo một loại chi phí khác nhau: nguồn vào cần kết nối với công cụ quảng cáo, thanh toán cần thiết kế cả trường hợp thất bại và hoàn tiền, còn thử nghiệm tiêu tốn thời gian phân tích một cách liên tục.

Yeowubie Interaction vừa phát triển cho khách hàng vừa vận hành sản phẩm của mình. Dịch vụ quản lý điểm danh onSpots, dịch vụ kết nối và bản đồ hóa giữa người học và người dạy tiếng Hàn là Langtori, và dịch vụ tuyển dụng tại Việt Nam Job Connect VN có định nghĩa kích hoạt khác nhau. Cùng một công ty làm ra, nhưng hành động cốt lõi khác thì nội dung của ba sự kiện cũng khác. Lý do bài viết này không đưa số liệu đo lường của sản phẩm nội bộ cũng nằm ở đó. Chúng tôi chưa có con số đủ chỉnh chu để công bố, và không tạo ra con số không có thật.

Tóm lại, thứ tự là như sau. Định nghĩa kích hoạt bằng một câu, gắn ba sự kiện, nối định danh ẩn danh với định danh tài khoản, loại bỏ thông tin định danh cá nhân khỏi tham số, viết quy ước chặn trùng lặp và thất thoát thành một trang, và kiểm tra ở mỗi lần phát hành. Khi sáu việc này đứng vững, phần mở rộng sau đó không khó. Các đội thất bại khi gắn đo lường lần đầu thường không phải vì thiết kế thiếu, mà vì đã bắt đầu quá lớn.