App Store từ chối metadata: cách khắc phục 2.3.x, 2.3.7, 4.3 và 5.2.1
Bạn vừa nhận được email. Trạng thái chuyển thành Metadata Rejected, và ghi chú trong Resolution Center trích dẫn một số hướng dẫn mà bạn phải tra cứu lại. Tin tốt là bị từ chối vì metadata thuộc loại dễ xử lý hơn: bạn không cần tải lại bản build, chỉ cần chỉnh sửa bản ghi phiên bản rồi gửi lại.
Điều đầu tiên cần kiểm tra là số hướng dẫn trong tin nhắn Resolution Center, vì nó cho bạn biết chính xác cần sửa trường nào. Bài viết này đề cập đến bốn lỗi bạn có khả năng gặp nhất khi bị từ chối vì phần niêm yết. Số hướng dẫn có thể thay đổi theo thời gian, nên nội dung ở đây phản ánh App Store Review Guidelines hiện hành.
Trước tiên, cơ chế: "Metadata Rejected" thực sự nghĩa là gì
Trạng thái Metadata Rejected chỉ vào phần niêm yết trên store — tên ứng dụng, phụ đề, từ khóa, mô tả, ảnh chụp màn hình, video xem trước, URL — chứ không phải bản ứng dụng đã biên dịch. Vì cờ đánh dấu nằm ở metadata, bạn không cần bản build mới. Bạn chỉnh sửa trường bị nêu trong App Store Connect, giữ nguyên bản build hiện có gắn với phiên bản, rồi gửi lại.
Có hai lưu ý cần nói rõ. Thứ nhất, gửi lại vẫn đưa bạn quay lại hàng đợi kiểm duyệt, nên không cần build mới không có nghĩa là không cần kiểm duyệt lại — con người hoặc hệ thống tự động vẫn sẽ xem xét lần nữa. Thứ hai, sửa đúng một trường mà Apple nêu ra không giúp phần còn lại của bài niêm yết được miễn dịch. Người kiểm duyệt có thể đánh dấu một hướng dẫn khác ở lượt sau. Hãy dọn dẹp toàn bộ bài niêm yết trong khi đang chỉnh sửa, chứ không chỉ riêng câu đã bị trích dẫn lại.
Hướng dẫn 2.3.3 — ảnh chụp màn hình phải cho thấy ứng dụng đang được sử dụng
Điều gì kích hoạt lỗi này. Ảnh chụp màn hình của bạn không thể hiện ứng dụng đang thực hiện chức năng của nó. Trường hợp kinh điển là ô đầu tiên chỉ là màn hình splash, trang đăng nhập, hoặc hình ảnh tiêu đề kèm khẩu hiệu mà không có giao diện thật nào. Lỗi này cũng xảy ra khi ảnh chụp màn hình thể hiện một tính năng mà ứng dụng không có, hoặc tham chiếu đến thiết bị/giao diện của nền tảng khác.
Trước: ô đầu tiên là logo của bạn nằm giữa nền gradient với dòng chữ "cách thông minh nhất để lên kế hoạch cho tuần của bạn," không có bất kỳ giao diện ứng dụng nào.
Sau: ô đầu tiên là một màn hình thật từ luồng chức năng cốt lõi — một chế độ xem theo tuần với các mục nhập thực tế — kèm chú thích ngắn nêu lợi ích phía trên khung thiết bị. Người kiểm duyệt (và người dùng) có thể thấy ứng dụng làm gì chỉ từ ảnh thu nhỏ. Vẫn giữ chú thích marketing và khung thiết bị, nhưng đảm bảo giao diện ứng dụng bên dưới là thật và cập nhật.
Đây là thay đổi thuộc về metadata: thay ảnh trong bản ghi phiên bản, gửi lại, không cần build mới.
Hướng dẫn 2.3.7 — từ khóa phải mô tả ứng dụng của bạn, không phải để lách tìm kiếm game
Điều gì kích hoạt lỗi này. Đây là hướng dẫn về lạm dụng từ khóa. Lỗi xảy ra khi metadata của bạn bị nhồi nhét các từ không mô tả ứng dụng: nhãn hiệu bạn không sở hữu, tên của các ứng dụng lớn hơn hoặc phổ biến hơn, ngôn ngữ về giá đặt sai trường, tên người nổi tiếng chèn vào để tăng lượt tìm kiếm, hoặc các cụm từ chung chung nhồi vào để bắt lượt tìm kiếm. Trường từ khóa 100 ký tự thường là thủ phạm, nhưng phụ đề và tên ứng dụng cũng bị đánh dấu. Tên ứng dụng bị giới hạn 30 ký tự, và ngôn ngữ về giá hay khuyến mãi không được xuất hiện trong tên, phụ đề, hay ảnh chụp màn hình.
Trước (trường từ khóa): một danh sách bao gồm tên của ba ứng dụng lớn hơn trong cùng danh mục, tên một nhà sáng tạo nổi tiếng, và vài từ đang thịnh hành không liên quan, không từ nào mô tả tính năng bạn thực sự có.
Sau: từ khóa ánh xạ đến những gì người dùng thực sự tìm kiếm để tìm ra chức năng của bạn — các tác vụ nó thực hiện, vấn đề nó giải quyết, các danh từ lấy từ chính màn hình ứng dụng của bạn. Mỗi từ khóa nên trỏ đến điều gì đó ứng dụng thực sự làm được.
Trước (phụ đề): một câu so sánh định vị bản thân đối đầu với một ứng dụng đối thủ được nêu tên.
Sau: phụ đề nêu rõ kết quả mà ứng dụng của bạn mang lại bằng ngôn ngữ đơn giản, không có tên thương hiệu nào khác. Phụ đề là để cung cấp bối cảnh cho ứng dụng của bạn, không phải nơi để mượn lưu lượng tìm kiếm của người khác.
Hướng dẫn 4.3 — spam và ứng dụng gần như trùng lặp
Điều gì kích hoạt lỗi này. 4.3 nói về sự giống nhau. Lỗi xảy ra khi bạn phát hành nhiều ứng dụng gần như giống hệt dưới các bundle ID riêng biệt (một bản build riêng cho mỗi thành phố, mỗi đội, mỗi khách hàng, thay vì một ứng dụng chứa các biến thể đó bên trong), hoặc khi một bản gửi khó phân biệt với thứ đã có sẵn rộng rãi. Đây thường là vấn đề về khái niệm sản phẩm, nhưng chính bài niêm yết là thứ khiến sự trùng lặp lộ ra — mô tả và ảnh chụp màn hình giống hệt nhau giữa các ứng dụng của chính bạn là dấu hiệu rõ ràng.
Trước: năm ứng dụng trong tài khoản của bạn có cùng bố cục, cùng danh sách tính năng, và nội dung chỉ khác nhau ở việc đổi tên một thành phố hoặc một đội.
Sau: một ứng dụng duy nhất mang các biến thể đó dưới dạng tùy chọn hoặc giao dịch mua trong ứng dụng, với bài niêm yết mô tả điều thực sự khác biệt mà nó làm được. Nếu bạn thực sự có các sản phẩm riêng biệt, hãy để mỗi bài niêm yết thể hiện điều thực sự khác biệt qua ảnh chụp màn hình và mô tả, không chỉ là tìm-và-thay một danh từ riêng.
4.3 có thể đòi hỏi nhiều hơn việc chỉnh sửa metadata nếu ứng dụng thực sự chỉ là một bản làm lại sơ sài. Nhưng khi vấn đề chỉ là các bài niêm yết đọc giống hệt bản sao của nhau, việc phân biệt hóa nội dung và ảnh chụp màn hình chính là một cách khắc phục thuộc về metadata.
Hướng dẫn 5.2.1 — sở hữu trí tuệ của người khác trong metadata của bạn
Điều gì kích hoạt lỗi này. Sử dụng tài liệu bên thứ ba được bảo hộ mà bạn không có quyền — nhãn hiệu, tác phẩm có bản quyền, tên nhái — ở bất kỳ đâu trong bundle, tên nhà phát triển, hoặc metadata của bạn. Một biến thể phổ biến là sự không khớp giữa ứng dụng hoặc thương hiệu trong bài niêm yết với thực thể thực sự đã gửi bản đó, khiến Apple phải hỏi ai là chủ sở hữu tên đó.
Trước: tên một thương hiệu hoặc nền tảng mà bạn không sở hữu xuất hiện trong tiêu đề ứng dụng, phụ đề, hoặc trường từ khóa để bắt lượt tìm kiếm của nó.
Sau: tên sản phẩm của chính bạn trong tiêu đề, phụ đề và từ khóa. Nếu bạn thực sự tích hợp với một nền tảng bên thứ ba và cần nêu rõ điều đó, hãy giữ mọi đề cập về khả năng tương thích thực tế trong phần mô tả nơi được phép, và không đưa vào tên hay phụ đề. Nếu bạn xây dựng ứng dụng cho một khách hàng sở hữu nhãn hiệu đó, hãy gửi từ tài khoản của thực thể sở hữu nó, hoặc được thêm vào nhóm của họ, để tên người bán và thương hiệu khớp nhau.
Phần không cần build mới, nói lại
Với cả bốn trường hợp, nếu cách khắc phục nằm trong bản ghi phiên bản — văn bản và hình ảnh — bạn sửa nó trong App Store Connect rồi gửi lại đúng bản build đó. Bạn không cần tăng số hiệu build hay chờ xử lý. Đó là lối đi nhanh mà việc bị từ chối vì metadata mang lại cho bạn. Cái giá phải trả là bạn phải quay lại quy trình kiểm duyệt, nên việc đọc toàn bộ bài niêm yết đối chiếu với bốn hướng dẫn này trước khi bấm gửi lại đáng làm hơn là xử lý từng lỗi một.
Mokbi giúp được gì (và không giúp được gì)
Phần lớn rắc rối với 2.3.7 bắt đầu từ khâu viết nội dung, khi trường từ khóa hoặc phụ đề bị nhồi nhét để tăng độ phủ tìm kiếm. AI của Mokbi soạn nội dung niêm yết của bạn — tên, phụ đề, từ khóa, mô tả — dựa trên những gì ứng dụng của bạn thực sự làm được, giúp bạn tránh thói quen nhồi nhét và mượn thương hiệu vốn dẫn đến bị từ chối vì từ khóa ngay từ đầu. Sau đó, nó bản địa hóa nội dung đó sang 50 ngôn ngữ, nên bạn không phải tự tay viết lại trường từ khóa cho từng thị trường và vô tình lặp lại chính cái bẫy đó ở mỗi nơi.
Cần nhìn nhận rõ giới hạn của nó. Điều này giảm khả năng bị đánh dấu 2.3.x hoặc 5.2.1 về mặt câu chữ; nó không thể đảm bảo được duyệt, và không quyết định những gì bên trong bản build của bạn. Kiểm duyệt là quyền của Apple. Nội dung tuân thủ, đúng với ứng dụng giúp loại bỏ những lý do dễ tránh, tự gây ra do chính mình. Mokbi không tự động đăng lên bài niêm yết của bạn — nó tạo ra nội dung và ảnh chụp màn hình; bạn xem lại và tự gửi.