Por qué tu plugin de WooCommerce o tu app de Shopify consigue instalaciones pero no usuarios de pago, y el procedimiento go-to-market que lo arregla

Publico mis propios plugins de WooCommerce bajo la marca plogins y veo el mismo patrón en mis estadísticas y en las herramientas que me enseñan agencias: el contador de instalaciones sube y el plan de pago no se mueve. La ficha consigue que alguien pulse Instalar. Después, nadie sabe si el usuario terminó la configuración, vio un resultado o borró el plugin esa misma tarde.

Esta guía es el procedimiento que uso para averiguar dónde se produce la caída y corregirla. Cubre plugins de WordPress.org y apps de la Shopify App Store a la vez, porque los problemas se parecen aunque las tiendas sean distintas. Cada límite que aparece abajo sale de la documentación de la propia plataforma, enlazada junto al dato. Donde una plataforma no documenta nada, lo digo.

Si llevas un plugin o una app como producto, o una agencia con herramientas propias, este es el trabajo de un ingeniero go-to-market: fichas, medición del onboarding y contenido que sigue a las versiones.

#Por qué mi plugin de WooCommerce tiene instalaciones pero ningún usuario de pago

Las instalaciones miden la ficha. Los usuarios de pago miden todo lo que ocurre después. Cuando las dos cifras se separan, el hueco está en uno de estos cuatro sitios:

1. La ficha atrae al lector equivocado. Las etiquetas, los términos de búsqueda o la descripción corta coinciden con una consulta cuya intención tu producto no cubre. Esas instalaciones se pierden porque el producto responde a otra pregunta.
2. La configuración es demasiado larga o confusa. El usuario activa el plugin, aterriza en una pantalla de ajustes con veinte campos y se va. En Shopify pasa lo mismo en la pantalla de la app incrustada en el administrador.
3. El primer resultado llega tarde. Un plugin de envíos que solo demuestra su valor cuando entra el siguiente pedido deja un hueco largo entre la instalación y el beneficio. Muchos usuarios desinstalan dentro de ese hueco.
4. La mejora de plan no tiene detonante. La edición gratuita resuelve el problema lo bastante bien y nada en el producto avisa al usuario de cuándo le ayudaría la edición de pago.

No se distinguen mirando el contador de instalaciones. Hacen falta unas pocas cifras, medidas igual antes y después de cada cambio. Ese es el primer paso del procedimiento, y la mayoría de los propietarios de plugins se lo salta.

#Qué debo medir antes de cambiar la ficha de un plugin

Apunta el estado actual antes de editar un solo campo. Sin una columna de “antes”, cualquier cambio posterior es una opinión. Yo llevo una tabla por producto y la relleno a intervalos fijos, por ejemplo las cuatro semanas previas a un cambio de ficha y las cuatro posteriores.

Esta es la plantilla. Las columnas Antes y Después están vacías a propósito: rellénalas con tus datos.

Tres reglas mantienen la tabla honesta:

• Fija la duración del periodo. Cuatro semanas contra cuatro semanas. Una ventana “después” más corta favorece al cambio.
• Cambia una sola cosa por periodo. Si reescribes la ficha y el onboarding en la misma semana, no sabrás cuál de los dos movió las cifras.
• Escribe la definición antes de leer el número. “Configuración completada” significa un estado guardado concreto. Decide primero cuál es ese estado y cuéntalo después.

La separación entre usuarios de pago y gratuitos en las filas de uso de funciones viene de Mat De Sousa, fundador de WideBundle, que recomendó medir el uso de funciones por separado para ambos grupos en una publicación en X del 2 de noviembre de 2026, junto con las desinstalaciones del mismo día, la finalización del onboarding y la retención. En su opinión, las funciones que usan de verdad los usuarios de pago indican qué vende el plan de pago. Coincido con esa separación y añadiría algo: si una función la usan mucho los usuarios gratuitos y poco los de pago, es candidata a detonante de la mejora de plan.

#Cómo relleno campo por campo la ficha de un plugin de WordPress.org

Una ficha de WordPress.org se genera a partir de tu readme.txt. Las reglas de abajo salen de la documentación del readme. La columna de la derecha es lo que reviso en mis propios readmes antes de cada versión.

La descripción corta carga con la mayor parte del peso porque aparece donde los usuarios comparan plugins. La escribo como una sola frase: qué hace el plugin por una tienda WooCommerce, con las palabras del dueño de la tienda. En plogins-customs eso significa aranceles, papeleo de aduanas y documentos de transportista, los términos que usa un comerciante que envía fuera de la UE, y no el nombre de un reglamento.

La descripción larga y la sección de preguntas frecuentes del readme son donde respondes a las dudas que bloquean la configuración. Paso al FAQ del readme cada pregunta que surgió en el foro de soporte, formulada como la hizo el usuario. Así los hilos de soporte se convierten en contenido de ficha y se acorta el camino del siguiente usuario hasta una configuración que funcione.

Para el lado del plugin en tiendas WooCommerce, tienes mi página de desarrollador WooCommerce.

#Cómo relleno campo por campo la ficha de una app en la Shopify App Store

Shopify documenta bastante más de la ficha que WordPress.org. Todas las cifras de esta tabla salen de las buenas prácticas de la Shopify App Store.

Otros dos puntos de la misma página cambian cómo planifico la ficha:

• Traducciones. Shopify afirma que las fichas traducidas convierten “hasta 4 veces mejor en mercados que no son de habla inglesa” (traducción propia) y que las fichas principales en inglés se traducen automáticamente a 8 idiomas: portugués de Brasil, danés, neerlandés, francés, alemán, chino simplificado, español y sueco. Escribo la ficha principal en inglés con frases cortas y literales para que la traducción automática tenga menos margen de error, y reviso a mano las versiones en alemán y en español. Si vendes a comerciantes españoles, lee la versión en español como la leería uno de ellos: un término de búsqueda traducido palabra por palabra rara vez coincide con lo que teclea un dueño de tienda en Madrid o Valencia.
• Rendimiento de la tienda. Shopify pide que las apps no reduzcan la puntuación de rendimiento de Lighthouse en más de 10 puntos. La puntuación pondera Inicio 17%, Detalle de producto 40% y Colección 43%. Si la app inyecta algo en el escaparate, mido esos tres tipos de página con la app y sin ella antes de enviarla a revisión.

Las capturas y el vídeo son donde el problema de onboarding de la primera sección se hace visible. Si no consigo una secuencia de capturas que vaya de la instalación al primer resultado en entre tres y seis imágenes, la configuración es demasiado larga, y arreglar las capturas no arregla el producto.

Si estás construyendo la app, mi página de desarrollador Shopify cubre la parte de implementación.

#Qué cambia la insignia Built for Shopify para una app

Built for Shopify es el único lugar donde Shopify afirma que algo afecta a la búsqueda. Según esa página, el estatus da:

• una insignia en la tarjeta de la app y un destacado en la ficha,
• un filtro de búsqueda y un impulso de posición en la búsqueda de la App Store,
• revisión prioritaria y segmentación en el plan de anuncios,
• derecho a optar a la primera colección de la portada y de las categorías y a la sección Picked for you, que Shopify describe como personalizada y no garantizada.

Los criterios abarcan seguridad y fiabilidad; rendimiento en el administrador y, para las apps que lo tocan, en el escaparate o el checkout; facilidad de uso; utilidad demostrada medida en instalaciones; número de reseñas y valoración en una ventana móvil; y una ficha completa. La app debe estar incrustada en el administrador de Shopify.

El proceso tiene consecuencias. Suspender tres veces seguidas el mismo criterio supone tres meses de suspensión de la solicitud. El estatus se revisa cada año, y una app que cae por debajo de un criterio dispone de 60 días para corregirlo.

Para planificar, trato los criterios como una lista de comprobación que coincide casi por completo con el trabajo de onboarding de más abajo. La “facilidad de uso” y la “utilidad demostrada” son difíciles de acreditar sin los eventos de configuración y primer resultado, así que primero instrumento y luego solicito. Solicitarlo pronto y suspender repetidamente el mismo criterio cuesta tres meses.

#Cómo instrumento el onboarding de un plugin para ver dónde se van los usuarios

Los paneles de las tiendas se detienen en la instalación y la desinstalación. Todo lo que ocurre entre esos dos eventos tiene que salir de tu propio producto. Envío cinco eventos, y los nombres de abajo son los que yo recomiendo, no un estándar de ninguna plataforma ni herramienta de analítica:

La definición de first_result es la decisión de diseño importante. En plogins-customs, un primer resultado es un documento de aduanas generado a partir de un pedido real. En una app de packs en Shopify podría ser el primer pack mostrado en la página de un producto. Escríbela por producto, porque el evento vale lo que vale esa definición.

Un esquema mínimo del lado de WordPress queda así. El endpoint y el nombre de la opción son marcadores de posición, y no se envía nada hasta que el dueño del sitio ha dado su consentimiento:

// Example only: endpoint and option name are placeholders.
function myplugin_track( string $event, array $props = [] ): void {
    if ( get_option( 'myplugin_telemetry_optin' ) !== 'yes' ) {
        return;
    }
    wp_remote_post( 'https://analytics.example.com/api/event', [
        'blocking' => false,
        'timeout'  => 2,
        'body'     => wp_json_encode( [
            'event'   => $event,
            'product' => 'myplugin',
            'version' => MYPLUGIN_VERSION,
            'props'   => $props,
        ] ),
        'headers'  => [ 'Content-Type' => 'application/json' ],
    ] );
}

add_action( 'myplugin_setup_saved', function () {
    myplugin_track( 'setup_completed', [ 'seconds_since_install' => time() - (int) get_option( 'myplugin_installed_at' ) ] );
} );

En un plugin gratuito pido el consentimiento en la pantalla de configuración, explico qué se envía y mantengo la carga libre de datos personales: sin correos y sin URL de tienda salvo que el usuario lo haya aceptado. En Shopify, el backend de la app ya conoce la tienda, así que los eventos se envían desde el servidor de la propia app.

Umami, PostHog y GA4 aceptan eventos personalizados. Elijo una herramienta por producto y me quedo con ella, porque cambiar de herramienta en mitad de una comparación antes/después la invalida. Cuando los cinco eventos fluyen, la tabla de medición de la segunda sección se rellena sola, y el embudo muestra cuál de los cuatro puntos de fallo de la primera sección te afecta.

Mat De Sousa añade otro argumento a favor de este trabajo en la misma publicación: según su experiencia, los comerciantes instalan apps competidoras en paralelo y se quedan con la más rápida de configurar. Si eso encaja con tu categoría, seconds_since_install en setup_completed es la cifra que debes vigilar.

#Cómo convierto las versiones de un plugin en contenido que atrae usuarios

La mayoría de los propietarios de plugins escribe un registro de cambios y se queda ahí. El changelog es exacto, breve y casi nadie lo lee. Las funciones que contiene son el mejor material para contenido, porque cada una resuelve un problema concreto que un dueño de tienda busca.

Para plogins publico un feed de funciones legible por máquinas en plogins.com/features.json. El archivo envuelve las entradas en un objeto con vendor, count y releases. Cada entrada de versión tiene plugin, name, edition, version, released, url, changelog, wpOrg y una lista features donde cada elemento tiene un kind (new, added o changed) y un text. Las correcciones y las notas de seguridad se dejan fuera a propósito: importan a los usuarios y su sitio es el changelog, pero no describen una capacidad nueva que alguien busque.

Esta es la entrada real de plogins-customs 1.3.0, publicada el 1 de noviembre de 2026, recortada a dos de sus cinco funciones:

{
  "plugin": "plogins-customs",
  "name": "Customs",
  "edition": "free",
  "version": "1.3.0",
  "released": "2026-11-01",
  "url": "https://plogins.com/plogins-customs/",
  "changelog": "https://plogins.com/plogins-customs/changelog/",
  "wpOrg": "https://wordpress.org/plugins/plogins-customs/",
  "features": [
    {
      "kind": "added",
      "text": "Customs Paperwork. Generate printable Commercial Invoice and Customs Declaration (CN22/CN23) slips directly from the WooCommerce order edit screen and order list."
    },
    {
      "kind": "added",
      "text": "Store EORI number setting under WooCommerce > EU Import Duty (Union Customs Code, Reg. (EU) No 952/2013, Art. 9), automatically printed on declarations and carrier export documents."
    }
  ]
}

El procedimiento que convierte una entrada así en contenido:

1. Lee el feed después de cada versión. Mi flujo de prensa recoge las entradas nuevas y lista las funciones que todavía no se han usado en ningún artículo.
2. Asocia cada función a un problema. “Customs Paperwork” responde a la pregunta del comerciante sobre qué documentos necesita un paquete que sale de la UE. El ajuste del EORI responde a dónde debe figurar el número EORI.
3. Busca el artículo que ya cubre ese problema. Si existe, la función entra en ese artículo como un párrafo con un enlace al plugin. Si no existe, el problema se convierte en un artículo nuevo.
4. Escríbelo en cada idioma que sirve el sitio. Publico en seis idiomas, así que la función aterriza en seis artículos, cada uno escrito para los lectores y las normas de los países de ese idioma.
5. Enlaza de vuelta desde el plugin. La página del propio plugin y el FAQ del readme enlazan al artículo que explica el problema, de modo que quien llega desde el buscador y quien llega desde el plugin se encuentran con la misma explicación.

El formato del feed importa por dos motivos. Un script puede leerlo, así que el paso de la versión al borrador no depende de que alguien se acuerde. Y como cada función es una frase con un kind, veo de un vistazo qué versiones añadieron algo digno de escribirse y cuáles solo cambiaron un comportamiento.

Si quieres este flujo integrado en tu propio proceso de versiones y en tu sistema de contenidos, forma parte de lo que monto como ingeniero go-to-market. La parte de automatización, ganchos de versión y tareas programadas, está cerca del trabajo de mi página de automatización de procesos de negocio.

#Puede un competidor copiar mi app de Shopify o mi plugin de WooCommerce

Según Mat De Sousa, en la misma publicación, las apps que son solo una capa visual sobre la tienda se copian con facilidad. Propone dos añadidos más difíciles de copiar: una capa de servicio, en la que el proveedor configura la app para el comerciante, y una capa de datos, como tests A/B y analítica que muestran al comerciante qué cambió la app.

Mi propio trabajo respalda la mitad de la capa de datos desde el lado del cliente. Desde 2019 ejecuto tests A/B, recomendaciones y contenido dinámico en Dynamic Yield para clientes de comercio electrónico. Los comerciantes que ven un resultado de test ligado a sus propias preguntas de ingresos piden el siguiente test. Un comerciante que solo ve un widget pregunta si existe un widget más barato.

Para el propietario de un plugin o de una app, la versión práctica es pequeña:

• Capa de servicio. Ofrece una sesión de configuración o una configuración hecha por ti dentro del plan de pago, y hazla visible en la ficha y en la pantalla de configuración. En plogins-customs, el equivalente son los ajustes de arancel y origen rellenados de antemano para el catálogo de un comerciante.
• Capa de datos. Muestra al comerciante dentro del producto una cifra que demuestre que el plugin funcionó: documentos generados, líneas de arancel añadidas, correos entregados. Esa cifra es también el evento first_result de la sección anterior.

Mat De Sousa recomienda además adoptar rápido las funciones nuevas de Shopify. Lo leo también como un argumento de ficha: una capacidad nueva de la plataforma que tu app admite desde el primer día es un término de búsqueda nuevo, una captura nueva y una línea de función nueva.

#Recomienda Shopify Sidekick apps de la App Store

La página de ayuda de Sidekick documenta que Sidekick puede generar apps personalizadas, crear flujos de Shopify Flow y ejecutar tareas de varios pasos. La página no dice que Sidekick recomiende apps de la App Store.

Mat De Sousa lo describe de otra forma, a partir de su propio uso: según su relato, Sidekick convierte la pregunta de un comerciante en palabras clave y devuelve de 3 a 5 apps bien posicionadas. Es una observación suya, y Shopify no la ha documentado.

Dos conclusiones valen con cualquiera de las dos lecturas. Si su descripción es correcta, las apps que se posicionan bien en la búsqueda normal de la App Store son las que muestra Sidekick, así que el trabajo de ficha de arriba se aplica dos veces. Si Sidekick genera una app personalizada para una necesidad simple, una app que solo cubre esa necesidad compite con una alternativa generada gratis, y eso te devuelve a las capas de servicio y de datos. Hasta que Shopify documente el comportamiento de recomendación, no planifico ningún lanzamiento en torno a él.

#Qué no documentan WordPress.org ni la Shopify App Store sobre el ranking

Ninguna de las dos plataformas publica los pesos de su ranking de búsqueda. La página del readme de WordPress.org explica cómo se muestran y filtran las etiquetas y las descripciones. Las buenas prácticas de Shopify explican cómo rellenar cada campo, y la página de Built for Shopify dice que el estatus da un impulso de posición en la búsqueda. Ninguna de esas páginas dice cuánto pesa cada campo, reseña o cifra de instalaciones.

La ponderación de Lighthouse de la página de buenas prácticas de Shopify (Inicio 17%, Detalle de producto 40%, Colección 43%) describe cómo combina Shopify la puntuación de rendimiento entre tipos de página. Es una medida de rendimiento, y ninguno de los tres documentos la vincula con la posición en la búsqueda.

Esto condiciona cómo hablo de resultados:

• No prometo una posición en el ranking a nadie, y eso me incluye a mí.
• Mido lo que puedo definir: visitas a la ficha, instalaciones, configuración completada, primer resultado, mejoras de plan.
• Cuando a un cambio de ficha le siguen más instalaciones, lo cuento como un cambio en el mismo periodo, con los valores de antes y después, y mantengo iguales las duraciones de los periodos.

#Puedo enviar correos de seguimiento a los usuarios que han instalado mi plugin

Los mensajes que forman parte del servicio, como una clave de licencia, la confirmación de una configuración o un aviso de seguridad sobre el plugin, son parte de operarlo. El seguimiento comercial a una persona es otro caso, y está regulado.

En España lo regula el artículo 21 de la Ley 34/2002, de servicios de la sociedad de la información y de comercio electrónico (LSSI-CE). Prohíbe enviar comunicaciones publicitarias o promocionales por correo electrónico u otro medio de comunicación electrónica equivalente que el destinatario no haya solicitado antes o autorizado expresamente. La excepción es estrecha: se aplica cuando existe una relación contractual previa, los datos de contacto se obtuvieron de forma lícita y el mensaje trata de productos o servicios propios similares a los contratados. En todo caso, debes ofrecer un procedimiento sencillo y gratuito para oponerse, tanto al recoger los datos como en cada comunicación, y en un correo eso exige incluir una dirección electrónica válida donde ejercer ese derecho. La Agencia Española de Protección de Datos (AEPD) es la autoridad a la que acudir para el tratamiento de datos personales que acompaña a estos envíos. Detrás está el artículo 13 de la Directiva 2002/58/CE sobre privacidad y comunicaciones electrónicas, que fija la misma regla de consentimiento en toda la UE.

En la práctica, para un usuario de un plugin gratuito que nunca ha comprado nada, pido el consentimiento al registrarse con una casilla sin marcar y una descripción clara de lo que va a recibir. Para un cliente de pago, la excepción de la relación contractual previa puede cubrir productos similares, siempre que la opción de oposición estuviera desde el primer contacto.

Uso Mautic a diario en una plataforma de suscripción, y la configuración que funciona es sencilla: un segmento por producto y plan, construido con los mismos eventos install, setup_completed y upgrade, y correos disparados por lo que el usuario hizo o dejó de hacer. Quien instaló pero nunca disparó setup_completed recibe un mensaje sobre el único ajuste que bloquea la configuración. Quien llegó a first_result no recibe nada sobre la configuración. Así los correos son cortos y relevantes, y los segmentos y la tabla de medición leen de un único flujo de eventos.

#En qué orden trabajo un plugin o una app que se estanca tras la instalación

Esta es la secuencia que sigo en mis productos y que recomiendo para cualquier plugin o app con instalaciones y sin usuarios de pago:

1. Semana 1: medir. Define los cinco eventos y la condición de first_result, publica el seguimiento con consentimiento y rellena la columna Antes de la tabla de medición con el panel de la tienda y tu analítica.
2. Semana 2: ficha. Recorre la lista de comprobación campo por campo de tu plataforma. Corrige etiquetas, descripción corta, términos de búsqueda, capturas y lista de funciones según los límites documentados. No cambies nada del producto todavía.
3. Semanas 3 a 6: leer el embudo. Deja que los eventos recojan un periodo completo. Localiza el paso con mayor caída: configuración iniciada, configuración completada o primer resultado.
4. Semana 7: corregir la mayor caída. Acorta la configuración, rellena valores por defecto o acerca el primer resultado a la instalación. Un solo cambio.
5. Semanas 7 a 10: medir de nuevo. Rellena la columna Después con un periodo de la misma duración.
6. En cada versión: contenido. Añade la versión al feed de funciones, asocia cada función nueva a un problema y a un artículo, y actualiza las líneas de función de la ficha.
7. Cuando el embudo se estabiliza: seguimiento. Monta las secuencias de correo con consentimiento sobre los mismos eventos.

En Shopify, solicita Built for Shopify después del paso 5, cuando puedas mostrar cifras de configuración y utilidad en lugar de esperar a que la revisión las encuentre.

#Qué hago ahora para empezar

Toma la tabla de medición de este artículo, rellena la columna Antes de tu plugin o app con los datos de las últimas cuatro semanas y envíamela junto con el enlace a tu ficha de WordPress.org o de la Shopify App Store a través de la página del ingeniero go-to-market. Te devolveré una revisión de la ficha campo por campo frente a los límites documentados y el paso de onboarding que instrumentaría primero.