Universal Google Analytics - en kombination af mobil- og WEB-analyse. Opsætning af e-handelssporing for en Google Analytics-konto

Efter flere år på nettet er vores marketingfolk blevet vant til analysesystemer, de forstår dem, kender de fleste værktøjer og ved, hvordan de skal bruges. De lærte at arbejde med det på 5-10 år. Og mobilanalyse er stadig en mørk skov for dem. Funktionaliteten halter derfor lidt efter nettet i udviklingen, fordi branchen er ung.

Vi vil tale om disse problemer med den ældre Google analytiker Analytics, Stanislav Vidyaev. Fuld lydversion af interviewet - iTunes, TuneIn.



Jeg logger ind i systemet, hvilken funktionalitet skal jeg mestre først for rent faktisk at begynde at arbejde med dit produkt? Måske er der noget litteratur, seminarer, dine bøger på engelsk?

Google Analytics er i første omgang et webprodukt, og alle relevante metrics er veludviklede i det.
Udviklingen forløber på en sådan måde, at webproduktet i første omgang begynder at tilpasse sig fremkomsten af ​​denne mobile verden.

For at være ærlig, altså Google virksomhed lidt sent: vi fik vores første mobilprofiler for 2 år siden (juni 2012), siden dengang har mobilretningen udviklet sig, og systemet forsøger at mestre mobilt sprog. Men nærmer sig stadig den mobile verden fra en webmarketers synspunkt.

En marketingmedarbejder, der har været involveret i webanalyse og hjemmesider, er allerede mere eller mindre forberedt, og når han kommer til os for at analysere en mobilapplikation, vælger han de sædvanlige målinger.
De er ikke særlig anvendelige til en mobilapplikation, men ikke desto mindre kan de bruges til at vurdere effektiviteten af ​​en mobilapplikation.

Alle de metrics, der er der, og som er synlige umiddelbart efter installation af Analytics. denne mængde aktive brugere, ny, tilbagevendende, geografi for anvendelse af applikationer, popularitet af individuelle sektioner, hvordan folk ser dem (samme konverteringer, køb) - hele det sæt, der i første omgang er nødvendigt for at forstå, hvad der sker i mobilapplikationen. Nogle andre ting kan konfigureres - Brugerdefinerede dimensioner.

Hvad er brugerdefinerede dimensioner?

Dette er yderligere parametre, som ikke eksisterer som standard, men vi kan oprette og indstille dem. For eksempel klikker en bruger i en applikation på en knap og bliver en betalt bruger, vi kan betegne ham som en betalt bruger, som han vil forblive hos resten af ​​sit liv, så længe han har denne applikation installeret.
Det vil sige, at vi kan segmentere alle hans yderligere besøg som en gruppe af betalte brugere af vores applikation. Dette er yderligere konfigureret, og i første omgang er disse metrics ikke inkluderet i Analytics. Det vil sige, du skal tænke over dette på forhånd, komme med denne metrik, forstå på hvilket tidspunkt du skal oprette og starte den.




Der er sådan en konstruktør på nettet. Vi bringer nettet til mobil. Arkitekter mener, at de samme analytiske koncepter og principper, som findes for websteder, også kan anvendes til mobilapplikationer

Hvor kan jeg få det indledende sæt af viden?

En bog er den værste måde at beskrive et problem på, så snart den udgives, bliver den straks forældet. Jeg ville sende alle til vores ressource. Den eneste ulempe er, at den kun er på engelsk og endnu ikke er oversat til russisk.
Denne ressource indeholder den seneste information, alle meddelelser er lavet der.

Naturligvis er internettet enormt, der er mange kloge mennesker, der skriver noget værd på egen hånd. Grundlæggende ville jeg læse anmeldelser af forskellige systemer og sammenligninger fra forskellige forfattere. De er ikke altid korrekte, de går glip af noget, men generel idé god.

Hvilke reelle udfordringer ser du i mobilanalyse lige nu?

Dette er kompleksiteten af ​​systemet som helhed. Det vil sige teknisk analyse i mobile applikationer. Jeg tager ikke hjemmesider, for måske vil vi i fremtiden ikke have en opdeling mellem en mobil og en almindelig hjemmeside, og sådan noget som en mobil hjemmeside forsvinder.

Hvis vi tager applikationen, så er dette kompleksiteten af ​​teknisk implementering, integration af pakker og store installationskrav til den tekniske træning af den, der gør det.

Hvis du installerede koden på webstedet og gik (der er nogle data), så skal du i applikationen tænke på forhånd, hvad vi vil spore, hvordan og på hvilke tidspunkter vi vil udløse visse begivenheder. Det vil sige, at alt dette skal tænkes ud på forhånd, og den tekniske specialist skal implementere denne sag. Igen, hvis vi taler om selve Google Analytics, som jeg nævnte, er systemet lige ved at vænne sig til mobile definitioner.

Der er et andet emne, der udvikler sig i dag (på den ene side er dette en svaghed ved Google Analytics, men de ønsker at gøre et meget stort nummer ud af denne svaghed stærke side) er en kombination af to verdener - web og mobil.

Det er netop under "paraplyen" af Universal Analytics, at vi vil bevæge os i denne retning. Universal Analytics er en ny reinkarnation af Google Analytics, som har en anden kode og arkitektur, den bruger forskellige cookies - dette er nyt system. Det kaldes kun Google Analytics, fordi det er synligt i grænsefladen.

Da jeg forberedte mig til interviewet, kiggede jeg igen på dokumentationen fra en anden god kilde - developers.google.com - der tekniske oplysninger. Jeg kiggede også på SDK, og der er allerede en bruger-id sektion, som kan bruges til at spore konverteringer fra forskellige enheder til webstedet (i øjeblikket kun til webstedet) for den samme bruger.

Hvad er princippet der?

Brugeren kommer til webstedet, klient-id'et indlæses i hans browser - dette er Google Analytics-id'et, og det er unikt for denne browser, det vil sige, hvor mange browsere brugeren har, så mange identifikatorer og følgelig, unikke besøgende V Analytics rapporter. Hvis han har tre browsere på én enhed, så vil disse være tre forskellige brugere.

Der er et bruger-id - dette er en parameter for virksomhedsejeren, webstedsejeren. Det vil sige, når en bruger har registreret sig, udfyldt en ansøgning (identificeret sig selv på en eller anden måde), kan webstedsejeren uploade dette bruger-id.

Så bruger-id er allerede dukket op i dokumentationen til mobilapplikationer. Det vil sige, vi kan kombinere ikke kun hans historie med at besøge webstedet, men også applikationer. I i øjeblikket Vi har stadig en klar skelnen mellem web- og mobilverdenen. Men så vil Universal Analytics bevæge sig i retning af at kombinere disse to verdener.

Du promoverer aktivt Google Tag Manager. Hvad er det her, hvordan virker det?

Google Tag Manager er en måde at arbejde med sporingskoder på. Hvis vi tager hjemmesider, er dette kode, et script - et stykke kode, som vi installerer på siden, og først derefter i Tag Manager-grænsefladen arbejder vi med direkte sporingskoder for analytiske systemer.




Og denne Tag Manager-kode, den udfører funktionerne i andre koder, det vil sige, den sender opkald, foregiver at være dem, og i øjeblikket kan den fungere som Google Analytics, derefter som Yandex.Metrica, derefter som konverteringssporing - det udfører funktionerne i disse koder.

Hvilket problem løser det?

Problemet med at installere koder i webstedets kildekode. Det vil sige, at vi ikke behøver at løbe til en teknisk specialist eller en webprogrammør hver gang og sige: "Installer denne lille linje." Og han lægger det i Pipeline, og denne ting varer tre måneder, den redigeres, så udføres den - jo større virksomheden er, jo flere problemer er der i denne forbindelse.
Med Tag Manager har vi et uddrag på webstedet, måske er der nogle yderligere funktioner, som vi tænkte igennem på forhånd, for eksempel en transaktion. Yderligere muligheder i syntaks Tag Manager overført til Datalag er en måde at videregive hændelser, variabler og transaktioner til Google Tag Manager. Det vil sige, at alle parametre er specificeret, og så kan vi spore eksempelvis transaktioner i både Google Analytics og Yandex.Metrica – hvor end vi har brug for det.

Er det den samme historie i mobilanalyse?

Historien er som følger. Skaberne og udviklerne af Tag Manager gjorde det som følger: Der er et enkelt SDK til Tag Manager og Google Analytics. Altså ved at integrere i SDK seneste Google Analytics med applikationen, du integrerer Tag Manager. Og omvendt – ved at integrere Tag Manager får du Google Analytics.

Det vil sige, at håndteringen af ​​denne kode er ret enklere og mere effektiv. Det handler ikke kun om sådanne markedsføringstiltag. Lad os sige, at du skal spore en begivenhed i Tag Manager, for dette behøver du ikke at løbe ind i udvikling og tvinge dem til at gøre det ny version applikation, offentliggør den, så denne opkald eller begivenhed er inkluderet.

Det vil sige, at jeg kan konfigurere sporing af enhver begivenhed uden hjælp fra udviklere?

Ja. Forudsat at denne begivenhed er indtastet i Tag Manager. Det vil sige, hvis det er der, så kan du inde i Tag Manager indtaste de koder, der er nødvendige for denne begivenhed. Det er meget nemmere.

Der er en pointe mere. Ved integration med Analytics opstår der muligheder for for eksempel at udføre eksperimenter.

Hvilken slags eksperimenter?

Disse er eksperimenter på rigtige brugere. Det vil sige, at vi ikke er et sted i en sandkasse, der tester forskellige farver, størrelser på knapper, billeder, tekster, logodesigns mv. Alle disse designelementer kan ændres dynamisk og eksperimenteres med i Google Analytics.

Det vil se sådan ud. Eksperimentet oprettes og konfigureres i Tag Manager, og visualiseringen af ​​dette eksperiment og alle graferne, der viser, hvilkened, der vandt, er alle synlige i Analytics. Og efter at dette eksperiment er afsluttet, vil det være muligt at konfigurere applikationen i Tag Manager på en sådan måde, at den vindende mulighed bliver den grundlæggende.

Dette er for eksempel et eksperiment med en formular: hvilken registrering er bedre - kun Facebook eller Facebook + E-mail?

Ja, inklusive. De elementer, som vi ønsker at udføre et eksperiment med, vi dekorerer dem med Tag Manager-variabler, det vil sige et containerkald.

Jeg ser et problem: der er en simpel almindelig marketingmedarbejder - det er umuligt for ham at implementere et analytisk mobilsystem (slet ikke et) uden at gå til udvikleren. Faktisk er der ikke mange muligheder, dette er virkeligheden på markedet.

Men der er en anden mulighed - du har et værktøj som Google Developer Console. Hvorfor ikke lægge det derude? mere mængde oplysninger om fastholdelse, churn rate osv.?

Vi bevæger os i denne retning, men der er ingen ideel situation, vi kan kun stræbe efter det. Rapporter vises. For nylig var der en juni-opdatering - en række rapporter for spilapplikationer dukkede op. Det vil sige, at du kan se antal spillere, fastholdelse mv. Men igen, dette er ret generel information.

Hvis du for eksempel vil se sådan noget, så kig med ved hjælp af Google Analytics, hvordan brugere falder fra, når de passerer igennem forskellige niveauer spil. For eksempel har du 10 niveauer, og ved hjælp af analyser opdager du, at niveau 5 og 6 er for svære, brugerne kommer ikke forbi dem og falder fra. Herefter gør du dem lidt nemmere, og de når niveau 7-8. Det vil sige, at varigheden af ​​brugerinteraktion i ét legetøj øges.

Disse unikke ting for alle kan ikke skærpes på sådan en platform, så Google Analytics kommer i spil, som kan modificeres til disse formål, konfigureres og spores der.

Hvad er de grundlæggende Google funktioner Udviklerkonsol?

Det er her, vi udgiver ansøgninger. Det vil sige, at vi opretter en udviklerkonto, vi udgiver applikationer, betaler $25 og begynder at promovere det på Google Play (du kan have flere applikationer), og nogle statistikker er tilgængelige der som standard. Men igen, dette er ikke egnet til seriøs analyse - dette er det grundlæggende niveau.


Har du en bekvem måde at spore kilden til installationer, noget som en analog af samme MAT. Det vil sige, til Android ser det ud til at være der, men hvordan gør man det til iOS?

Dette er et spørgsmål om Google Play-integration med applikationen. Hvis vi gør dette, så kan vi se de kilder, der kommer til Google Play (til vores side) og derefter blive til installationer, så kan vi linke denne historie med konverteringer.

I webjargon - Google Play holder henvisningen frem. Det vil sige, henvisningen, der bragte os trafik (dette kunne være en betalt kilde, affilierede programmer, sociale netværk - hvad som helst), vi kan se alle disse ting inde i applikationsanalysen.

Desuden er emnet videreudviklet der - konverteringssporing for at sende konverteringen tilbage til samme AdWords - dette er også muligt, helt frem til sidste klik på en specifik annonce i en specifik applikation. Vi ser konvertering.

Baseret på denne analyse ser vi kilde 1, kilde 2, installationer, konverteringer. Vi ser, at kilde 1 skal slås fra, fordi den ikke konverteres, og alle penge skal f.eks. overføres til kilde 2. Analyse om dette. Dette er netop kombinationen af ​​marketinghandlinger med brugeradfærd inde i en Android-applikation.




iOS transmitterer ikke, forlænger ikke referenten. For at gøre dette på developers.google.com/ er der en beskrivelse af processen for, hvordan man trækker denne henvisning. Det vil sige, at der allerede er serverintegration, seriøs teknisk opsætning er nødvendig.

Hvordan beregner man korrekt brugerens levetid i en applikation?

Videnskaben ved ikke, hvad der sker efter den sidst overvågede hændelse. Brugeren klikkede og åbnede siden – hvor længe var han på den? Han læste det i 5 minutter eller studerede det i 40 minutter diagonalt, op og ned og på tværs - vi ved det ikke.

Vi har den tid, brugeren er på siden eller i mobilapplikationen - dette er den første og sidste begivenhed, og vi måler den periode, der er gået mellem dem. Det vil sige, at Google Analytics sporer en hændelse, og nedtællingen begynder fra dette tidspunkt.

Hvad kan der gøres for at gøre denne sag mere præcis?

Der var sådan en teknik, den virkede for hjemmesider. For eksempel sidevisning: Lad os sige, at vi har et stort indholdswebsted, vi har enorme artikler, folk læser analyser. Jeg åbnede siden - jeg læste den, der sker ikke flere begivenheder. Det vil sige, at Analytics ikke ved og kan ikke vide, hvor længe jeg har været på denne side.

For at måle tiden på denne side affyrer vi en begivenhed. Lad os sige, at vi hvert 15. sekund, mens brugeren er på siden, sender en begivenhed eller sporer Scroll som en begivenhed – det viser sig, at vi giver Analytics besked om, at brugeren stadig er på siden.

For applikationen kan du køre noget lignende. Ikke kun spor klik på knapper, men også ting som Swipe, Zoom ind, Zoom ud - vi kan også sende begivenheder til alle disse handlinger, der er strengt gældende for applikationen. Det vil sige, at der forekom en Zoom ind på én skærm, og en Zoom ud fandt sted på en anden skærm. Alt dette kan spores, og det vil øge den tid, brugeren interagerer med applikationen. Og hvis den er åben, og skærmen er mørk, så tror jeg, at der ikke er behov for at spore noget.

Sådanne ting som viralitet, organiske stoffer osv. - er det muligt at spore i det mindste viraliteten af ​​en applikation eller i det mindste estimere den omtrentlige værdi?

Anslå snarere den omtrentlige værdi. Der er ingen viralitetsrapport i Google Analytics. Vi skal tænke på forhånd og prøve at forestille os, hvordan vores ansøgning kan afvige, og hvordan vores handlinger kan påvirke dette.

Vi lancerede en annonce, efter den er der nogle lang hale, som altid kommer igennem - du skal se afsnittet. Det vil sige, at vi allokerer annoncetrafik til segmentet, vi ved på hvilke datoer nogle offline events finder sted og andre indholdsprojekter finder sted.

Lad os sige dig og jeg bil app, og vi afholder et motorrally Moskva-Petushki, hvor vi promoverer denne ansøgning - og der er reklame for ansøgningen på alle sider af bilerne. Vi ser på datoerne for dette bilrally (der er en anmærkning i Google Analytics, alt dette kan registreres efter tid) og dynamikken i installationer osv.

Eller der var for eksempel nyheder på tv i dag. Derfor ser vi på organisk trafik, brandcitater i søgninger - alle disse ting skal kombineres. Du kan opdele dette i segmenter og se, hvordan annoncetrafik påvirker organisk vækst.

Er organisk trafik allerede synlig i dine rapporter?

Ja. I Analytics kan du se dette, der vil være to segmenter - to kurver - de følger hinanden eller gør det ikke. Derfor er det også muligt at evaluere kvaliteten af ​​trafikken, for eksempel hvad er brugerinteraktionstiden, om den er faldende eller stigende. Det vil sige, vi bringer det publikum eller ej. Det er det samme med konverteringer.

Alle disse ting kan vurderes ved en række indirekte tegn. Der er naturligvis ingen direkte indberetning.

Der er et andet problem - svindel i mobilsegmentet: trafik af lav kvalitet strømmer ind. Er det muligt at opdage denne svindel? Jeg ved, hvordan man gør dette på nettet. Det vil sige, jeg ser kilder, jeg ser endda på det samme Google-netværk, hvad han ikke fangede, jeg fanger det selv og leder efter svindlere med ubesvarede klik, uanset hvad - der er mange muligheder for at overliste mig. Jeg afskar hvert område i detaljer.

Hvis du har nogen mekanik til at frasortere denne svindel på mobilenheder ved hjælp af den samme Google Analytics?

Analytics er ikke designet til at fange tyve. Igen er der tale om en række indirekte tegn.

Jeg har endnu ikke haft nogen tilfælde, hvor jeg fangede nogen specifikt til mobilanalyse, men der var nogle med websteder. Kunder kontaktede os og spurgte, hvilken slags trafik dette var.
Svig kan ses af nogle specifikke interaktionsindikatorer.

Det sker, at de laver sådanne bannere, at når jeg klikker på krydset, kommer jeg stadig til annoncen. Hvordan vil jeg forstå, at der er noget galt der på grund af hvilken begivenhed?

Det første tegn er en høj afvisningsprocent. Hvis vores mål er installationer, og denne trafik giver installationer, så er det lidt mere kompliceret. Hvis vi ser et stort antal besøg Google sider Play/App Store og få installationer, og for os er denne trafik betalt, så kan vi undre os over, hvordan det sker.

I øjeblikket, hvis der er en reklamekampagne, kan du gå og se på denne annonce, bede dine pårørende om at gå, kolleger til kolleger, så de ser på denne ting fra forskellige enheder (helst i forskellige regioner) og ringe. Følgelig, hvis der er svindel, så kan det på denne måde i det mindste blive fanget.

Hvordan man opfører sig med partnere er det næste spørgsmål, men Analytics selv vil ikke se kendsgerningen af ​​svindel, men vil blot fortælle dig, at det er klart, at de kommer og ikke installerer.

Spørgsmål om restriktioner på produktet mht. mængder, antal arrangementer mv. - gælder de for mobil?

Ja. Begrænsningen er generel for al Analytics og for enhver ressource. Og der er flere begrænsninger direkte for mobilapplikationer. Alt dette er beskrevet i dokumentationen.
For standard Google Analytics er det 10 millioner hits om måneden.

For én ressource er denne begrænsning ret fleksibel. Det vil sige, at hvis vi har 30-40-50-100, arbejder vi normalt. Det eneste negative, der sker, er, at vi inkluderer sampling - nøjagtigheden af ​​dataene lider. Vi ser de samme grafer og tendenser, men relativt set tager systemet i individuelle rapporter 10% af denne trafik som grundlag for beregningen af ​​denne rapport, og multiplicerer den derefter i sindet. Dette er prøveudtagning.

Med fremkomsten af ​​forhandlere i Rusland, og med fremkomsten af ​​muligheden for at købe Google Analytics Premium til disse websteder, inklusive applikationer, bliver denne regel strengere. Det vil sige, vi meddeler: "Kære kunde, du har overskredet grænsen så mange gange."

Hvis du har 10-20-50 millioner hits, vil der ikke være en sådan meddelelse. Hvis det er meget - 500 millioner om måneden, så er der stor sandsynlighed for, at sådan en advarsel bliver modtaget.

Er det muligt i det mindste at tage rådata fra en mobilapplikation for at bygge din egen analyse?

Ja. For Mobil API Der er ingen sådanne applikationer i applikationer lige nu, men jeg tror, ​​at under "paraplyen" af Universal Analytics vil det være tilgængeligt. Især det faktum, at User ID begynder at blive knyttet til mobile enheder, og det er et emne tæt på API'en. Serveren arbejder allerede med Big Data og andre integrationer.

Jeg tror, ​​at dette emne vil blive udviklet i den nærmeste fremtid, og API'en til mobilapplikationer vil enten være separat eller inden for Core Reporting API, som i øjeblikket er tilgængelig i Analytics. Jeg ved ikke, hvordan det bliver arkitektonisk, men det antyder naturligvis sig selv, hvad det bliver.

Der er helt sikkert en form for køreplan, som du har hørt om, og som dine kolleger giver dig mulighed for at fortælle om. Hvad vil der ske? Hvornår vil sådanne metrics som Return Rade, LTV og noget andet dukke op? Hvornår begynder Google Analytics at tale til mig på mobilsprog?

Som et tre-årigt barn forsøger han at mestre sin mors og fars sprog og siger allerede noget. I i dette tilfælde Return Rade på nettet har en loyalitetsrapport - ny og tilbagevendende. Der er lignende rapporter i mobil, kun de kaldes lidt anderledes, men du kan se og arbejde med dem der.

Hvad angår LTV, er der ingen sådan rapport, men den kan indsamles ved hjælp af tilpassede metrics og parametre. Det vil sige, konventionelt ved vi, at denne bruger i går købte noget fra os for 5 rubler, og vi skriver i en variabel for ham, at han efterlod 5 rubler hos os. Hvis han køber noget andet for 5 rubler i morgen, kan vi tage de tidligere 5 rubler og tilføje yderligere 5 til dem og få 10 rubler.

Igen kan du ikke forudse alle tilfælde. Vi kan ikke altid forudse og forudsige, at en given funktion rent faktisk vil lykkes. Og du kan give mulighed for selv at konfigurere det, du har brug for, ved hjælp af de samme tilpassede variabler (brugerdefinitioner på Universal Analytics-sproget).

Der er variabler på hit-, sessions- og brugerniveau. Og kun for LTV er en session på brugerniveau bedre egnet, når vi tildeler en eller anden parameter til brugeren.

Alle taler om det, men ikke alle bruger det, for det er en ret specifik funktion. Og segmentér derefter brugeren, der forlod 10 rubler, mod brugeren, der forlod 5 rubler, og sammenlign dataene om dem.

Generelt mangler du pædagogiske ting i et simpelt sprog.

Faktisk er det vestlige marked mere forberedt og uddannet i denne henseende. De har ingen problemer med at kommunikere på mere teknisk sprog. Det vil sige, folk der er kyndige, og du kan simpelthen fortælle dem: "Her er tilpassede variabler." Og som svar: "Okay, jeg går og gør det, jeg forstår alt."

Måske er der nogle andre funktioner, overraskelser, feedback, push-meddelelser?

Intern kommunikation med produktchefer er struktureret sådan, at der bliver fortalt os om det, der passer. Hvad jeg talte om den kombinerede funktionalitet af Tag Manager og Google Analytics, om mulighederne i dette system, det er præcis den slags funktionalitet, der bliver tilgængelig lige nu.

De talte om eksperimenter i mobilapplikationer for ganske nylig, de tester i øjeblikket og vil snart blive udrullet. Vi kan allerede med en halv hvisken fortælle, at det er eller snart vil være med hensyn til enkelte ting, hvilket bliver svært for mig at sige senere.

Er der nogen tilbagemeldinger fra markedet?

Ja. Vi har udviklere, specialister, der kommunikerer inden for Google med sælgere - hos os sælger vi AdWords, og derudover har vi kundernes behov for analyser.

Vi mødes, og denne kommunikation foregår sådan her. Vi har en person i Østeuropa, vi kommunikerer til ham, at vi har sådanne og sådanne vanskeligheder, sådanne og sådanne muligheder og vidunderlige konkurrenter - lad os se på grænsefladen sammen, måske vil der opstå nogle ideer.

Vi kigger sammen, han kommer med ideer, og han kan formidle dem til udvikleren. Udvikleren siger - "Okay, interessant emne, lad os se." Der er sådan kommunikation.

For ikke længe siden annoncerede Google ny service statistik, som kaldes Universal Analytics. Imidlertid begyndte mange at bruge det ikke så aktivt, som skaberne af dette system havde planlagt.

Af denne grund besluttede udviklerne at gøre overgangen til Universal Analytics-tjenesten obligatorisk. Nu vil du i en måned have mulighed for at fortsætte med at bruge den almindelige Google-tjeneste, men efter dette tidspunkt bliver du automatisk omdirigeret til det nye system.

Hvordan er Universal Analytics så forskellig fra den sædvanlige Google Analytics? I det store og hele er der meget få forskelle. Den nye statistiktjeneste giver dig dog mange nye funktioner, som vil være nyttige for dig. Der vil være udvidede rapporter om trafikken til dit projekt og effektiviteten af ​​annoncekampagner. Men hvis du har brugt Google Analytics i længere tid, vil du ikke mærke den store forskel.

Den obligatoriske overgang til en analysetjeneste skyldes udviklernes ønske om at kombinere flere værktøjer til ét. På den ene side er alt godt, for du får adgang til mere brede muligheder. En tvungen overgang til Universal Analytics-tjenesten er dog ikke så slemt for dem, der er vant til at arbejde i gammelt system. Men hvad kan du gøre, hvis du ikke har meget valg?

For at kunne bruge den nye statistiktjeneste skal du dog foretage nogle justeringer på dit websted. Først og fremmest skal du opdatere din sporingskode. Uden dette vil analysetjenesten ikke være i stand til at indsamle alle de oplysninger, du har brug for. Det er meget nemt at gøre. I dine kontoindstillinger skal du vælge en sporingskode, kopiere den til en fil og derefter uploade den til din hosting. Inden for et par minutter begynder Universal Analytics at indsamle data fra dit projekt.

Hvad er Universal Analytics Som udviklerne selv siger, er Universal Analytics absolut ny standard traditionel Google-tjeneste Analytics. Selvom han annoncerer en lang række funktioner, der vil være tilgængelige, er der ingen særlige innovationer lige nu. Mest sandsynligt vil nye dukke op i fremtiden funktionalitet, men nu store forskelle Der er ingen forskel på den gamle og den nye version.

Hvis du endnu ikke har skiftet til den nye Universal Analytics-tjeneste, så gør det hurtigt. Ellers vil du efter nogen tid være tvunget til at bruge den nye tjeneste, og adgangen til traditionel Google Analytics vil simpelthen blive blokeret.

Hej kære læsere af bloggen. Googles analysetjeneste anses med rette for at være en af ​​de mest funktionelle på RuNet-markedet, og den er samtidig helt gratis.

I denne artikel vil jeg introducere dig til principperne for driften af ​​dette system og grundlæggende begreber, indlejret i dets fundament, så du selv med et nærmere kendskab til det forstår, hvad der er hvad og ikke forvirrer brugere, sessioner (sessioner) og interaktioner (hits), og også forstår forholdet mellem parametre og indikatorer.

I den nuværende periode Google system Analytics gennemgår en opdatering, fordi det bliver erstattet af et mere avanceret kompleks kaldet Universal Analytics, hvis sporingskode allerede tilbydes til installation. Derfor vil jeg i denne artikel beskrive de nye muligheder, som Google Analytics vil modtage efter sin reinkarnation i UA (modtagelse af data fra alle enheder forbundet til netværket osv.).

Funktioner og principper for drift af Google Analytics

Google Analytics er et analysesystem, der går langt ud over de almindelige muligheder, såsom Top100 og endda Yandex Metrica. Dette system er lige så kraftfuldt, som det er svært at mestre, især for utrænede brugere. På trods af al dens imponerende funktionalitet har Googles hjerne en ret høj adgangsbarriere, og mange bruger enten ikke denne analyse eller bruger kun en meget lille del af alle de muligheder, den giver.

Med Google Analytics kan du indsamle og analysere data forskellige enheder og digitale medier. På den måde kan du for eksempel forstå, hvordan kunder finder dine hjemmesider eller mobilapplikationer, og hvordan de interagerer med dem (vurdere brugeradfærd). Selve analysesystemet består, kan man sige, af fire blokke, der udfører følgende funktioner:

  • Dataindsamling
  • Blok, der giver dig mulighed for at foretage indstillinger
  • Databehandlingsenhed
  • Udskriver rapporter i den mest visuelle form
  • Med disse fire komponenter kan du indsamle, tilpasse og analysere data på tværs af dit websted. Lad os starte i rækkefølge, nemlig med dataindsamlingsblokken. Hvordan foregår udvindingen? nødvendige oplysninger? Det er rigtigt, ved at bruge tællerkoden installeret på webstedet (eller mobilapplikationen). Generelt som sædvanligt.

    Denne sporingskode indeholder en række instruktioner til Google Analytics, der fortæller dig, hvilke brugerinteraktioner med webstedet du skal være opmærksom på, og hvilke data du skal indsamle. Metoden til dataindsamling bestemmes af det digitale miljø, som måleren opererer i. For eksempel, når du installerer det på et websted, bruges JavaScript-sporingskode. Og for at integrere målerkoden i en mobilapplikation bruges et såkaldt udviklerkit (SDK).

    Brugeren bringer gennem sine handlinger liv i Google Analytics-sporingskoden (åbner en side på dit websted eller går til en ny skærm i din applikation). Som et resultat indsamles der information om alle udførte handlinger, herunder titler og URL'er på sider, der er set, og andre ting, som derefter samles i en pakke (hit). Denne pakke sendes til systemserveren for at udføre det næste trin - databehandling.

    Alle disse "rå" data på Google-serveren passerer gennem sigten af ​​de indstillinger, du har foretaget (din konfiguration), som giver dig mulighed for at luge det unødvendige ud i overensstemmelse med den givne måleplan og de tilsigtede (forretningsmæssige) mål. Hvad betyder det i praksis? Nå, for eksempel kan du indstille et filter i Analytics-indstillingerne for at filtrere data fra dine medarbejdere, der besøger et websted eller en mobilapplikation. De vil ikke blive behandlet yderligere og vil ikke påvirke resultaterne, der præsenteres i rapporterne. Desuden vil disse data ikke rigtig blive indsamlet, og selv efter at du har annulleret filteret, vil du ikke være i stand til at se det.

    Ud over at indsamle data ved hjælp af tælleren, er det muligt at importere disse oplysninger fra andre tjenester i "det gode selskab". For eksempel kan du linke din Google Analytics-konto til en konto i , eller i . I princippet kan du importere data til Analytics selv fra kilder, der ikke tilhører Google (f.eks. indsamlet af dig selv).

    Det, der er bemærkelsesværdigt, er, at det er på behandlingsstadiet, at systemet kombinerer alle disse data fra forskellige kilder (inklusive dem, der er indsamlet af dets tællere), og de vil bidrage til de resulterende rapporter. Google Analytics-rapporteringssystemet omfatter en hel del praktiske værktøjer til visuel præsentation af data. Men hvis det ønskes, kan rapporter også tilgås via API'et, hvis du for eksempel ønsker at oprette dine egne rapporteringssystemer uden for GA-grænsefladen.

    Lad os tage et generelt kig på, hvordan Analytics indsamler de nødvendige data om dit websted. Selve indsamlingsmodellen tager højde for tre ting – brugere, sessioner (sessioner) og interaktioner.

  • En bruger er en besøgende på dit websted eller din mobilapplikation
  • En session (efter min mening mere forståelig er begrebet session) er den tid, der bruges på en hjemmeside eller en applikation
  • Interaktion er brugernes handlinger på et websted.
  • Dette diagram har en hierarkisk struktur, der går ned fra brugeren til interaktionen. Brugere skelnes mellem dem, der kun besøger dit websted én gang, og dem, der besøger det flere gange om dagen. I Google Analytics-systemet betragtes hvert besøg som en session (session), hvilket indebærer muligheden for at genkende den samme bruger (tilbagevendende) inden for flere sessioner.

    Til gengæld består en afsluttet session på din hjemmeside af individuelle interaktioner. For eksempel kan en bruger gå hjem og straks gå, hvilket resulterer i, at kun én interaktion registreres af Google: browsing. hjemmeside. Som en del af en anden session (session) kunne brugeren også se videoen og også foretage et køb. Dette ville resultere i tre interaktioner.

    Disse individuelle interaktioner inden for en enkelt session (session) kaldes hits, som igen er underopdelt i grupper, der refererer til enten sidevisnings-, transaktions- eller hændelseshits. Lad mig understrege igen hierarkisk dataindsamlingsskema vedtaget i Google Analytics— hver interaktion, der spores af systemet, tilhører en session, og hver session er knyttet til en tilsvarende bruger.

    Som du allerede forstår, indsamler den sporingskode, du har installeret på din hjemmeside, mobilapplikation eller andet digitalt miljø, direkte data (oplysninger om brugerhandlinger). Den sender de indsamlede oplysninger til din Analytics-konto med det formål at behandle og generere rapporter.

    Linking af den indsamlede sporingskode til din konto sker ved hjælp af en unik identifikator, der er indlejret i koden. For eksempel i eksemplet Google Analytics-kode til et websted eller en applikation.

    Registrering med Google Analytics og kørsel af sporingskoden

    Faktisk er den nu ude af beta-testning ny måde sporing, som blev kaldt Universal Analytics (vi taler om det lidt senere) og koden, som allerede tilbydes installeret ved registrering på det officielle websted Google.com/analytics/ :

    Vær opmærksom på, at du frit kan vælge, ved hjælp af knapperne i toppen, hvor præcist du ønsker at indsamle statistik – på hjemmesiden eller i mobilapplikationen. Når du har udfyldt alle felterne i registreringsformularen i Analytics, bliver du bedt om at acceptere vilkårene og betingelserne og kopiere sporingskoden med en unik identifikator til dit websted, dog fra Universal Analytics:

    Lad os først se på aspekterne af GA's arbejde, og først derefter vil vi tale om, hvordan den nye UA (Universal Analytics) adskiller sig fra den, og hvad der fik Google til at udvikle den og gradvist gå over fra klassisk GA. Dem. Lad os nu fortsætte samtalen om Google Analytics. Så...

    Sporingskoden indsamler oplysninger om, hvordan brugere interagerer med et websted eller en webapplikation. Disse oplysninger indsamles i pakker og sendes til Googles servere (for eksempel i form af en liste over parametre i URL'en). Sporingskoden kan også genkende nye og tilbagevendende brugere. Alle indsamlede data er knyttet til din Google Analytics-konto ved hjælp af en unik identifikator, der er indlejret i sporingskoden. Vi har lige talt om det her.

    Installation af Google Analytics sporingskode på dit websted

    For at spore og indsamle data på hjemmesider bruges et stykke JavaScript-kode, som blev vist på det forrige skærmbillede. Den indeholder et link til analytics.js-biblioteket, som styrer typen af ​​data, der indsamles på webstedet. For at indsamle al statistik skal denne kode naturligvis være til stede på hver side på dit websted.

    (funktion(i,s,o,g,r,a,m)(i["GoogleAnalyticsObject"]=r;i[r]=i[r]||funktion())((i[r].q = i[r].q||).push(argumenter)),i[r].l=1*ny Dato();a=s.createElement(o), m=s.getElementsByTagName(o);a . async=1;a.src=g;m.parentNode.insertBefore(a,m) ))(window,document,"script","//www.google-analytics.com/analytics.js","ga " );

    ga("opret", "UA-51939022-1", "slaviali.ru");

    ga("send", "sidevisning");

    For at gøre dette føjes det normalt til skabelonfilen på dit websted (hvis det f.eks. virker på). Så for eksempel kan du i dit tema finde en fil, hvori "hovedet" af dokumentet (websiden) er dannet, bestående af de afsluttende og åbne Head-tags. Lige før det afsluttende tag kan du indsætte Universal Analytics-sporingskoden. Hvordan JavaScript-sporingskode fungerer på et websted Hvis sporingskoden er placeret på alle sider på siden, vil hvert opkald (åbnet af brugeren) danne et hit (et interaktionselement). Hvis denne regel overtrædes, vil du ikke få et komplet billede af alle interaktioner (udført inden for en specifik session). Derudover tilføjer en sporingskode til de fleste

    øverste del sidens kildekode sikrer, at browseren, når den parser denne kode (startende fra toppen og nedad), aktiverer udførelsen af ​​Analytics-scriptet. Så selvom en bruger forlader, før siden er færdig med at indlæse, vil deres interaktion med dit websted blive talt. Analytics-koden kører asynkront, dvs. kører videre baggrund mens browseren udfører andre opgaver med at indlæse websideelementer. Dette giver dig igen mulighed for at begynde at indsamle data før

    Efter at sporingskoden på en given side er udført, opretter systemet anonyme unikke identifikatorer beregnet til. Der er flere måder at oprette sådanne identifikatorer på. Som standard bruger Google Analytics sin egen (læs og hvad de spiser), men du har mulighed for at oprette og bruge din egen identifikator.

    Ved indlæsning JavaScript-sider Tællerkoden indsamler oplysninger om selve hjemmesiden, for eksempel URL'en på den aktuelle side. Tælleren indsamler også oplysninger om den browser, hvor denne side er åbnet, for eksempel dens navn eller sprogindstillinger. Og endda om det operativsystem, som denne browser kører under. Al denne information pakkes og sendes til Gula-serveren som et sidevisningshit. Og denne proces gentages hver gang siden indlæses i browseren.

    Det bemærkelsesværdige er, at alt dette vil fungere godt uden nogen foreløbige indstillinger. Registreret med Google Analytics, modtog koden og alt vil fungere godt, og du vil se de indsamlede data i form af endelige rapporter. Det er der dog også yderligere mulighed kodeindstillinger, der giver dig mulighed for at indsamle mere information om brugere, deres session(er) og interaktioner med dit websted.

    Sådan fungerer Analytics SDK i mobilapplikationer

    Med Analytics kan du også indsamle... Processen er dog noget anderledes end, hvordan den gøres i tilfælde af en hjemmeside. Det er ikke JavaScript-kode, der bruges, men det såkaldte SDK (development kit), som vil være anderledes for forskellige operativsystemer(Android, iOS). Samtidig indsamles der data om, hvad brugeren præcis ser i applikationen, hvor ofte han åbner den mv.

    Disse data pakkes igen i hits og sendes til din Google Analytics-konto, men ikke med det samme, men efter akkumulering på mobilenheden. Hvorfor bliver dette gjort?

  • For det første mobil enhed(i modsætning til en hjemmeside) behøver ikke altid at være forbundet til netværket, og selv i forbindelsesøjeblikket er der "døde zoner" for modtagelse, celleoverbelastning osv. omstændigheder.
  • For det andet kan selve processen med at sende data til Googles servere i realtid (som det gøres af tællere installeret på websteder) reducere batterilevetiden på en mobilenhed betydeligt.
  • Derfor akkumuleres indsamlede hits (pakker med opsamlede data) på enheden og sendes af SDK-tjenesten til Google-servere hver halve time, når du bruger Android OS og meget oftere til iOS (hvert andet minut). Hvad der er bemærkelsesværdigt er, at du frit kan ændre dette interval efter eget skøn for at kontrollere batterilevetiden på mobiltelefonen til brugere af din applikation.

    SDK'et, såvel som tællerens Javascript-kode, kan differentiere (adskille) brugere (mere præcist, de mobile enheder, som applikationen kører på). Når applikationen starter, en anonym unik identifikator, som derefter spores. Dem. den mobile enhed og dens bruger identificeres (den første er markeret, da den anden er sværere at markere).

    Når du opdaterer applikationen til en ny version, ændres enheds-id'et ikke. Men når du geninstallerer (afinstallerer og derefter installerer programmet), slettes den gamle identifikator og erstattes med en ny. En sådan bruger vil ikke blive talt som en tilbagevendende bruger, men som en ny. SDK'et kan også ændres for at indsamle yderligere oplysninger om dine brugere, deres sessioner og interaktioner med applikationen.

    Det bemærkelsesværdige er, at Google Analytics ikke kun kan indsamle data fra websteder eller mobilapplikationer. Det understøtter også andre enheder, som det ser ud til, er absolut umulige at forbinde til dette system (terminaler til at modtage betalinger, kasseapparat osv.). Åh nej. Der er en speciel protokol med et navn, der ikke kan udtales (Measurement Protocol), som giver dig mulighed for at sende data fra enhver enhed, der er tilsluttet internettet.

    Når du arbejdede med websteder og mobilapplikationer, skabte selve tællerkoden hits (pakker med indsamlet information) og sendte dem til din Google-konto. Her skal du selv skabe de samme hits. Hvordan dette gøres er præcist beskrevet i den førnævnte uudtalelige protokol og side for udviklere.

    Behandling af data indsamlet af tællere i Google Analytics

    Så vi har talt om dataindsamling i generelle vendinger, det er på tide at gå videre til de blokke, der er ansvarlige for behandling og opsætning af dem. Samspillet mellem disse to blokke giver dig mulighed for at strukturere og transformere de indsamlede data til de oplysninger, der kan ses i Analytics-rapporter. Hvordan virker det?

    Systemet opdeler de indsamlede data efter brugere og sessioner (sessioner), og ved at ændre indstillingerne kan du påvirke denne proces. Derudover blandes data indsamlet fra andre kilder (ikke ved hjælp af Google Analytics-sporingskoden) i den samlede masse.

    Dette kan være data fra Adwords, Adsense, Google Webmaster (ved at linke disse systemers konti) og andre kilder, der ikke tilhører det "gode selskab" (ved at downloade en forberedt fil manuelt eller ved at bruge et specielt skrevet program ved hjælp af mulighederne for Analytics API). Du kan også bruge værktøjet "forbrugsdataimport", som bruges til at tilføje oplysninger om de midler, der er brugt på tredjepartsannoncering (ikke Google), så du derefter kan evaluere effektiviteten af ​​annoncekampagnedataene.

    Alle disse oversigtsdata vil passere gennem de filtre, du indstiller i indstillingerne. Disse indstillinger fortæller systemet, hvilke data der skal inkluderes, og hvad der skal udelukkes fra fremtidige rapporter. De kan også påvirke, hvordan de indsamlede data formateres. Nå, i sidste ende er al den indsamlede information struktureret og samlet i databasetabeller (DB). Generer evt påkrævet af brugeren En analyserapport baseret på disse databaser vil ikke være vanskelig.

    Hvordan Analytics skelner mellem brugere og sessioner (sessioner)

    På sitesiden pakkes data om brugere, sessioner (sessioner) og interaktioner i hits, og de behandles i selve Analytics-systemet. Hvordan opretter Google Analytics brugere? Når dit websted eller din mobilapplikation første gang indlæses på en enhed (mobil eller stationær computer), sammen med det første hit (pakke med indsamlede data), oprettes en unik identifikator svarende til denne enhed, og den vil i fremtiden blive knyttet til hvert hit sendt til systemserverne.

    Når Analytics analyserer de indsamlede data, betragter Analytics hver sådan bruger som en unik bruger (selv om det i virkeligheden er et "dumt" stykke hardware, ikke en person). Hver ny identifikator, der opdages under analysen af ​​indholdet af hits, vil blive betragtet som en ny bruger. Hvis identifikatoren i det næste hit viser sig at være stødt på tidligere, vil en sådan bruger (et "dumt" stykke hardware) blive betragtet som returneret.

    Hvis brugeren (for eksempel ved at indstille browserindstillingerne til at rydde dem, når programmet lukkes), så bliver sådanne identifikatorer ødelagt. Det samme sker i tilfælde af sletning og geninstallation mobilapplikation. Som følge heraf vil en sådan bruger blive betragtet som ny og ikke vende tilbage, som han i virkeligheden er.

    Hvis en person besøger din hjemmeside fra en telefon, tablet, bærbar computer osv. stationær computer, så tæller Google Analytics dem som fire forskellige brugere som standard, fordi sporingskoden vil tildele forskellige id'er til alle disse enheder. Sandt nok kan du i systemindstillingerne ændre den måde, identifikatoren oprettes og tildeles på. I det væsentlige vil dette give dig mulighed for at kombinere brugerinteraktion på tværs af flere enheder, dvs. opnå mere pålidelige data som output.

    Hvordan opretter systemet sessioner? I Analytics er en session et sæt interaktioner af en bestemt bruger (bestående af individuelle typer af hits) under specificeret periode tid. Disse interaktioner kan være sidevisninger, begivenheder eller transaktioner (foretage et køb) i en onlinebutik. Den samme bruger kan lave flere sessioner, som kan forekomme inden for samme dag eller med intervaller på flere dage, uger eller endda måneder.

    Efter afslutningen af ​​en session (session) kan en anden startes. Men hvad med systemet? Det viser sig, at sessionen som standard anses for afsluttet efter en halv times brugerinaktivitet. Denne periode kaldes en session timeout og er karakteriseret ved, at systemet i denne periode ikke modtager hits (pakker med data om handlinger på siden) fra en given bruger.

    I dette tilfælde vil en ny session begynde, efter at systemet har modtaget et nyt hit om denne brugers handlinger. Den halve times timeout tages som et gennemsnitstal, der passer til de fleste websteder. Men i syskan du indstille den timeout, der efter din mening vil være optimal. Det vigtigste er, at dette giver dig mulighed for mere præcist at spore statistik og forstå de processer, der foregår på dit websted. For eksempel, hvis du har mange videoer, der er længere end 30 minutter, giver det mening at øge timeoutet for automatisk afslutning af sessionen.

    Analytics-konfigurationsindstillinger

    Konceptet med brugere og sessioner ligger til grund for arbejdet i Google Analytics-tjenesten, og forståelsen af, hvordan disse data udvindes fra rå arrays, er vigtig for at få den maksimale information fra de genererede rapporter. Det er også vigtigt at forstå, hvordan systemet anvender konfigurationsindstillinger (lavet af dig) på de indsamlede data, og hvordan det forbereder dem til rapportering.

    Konfigurationsindstillinger kan påvirke de resulterende rapporter som følger:

  • Inkluder data
  • Ekskluder data
  • Ændre, hvordan data vises i rapporter
  • Der er et stort antal konfigurationsmuligheder i Google Analytics. Måske endda for meget, fordi det er meget skræmmende for en nybegynder. Men hvis vi blandt dem udpeger de vigtigste grupper af værktøjer, får vi ikke meget:

  • — med deres hjælp kan du ændre de data, der indgår i rapporterne (inkludere eller udelukke noget), samt ændre måden, de vises på i rapporterne, så de passer bedre til de opgaver, du står overfor. Du kan for eksempel lave et filter, der udelukker trafik fra en bestemt IP-adresse eller en hel række adresser (så f.eks. besøg fra dine medarbejdere ikke forvrænger statistik, da de ikke er din målgruppe). Filtre anvendes på databehandlingsstadiet (når der modtages hits fra sporingskoden - de accepteres enten ikke, som i vores eksempel med IP, eller er ændret).
  • — i processen med at opsætte mål i Google Analytics oprettes nye indikatorer for rapporter, for eksempel konverterings- eller konverteringsrater. Mål giver dig mulighed for at angive, hvilke hits (såsom sidevisninger eller skærmvisninger) der skal bruges ved beregning af konverteringer. Du kan sætte et mål, for eksempel at spore nyhedsbrevsabonnementer, og for hvert efterfølgende abonnement foretaget af en bruger på siden, vil en konvertering blive registreret på din konto. Nå, ved hjælp af konverteringsindikatorer vil det efter nogen tid være muligt at afgøre, om du har nået de mål, der er tildelt webstedet eller mobilapplikationen (salgsniveau, registreringer osv.).
  • er en anden måde at transformere de indsamlede data ved hjælp af sporingskode, så du kan forbinde specifikke datastykker for at analysere den overordnede ydeevne. I Analytics kan du oprette grupper af kanaler ( markedsføringsaktiviteter- for eksempel displayannoncering, sociale netværk, e-mail-nyhedsbreve osv.) og indholdsgrupper (bruges til at skabe og analysere en samling af indhold - for eksempel i en netbutik kan du kombinere alle produktsider i én gruppe, og al information artikler til en anden for at forstå, hvilken rolle hver gruppe spiller).
  • Alle konfigurationsmuligheder beskrevet ovenfor Google-indstillinger Analytics anvendes på data, før det aggregeres ( sidste skridt databehandlingsstadiet). Men under selve aggregeringsprocessen opretter og distribuerer systemet rapportparametre på tværs af tabeller (indikatorer genberegnes for hver parameter). Når du åbner en rapport på din konto, sender den først en forespørgsel til aggregerede tabeller fyldt med data. Som svar returneres specifikke parametre og indikatorer til rapporten. Når du bruger API'en, sendes anmodninger om data fra aggregerede tabeller af den applikation, du har oprettet.

    Alle data indsamlet af sporingskoden, der er blevet behandlet, vil være tilgængelige for dig i form af rapporter i Analytics-webgrænsefladen eller i din egen grænseflade, som modtager data via API'en. Oftest bruges systemets webgrænseflade til at tilgå rapporter. Det kan opfattes som et lag oven på dine data, der giver dig mulighed for at strukturere, segmentere og filtrere dem ved hjælp af et sæt analytiske værktøjer. Ved hjælp af API'en kan du programmæssigt tilføje til brugerdefinerede applikationer analytiske data (f.eks. i administrationspanelet i dit CMS).

    Alle rapporter er baseret på kombinationer af parametre og indikatorer:

    Ved at kombinere forskellige parametre og indikatorer kan Google Analytics-systemet generere næsten enhver rapport, der er nødvendig for at evaluere markedsføringshandlinger og brugeradfærd på et websted (eller en mobilapplikation).

    "Parameter" er beregnet til at beskrive dataenes karakteristika. For eksempel kan den trafikkilde, hvorfra den besøgende kom til dit websted, være:

    Et eksempel på en bruger med dit websted kunne være navnet på den side, han ser:

    "Indikatorer" er kvantitativ måling data, der kan bruges til at tælle hyppigheden af ​​hændelser, såsom det samlede antal brugere på et websted eller en mobilapplikation.

    Gennemsnitsværdier kan også bruges som indikatorer, for eksempel det gennemsnitlige antal sider set af en bruger på et websted inden for en session (den samme berygtede indikator for visningsdybde, som menes at påvirke adfærdsvurderingen af ​​webstedet ved at søgemaskiner).

    Oftest vises parametre og indikatorer i Google Analytics-rapporter i form af tabeller, hvor den første kolonne indeholder værdien af ​​en bestemt parameter, og de resterende kolonner indeholder de tilsvarende indikatorer. Men når du opretter rapporter, har hver af dem sit eget omfang (som svarer til et vist niveau af hierarkiet af analytiske data relateret til enten brugere, sessioner eller hitinteraktioner).

    I de fleste tilfælde giver det mening kun at kombinere de dimensioner og mål, der hører til det samme handlingsområde i rapporter. For eksempel er "antal besøg" en sessionsmetrik, så den kan kun bruges med parametre på sessionsniveau (såsom "trafikkilde" eller "geografisk placering").

    Det ville ikke være logisk at kombinere "antal besøg" med parametre på hitniveau, såsom parameteren "sidetitel". Eller f.eks. "besøgets varighed"-indikatoren (måler den tid, en bruger brugte på siderne på dit websted) refererer til hitniveauet og kan ikke bruges sammen med sessionsniveauparametre (alle med den samme "trafikkilde" eller "geografisk placering").

    Hvis du dykker ned i essensen af ​​parametrene og indikatorerne, vil dette hjælpe dig med at få mere meningsfulde data, der er nødvendige for at analysere ydeevnen af ​​dit websted eller din mobilapplikation.

    Universal Analytics

    Universal Analytics-tjenesten er ny Google standard Analytics. Snart skal alle konti bruge Universal Analytics. For ikke længe siden forlod den beta-teststadiet, og nu er der på dine kontosider i fanen "Administrator" et tilbud om at skifte til det.

    Sporingskoden (hvis du var opmærksom) inkluderer allerede UA-identifikationen, hvilket betyder, at en af ​​fordelene ved Universal Analytics vil blive realiseret automatisk - muligheden for at indsamle data fra evt. elektroniske enheder forbundet til internettet (ved hjælp af en Java-scriptkode, eller ved hjælp af et SDK eller ved hjælp af Measurement Protocol). Vi har allerede talt om dette lidt højere.

    I UA er den ovennævnte mulighed for at oprette dine egne bruger-id'er, der ikke vil være bundet til enheden, blevet tilgængelig. Kan du huske, at jeg gav et eksempel om logins fra en mobiltelefon, tablet, bærbar computer og computer af samme person? I klassisk GA ville disse besøg blive talt som fire forskellige brugere, men takket være Universelle indstillinger I Analytics kan du manuelt indstille brugeridentifikation for dit websted, og i vores eksempel vil vi tælle én bruger.

    Det er op til dig at beslutte, om du vil skifte til Universal Analytics eller blive på GA indtil videre.

    Held og lykke til dig! Vi ses snart på bloggens sider

    Du kan se flere videoer ved at gå til ");">

    Du kan være interesseret

    Ny bog: Google Analytics. Detaljeret praktisk guide
    HotLog - registrering i rangeringen af ​​websteder og modtagelse af en besøgstællerkode Hvorfor har du brug for analyser, hvordan og hvad er den bedste måde at indsamle webstedsstatistik på?

    Vi løslod ny bog"Indholdsmarkedsføring på sociale medier: Sådan kommer du ind i dine følgeres hoveder og får dem til at blive forelsket i dit brand."

    Abonner

    Webanalyse er som at udvinde guld. Jo dybere du graver ned i minen, jo mere skinnende metal får du, og jo stærkere strømmen af ​​glædestårer. Det samme med oplysninger om brugere. Jo mere du ved om dem, jo ​​bedre kan du gøre din hjemmeside og din virksomhed. Derfor har vi i dag at gøre med Google Universal Analytics. Dette er en ret gammel opdatering til analysesystemet, men ikke alle ved, hvor mange fede funktioner den tilføjede. Vores artikel hjælper med at udfylde hullerne i viden.

    Hvad er det

    Dette er en analysesystemstandard, der erstattede den gamle Google version Analytics. Det blev lanceret i beta i 2013, en fuldgyldig overgang fandt sted i 2014. Universal Analytics hjælper med at overvåge klienter og besøgende på webstedet overalt: Værktøjet tildeler hver bruger et bruger-id, som tildeles ham for altid og roamer fra enhed til enhed . Hvis den samme person tilgår siden fra en telefon og en computer, vil Google Universal Analytics forstå dette og tage hensyn til det.

    Yderligere - mere. Værktøjet sporer enhver aktivitet hos dit publikum: webstedsbesøg, handlinger i mobilapplikationer og endda offlinekøb. Det hjælper med at evaluere brugeradfærd som helhed, snarere end inden for et enkelt besøg. I moderigtige termer kaldes dette "adfærdssporing på tværs af platforme." Nu kan du overvåge, hvordan de opfører sig Mennesker, ikke besøgende. Tidligere var det nødvendigt at drage konklusioner om effektiviteten af ​​en hjemmeside baseret på alle registrerede besøg. Samtidig kunne den samme person først finde noget brugbart på telefonen, og derefter studere alt i detaljer hjemmefra og med succes konvertere til en køber. Men samtidig blev det første besøg på siden regnet som ikke-konverterende og ubrugeligt, selvom det faktisk ikke er tilfældet.

    Sådan fungerer Google Universal Analytics

    Nemmere end den gamle version af værktøjet. Tidligere brugte Analytics så mange som 5 forskellige cookies at indsamle besøgsdata. De fortalte systemet, hvor brugeren kom fra, hvilket søgeord han indtastede i søgningen og andre vigtige oplysninger. Nu er alt anderledes - Universal Analytics bruger kun et særligt bruger-id. Så snart brugeren går til webstedet, sendes denne identifikator til Googles servere, og alt andet beregnes der.

    Ikke for alle

    Ordningen virker kun for registrerede brugere. Som standard er alle besøgende på webstedet nye. Men så snart en person registrerer sig og indtaster et brugernavn og en adgangskode, trækker systemet straks op og tildeler ham et bruger-id. Alt, hvad en logget ind bruger gør, registreres på hans personlige tæller.

    Lad os se på et eksempel. Lad os forestille os, at vi har en online boghandel

    • En ny bruger kommer ind på webstedet ved at klikke på en kontekstuel annonce, enheden er en smartphone. Den er tildelt ID_1. Manden ledte efter den bog, han skulle bruge, fandt den, men turde ikke bestille den med det samme – han ville gøre alt fra sin hjemmecomputer.
    • Efter at have nået hjem, går han igen til butikkens hjemmeside. Denne gang er overgangen direkte, og browseren er allerede en almindelig computer. Den er tildelt ID_2. Brugeren registrerer, vælger den rigtige bog og bestiller det. Alt dette er registreret på hans personlige konto.
    • En uge senere får vores helt igen adgang til webstedet ved hjælp af et link fra sociale netværk (sidste gang han abonnerede på VKontakte-butikken). I starten får han tildelt ID_3, men så kommer han ind personlig konto og systemet henter den gamle identifikator – ID_2. En person afgiver en ordre, og alle handlinger på siden registreres på den gamle tæller.

    Bruger-ID-funktionen kan aktiveres i afsnittet "Administrator". Vi er interesserede i menupunktet "Sporingskode" -> Bruger-ID.

    Okay, men hvad med de andre funktioner? Lad os finde ud af det nu.

    Sådan bruger du Google Universal Analytics Spor kunder offline

    Measurement Protocol vil hjælpe her - et særligt værktøj til at linke data fra forskellige kilder. Kundeoplysninger fra CRM kan overføres til analysesystemet i CSV-format. Dette kan være køn, alder og andre data om klienter.

    Measurment Protocol fungerer med enhver enhed, der er i stand til at sende en simpel HTTP-anmodning, selv en terminal og stregkodescanner. Denne funktion er nyttig, hvis kunder ofte betaler for køb kontant, når de møder en kurer eller ved et afhentningssted. Den største vanskelighed er at sikre, at betalingen er registreret på bruger-id'et bestemt person, men det er ganske muligt at gøre dette ved hjælp af selve protokollen. Google selv skriver mere om dette.

    Lav dine egne rapporter

    Denne funktion er praktisk, hvis du har brug for noget særligt. Det er her, brugerparametre og målinger kommer til undsætning. De første hjælper med at sortere brugere efter forskellige karakteristika: by, trafikkilde. søgeord og så videre. De andre er nødvendige for at spore eventuelle specifikke indikatorer med de parametre, du har brug for, for eksempel opkald længere end 5 minutter eller konvertering blandt kvinder. Det vigtigste er at arrangere afsendelsen af ​​disse data fra dit CRM og tilbage.

    Indstil sessionstimeout

    Som standard varer en session i Google Universal Analytics 30 minutter, og kampagner varer 6 måneder. Hvis dette er for kort til dig, kan du justere ventetiden efter din smag, selv i 10 timer. Dette kan være nyttigt, hvis brugere skal hænge på siden i lang tid for at afgive en ordre (dette sker). Du kan også konfigurere parameteren i menuen Administrator, her:

    Filtrer mærkevareforespørgsler

    Ingen husker hjemmesidens URL'er, alle søger bare efter dem efter firmanavn. Hvis du ikke gør noget ved det, vil sådanne overgange blive talt som normale søgetrafik, selvom de faktisk allerede har fundet dig og kender dig. Universal Analytics hjælper dig med at gøre dette. Gå til den samme administratormenu og vælg "Liste over ekskluderede søgeforespørgsler" i supermenuen "Sporingskode" (det er på skærmbilledet ovenfor).

    Returner brugere til webstedet

    Universal Analytics har sit eget remarketingværktøj. Det hjælper dig med at køre AdWords-annoncekampagner for målgrupper, der allerede har besøgt dit websted. For eksempel ledte en bruger efter et kamera på din hjemmeside, fandt det, kiggede på det, men købte det ikke. Hvis der er mange sådanne mennesker. du kan løbe reklamekampagne med en dynamisk egenskab. I dette tilfælde vil annoncen inkludere det samme ukøbte kamera og sige "godt, køb mig, du lovede." Du kan aktivere remarketing i den samme administratormenu, som alle er trætte af:

    Vurder sammensætningen af ​​målgruppen

    Du kan konfigurere analysesystemet, så det indsamler data om besøgendes køn, alder og interesser (ligesom i Yandex.Metrica, ja). Med deres hjælp kan du segmentere målgruppe og straks tage det i omløb - start en annoncekampagne i AdWords for segmentet.

    Spor stien til målhandlingen på alle platforme

    Det bruger-id, der er knyttet til hver bruger, hjælper med at bestemme, hvilke enheder personen brugte, før han foretog et køb – jeg har allerede givet eksempler på sådanne situationer. Ved hjælp af analyseværktøjer kan du se, hvor mange mennesker der ser siden fra en telefon og køber varer fra en computer eller omvendt. Dette vil hjælpe dig med at vurdere mobiltrafikkens rolle i dit tilfælde. Hvis gadgetbrugere køber meget hos dig, bør du overveje at forbedre mobiloptimeringen og alt det der.

    Google Universal Analytics er et meget kraftfuldt værktøj. I forhold til den gamle version af tjenesten er der kommet meget til. Du kan tilføje integration med offline salg, opsætte remarketing, generere dine egne rapporter med de nødvendige parametre og gør en masse andre nyttige ting. Ja, det er ikke altid nemt at finde ud af, hvordan et system eller en separat funktion fungerer. Men hvis du kæmper dig igennem alle felter, kolonner og grafer, vil resultatet være en enorm række nyttige oplysninger.

    • Oversættelse

    Alle virksomheder vil før eller siden gå online, og webanalytikere bliver forretningsanalytikere. Webelementer bliver allerede brugt i forretningsanalyse.

    En digital analytiker er et ret snævert speciale – det er blot en forretningsanalytiker, der primært arbejder i den digitale verden og lidt i den virkelige verden.

    Snart er der ingen opdelinger. Ingen digital, ingen web, ingen offline - bare alt sammen.



    Relativt for nylig udgav Google Universal Analytics. Den har indbygget interessante muligheder til forretningsanalyse. Desværre er det de færreste, der ved, hvilke muligheder vi taler om.

    Bruger-ID'et bestemmes af analytikeren og sendes til GA gennem en parameter i koden. User-ID indeholder ikke personlige data. For at kode brugeren kan du bruge en 64-bit hash.

    Du kan se brugere med og uden bruger-id. Over tid vil det blå felt øges og tillade bedre undersøgelse af adfærd. Men selv med så mange brugere, kan User-ID allerede svare på et par spørgsmål. For eksempel, hvor mange mennesker bruger desktop og mobil version. Eller finde ud af, om købere rent faktisk søger på mobilen og køber fra fastnet?

    Selvom siden ikke er kommerciel, er det stadig vigtigt at få brugeren til at registrere sig på siden. Med User-ID er det nemmere at analysere dette og komme frem til en passende løsning. Dette er en vigtig markedsføringsopgave. Menneskets psykologi skal tages i betragtning.

    L'Oreal Paris gør dette meget godt. De har meget interessant indhold, hvilket får brugeren til at vende tilbage til siden igen og igen. Hver artikel og produkt er udstyret med en "Gem"-knap, som virker selv for ikke-loggede brugere. Men hvis brugeren ikke ønsker at miste sine bogmærker, skal han oprette en konto. Ved siden af ​​hvert produkt er der en “Vælg” knap, som giver dig mulighed for at vælge artikler og produkter, som er interessante for køberen, og det fører også til login.

    Vær ikke den slags selskab, der beder til guderne for at få vigtig information. Det er bedre at skabe nye muligheder og grunde til, at købere kan identificere sig på siden.

    Du kan også modtage rapporter om, hvor mange personer der får adgang til siden fra forskellige enheder.

    Bare et par musebevægelser og her er de svarene på alle dine spørgsmål.

    Dette er den enkleste fremstilling. Du kan spore din indkomst og transaktioner. Ved hjælp af UA kan du se, hvor en person startede sin rejse, og hvordan han interagerede med webstedet fra en eller flere enheder.

    Importer Alle data, der er indsamlet offline, kan importeres til Google Analytics. For eksempel vil data fra CRM udvide din forståelse af klienten markant.

    Det eneste, GA kan fortælle os om brugeren fra det første eksempel, er et unikt ID.

    Ved at øge størrelsen af ​​databasen kan du tilføje en anden nyttige oplysninger om klienten.

    Jo flere oplysninger der tilføjes, jo mere kan de suppleres (men uden brug af personlige data).

    For at gøre dette skal du logge ind på din konto og i egenskaberne klikke på "Importer data". Data kan også importeres ved hjælp af Google Analytics Management API:

    De rapporter, du ser der, afhænger af de data, der sendes til GA. For eksempel kan oplysningerne se sådan ud:

    Sådan kan du analysere primære metrics baseret på sekundære metrics. For eksempel efter uddannelsesniveau.

    Et andet eksempel: at bruge rejseselskab. Opdelt i typer af rejsende:

    Her kan du se en detaljeret manual om import af data.

    Protokol til måling og dataoverførsel Når nogle handlinger sker offline, er det muligt at overføre dem til GA gennem en speciel protokol. Disse data kan knyttes til almindelig brugeraktivitet.

    Sådan ser rapporten ud:

    Den første og anden kolonne er også tilgængelige i almindelig GA. Men integration med CRM-databasen åbner op for adskillige flere muligheder: offline afslag, offline aftalelukninger osv. Alle disse oplysninger hjælper dig med at lære mere om dine kundeemner.

    Simpelt kodeeksempel:

    POST /indsaml HTTP/1.1 Host: www.google-analytics.com v=1 // Version af GA-protokol. Konstant. &tid=UA-XXXX-Y // Ejendoms-id &cid=555 // GA-klient-id. Hentet fra sporingskode. &ni=1 // Ikke-interaktionshit. &t=hændelse // Hændelseshittype. Påkrævet. &ec=ClientOfflineConv //Begivenhedskategori. &ea=OnlineLead // Hændelseshandling påkrævet. &el=OpportunityRegistered // Event Label. &ev=300//Begivenhedsværdi (300)

    • ec (kategori): Vil gruppere alle offline data.
    • ea (handling): Den truffede handling.
    • el (etiket): Begivenhedsnavn. Ændres sammen med ændringen i brugerens status i databasen.
    • ev (værdi): Skal indstilles, hvis værdien er knyttet til offline data.
    Og her er et eksempel på offline dataintegration ved hjælp af en server-til-server-anmodning:

    Funktion gaFireHit($data = null) ( if ($data) ( $url = "https://ssl.google-analytics.com/collect"; $getString .= "?payload_data&"; $getString .= http_build_query($ data); $result = socketPost($url, $getString, $_SERVER["HTTP_USER_AGENT"]); ; $port = isset($parts["port]) ? $parts["port"] : 80; $success = $fp = fsockopen($parts["host"], $port, $errno, $errstr, 30 ); if ($fp) ( $output = "POST" . $parts["sti"] . " HTTP/1.1\r\n"; if (is_string($ua)) ( output .= "Bruger-agent: " . $ua . "\r\n" ) $output .= "Vært: " . $parts["host"] . : application/x-www-form-urlencoded\r\n"; Content-Length: " . strlen($post_string) . "\r\n"; $output .= "Forbindelse^ Luk\r \n\r\n"; $output .= isset($post_string) ? $post_string: ""; $success = fwrite($fp, $fp) returner $success: false;

    Bonusser Der er et par andre ting, som Universal Analytics kan gøre nemmere. f.eks.