Un controllo di disponibilità può essere verde mentre il negozio perde ordini in silenzio. La homepage restituisce 200. La scheda prodotto restituisce 200. Un codice promozionale azzera il totale, un metodo di spedizione sparisce per un paese, o l’evento di acquisto non parte, e il monitor non ha nulla da dire. Ho smesso di trattare “il sito è su” come notizia. La notizia è se chi compra può pagare.
Segui il compratore, non la pagina di stato
In un negozio WordPress o WooCommerce vivo percorro un percorso e scrivo dove piega:
Il carrello mostra l’articolo, il prezzo e la quantità che chi compra vede davvero. La spedizione offre il metodo che appartiene a quell’indirizzo, non un metodo rimasto da una zona di prova. Un codice promozionale cambia il totale di proposito, oppure non tocca affatto il totale. Il pagamento elenca ancora Stripe, PayPal e il metodo che tende a sparire per un tipo di prodotto. L’analisi riceve l’evento di acquisto su un ordine vero, non su un clic che gli somigliava.
Ognuna di quelle cose può fallire mentre il server sembra sano. Ho visto negozi festeggiare una homepage veloce nella stessa settimana in cui l’evento di checkout ha smesso di arrivare all’account pubblicitario. Gli annunci continuavano a spendere. Il negozio continuava a “convertire” nella testa del proprietario. Il report non era d’accordo, e nessuno aveva aperto il report.
| La spia | Cosa può ancora essere sbagliato |
|---|---|
| Home 200 | La richiesta di aggiunta al carrello fallisce per un cliente entrato. |
| Scheda prodotto veloce | La zona di spedizione del paese principale non restituisce nulla. |
| Il checkout si carica | Un codice della stagione scorsa mette il totale a zero. |
| Plugin di pagamento attivo | Un tipo di prodotto fa cadere l’unico metodo che i compratori usano. |
| Il tag manager c’è | L’evento di acquisto parte sul pulsante, non sull’ordine pagato. |
La velocità fa parte del percorso, non un hobby a parte
Un carrello lento è un carrello fallito per una parte di chi compra, quindi misuro il percorso, non un voto di laboratorio sulla homepage. Una cache che rende veloce la prima vista e lascia il carrello vecchio non è una vittoria. Preferisco una scheda prodotto un po’ più lenta a un carrello che mostra il prezzo di ieri.
Non è un test di intrusione
Percorrere il percorso del denaro non è un test di penetrazione, e non lo vendo come tale. Non fa nemmeno comparire il negozio in un motore di risposte. Sono lavori diversi, con prove diverse. Quello che posso dire dopo cinque giorni è più stretto e più utile: qui cade un ordine, questo è a rischio, questo è l’ordine in cui lo sistemerei.
Se l’unica prova di salute è un codice di stato, stai misurando l’umore del server, non il ricavo del negozio.
Un codice è un piccolo programma
Apro l’elenco dei codici ancora attivi e provo quelli noiosi, non una stringa a caso. Un codice della stagione scorsa che non è mai stato chiuso. Un codice che si accumula su un prezzo già ridotto. Un codice che si applica alla riga di spedizione quando tutti credono che si applichi al prodotto. Ognuno sono poche righe di configurazione, e ognuno cambia ciò che paga chi compra. Preferisco un’ora su quell’elenco a un giorno a discutere un tema nuovo.
La stessa pazienza vale per le zone di spedizione. La zona del paese che compra davvero è quella che provo, con un codice postale di quel paese, non con l’indirizzo del negozio. Un metodo che compare per il codice del proprietario e sparisce per un cliente è un bug normale. Non chiama nessuno. Toglie solo l’ordine.
Il risultato di cui mi fido è una lista breve con un responsabile e un modo per capire che la correzione ha funzionato. “Migliorare la conversione” non è una lista. “Il codice SAVE10 ignora il prezzo in offerta e si accumula su se stesso” è una lista. La seconda frase si prova su un ordine di staging questa settimana. La prima si può discutere per un anno.
