{"id":507,"date":"2026-04-14T13:58:41","date_gmt":"2026-04-14T16:58:41","guid":{"rendered":"https:\/\/eduardovillao.me\/pt-br\/?p=507"},"modified":"2026-04-14T13:59:29","modified_gmt":"2026-04-14T16:59:29","slug":"como-eu-melhorei-a-taxa-de-ativacao-do-wpfeatureloop-em-80-com-wordpress-playground","status":"publish","type":"post","link":"https:\/\/eduardovillao.me\/pt-br\/como-eu-melhorei-a-taxa-de-ativacao-do-wpfeatureloop-em-80-com-wordpress-playground\/","title":{"rendered":"Como Eu Melhorei a Taxa de Ativa\u00e7\u00e3o do WPFeatureLoop em 80% com WordPress Playground"},"content":{"rendered":"\n

A maioria dos produtos SaaS tem um gap entre o signup e o momento em que o usu\u00e1rio realmente entende<\/em> o produto. No WPFeatureLoop, esse gap era brutal.<\/p>\n\n\n\n

Usu\u00e1rios criavam uma conta, olhavam o dashboard, e\u2026 nada. O pr\u00f3ximo passo era instalar um SDK via Composer. Pra um dev WordPress que s\u00f3 queria ver se a ferramenta valia seu tempo, isso \u00e9 pedir demais.<\/p>\n\n\n\n

T\u00ednhamos 72% de drop-off entre cria\u00e7\u00e3o de conta e primeira instala\u00e7\u00e3o do SDK. A maioria desses usu\u00e1rios nunca voltou.<\/p>\n\n\n\n

Ent\u00e3o eu corrigi o onboarding. E a solu\u00e7\u00e3o veio de um lugar inesperado: WordPress Playground.<\/p>\n\n\n\n

O Problema do Onboarding “Instale Primeiro”<\/h2>\n\n\n\n

O WPFeatureLoop \u00e9 um SaaS de vota\u00e7\u00e3o de features pra donos de plugins WordPress. Voc\u00ea instala um SDK PHP no seu plugin, e seus usu\u00e1rios ganham um widget embutido onde podem sugerir features, votar e comentar. Voc\u00ea gerencia tudo por um dashboard Kanban.<\/p>\n\n\n\n

A proposta de valor \u00e9 clara quando voc\u00ea v\u00ea funcionando. O problema era que os usu\u00e1rios n\u00e3o conseguiam ver funcionando sem antes integrar o SDK \u2014 o que significa configurar Composer, adicionar uma depend\u00eancia, configurar chaves e fazer deploy. S\u00e3o 20 a 40 minutos de trabalho antes de conseguir responder a pergunta “isso vale a pena?”<\/p>\n\n\n\n

Esse \u00e9 o problema cl\u00e1ssico de ativa\u00e7\u00e3o: voc\u00ea est\u00e1 pedindo pro usu\u00e1rio investir antes de ver o retorno.<\/p>\n\n\n\n

O n\u00famero que tornou isso concreto: nossa taxa de ativa\u00e7\u00e3o \u2014 a porcentagem de signups que completavam a integra\u00e7\u00e3o do SDK e submetiam pelo menos um feature request \u2014 estava em 28%. Tudo que vinha depois (reten\u00e7\u00e3o, upgrades) ficava prejudicado por esse n\u00famero.<\/p>\n\n\n\n

A Solu\u00e7\u00e3o: Deixa Ele Experimentar Primeiro<\/h2>\n\n\n\n

O insight foi simples. Em vez de pedir pro usu\u00e1rio instalar o SDK pra ver o widget, e se eu pudesse mostrar o widget primeiro, com zero setup?<\/p>\n\n\n\n

\u00c9 a\u00ed que entra o WordPress Playground.<\/p>\n\n\n\n

WordPress Playground \u00e9 um ambiente WordPress completo que roda inteiramente no browser, via WebAssembly. Sem servidor. Sem instala\u00e7\u00e3o. Um site WordPress real rodando localmente numa aba.<\/p>\n\n\n\n

E o mais importante: ele suporta Blueprints \u2014 um formato de configura\u00e7\u00e3o em JSON que permite definir exatamente o que acontece quando o Playground carrega: quais plugins instalar, quais settings configurar, qual p\u00e1gina abrir, at\u00e9 com qual usu\u00e1rio logar.<\/p>\n\n\n\n

Isso significava que eu podia construir um ambiente Playground que:<\/p>\n\n\n\n

    \n
  1. Instala automaticamente um plugin demo com o SDK do WPFeatureLoop j\u00e1 embutido<\/li>\n\n\n\n
  2. Pr\u00e9-configura com as chaves de API reais do projeto do usu\u00e1rio<\/li>\n\n\n\n
  3. Abre direto na p\u00e1gina onde o widget est\u00e1<\/li>\n\n\n\n
  4. Faz login como admin automaticamente<\/li>\n<\/ol>\n\n\n\n

    O usu\u00e1rio clica em “Try it live”, uma nova aba abre, e em segundos ele est\u00e1 olhando pro widget real do WPFeatureLoop, conectado ao projeto real dele.<\/p>\n\n\n\n

    Como Funciona Tecnicamente<\/h2>\n\n\n\n

    O Blueprint \u00e9 gerado server-side no momento em que o usu\u00e1rio clica em “Try it live”, com as chaves do projeto injetadas dinamicamente. Aqui vai uma vers\u00e3o simplificada da estrutura:<\/p>\n\n\n\n

    {\n    \"landingPage\": \"\/sample-page\/\",\n    \"login\": true,\n    \"plugins\": [\"wpfeatureloop-demo\"],\n    \"steps\": [\n        {\n            \"step\": \"defineWpConfigConsts\",\n            \"consts\": {\n                \"WPFL_PROJECT_KEY\": \"chave-real-do-usuario\",\n                \"WPFL_API_URL\": \"https:\/\/api.wpfeatureloop.com\"\n            }\n        }\n    ]\n}\n<\/code><\/pre>\n\n\n\n
    A URL do Playground fica:<\/p>\n\n\n\n
    https://playground.wordpress.net\/?blueprint-url=https:\/\/app.wpfeatureloop.com\/api\/blueprint\/{project_id}\n<\/code><\/pre>\n\n\n\n
    \u00c9 isso. O usu\u00e1rio cai num widget funcionando, conectado ao dashboard dele. Ele pode submeter um feature request, votar, e depois voltar pro dashboard do WPFeatureLoop e ver aparecer em tempo real.<\/p>\n\n\n\n
    Um detalhe importante: o sandbox do Playground \u00e9 tempor\u00e1rio e n\u00e3o persiste dados entre sess\u00f5es. Mas pra onboarding isso n\u00e3o importa \u2014 o objetivo \u00e9 demonstrar valor, n\u00e3o armazenar dados.<\/p>\n\n\n\n
    A Mudan\u00e7a na UI<\/h2>\n\n\n\n
    No dashboard, quando o usu\u00e1rio cria um novo projeto, um modal “Get Started” abre com tr\u00eas abas:<\/p>\n\n\n\n