Listado y promoción: contenido, localización, notas de versión

1. El listado como parte del producto, no «un formulario para cumplir»

Un desarrollador que llega por primera vez a la Store a menudo percibe el listado como «otro formulario largo que hay que rellenar con algo». Es como escribir el README del repo a las tres de la madrugada: «luego lo reescribo bien». Spoiler: normalmente no se reescribe.

Para ChatGPT App, el listado es lo primero, y a veces lo único, que verá el usuario antes de pulsar «Try» o pasar de largo. El nombre, el subtítulo, la descripción corta, la lista de escenarios, el icono: todo funciona como un mini‑landing.

Además, el listado influye no solo en las personas, sino también en el propio ChatGPT. Los metadatos (nombre, categorías, descripción) participan en los mecanismos de descubrimiento. Cuando el modelo elige qué App sugerir al usuario para una consulta, también se apoya en los textos que has escrito aquí.

Las directrices oficiales exigen que el nombre y la descripción del App sean claros, precisos y no induzcan a error respecto a la funcionalidad. Nada de «somos una IA mágica que lo hace todo» ni «cliente oficial de X» si no se corresponde con la realidad.

Es decir, en este paso haces tres cosas a la vez:

1. Explicas a una persona por qué tu App existe en absoluto.
2. Das pistas a los algoritmos de la Store y de ChatGPT sobre en qué situaciones es pertinente sugerir el App.
3. Sientas la base de la confianza: prometes exactamente lo que realmente haces, sin magia ni dark patterns.

2. Estructura del listado de ChatGPT App

La interfaz concreta de la Store puede cambiar campos y apariencia, pero el armazón lógico casi siempre es el mismo. De lo que hoy suele pedirse para un ChatGPT App con widget de UI:

Recuerdo desde el inicio de la lección: las directrices exigen que los nombres y descripciones sean claros y honestos, sin intentar hacerse pasar por «cliente oficial de algo». En la tabla anterior está desglosado por campos concretos del listado.

Todo esto parece un poco burocrático hasta que te pones en el lugar del usuario. Abres la Store, ves un montón de tarjetas, tienes cinco segundos de atención. Mirando GiftGenius, quieres entender al instante:

• ¿este App trata de mis tareas?
• ¿es seguro y no hará cosas raras con mis datos?
• ¿es diferente a un diálogo normal con ChatGPT?

Las respuestas a estas preguntas debe darlas tu listado.

3. Nombre y subtítulo: cómo no dispararte en el pie

Criterios de un buen nombre

El nombre del App tiene varias funciones a la vez: se pronuncia en conversación («activa GiftGenius»), se teclea en la búsqueda, se ve en la lista. Por eso, el nombre ideal:

• es corto y memorable;
• transmite la idea principal (GiftGenius → «algo sobre regalos y “inteligencia”»);
• no infringe marcas registradas ajenas;
• no promete imposibles ni se hace pasar por cliente oficial de una plataforma ajena.

Las mismas directrices de OpenAI de las que hablamos al principio prohíben explícitamente nombres engañosos, incluidas insinuaciones de oficialidad que no tienes.

Veamos ejemplos para nuestro GiftGenius.

En este curso seguimos usando GiftGenius como nombre principal. Si haces tu propio App, no temas un branding ligero: «TripTailor», «StockScout», «LegalChecklist», etc.

Subtítulo: una sola frase que lo resuelve todo

El subtítulo es tu «one-liner». Se ve en los resultados de la Store y en la página del App. Las directrices oficiales recomiendan que estos textos expliquen con claridad y honestidad la finalidad del App.

Mala opción:

"¡El asistente de IA ideal para cualquier tarea!"

Buena opción:

"Ayuda a elegir un regalo por los intereses de la persona directamente en el chat en 30 segundos."

Un buen subtítulo:

• dice qué resultado obtendrá el usuario;
• sugiere el contexto (en nuestro caso — «directamente en el chat»);
• no entra en detalles técnicos («analiza vectores de embedding» no le interesa a nadie).

Para practicar, es útil escribir 5–7 variantes y releerlas con ojos de alguien no técnico. Si tú mismo te trabas al leerlo en voz alta, reescríbelo.

4. Descripción: corta y larga, antes/después

Descripción corta

La descripción corta suele constar de un par de frases y se muestra junto al subtítulo. A menudo es tu última oportunidad de captar al usuario al que le da pereza abrir detalles.

Estructura:

1. Primera frase: qué hace el App.
2. Segunda: en qué se diferencia de ChatGPT «a pelo» u otros Apps.

Ejemplo «antes» para GiftGenius:

"App para elegir regalos. Usa MCP y un backend complejo para ofrecer los mejores resultados."

Problemas:

• detalles técnicos de más;
• no se entiende en qué eres mejor que usar ChatGPT sin más;
• no se describe el escenario de usuario.

Reescritura:

"GiftGenius ayuda a elegir un regalo según los intereses de la persona, el presupuesto y la ocasión. Respondes un par de preguntas en el chat y el App muestra ideas concretas con enlaces."

Aquí nos anclamos a la experiencia real del usuario: «respondo preguntas → veo ideas». Ese texto además ayuda a ChatGPT a entender mejor tus escenarios típicos.

Descripción larga

La descripción larga la leen personas ya motivadas, pero ni siquiera ellas quieren un tratado técnico. Buena plantilla:

1. Quién es la audiencia objetivo (por ejemplo, «personas que odian elegir regalos a última hora»).
2. Qué tareas resuelve el App (2–3 escenarios principales).
3. En qué es más cómodo el App que preguntar a ChatGPT sin App.
4. Qué pasa con los datos y la seguridad — muy breve, remitiendo a la Policy.
5. Idiomas/regiones si hay limitaciones.

Para GiftGenius, ejemplo de plantilla:

GiftGenius — para quienes siempre se acuerdan del regalo a última hora. 
El App pregunta para quién eliges el regalo, cuál es tu presupuesto y por qué ocasión, y luego muestra una lista de ideas con descripciones y enlaces.

A diferencia de un diálogo normal con ChatGPT, GiftGenius usa tu catálogo de productos y precios actualizados, y recuerda el historial de selecciones dentro de la conversación.

El App no guarda tu conversación más tiempo del necesario para preparar las recomendaciones. Más detalles — en nuestra Política de privacidad.

Lo principal: no conviertas la descripción en un vertedero de términos de arquitectura. Bajo el capó habrá MCP, Agents, caché, feature flags, pero al usuario le importa el escenario: más rápido, más fácil, más fiable.

5. Capturas, vídeo, icono y visual exterior

Ya resolvimos los textos del listado. Ahora — lo que el usuario ve, no lo que lee: el icono, posibles capturas y un vídeo corto.

Dónde se ve el visual para ChatGPT App

A fecha de 2025–2026, las interfaces de ChatGPT Store para GPTs normales no muestran el carrusel de capturas típico de las tiendas móviles: básicamente hay icono, nombre, autor y sugerencias iniciales.

Para ChatGPT Apps con widgets de UI la situación es similar: el principal «escaparate» está dentro del propio ChatGPT (primer arranque del App, widget inline, etc.). Las capturas externas, vídeos y el diseño visual amplio suelen vivir:

• en un landing independiente del App;
• en posts y anuncios («cómo hicimos GiftGenius»);
• en sitios como Product Hunt, README de GitHub, etc.

Por eso, cuando hablamos de «capturas y vídeo para el listado», en la práctica nos referimos a recursos externos adonde llevarás a la gente desde la Store, la documentación o redes sociales.

Icono del App

El icono parece poca cosa hasta que lo ves en una lista con decenas de apps. Principios básicos:

• forma simple que se lea en un círculo pequeño (128×128);
• texto al mínimo, mejor sin texto;
• buena relación de contraste con el fondo;
• vínculo visual con el tema del App (regalo, carrito, análisis de gráficos, etc.).

Para GiftGenius, lo lógico — una caja de regalo minimalista sobre fondo de contraste, sin poner «GG» en tipografía diminuta.

Capturas: qué mostrar exactamente

Cuando haces un landing o un artículo sobre el App, necesitas capturas que muestren:

• el escenario principal: el usuario hace una pregunta → aparece el widget con recomendaciones;
• el «momento vistoso»: filtrado, elección de opción, quizá integración con Instant Checkout (si existe);
• el mínimo de detalles extra: sin PII, cuentas de prueba en lugar de compradores reales, interfaz limpia.

Un truco práctico: preparar un «catálogo demo» aparte con productos ficticios y nombres limpios, para no exponer identificadores internos ni marcas ajenas.

Vídeo corto

Un walkthrough de 30–60 segundos se puede grabar con un simple screencaster: abrir ChatGPT, teclear una consulta típica, mostrar cómo aparece el App y cómo se interactúa con él. Básicamente, reproduces uno de tus golden prompts del módulo de UX.

Guion para GiftGenius:

1. El usuario escribe: «Necesito un regalo para un compañero desarrollador, presupuesto $50».
2. ChatGPT sugiere GiftGenius.
3. Aparece el widget con preguntas de aclaración y luego — la lista de opciones.

Ese vídeo sirve perfecto tanto para el landing como para un post en redes.

6. Localización del listado: estrategias y escollos

Del visual a los idiomas. Incluso si la UI y los datos ya están muy bien localizados (como vimos en el módulo 9), el listado va por libre y aquí hay trampas.

Por qué no es tan sencillo

Tu App puede localizar de maravilla la UI y los datos, usar openai/locale, _meta["openai/userLocation"] y otros trucos del módulo 9. Pero el listado va por su cuenta.

A fecha de 2025–2026, ChatGPT Store no cambia automáticamente el nombre y la descripción del App según el idioma de la interfaz del usuario. No hay un mecanismo «integrado» de metadatos multilingües: la Store muestra un único conjunto de textos.

De aquí se derivan tres estrategias populares.

Estrategia 1: Universal English

La opción más simple y extendida: toda la descripción y el nombre en inglés. En el texto se puede indicar qué idiomas soporta el App:

"Supports English, Spanish, Russian."

Ventajas: un único listado, fácil de mantener, comprensible para la mayoría de la audiencia técnica. Inconveniente evidente: peor conversión entre usuarios que no leen inglés con comodidad.

Estrategia 2: nombre híbrido

Intento de sentarse en dos sillas: «GiftGenius | Regalos». Ese nombre lo leen usuarios angloparlantes e hispanohablantes.

Ventaja: más gente entiende intuitivamente de qué trata el App. Inconvenientes: se ve «ruidoso», puede estropear el estilo general de la Store y no resuelve la descripción larga — habrá que elegir un idioma.

Estrategia 3: apps separadas por idioma

Variante para proyectos grandes: crear, por ejemplo, «GiftGenius (RU)» y «GiftGenius (Global)» como Apps distintos con el mismo backend MCP.

Ventajas:

• puedes adaptar por completo la descripción, las sugerencias iniciales e incluso el flujo al mercado local;
• mejor «SEO» dentro de la Store: un usuario que escribe en su idioma verá un nombre y una descripción comprensibles.

Inconvenientes:

• las estadísticas de uso y las reseñas se reparten entre varios Apps;
• más trabajo de mantenimiento: releases, listados, revisiones para cada variante.

Consejo práctico

Para un App de aprendizaje/proof‑of‑concept suele bastar con Universal English, sobre todo si la audiencia principal son desarrolladores. En un producto real, un compromiso razonable es empezar con uno o dos idiomas y hacer buenas traducciones, en lugar de intentar salir en diez con «ensalada» de traducción automática.

La relación con el módulo de localización es esta: ya sabes localizar UI y datos con flexibilidad. Ahora solo necesitas que los textos del listado no contradigan lo que realmente verá el usuario. No escribas «solo soporta inglés» si el App ya funciona sin problemas en español.

7. Notas de versión: por qué hacen falta y cómo evitar el «hemos mejorado todo»

El listado es el momento del primer encuentro. Luego el App evolucionará y hay que contárselo a los usuarios: aquí entran las notas de versión.

Qué son las notas de versión en el contexto de ChatGPT App

Las notas de versión son una descripción breve de los cambios en la nueva versión del App: qué se añadió, qué se corrigió, qué se aceleró. En tiendas clásicas hay una pestaña específica «Version history». En la Store actual de ChatGPT puede que no exista, por lo que las notas de versión viven:

• en la descripción de la nueva versión en la consola de la Store;
• en tu web/blog/repositorio;
• dentro del propio App, si permites que el usuario pregunte «qué hay de nuevo».

El formato suele ser simple: nombre de versión, fecha y lista de cambios clave.

Por qué merece la pena dedicarles tiempo

Primero, el usuario ve que el App está vivo: se le dedica atención, se mejora, se corrigen errores. Eso aumenta la confianza en tu código y en tu negocio.

Segundo, tienes una cronología: es cómodo ver cuándo añadiste una función y referenciarlo en soporte o «vender» actualizaciones dentro de la empresa.

Tercero, las notas de versión son material listo para mini‑promoción: un correo, un post en redes, un vídeo corto.

Cómo escribir: vende el beneficio, no las entidades internas

La experiencia en tiendas móviles y las recomendaciones de producto se resumen en una idea simple: describe cambios desde la óptica del beneficio para el usuario, no de las entidades internas que tocaste.

Mal:

"v1.1 — refactor del algoritmo de selección, scoring mejorado, bugs arreglados."

Mejor:

"v1.1 — regalos más precisos para personas con aficiones poco comunes. 
Ahora GiftGenius entiende mejor los intereses si mencionas juegos de mesa, manualidades o música. 
También corregimos un error raro que a veces vaciaba la lista de recomendaciones."

Aquí incluso el bugfix se formula como mejora de fiabilidad para el usuario.

Ejemplos para GiftGenius

Primer release:

v1.0 — lanzamiento de GiftGenius
- Primeras selecciones de regalos por nombre, intereses y presupuesto.
- Soporte USD/EUR.
- Localización de la interfaz: EN, RU.

Segundo release:

v1.1 — regalos por foto y filtros por tipo
- Añadimos una herramienta experimental: puedes subir una foto del escritorio de la persona y GiftGenius sugerirá ideas acordes.
- Nuevo filtro "solo regalos digitales" — útil si la persona está en otra ciudad.
- Aceleramos la búsqueda en el catálogo, la lista de recomendaciones se abre más rápido.

Este formato se convierte fácilmente en texto para la Store y en un post breve «qué hay de nuevo en GiftGenius».

8. Mini plan de promoción: cómo parecer un poco marketer

Ni el listado perfecto ni las notas de versión cuidadas traerán usuarios por sí solas. Hace falta al menos un plan mínimo de promoción que pueda ejecutar un desarrollador.

El marketing completo es otro curso, pero sin promoción incluso el mejor App en la Store cogerá polvo. Necesitamos un conjunto mínimo de acciones que realmente puedas hacer como dev.

«Promoción» interna en el ecosistema de ChatGPT

Lo primero y principal: un listado bien escrito ya es parte de la promoción. Los metadatos y descripciones ayudan a ChatGPT a sugerir tu App en diálogos relevantes, y la búsqueda de la Store a encontrarlo por palabras clave.

De aquí se derivan pasos prácticos:

• mencionar escenarios típicos en la descripción (compra de regalos, preparación de informes, etc.);
• no saturar el listado con jerga técnica — solo espanta al usuario;
• evitar declaraciones demasiado amplias «para todo y para todos», para no diluir el «SEO».

Promoción externa: landing, redes, comunidad

Los estudios sobre el tema recomiendan un plan mínimo sencillo para ChatGPT Apps:

1. Hacer un vídeo breve de preview (30–60 segundos) que muestre el escenario clave.
2. Escribir una nota/artículo en el blog: «Cómo hicimos GiftGenius» — con un par de capturas y una descripción de arquitectura a alto nivel.
3. Publicar 1–2 posts en redes (Twitter/X, LinkedIn, Telegram) con enlace al App o al landing.
4. Pedir a 5–10 colegas/amigos que prueben el App y den feedback honesto.

Importante no convertirse en spammer: nada de «mencionar a todos en un tuit» ni «escribir a todos los chats». Buena regla: cada post debe aportar valor real (demo, explicación de arquitectura, caso interesante).

Dónde publicar las notas de versión

Como ya comentamos, puede que en la Store no exista el historial de versiones. Entonces, conviene duplicar las notas de versión:

• en la página del App en la Store (si ahí se puede añadir texto sobre la nueva versión);
• en tu web (sección Changelog);
• en el README del repositorio (si el App es open‑source o parcialmente abierto);
• en la newsletter o canal para usuarios interesados.

Aquí es cómodo usar la misma estructura «en bruto», definida en código o config, y luego renderizarla en distintos canales.

Ejemplo sencillísimo en TypeScript:

// shared/releaseNotes.ts
export const releaseNotes = [
  {
    version: "1.0.0",
    date: "2025-02-01",
    changes: [
      "Primer lanzamiento público de GiftGenius",
      "Selección de regalos por intereses y presupuesto",
    ],
  },
  {
    version: "1.1.0",
    date: "2025-03-10",
    changes: [
      "Nuevo filtro «solo regalos digitales»",
      "Búsqueda de catálogo acelerada",
    ],
  },
];

Este array se puede usar tanto en el widget (respuesta a «qué hay de nuevo?») como para generar la página de Changelog en tu web.

9. Imagen completa: el listado de GiftGenius como ejemplo

Para conectar todo, hagamos un listado «borrador» para nuestro App de práctica.

Versión textual

Nombre:
GiftGenius

Subtítulo:
Elige regalos en 30 segundos según intereses y presupuesto, directamente en el chat.

Descripción corta:
GiftGenius hace algunas preguntas sobre la persona, el presupuesto y la ocasión y muestra una lista preparada de ideas con descripciones y enlaces. Ideal cuando falta una noche para la celebración.

Descripción larga (versión abreviada):

GiftGenius ayuda a quienes están cansados de romperse la cabeza con los regalos a última hora. 
El App pregunta para quién eliges el regalo, qué le interesa a la persona y cuál es tu presupuesto, 
y luego muestra ideas concretas con una breve descripción y un enlace para comprarlas.

GiftGenius tiene en cuenta tu catálogo de productos y los precios actuales, por lo que las recomendaciones están más cerca del mundo real 
que un consejo genérico en el chat.

El App soporta interfaces en inglés y ruso. 
No usamos tus datos para entrenar modelos de terceros y guardamos el historial de selecciones solo dentro de una sesión. 
Más detalles — en nuestra Política de privacidad.

Sugerencias iniciales:

• «Help me find a birthday gift for a colleague who loves board games, budget $40.»
• «Elige un regalo para mi madre, a la que le gusta la jardinería, hasta 3000 ₽.»
• «Suggest digital-only gifts for a friend who lives abroad, budget €50.»

Icono: caja de regalo minimalista en colores corporativos.

Idiomas: EN, RU (indicado explícitamente en la descripción, y la UI ya sabe cambiar según openai/locale).

Enlaces:
Privacy Policy, Terms of Use, Support page — todo esto lo hicimos en la lección anterior.

Esquema: recorrido del usuario desde el listado hasta el uso

Para mayor claridad — un diagrama pequeño:

flowchart TD
    A[Listado de GiftGenius en la Store] --> B[El usuario lee
el nombre y la descripción]
    B --> C{¿Entiende
el valor del App?}
    C -- Sí --> D[Hace clic en Try / conecta el App]
    C -- No --> E[Pasa de largo]
    D --> F[Primer diálogo con ChatGPT]
    F --> G[El modelo sugiere GiftGenius
según el contexto de la solicitud]
    G --> H[Aparece el widget
y el flujo de selección de regalos]

Un buen listado aumenta la probabilidad de que el usuario siga la rama «Sí» y que en el paso G ya entienda aproximadamente qué esperar del App.

10. Errores típicos en listado y promoción

Error Nº 1: el nombre y el subtítulo prometen una magia que no existe.
Es tentador escribir «Ultimate AI that does everything», pero golpea por dos frentes. El usuario espera un superasistente universal y obtiene una herramienta especializada. La moderación de la Store puede cuestionarlo: si esas afirmaciones se corresponden con el comportamiento real y la política. Las guías exigen formulaciones claras y precisas sin exageraciones.

Error Nº 2: la descripción está abarrotada de detalles técnicos.
«Usa MCP, Agents SDK, caché en el edge» — todo eso es genial para una charla en un meetup, pero completamente inútil en el listado. Al usuario le importan los escenarios y el resultado: más rápido, más simple, más fiable. Deja los detalles técnicos para el post «cómo lo hicimos».

Error Nº 3: ignorar la localización del listado.
El App localiza muy bien la UI y los datos, pero el listado se deja con mala traducción automática o solo en inglés para un mercado donde la mayoría no lee inglés. Pierdes conversión incluso antes del primer arranque del App. Mejor uno o dos idiomas con buen texto que diez con galimatías.

Error Nº 4: icono y visual hechos a última hora «sobre la marcha».
Demasiados detalles, texto ilegible en un círculo pequeño, o un icono gris que se pierde entre otros. El usuario simplemente no recuerda que era tu App. Dedica un par de horas a un icono cuidado y capturas claras: las usarás mucho tiempo en artículos, slides y redes.

Error Nº 5: notas de versión al estilo «bug fixes and improvements».
Sí, todo el mundo lo pone, pero tú puedes hacerlo mejor. Si tú mismo dentro de un mes no entiendes qué cambió en la versión 1.3, el usuario menos aún. Describe los cambios en términos de beneficio: qué es más rápido, qué es más fiable, qué escenarios nuevos aparecieron. Corto, pero concreto.

Error Nº 6: ausencia de anuncio externo.
El App ya está en la Store, pero no se lo contaste a nadie. Ni post, ni vídeo corto, ni entrada en el blog. Al final tu App solo lo ven usuarios aleatorios en los resultados de la Store. Incluso un anuncio mínimo para colegas, seguidores o comunidad te da las primeras instalaciones y feedback con el que mejorar.

Error Nº 7: falta de coherencia entre el listado y el comportamiento real del App.
En el listado dice que el App no guarda datos, pero la lógica de retención está configurada de otro modo. O se promete un idioma que en realidad está en beta y falla. Esto no solo empeora reseñas, también puede motivar reclamaciones por parte de la Store. Los textos del listado deben seguir a la arquitectura y la configuración de seguridad — de las que hablamos en módulos anteriores — y no vivir por su cuenta.