Care sunt componentele datelor despre evenimente?

Aceasta este partea a patra a seriei de cinci părți despre Datele clienților. Iată părțile unu, doi și trei.

Datele clienților cuprind date despre evenimente și date despre entități - știți deja acest lucru dacă ați trecut prin partea întâi (Ce sunt datele clienților?).

În acest ghid, veți afla despre componentele datelor despre evenimente, convenția de denumire preferată pentru definirea evenimentelor, categoriile de date ale entităților și cele două tipuri principale de entități.

Date despre eveniment

Deoarece probabil ați cumpărat lucruri online, să începem cu un exemplu de comerț electronic.

Când interacționați cu o aplicație de comerț electronic (web sau mobil), de obicei cumpărați un produs adăugându-l în coș, procedând la finalizarea comenzii și finalizarea plății - acestea sunt evenimente pe care le efectuați atunci când treceți prin procesul de cumpărare a unui articol pe aplicația.

Călătoria cumpărătorului, totuși, nu este atât de simplă și există câteva alte evenimente care pot avea loc, cum ar fi:

• Un produs este vizualizat
• Căruciorul este vizualizat
• Un produs este scos din coș
• Se aplică un cupon
• Se alege o adresă
• Se alege o metodă de plată
• O comandă este finalizată

Si asa mai departe.

Evenimente obișnuite, cum ar fi Adăugați în coș, Proceed to Checkout și Efectuați plata , vă vin în minte imediat, dar pentru a înțelege comportamentul utilizatorului, trebuie să urmăriți și alte evenimente precum cele menționate mai sus.

Decizia ce evenimente să urmăriți și denumirea evenimentelor folosind o convenție de denumire adecvată sunt primii doi pași în procesul de colectare a datelor despre evenimente.

Care sunt următorii doi pași?

Mă bucur că ai întrebat!

Fiecare eveniment este însoțit de proprietăți (sau atribute de eveniment ) care oferă mai mult context despre un eveniment. Decizia ce proprietăți să se asocieze cu un eveniment și denumirea acelor proprietăți sunt următorii doi pași în procesul de colectare a datelor despre eveniment.

Ce este într-un nume?

Când vine vorba de date, totul.

O convenție de denumire sau o taxonomie adecvată este ceea ce face ca datele bune să iasă în evidență de datele proaste și le permite părților interesate să înțeleagă la ce se uită. Nemenținerea unei taxonomii standardizate, pe de altă parte, este una dintre cauzele principale pentru care seturile de date sunt denaturate sau umflate cu redundanță.

De asemenea, atunci când lucrați cu datele clienților, nemenținerea majusculei uniforme la denumirea evenimentelor și a proprietăților evenimentului este una dintre cele mai mari greșeli pe care le puteți face — una care poate avea ramificații pe termen lung. O convenție bună de denumire ar trebui să fie întotdeauna însoțită de linii directoare stricte pentru majuscule.

Iata de ce:

Adaugă în coș, added_to_cart, productAdded, adaugă în coș, Adăugat în coș, Produs adăugat sunt moduri diferite de a defini același eveniment.

Deși niciuna dintre acestea nu este greșită în sine și nu există reguli stabilite când vine vorba de denumirea evenimentelor și proprietăților, există cele mai bune practici pe care ar trebui să ia în considerare următoarele.

Convenția de denumire obiect-acțiune a devenit aproape standardul industriei și din motive întemeiate - descrie în mod clar acțiunea care a avut deja loc. Produs adăugat înseamnă cu siguranță că un obiect (produs) este urmat de o acțiune (adăugat).

Aflați mai multe despre configurarea unei taxonomii consistente pentru evenimentele dvs.

Componentele datelor despre eveniment

Există două componente cheie ale unui eveniment: o entitate (una sau mai multe) și proprietățile evenimentului.

Asocierea datelor de entitate, cum ar fi user_id , cu un eveniment oferă informații despre utilizatorul care a efectuat evenimentul.

În absența unui identificator unic, cum ar fi user_id , datele despre eveniment vor rămâne anonime și nu va exista nicio modalitate de a ști cine a efectuat evenimentul respectiv. În mod similar, în contextul B2B SaaS, în care un utilizator poate face parte din mai multe organizații, organization_id trebuie să fie asociat cu evenimente pentru a ști unde au loc evenimentele.

Pe lângă entități, există și alte informații care pot fi adunate în scopul analizei și segmentării atunci când au loc evenimente.

Revenind la exemplul de comerț electronic, atunci când un produs este achiziționat, pe lângă faptul că știi cine a făcut achiziția, cel puțin, trebuie să știi și ce produs a fost achiziționat la ce preț și când .

Aceste informații suplimentare sunt adunate sub forma proprietăților evenimentului .

În prima parte a acestei serii, s-a menționat că datele despre evenimente cuprind trei elemente cheie:

• Acțiunea sau evenimentul care a avut loc
• Marca temporală sau data și ora exactă la care a avut loc evenimentul
• Starea sau toate celelalte proprietăți asociate cu evenimentul (cunoscute ca proprietăți ale evenimentului)

Să ne uităm la evenimentul Product Added (numele în cazul corect conform cadrului obiect-acțiune pentru evenimentul Add to Cart ) și să presupunem că a fost efectuat de un utilizator la 1 ianuarie 2020, la 10 am UTC. Datele culese în momentul producerii evenimentului includ următoarele:

• Acțiunea: Produs adăugat
• Marca temporală: 1577872800 (marca temporală Unix pentru ABZ 7.99 ( Statul: 0123 ABZ 7,99 ( Conform acestui exemplu, proprietățile asociate evenimentului Product Added sunt user_id, product_id, price și cantitate , fiecare dintre acestea oferind mai multe informații despre eveniment. Marca temporală este asociată cu evenimentul pentru a ști când a avut loc.

  De asemenea, este util să specificați un nume pentru marca temporală, care este în esență o proprietate de eveniment. Nu este obligatoriu să faceți acest lucru, deoarece practica standard este să asociați marcajul de timp ca marcaj de timp cu fiecare eveniment atunci când trimiteți date către instrumente terțe; cu toate acestea, specificarea unui nume distinct pentru proprietatea care stochează marcajul de timp poate fi utilă pe termen lung atunci când trebuie să lucrați cu date istorice despre evenimente.

  Taxonomia recomandată pentru marcajele de timp este numele evenimentului urmat de „la”: product_added_at pentru evenimentul Product Added.

  S-ar putea să fi observat deja că snake_case este folosit pentru a defini proprietățile evenimentului, ceea ce face mai ușor să distingeți numele evenimentelor de proprietățile evenimentului. Acestea fiind spuse, rețineți că nu există reguli predefinite aici și ar trebui să alegeți ceea ce funcționează cel mai bine pentru dvs. și pentru echipa dvs.

  Iată o privire finală asupra proprietăților asociate evenimentului Product Added și a tipurilor de date ale fiecăreia dintre aceste proprietăți:

  

  Specificarea tipului de date pentru fiecare proprietate asigură consistența datelor și facilitează procesul de instrumentare.

  

  Notă secundară: este bine să rețineți că Acum ar trebui să fie clar că colectarea datelor despre evenimente cuprinde următorii pași:

  • Deciderea evenimentelor de urmărit
  • Numirea acelor evenimente folosind o convenție de denumire adecvată
  • Decizia ce proprietăți să asocieze cu fiecare eveniment
  • Numirea acelor proprietăți folosind o convenție de denumire adecvată

  Următoarea (și ultima) parte a acestei serii acoperă procesul de decizie a evenimentelor de urmărit și ce date să colecteze.

  Cu toate acestea, ar trebui să aveți o idee bună la ce să vă așteptați când vă uitați la datele despre evenimente (fie într-un plan de urmărire înainte de instrumentare sau într-o destinație de date, cum ar fi instrumentul dvs. de analiză a produsului).

  Câteva evenimente comune și proprietățile lor

  Înainte de a continua, aruncați o privire la câteva evenimente și proprietăți comune care sunt urmărite de majoritatea produselor tehnologice.

  

  Tipuri de entități

  Este timpul să aruncăm o privire în profunzime asupra diferitelor entități și proprietăților lor. Dacă nu ați făcut-o deja, parcurgeți acest ghid pentru a înțelege cum se leagă datele entității cu datele despre evenimente.

  În prima parte a acestei serii, s-a menționat că datele partajate de utilizatori se încadrează în datele de entitate. Deși acest lucru este adevărat, nu toate datele entităților sunt partajate de utilizatori înșiși — datele despre entități pot fi, de asemenea, generate.

  Datele entității cuprind proprietăți asociate cu entitatea — dacă Utilizatorul este entitatea, toate informațiile despre un utilizator sunt adunate sub forma proprietăților utilizatorului.

  User_id este generat implicit pentru fiecare utilizator pentru a identifica utilizatorii (și acționează ca un identificator pentru evenimente.)

  Acestea fiind spuse, pentru moment, uitați de evenimente și gândiți-vă la diferitele informații care se referă exclusiv la utilizatori și vă vorbesc despre trăsăturile acestora.

  Tipuri de date de entitate

  Datele entităților pot fi clasificate în următoarele grupe (menționate și în partea 3 a acestei serii):

  • Informații de identificare personală, cum ar fi Date demografice , cum ar fi Personaj , cum ar fi Preferințe precum Date specifice produsului, cum ar fi Datele de sub fiecare grupă se încadrează în proprietățile utilizatorului. Cu alte cuvinte, proprietățile utilizatorilor stochează diverse detalii și trăsături despre utilizatori, permițându-vă să-i identificați și să aflați mai multe despre ei.

    În timp ce majoritatea informațiilor provin direct de la utilizator, anumite proprietăți ale utilizatorului sunt generate automat în timp, ca urmare a utilizării produsului.

    Dar datele despre evenimente nu sunt generate și din cauza utilizării produsului?

    Sigur este — proprietățile utilizatorului sunt detalii suplimentare legate de un eveniment adunat atunci când are loc evenimentul. Să aruncăm o privire la evenimentul Înscris și la proprietățile acestuia:

    

    După cum puteți vedea, toate proprietățile asociate cu acest eveniment oferă detalii despre utilizatori - detalii care sunt fie partajate de utilizatori înșiși ( nume, prenume, e-mail, telefon, țară ) sau detalii care sunt generate automat ( signed_up_at, user_id ).

    Este util să aveți în vedere următoarele:

    • Unele evenimente precum Înregistrarea sau Majoritatea proprietăților utilizatorilor care exclud marcajele de timp și identificatorii pot fi modificate. Un utilizator își poate schimba numele, adresa de e-mail, telefonul, locația, industria, rolul postului etc. Dar ora înregistrării (signed_up_at) sau identificatorul unic (user_id) nu poate fi schimbat de către utilizator.

    Proprietățile utilizatorului vs. proprietățile organizației

    Cu aplicațiile pentru consumatori, timpul petrecut, produsele achiziționate, melodiile redate sau videoclipurile vizionate sunt proprietăți asociate utilizatorului stocate ca proprietăți ale utilizatorului, ale căror valori sunt actualizate constant odată cu creșterea utilizării.

    În contextul B2B SaaS, Utilizatorul și Organizația sunt principalele entități, iar evenimentele colectate sunt legate de un utilizator sau de o organizație (sau ambele).

    Ar putea exista și alte entități de grup, cum ar fi o echipă sau un proiect, cu anumite date legate de ele, așa cum este cazul majorității instrumentelor de productivitate - procesul de colectare a datelor organizației este aplicabil și în astfel de cazuri.

    Să aruncăm o privire la câteva proprietăți comune ale utilizatorilor relevante pentru produsele B2B SaaS:

    

    Când un utilizator face parte dintr-o organizație , multe informații importante sunt legate de organizație și nu de utilizator.

    Unele proprietăți comune ale organizației (numite și proprietăți de grup ) sunt următoarele:

    

    Este important să rețineți că organizația_id acționează și ca un identificator și ar trebui să fie asociat cu evenimente pentru a ști sub ce organizație a avut loc un anumit eveniment.

    Menținerea următoarelor afirmații poate ajuta la diferențierea între proprietățile utilizatorului și proprietățile organizației:

    • Fiecare informație care ajută la definirea cohortelor de utilizatori - de unde provin, cine sunt, care este obiectivul lor sau ce fac în interiorul unui produs - este stocată ca proprietate de utilizator .
    • Fiecare informație care ajută la segmentarea conturilor sau organizațiilor — tipul de cont, veniturile pe care le generează, produsele sau caracteristicile pe care le folosește, resursele pe care le consumă sau numărul de utilizatori care fac parte din el — este stocată ca proprietate a organizației ( sau proprietatea grupului).

    Odată ce puteți face diferența între cele de mai sus, devine ușor să aduceți noi entități (cum ar fi echipe sau proiecte) în amestec.

    Pasii urmatori

    Acum ar trebui să înțelegeți clar cum să definiți evenimentele și proprietățile asociate acestora, precum și să specificați proprietățile fiecărei entități (utilizator și organizație).

    Pentru a începe să definiți evenimente și să vă organizați datele astăzi, începeți cu un cont Amplitude gratuit.