Listagem e promoção: conteúdo, localização, notas de versão

1. A listagem como parte do produto, não “um formulário para cumprir tabela”

O desenvolvedor que chega ao Store pela primeira vez muitas vezes vê a listagem como “só mais um formulário longo que preciso preencher com qualquer coisa”. É mais ou menos como escrever o README do repositório às três da manhã: “depois eu reescrevo direito”. Spoiler: quase nunca reescrevem.

Para um ChatGPT App, a listagem é a primeira — e às vezes a única — coisa que o usuário verá antes de clicar em “Try” ou rolar para baixo. Nome, subtítulo, descrição curta, lista de cenários, ícone — tudo isso funciona como uma mini landing page.

Além disso, a listagem influencia não só as pessoas, mas o próprio ChatGPT. Os metadados (nome, categorias, descrição) participam dos mecanismos de discovery. Quando o modelo escolhe qual App sugerir a um usuário para uma solicitação específica, ele também se apoia nos textos que você escreveu aqui.

As diretrizes oficiais exigem que o nome e a descrição do App sejam claros, precisos e não induzam a erro quanto à funcionalidade. Nada de “somos uma IA mágica que faz tudo” e “cliente oficial de X”, se isso não for verdade.

Ou seja, nesta etapa você faz três coisas ao mesmo tempo:

1. Explica à pessoa por que seu App existe.
2. Dá pistas aos algoritmos do Store e do ChatGPT sobre em quais situações o App é apropriado.
3. Constrói a base de confiança: promete exatamente o que realmente faz, sem magia nem dark patterns.

2. Estrutura da listagem de um ChatGPT App

A interface específica do Store pode mudar os campos e a aparência, mas a estrutura lógica quase sempre é a mesma. Do que hoje normalmente é necessário para um ChatGPT App com widget de UI:

Lembrando do início da aula: as diretrizes exigem nomes e descrições claros e honestos, sem tentar se passar por “cliente oficial de algo”. A tabela acima destrincha isso por campos concretos da listagem.

Tudo isso parece meio burocrático até você se colocar no lugar do usuário. Você abre o Store, vê um monte de cards, tem cinco segundos de atenção. Olhando para o GiftGenius, você quer entender de imediato:

• este App resolve os meus problemas?
• é seguro e não vai fazer coisas estranhas com meus dados?
• ele é diferente de um chat normal com o ChatGPT?

As respostas a essas perguntas devem estar na sua listagem.

3. Nome e subtítulo: como não dar um tiro no pé

Critérios de um bom nome

O nome do App tem vários papéis ao mesmo tempo: é dito numa conversa (“abra o GiftGenius”), digitado na busca e visto na lista. Por isso, o nome ideal:

• é curto e memorável;
• transmite a ideia principal (GiftGenius → “algo sobre presentes e ‘inteligência’”);
• não infringe marcas de terceiros;
• não promete o impossível nem se passa por cliente oficial de alguma plataforma.

As mesmas diretrizes da OpenAI, citadas no início, proíbem explicitamente nomes enganosos, incluindo insinuações de oficialidade que você não possui.

Vamos ver exemplos para o nosso GiftGenius.

Ao longo do curso continuamos usando GiftGenius como nome principal. Se você estiver criando seu próprio App, não tenha medo de um leve branding: “TripTailor”, “StockScout”, “LegalChecklist” etc.

Subtítulo: uma frase que resolve tudo

O subtítulo é o seu “one‑liner”. Ele aparece nos resultados do Store e na página do App. As diretrizes oficiais recomendam que esses textos expliquem de forma clara e honesta a finalidade do App.

Ruim:

"O assistente de IA perfeito para qualquer tarefa!"

Bom:

"Ajuda a escolher um presente em 30 segundos com base nos interesses da pessoa, direto no chat."

Um bom subtítulo:

• diz qual resultado o usuário obterá;
• sugere o contexto (no nosso caso — “direto no chat”);
• não entra em detalhes técnicos (“analisa vetores de embedding”) que não interessam a ninguém.

Para praticar, vale escrever 5–7 variantes e reler com os olhos de alguém não técnico. Se você mesmo gagueja ao ler em voz alta, — reescreva.

4. Descrição: curta e longa, antes/depois

Descrição curta

A descrição curta geralmente tem duas frases e aparece ao lado do subtítulo. Muitas vezes é sua última chance de fisgar o usuário que tem preguiça de abrir os detalhes.

Estrutura:

1. Primeira frase — o que o App faz.
2. Segunda — em que ele difere de um ChatGPT comum ou de outros Apps.

Exemplo “antes” para o GiftGenius:

"App para escolher presentes. Usa MCP e um backend complexo para entregar os melhores resultados."

Problemas:

• detalhes técnicos desnecessários;
• não está claro por que você é melhor que o ChatGPT puro;
• não descreve o cenário do usuário.

Vamos reescrever:

"O GiftGenius ajuda a escolher um presente com base nos interesses da pessoa, no orçamento e no motivo. Você responde a algumas perguntas no chat, e o App mostra ideias concretas com links."

Aqui nos conectamos à experiência real do usuário: “respondo a perguntas → vejo ideias”. Esse texto também ajuda o ChatGPT a entender melhor seus cenários típicos.

Descrição longa

A descrição longa é lida por quem já está motivado, mas mesmo assim ninguém quer mergulhar num tratado técnico. Um bom molde:

1. Quem é o público‑alvo (por exemplo, “pessoas que odeiam escolher presentes no último minuto”).
2. Quais tarefas o App resolve (2–3 cenários principais).
3. Por que o App é mais conveniente do que apenas perguntar ao ChatGPT sem App.
4. Como os dados e a segurança são tratados — bem curto, remetendo à Política.
5. Idiomas/regiões, se houver restrições.

Para o GiftGenius, um exemplo de molde:

GiftGenius — para quem sempre lembra do presente no último minuto. 
O App pergunta para quem você está escolhendo o presente, qual é seu orçamento e qual é a ocasião, e depois mostra uma lista pronta de ideias com descrições e links.

Ao contrário de um diálogo comum com o ChatGPT, o GiftGenius usa seu catálogo de produtos e preços atualizados, e também lembra o histórico de seleções dentro da conversa.

O App não guarda sua conversa por mais tempo do que o necessário para gerar recomendações. Saiba mais na nossa Política de Privacidade.

O principal — não transforme a descrição num amontoado de termos de arquitetura. Por baixo do capô pode haver MCP, Agents, cache, feature flags, mas o que importa para o usuário é o cenário: mais rápido, mais simples, mais confiável.

5. Capturas de tela, vídeo, ícone e visual

Encerrados os textos da listagem, vamos ao que o usuário vê — e não lê: ícone, possíveis capturas de tela e um vídeo curto.

Onde o visual aparece para um ChatGPT App

Em 2025–2026, as interfaces do ChatGPT Store para GPTs comuns não mostram o tradicional “carrossel de capturas” dos stores móveis: lá aparecem principalmente ícone, nome, autor e sugestões iniciais.

Para ChatGPT Apps com widgets de UI, a situação é parecida: a “vitrine” principal fica dentro do próprio ChatGPT (primeira execução do App, widget inline etc.). Capturas externas, vídeos e um visual mais amplo vivem com mais frequência:

• numa landing page separada do App;
• em posts e anúncios (“como criamos o GiftGenius”);
• em plataformas como Product Hunt, README do GitHub etc.

Portanto, quando falamos de “capturas e vídeo para a listagem”, na prática estamos falando de recursos externos, para onde você levará as pessoas a partir do Store, da documentação ou das redes sociais.

Ícone do App

Ícone parece detalhe — até você vê‑lo em uma lista com dezenas de apps. Princípios básicos:

• forma simples que seja legível num círculo pequeno (128×128);
• mínimo de texto, de preferência nenhum;
• bom contraste com o fundo;
• ligação visual com o tema do App (presente, carrinho, análise de gráficos etc.).

Para o GiftGenius, uma opção lógica é uma caixa de presente minimalista em fundo contrastante, sem a sigla “GG” em fonte minúscula.

Capturas de tela: o que mostrar

Ao criar a landing ou um artigo sobre o App, você precisa de capturas que mostrem:

• o cenário principal: o usuário fez uma pergunta → apareceu um widget com recomendações;
• o “momento de destaque”: filtragem, escolha de opção e, talvez, integração com Instant Checkout (se houver);
• o mínimo de detalhes desnecessários: remover PII, usar contas de teste no lugar de clientes reais, interface limpa.

Uma boa prática é montar um “catálogo de demonstração” separado com produtos fictícios e nomes limpos, para não expor identificadores internos e marcas de terceiros.

Vídeo curto

Um walkthrough de 30–60 segundos pode ser gravado com qualquer gravador de tela: abrir o ChatGPT, digitar uma solicitação típica, mostrar como o App aparece e como interagir com ele. Basicamente, você reproduz um dos seus golden prompts do módulo sobre UX.

Roteiro para o GiftGenius:

1. O usuário escreve: “Preciso de um presente para um colega desenvolvedor, orçamento de $50”.
2. O ChatGPT sugere o GiftGenius.
3. Surge um widget com perguntas de esclarecimento e, em seguida, uma lista de opções.

Esse vídeo é ótimo tanto para a landing quanto para um post em redes sociais.

6. Localização da listagem: estratégias e armadilhas

Do visual — aos idiomas. Mesmo que a UI e os dados já estejam muito bem localizados (o que vimos no módulo 9), a listagem tem vida própria e há armadilhas aqui.

Por que não é tão simples

Seu App pode localizar muito bem a UI e os dados, usar openai/locale, _meta["openai/userLocation"] e outros truques do módulo 9. Mas a listagem tem vida própria.

Até 2025–2026, o ChatGPT Store não alterna automaticamente o nome e a descrição do App conforme o idioma da interface do usuário. Ou seja, você não tem um mecanismo “embutido” de metadados multilíngues: o Store mostra um único conjunto de textos.

Disso derivam três estratégias populares.

Estratégia 1: Universal English

A opção mais simples e comum — toda a descrição e o nome em inglês. No texto, você pode indicar explicitamente quais idiomas o App suporta:

"Supports English, Spanish, Russian."

Vantagens: uma única listagem, fácil de manter, compreensível para a maior parte do público técnico. Desvantagem óbvia: pior conversão entre usuários que não leem inglês com conforto.

Estratégia 2: Nome híbrido

É a tentativa de agradar dois públicos: “GiftGenius | Podarki”. Esse nome é legível para usuários anglófonos e para os que entendem o termo transliterado.

Vantagem: mais gente entende intuitivamente do que se trata o App. Desvantagem: fica “barulhento”, pode prejudicar o estilo geral do Store, e não resolve o problema da descrição longa — que ainda precisará ser escolhida em um idioma.

Estratégia 3: Apps separados por idioma

Opção para projetos maiores: criar, por exemplo, “GiftGenius (RU)” e “GiftGenius (Global)” como Apps diferentes com o mesmo backend MCP.

Vantagens:

• dá para adaptar completamente a descrição, as sugestões iniciais e até o fluxo ao mercado local;
• melhor “SEO” dentro do Store: o usuário que escreve em russo verá nome e descrição compreensíveis.

Desvantagens:

• estatísticas de uso e avaliações ficam espalhadas entre vários Apps;
• mais trabalho de manutenção: releases, listagens, review para cada variante.

Conselho prático

Para um App de estudo/prova de conceito, geralmente basta o Universal English, especialmente se o público principal for desenvolvedores. Em um produto real, um compromisso sensato é começar com um ou dois idiomas e fazer boas traduções, em vez de tentar lançar em dez com “salada de palavras” de tradução automática.

A ligação com o módulo de localização é esta: você já sabe localizar UI e dados com flexibilidade. Agora, basta garantir que os textos da listagem não contradigam o que o usuário realmente verá. Não escreva “suporta apenas inglês” se o App já funciona tranquilamente em espanhol.

7. Notas de versão: para que servem e como escrever sem “melhoramos tudo”

A listagem é o momento do primeiro encontro. Depois o App evolui, e é preciso contar isso aos usuários — entram em cena as notas de versão.

O que são notas de versão no contexto de um ChatGPT App

Notas de versão são uma breve descrição das mudanças em uma nova versão do App: o que foi adicionado, corrigido e acelerado. Nos stores clássicos há uma aba “Version history” só para isso. No ChatGPT Store atual pode não existir essa aba; portanto, as notas de versão vivem:

• na descrição da nova versão no console do Store;
• no seu site/blog/repositório;
• dentro do próprio App, se você permitir que o usuário pergunte “o que há de novo”.

O formato geralmente é simples: nome da versão, data e lista das mudanças principais.

Por que gastar tempo com isso

Primeiro, o usuário percebe que o App está vivo: ele recebe melhorias, correções de bugs. Isso aumenta a confiança tanto no seu código quanto no seu negócio.

Segundo, você mesmo passa a ter uma cronologia: é prático ver quando uma feature foi adicionada e referenciar isso no suporte ou “vender” updates internamente.

Terceiro, notas de versão são material pronto para mini‑divulgação: e‑mail na newsletter, post em redes sociais, vídeo curto.

Como escrever: venda a utilidade, não as entidades internas

A experiência em stores móveis e as recomendações de autores de produto convergem para uma ideia simples: descreva as mudanças do ponto de vista do benefício para o usuário, não das entidades internas que você alterou.

Ruim:

"v1.1 — refatorado o algoritmo de seleção, scoring aprimorado, bugs corrigidos."

Melhor:

"v1.1 — presentes mais precisos para pessoas com hobbies raros. 
Agora o GiftGenius entende melhor os interesses quando você menciona jogos de tabuleiro, artesanato ou música. 
Também corrigimos um erro raro que às vezes limpava a lista de recomendações."

Aqui até a correção de bug é formulada como melhoria de confiabilidade para o usuário.

Exemplos para o GiftGenius

Primeiro release:

v1.0 — lançamento do GiftGenius
- Primeiras seleções de presentes por nome, interesses e orçamento.
- Suporte a USD/EUR.
- Localização da interface: EN, RU.

Segundo release:

v1.1 — presentes por foto e filtros por tipo
- Adicionamos uma ferramenta experimental: você pode enviar uma foto da mesa de trabalho da pessoa e o GiftGenius sugere ideias relacionadas.
- Novo filtro "apenas presentes digitais" — útil quando a pessoa está em outra cidade.
- Aceleramos a busca no catálogo; a lista de recomendações abre mais rápido.

Esse formato é fácil de virar texto no Store e um post curto “o que há de novo no GiftGenius”.

8. Mini plano de divulgação: como parecer um pouco marketeiro

Mesmo a listagem perfeita e notas de versão caprichadas não trazem usuários sozinhas. É preciso ao menos um plano mínimo de divulgação que possa ser feito pelo desenvolvedor.

Marketing de verdade é outro curso, mas sem nenhuma divulgação até o melhor App no Store vai juntar poeira. Precisamos de um conjunto mínimo de ações que você realmente consiga fazer como dev.

“Divulgação” interna no ecossistema do ChatGPT

Primeiro e principal: uma boa listagem já é, por si só, parte da divulgação. Metadados e descrições ajudam o ChatGPT a sugerir seu App em diálogos relevantes, e a busca do Store a encontrá‑lo por palavras‑chave.

Daqui seguem passos práticos:

• mencionar cenários típicos na descrição (compra de presentes, preparação de relatórios etc.);
• não entulhar a listagem de jargão técnico — isso só afasta o usuário;
• evitar declarações amplas demais “para tudo e todos”, para não diluir o “SEO”.

Divulgação externa: landing, redes sociais, comunidade

Pesquisas sobre o tema recomendam um plano mínimo simples de divulgação para ChatGPT Apps:

1. Gravar um vídeo‑preview curto (30–60 segundos) mostrando o cenário principal.
2. Escrever uma nota/artigo no blog: “Como criamos o GiftGenius” — com algumas capturas e uma visão de alto nível da arquitetura.
3. Fazer 1–2 posts nas redes (Twitter/X, LinkedIn, Telegram) com link para o App ou a landing.
4. Pedir para 5–10 colegas/amigos experimentarem o App e darem feedback honesto.

Importante não virar spammer: nada de “marcar todo mundo no tweet” ou “postar em todos os grupos”. Uma boa regra — cada post precisa entregar valor real (demo, explicação de arquitetura, análise de um caso interessante).

Onde publicar as notas de versão

Como já discutimos, pode não haver um histórico de versões separado no Store. Então faz sentido duplicar as notas de versão:

• na página do App no Store (se for possível adicionar texto sobre a nova versão);
• no seu site (seção Changelog);
• no README do repositório (se o App for open‑source ou parcialmente aberto);
• na newsletter ou canal para usuários interessados.

Aqui é prático usar uma mesma estrutura “bruta”, definida no código ou no config, e depois apenas renderizá‑la em diferentes canais.

Exemplo simples em TypeScript:

// shared/releaseNotes.ts
export const releaseNotes = [
  {
    version: "1.0.0",
    date: "2025-02-01",
    changes: [
      "Primeiro lançamento público do GiftGenius",
      "Seleção de presentes por interesses e orçamento",
    ],
  },
  {
    version: "1.1.0",
    date: "2025-03-10",
    changes: [
      "Novo filtro \"apenas presentes digitais\"",
      "Busca no catálogo mais rápida",
    ],
  },
];

Esse array pode ser usado tanto no widget (resposta a “o que há de novo?”) quanto na geração da página de Changelog no seu site.

9. Visão completa: a listagem do GiftGenius como exemplo

Para amarrar tudo, vamos rascunhar uma listagem “de treino” para o nosso App.

Versão textual

Nome:
GiftGenius

Subtítulo:
Escolhe presentes em 30 segundos com base em interesses e orçamento, direto no chat.

Descrição curta:
O GiftGenius faz algumas perguntas sobre a pessoa, o orçamento e a ocasião e mostra uma lista pronta de ideias com descrições e links. Ideal quando falta só uma noite para a comemoração.

Descrição longa (versão resumida):

O GiftGenius ajuda quem está cansado de quebrar a cabeça com presentes no último minuto. 
O App pergunta para quem você está escolhendo o presente, do que a pessoa gosta e qual é seu orçamento, 
e então mostra ideias concretas com uma breve descrição e um link para comprar.

O GiftGenius considera seu catálogo de produtos e preços atualizados, por isso as recomendações ficam mais próximas do mundo real 
do que um conselho genérico no chat.

O App suporta interface em inglês e russo. 
Não usamos seus dados para treinar modelos de terceiros e guardamos o histórico de seleções apenas dentro de uma sessão. 
Saiba mais na nossa Política de Privacidade.

Sugestões iniciais:

• “Help me find a birthday gift for a colleague who loves board games, budget $40.”
• “Escolha um presente para minha mãe, que gosta de jardinagem, até 3000 ₽.”
• “Suggest digital-only gifts for a friend who lives abroad, budget €50.”

Ícone: caixa de presente minimalista nas cores da marca.

Idiomas: EN, RU (mencionado explicitamente na descrição, e a UI já alterna via openai/locale).

Links:
Privacy Policy, Terms of Use, Support page — tudo isso já fizemos na aula anterior.

Diagrama: jornada do usuário da listagem ao uso

Para visualização — um diagrama pequeno:

flowchart TD
    A[Listagem do GiftGenius no Store] --> B[Usuário lê
o nome e a descrição]
    B --> C{Ele entende
o valor do App?}
    C -- Sim --> D[Clica em Try / conecta o App]
    C -- Não --> E[Rola para baixo]
    D --> F[Primeiro diálogo com o ChatGPT]
    F --> G[O modelo sugere o GiftGenius
pelo contexto da solicitação]
    G --> H[Aparece o widget
e o fluxo de escolha de presentes]

Uma boa listagem aumenta a probabilidade de o usuário seguir pelo ramo “Sim” e, no passo G, já ter uma noção do que esperar do App.

10. Erros típicos na listagem e na divulgação

Erro nº 1: nome e subtítulo prometem uma magia que não existe.
Escrever “Ultimate AI that does everything” é tentador, mas isso bate em duas frentes. O usuário espera um superassistente universal e recebe uma ferramenta especializada. A moderação do Store pode questionar: essas declarações correspondem ao comportamento real e à política? As diretrizes exigem formulações claras e precisas, sem exageros.

Erro nº 2: a descrição está lotada de detalhes técnicos.
“Usa MCP, Agents SDK, cache na camada edge” — ótimo para uma palestra no meetup, absolutamente inútil na listagem. Para o usuário, importam cenários e resultado: mais rápido, mais simples, mais confiável. Deixe os detalhes técnicos para o post “como fizemos”.

Erro nº 3: ignorar a localização da listagem.
O App localiza muito bem a UI e os dados, mas a listagem ficou em uma tradução automática ruim ou só em inglês para um mercado onde a maioria não lê inglês. Você perde conversão antes mesmo do primeiro uso. Melhor um ou dois idiomas com texto de qualidade do que dez com abobrinha.

Erro nº 4: ícone e visual feitos às pressas “no improviso”.
Detalhes complexos demais, texto ilegível num círculo pequeno, ou um ícone cinza que some no meio dos outros. O usuário simplesmente não lembra que era o seu App. Gaste algumas horas num ícone caprichado e capturas limpas: você ainda vai usá‑los por muito tempo em artigos, slides e redes sociais.

Erro nº 5: notas de versão no estilo “bug fixes and improvements”.
Sim, todo mundo escreve assim, mas você pode fazer melhor. Se nem você entender o que mudou na 1.3 daqui a um mês, o usuário muito menos. Descreva as mudanças pela ótica da utilidade: o que ficou mais rápido, o que ficou mais confiável, que novos cenários surgiram. Curto, mas concreto.

Erro nº 6: ausência de anúncio externo.
O App já está no Store, mas você não contou para ninguém. Sem post, sem videozinho, sem nota no blog. Resultado: seu App é visto só por usuários aleatórios na busca do Store. Mesmo um anúncio mínimo para colegas, seguidores ou comunidade rende as primeiras instalações e feedback para melhorar.

Erro nº 7: inconsistência entre a listagem e o comportamento real do App.
Na listagem diz que o App não armazena dados, mas a retenção está configurada de outro jeito. Ou promete idioma russo, mas na prática ainda está em beta e falha. Isso não só estraga as avaliações como pode gerar questionamentos do Store. Os textos da listagem devem acompanhar a arquitetura e as configurações de segurança, de que falamos nos módulos anteriores, e não viver vida própria.