Audit de tracking înseamnă verificarea sistematică a modului în care datele sunt definite, colectate, transmise, procesate și folosite în deciziile comerciale. Auditul nu se limitează la confirmarea că un tag se declanșează. El trebuie să stabilească dacă informația măsurată reprezintă corect fenomenul analizat și dacă diferențele dintre sisteme pot schimba concluziile managementului.

O implementare poate funcționa tehnic și totuși să producă date nepotrivite pentru decizie. Evenimentul de achiziție poate ajunge în Google Analytics 4, dar cu o valoare greșită. Comanda poate fi înregistrată de două ori. Retururile pot lipsi. Platforma de advertising poate atribui aceeași vânzare după o regulă diferită de cea folosită în raportarea internă.

Problema nu este întotdeauna lipsa datelor. Uneori, problema este încrederea nejustificată în date care nu au fost validate.

Ce este un audit de tracking?

Un audit de tracking este procesul prin care o companie verifică dacă infrastructura sa de măsurare produce informații suficient de complete, corecte și coerente pentru utilizările declarate.

Aceste utilizări pot fi foarte diferite:

evaluarea performanței campaniilor;
alocarea bugetelor între canale;
analiza parcursului de cumpărare;
măsurarea ratei de conversie;
compararea veniturilor între segmente;
evaluarea profitabilității produselor;
construirea dashboardurilor de management;
antrenarea algoritmilor de licitare automată.

Fiecare utilizare impune alte cerințe. Un set de date poate fi suficient pentru analiza orientativă a traficului, dar insuficient pentru calcularea profitabilității campaniilor. Poate fi util pentru observarea unei tendințe, dar prea instabil pentru stabilirea bugetului trimestrial.

De aceea, rezultatul unui audit nu ar trebui să fie o simplă listă de taguri corecte și incorecte. Rezultatul trebuie să explice ce decizii pot fi susținute de datele actuale, unde există incertitudine și ce probleme trebuie remediate înainte ca indicatorii să fie folosiți comercial.

Audit de tracking, audit GA4 și verificarea tagurilor nu sunt același lucru

Termenii sunt folosiți frecvent ca și cum ar descrie aceeași activitate. Diferența pare mică, dar schimbă amploarea verificării.

Tipul verificării	Întrebarea principală	Limita obișnuită
Verificarea tagurilor	Se declanșează tagul în condițiile stabilite?	Nu demonstrează că datele sunt corecte comercial.
Audit GA4	Este configurată și utilizată corect proprietatea GA4?	Poate să nu acopere CRM-ul, ERP-ul și platformele de advertising.
Audit de tracking	Poate fi urmărit corect fenomenul necesar deciziei?	Necesită colaborare între tehnologie, marketing, analytics și business.

Un tag poate transmite exact ceea ce a fost programat și totuși să transmită valoarea nepotrivită. De exemplu, parametrul value poate include transportul și TVA-ul, în timp ce raportarea internă folosește venitul net fără aceste componente. Implementarea tehnică este funcțională. Comparația comercială nu este.

De ce un tracking funcțional poate produce decizii greșite

Evenimentul există, dar nu reprezintă corect acțiunea

Prezența unui eveniment într-un raport demonstrează că o informație a fost procesată. Nu demonstrează automat că evenimentul corespunde comportamentului pe care compania încearcă să îl măsoare.

Un eveniment denumit generate_lead se poate declanșa la apăsarea butonului de trimitere, chiar dacă formularul returnează o eroare. În raport, compania vede un lead. În realitate, nu a fost înregistrată nicio solicitare.

Într-un magazin online, evenimentul purchase se poate declanșa la încărcarea paginii de confirmare. Dacă pagina este reîncărcată și identificatorul tranzacției nu este gestionat corect, aceeași comandă poate fi transmisă din nou.

Valoarea transmisă nu este valoarea folosită în business

Venitul poate avea mai multe definiții legitime:

valoarea brută a comenzii;
valoarea fără TVA;
valoarea fără transport;
valoarea după discount;
valoarea facturată;
valoarea încasată;
valoarea după retururi și anulări.

Niciuna dintre aceste definiții nu este universal corectă. Problema apare când sistemele folosesc definiții diferite, iar rapoartele sunt comparate ca și cum baza de calcul ar fi aceeași.

O conversie nu are aceeași semnificație în toate platformele

Google Analytics 4, Google Ads, Meta Ads, CRM-ul și sistemul comercial pot raporta valori diferite fără ca toate diferențele să provină din erori.

Platformele pot utiliza:

ferestre de atribuire diferite;
modele de atribuire diferite;
momente diferite pentru înregistrarea conversiei;
fusuri orare diferite;
reguli diferite pentru conversiile post-vizualizare;
date observate și date modelate;
definiții diferite pentru utilizatori, sesiuni și comenzi.

Compararea directă a două coloane fără reconcilierea acestor reguli produce adesea o concluzie falsă: unul dintre sisteme ar fi „greșit”. Uneori există într-adevăr o eroare. Alteori, sistemele răspund la întrebări diferite.

Audit de tracking. Trebuie să înceapă de la decizie.

Un audit de tracking eficient începe cu decizia pe care compania încearcă să o ia, nu cu inventarul instrumentelor instalate.

Ordinea recomandată este:

definirea deciziei;
identificarea indicatorilor necesari;
stabilirea definiției fiecărui indicator;
identificarea evenimentelor și parametrilor necesari;
alegerea sistemului de referință;
verificarea implementării;
reconcilierea rezultatelor.

Să presupunem că managementul vrea să mute bugetul spre campaniile cu cea mai bună profitabilitate. Pentru această decizie nu sunt suficiente costul publicitar și venitul raportat de platformă.

Analiza poate necesita:

costul media;
venitul net;
marja produselor;
discounturile;
costul transportului suportat de companie;
retururile;
anulările;
clienții noi și recurenți;
costurile variabile asociate comenzii.

Dacă trackingul nu transmite sau nu poate conecta aceste informații, algoritmul poate optimiza veniturile, nu profitul. Indicatorul nu este neapărat calculat greșit. Este insuficient pentru decizia formulată.

Ce trebuie verificat într-un audit de tracking

Obiectivele și planul de măsurare

Planul de măsurare descrie legătura dintre obiective, întrebări de business, indicatori, evenimente, parametri și sursele datelor.

Auditul trebuie să verifice:

dacă fiecare indicator important are o definiție documentată;
dacă definiția este folosită consecvent în toate rapoartele;
dacă evenimentele colectate pot calcula indicatorul;
dacă există date colectate fără o utilizare clară;
dacă lipsesc informații necesare unor decizii importante;
dacă responsabilitatea pentru fiecare sursă este stabilită.

Fără acest pas, auditul riscă să valideze o implementare care măsoară riguros lucruri fără valoare decizională.

Arhitectura implementării

Trebuie inventariate toate componentele prin care trece informația:

site-ul sau aplicația;
stratul de date;
Google Tag Manager sau o implementare directă;
platforma de management al consimțământului;
GA4;
platformele de advertising;
server-side tagging, dacă există;
CRM-ul;
ERP-ul;
platforma e-commerce;
depozitul de date și instrumentele de business intelligence.

O eroare introdusă într-un singur punct poate fi propagată în toate rapoartele. De exemplu, o valoare greșită în stratul de date poate ajunge identic în GA4, Google Ads și dashboardul intern. Faptul că trei sisteme afișează aceeași valoare nu demonstrează că valoarea este corectă. Poate demonstra doar că toate folosesc aceeași sursă greșită.

Evenimentele și parametrii

Pentru fiecare eveniment important se verifică:

condiția exactă de declanșare;
momentul declanșării;
numărul de declanșări;
numele evenimentului;
parametrii obligatorii și opționali;
tipul datelor transmise;
valorile implicite;
comportamentul în caz de eroare;
diferențele între dispozitive, browsere și versiuni ale site-ului.

Testarea trebuie să includă atât traseul normal, cât și excepțiile. Un formular nu se verifică doar când este completat corect. Trebuie testate validarea, erorile serverului, trimiterea repetată și revenirea în pagină.

Identificatorii folosiți la reconciliere

Identificatorii permit conectarea aceleiași entități între sisteme. Pot fi identificatori de comandă, produs, client, lead, sesiune sau oportunitate.

Auditul trebuie să răspundă la câteva întrebări simple:

identificatorul este unic?
este stabil?
este transmis în toate sistemele relevante?
este păstrat în aceeași formă?
poate fi folosit fără ambiguitate la reconciliere?
respectă cerințele privind protecția datelor?

Fără un identificator comun, comparația rămâne agregată. O diferență de 8% poate fi observată, dar nu poate fi explicată la nivelul comenzilor care lipsesc sau diferă.

Cum se validează evenimentele în GA4

Validarea trebuie făcută în mai multe etape. Niciun instrument nu confirmă singur întregul flux.

Verificarea în browser

Google Tag Assistant și instrumentele de dezvoltare ale browserului pot arăta dacă tagurile se încarcă, când se declanșează și ce solicitări sunt trimise. Aici pot fi observate declanșările multiple, parametrii lipsă și solicitările blocate.

Verificarea în DebugView

DebugView permite observarea evenimentelor și a parametrilor transmiși în modul de depanare. Este util pentru verificarea secvenței evenimentelor și a valorilor la nivel de eveniment și produs.

Prezența evenimentului în DebugView confirmă că acesta a fost primit în contextul testului. Nu confirmă automat că toate scenariile reale sunt acoperite sau că valoarea este reconciliată cu sistemul comercial.

Verificarea în Realtime

Rapoartele Realtime pot confirma că evenimentele ajung în proprietatea potrivită. Sunt utile mai ales după verificarea structurii și a proprietății în care sunt trimise datele.

Validarea Measurement Protocol

Pentru evenimentele trimise prin Measurement Protocol, un răspuns HTTP reușit nu garantează că solicitarea este validă. Documentația Google precizează că Measurement Protocol nu returnează coduri de eroare HTTP pentru toate evenimentele incorect structurate. De aceea, solicitările trebuie testate prin serverul de validare înainte de implementarea în producție.

După validarea structurii, implementarea trebuie verificată separat în proprietatea reală, prin Realtime și DebugView.

Cum se verifică trackingul e-commerce

Trackingul e-commerce trebuie verificat pe întregul parcurs comercial, nu doar la achiziție.

Evenimentele relevante pot include:

vizualizarea listei de produse;
selectarea unui produs;
vizualizarea paginii de produs;
adăugarea în coș;
eliminarea din coș;
vizualizarea coșului;
începerea checkoutului;
adăugarea informațiilor de livrare;
adăugarea informațiilor de plată;
achiziția;
rambursarea.

Pentru fiecare etapă trebuie verificată atât declanșarea, cât și consistența produselor și valorilor transmise.

Produsele și cantitățile

Un eveniment de achiziție poate avea valoarea totală corectă, dar produse sau cantități greșite. Această eroare poate trece neobservată într-un raport agregat de venituri și poate compromite analiza portofoliului.

Trebuie comparate:

identificatorul produsului;
denumirea;
categoria;
varianta;
prețul unitar;
cantitatea;
discountul;
cuponul;
afilierea comercială, dacă este relevantă.

Valoarea, moneda și componentele comenzii

Dacă este transmis parametrul value, moneda trebuie transmisă consecvent. Auditul trebuie să stabilească ce include valoarea: produse, TVA, transport, taxe și discounturi.

Formula de control poate fi exprimată astfel:

Valoarea produselor = suma(preț unitar × cantitate) - discounturi aplicabile

Această valoare nu trebuie presupusă identică cu totalul comenzii. Transportul, taxele sau alte componente pot fi raportate separat.

Achizițiile duplicate

Documentația Google recomandă utilizarea unei singure metode principale de implementare pentru Google tag. Folosirea simultană și necontrolată a unei implementări directe și a Google Tag Manager poate produce numărări duble și alte efecte nedorite.

Duplicarea poate apărea și când:

pagina de confirmare este reîncărcată;
istoricul browserului redeschide pagina;
evenimentul este trimis atât din browser, cât și de pe server;
două taguri folosesc aceeași condiție;
un plugin și o implementare personalizată transmit aceeași achiziție.

De ce `transaction_id` este critic

transaction_id este identificatorul care permite recunoașterea aceleiași tranzacții și reconcilierea ei cu sistemul comercial.

În GA4, dacă același eveniment e-commerce este trimis de două ori cu același identificator al tranzacției, Google Analytics colectează prima apariție și o ignoră pe a doua. Acest comportament ajută la reducerea duplicării, dar nu elimină nevoia de testare.

Un identificator reutilizat greșit poate produce efectul opus: o achiziție reală poate fi ignorată. În timpul testării, reutilizarea aceluiași identificator poate face ca o versiune nouă a evenimentului să nu mai apară, chiar dacă parametrii au fost modificați.

Auditul trebuie să verifice dacă transaction_id:

este unic pentru fiecare comandă;
este identic în GA4 și platforma e-commerce;
nu conține valori dinamice instabile;
nu este gol sau înlocuit cu o valoare implicită;
poate lega achiziția de rambursare;
este păstrat în exporturile și dashboardurile ulterioare.

Cum se reconciliază datele între sisteme

Reconcilierea înseamnă compararea informațiilor după uniformizarea definițiilor, perioadelor și regulilor de calcul.

Alegerea sistemului de referință

Sistemul de referință depinde de întrebarea analizată.

Sistem	Ce poate reprezenta bine	Limită principală
Google Analytics 4	Interacțiuni și evenimente digitale	Nu este registrul comercial final al companiei.
Platforma e-commerce	Comenzi plasate și starea lor operațională	Poate să nu reflecte facturarea sau încasarea finală.
ERP	Facturi, livrări, retururi și date contabile	Poate pierde contextul sursei și al comportamentului digital.
CRM	Leaduri, oportunități și etapele comerciale	Calitatea depinde de procesele și disciplina de utilizare.
Platforma de advertising	Conversii atribuite pentru optimizarea campaniilor	Folosește propriile ferestre și modele de atribuire.

Pentru numărul comenzilor plasate, platforma e-commerce poate fi sursa operațională potrivită. Pentru venitul facturat, ERP-ul poate fi mai relevant. Pentru traseul digital anterior comenzii, GA4 poate oferi contextul necesar.

Uniformizarea perioadei

Înaintea comparației trebuie aliniate:

data de început și de sfârșit;
fusul orar;
momentul atribuit tranzacției;
latența procesării;
data comenzii, facturii, livrării sau încasării.

O comandă plasată la finalul zilei poate apărea în zile diferite în două sisteme care folosesc fusuri orare diferite. La nivel lunar, efectul poate fi redus. La nivel zilnic, poate schimba vizibil raportul.

Compararea la nivel de tranzacție

Compararea agregată arată dimensiunea diferenței. Compararea la nivel de transaction_id explică sursa ei.

Comenzile pot fi împărțite în patru categorii:

există în ambele sisteme și au aceeași valoare;
există în ambele sisteme, dar au valori diferite;
există numai în GA4;
există numai în sistemul comercial.

Fiecare categorie indică alte cauze posibile. Comenzile prezente numai în GA4 pot fi duplicate, teste sau comenzi eliminate ulterior. Comenzile prezente numai în platforma comercială pot proveni din blocarea trackingului, erori tehnice, lipsa consimțământului sau canale care nu trec prin fluxul digital măsurat.

Ce diferențe sunt acceptabile?

Nu există un prag universal care să transforme automat o diferență în eroare acceptabilă sau critică.

Toleranța depinde de:

decizia susținută;
volumul tranzacțiilor;
valoarea comenzilor;
stabilitatea diferenței;
distribuția erorii între segmente;
posibilitatea de reconciliere;
impactul asupra bugetelor;
gradul de modelare a datelor;
comportamentul consimțământului;
retururi și anulări.

O diferență agregată de 3% poate părea redusă. Dacă este concentrată în campaniile cu bugete mari sau în produsele cu marjă ridicată, implicația comercială poate fi disproporționată.

Invers, o diferență mai mare poate fi explicabilă atunci când sunt comparate comenzi plasate cu venituri facturate după anulări și retururi.

Pragul trebuie stabilit în funcție de utilizare. Datele pentru monitorizarea unei tendințe pot tolera o abatere mai mare decât datele folosite pentru remunerarea unui partener sau calcularea profitabilității.

Cum influențează consimțământul calitatea datelor

Platforma de management al consimțământului și Consent Mode modifică datele care pot fi observate și modul în care tagurile se comportă.

Consent Mode nu colectează consimțământul în locul companiei. El transmite către tagurile Google starea consimțământului comunicată de mecanismul implementat pe site.

Auditul trebuie să verifice:

starea implicită a consimțământului;
momentul în care starea este transmisă;
actualizarea după alegerea utilizatorului;
comportamentul tagurilor înainte și după alegere;
diferențele între pagini și domenii;
persistența preferinței;
funcționarea pe dispozitive și browsere diferite;
alinierea cu configurația platformelor de advertising.

Date observate și date modelate

În anumite condiții, GA4 poate utiliza modelare comportamentală pentru a estima comportamentul utilizatorilor care nu permit stocarea identificatorilor analytics. Datele modelate nu sunt echivalente cu observația directă.

Eligibilitatea pentru modelare depinde de implementare și de atingerea unor praguri de date. Prin urmare, existența Consent Mode nu demonstrează că proprietatea beneficiază automat de modelare.

În plus, suprafețele de raportare nu tratează întotdeauna datele în același mod. Rapoartele standard, explorările, Data API și exportul BigQuery pot prezenta diferențe deoarece folosesc niveluri de agregare, limitări și componente de modelare diferite.

Auditul trebuie să distingă între:

date observate;
date modelate;
date absente;
date filtrate;
date procesate după alte reguli.

Erori frecvente descoperite într-un audit de tracking

evenimentul purchase se declanșează înainte ca tranzacția să fie confirmată;
achiziția este trimisă atât prin Google Tag Manager, cât și prin codul site-ului;
transaction_id lipsește sau este reutilizat;
value include alte componente decât valoarea comparată în ERP;
moneda lipsește sau este transmisă greșit;
produsele din eveniment nu corespund produselor din comandă;
cantitățile sunt întotdeauna egale cu unu;
discounturile nu sunt transmise;
rambursările și anulările lipsesc;
formularele sunt măsurate la apăsarea butonului, nu la confirmarea trimiterii;
plata pe un domeniu extern rupe sesiunea sau modifică sursa;
mediul de test trimite evenimente în proprietatea de producție;
consimțământul este actualizat după declanșarea necontrolată a tagurilor;
numele evenimentelor diferă între site și aplicație;
parametrii personalizați nu sunt documentați;
definiția conversiei diferă între GA4, advertising și CRM;
modificările implementării nu sunt însoțite de testare și documentație.

Cum se prioritizează problemele identificate

Nu toate erorile trebuie corectate în aceeași ordine. Prioritatea trebuie stabilită după efectul asupra deciziilor, nu după cât de vizibilă este problema în instrumentul de testare.

Un model simplu de evaluare poate folosi formula:

Prioritate = impact decizional × frecvență × amplitudine × dificultatea detectării

Fiecare factor poate primi un scor de la 1 la 5.

Factor	Întrebarea de evaluare
Impact decizional	Poate eroarea schimba bugete, prețuri, investiții sau concluzii manageriale?
Frecvență	Cât de des apare problema?
Amplitudine	Cât de mare este abaterea produsă?
Dificultatea detectării	Poate problema rămâne neobservată în raportarea curentă?

Modelul nu produce un adevăr matematic. Rolul lui este să facă prioritizarea explicită și comparabilă.

O etichetă lipsă pe o pagină cu trafic redus poate fi ușor de observat și poate avea impact redus. O valoare greșită transmisă consecvent pentru toate achizițiile poate fi mai greu de detectat, deoarece rapoartele par stabile. Stabilitatea datelor nu este totuna cu exactitatea lor.

Ce trebuie să conțină raportul final de audit

Un raport util trebuie să permită echipelor să înțeleagă problema, să o corecteze și să verifice remedierea.

Raportul ar trebui să includă:

Scopul auditului – deciziile și procesele analizate.
Sistemele verificate – proprietăți, conturi, containere, domenii și fluxuri.
Harta datelor – sursele, transformările și destinațiile informației.
Inventarul evenimentelor – definiții, declanșări și parametri.
Scenariile testate – trasee normale, excepții și erori.
Dovezile – capturi, payloaduri, tranzacții și comparații.
Problemele identificate – cauza probabilă, nu doar simptomul.
Impactul – indicatorii și deciziile afectate.
Prioritatea – ordinea recomandată pentru remediere.
Recomandarea tehnică – schimbarea necesară.
Responsabilitatea – echipa sau rolul care trebuie să intervină.
Criteriul de acceptare – condiția prin care remedierea este considerată validă.
Planul de retestare – verificarea după implementare.

Formularea „evenimentul nu funcționează” nu este suficientă. Un diagnostic utilizabil trebuie să precizeze în ce condiții apare problema, ce date produce, ce raport afectează și cum se verifică soluția.

Checklist pentru audit de tracking

Strategia de măsurare

Există un plan de măsurare documentat?
Indicatorii sunt legați de decizii concrete?
Definițiile sunt identice în rapoarte și sisteme?
Este stabilită sursa de referință pentru fiecare indicator?

Implementarea tehnică

Este inventariată metoda de implementare?
Există taguri duplicate?
Evenimentele se declanșează în momentul corect?
Parametrii au formatul și valorile așteptate?
Mediile de test și producție sunt separate?

E-commerce

transaction_id este unic și stabil?
Valoarea și moneda sunt corecte?
Produsele, cantitățile și discounturile sunt complete?
Achizițiile duplicate sunt prevenite?
Retururile și rambursările sunt tratate?

Consimțământ

Starea implicită este transmisă înaintea tagurilor relevante?
Alegerea utilizatorului actualizează corect starea?
Preferința este păstrată?
Comportamentul este testat în mai multe browsere și scenarii?

Advertising

Conversiile importate au aceeași definiție?
Conversiile principale și secundare sunt configurate intenționat?
Valorile trimise algoritmilor corespund obiectivului comercial?
Sunt documentate ferestrele și regulile de atribuire?

Reconciliere

Perioada și fusul orar sunt identice?
Comenzile pot fi comparate prin identificator?
TVA-ul, transportul și discounturile sunt tratate identic?
Anulările și retururile sunt separate?
Diferențele pot fi explicate, nu doar cuantificate?

Guvernanță

Există documentație actualizată?
Modificările sunt aprobate și testate?
Există alerte pentru abateri importante?
Este stabilit cine răspunde pentru calitatea datelor?
Auditul este repetat după schimbări majore?

Audit de tracking: când pot fi folosite datele în decizii?

Audit de tracking nu înseamnă că toate sistemele trebuie să raporteze valori perfect identice. O astfel de așteptare ignoră diferențele legitime de definiție, procesare, consimțământ și atribuire.

Datele pot susține o decizie când sunt îndeplinite patru condiții:

indicatorul este definit fără ambiguitate;
implementarea măsoară fenomenul declarat;
diferențele dintre sisteme sunt explicate și monitorizate;
abaterea rămasă nu schimbă material decizia analizată.

Datele nu trebuie să fie perfecte. Trebuie să fie suficient de corecte pentru scopul în care sunt utilizate. Această diferență obligă compania să definească mai întâi decizia, toleranța și consecința unei erori.

Dacă GA4, platformele de advertising, magazinul online și sistemul comercial nu pot fi reconciliate, alegerea raportului care pare mai credibil nu rezolvă problema. Un audit de tracking trebuie să identifice unde se modifică informația, ce decizii sunt afectate și ce corecții au prioritate.

Surse și lecturi suplimentare

Google Analytics – Measure ecommerce – documentația oficială pentru evenimentele și parametrii e-commerce recomandați în GA4.
Google Analytics – Validate your ecommerce setup – metode de verificare a evenimentelor e-commerce, a identificatorilor tranzacțiilor și a duplicării.
Google Analytics – Validate Measurement Protocol events – explică validarea structurii evenimentelor înainte de utilizarea în producție.
Google Analytics – Verify Measurement Protocol implementation – descrie verificarea evenimentelor în Realtime și DebugView.
Google for Developers – Consent Mode – documentația oficială privind ajustarea comportamentului tagurilor în funcție de starea consimțământului.
Google Analytics Help – Behavioral modeling for consent mode – criterii și limite pentru modelarea comportamentală bazată pe datele observate.
Google Analytics Help – Reporting surfaces comparison – diferențele dintre rapoarte, explorări, Data API și exportul BigQuery.
Google Analytics Help – Data differences between reports and explorations – cauze documentate pentru diferențele dintre suprafețele de raportare GA4.

Continuă analiza

De ce diferă veniturile din GA4 de comenzile magazinului online – analiza continuă cu identificarea cauzelor pentru care valorile din analytics și sistemul comercial nu coincid.
Marja comercială în e-commerce și segmentarea portofoliului – explică de ce datele despre venituri trebuie completate cu informații despre marjă și rolul economic al produselor.