Lên store thôi chưa đủ: danh sách kiểm tra ASO

Hoạt động tìm kiếm trên store diễn ra như nào ?

Tìm kiếm trên store có cấu trúc khác với tìm kiếm web. Phần chữ được lập chỉ mục chỉ giới hạn trong vài trường do store quy định, và thứ hạng không chỉ dựa vào mức độ trùng khớp từ ngữ mà còn dựa vào việc người vào từ truy vấn đó có thực sự cài đặt và ở lại hay không. App Store và Google Play xử lý hai trục này theo phạm vi khác nhau.

Tách riêng hai trục sẽ dễ hiểu hơn. Trục thứ nhất là mức độ liên quan: từ khóa mà người dùng gõ trùng bao nhiêu với từ khóa nằm trong thông tin niêm yết. Trục thứ hai là hiệu quả: sau khi xuất hiện trong kết quả tìm kiếm, người ta có mở trang chi tiết không, mở rồi có cài không, cài rồi có gỡ không. Nếu chỉ chăm chút trục thứ nhất thì lượt hiển thị tăng mà lượt cài đặt không tăng theo; nếu chỉ lo trục thứ hai thì ngay từ đầu ứng dụng đã không xuất hiện trong kết quả.

Trên App Store, phần chữ được đọc cho tìm kiếm khá hẹp. Trọng tâm là tên ứng dụng, phụ đề, và ô từ khóa mà người dùng không nhìn thấy. Tên nhà phát triển và tên các gói mua trong ứng dụng cũng được cho là có ảnh hưởng. Ngược lại, phần mô tả trên trang chi tiết từ lâu được giới làm ASO hiểu là không nằm trong chỉ mục tìm kiếm. Vì Apple không công bố toàn bộ quy tắc lập chỉ mục nên sẽ không viết điều này như một sự thật đã xác nhận. Chỉ có điều bản thân việc Apple tách riêng một ô từ khóa ẩn đã là một gợi ý. Tiêu chuẩn mới nhất, bạn nên kiểm tra trực tiếp trong tài liệu trợ giúp của App Store Connect.

Google Play không có ô từ khóa riêng. Thay vào đó, tiêu đề ứng dụng, mô tả ngắn và mô tả đầy đủ đều được đọc cho mục tìm kiếm. Vì vậy cùng một nội dung nhưng tính chất bài viết sẽ khác. Việc trên App Store sắp xếp một danh sách mà nhét các từ khác nhau vào số ký tự giới hạn. Việc trên Google Play khi viết cần câu chữ phải tự nhiên với người đọc mà vẫn chứa các truy vấn thật. Sao chép nguyên một đoạn cho cả hai store thì cả hai bên đều thiệt và không phù hợp.

Ở trục hiệu quả có một vấn đề rất hay gặp: gộp truy vấn thương hiệu với truy vấn chung. Người đã biết chính xác tên ứng dụng và gõ đúng tên đó thì tỷ lệ chuyển đổi đương nhiên cao. Con số này trộn vào mức trung bình sẽ khiến hiệu quả ở các truy vấn chung trông đẹp hơn thực tế. Phải tách hai loại ra mới đánh giá được việc chỉnh sửa thông tin niêm yết có tác dụng hay không.

Đường kiểm chứng khác nhau giữa hai store. Google Play Console cung cấp báo cáo cho biết người dùng đã vào bằng những truy vấn nào. Đây là chỗ nên mở đầu tiên. App Store Connect không cung cấp dữ liệu truy vấn theo cách tương tự. Bù lại, công cụ từ khóa của Apple Search Ads cho thấy mức độ phổ biến ước lượng của từng truy vấn, và cách kiểm tra thủ công là tự tìm ứng dụng của mình trên thiết bị thật để xem nó đứng thứ mấy vẫn còn hiệu lực. Khi làm việc này phải đặt đúng quốc gia storefront và ngôn ngữ thiết bị theo thị trường mục tiêu. Thứ hạng nhìn thấy trên App Store của tài khoản Hàn Quốc khác với màn hình mà người dùng Việt Nam nhìn thấy.

Khi sắp thứ tự công việc, hãy xem lượt cài thực tế của ứng dụng đến từ nền tảng nào trước đã. Phân bố của chính ứng dụng bạn quan trọng hơn thống kê thị phần của toàn thị trường. Nếu tỷ lệ iOS và Android lệch hẳn về một phía thì tập trung đào sâu quy tắc của store đó trước là hợp lý.

Tên, phụ đề và ô từ khóa: đặt gì vào đâu

Chỗ để đặt chữ khác nhau giữa hai store. App Store chia thành tên ứng dụng, phụ đề, và ô từ khóa mà người dùng không thấy. Google Play thì tiêu đề, mô tả ngắn và mô tả đầy đủ đều được đọc cho tìm kiếm. Mỗi chỗ có vai trò riêng, nên nhét cùng một từ vào mọi ô là lãng phí chỗ.

Giới hạn ký tự do store điều chỉnh. Mức được dùng lâu nay là App Store 30 ký tự cho tên, 30 cho phụ đề, 100 cho ô từ khóa; Google Play 30 ký tự cho tiêu đề, 80 cho mô tả ngắn, 4.000 cho mô tả đầy đủ. Tuy vậy đừng viết theo trí nhớ: hãy kiểm tra bằng bộ đếm ký tự ngay trên ô nhập của App Store Connect và Play Console. Ô nhập luôn là chuẩn mới nhất.

Tên ứng dụng là chỗ chứa cả thương hiệu lẫn từ chỉ hạng mục. Chỉ để thương hiệu thì chỉ người đã biết tên mới tìm ra. Ngược lại, nếu nối một chuỗi từ hạng mục quá dài thì tên bị cắt và không đọc được trong danh sách kết quả. Tiêu chí là từ ngữ mà người ta thật sự gõ. Với một ứng dụng chấm công, đó không phải tên gọi chính thức dùng trong nội bộ mà là từ người quản lý sẽ gõ vào ô tìm kiếm. Với một ứng dụng tuyển dụng, đó không phải thuật ngữ chỉ nghề nghiệp mà là từ ngữ người đi tìm việc gõ ra.

Phụ đề là chỗ chứa những từ chưa đưa được vào tên. Lặp lại từ đã có trong tên là lãng phí. Thay vì liệt kê tính năng, viết sao cho đọc một dòng là hiểu ai dùng ứng dụng này để làm gì sẽ có lợi hơn cho chuyển đổi. Phụ đề vừa được đọc cho tìm kiếm vừa hiện ra trước mắt người dùng, nên đáng để dành thời gian cân bằng hai vai trò đó.

Ô từ khóa có quy tắc khá rõ. Chỉ ngăn cách bằng dấu phẩy và không thêm dấu cách, vì dấu cách cũng tính vào số ký tự. Không lặp lại những từ đã có trong tên và phụ đề. Apple tự ghép các từ trong ô thành cụm nên cũng không cần nhét nguyên cả cụm. Đưa cả dạng số ít và số nhiều vào cạnh nhau thường là thừa. Nhét tên thương hiệu của đối thủ là cách làm dễ dẫn tới vấn đề nhãn hiệu, không nên.

Mô tả đầy đủ của Google Play phải là văn bản cho người đọc. Cố nhồi đi nhồi lại một từ bị xem là vi phạm chính sách và cũng không giúp gì cho thứ hạng. Hai ba câu đầu hiển thị cùng mô tả ngắn ở trạng thái thu gọn, nên điều quan trọng nhất phải nằm ở đó. Phần còn lại diễn giải tính năng và tình huống sử dụng bằng câu văn, đồng thời đưa vào một cách tự nhiên những cách nói mà người dùng thật sự dùng.

Ngôn ngữ niêm yết là một đơn vị công việc riêng. Mỗi storefront có bộ trường riêng, bỏ trống một ngôn ngữ nghĩa là ở thị trường đó bạn tự cắt bớt phần chữ được lập chỉ mục. Chỉ nhìn vào các sản phẩm mà Yeowubie Interaction đang vận hành cũng thấy tình huống khác nhau. Langtori hỗ trợ tiếng Hàn, tiếng Việt và tiếng Anh, trong đó tiếng Việt là ngôn ngữ chủ lực, nên bản niêm yết tiếng Việt mới là mặt trận chính. Job Connect VN chỉ phục vụ thị trường Việt Nam nên quyết định về ngôn ngữ khá đơn giản. onSpots hỗ trợ đa ngôn ngữ và không giới hạn ở một quốc gia, nên cách gọi tên công việc thay đổi theo từng thị trường. Phủ toàn bộ storefront bằng một bản tiếng Anh duy nhất sẽ khiến những từ mà người dùng bản địa thật sự gõ rơi ra khỏi chỉ mục.

Xin thêm một lưu ý cuối. Số ký tự và cấu trúc trường viết trong mục này thay đổi theo chính sách của store. Trước khi sửa lớn phần niêm yết, mở App Store Connect và Play Console xem màn hình hiện tại cùng tài liệu chính thức một lượt sẽ an toàn hơn.

Ba hình ảnh đầu tiên về ứng dụng quyết định lượt cài

Trên màn hình kết quả tìm kiếm, thứ người ta nhìn thấy là biểu tượng, tên, và vài ảnh chụp màn hình đầu tiên. Ngay cả khi đã vào trang chi tiết, phạm vi nhìn thấy trước khi cuộn cũng chỉ dừng quanh ba ảnh đầu. Nếu ở đó chưa nắm được đây là ứng dụng gì thì những ảnh còn lại sẽ không được mở ra.

Trong kết quả tìm kiếm của App Store, dạng hiển thị ba ảnh dọc hoặc một ảnh ngang đã được duy trì từ lâu. Nếu bạn tải lên ảnh dọc thì ảnh số 1 đến số 3 gần như là tài sản dành riêng cho kết quả tìm kiếm. Google Play thiên về hiển thị biểu tượng và tiêu đề ở kết quả tìm kiếm, còn ảnh chụp màn hình có trọng lượng lớn hơn ở trang chi tiết. Tuy nhiên dạng hiển thị này bị store thử nghiệm và thay đổi khá thường xuyên. Việc mở thiết bị thật ra xem hiện tại nó hiển thị thế nào chính xác hơn mọi mô tả trong tài liệu.

Ảnh đầu tiên phải mang một dòng lợi ích lớn nhất. Không phải tên tính năng mà là kết quả người dùng nhận được. Với ứng dụng chấm công, điều cần nói trước không phải cách ghi nhận dữ liệu mà là việc mỗi tháng người quản lý sẽ bớt phải làm gì. Ảnh thứ hai đặt một màn hình cốt lõi cho thấy điều vừa nói được hiện thực hóa thật. Ảnh thứ ba nên hóa giải trước những điều khiến người ta ngần ngại cài đặt ứng dụng: mất bao lâu để thiết lập, có dùng được khi không có mạng không, đây là ứng dụng dùng một mình hay cả nhóm cùng dùng.

Chữ đặt trên ảnh phải ngắn. Vì phải đọc được ở kích thước bị thu nhỏ trong kết quả tìm kiếm nên khoảng năm đến bảy từ là giới hạn trên. Nhồi phần giải thích bằng chữ nhỏ thì khi thu nhỏ chỉ còn là một vệt xám. Màn hình trong ảnh phải là màn hình thật của ứng dụng. Vẽ thêm tính năng chưa có thì có thể bị nhắc trong khâu duyệt, mà kể cả qua được thì ngay sau khi cài người dùng sẽ phản bác đúng điểm đó trong phần đánh giá.

Ảnh chụp màn hình theo từng ngôn ngữ phải chuẩn bị riêng. Nếu storefront Việt Nam đang treo ảnh giao diện tiếng Anh thì dù ứng dụng có hỗ trợ tiếng Việt, người dùng vẫn kết luận là không hỗ trợ. Định dạng số, định dạng ngày tháng và cách ghi tiền tệ bên trong ảnh nếu đúng chuẩn bản địa thì mức độ tin cậy khác hẳn. Ảnh chỉ dán chữ dịch lên và ảnh chụp thật trong ngôn ngữ đó nhìn ra được sự khác biệt.

Nếu định gắn video xem trước, hãy kiểm tra cách phát của từng store trước đã. App preview trên iOS nhiều trường hợp tự phát mà không có tiếng, nên ba giây đầu phải hiểu được trong trạng thái tắt tiếng. Video quảng bá của Google Play gắn ở vị trí khác và cách phát cũng khác. Nếu chưa chuẩn bị được video thì không làm cũng không sao. Một video làm dở còn tệ hơn là không có.

Cách kiểm tra thì đơn giản. Cầm thiết bị thật, vào storefront của thị trường mục tiêu và tìm ứng dụng của mình bằng nhiều truy vấn khác nhau. Phải xem trên thiết bị cầm tay chứ không phải trình giả lập hay bản xem trước trên web. Và hãy đặt nó cạnh những ứng dụng khác cùng xuất hiện trong kết quả đó. Ảnh chụp màn hình trông ổn khi phóng to riêng một mình rất hay trở nên không phân biệt được khi nằm trong danh sách cạnh đối thủ.

Cách xử lý đánh giá và xếp hạng một cách trung thực

Xin vạch ranh giới trước. Mua đánh giá, treo thưởng đổi lấy số sao, hoặc lọc trước những người có khả năng chấm điểm thấp để không đưa họ ra store, đều là hành vi bị cấm ở cả App Store lẫn Google Play. Bị phát hiện thì đánh giá bị gỡ, mức hiển thị bị hạn chế, và nếu lặp lại thì tài khoản nhà phát triển bị đình chỉ.

Giữ ranh giới này không chỉ là chuyện đạo đức. Nó cũng không có tác dụng thật. Điểm số bị thao túng có thể đẩy được lượt cài nhưng không tạo ra được hành vi sau khi cài. Tín hiệu hiệu quả của store không dừng ở lượt cài mà nhìn tiếp phía sau đó. Thêm nữa, khi lời khen trong đánh giá lệch với trải nghiệm thật thì người đọc trang chi tiết càng kỹ càng dễ rời đi. Mua đánh giá thì được một con số nhất thời và mất đi tài khoản cùng niềm tin.

Cách được phép thì chính store cung cấp. iOS có API hiển thị lời mời đánh giá do hệ thống bật lên, Android có In-App Review API. Cả hai trường hợp, store kiểm soát việc có hiện hay không và hiện bao nhiêu lần, nhà phát triển không ép được. Ràng buộc này nghe có vẻ bí bách nhưng dùng đúng như vậy mới là chuẩn. Tự dựng giao diện riêng mô phỏng hộp chấm sao bị xem là vi phạm nguyên tắc.

Thời điểm hỏi là thứ cần thiết kế. Ngay sau khi người dùng hoàn tất được một việc là chỗ tốt. Khi đã ghi đủ chấm công một tháng, khi đã kết nối được với người mình cần, khi lần đầu đạt được kết quả mong muốn. Ngược lại, ngay sau màn hình lỗi, ngay sau một lần thanh toán thất bại, hay ngay sau lần mở ứng dụng đầu tiên là tệ nhất. Do vậy, đòi hỏi một người dùng mới để đưa ra đánh giá.

Phải mở một lối riêng cho người dùng đang bất mãn. Đặt trong ứng dụng một nút liên hệ luôn mở và xử lý vấn đề ở đó trước. Điều này khác với review gate. Review gate là bộ lọc hỏi số sao trước rồi chỉ đẩy người sẽ chấm cao ra store; còn nút liên hệ là cửa mở cho tất cả mọi người, không liên quan đến số sao. Cái trước bị cấm, cái sau là thiết kế sản phẩm bình thường.

Với đánh giá đã nhận thì hãy trả lời. Đặc biệt là điểm 1 và điểm 2, nên trả lời không sót cái nào. Trình tự là xác nhận sự việc, lịch sự xin thông tin cần để tái hiện lỗi, và sau khi sửa thật thì quay lại cập nhật câu trả lời. Google Play gửi thông báo cho người viết khi nhà phát triển phản hồi. Có những người biết vấn đề đã được xử lý rồi tự nâng điểm, và đó mới là con đường bình thường. Câu trả lời cũng là một dạng tài liệu công khai: người khác đọc trang chi tiết về sau sẽ thấy đoạn đối thoại đó.

Cấu trúc xếp hạng của hai store cũng khác. Apple cho phép chọn đặt lại điểm đánh giá khi phát hành phiên bản mới. Đây là quân bài chỉ nên dùng khi đã sửa sản phẩm ở mức lớn, vì các đánh giá đã tích lũy cũng biến mất cùng lúc. Google Play được biết là đặt trọng số cao hơn cho các đánh giá gần đây, nên một giai đoạn tệ sẽ loãng dần theo thời gian. Có điều tiền đề của việc đó là các phiên bản sau thật sự tốt lên. Dù theo hướng nào, quy tắc chính xác ở thời điểm hiện tại nên tra trong tài liệu chính thức của từng store.

Cuối cùng, hãy dùng đánh giá làm đầu vào cho sản phẩm. Mỗi quý rút ra ba phàn nàn lặp lại nhiều nhất trong đánh giá và đưa lên đầu backlog, chỉ một thói quen đó thôi cũng đủ để điểm số dịch chuyển dần. Cách này chậm nhưng là loại cải thiện không bị đảo ngược.

Đo lường và lặp lại: đổi gì và chờ gì

ASO không phải việc thiết lập một lần rồi xong mà là vòng lặp đổi, chờ, và đọc. Mỗi lần chỉ đổi một yếu tố rồi so sánh các chỉ số store cung cấp trước và sau thay đổi. Bốn chỉ số nền tảng là lượt hiển thị trong kết quả tìm kiếm, lượt xem trang chi tiết, lượt cài, và tỷ lệ chuyển đổi giữa các bước đó.

App Store Connect cho xem lượt hiển thị, lượt xem trang chi tiết, số lượt tải và tỷ lệ chuyển đổi, tách theo loại nguồn. Vào từ tìm kiếm trong store, vào từ duyệt trong store, vào từ liên kết web, và vào từ một ứng dụng khác là những thứ có tính chất hoàn toàn khác nhau. Gộp chung lại thì tác dụng của việc sửa niêm yết bị chôn dưới tác dụng của chiến dịch quảng cáo. Ít nhất hãy tách riêng phần vào từ tìm kiếm để nhìn.

Trên Play Console thì xem báo cáo thu nạp người dùng, số người truy cập trang niêm yết, và báo cáo truy vấn tìm kiếm. Google đã cung cấp dữ liệu truy vấn thì không xem báo cáo đó đúng là tự thiệt. Nếu người dùng đang vào bằng những truy vấn ngoài dự đoán thì có chỗ để đưa cách nói đó vào mô tả ngắn và mô tả đầy đủ một cách tự nhiên.

Chức năng thử nghiệm A/B cũng có sẵn trong store. iOS có tối ưu trang sản phẩm, Android có thử nghiệm thông tin niêm yết. Nhưng có một điều kiện tiên quyết: lưu lượng phải đủ thì kết quả mới có ý nghĩa. Chạy vài ngày trong tình trạng ít lượt truy cập rồi chọn bên thắng thì chẳng khác gì chọn nhiễu. Nếu lưu lượng thấp, đừng chia nhỏ thử nghiệm mà hãy áp dụng nguyên một thay đổi lớn rồi so sánh trước sau trong khoảng thời gian đủ dài.

Nhịp thay đổi của hai store cũng khác. Tên, phụ đề và ô từ khóa của App Store gắn với luồng nộp phiên bản mới nên không thể sửa bất cứ lúc nào. Thông tin niêm yết của Google Play thì sửa tương đối tự do, bù lại có khâu xem xét. Vì khác biệt này, trong thực tế nhiều khi tiện hơn nếu thử nghiệm câu chữ trên Play trước, rút ra kết luận, rồi đưa kết luận đó vào lần nộp phiên bản iOS kế tiếp.

Phải tính cả thời gian chờ vào kế hoạch. Một thay đổi trong thông tin niêm yết thường mất vài ngày để vào chỉ mục, và thêm một đến hai tuần nữa để thứ hạng ổn định ở trạng thái mới. Nhìn ba ngày rồi hoàn tác thì không học được gì. Ngược lại, ảnh chụp màn hình và biểu tượng phản ứng khá nhanh trên tỷ lệ chuyển đổi nên có thể kết luận sớm hơn một chút. Hãy phân biệt cái chậm và cái nhanh rồi đặt mốc kỳ vọng khác nhau cho từng loại.

Cũng nên ghi lại những yếu tố gây nhiễu. Lễ tết và kỳ nghỉ, đầu năm học, các đợt chạy quảng cáo bên ngoài, xuất hiện trên báo chí, một bản cập nhật lớn của đối thủ, tất cả đều làm rung con số. Nếu không ghi lại các sự kiện này thì vài tuần sau chỉ nhìn vào đồ thị bạn sẽ rút ra kết luận sai.

Công cụ rẻ nhất và hay bị bỏ quên nhất là nhật ký thay đổi. Mỗi dòng ghi ngày, store, trường đã sửa, giá trị trước, giá trị sau, kỳ vọng điều gì, sẽ nhìn bằng chỉ số nào, và khi nào thì kết luận. Một bảng tính là đủ. Không có bản ghi này thì không có sự lặp lại, mà không có lặp lại thì ASO chỉ là phỏng đoán.

Yeowubie Interaction cũng làm việc này theo thứ tự khác nhau cho từng sản phẩm. onSpots được dùng ở nhiều quốc gia nên phải tách ra xem theo từng ngôn ngữ. Job Connect VN chỉ có một thị trường nên quyết định đơn giản hơn, đổi lại khác biệt trong cách diễn đạt ngay trong thị trường đó lại quan trọng. Langtori có hai nhóm người dùng là người học và người dạy, hai nhóm này tìm bằng những từ khác nhau nên phần niêm yết phải cân bằng cả hai phía. Trong mọi trường hợp, bê nguyên một công thức đã hiệu quả với ứng dụng khác về dùng thì sẽ không khớp. Chỉ giữ lại những gì đã tự kiểm chứng trên storefront của chính ứng dụng mình.