Cum se monitorizează calitatea datelor — un ghid detaliat

Prevenirea unei erori în colectarea datelor este mai ușor decât abordarea consecințelor acesteia. Sagacitatea deciziilor tale de afaceri depinde de calitatea datelor tale. În acest articol, vă spunem cum să verificați calitatea datelor în toate etapele de colectare, de la declarația de lucru până la rapoartele finalizate.

Din păcate, multe companii care cheltuiesc resurse substanțiale stocând și procesând date încă iau decizii importante bazate pe intuiție și pe propriile așteptări în loc de date.

De ce se întâmplă asta? Neîncrederea în date este exacerbată de situațiile în care datele oferă un răspuns care este în contradicție cu așteptările decidentului. În plus, dacă cineva a întâlnit erori în date sau rapoarte în trecut, este înclinat să favorizeze intuiția. Acest lucru este de înțeles, deoarece o decizie luată pe baza unor date incorecte vă poate arunca înapoi, mai degrabă decât să vă avanseze.

Imaginați-vă că aveți un proiect cu mai multe valute. Analistul dvs. a configurat Google Analytics într-o singură monedă, iar agentul de marketing responsabil cu publicitatea contextuală a configurat importul costurilor în Google Analytics într-o altă monedă. Ca urmare, aveți o rentabilitate nerealistă a cheltuielilor publicitare (ROAS) în rapoartele campaniei dvs. de publicitate. Dacă nu observați această eroare la timp, puteți fie să dezactivați campaniile profitabile, fie să măriți bugetul pentru cele care înregistrează pierderi.

În plus, dezvoltatorii sunt de obicei foarte ocupați, iar implementarea analizei web este o sarcină secundară pentru ei. În timp ce implementează noi funcționalități - de exemplu, un nou design pentru o unitate cu accesorii - dezvoltatorii pot uita să verifice dacă datele sunt colectate în Google Analytics. Ca urmare, când vine momentul să evaluăm eficacitatea noului design, se dovedește că colectarea datelor a fost întreruptă în urmă cu două săptămâni. Surprinde.

Imaginați-vă că ați făcut o eroare în timpul fazei de specificare. Dacă îl găsiți și îl corectați imediat, remedierea va fi relativ ieftină. Dacă eroarea este dezvăluită după implementare, la construirea rapoartelor sau chiar la luarea deciziilor, costul remedierii acesteia va fi foarte mare.

Colectarea datelor constă de obicei din cinci pași cheie:

1. Formulați o provocare de afaceri. Să presupunem că trebuie să evaluați eficiența unui algoritm pentru selectarea bunurilor dintr-un bloc de recomandări.
2. Analistul sau persoana responsabilă cu colectarea datelor proiectează un sistem de metrici care urmează să fie urmărite pe site.
3. Persoana configurează Google Analytics și Google Tag Manager.
4. Cel care trimite termeni de referință pentru ca dezvoltatorii să le implementeze.
5. După ce dezvoltatorul implementează valorile și stabilește colectarea datelor, analistul lucrează cu rapoarte.

În aproape toate aceste etape, este foarte important să vă verificați datele. Este necesar să testați documentația tehnică, setările Google Analytics și Google Tag Manager și, bineînțeles, calitatea datelor colectate pe site-ul dvs. sau în aplicația dvs. mobilă.

Înainte de a trece la fiecare pas, să aruncăm o privire la câteva cerințe pentru testarea datelor:

• Nu poți testa fără instrumente. Cel puțin, va trebui să lucrați cu consola pentru dezvoltatori într-un browser.
• Nu există un rezultat abstract așteptat. Trebuie să știi exact cu ce ar trebui să ajungi. Avem întotdeauna un anumit set de parametri pe care trebuie să-i colectăm pentru orice interacțiune a utilizatorului cu un site. Și știm ce valori ar trebui să ia acești parametri.
• Sunt necesare cunoștințe speciale. Cel puțin, trebuie să fiți familiarizat cu documentația instrumentelor de analiză web pe care le utilizați, cu practica și cu experiența participanților pe piață.

După cum am menționat, este mult mai ușor să corectați o eroare dacă o prindeți în specificații. Prin urmare, verificarea documentației începe cu mult înainte de colectarea datelor. Să ne dăm seama de ce trebuie să vă verificăm documentația.

Scopurile documentației de testare:

• Remediați greșelile cu puțin efort. O eroare în documentație este doar o eroare în textul scris, așa că tot ce trebuie să faci este să faci o editare rapidă.
• Preveniți necesitatea unor modificări în viitor care pot afecta arhitectura site-ului/aplicației.
• Protejați reputația analistului. Un instrument cu erori de dezvoltare ar putea pune sub semnul întrebării competența celui care l-a redactat.

Cele mai frecvente erori în specificații:

1. Greșeli de tipar. Un dezvoltator poate copia numele parametrilor fără a le citi. Nu este vorba despre greșeli gramaticale sau de ortografie, ci mai degrabă despre nume incorecte ale parametrilor sau ale valorilor pe care le dețin acești parametri.
2. Ignorarea câmpurilor la urmărirea evenimentelor. De exemplu, un mesaj de eroare poate fi ignorat dacă un formular nu a fost trimis cu succes.
3. Nume de câmpuri nevalide și nepotrivire cu schema îmbunătățită de comerț electronic. Implementarea comerțului electronic îmbunătățit cu o variabilă dataLayer necesită o documentație clară. Prin urmare, este mai bine să verificați toate câmpurile de două ori atunci când vă redactați specificațiile.
4. Nu aveți suport valutar pentru un site cu mai multe monede. Această problemă este relevantă pentru toate rapoartele legate de venituri.
5. Limitele de accesare nu sunt luate în considerare. De exemplu, să presupunem că pot exista până la 30 de produse diferite pe o pagină de catalog. Dacă transferăm informații despre vizualizări în același timp pentru toate produsele, este probabil ca accesarea din Google Analytics să nu fie transferată.

Următorul pas după ce verificați documentația tehnică este să verificați setările Google Analytics și Google Tag Manager.

De ce să testați setările Google Analytics și Google Tag Manager?

• Asigurați-vă că parametrii sunt procesați corect de către sistemele de colectare a datelor. Google Analytics și Google Tag Manager pot fi configurate în paralel cu implementarea de metrici pe site-ul dvs. Și până când analistul nu termină, datele nu vor apărea în Google Analytics.
• Faceți mai ușor testarea valorilor încorporate pe site. Va trebui să vă concentrați doar pe o parte din munca dezvoltatorului. În etapa finală a lui X, va trebui să căutați cauza erorii direct pe site, nu în setările platformei.
• Cost redus de reparație, deoarece nu este nevoie să implicați dezvoltatori.

Cele mai frecvente erori în Google Analytics:

1. Nu a fost creată o variabilă personalizată. Acest lucru este relevant în special pentru conturile Google Analytics 360, care pot avea până la 200 de valori și 200 de parametri. În acest caz, este foarte ușor să ratezi unul.
2. Domeniul de acces specificat este nevalid. Nu veți putea detecta această eroare în timpul fazei de revizuire dataLayer sau examinând accesarea pe care o trimiteți, dar când creați raportul, veți vedea că datele nu arată așa cum vă așteptați.
3. Obțineți o copie a unui parametru existent. Această eroare nu afectează datele trimise, dar poate cauza probleme la verificarea și crearea rapoartelor.

Cele mai frecvente erori în Google Manager de etichete:

1. Nu au fost adăugați parametri, cum ar fi eticheta Universal Analytics sau variabila Setări Google Analytics.
2. Indexul din etichetă nu se potrivește cu parametrul din Google Analytics, creând riscul ca valorile să fie transmise parametrilor greșiți. De exemplu, să presupunem că ați specificat indexul parametrului numărului de utilizatori din GTM pentru parametrul de evaluare a articolului. Este posibil ca această eroare să fie găsită imediat la construirea rapoartelor, dar nu veți mai putea influența datele colectate.
3. Nume de variabilă nevalid specificat în dataLayer. Când creați un dataLayer, asigurați-vă că specificați sub ce nume va fi găsită variabila în matricea dataLayer. Dacă tastați sau scrieți o altă valoare, această variabilă nu va fi niciodată citită din dataLayer.
4. Urmărirea îmbunătățită a comerțului electronic nu este activată.
5. Declanșatorul de pornire nu este configurat corect. De exemplu, expresia regulată pentru declanșarea X este scrisă incorect sau există o eroare în numele evenimentului.

Ultima etapă de testare este testarea direct pe site. Această etapă necesită mai multe cunoștințe tehnice, deoarece va trebui să urmăriți codul, să verificați cum este instalat containerul și să citiți jurnalele. Deci, trebuie să fii priceput și să folosești instrumentele potrivite.

De ce să testați valorile încorporate?

• Verificați dacă ceea ce este implementat respectă specificațiile și înregistrați eventualele erori.
• Verificați dacă valorile de trimis sunt adecvate. Verificați dacă parametrii transmit valorile de transmis. De exemplu, categoria de mărfuri nu își trece numele.
• Oferiți feedback dezvoltatorilor cu privire la calitatea implementării. Pe baza acestui feedback, dezvoltatorii pot face modificări site-ului.

Cele mai frecvente greșeli:

1. Nu toate scenariile sunt acoperite. De exemplu, să presupunem că un articol poate fi adăugat în coș pe produs, catalog, promoție sau pagina principală, adică oriunde unde există un link către articol. Cu atât de multe puncte de intrare, poți rata ceva.
2. Sarcina nu este implementată pe toate paginile. Adică, pentru unele pagini sau anumite partiții/directoare, datele nu sunt colectate deloc sau sunt colectate doar parțial. Pentru a preveni astfel de situații, putem întocmi o listă de verificare. În unele cazuri, putem avea până la 100 de verificări pentru o funcție.
3. Nu toți parametrii sunt implementați; adică dataLayer-ul este implementat doar parțial.
4. Schema dataLayer pentru comerțul electronic îmbunătățit este întreruptă. Acest lucru este valabil mai ales pentru evenimente precum adăugarea de articole în coș, trecerea între pașii de plată și clicul pe articole. Una dintre cele mai frecvente erori în implementarea comerțului electronic îmbunătățit este lipsa parantezelor drepte din matricea Produse .
5. DataLayer folosește un șir gol în loc de null sau nedefinit pentru a zero parametrul. În acest caz, rapoartele Google Analytics conțin linii goale. Dacă utilizați null sau nedefinit, această opțiune nici măcar nu va fi inclusă în hit-ul pe care îl trimiteți.

Instrumente pe care le folosim pentru a testa datele:

• Extensia Google Analytics Debugger Chrome
• GTM Debugger, pe care îl puteți folosi pentru a activa modul de previzualizare în Google Tag Manager
• Comanda dataLayer din consola dezvoltatorului
• Fila Rețea din consola pentru dezvoltatori
• Extensia Chrome Google Tag Assistant

Să aruncăm o privire mai atentă la aceste instrumente.

Pentru a începe, trebuie să instalați această extensie în browser și să o activați. Apoi deschideți ID-ul paginii și accesați fila Consolă. Informațiile pe care le vedeți sunt furnizate de extensie.

Acest ecran arată parametrii care sunt transmise cu accesări și valorile care sunt transmise pentru acei parametri:

Există, de asemenea, un bloc extins de comerț electronic. Îl puteți găsi în consolă ca ec :

În plus, aici sunt afișate mesaje de eroare, cum ar fi pentru depășirea limitei de dimensiune a accesului.

Dacă trebuie să verificați compoziția dataLayer, cel mai simplu mod de a face acest lucru este să tastați comanda dataLayer în consolă:

Iată toți parametrii care sunt transmisi. Le puteți studia în detaliu și le puteți verifica. Fiecare acțiune de pe site este reflectată în dataLayer. Să presupunem că aveți șapte obiecte. Dacă faceți clic pe un câmp gol și apelați din nou comanda dataLayer , un al optulea obiect ar trebui să apară în consolă.

Pentru a accesa Google Tag Manager Debugger, deschideți contul Google Tag Manager și faceți clic pe butonul Previzualizare :

Apoi deschideți site-ul și reîmprospătați pagina. În panoul inferior, ar trebui să apară un panou care arată toate etichetele care rulează pe pagina respectivă.

Evenimentele care sunt adăugate la dataLayer sunt afișate în stânga. Făcând clic pe ele, puteți verifica compoziția în timp real a dataLayer.

Caracteristici ale testării browserului mobil:

• Pe smartphone-uri și tablete, site-urile pot fi lansate în modul adaptiv sau poate exista o versiune mobilă separată a site-ului. Dacă rulați versiunea mobilă a unui site pe desktop, aceasta va fi diferită de aceeași versiune de pe telefon.
• În general, extensiile nu pot fi instalate în browserele mobile.
• Pentru a compensa acest lucru, trebuie să activați modul Depanare în eticheta Universal Analytics sau în codul de urmărire Google Analytics de pe site.

Caracteristici ale testării aplicațiilor mobile:

• Lucrul cu codul aplicației necesită mai multe cunoștințe tehnice.
• Veți avea nevoie de un server proxy local pentru a intercepta accesările. Pentru a urmări numărul de solicitări pe care le trimite un dispozitiv, puteți filtra cererile după numele aplicației sau gazda către care sunt trimise.
• Toate accesările sunt colectate în format Measurement Protocol și necesită procesare suplimentară. Odată ce accesările au fost colectate și filtrate, acestea trebuie copiate și analizate în parametri. Puteți folosi orice instrument convenabil pentru a face acest lucru: Hit Builder, formule în Foi de calcul Google sau o aplicație JavaScript sau Python. Totul depinde de ce este mai convenabil pentru tine. În plus, veți avea nevoie de cunoștințe despre parametrii protocolului de măsurare pentru a identifica erorile în accesările trimise.

1. Conectați-vă dispozitivul mobil la laptop prin USB.
2. Deschideți Google Chrome pe dispozitivul dvs.
3. În consola pentru dezvoltatori Chrome, deschideți raportul Dispozitive la distanță:

1. Confirmați conexiunea la dispozitiv făcând clic pe Ok în caseta de dialog. Apoi selectați fila pe care doriți să o inspectați și faceți clic pe Inspectați .
2. Acum puteți lucra cu consola pentru dezvoltatori în modul standard, ca în browser. Veți avea toate filele familiare: Consolă, Rețea și altele.

1. Pentru a lucra cu o aplicație mobilă, trebuie să instalați și să rulați un server proxy. Îl recomandăm pe Charles.
2. Un server proxy este instalat, verificați la ce adresă IP se conectează aplicația:

3. Apoi luați dispozitivul și configurați conexiunea Wi-Fi prin serverul proxy folosind portul 8888. Acesta este portul pe care Charles îl folosește în mod implicit.

4. După aceea, este timpul să adune hit-uri. Rețineți că, în aplicații, accesările nu sunt trimise pentru a colecta, ci în loturi. Lotul este o solicitare pachet care vă ajută să trimiteți mai multe solicitări. În primul rând, economisește resursele aplicației. În al doilea rând, dacă există probleme de rețea, cererile vor fi stocate în aplicație și un pool comun va fi trimis imediat ce conexiunea la rețea este restabilită.

5. În cele din urmă, datele colectate trebuie analizate (dezasamblate) în parametri, verificate în ordine și verificate în raport cu specificațiile.

Acest pas este cel mai rapid și mai ușor. În același timp, se asigură că datele colectate în Google Analytics au sens. În rapoartele dvs., puteți verifica sute de scenarii diferite și puteți privi indicatorii în funcție de dispozitiv, browser etc. Dacă găsiți anomalii în date, puteți reda scriptul pe un anumit dispozitiv și într-un anumit browser.

De asemenea, puteți utiliza rapoartele Google Analytics pentru a verifica caracterul complet al datelor transferate la dataLayer. Adică, în funcție de fiecare dintre scenarii, variabila este completată, dacă există toți parametrii în ea, dacă parametrii iau valorile corecte etc.

Dorim să împărtășim cele mai utile rapoarte (în opinia noastră). Le puteți folosi ca listă de verificare a colectării datelor:

• Rapoarte de comerț electronic:
  • Performanța produsului
  • Performanța listei de produse
  • Promovare Internă
• Comportament — Evenimente — Cele mai importante evenimente
• Achiziție — Campanii — Analiza costurilor
• Rapoarte personalizate — De exemplu, unul care afișează comenzi duplicate

Să vedem cum arată aceste rapoarte în interfață și cărora dintre aceste rapoarte trebuie să fii atent mai întâi.

Cea mai valoroasă filă din acest raport este Comportamentul la cumpărături. Acesta analizează caracterul complet al colectării datelor în fiecare etapă a comerțului electronic îmbunătățit. Adică, putem vedea dacă Google Analytics transferă vizualizările listei de produse, clicurile, vizualizările cu detalii despre produse, adăugarea/ștergerea produselor în/din coș și achizițiile în sine.

La ce ar trebui să fim atenți aici? În primul rând, este foarte ciudat dacă aveți valori zero în oricare dintre coloane. În al doilea rând, dacă aveți mai multe valori într-o anumită etapă decât în ​​etapa anterioară, este posibil să aveți probleme la colectarea datelor. De exemplu, să presupunem că numărul de achiziții unice ale unui articol este mai mare decât numărul de achiziții. E ciudat și merită să fii atent.

De asemenea, puteți comuta între alți parametri din acest raport, care ar trebui să fie trimiși și către Enhanced ECommerce. De exemplu, dacă selectați Categorie de articole ca opțiune principală, este posibil să vedeți că există vânzări pentru anumite categorii de articole, dar nu există vizualizări pentru aceste articole, nicio adăugare la coș etc.

În primul rând, este necesar să parcurgeți toți parametrii care sunt transmisi către Google Analytics și să vedeți ce valori ia fiecare parametru. De obicei, este imediat clar dacă totul este în regulă. Analize mai detaliate pentru fiecare dintre evenimente pot fi efectuate în rapoarte personalizate.

Un alt raport standard care poate fi util pentru verificarea importului datelor de cheltuieli în Google Analytics este Analiza costurilor.

Vedem adesea rapoarte în care există cheltuieli pentru o sursă sau campanie publicitară, dar nu există sesiuni. Acest lucru poate fi cauzat de probleme sau erori ale etichetelor UTM. Ca alternativă, filtrele din Google Analytics pot exclude sesiunile dintr-o anumită sursă. Aceste rapoarte trebuie verificate din când în când.

Am dori să evidențiem raportul personalizat care vă permite să urmăriți tranzacțiile duplicate. Este foarte ușor de configurat: parametrul trebuie să fie un ID de tranzacție, iar dimensiunea cheie trebuie să fie tranzacții.

Rețineți că, atunci când există mai multe tranzacții în raport, aceasta înseamnă că informațiile despre aceeași comandă au fost trimise de mai multe ori.

Dacă găsiți o problemă similară, citiți aceste instrucțiuni detaliate despre cum să o remediați.

Google Analytics are un instrument de alerte personalizate foarte bun care vă permite să urmăriți modificările importante fără a vizualiza rapoarte. De exemplu, dacă nu mai colectați informații despre sesiunile Google Analytics, puteți primi o notificare prin e-mail.

Vă recomandăm să configurați notificări pentru cel puțin aceste patru valori:

• Numărul de sesiuni
• Rata de respingere
• Venituri
• Numărul de tranzacții

Din experiența noastră, aceasta este sarcina cea mai dificilă și consumatoare de timp - linia îngustă în care greșelile sunt cele mai frecvente.

Pentru a evita problemele cu implementarea dataLayer, verificările trebuie efectuate cel puțin o dată pe săptămână. În general, frecvența ar trebui să depindă de cât de des implementați modificările pe site. În mod ideal, trebuie să testați dataLayer după fiecare schimbare semnificativă. Este nevoie de timp pentru a face acest lucru manual, așa că am decis să automatizăm procesul.

Pentru a automatiza testarea, am construit o soluție bazată pe cloud care ne permite să:

• Verificați dacă variabila dataLayer de pe site se potrivește cu valoarea de referință
• Verificați disponibilitatea și funcționalitatea codului Google Manager de etichete
• Verificați dacă datele sunt trimise către Google Analytics și OWOX BI
• Colectați rapoarte de eroare în Google BigQuery

Avantajele automatizării testelor:

• Creșteți semnificativ viteza de testare. Din experiența noastră, puteți testa mii de pagini în câteva ore.
• Obțineți rezultate mai precise, deoarece factorul uman este exclus.
• Reduceți costul testării, deoarece aveți nevoie de mai puțini specialiști.
• Măriți frecvența testării, deoarece puteți rula teste după fiecare modificare a site-ului.

O schemă simplificată a algoritmului pe care îl folosim:

Când vă conectați la aplicația noastră, trebuie să specificați paginile pe care doriți să le verificați. Puteți face acest lucru încărcând un fișier CSV, specificând un link către harta site-ului sau pur și simplu specificând adresa URL a site-ului, caz în care aplicația va găsi harta site-ului în sine.

Apoi, este important să specificați schema dataLayer pentru fiecare scenariu de testat: pagini, evenimente, script-uri (o secvență de acțiuni, cum ar fi pentru checkout). Apoi puteți utiliza expresii regulate pentru a specifica dacă tipurile de pagină se potrivesc cu adresa URL.

După ce a primit toate aceste informații, aplicația noastră rulează prin toate paginile și evenimentele conform programului, verifică fiecare script și încarcă rezultatele testelor în Google BigQuery. Pe baza acestor date, am configurat notificări prin e-mail și Slack.

PS Dacă aveți nevoie de un audit complet al site-ului, puteți solicita servicii de consultanță de la OWOX BI. Înscrieți-vă pentru o demonstrație și vom discuta despre posibilități.