Uma verificação de disponibilidade pode estar verde enquanto a loja perde encomendas em silêncio. A página inicial devolve 200. A página do produto devolve 200. Um código promocional põe o total a zero, um método de envio desaparece para um país, ou o evento de compra não dispara, e o monitor não tem nada a dizer. Deixei de tratar “o site está no ar” como notícia. A notícia é se um comprador consegue pagar.
Segue o comprador, não a página de estado
Numa loja WordPress ou WooCommerce ao vivo percorro um caminho e escrevo onde ele dobra:
O carrinho mostra o artigo, o preço e a quantidade que o comprador vê mesmo. O envio oferece o método que pertence a essa morada, não um método que sobrou de uma zona de teste. Um código promocional muda o total de propósito, ou não toca no total de todo. O pagamento continua a listar Stripe, PayPal e o método que tende a desaparecer para um tipo de produto. A analítica recebe o evento de compra numa encomenda real, não num clique que se parecia com uma.
Qualquer uma dessas coisas pode falhar enquanto o servidor parece saudável. Já vi lojas a celebrar uma página inicial rápida na mesma semana em que o evento de checkout deixou de chegar à conta de anúncios. Os anúncios continuavam a gastar. A loja continuava a “converter” na cabeça do dono. O relatório não concordava, e ninguém tinha aberto o relatório.
| A luz | O que ainda pode estar errado |
|---|---|
| Página inicial 200 | O pedido de adicionar ao carrinho falha para um cliente com sessão. |
| Página de produto rápida | A zona de envio do país principal não devolve nada. |
| O checkout carrega | Um código da época passada põe o total a zero. |
| Plugin de pagamento ativo | Um tipo de produto faz cair o único método que os compradores usam. |
| O gestor de etiquetas está | O evento de compra dispara no botão, não na encomenda paga. |
A velocidade faz parte do caminho, não um passatempo à parte
Um carrinho lento é um carrinho falhado para uma parte dos compradores, por isso meço o caminho, não uma nota de laboratório na página inicial. Uma cache que torna a primeira vista rápida e deixa o carrinho velho não é uma vitória. Prefiro uma página de produto um pouco mais lenta do que um carrinho com o preço de ontem.
Isto não é um teste de intrusão
Percorrer o caminho do dinheiro não é um teste de penetração, e não o vendo como tal. Também não faz a loja aparecer num motor de respostas. São trabalhos diferentes, com provas diferentes. O que posso dizer ao fim de cinco dias é mais estreito e mais útil: aqui cai uma encomenda, isto é o que está em risco, esta é a ordem em que o corrigiria.
Se a única prova de saúde é um código de estado, está a medir o humor do servidor, não a receita da loja.
Um código é um programa pequeno
Abro a lista de códigos que ainda estão activos e experimento os aborrecidos, não uma cadeia ao acaso. Um código da época passada que nunca foi encerrado. Um código que se acumula sobre um preço que já está reduzido. Um código que se aplica à linha de envio quando todos acreditam que se aplica ao produto. Cada um são umas linhas de configuração, e cada um muda o que o comprador paga. Prefiro passar uma hora nessa lista a um dia a discutir um tema novo.
A mesma paciência vai para as zonas de envio. A zona do país que realmente compra é a que testo, com um código postal desse país, não com a morada da própria loja. Um método que aparece para o código do dono e desaparece para um cliente é um erro normal. Não chama ninguém. Limita-se a tirar a encomenda.
O entregável em que confio é uma lista curta com um dono e uma forma de saber que a correcção funcionou. “Melhorar a conversão” não é uma lista. “O código SAVE10 ignora o preço de promoção e acumula-se sobre si próprio” é uma lista. A segunda frase pode ser testada numa encomenda de staging esta semana. A primeira pode ser discutida durante um ano.
