Web arazo gehienak ez dira goizero begiratzen dituzun dashboardetan agertzen

Oso ohikoa da talde digitaletan: analytics panela irekitzen duzu, bihurketen edo diru-sarreren jaitsiera ikusten duzu, eta berehala hasten zara beste grafikoetan azalpen baten bila. Trafikoa, kanpaina, gailua, kargatze-abiadura... dena susmagarri bihurtzen da. Baina dashboard-ak jaitsiera erakusten duenerako, arazoa dagoeneko martxan egon ohi da.

Hori da web kudeaketako puntu itsu nagusia: analitikak ondorioak erakusten ditu, ez kausak. Salmenta-neurketek ondorioak erakusten dituzte, ez kausak. KPI dashboard-ek ondorioak erakusten dituzte, ez kausak. Baliagarriak dira, baina oso gutxitan azaltzen dute zer izan den benetako abiarazlea.

Zergatik iristen diren dashboard-ak berandu

Dashboard-ak oso onak dira zer gertatu den erantzuteko. Baina zergatik gertatu den galdetzean, askotan motz geratzen dira. Orrialde bat motelduz gero, script batek interakzio bat apurtuz gero, irudi bat handiegia bada edo esteka batek helmuga hautsi batera eramaten badu, negozioaren inpaktua geroago ager daiteke: bihurketa txikiagoak, engagement ahulagoa edo kanpaina-emaitza okerragoak.

Arazoa da kausa tekniko horiek beste aldagai batzuekin nahasten direla. Salmenten jaitsiera bat sasoikotasunarekin, kanpaina-aldaketarekin edo gailu-mixaren aldaketarekin batera etor daiteke. Erabiltzailearen benetako esperientziatik gertu dagoen behaketa-geruza teknikorik gabe, taldeak hipotesiak eztabaidatzen amaitzen du, ekintzak lehenetsi beharrean.

Zer geratzen den maiz radarretik kanpo

Web arazo asko ez dira negozio-neurri gisa hasten. Frikzio tekniko gisa hasten dira: JavaScript erroreak, AJAX eskaeretako HTTP hutsegiteak, baliabideen kargatze-erroreak, tamaina handiegiko edo txikiegiko irudiak, TTFB altua edo CLS-n islatzen den ezegonkortasun bisuala.

Badira arazo sotilagoak ere, baina berdin garestiak: barne-nabigaziotik, kanpo-iturrietatik edo kanpainetatik datozen esteka hautsiak; nabigatzaile, sistema eragile edo bereizmen jakin bati soilik eragiten dioten akatsak; eta une kritikoetan errendimendua hondatzen duten orriak. Dashboard finantzario batean, hori guztia berandu eta nahastuta agertu ohi da.

Egin galdera egokia

“Zer jaitsi da?” galdetu beharrean, hobe da galdetzea: “Zer aldatu da teknikoki jaitsiera eragin zezakeena?”. Ikuspegi-aldaketa horrek taldearen lana aldatzen du. Helburua ez da zenbakiak atzetik jarraitzea, baizik eta neurgarriak diren frikzioak identifikatzea eta benetako erabiltzaile-inpaktuaren arabera ordenatzea.

Horretan laguntzen du negozio-analitika eta behaketa teknikoa bereizteak. Salmenta-analitikak bihurketa jaitsi dela esan dezake. Web observability-ak lagundu dezake erroreak handitu ote diren, full load time okertu ote den edo nabigatzaile zehatz batek intzidentzia gehiago dituen ikusten.

Iturrira eramaten duten seinaleak

Erreakziotik diagnostikora igaro nahi baduzu, komeni da arazoaren iturritik gertuago dauden seinaleak jarraitzea. Baliagarrienak hauek izan ohi dira:

• TTFB, zerbitzariaren hasierako erantzunean atzerapenak hautemateko.
• CLS, interakzioa oztopa dezakeen ezegonkortasun bisuala identifikatzeko.
• Usable time eta full load time, orria noiz bihurtzen den benetan erabilgarri ulertzeko.
• JavaScript eta AJAX erroreak, askotan urrats kritikoak isilean apurtzen dituztenak.
• Baliabideen kargatze-hutsegiteak, funtzioa edo diseinua kaltetzen dutenak.
• Esteka hautsiak, batez ere kanpainetatik edo trafiko handiko barne-orrialdeetatik datozenean.

Seinale horiek baliagarriak dira arazoa non hasten den erakusten dutelako, ez soilik negozio-inpaktua non agertzen den.

Lehenetsi inpaktuaren arabera, ez zarataren arabera

Errore guztiek ez dute premia bera. Trafiko gutxiko orri batean gertatutako akats isolatu batek ez du pisu bera landing nagusi batean edo bihurketa-urrats kritiko batean errepikatzen den intzidentzia batek baino. Horregatik, lehentasuna erabiltzaileengan duen inpaktuaren arabera ezarri beharko litzateke, ez alerta kopuru gordinaren arabera.

Erroreak taldekatzen eta kategorietan banatzen direnean, patroiak argiago ikusten dira: zein arazo errepikatzen den, zein testuingurutan agertzen den eta zein orritan eragiten duen. Horrek errazago egiten du erabakitzea hurrengo pausoa script bat berrikustea, esteka bat zuzentzea, irudi bat optimizatzea edo errendimendu-jaitsiera bat ikertzea den.

Ikuspegi erabilgarriagoa marketin, produktu eta teknologiaren artean

Ikuspegi honek tentsio arrunt bat arintzen du. Marketinak bihurketaren jaitsiera ikusten du, produktuak frikzioa antzematen du eta teknologiak sintoma berandu jasotzen du. Denek froga tekniko bera ikusten dutenean, elkarrizketa aldatzen da. Ez da hipotesiak defendatzea, baizik eta inpaktua non dagoen eta zer lehenetsi behar den ulertzea.

Intzidentziak nabigatzailearen, sistema eragilearen edo bereizmenaren arabera segmentatzeak ikuspegi agregatuan desagertzen diren arazoak ere agerian utz ditzake. Batzuetan arazoa ez da globala; audientziaren segmentu jakin bati eragiten dio. Eta segmentu hori kanpaina, eskualde edo gailu-multzo garrantzitsu batekin bat badator, kostua dashboard-ak iradokitzen duena baino handiagoa izan daiteke.

Nola hasi konplikatu gabe

Ez duzu neurketa guztia egun batetik bestera aldatu behar. Hasi orri kritikoen zerrenda labur batekin: home, kanpaina-landingak, produktu-orriak eta bihurketa-urrats nagusiak. Ondoren, behatu zer errore tekniko agertzen diren, nola biltzen diren eta trafikoarekin eta bihurketarekin zer harreman duten.

Helburua ez da datu gehiago pilatzea, erabaki hobeak hartzeko seinale hobeak izatea baizik. Neurri bat jaisten denean, iturrira lehenago iritsi nahi duzu. Eta horretarako, negozio-dashboard-ak istorioaren zati bat baino ez dira.