Engenheiro go-to-market para plugins WooCommerce, apps Shopify e Mautic

#Porque é que, em 2026, as funcionalidades já não bastam

Copiar uma funcionalidade demora hoje alguns dias. As agências constroem pequenas ferramentas próprias para os clientes, e a parte visual de um plugin ou de uma app é a mais fácil de copiar. O que continua difícil de copiar é a distribuição: uma ficha que responde à pergunta do comprador, um onboarding que chega depressa ao primeiro resultado, dados que mostram de que funcionalidade precisam os utilizadores pagantes e um acompanhamento que não depende de alguém se lembrar de escrever um email.

Mat De Sousa, que gere a app Shopify WideBundle, descreveu a mesma mudança a partir de entrevistas com agências Shopify: as apps puramente visuais têm dificuldade em crescer, e as que crescem juntam uma camada de serviço (configurar a app para o comerciante) e uma camada de dados (testes A/B e analítica que a agência não consegue construir sozinha). Do lado do WooCommerce vejo o mesmo: desde 2019 faço testes A/B, recomendações e conteúdo dinâmico no Dynamic Yield para clientes de comércio eletrónico, e a camada de dados é o que os clientes mais pedem.

#Para quem é a engenharia go-to-market

Este trabalho é pedido por três tipos de cliente, e cada um parte de um sítio diferente.

• Quem faz plugins e apps. Tem um plugin WooCommerce no WordPress.org ou uma app Shopify na App Store, uma versão gratuita e uma paga, e instalações que não se transformam em receita. O trabalho começa pela ficha de produto e pelo caminho entre a instalação e o primeiro resultado.
• Lojas com ferramentas de marketing que se foram juntando ao acaso. GA4, Google Tag Manager, uma ferramenta de newsletter, um CRM e alguns cenários em Zapier ou Make.com, cada peça montada por uma pessoa diferente. Ninguém sabe dizer que canal traz clientes que pagam. O trabalho começa pela medição e pelo fluxo de dados entre essas ferramentas.
• Empresas de serviços B2B e agências. Os contactos chegam por formulários e email, e o acompanhamento depende de quem tem tempo. O trabalho começa pelo Mautic ou pelo CRM: um único sítio onde vivem o contacto, o seu consentimento e o seu histórico, e uma automação que faz o acompanhamento.

Se nenhum dos três descreve a sua situação, o problema está provavelmente no produto ou no próprio site, e o melhor ponto de partida é o desenvolvimento WooCommerce ou a automação de processos de negócio.

#O que recebe nas primeiras semanas

Cada projeto produz ficheiros que ficam consigo, seja quem for que trabalhe neles depois.

O procedimento por trás destes ficheiros, com a tabela de medição, os campos da ficha e os nomes dos eventos, está no meu artigo sobre como fazer crescer um plugin WooCommerce ou uma app Shopify.

#Ferramentas que uso em produção

Indico apenas ferramentas que usei em projetos reais. Se usa outra coisa, digo-o antes de orçamentar.

#O que preciso de si

• Acesso de leitura à analítica, às estatísticas do diretório ou do Partner Dashboard e à instância do CRM ou do Mautic.
• O changelog ou as notas de lançamento das últimas versões.
• A sua própria frase sobre o motivo pelo qual um comprador instala o produto ou o contacta. Confronto-a com os dados e não a invento.
• Uma pessoa que decida quando dois objetivos entram em conflito, por exemplo mais instalações contra menos pedidos de suporte.
• Design gráfico, se a ficha ou as páginas de destino precisarem de novos elementos visuais. O design vem do seu lado; eu implemento-o e meço-o.

#Como faço o relatório

Por escrito, no repositório ou num documento partilhado, e nunca apenas numa chamada. Cada relatório traz a mesma tabela do ponto de partida, o que mudou desde o anterior e o que recomendo retirar. Se uma alteração não mexeu no seu número, o relatório di-lo. Não prometo posições, instalações nem receita, porque nem o diretório de plugins nem a App Store publicam como classificam, e os seus resultados dependem tanto do produto como da distribuição.

#O que costuma falhar primeiro, também no meu próprio site

A primeira auditoria costuma encontrar uma ferramenta que funciona e não regista nada de útil. Três exemplos deste site, todos encontrados e corrigidos em 2026:

• Parâmetros de campanha perdidos no redirecionamento. Uma regra pensada para eliminar URLs duplicados enviava todos os endereços com utm_*, gclid ou fbclid para o URL simples, com um 301. A etiqueta canónica já tratava dos duplicados, por isso a regra só fazia mal: de julho a outubro, os campos UTM ocultos do formulário de contacto ficaram vazios, e a origem desses pedidos é desconhecida. A correção foi deixar os parâmetros de medição em paz e deixar a etiqueta canónica e o cabeçalho No-Vary-Search fazerem o seu trabalho. O teste é um único pedido: um endereço com um utm_source novo tem de devolver 200 e nunca 301.
• Um interruptor de consentimento que não controlava nada. O banner de cookies tinha uma categoria “funcional”, marcada por predefinição, e nenhum código escutava a escolha do utilizador. Os vídeos incorporados do YouTube carregavam de qualquer forma, embora a descrição prometesse que desligá-la os bloquearia. Desmarcar apenas a caixa teria piorado a situação: o banner passaria a perguntar e a mentir sobre o efeito. A ordem é sempre primeiro o mecanismo e só depois a predefinição.
• Um formulário de newsletter sem confirmação e sem saída. O formulário enviava o endereço diretamente para um serviço de email. Não havia dupla confirmação, não havia ligação para cancelar a subscrição, e a política de privacidade não mencionava a newsletter. A correção foi uma ligação de confirmação assinada, válida durante sete dias, e uma ligação permanente de cancelamento. O endereço só entra na lista depois da confirmação, o primeiro momento em que pode ser adicionado legalmente.

Todos os três pareciam uma funcionalidade a funcionar, e qualquer relatório construído sobre eles ficaria errado. Por isso as primeiras semanas vão para a tabela de ponto de partida e para o plano de eventos, antes de qualquer campanha ou automação.

#O que faço como engenheiro go-to-market

#Onde fiz este trabalho

Tudo o que se segue é trabalho que fiz eu próprio, descrito sem nomes de clientes.

#Mautic alimentado por um ERP, uma ferramenta de newsletter e dados de moradas

Desde outubro de 2025 trabalho como engenheiro full-stack numa plataforma de media e comércio por subscrição, para uma agência de engenharia de software de Viena. Construí um serviço em Kotlin e Spring Boot que reúne no Mautic, via OAuth, dados de subscritores, empresas, moradas e campanhas vindos de um ERP editorial legado, do CleverReach e de fontes de moradas. A maior parte do trabalho é resolução de identidades: fazer corresponder empresas, normalizar e-mails e telefones, remover duplicados, respeitar as marcas de proibição de contacto e manter rastreável a origem de cada registo. As importações correm numa fila assíncrona sobre milhões de linhas de contactos e de objetos personalizados. Um modelo de linguagem local (Ollama via Spring AI) classifica os registos dentro dessa fila, com saída estruturada, na infraestrutura do próprio cliente, de modo que os dados de contacto nunca a abandonam.

#Porque falham os primeiros pagamentos

Na mesma plataforma fiz uma análise só de leitura dos primeiros pagamentos abandonados em Stripe, Klarna, PayPal e fatura. Separou os grupos de falhas SCA e 3D Secure dos utilizadores que desistem ou saltam entre métodos de pagamento, e passou a ser uma exportação mensal repetível que substituiu a revisão manual. Num negócio de subscrições é o passo entre “começou um período de teste” e “chegou a receita”, exatamente onde o trabalho go-to-market compensa.

#Experiências, medição e automação de CRM

• Experiências: testes A/B, recomendações e conteúdo dinâmico em Dynamic Yield para clientes de e-commerce desde 2019.
• Medição: Google Tag Manager, GA4, Search Console e BigQuery, configurados para que campanhas e conversões se possam realmente ler.
• CRM: desde janeiro de 2021, trabalho em contrato para um cliente de Berlim em WordPress, WooCommerce, HubSpot e Shopify, com automações em Make.com e Zapier entre os sites, o CRM e outras ferramentas.

#Os meus plugins como banco de ensaio

• plogins: os meus plugins WooCommerce, com versões gratuitas no WordPress.org e versões Pro vendidas diretamente, com PHPStan, PHPCS e lançamentos automáticos. As funcionalidades de conversão incluem order bumps, recuperação de carrinhos abandonados, e-mails de acompanhamento, listas de espera de reposição de stock e preços por escalões; a conformidade com a UE inclui o botão de livre resolução exigido pela Diretiva (UE) 2023/2673 e o Polski for WooCommerce (GPSR, Omnibus).
• Feed de lançamentos: cada lançamento escreve as suas novas funcionalidades num feed público em plogins.com/features.json, e o meu processo de revista de imprensa leva-as daí para os artigos sobre os problemas que resolvem.
• Agentes de IA: escrevi um servidor MCP de código aberto, o woocommerce-mcp, que expõe a agentes de IA os produtos, as encomendas e os dados de vendas do WooCommerce.

Serviços relacionados: desenvolvedor Shopify, integração WooCommerce com ERP e automação de processos de negócio.

#O que a App Store e o diretório de plugins realmente premeiam

A Shopify documenta parte das regras. As apps com o estatuto Built for Shopify recebem um selo, um filtro e um reforço na classificação da pesquisa da App Store, e o estatuto depende do desempenho, da facilidade de utilização e da utilidade comprovada, medida em instalações, número de avaliações e classificação (Shopify, Built for Shopify). O guia de fichas admite até cinco termos de pesquisa formados por palavras completas e indica que as apps não devem baixar a pontuação de desempenho Lighthouse de uma loja em mais de 10 pontos (Shopify, boas práticas da App Store).

O WordPress.org documenta o formato do readme: de 1 a 5 etiquetas, as etiquetas exclusivas do seu plugin não são apresentadas, e a descrição curta deve ficar abaixo de 150 caracteres (Plugin Handbook, readme). Nenhuma das plataformas publica os pesos da classificação, por isso não prometo posições. Corrijo o que está documentado e meço o resto.

#Consentimento no acompanhamento

Um email automático a quem instalou um plugin gratuito ou iniciou um período de teste é, na maioria dos casos, marketing e precisa de base legal. A regra sobre comunicações não solicitadas vem do artigo 13.º da Diretiva 2002/58/CE (ePrivacy), transposta em Portugal pela Lei n.º 41/2004; a fiscalização do tratamento de dados pessoais cabe à CNPD. Configuro o Mautic para que o consentimento, a sua origem e a data fiquem guardados por contacto, e para que as campanhas verifiquem esse campo em vez de o presumirem.

Envie um briefing escrito curto através da página de contacto: o produto, onde é vendido, que dados já tem e o único número que quer fazer mexer.