Listing và quảng bá: nội dung, bản địa hóa, ghi chú phát hành

1. Listing như một phần của sản phẩm, không phải “điền cho có”

Lập trình viên lần đầu lên Store thường coi listing là “thêm một form dài cần điền cho xong”. Nó giống việc viết README trong repository lúc 3 giờ sáng: “để mai viết lại cho ngon”. Spoiler: đa phần sẽ không viết lại đâu.

Với ChatGPT App, listing là điều đầu tiên, đôi khi là duy nhất, mà người dùng thấy trước khi bấm “Try” hoặc cuộn tiếp. Tên, phụ đề, mô tả ngắn, danh sách kịch bản, biểu tượng — tất cả hoạt động như một mini-landing.

Ngoài ra, listing ảnh hưởng không chỉ đến con người mà còn đến chính ChatGPT. Metadata (tên, danh mục, mô tả) tham gia vào cơ chế discovery. Khi mô hình chọn App nào gợi ý cho người dùng theo một truy vấn cụ thể, nó cũng dựa vào những văn bản bạn viết ở đây.

Guidelines chính thức yêu cầu tên và mô tả App phải rõ ràng, chính xác và không gây hiểu lầm về chức năng. Không có chuyện “chúng tôi là AI thần kỳ làm được mọi thứ” hay “khách hàng chính thức của X” nếu điều đó không đúng sự thật.

Tức là ở bước này bạn làm ba việc cùng lúc:

1. Giải thích cho con người lý do App của bạn tồn tại.
2. Đưa gợi ý cho thuật toán của Store và ChatGPT về các tình huống nên đề xuất App.
3. Đặt nền tảng niềm tin: hứa đúng những gì bạn thật sự làm, không phép màu hay dark pattern.

2. Khung listing cho ChatGPT App

Giao diện Store cụ thể có thể thay đổi trường và diện mạo, nhưng khung logic gần như luôn giống nhau. Với ChatGPT App có widget UI, thường cần những thứ sau:

Nhắc lại từ đầu bài: guidelines yêu cầu tên và mô tả phải rõ ràng và trung thực, không cố “giả làm khách hàng chính thức của ai đó”. Bảng trên đã bóc tách theo từng trường cụ thể của listing.

Mọi thứ sẽ trông hơi quan liêu cho đến khi bạn đặt mình vào vị trí người dùng. Bạn mở Store, thấy cả đống thẻ, bạn có 5 giây chú ý. Nhìn vào GiftGenius, bạn muốn lập tức hiểu:

• App này có liên quan đến việc của tôi không?
• Nó an toàn và không làm điều kỳ lạ với dữ liệu của tôi chứ?
• Nó khác gì so với một cuộc trò chuyện ChatGPT thông thường?

Listing của bạn phải trả lời được các câu hỏi đó.

3. Tên và phụ đề: đừng “tự bắn vào chân”

Tiêu chí cho một cái tên tốt

Tên App có nhiều vai: được nói trong hội thoại (“bật GiftGenius”), gõ trong ô tìm kiếm, thấy trong danh sách. Vì vậy, tên lý tưởng:

• ngắn gọn và dễ nhớ;
• truyền tải ý chính (GiftGenius → “gì đó về quà và sự thông minh”);
• không xâm phạm nhãn hiệu của người khác;
• không hứa điều bất khả thi và không giả làm khách hàng chính thức của nền tảng nào.

Chính các guidelines của OpenAI mà ta đã nhắc tới cũng cấm rõ ràng những tên gây hiểu lầm, bao gồm ám chỉ tính “chính thức” mà bạn không có.

Xem ví dụ cho GiftGenius.

Trong khóa học, ta tiếp tục dùng GiftGenius làm tên chính. Nếu bạn làm App riêng, đừng ngại một chút branding: “TripTailor”, “StockScout”, “LegalChecklist”, v.v.

Phụ đề: một câu “one-liner” quyết định tất cả

Phụ đề là “one-liner” của bạn. Nó hiển thị trong kết quả Store và trên trang App. Guidelines khuyên các văn bản này phải giải thích rõ ràng, trung thực mục đích App.

Phương án tệ:

"Trợ lý AI hoàn hảo cho mọi việc!"

Phương án tốt:

"Giúp chọn quà theo sở thích trong 30 giây ngay trong chat."

Phụ đề tốt sẽ:

• nói rõ kết quả người dùng nhận được;
• gợi ngữ cảnh (ở đây — “ngay trong chat”);
• không sa vào chi tiết kỹ thuật (“phân tích các vector embedding” chẳng ai hứng thú).

Thực hành tốt là viết 5–7 phương án rồi đọc lại bằng mắt của một người không chuyên kỹ thuật. Nếu chính bạn còn vấp khi đọc to — hãy viết lại.

4. Mô tả: ngắn và dài, trước/sau

Mô tả ngắn

Mô tả ngắn thường gồm vài câu và hiển thị cạnh phụ đề. Thường đây là cơ hội cuối cùng để “bắt” người dùng lười mở chi tiết.

Cấu trúc:

1. Câu đầu — App làm gì.
2. Câu thứ hai — khác gì so với ChatGPT thường hoặc App khác.

Ví dụ “trước” cho GiftGenius:

"App để chọn quà tặng. Dùng MCP và backend phức tạp để cho kết quả tốt nhất."

Vấn đề:

• thừa chi tiết kỹ thuật;
• không rõ bạn hơn ChatGPT thường ở điểm nào;
• không mô tả kịch bản người dùng.

Viết lại:

"GiftGenius giúp chọn quà theo sở thích, ngân sách và dịp tặng. Bạn trả lời vài câu hỏi trong chat, và App hiển thị các ý tưởng cụ thể kèm liên kết."

Ở đây ta gắn với trải nghiệm thật: “trả lời câu hỏi → thấy ý tưởng”. Văn bản như vậy cũng giúp ChatGPT hiểu tốt hơn các kịch bản điển hình của bạn.

Mô tả dài

Mô tả dài dành cho những người đã có động lực, nhưng họ cũng không muốn đọc bài luận kỹ thuật. Mẫu hay:

1. Ai là đối tượng (ví dụ, “những người ghét chọn quà vào phút chót”).
2. App giải quyết các việc gì (2–3 kịch bản chính).
3. Vì sao App tiện hơn so với hỏi ChatGPT mà không dùng App.
4. Dữ liệu và bảo mật — rất ngắn, dẫn chiếu tới Policy.
5. Ngôn ngữ/khu vực nếu có giới hạn.

Ví dụ mẫu cho GiftGenius:

GiftGenius — dành cho những ai lần nào cũng nhớ tới quà vào phút cuối. 
App hỏi bạn tặng ai, ngân sách bao nhiêu và dịp gì, rồi hiển thị danh sách ý tưởng có mô tả và liên kết.

Khác với hội thoại ChatGPT thông thường, GiftGenius dùng catalog sản phẩm và giá hiện tại của bạn, 
và còn nhớ lịch sử gợi ý trong phạm vi cuộc trò chuyện.

App không lưu cuộc trò chuyện của bạn lâu hơn mức cần thiết để gợi ý. Xem chi tiết trong Chính sách quyền riêng tư.

Điều quan trọng — đừng biến mô tả thành bãi rác thuật ngữ kiến trúc. Bên dưới có MCP, Agents, cache, feature flags, nhưng người dùng cần kịch bản: nhanh hơn, đơn giản hơn, đáng tin hơn.

5. Ảnh chụp màn hình, video, biểu tượng và phần hình ảnh

Xong phần văn bản của listing. Tiếp theo là thứ người dùng “thấy” chứ không “đọc”: biểu tượng, có thể là ảnh chụp màn hình và video ngắn.

Phần hình ảnh của ChatGPT App xuất hiện ở đâu

Tính đến giai đoạn 2025–2026, giao diện ChatGPT Store cho GPTs thông thường không hiển thị “băng chuyền ảnh chụp màn hình” như các store di động: chủ yếu là biểu tượng, tên, tác giả và gợi ý khởi đầu.

Với ChatGPT Apps có widget UI, tình hình tương tự: “vitrine” chính nằm bên trong ChatGPT (lần chạy App đầu, widget inline, v.v.). Ảnh chụp màn hình, video và trang trí rộng hơn thường nằm ở:

• landing page riêng của App;
• bài viết và thông báo (“chúng tôi đã làm GiftGenius như thế nào”);
• các nền tảng như Product Hunt, GitHub README, v.v.

Vì vậy khi nói “ảnh chụp và video cho listing”, trên thực tế là các tài nguyên bên ngoài nơi bạn dẫn người dùng từ Store, tài liệu hoặc mạng xã hội.

Biểu tượng App

Biểu tượng — chuyện nhỏ cho đến khi bạn thấy nó giữa hàng chục app. Nguyên tắc cơ bản:

• hình đơn giản, đọc được trong vòng tròn nhỏ (128×128);
• tối thiểu chữ, tốt nhất không có chữ;
• tương phản tốt với nền;
• liên hệ thị giác với chủ đề App (hộp quà, giỏ, phân tích biểu đồ, v.v.).

Với GiftGenius, phương án hợp lý — hộp quà tối giản trên nền tương phản, không dán chữ “GG” nhỏ xíu.

Ảnh chụp màn hình: nên cho thấy gì

Khi làm landing hoặc bài viết về App, bạn cần ảnh chụp cho thấy:

• kịch bản chính: người dùng đặt câu hỏi → widget đề xuất xuất hiện;
• “khoảnh khắc ấn tượng”: lọc, chọn phương án, có thể — tích hợp Instant Checkout (nếu có);
• tối thiểu chi tiết thừa: bỏ PII, dùng tài khoản test thay vì khách hàng thật, giao diện sạch.

Mẹo thực tế hay — tạo một “catalog demo” riêng với sản phẩm giả và tên gọi gọn gàng, để không lộ định danh nội bộ và brand của người khác.

Video ngắn

Walkthrough 30–60 giây có thể ghi bằng trình quay màn hình bình thường: mở ChatGPT, gõ truy vấn điển hình, cho thấy App xuất hiện và cách tương tác. Về bản chất, bạn tái hiện một golden prompt trong module UX.

Kịch bản cho GiftGenius:

1. Người dùng viết: “Cần quà cho đồng nghiệp lập trình, ngân sách $50”.
2. ChatGPT đề xuất GiftGenius.
3. Widget xuất hiện với câu hỏi làm rõ, sau đó — danh sách phương án.

Video như vậy rất phù hợp cho cả landing và bài đăng mạng xã hội.

6. Bản địa hóa listing: chiến lược và bẫy thường gặp

Từ hình ảnh chuyển sang ngôn ngữ. Ngay cả khi UI và dữ liệu đã được bản địa hóa tuyệt vời (chúng ta làm ở module 9), listing có đời sống riêng và tồn tại vài cái bẫy.

Vì sao phần này không đơn giản

App của bạn có thể bản địa hóa UI và dữ liệu rất tốt, dùng openai/locale, _meta["openai/userLocation"] và các mẹo khác trong module 9. Nhưng listing lại sống cuộc đời riêng.

Tính đến 2025–2026, ChatGPT Store không tự động chuyển tên và mô tả App theo ngôn ngữ giao diện của người dùng. Tức là không có cơ chế “đa ngôn ngữ” tích hợp cho metadata: Store hiển thị một bộ văn bản duy nhất.

Từ đó có ba chiến lược phổ biến.

Chiến lược 1: Universal English

Cách đơn giản, phổ biến nhất — toàn bộ mô tả và tên dùng tiếng Anh. Trong văn bản có thể ghi rõ App hỗ trợ những ngôn ngữ nào:

"Supports English, Spanish, Russian."

Ưu: một listing, dễ bảo trì, đa số khán giả kỹ thuật hiểu được. Nhược điểm rõ ràng: chuyển đổi kém hơn với người dùng không thoải mái đọc tiếng Anh.

Chiến lược 2: Tên lai

Cố “ngồi hai ghế”: “GiftGenius | Quà tặng”. Tên như vậy đọc được với người dùng tiếng Anh lẫn người Việt/nga, v.v.

Ưu: nhiều người trực giác hiểu App nói về gì. Nhược: “ồn”, có thể phá vỡ phong cách chung của Store, và không giải quyết mô tả dài — vẫn phải chọn một ngôn ngữ.

Chiến lược 3: App riêng theo ngôn ngữ

Phương án cho dự án lớn: làm “GiftGenius (RU)” và “GiftGenius (Global)” dưới dạng App khác nhau nhưng dùng chung MCP backend.

Ưu điểm:

• có thể tùy biến hoàn toàn mô tả, gợi ý khởi đầu và thậm chí flow theo thị trường địa phương;
• “SEO” trong Store tốt hơn: người dùng viết bằng tiếng bản địa sẽ thấy tên và mô tả dễ hiểu.

Nhược điểm:

• thống kê sử dụng và đánh giá bị chia nhỏ giữa nhiều App;
• nhiều việc bảo trì hơn: phát hành, listing, review cho từng biến thể.

Lời khuyên thực tế

Với App học tập/proof-of-concept, thường Universal English là đủ, đặc biệt nếu khán giả chính là lập trình viên. Với sản phẩm thật, thỏa hiệp hợp lý — bắt đầu với một-hai ngôn ngữ và làm bản dịch chất lượng, thay vì khởi động cùng lúc mười ngôn ngữ với “salad từ máy dịch”.

Liên hệ với module bản địa hóa: bạn đã biết bản địa hóa UI và dữ liệu linh hoạt. Giờ chỉ cần đảm bảo văn bản listing không mâu thuẫn với những gì người dùng thật sự thấy. Đừng viết “chỉ hỗ trợ tiếng Anh” nếu App đã hoạt động tốt bằng tiếng Tây Ban Nha.

7. Ghi chú phát hành: để làm gì và viết sao cho khỏi “đã cải thiện mọi thứ”

Listing là khoảnh khắc gặp gỡ đầu tiên. Sau đó App sẽ phát triển và bạn cần kể lại cho người dùng — đó là lúc ghi chú phát hành vào cuộc.

Ghi chú phát hành trong ngữ cảnh ChatGPT App là gì

Ghi chú phát hành là mô tả ngắn về thay đổi trong phiên bản mới: thêm gì, sửa gì, tăng tốc gì. Ở các store cổ điển có tab riêng “Version history”. Trong ChatGPT Store hiện tại có thể không có, nên ghi chú phát hành sống ở:

• mục mô tả phiên bản mới trong console Store;
• trang web/blog/repository của bạn;
• bên trong App, nếu bạn cho phép người dùng hỏi “có gì mới”.

Định dạng thường đơn giản: tên phiên bản, ngày và danh sách thay đổi chính.

Tại sao nên tốn thời gian cho việc này

Thứ nhất, người dùng thấy App còn sống: có người quay lại, cải tiến, sửa lỗi. Điều này tăng niềm tin vào cả code lẫn business của bạn.

Thứ hai, bạn có dòng thời gian nội bộ: thuận tiện xem lúc nào thêm tính năng X và dẫn chiếu trong hỗ trợ hay “bán” cập nhật trong công ty.

Thứ ba, ghi chú phát hành là chất liệu sẵn cho quảng bá mini: email, bài đăng mạng xã hội, video ngắn.

Cách viết: bán lợi ích, không bán thuật ngữ nội bộ

Kinh nghiệm từ store di động và khuyến nghị của các tác giả sản phẩm quy về một ý: mô tả thay đổi dưới góc lợi ích người dùng, không phải các thực thể nội bộ bạn đã chỉnh.

Dở:

"v1.1 — refactor thuật toán chọn, cải thiện scoring, fix bug."

Tốt hơn:

"v1.1 — gợi ý chính xác hơn cho người có sở thích hiếm. 
Giờ đây GiftGenius hiểu tốt hơn nếu bạn nhắc tới board game, thủ công hoặc âm nhạc. 
Cũng đã sửa một lỗi hiếm khiến danh sách gợi ý đôi khi bị làm trống."

Ngay cả bugfix cũng được diễn đạt như cải thiện độ tin cậy cho người dùng.

Ví dụ cho GiftGenius

Phát hành đầu tiên:

v1.0 — ra mắt GiftGenius
- Những gợi ý quà đầu tiên theo tên, sở thích và ngân sách.
- Hỗ trợ USD/EUR.
- Bản địa hóa giao diện: EN, RU.

Phát hành thứ hai:

v1.1 — quà theo ảnh và bộ lọc theo loại
- Thêm công cụ thử nghiệm: có thể tải ảnh bàn làm việc của người nhận, và GiftGenius sẽ gợi ý ý tưởng phù hợp.
- Bộ lọc mới "chỉ quà tặng số" — tiện nếu người đó ở thành phố khác.
- Tăng tốc tìm kiếm trong catalog, danh sách gợi ý mở nhanh hơn.

Định dạng này dễ chuyển thành văn bản trong Store và cả bài đăng “có gì mới ở GiftGenius”.

8. Kế hoạch quảng bá mini: làm sao trông như bạn có tí chất marketing

Ngay cả listing tuyệt vời và ghi chú phát hành gọn gàng cũng không tự kéo người dùng. Cần ít nhất một kế hoạch quảng bá tối thiểu, có thể do chính lập trình viên thực hiện.

Marketing đúng nghĩa là cả một khóa học khác, nhưng không có quảng bá thì App tốt nhất trong Store cũng chỉ “đắp chiếu”. Ta cần bộ hành động tối thiểu mà bạn thật sự có thể làm với vai trò dev.

“Quảng bá” nội bộ trong hệ sinh thái ChatGPT

Điều đầu tiên và quan trọng: một listing viết tốt tự thân đã là một phần quảng bá. Metadata và mô tả giúp ChatGPT đề xuất App trong hội thoại liên quan, và tìm kiếm trong Store — tìm ra nó bằng từ khóa.

Từ đó có các bước thực tiễn:

• nhắc các kịch bản điển hình trong mô tả (mua quà, chuẩn bị báo cáo, v.v.);
• đừng trút biệt ngữ kỹ thuật vào listing — người dùng sẽ ngại;
• tránh tuyên bố quá rộng “cho mọi thứ và mọi người” để không làm loãng “SEO”.

Quảng bá bên ngoài: landing, mạng xã hội, cộng đồng

Các nghiên cứu gợi ý một kế hoạch tối thiểu cho ChatGPT Apps:

1. Làm video preview ngắn (30–60 giây) cho thấy kịch bản chính.
2. Viết ghi chú/bài blog: “Chúng tôi làm GiftGenius như thế nào” — kèm vài ảnh và mô tả kiến trúc ở mức cao.
3. Tạo 1–2 bài trên mạng xã hội (Twitter/X, LinkedIn, Telegram) kèm liên kết App hoặc landing.
4. Nhờ 5–10 đồng nghiệp/bạn bè dùng thử và phản hồi chân thật.

Quan trọng là đừng thành spammer: không “tag tất cả mọi người” hay “đăng khắp mọi chat”. Nguyên tắc hay — mỗi bài phải có giá trị thật (demo, giải thích kiến trúc, phân tích case thú vị).

Đăng ở đâu các ghi chú phát hành

Như đã nói, Store có thể không có lịch sử phiên bản riêng. Vậy nên hợp lý là đăng song song:

• trên trang App trong Store (nếu có chỗ thêm văn bản về phiên bản mới);
• trên website của bạn (mục Changelog);
• trong README của repository (nếu App open-source hoặc mở một phần);
• trong newsletter hoặc kênh dành cho người dùng quan tâm.

Tiện nhất là dùng cùng một cấu trúc “thô” được định nghĩa trong code hoặc config, rồi render ra các kênh khác nhau.

Ví dụ đơn giản bằng TypeScript:

// shared/releaseNotes.ts
export const releaseNotes = [
  {
    version: "1.0.0",
    date: "2025-02-01",
    changes: [
      "Phát hành công khai đầu tiên của GiftGenius",
      "Gợi ý quà theo sở thích và ngân sách",
    ],
  },
  {
    version: "1.1.0",
    date: "2025-03-10",
    changes: [
      "Bộ lọc mới “chỉ quà tặng số”",
      "Tăng tốc tìm kiếm trong catalog",
    ],
  },
];

Mảng này có thể dùng trong widget (trả lời “có gì mới?”) và để tạo trang Changelog trên website của bạn.

9. Bức tranh tổng thể: listing GiftGenius làm ví dụ

Để kết nối mọi thứ, hãy phác thảo listing “bản nháp” cho App học tập của chúng ta.

Phiên bản văn bản

Tên:
GiftGenius

Phụ đề:
Chọn quà theo sở thích và ngân sách trong 30 giây ngay trong chat.

Mô tả ngắn:
GiftGenius hỏi vài thông tin về người nhận, ngân sách và dịp tặng, rồi hiển thị danh sách ý tưởng kèm mô tả và liên kết. Lý tưởng khi chỉ còn một buổi tối trước ngày lễ.

Mô tả dài (rút gọn):

GiftGenius giúp những ai mệt mỏi vì phải nghĩ quà vào phút chót. 
App hỏi bạn tặng ai, người đó thích gì và ngân sách bao nhiêu, 
rồi hiển thị ý tưởng cụ thể kèm mô tả ngắn và liên kết nơi mua.

GiftGenius sử dụng catalog sản phẩm và giá hiện tại của bạn, nên gợi ý gần với thế giới thực 
hơn so với lời khuyên chung chung trong chat.

App hỗ trợ giao diện tiếng Anh và tiếng Nga. 
Chúng tôi không dùng dữ liệu của bạn để huấn luyện các mô hình bên thứ ba và chỉ lưu lịch sử gợi ý trong phạm vi một phiên. 
Chi tiết — trong Chính sách quyền riêng tư.

Gợi ý khởi đầu:

• “Help me find a birthday gift for a colleague who loves board games, budget $40.”
• “Gợi ý quà cho mẹ thích làm vườn, ngân sách tới 3000 ₽.”
• “Suggest digital-only gifts for a friend who lives abroad, budget €50.”

Biểu tượng: hộp quà tối giản với màu nhận diện.

Ngôn ngữ: EN, RU (đã nêu rõ trong mô tả, và UI của chúng ta đã tự chuyển theo openai/locale).

Liên kết:
Privacy Policy, Terms of Use, Support page — chúng ta đã làm trong bài trước.

Sơ đồ: hành trình người dùng từ listing tới sử dụng

Để trực quan — một sơ đồ nhỏ:

flowchart TD
    A[Listing GiftGenius trong Store] --> B[Người dùng đọc
tên và mô tả]
    B --> C{Anh/chị ấy có hiểu
giá trị của App không?}
    C -- Có --> D[Nhấn Try / kết nối App]
    C -- Không --> E[Lướt qua tiếp]
    D --> F[Cuộc hội thoại đầu tiên với ChatGPT]
    F --> G[Mô hình đề xuất GiftGenius
theo ngữ cảnh truy vấn]
    G --> H[Widget xuất hiện
và kịch bản chọn quà]

Listing tốt làm tăng khả năng người dùng đi theo nhánh “Có” và tới bước G đã phần nào hiểu kỳ vọng với App.

10. Lỗi điển hình khi làm listing và quảng bá

Lỗi số 1: Tên và phụ đề hứa hẹn phép màu không có thật.
Viết “Ultimate AI that does everything” nghe hấp dẫn, nhưng phản tác dụng hai mảng. Người dùng kỳ vọng siêu trợ lý vạn năng, còn thực tế chỉ là công cụ chuyên biệt. Đội kiểm duyệt Store có thể đặt câu hỏi: các tuyên bố đó có khớp hành vi thực và chính sách không. Hướng dẫn yêu cầu diễn đạt rõ ràng, chính xác, không phóng đại.

Lỗi số 2: Mô tả ngập chi tiết kỹ thuật.
“Dùng MCP, Agents SDK, cache ở edge layer” — tuyệt cho talk ở meetup, nhưng vô dụng trong listing. Người dùng quan tâm kịch bản và kết quả: nhanh hơn, đơn giản hơn, tin cậy hơn. Chi tiết kỹ thuật để dành cho blogpost “chúng tôi làm thế nào”.

Lỗi số 3: Bỏ qua bản địa hóa của listing.
App bản địa hóa UI và dữ liệu rất tốt, nhưng listing để máy dịch tệ hoặc chỉ tiếng Anh cho thị trường mà đa số không đọc tiếng Anh. Kết quả bạn mất chuyển đổi trước cả lần chạy đầu tiên. Tốt hơn một-hai ngôn ngữ với văn bản chất lượng, hơn mười ngôn ngữ lộn xộn.

Lỗi số 4: Biểu tượng và phần hình ảnh làm vội “cho có”.
Chi tiết quá rối, chữ không thể đọc trong vòng tròn nhỏ, hoặc biểu tượng xám nhạt lẫn giữa đám khác. Người dùng đơn giản không nhớ đó là App của bạn. Hãy dành vài giờ cho biểu tượng gọn gàng và ảnh chụp rõ ràng: bạn sẽ dùng chúng rất lâu trong bài viết, slide và mạng xã hội.

Lỗi số 5: Ghi chú phát hành kiểu “bug fixes and improvements”.
Đúng là ai cũng viết vậy, nhưng bạn có thể làm tốt hơn. Nếu chính bạn sau một tháng không hiểu có gì khác ở bản 1.3, thì người dùng càng không. Hãy mô tả thay đổi dưới góc lợi ích: cái gì nhanh hơn, tin cậy hơn, xuất hiện kịch bản mới nào. Ngắn, nhưng cụ thể.

Lỗi số 6: Không có thông báo bên ngoài.
App đã lên Store nhưng bạn không nói với ai. Không bài đăng, không video ngắn, không ghi chép blog. Kết quả App của bạn chỉ đến với người dùng tình cờ trong kết quả Store. Ngay cả thông báo tối thiểu cho đồng nghiệp, người theo dõi hoặc cộng đồng cũng mang lại những lượt cài đầu tiên và phản hồi để bạn cải thiện.

Lỗi số 7: Listing không khớp với hành vi thực của App.
Listing ghi App không lưu dữ liệu, nhưng logic retention lại khác. Hoặc hứa hỗ trợ một ngôn ngữ trong khi thực tế vẫn beta và lỗi. Điều này không chỉ làm xấu đánh giá, mà còn có thể gây vấn đề với Store. Văn bản listing phải đi sau kiến trúc và cài đặt bảo mật ta đã bàn ở các module trước, chứ không sống tách biệt.