Biosites orientados à entrega de valor

Revisão de produto — 29/10/2026. Este documento substitui a ideia de três templates diferenciados apenas por cores. Define o escopo de conversão; não declara fluxos de negócio implementados nem ganhos já medidos.

1. O problema que vamos resolver

Uma lista de links transfere ao visitante o trabalho de descobrir qual oferta serve para ele. Uma página de captação precisa responder: isto é para mim, o que vou receber, por que vale meu contato, quanto esforço exige e como recebo depois?

O produto será um construtor de pequenas jornadas de aquisição: identidade do criador → oferta compreensível → escolha informada → acesso autorizado → próximo passo opcional. Links continuam disponíveis, mas não disputam o mesmo peso da oferta principal.

Público inicial: especialistas e pequenos negócios que já têm uma audiência e um material próprio útil. Primeira vitória: publicar uma oferta, captar um contato com finalidade clara e entregar o material sem intervenção manual. Não começar com um construtor universal nem prometer vendas por simples troca de template.

2. Referências verificadas e oportunidade

As páginas públicas não comprovam taxa de conversão nem permitem concluir que um concorrente não ofereça determinada função. Nossa oportunidade é uma hipótese: tornar publicação, seleção de material, captura transparente e recuperação de acesso mais claras para o público brasileiro. Não anunciar superioridade antes de testar.

3. Template, tema e oferta são escolhas diferentes

• Template: estrutura e jornada — campanha, biblioteca ou editorial.
• Tema: cores, fontes aprovadas, bordas, fundo, espaçamento e imagem de capa.
• Oferta: material, proposta, público, modo direto/lead/pago, condições e validade.
• Blocos: componentes permitidos, com campos e posição compatíveis com o template.

Todos os templates suportam identidade própria, domínio da plataforma e rodapé gratuito. Um mesmo tema pode vestir qualquer template. Trocar de tema não altera regras de acesso; trocar de template preserva ofertas e grants. Preview mostra o conteúdo real antes de publicar uma revisão.

4. Três jornadas prioritárias

A. Campanha — uma isca principal

Quando usar: tráfego de um post, anúncio, palestra ou parceria com promessa específica.

Estrutura: identidade compacta → benefício principal → capa/preview do material → três resultados concretos → CTA dominante → formulário contextual → confirmação e acesso. Links secundários ficam após a oferta, com menor peso.

Conteúdo obrigatório: para quem é, o que inclui, formato/tamanho, condições para obter acesso e identificação do criador. Informar tempo de consumo apenas quando fundamentado pelo autor. Provas e depoimentos só com origem real e autorização; nenhuma contagem inventada.

Captura: e-mail como padrão mínimo; nome e telefone só quando a finalidade justificar. Escolha de marketing separada e opcional. O CTA abre a captura da oferta escolhida, sem levar a um formulário genérico.

Pós-captura: botão de acesso imediato quando a política permitir, confirmação legível, recuperação por e-mail e mensagem de erro com retry. Ofertas adicionais só depois da entrega.

URL de campanha: /@criador/o/guia, para abrir a oferta diretamente e manter contexto de origem, sem obrigar a procurar o material na página principal.

Métrica: acessos concedidos únicos por oferta; conversão de captura entre visitantes elegíveis com medição consentida. Medir separadamente falhas e tempo entre envio válido e acesso.

B. Biblioteca — encontrar o material certo

Quando usar: criador com várias iscas para públicos ou níveis diferentes.

Estrutura: busca por título/benefício → filtros por assunto e modalidade → uma recomendação editorial → grade com capas e metadados → detalhe da oferta → captura específica. Não solicitar contato para navegar ou ver a descrição.

Cards: título orientado ao resultado, resumo, assunto, formato e acesso gratuito/por contato/pago. Não esconder condições atrás de “saiba mais”. Resultados vazios oferecem limpar filtros e retornar ao catálogo.

Captura: uma oferta por vez. A sessão pode reaproveitar dados já fornecidos para a mesma finalidade, com escolha explícita; nunca transformar o primeiro envio em consentimento amplo para todos os produtos ou tenants.

Pós-captura: acesso ao item e sugestão relacionada opcional. Marcar “já disponível para você” apenas quando um grant válido for verificado no servidor.

Métrica: seleção de oferta, busca sem resultado, abandono no detalhe e concessão por assunto. Ranking inicial é editorial; personalização automática depende de evidência e avaliação de privacidade.

C. Editorial — demonstrar antes de pedir

Quando usar: fotógrafo, designer, educador ou especialista cuja qualidade precisa ser percebida antes da captura.

Estrutura: apresentação autoral → amostra pública relevante → explicação do método ou do trabalho → isca relacionada → continuidade gratuita ou produto pago claramente separado. O conteúdo deve conduzir a uma oferta coerente, sem virar um mural sem prioridade.

Amostra: trecho, exercício, comparativo ou galeria autoral. Preview é um asset público separado do arquivo protegido; nunca baixar o arquivo completo e escondê-lo com CSS.

Captura: CTA vinculado ao conteúdo visto, por exemplo “Receber os exercícios de composição”. O visitante entende o valor antes de fornecer contato.

Produto pago: página própria com inclusões, preço total, formato, política de acesso, suporte e identificação do vendedor. Checkout hospedado e confirmação autenticada, sem competir visualmente com o CTA gratuito na primeira dobra.

Métrica: percurso amostra → oferta → concessão. Para compra, medir pedido confirmado e falha de entrega; nunca usar intenção do navegador como receita.

5. Jornada completa da isca

1. Descoberta: URL compartilhável da página ou da oferta, preview social adequado e promessa consistente com a origem.
2. Compreensão: preview e benefícios específicos; preço/contrapartida visíveis; nenhum dado solicitado antes de explicar o valor.
3. Decisão: CTA com objeto claro e uma ação principal por seção. Formato e condições acompanham o botão.
4. Captura: formulário curto, labels persistentes, autocomplete, validação por campo, preservação em erro transitório e marketing desmarcado.
5. Verificação: servidor valida limites, tenant, finalidade e dados. Definir por oferta se exige confirmação de contato; não confundir coleta com identidade verificada.
6. Entrega: grant persistente → ticket curto ligado à sessão → stream autorizado. Mostrar estado pronto, pendente, indisponível ou expirado sem voltar ao início.
7. Recuperação: link de e-mail de curta duração, resposta neutra e recuperação de compra. Não obrigar novo pagamento nem nova adesão a marketing.
8. Continuidade: um próximo passo opcional, por exemplo outro material ou contato comercial, somente após a entrega.

E-mail é recuperação/transação, não a única forma de entrega. Falha de e-mail não pode apagar o direito ao material. Acesso direto não autorizado retorna à oferta específica; compras confirmadas seguem política explícita e não expiram silenciosamente.

6. Editor que ajuda a publicar uma oferta boa

Onboarding começa com “qual resultado você quer?”: distribuir uma isca, organizar materiais ou apresentar trabalho. Depois, escolher template, adicionar oferta, definir acesso e aplicar tema.

Campos da oferta: título, público, problema resolvido, benefícios, descrição, capa/preview, arquivo, formato/tamanho, modalidade, preço quando aplicável, contato do responsável e aviso de privacidade.

Preview mobile e desktop com estados de erro/sucesso; salvar rascunho, reordenar blocos permitidos, publicar revisão e reverter. Não deixar o criador editar HTML, scripts ou embeds arbitrários.

Checklist útil de publicação:

• Upload pronto e verificado; preview separado do asset protegido.
• CTA específico, oferta compreensível e campos proporcionais.
• Contraste/foco, texto alternativo e ausência de links quebrados.
• Política e responsável informados; consentimentos separados.
• Teste de acesso em sessão nova, inclusive caminho de recusa e recuperação.

Alertas editoriais sugerem melhorias sem inventar pontuação de conversão ou promessas comerciais. Limites e branding do plano são validados no backend.

7. Analytics que explica o resultado

Nenhum evento recebe valores de campos, PII, tokens ou texto livre. Analytics opcional só após escolha; registros de transação e segurança têm finalidade própria. O painel distingue população consentida e totais operacionais: não divide compras totais por visualizações parcialmente consentidas.

Sucesso principal: materiais disponibilizados a contatos válidos conforme a política da oferta. Qualidade de lead é uma medida posterior do criador, não uma suposição de que todo formulário gera oportunidade. Stream concluído não comprova leitura ou arquivo salvo.

8. Escopo e sequência de entrega

Não desenvolver três produtos independentes. Construir primeiro a infraestrutura compartilhada e provar a entrega com campanha; ampliar os templates depois. Os três protótipos atuais servem para avaliar direção e interação, não significam que P0 já esteja concluído.

Fora do início: automação completa de e-mail marketing, editor livre, marketplace, recomendações por IA, segmentação comportamental entre tenants e dezenas de templates cosméticos.

9. Crescimento e modelo comercial

Aquisição inicial por nichos que já distribuem conteúdo. Templates e exemplos precisam ensinar o uso, não apenas decorar a landing page. Rodapé gratuito leva a uma página de criação com o template escolhido como contexto, sem transportar dados do visitante.

Ativação: primeira publicação seguida da primeira entrega válida. Retenção: criadores com ofertas ativas e entregas bem-sucedidas, além de retorno ao painel. Receita: assinatura por necessidades verificáveis — domínio, branding, volume e equipe — com limites claros. Taxas e acesso ao pago serão definidos com o provedor; não cobrar por métricas de tracking nem bloquear recuperação de compras.

Experimentar uma hipótese por vez: clareza do benefício, preview, quantidade de campos ou posição do CTA. Comparar populações equivalentes e registrar volume, incerteza e período; não encerrar teste no primeiro resultado favorável. Antes de A/B automatizado, usar observação de tarefas com criadores e visitantes reais.

Critérios de pesquisa: o visitante consegue explicar o que receberá antes do clique; percebe a contrapartida; encontra a oferta sem instrução; entende como recusar marketing; chega ao acesso ou identifica como recuperar. Registrar sucesso, dificuldade e abandono — não inventar benchmarks de mercado.

10. Contrato da demonstração

Os modelos publicados no ambiente local devem mudar composição, hierarquia e interação: campanha focada, biblioteca filtrável e editorial com amostra contextual. O percurso de captura pode ser demonstrado com dados fictícios somente leitura e sucesso claramente simulado. Nenhum formulário real, pagamento, grant ou arquivo privado é criado nesta demonstração.

Aceite visual: diferenças percebidas sem depender das cores; oferta principal compreensível no mobile; amostra visível antes de pedir contato; navegação por teclado; diálogo fechável e foco restaurado; filtros utilizáveis e sem dependência de rastreamento. Aceite funcional de produção permanece no roadmap e exige backend e testes de autorização.

11. Personalização de identidade e fundo

Referência visual analisada nesta sessão no navegador: Atividades Infantis no Bio Sites. Na visita, apresentou fundo sólido azul-acinzentado, avatar circular, tipografia arredondada e cards com imagens de capa. Isso não significa que a página esteja usando fundo fotográfico neste momento. Nossa proposta amplia esses elementos com uma foto de fundo independente do conteúdo, sem copiar foto, nome ou materiais da referência.

Configurações por site, independentes do template:

• Fundo sólido, degradê ou foto, com posição focal, escurecimento de 0–70% e desfoque de 0–12 px.
• Paletas inicial natural, areia, noturna e suave; cores próprias para destaque, fundo e painel. Texto e rótulos dos botões precisam manter contraste legível.
• Avatar com iniciais ou foto, recorte circular, proporção reservada e borda. Produção: crop, ponto focal e texto alternativo apropriado quando a imagem trouxer informação.
• Conteúdo amplo ou compacto/central, superfície sólida ou vidro suave e raio de 0–32 px. Compactar não troca regras de acesso nem duplica o template.
• Preview, restaurar e, na versão com editor persistente, salvar rascunho, publicar revisão e reverter.

Na demonstração, o painel “Personalizar aparência” funciona nos três modelos. As mudanças ficam apenas na aba; fotos próprias não são enviadas nem guardadas no servidor. O avatar gerado é ilustrativo, não representa o criador real. O painel pertence à experiência de edição/demonstração e não deverá aparecer para visitantes do site publicado.

Performance: imagens próprias do projeto transformadas em WebP, com fundo em versões de 768/1600 px e avatar de 160 px. A foto é uma única camada fixa com blur limitado, sem listeners de scroll, vídeo automático ou parallax por padrão. Texto fica em uma superfície quase opaca, não diretamente sobre partes imprevisíveis da foto. Outras páginas não carregam a foto oculta até ela ser escolhida. O número real de bytes e os testes em dispositivo compõem a validação, sem promessa de melhoria de Core Web Vitals ainda não medida.

Upload em produção mantém o pipeline de segurança: limite de bytes/pixels, tipo real, reencodificação, remoção de metadados, quarentena e permissão por tenant. A validação do navegador é apenas feedback, nunca uma fronteira de confiança. Avatar e fundo são assets públicos de identidade; PDFs protegidos continuam privados.

12. Nome, e-mail, WhatsApp e repescagem

Não existe vencedor universal entre um campo e três. Menos dados podem reduzir esforço; mais canais podem apoiar relacionamento, mas também geram abandono, erro e contatos de baixa qualidade. Essas são hipóteses de produto: medir entrega válida e qualidade posterior por oferta, sem prometer percentuais de conversão.

Recomendação inicial para a intenção de repescagem deste produto:

Em produção, a configuração por campo será oculto / opcional / obrigatório, validada no servidor contra a finalidade da oferta. Não exigir os dois canais apenas para aumentar a base de marketing. Nome obrigatório precisa de uma finalidade justificada, não apenas da possibilidade de personalizar uma saudação. Explicar a contrapartida antes de solicitar os dados e permitir retirada das escolhas de marketing sem retirar direitos de compra ou acesso já concedidos.

Fornecer um canal de entrega não equivale a aceitar campanhas. Separar finalidade transacional, novidades por e-mail e novidades por WhatsApp. Marketing por canal é opcional e desmarcado. Mostrar quem contatará, para qual conteúdo e como sair. Na configuração inicial conservadora, campanhas dependem de opt-in explícito por canal; isso não afirma que consentimento seja a única base legal admitida para todo tratamento.

A política oficial do WhatsApp Business exige número fornecido e opt-in para contatos posteriores. A orientação governamental sobre princípios da LGPD reforça finalidade, adequação e necessidade. Base legal, texto e operação final precisam ser compatíveis com cada finalidade e canal; requisitos do provedor também serão conferidos antes da integração.

A lista de relacionamento deve preservar tenant, oferta/material de origem, assunto escolhido, canal, estado de verificação, status de opt-in por canal, versão do texto, instante e opt-out. Não inferir religião, saúde ou outros dados sensíveis a partir do interesse na isca. Normalizar telefone com código de país e e-mail, sem confundir formato válido com titularidade ou existência de conta no WhatsApp.

Repescagem: filtrar por interesse declarado e canal autorizado; lista de supressão impede recontato após saída. Contatos conflitantes não são fundidos automaticamente; deduplicação só dentro do tenant. Operações de campanha não podem ultrapassar o escopo autorizado nem reutilizar a base para a plataforma. Exportação deve incluir o status do canal e ser protegida por autorização, auditoria e prevenção de CSV injection.

Prioridade: implementar a configuração de campos e os recibos junto do primeiro fluxo real de captura. Integração de envio e automação de campanhas vem depois, com provedor, custos e gestão de opt-out definidos. A prévia atual exibe os três campos fictícios e presets, mas não envia contato ou mensagem.

13. Assets originais de demonstração

Gerados com a skill Imagegen, ferramenta integrada, sem uso de API/CLI com chave. Arquivos: apps/web/src/assets/studio-background.png e apps/web/src/assets/creator-avatar.png. Os PNGs são fontes; o visitante recebe derivados WebP do build.

Prompt do fundo: fotografia editorial de um estúdio criativo claro, parede de linho, luz natural suave, planta verde na lateral e mesa de carvalho na base; composição horizontal com espaço negativo, creme, verde sálvia e bege; sem pessoas, texto, marcas ou interface.

Prompt do avatar: retrato fotográfico original de uma educadora criativa adulta fictícia, aproximadamente 30 anos, sorriso natural, blusa verde sálvia, fundo creme, luz difusa e rosto central com espaço para crop circular; não representar pessoa conhecida; sem texto, marcas, moldura ou interface.

14. Gestão persistente, banner, textos e SEO

O ambiente Docker agora inclui /painel, com acesso administrativo local de dono único. Não é a autenticação multiusuário do SaaS: há uma credencial de demonstração gerada no primeiro início, preservada no volume e nunca incluída no frontend ou no Git. Uma flag de ambiente habilita esse módulo somente neste ambiente. A área pública fica em /c/slug.

Fluxo: criar campanha → escolher modelo → editar → adicionar arquivos/links → salvar rascunho → conferir prévia protegida → publicar. Salvamento e publicação são ações diferentes. A versão protege contra sobrescrever uma edição concorrente. Despublicar preserva os arquivos e o rascunho; publicar novamente restaura o acesso conforme a revisão atual.

Configurações disponíveis:

• Nome interno, modelo, slug, title, meta description, H1 e corpo. Title, description, Open Graph e canonical são renderizados no servidor na publicação. A URL anterior redireciona após uma renomeação publicada; rascunhos não mudam o endereço ao vivo. Este ambiente permanece noindex.
• Editor visual com parágrafos, H2/H3, negrito, itálico, listas e links HTTPS, sincronizado com Markdown. É um subconjunto deliberado; não promete suporte integral a CommonMark. HTML, scripts, embeds e imagens via texto não são aceitos.
• Biblioteca em grade/lista, ordem dos conteúdos e botão com texto próprio. O visitante também pode alternar grade/lista sem alterar a configuração publicada.
• Conteúdos do tipo link ou PDF, cada um com título, descrição formatada e modalidade direto/lead/pago. Arquivos são vinculados à oferta; títulos e capa não revelam o asset privado.
• Banner independente do fundo da página, com foto, altura, blur, escurecimento e ponto focal; avatar, cor do painel e destaque.

O painel permite upload e vinculação de PDFs até 10 MB e fotos PNG/JPEG/WebP até 5 MB. O navegador reencodifica imagens; o backend verifica tamanho e assinatura, rejeitando HTML/SVG e arquivos incompatíveis. A validação antimalware e o pipeline completo de produção continuam pendentes: usar arquivos de teste nesta etapa.

Um PDF direto de demonstração pode ser baixado de verdade. PDFs marcados como lead/pago não são entregues publicamente nesta etapa; a tela explica que o fluxo de concessão de acesso ainda precisa ser implementado. O mesmo arquivo não pode ficar público em uma campanha e ser apresentado como privado em outra. Mudanças de acesso só afetam a revisão publicada, e não impedem redistribuição de cópias já baixadas.

Persistência local: SQLite nativo do Bun em volume Docker, com campanhas, revisões publicadas, histórico de slugs, arquivos e eventos. É uma solução para o teste local com um dono, sem dependência nova. PostgreSQL, object storage privado, autenticação de contas e isolamento por tenant seguem como alvo do SaaS, com migração e testes antes de aceitar dados de clientes reais.

15. Analytics por identificador e eventos automáticos

Sim: o criador pode informar um Measurement ID do GA4, e o site emite automaticamente os eventos que implementamos. O campo aceita um identificador validado, nunca código HTML/JavaScript. Analytics próprio funciona sem configurar um provedor externo, sempre condicionado à escolha do visitante para a coleta opcional.

O site publicado oferece aceitar/rejeitar analytics com igual esforço e acesso posterior às preferências. Antes de aceitar, não carrega a tag externa nem transmite eventos opcionais. A prévia administrativa não rastreia. Cada campanha tem preferências e prefixos de cookies próprios; URLs enviadas não incluem query/fragmento e não enviamos valores de formulário, nome, e-mail ou telefone nos eventos.

Recebimento no coletor próprio: payload fechado, nomes enumerados, campanha/offer válidos, limite por campanha e retenção local de até 30 dias/5.000 eventos por campanha. O painel exibe totais agregados, sem identificador de visitante. Eventos do navegador são aproximados e podem ser falsificados; limites reduzem abuso, mas não tornam um clique prova financeira. Nenhum evento cliente pode declarar pagamento.

generate_lead e purchase só serão emitidos quando os fluxos correspondentes existirem e forem confirmados pela operação real. O navegador não deve interpretar clique em CTA ou retorno de checkout como compra. Para APIs externas, confirmação no backend, deduplicação e política de reenvio serão implementadas junto da entrega/pagamento.

Um ID não configura todo tipo de rastreamento: GTM precisa de tags/triggers e governança do container; está planejado, não executado neste módulo. Meta Pixel e integrações de conversão também são posteriores. Para GA4, o adaptador não garante medição completa nem configura a propriedade do cliente; revisar Enhanced Measurement e evitar autoeventos duplicados ou coleta extra. Bloqueadores, rede e recusa são limites legítimos.

Fontes oficiais verificadas: eventos GA4, configuração de eventos, Consent Mode, dataLayer do GTM e escopo de cookies.

16. Acesso, termos e movimento

O painel deixou de depender de um popup HTTP Basic. O login agora fica em /entrar/, com senha visível sob escolha, erros claros e sessão HttpOnly de 12 horas. /painel redireciona para o formulário; API privada retorna 401 sem abrir popup. Logout e expiração revogam o acesso; sessões guardam somente o hash do token. Mudança na versão dos termos exige novo aceite.

Termos em /termos/ e privacidade em /privacidade/, acessíveis no login e nos rodapés. O formulário registra o aceite da versão vigente separadamente de marketing e analytics. A minuta declara o estágio de demonstração, conteúdo permitido, responsabilidade sobre materiais, direitos sobre arquivos, limites de entrega, privacidade, disponibilidade e condições comerciais futuras. Identificação jurídica, atendimento e revisão para lançamento seguem pendentes; não há empresa, CNPJ ou política de reembolso inventados.

Movimento: entradas curtas, elevação em hover, feedback de botão, troca de biblioteca, abas e abertura de diálogos. Usar opacity/transform, sem scroll listeners ou efeitos contínuos no fundo. Respeitar prefers-reduced-motion tanto no CSS quanto nas animações disparadas por JavaScript. Sem JavaScript, os conteúdos públicos continuam visíveis; a área de edição e login requer JavaScript.