Porque é que o seu plugin WooCommerce ou a sua app Shopify tem instalações mas não tem utilizadores pagantes, e o procedimento de go-to-market que resolve o problema

Lanço os meus próprios plugins WooCommerce sob a marca plogins e vejo o mesmo padrão nas minhas estatísticas e nas ferramentas que as agências me mostram: o número de instalações sobe, o plano pago fica parado. A ficha leva as pessoas a clicar em «Instalar». Depois disso, ninguém sabe se o utilizador concluiu a configuração, viu um resultado ou apagou o plugin na mesma tarde.

Este guia é o procedimento que uso para descobrir onde está a quebra e corrigi-la. Cobre plugins do WordPress.org e apps da Shopify App Store lado a lado, porque os problemas se parecem, mesmo que as lojas sejam diferentes. Cada limite abaixo vem da documentação da própria plataforma, com a ligação junto ao facto. Onde a plataforma não documenta nada, digo-o.

Se gere um plugin ou uma app como produto, ou uma agência com ferramentas próprias, este é o trabalho de um engenheiro go-to-market: fichas, medição do onboarding e conteúdo que acompanha as versões.

#Porque é que o meu plugin WooCommerce tem instalações mas não tem utilizadores pagantes

As instalações medem a ficha. Os utilizadores pagantes medem tudo o que acontece depois. Quando os dois números se afastam, a falha está num de quatro sítios:

1. A ficha atrai o leitor errado. As etiquetas, os termos de pesquisa ou a descrição curta correspondem a uma pesquisa cuja intenção o seu produto não serve. Essas instalações desaparecem, porque o produto responde a outra pergunta.
2. A configuração é demasiado longa ou confusa. O utilizador ativa o plugin, chega a uma página de definições com vinte campos e sai. Na Shopify acontece o mesmo no ecrã da app integrada no painel de administração.
3. O primeiro resultado chega tarde. Um plugin de envios que só prova o seu valor quando entra a encomenda seguinte deixa um longo intervalo entre a instalação e o valor. Muitos utilizadores desinstalam dentro desse intervalo.
4. A subida de plano não tem gatilho. A edição gratuita resolve o problema o suficiente e nada no produto diz ao utilizador quando a edição paga ajudaria.

Não se distinguem estes quatro casos olhando para o número de instalações. São precisos alguns números, medidos sempre da mesma forma antes e depois de cada alteração. É o primeiro passo do procedimento e a maioria dos donos de plugins salta-o.

#O que devo medir antes de alterar a ficha de um plugin

Registe o estado atual antes de editar um único campo. Sem uma coluna «Antes», qualquer alteração posterior é uma opinião. Mantenho uma tabela por produto e preencho-a a intervalos fixos, por exemplo nas quatro semanas anteriores a uma alteração da ficha e nas quatro seguintes.

Aqui fica o modelo. As colunas Antes e Depois estão vazias de propósito: preencha-as com os seus dados.

Três regras mantêm a tabela honesta:

• Fixe a duração do período. Quatro semanas contra quatro semanas. Uma janela «depois» mais curta favorece a alteração.
• Altere uma coisa por período. Se reescrever a ficha e o onboarding na mesma semana, não saberá qual dos dois mexeu nos números.
• Escreva a definição antes de ler o número. «Configuração concluída» significa um estado guardado concreto. Decida primeiro qual é esse estado e só depois conte.

A separação entre pagantes e gratuitos nas linhas de adoção vem de Mat De Sousa, fundador da WideBundle, que recomendou acompanhar a adoção de funcionalidades separadamente nos dois grupos num post no X de 2 de novembro de 2026, a par das desinstalações no próprio dia, da conclusão do onboarding e da retenção. Na opinião dele, as funcionalidades que os pagantes realmente usam dizem-lhe o que o plano pago vende. Concordo com a separação e acrescento uma coisa: se uma funcionalidade é muito usada por utilizadores gratuitos e raramente por pagantes, é candidata a gatilho de subida de plano.

#Como preencho a ficha de um plugin no WordPress.org campo a campo

Uma ficha do WordPress.org é gerada a partir do readme.txt. As regras abaixo vêm da documentação do readme. A coluna da direita é o que verifico nos meus readmes antes de cada versão.

A descrição curta carrega a maior parte do peso, porque aparece onde os utilizadores comparam plugins. Escrevo-a numa só frase: o que o plugin faz por uma loja WooCommerce, nas palavras do dono da loja. No plogins-customs isso significa direitos aduaneiros, papelada alfandegária e documentos de transportadora, os termos que usa o comerciante que envia para fora da UE, em vez do nome de um regulamento.

A descrição longa e a secção de perguntas frequentes do readme são o sítio onde se respondem às dúvidas que bloqueiam a configuração. Passo para as perguntas frequentes do readme todas as questões que surgiram no fórum de suporte, formuladas como o utilizador as fez. Assim, os pedidos de suporte viram conteúdo da ficha e encurtam o caminho do utilizador seguinte até uma configuração funcional.

Para saber mais sobre a construção de plugins para lojas WooCommerce, consulte a minha página de desenvolvedor de WooCommerce.

#Como preencho a ficha de uma app na Shopify App Store campo a campo

A Shopify documenta muito mais da ficha do que o WordPress.org. Todos os valores desta tabela vêm das boas práticas da Shopify App Store.

Dois pontos da mesma página mudam a forma como planeio a ficha:

• Traduções. A Shopify afirma que as fichas traduzidas «convertem até 4x melhor em mercados não ingleses» (tradução própria) e que as fichas principais em inglês são traduzidas automaticamente para 8 idiomas: português do Brasil, dinamarquês, neerlandês, francês, alemão, chinês simplificado, espanhol e sueco. Escrevo a ficha principal em inglês com frases curtas e literais, para que a tradução automática tenha menos por onde errar, e reviso à mão as versões em alemão e espanhol. Repare que o português europeu não está na lista: a variante automática é a do Brasil. Se vende a comerciantes em Portugal, a ficha em português de Portugal fica por sua conta.
• Desempenho da loja. A Shopify pede que as apps não reduzam a pontuação de desempenho do Lighthouse em mais de 10 pontos. A pontuação pondera Página inicial 17%, Detalhes do produto 40%, Coleção 43%. Se a app injeta algo na loja, meço esses três tipos de página com e sem a app antes de submeter.

As capturas de ecrã e o vídeo são onde o problema de onboarding da primeira secção se torna visível. Se não consigo produzir uma sequência de capturas que vá da instalação ao primeiro resultado em três a seis imagens, a configuração é demasiado longa, e corrigir as capturas não corrige o produto.

Se está a construir a própria app, a minha página de desenvolvedor Shopify cobre a parte de implementação.

#O que muda o selo Built for Shopify numa app

O Built for Shopify é o único sítio onde a Shopify afirma que algo afeta a pesquisa. Segundo essa página, o estatuto dá:

• um selo no cartão da app e destaque na ficha,
• um filtro de pesquisa e um reforço de posição na pesquisa da App Store,
• revisão prioritária e segmentação no plano de anúncios,
• elegibilidade para a primeira coleção da página inicial e das categorias e para «Picked for you», que a Shopify descreve como personalizado e sem garantia.

Os critérios abrangem segurança, proteção e fiabilidade; desempenho no painel de administração e, nas apps que lhes tocam, na loja ou no checkout; facilidade de utilização; utilidade comprovada, medida em instalações; número de avaliações e classificação numa janela móvel; e uma ficha completa. A app tem de estar integrada no painel de administração da Shopify.

O processo tem consequências. Falhar o mesmo critério três vezes seguidas suspende a candidatura durante três meses. O estatuto é revisto anualmente e uma app que desça abaixo de um critério tem 60 dias para o corrigir.

Para planear, trato os critérios como uma lista de verificação que se sobrepõe quase por completo ao trabalho de onboarding descrito a seguir. «Facilidade de utilização» e «utilidade comprovada» são difíceis de demonstrar sem os eventos de configuração e de primeiro resultado, por isso instrumento primeiro e candidato-me depois. Candidatar-se cedo e falhar repetidamente o mesmo critério custa três meses.

#Como instrumento o onboarding de um plugin para ver onde os utilizadores desistem

Os painéis das lojas ficam-se pela instalação e pela desinstalação. Tudo o que está entre esses dois eventos tem de vir do seu próprio produto. Envio cinco eventos, e os nomes abaixo são os que eu recomendo, sem serem norma de qualquer plataforma ou ferramenta de análise:

A definição de first_result é a decisão de desenho mais importante. No plogins-customs, um primeiro resultado é um documento aduaneiro gerado a partir de uma encomenda real. Numa app de packs (bundles) na Shopify, pode ser o primeiro pack mostrado numa página de produto. Escreva-a por produto, porque o evento vale tanto quanto essa definição.

Um esboço mínimo do lado do WordPress fica assim. O endpoint e o nome da opção são marcadores de posição e nada é enviado até o dono do site dar o seu consentimento:

// 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' ) ] );
} );

Num plugin gratuito, peço o consentimento no ecrã de configuração, explico o que é enviado e mantenho a carga livre de dados pessoais: sem emails e sem URLs da loja, a menos que o utilizador o tenha aceitado. Na Shopify, o backend da app já conhece a loja, por isso os eventos seguem do lado do servidor, a partir da própria app.

Umami, PostHog e GA4 aceitam eventos personalizados. Escolho uma ferramenta por produto e mantenho-a, porque trocar de ferramenta a meio de uma comparação antes/depois estraga a comparação. Quando os cinco eventos fluem, a tabela de medição da segunda secção preenche-se sozinha e o funil mostra qual dos quatro pontos de falha da primeira secção se aplica.

Mat De Sousa junta mais um argumento para este trabalho no mesmo post: na experiência dele, os comerciantes instalam apps concorrentes em paralelo e ficam com a que é mais rápida de configurar. Se isto corresponde à sua categoria, o seconds_since_install no setup_completed é o número a vigiar.

#Como transformo as versões de um plugin em conteúdo que traz utilizadores

A maioria dos donos de plugins escreve um changelog e fica por aí. O changelog é rigoroso, curto e lido por quase ninguém. As funcionalidades que lá estão são o melhor material para conteúdo, porque cada uma resolve um problema concreto que o dono de uma loja procura.

Para os plogins, publico um feed de funcionalidades legível por máquina em plogins.com/features.json. O ficheiro envolve as entradas num objeto com vendor, count e releases. Cada entrada de versão tem plugin, name, edition, version, released, url, changelog, wpOrg e uma lista features em que cada item tem um kind (new, added ou changed) e um text. Correções e notas de segurança ficam de fora de propósito: importam aos utilizadores e pertencem ao changelog. Como não descrevem uma capacidade nova, ninguém as pesquisa.

Esta é a entrada real do plogins-customs 1.3.0, lançada a 1 de novembro de 2026, reduzida a duas das suas cinco funcionalidades:

{
  "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."
    }
  ]
}

O procedimento que transforma uma entrada destas em conteúdo:

1. Leia o feed depois de cada versão. O meu fluxo editorial vai buscar as entradas novas e lista as funcionalidades que ainda não foram usadas num artigo.
2. Associe cada funcionalidade a um problema. «Customs Paperwork» corresponde à pergunta do comerciante sobre que documentos precisa uma encomenda que sai da UE. A definição do EORI corresponde à pergunta sobre onde tem de constar o número EORI.
3. Procure o artigo que já cobre esse problema. Se existir, a funcionalidade entra nesse artigo como um parágrafo com ligação ao plugin. Se não existir, o problema passa a ser um artigo novo.
4. Escreva em cada idioma que o site serve. Publico em seis idiomas, por isso a funcionalidade chega a seis artigos, cada um escrito para os leitores e as regras dos países desse idioma.
5. Ligue de volta a partir do plugin. A página do próprio plugin e as perguntas frequentes do readme ligam ao artigo que explica o problema, de modo que quem chega pela pesquisa e quem chega pelo plugin encontram a mesma explicação.

O formato do feed conta por duas razões. Um script consegue lê-lo, portanto a passagem da versão ao rascunho não depende de alguém se lembrar. E como cada funcionalidade é uma frase com um kind, vejo de relance quais as versões que acrescentaram algo digno de um artigo e quais apenas alteraram comportamento.

Se quer este processo ligado ao seu próprio ciclo de versões e ao seu sistema de conteúdo, faz parte do que configuro como engenheiro go-to-market. A parte de automação, com ganchos de versão e tarefas agendadas, está próxima do trabalho da minha página de automação de processos de negócio.

#Um concorrente pode copiar a minha app Shopify ou o meu plugin WooCommerce

A opinião de Mat De Sousa, no mesmo post, é que as apps que são apenas uma camada visual sobre a loja se copiam facilmente. Sugere duas adições mais difíceis de copiar: uma camada de serviço, em que o fornecedor configura a app para o comerciante, e uma camada de dados, como testes A/B e análises que mostram ao comerciante o que a app mudou.

O meu próprio trabalho apoia, do lado do cliente, a metade da camada de dados. Desde 2019 executo testes A/B, recomendações e conteúdo dinâmico no Dynamic Yield para clientes de comércio eletrónico. Os comerciantes que veem o resultado de um teste ligado às suas próprias perguntas de faturação pedem o teste seguinte. O comerciante que só vê um widget pergunta se existe um widget mais barato.

Para o dono de um plugin ou de uma app, a versão prática é pequena:

• Camada de serviço. Ofereça uma sessão de configuração ou uma configuração feita por si no plano pago, e deixe isso visível na ficha e no ecrã de configuração. No plogins-customs, o equivalente são as definições de tarifa e de origem pré-preenchidas para o catálogo do comerciante.
• Camada de dados. Mostre ao comerciante, dentro do produto, um número que prove que o plugin funcionou: documentos gerados, linhas de direitos acrescentadas, emails entregues. Esse número é também o evento first_result da secção anterior.

Mat De Sousa recomenda ainda adotar depressa as novidades da Shopify. Leio isso também como argumento de ficha: uma nova capacidade da plataforma que a sua app suporta no primeiro dia é um novo termo de pesquisa, uma nova captura de ecrã e uma nova linha de funcionalidade.

#O Shopify Sidekick recomenda apps da App Store

A página de ajuda do Sidekick da Shopify documenta que o Sidekick pode gerar apps personalizadas, criar fluxos do Shopify Flow e executar tarefas em vários passos. A página não diz que o Sidekick recomenda apps da App Store.

Mat De Sousa descreve-o de outra forma, a partir da sua própria utilização: segundo ele, o Sidekick transforma a pergunta do comerciante em palavras-chave e devolve de 3 a 5 apps mais bem posicionadas. É uma observação dele e a Shopify não a documentou.

Duas conclusões valem nas duas leituras. Se a descrição dele estiver certa, as apps bem posicionadas na pesquisa normal da App Store são as que o Sidekick mostra, e o trabalho de ficha descrito acima conta a dobrar. Se o Sidekick gerar uma app personalizada para uma necessidade simples, uma app que só cubra essa necessidade compete com uma alternativa gerada e gratuita, o que nos devolve às camadas de serviço e de dados. Enquanto a Shopify não documentar o comportamento de recomendação, não planeio nenhum lançamento em torno dele.

#O que o WordPress.org e a Shopify App Store não documentam sobre o ranking

Nenhuma das plataformas publica os pesos do seu ranking de pesquisa. A página do readme do WordPress.org explica como as etiquetas e as descrições são apresentadas e filtradas. As boas práticas da Shopify explicam como preencher cada campo e a página do Built for Shopify diz que o estatuto dá um reforço de posição na pesquisa. Nenhuma destas páginas diz quanto pesa qualquer campo, avaliação ou número de instalações.

A ponderação do Lighthouse na página de boas práticas da Shopify (Página inicial 17%, Detalhes do produto 40%, Coleção 43%) descreve como a Shopify combina a pontuação de desempenho entre tipos de página. É uma medida de desempenho e nenhum dos três documentos a liga à posição na pesquisa.

Isto tem consequências na forma como falo de resultados:

• Não prometo uma posição no ranking a ninguém, incluindo a mim próprio.
• Meço o que consigo definir: visualizações da ficha, instalações, conclusão da configuração, primeiro resultado, subidas de plano.
• Quando uma alteração da ficha é seguida de mais instalações, registo-a como uma variação no mesmo período, com os valores antes e depois, e mantenho iguais as durações dos períodos.

#Posso enviar emails de acompanhamento a quem instalou o meu plugin

As mensagens que fazem parte do serviço, como uma chave de licença, a confirmação da configuração ou um aviso de segurança sobre o plugin, fazem parte do funcionamento do produto. O acompanhamento de marketing a uma pessoa é outro caso, e está regulado.

Em Portugal, as comunicações eletrónicas não solicitadas para fins de marketing direto constam da Lei n.º 41/2004, que transpõe a Diretiva 2002/58/CE (privacidade e comunicações eletrónicas). A regra de fundo vem do artigo 13.º dessa diretiva: o email de marketing a assinantes que sejam pessoas singulares exige consentimento prévio. A diretiva admite uma exceção limitada para contactos obtidos no contexto de uma venda ou das negociações de uma venda, para produtos ou serviços semelhantes, desde que a pessoa tenha tido, na recolha e em cada mensagem, uma forma simples e gratuita de recusar. A Comissão Nacional de Proteção de Dados (CNPD) é a autoridade portuguesa de proteção de dados e a entidade a quem pode recorrer em caso de dúvida sobre estas comunicações.

Na prática, para um utilizador de um plugin gratuito que nunca comprou nada, peço o consentimento no registo, com uma caixa não preenchida por omissão e uma descrição clara do que a pessoa vai receber. Para um cliente pagante, a exceção para clientes existentes pode aplicar-se a produtos relacionados, desde que a opção de recusa tenha existido desde o primeiro contacto.

Uso o Mautic todos os dias numa plataforma de subscrições, e a configuração que funciona é simples: um segmento por produto e plano, construído a partir dos mesmos eventos install, setup_completed e upgrade, e emails desencadeados pelo que o utilizador fez ou deixou de fazer. Quem instalou mas nunca disparou setup_completed recebe uma mensagem sobre a única definição que bloqueia a configuração. Quem chegou ao first_result não recebe nada sobre configuração. Os emails ficam curtos e relevantes, e os segmentos e a tabela de medição leem do mesmo fluxo de eventos.

#Qual é a ordem de trabalho para um plugin ou app que estagna depois da instalação

Esta é a sequência que sigo nos meus produtos e que recomendo a qualquer plugin ou app com instalações e sem utilizadores pagantes:

1. Semana 1: medir. Defina os cinco eventos e a condição de first_result, lance o acompanhamento com consentimento e preencha a coluna Antes da tabela de medição a partir do painel da loja e da sua análise.
2. Semana 2: ficha. Percorra a lista de verificação campo a campo da sua plataforma. Corrija etiquetas, descrição curta, termos de pesquisa, capturas de ecrã e lista de funcionalidades segundo os limites documentados. Não altere ainda nada no produto.
3. Semanas 3 a 6: ler o funil. Deixe os eventos recolher um período completo. Encontre o passo com a maior quebra: configuração iniciada, configuração concluída ou primeiro resultado.
4. Semana 7: corrigir a maior quebra. Encurte a configuração, pré-preencha valores por omissão ou aproxime o primeiro resultado da instalação. Uma só alteração.
5. Semanas 7 a 10: medir de novo. Preencha a coluna Depois com um período da mesma duração.
6. Em cada versão: conteúdo. Acrescente a versão ao feed de funcionalidades, associe cada funcionalidade nova a um problema e a um artigo e atualize as linhas de funcionalidades da ficha.
7. Com o funil estável: acompanhamento. Construa as sequências de email com consentimento sobre os mesmos eventos.

Na Shopify, candidate-se ao Built for Shopify depois do passo 5, quando já puder mostrar números de configuração e de utilidade em vez de esperar que a revisão os encontre.

#O que fazer a seguir

Pegue na tabela de medição deste artigo, preencha a coluna Antes do seu plugin ou da sua app com os dados das últimas quatro semanas e envie-a, juntamente com a ligação para a sua ficha no WordPress.org ou na Shopify App Store, através da página de engenheiro go-to-market. Devolvo-lhe uma revisão da ficha campo a campo face aos limites documentados e o passo de onboarding que eu instrumentaria primeiro.