Em resumo
A Flowsery analisou 75.167 gravações de sessão de adaptlypost.com num mês e encontrou 3.338 falhas reais com origem em 66 causas distintas. Nove em cada dez dessas falhas não levantaram qualquer erro de consola ou de rede, e as sessões que traziam um erro eram uma falha real em 2,8 % dos casos. Seguem-se quatro achados, ordenados pelo que custaram e não pela frequência com que dispararam.
Entre 13 de julho e 13 de agosto de 2026, a Flowsery analisou 75.167 gravações de sessão de adaptlypost.com e assinalou 3.338 delas como uma falha real para o visitante. O agrupamento por causa reduziu-as a 66 bugs distintos: um crítico, sete altos, quinze médios, quarenta e três baixos.
3.019 das 3.338 falhas não traziam erro de consola nem erro de rede. Nove em cada dez. No mesmo mês, 11.598 sessões traziam de facto um erro, e 319 dessas eram uma falha real. Um monitor de erros teria alertado sobre as onze mil sessões erradas e dormido durante as três mil que importavam.
Os quatro achados abaixo estão ordenados pelo que custaram, não pela frequência com que dispararam.
Sobre a AdaptlyPost
A AdaptlyPost é um agendador de redes sociais vendido com um teste de 7 dias. Publica em cinco línguas e tem um blog com um glossário que o Google indexa. A AdaptlyPost e a Flowsery têm o mesmo fundador.
Como decorreu o estudo
A gravação de sessões corria no site há cerca de dois meses quando a análise com IA foi ligada, a 13 de julho de 2026. Este estudo cobre exatamente um mês a partir dessa data. As 75.167 gravações são esse atraso acumulado mais tudo o que o tráfego ao vivo produziu enquanto a pipeline corria.
Uma gravação conta como falha quando o visitante tentou fazer algo que a página oferecia e a página não o entregou. Uma recusa de cartão não é uma falha, porque um banco a dizer que não não é um bug. Um botão de pagamento que não faz nada quando clicado é. Cada falha traz uma severidade, passos de reprodução e um link para a gravação. As falhas com a mesma causa são agrupadas, e foi assim que 3.338 se tornaram 66.
Achado 1: o checkout bloqueou pagamentos de cinco formas diferentes
Sete sessões na janela terminaram com o próprio site a travar um pagamento, de cinco formas separadas.
Dois dos cinco, os erros de servidor, apareceriam num rastreador de erros. A regra de faturação é o sistema de pagamentos a funcionar como foi desenhado, a recusar um cliente que quer pagar mais. O botão PayPal morto não lança absolutamente nada. A página de upgrade em falta é um 404, e os 404 são ruído de fundo em qualquer site.
O único problema crítico estava na página de início de sessão em francês. Um visitante submeteu o formulário e a página mostrou "400: Bad Request", muito provavelmente porque o widget anti-bot nunca chegou a carregar. Foi-se embora. Um formulário de início de sessão devia dizer "Email ou palavra-passe inválidos", não mostrar um código HTTP.
Achado 2: um controlo engoliu cliques em 17 rotas
48 sessões em 17 rotas diferentes mostram o mesmo padrão. Um visitante clica num seletor, nada visível acontece, clica outra vez, e outra, e depois vai-se embora.
É um único componente, reutilizado em cada página que pede ao visitante para escolher algo.
- No editor de posts em alemão, um cliente com sessão iniciada abre as definições do Pinterest e clica repetidamente em "choose board". O dropdown nunca abre. Clica em "post now" na mesma. A publicação nunca sai.
- No gerador de posts com IA, "Select Platform" não produz resposta ao longo de vários cliques. O visitante desiste e clica no título da página.
- Na calculadora de tarifas de influenciadores, o botão de nível de envolvimento ignora seis segundos de cliques insistentes antes de finalmente registar.
- No verificador de disponibilidade de nome de utilizador, três cliques na lista de plataformas não fazem nada. O visitante nunca chega a "Check Availability".
Nenhum deles lança exceção. Em todos os casos é um handler de clique a disparar contra um componente cujo estado visual nunca se atualiza, pelo que o visitante não consegue distinguir "ignorado" de "avariado". Os cliques de raiva são o único sinal, e esse sinal só existe dentro de uma gravação.
Achado 3: as traduções que não carregaram
A AdaptlyPost publica em cinco línguas, e as costuras notam-se. Nove sessões na janela, em quatro rotas, terminaram com o visitante a olhar para algo que nunca devia ter sido texto: uma chave de tradução, uma página de erro na língua errada ou um texto de preenchimento.
| O que o visitante viu | Sessões | Onde | Sinal de erro |
|---|---|---|---|
| Chaves de tradução como texto da página | 5 | /en/media-kit | Nenhum |
| Uma página 500 depois de mudar de língua | 2 | Página inicial | HTTP 500 |
| Ficheiros JSON de língua a devolver 404 | 2 | Analisador de nível de leitura, um artigo do blog | 404 em segundo plano |
A página do media kit é o caso mais claro. Cinco visitantes aterraram nela e viram "brandFacts.mediaKit.title" e "brandFacts.mediaKit.description" onde deviam estar o título e o texto. Nenhum clicou em nada. A página devolveu 200 sem erros de consola, por isso nada a assinalou.
brandFacts.mediaKit.eyebrow
brandFacts.mediaKit.title
brandFacts.mediaKit.description
brandFacts.mediaKit.assetsDescription
Mudar a língua para português produziu uma página 500 com "Ocorreu um erro inesperado". O botão de tentar novamente carregou a página inicial em português, e 17 minutos depois o mesmo 500 voltou. Outro visitante recebeu na página inicial em inglês um overlay 500 cujo botão de tentar novamente dizia "Intentar otra vez", espanhol numa página em inglês.
O seletor de língua também pede ficheiros de língua que não existem. Uma sessão no analisador de nível de leitura registou 24 erros 404 em segundo plano para ficheiros como /locales/fr/gdpr.json. Mudar um artigo do blog para espanhol fez o mesmo.
Depois de a janela fechar, a 18 de agosto, a versão espanhola do guia de zonas seguras saiu com o texto de preenchimento "Original text" como título principal.
Nada disto lança um erro que ajude. As chaves em bruto e o texto de preenchimento são uma página a renderizar a string errada. Os 404 de língua são pedidos em segundo plano que ninguém vê. Só as páginas 500 alertariam alguém, e uma delas resolveu-se sozinha ao tentar novamente.
Achado 4: os URLs de glossário que devolvem 404
O maior achado em contagem de sessões, e o mais aborrecido, e foi assim que durou tanto tempo.
Os artigos de glossário da AdaptlyPost vivem em /blog/<slug>. A certa altura foram publicados, e depois indexados, em /blog/glossary-<slug>. O site não tem rota para a forma com prefixo.
- 382 URLs
/blog/glossary-*distintos apareceram em falhas, em 1.287 sessões - A maior parte desse tráfego chegou diretamente de um resultado de pesquisa
- Dez slugs de amostra verificados contra o diretório de conteúdo: oito dos dez artigos existem, no URL sem prefixo
Os artigos existem e posicionam. O URL que o Google indexou aponta para nada, e uma única regra de redirecionamento resolveria isso.
O que a monitorização de erros viu
Das 75.167 gravações analisadas, 11.598 traziam um erro de consola ou de rede. 319 dessas eram uma falha real e visível para o visitante. Isso são 2,8 % de precisão. Abra as repetições filtradas por "tem erros" e 97 em cada 100 serão um rastreador bloqueado ou um fetch cancelado.
O sentido inverso é pior. Das 3.338 falhas reais, 3.019 não traziam qualquer erro. A maior parte do que está acima vive nesses 90 %: o botão PayPal morto, a regra de faturação, os cliques engolidos, a página do media kit a imprimir as suas chaves de tradução.
De uma repetição a uma alteração revisível
No dia seguinte ao fecho da janela, o agente da Flowsery pegou no problema do seletor de envolvimento do Achado 2, leu a gravação e abriu um pull request contra a base de código da AdaptlyPost.
A sua leitura do bug: tocar numa opção atualizava um estado que o visitante não conseguia ver, por isso nada mudava no ecrã e o gravador apanhou dez cliques sem resposta. A alteração recableia o controlo para se comportar como os seletores do site que já funcionam. Um commit, um ficheiro.
Ponto de situação
| Achado | Sessões na janela | Sinal de erro | Estado |
|---|---|---|---|
| Checkout bloqueou pagamentos, de cinco formas | 7 | 2 de 5 modos | Corrigido |
| 400 em bruto no início de sessão | 1 | HTTP 400 | Corrigido |
| Seletor engoliu cliques | 48, em 17 rotas | Nenhum | Corrigido |
| Traduções que não carregaram | 9, em 4 rotas | 3 de 9 | Corrigido |
| URLs de glossário a devolver 404 | 1.287 | HTTP 404 | Corrigido |
O que mudou no mês foi a forma do backlog. Antes de 13 de julho era aquilo que a alguém calhava reparar. Depois, é uma lista ordenada onde cada entrada traz uma contagem de sessões, uma data de primeira aparição, uma severidade, passos de reprodução e uma gravação para abrir.
"Devíamos olhar para o checkout" perde contra um item de roadmap. "Sete pessoas tentaram pagar e o checkout travou-as, de cinco formas diferentes, e aqui está a gravação de uma delas" não perde.
O que se generaliza
- Um 200 com uma página completamente renderizada
- Um 200 a transportar uma mensagem de erro
- Um handler de clique que disparou normalmente
- 11.598 sessões marcadas, 319 delas reais
- Um título que diz brandFacts.mediaKit.title
- Um cliente pagante a quem foi recusado um upgrade
- Dez cliques sem resposta, e depois o visitante a sair
- 3.338 falhas reais, 66 causas distintas
Ordene por custo, não por volume. Os 404 do glossário tocaram 1.287 sessões e os bugs do checkout tocaram sete, e os do checkout valem mais.
Trate os controlos silenciosos como bugs sem telemetria. Um dropdown morto não lança nada, não regista nada e devolve 200. A única prova de que existe é uma pessoa a clicar dez vezes no mesmo sítio, e essa prova está na gravação ou em lado nenhum.
Leia o que a página mostra, não o que o servidor devolveu. Um título que diz brandFacts.mediaKit.title é um 200 sem erros de consola, e uma página em espanhol cujo título principal é "Original text" também. Nenhum aparece como quebra de funil, porque o visitante nunca entrou no funil.