Universal Google Analytics - en kombinasjon av mobil- og WEB-analyse. Konfigurere e-handelssporing for en Google Analytics-konto
Etter flere år på nettet har markedsførerne våre blitt vant til analysesystemer, de forstår dem, er kjent med de fleste verktøyene og vet hvordan de skal bruke dem. De lærte å jobbe med det på 5-10 år. Og mobilanalyse er fortsatt en mørk skog for dem. Følgelig henger funksjonaliteten litt etter nettet i utviklingen, fordi bransjen er ung.
Vi vil snakke om disse problemene med den eldste Google-analytiker Analytics, Stanislav Vidyaev. Full lydversjon av intervjuet - iTunes, TuneIn.
Jeg logger på systemet, hvilken funksjonalitet må jeg mestre først for å faktisk begynne å jobbe med produktet ditt? Kanskje det er litt litteratur, seminarer, bøkene dine på engelsk?
Google Analytics er i utgangspunktet et nettprodukt og alle relevante beregninger er godt utviklet i det.
Utviklingen går på en slik måte at nettproduktet i utgangspunktet begynner å tilpasse seg fremveksten av denne mobile verdenen.
For å være ærlig, da Google-selskap litt sent: vi fikk våre første mobilprofiler for 2 år siden (juni 2012), siden den gang har mobilretningen utviklet seg, og systemet prøver å mestre mobilspråk. Men nærmer seg fortsatt den mobile verden fra synspunktet til en nettmarkedsfører.
En markedsfører som har vært involvert i nettanalyse og nettsteder er allerede mer eller mindre forberedt, og når han kommer til oss for å analysere en mobilapplikasjon, velger han de vanlige beregningene.
De er lite anvendelige for en mobilapplikasjon, men de kan likevel brukes når man skal vurdere effektiviteten til en mobilapplikasjon.
Alle beregningene som er der og som er synlige umiddelbart etter installasjon av Analytics. Denne mengden aktive brukere, ny, returnerende, geografi for bruk av applikasjoner, popularitet til individuelle seksjoner, hvordan folk ser på dem (samme konverteringer, kjøp) - hele settet som i utgangspunktet er nødvendig for å forstå hva som skjer i mobilapplikasjonen. Noen andre ting kan konfigureres - Egendefinerte dimensjoner.
Hva er egendefinerte dimensjoner?
Dette er tilleggsparametere som ikke eksisterer som standard, men vi kan opprette og angi dem. For eksempel, en bruker i en applikasjon klikker på en knapp og blir en betalt bruker, vi kan merke ham som en betalt bruker, som han vil forbli hos resten av livet så lenge han har denne applikasjonen installert.
Det vil si at vi kan segmentere alle hans videre besøk som en gruppe betalte brukere av applikasjonen vår. Dette er i tillegg konfigurert, og i utgangspunktet er ikke disse beregningene inkludert i Analytics. Det vil si at du må tenke på dette på forhånd, komme opp med denne beregningen, forstå på hvilket tidspunkt du skal lage og lansere den. 
Det finnes en slik konstruktør på nettet. Vi bringer nettet til mobil. Arkitekter mener at de samme analysekonseptene og prinsippene som finnes for nettsteder, også gjelder for mobilapplikasjoner
Hvor kan jeg få det første settet med kunnskap?
En bok er den verste måten å beskrive et problem på; så snart den er publisert, blir den umiddelbart utdatert. Jeg ville sendt alle til vår ressurs. Den eneste ulempen er at den kun er på engelsk og ennå ikke er oversatt til russisk.
Denne ressursen inneholder den nyeste informasjonen, alle kunngjøringer gjøres der.
Naturligvis er internett stort, det er mange smarte mennesker som skriver noe som er verdt på egenhånd. I utgangspunktet ville jeg lest anmeldelser av forskjellige systemer og sammenligninger fra forskjellige forfattere. De er ikke alltid riktige, de går glipp av noe, men generell idé flink.
Hvilke reelle utfordringer ser du i mobilanalyse akkurat nå?
Dette er kompleksiteten til systemet som helhet. Det vil si teknisk analyse i mobilapplikasjoner. Jeg tar ikke nettsider, for kanskje i fremtiden vil vi ikke ha en deling mellom en mobil og en vanlig nettside, og noe slikt som et mobilnettsted vil forsvinne.
Hvis vi tar applikasjonen, så er dette kompleksiteten i teknisk implementering, integrasjon av pakker og store installasjonskrav for teknisk opplæring av den som gjør det.
Hvis du installerte koden på nettstedet og gikk (det er noen data), må du i applikasjonen tenke på forhånd hva vi vil spore, hvordan og i hvilke øyeblikk vi vil utløse visse hendelser. Det vil si at alt dette må tenkes ut på forhånd, og den tekniske spesialisten må implementere denne saken. Igjen, hvis vi snakker om selve Google Analytics, som jeg nevnte, begynner systemet bare å venne seg til mobildefinisjoner.
Det er et annet tema som utvikler seg i dag (på den ene siden er dette en svakhet ved Google Analytics, men de ønsker å gjøre en veldig stor sak ut av denne svakheten sterke poeng) er en kombinasjon av to verdener - nett og mobil.
Det er nettopp under "paraplyen" til Universal Analytics at vi vil bevege oss i denne retningen. Universal Analytics er en ny reinkarnasjon av Google Analytics, som har en annen kode og arkitektur, den bruker forskjellige informasjonskapsler - dette er nytt system. Det kalles Google Analytics bare fordi det er synlig i grensesnittet.
Da jeg forberedte meg til intervjuet, så jeg igjen på dokumentasjonen fra en annen god kilde - developers.google.com - der Teknisk informasjon. Jeg så også på SDK, og det er allerede en bruker-ID-del som kan brukes til å spore konverteringer fra forskjellige enheter til nettstedet (foreløpig kun til nettstedet) til samme bruker.
Hva er prinsippet der?
Brukeren kommer til nettstedet, klient-ID-en lastes inn i nettleseren hans - dette er Google Analytics-identifikatoren, og den er unik for denne nettleseren, det vil si hvor mange nettlesere brukeren har, så mange identifikatorer og følgelig, unike besøkende V Analytics-rapporter. Hvis han har tre nettlesere på én enhet, vil disse være tre forskjellige brukere.
Det er en bruker-ID - dette er en parameter for bedriftseieren, nettsideeieren. Det vil si at når en bruker har registrert seg, fylt ut en søknad (identifisert seg på en eller annen måte), kan nettstedets eier laste opp denne bruker-IDen.
Så bruker-ID har allerede dukket opp i dokumentasjonen for mobilapplikasjoner. Det vil si at vi kan kombinere ikke bare hans historie med å besøke nettstedet, men også applikasjoner. I dette øyeblikket Vi har fortsatt et klart skille mellom nett- og mobilverdenen. Men da vil Universal Analytics bevege seg mot å kombinere disse to verdenene.
Du promoterer aktivt Google Tag Manager. Hva er dette, hvordan fungerer det?
Google Tag Manager er en måte å jobbe med sporingskoder på. Hvis vi tar nettsider er dette kode, et script - en kodebit som vi installerer på siden, og først da i Tag Manager-grensesnittet jobber vi med direkte sporingskoder for analytiske systemer. 
Og denne Tag Manager-koden, den utfører funksjonene til andre koder, det vil si at den sender anrop, utgir seg for å være dem, og for øyeblikket kan den fungere som Google Analytics, deretter som Yandex.Metrica, deretter som konverteringssporing - den utfører funksjonene til disse kodene.
Hvilket problem løser det?
Problemet med å installere koder i kildekoden til nettstedet. Det vil si at vi ikke trenger å løpe til en teknisk spesialist eller en webprogrammerer hver gang og si: "Installer denne lille linjen." Og han legger det i Pipeline, og denne tingen varer i tre måneder, den redigeres, så blir den utført - jo større selskapet er, jo flere problemer er det i denne forbindelse.
Med Tag Manager har vi én kodebit på nettstedet, kanskje det er noen tilleggsfunksjoner, som vi tenkte gjennom på forhånd, for eksempel en transaksjon. Ekstra alternativer i syntaks Tag Manager overført til Datalag er en måte å sende hendelser, variabler og transaksjoner til Google Tag Manager. Det vil si at alle parameterne er spesifisert, og så kan vi spore for eksempel transaksjoner i både Google Analytics og Yandex.Metrica – uansett hvor vi trenger det.
Er det den samme historien i mobilanalyse?
Historien er som følger. Skaperne og utviklerne av Tag Manager gjorde det som følger: det er én enkelt SDK for Tag Manager og Google Analytics. Det vil si ved å integrere i SDK siste Google Analytics med applikasjonen, du integrerer Tag Manager. Og omvendt – ved å integrere Tag Manager får du Google Analytics.
Det vil si at det er ganske enklere og mer effektivt å administrere denne koden. Det handler ikke bare om slike markedsføringsgrep. La oss si at du trenger å spore en hendelse i Tag Manager, for dette trenger du ikke å gå inn i utviklingen og tvinge dem til å gjøre det ny verson applikasjon, publiser den slik at denne samtalen eller arrangementet er inkludert.
Det vil si at jeg kan sette opp sporing av enhver hendelse uten hjelp fra utviklere?
Ja. Forutsatt at denne hendelsen legges inn i Tag Manager. Det vil si at hvis den er der, så kan du inne i Tag Manager skrive inn eventuelle koder som trengs for denne hendelsen. Det er mye enklere.
Det er ett poeng til. Ved integrering med Analytics oppstår det muligheter for for eksempel å gjennomføre eksperimenter.
Hva slags eksperimenter?
Dette er eksperimenter på ekte brukere. Det vil si at vi ikke er et sted i en sandkasse som tester forskjellige farger, størrelser på knapper, bilder, tekster, logodesign osv. Alle disse designelementene kan endres dynamisk og eksperimenteres med i Google Analytics.
Det vil se slik ut. Eksperimentet opprettes og konfigureres i Tag Manager, og visualiseringen av dette eksperimentet og alle grafene som viser hvilket programkonfigurasjonsalternativ som ble vunnet, er alle synlige i Analytics. Og etter at dette eksperimentet er fullført, vil det være mulig å konfigurere applikasjonen i Tag Manager på en slik måte at vinneralternativet blir det grunnleggende.
Dette er for eksempel et eksperiment med et skjema: hvilken registrering er bedre - bare Facebook eller Facebook + E-post?
Ja, inkludert. Elementene vi ønsker å utføre et eksperiment med, dekorerer vi dem med Tag Manager-variabler, det vil si et containerkall.
Jeg ser et problem: det er en enkel vanlig markedsfører - det er umulig for ham å implementere et analytisk mobilsystem (ikke et i det hele tatt) uten å gå til utvikleren. Faktisk er det ikke mange alternativer, dette er virkeligheten i markedet.
Men det er et annet alternativ - du har et verktøy som Google Developer Console. Hvorfor ikke legge det ut der? mer mengde informasjon om oppbevaring, churn rate, etc.?
Vi beveger oss i denne retningen, men det er ingen ideell situasjon, vi kan bare strebe etter det. Rapporter vises. Nylig kom det en junioppdatering - en rekke rapporter for spillapplikasjoner dukket opp. Det vil si at du kan se antall spillere, oppbevaring osv. Men igjen, dette er ganske generell informasjon.
Hvis du vil se noe slikt, for eksempel, se med ved hjelp av Google Analytics, hvordan brukere slipper når de passerer ulike nivåer spill. Du har for eksempel 10 nivåer, og ved hjelp av analyser oppdager du at nivå 5 og 6 er for vanskelige, brukere passerer dem ikke og faller av. Etter det gjør du dem litt lettere, og de når nivå 7-8. Det vil si at varigheten av brukerinteraksjon i ett leketøy øker.
Disse unike tingene for alle kan ikke skjerpes på en slik plattform, så Google Analytics spiller inn, som kan modifiseres til disse formålene, konfigureres og spores der.
Hva er de grunnleggende Google-funksjoner Utviklerkonsoll?
Det er her vi publiserer søknader. Det vil si at vi oppretter en utviklerkonto, vi publiserer applikasjoner, betaler $25 og begynner å markedsføre den på Google Play (du kan ha flere applikasjoner), og noe statistikk er tilgjengelig der som standard. Men igjen, dette er ikke egnet for seriøs analyse - dette er det grunnleggende nivået. 
Har du en praktisk måte å spore kilden til installasjoner, noe sånt som en analog av samme MAT. Det vil si, for Android ser det ut til å være der, men hvordan gjør jeg det for iOS?
Dette er et spørsmål om Google Play-integrasjon med applikasjonen. Hvis vi gjør dette, så kan vi se kildene som kommer til Google Play (til siden vår) og deretter bli til installasjoner, så kan vi koble denne historien med konverteringer.
I nettsjargong – Google Play holder frem henvisningsadressen. Det vil si at henvisningen som ga oss trafikk (dette kan være en betalt kilde, tilknyttede programmer, sosiale nettverk - hva som helst), vi kan se alle disse tingene i applikasjonsanalysen.
Dessuten er emnet videreutviklet der - konverteringssporing for å sende konverteringen tilbake til samme AdWords - dette er også mulig, helt frem til siste klikk på en bestemt annonse i en spesifikk applikasjon. Vi ser konvertering.
Basert på denne analysen ser vi kilde 1, kilde 2, installasjoner, konverteringer. Vi ser at kilde 1 må slås av, fordi den ikke konverteres, og alle penger må overføres til kilde 2, for eksempel. Analytics om dette. Dette er nettopp kombinasjonen av markedsføringshandlinger med brukeratferd inne i en Android-applikasjon. 
iOS overfører ikke, utvider ikke henvisningen. For å gjøre dette på developers.google.com/, er det en beskrivelse av prosessen for hvordan du drar denne henvisningen. Det vil si at det allerede er serverintegrasjon, seriøst teknisk oppsett er nødvendig.
Hvordan beregner man brukerens levetid riktig i en applikasjon?
Vitenskapen vet ikke hva som skjer etter den siste overvåkede hendelsen. Brukeren klikket og åpnet siden – hvor lenge var han på den? Han leste den i 5 minutter eller studerte den i 40 minutter diagonalt, opp og ned og på tvers - vi vet ikke.
Vi har tiden brukeren er på siden eller i mobilapplikasjonen - dette er første og siste hendelse, og vi måler perioden som har gått mellom dem. Det vil si at Google Analytics sporer en hendelse, og nedtellingen begynner fra dette punktet.
Hva kan gjøres for å gjøre denne saken mer nøyaktig?
Det var en slik teknikk, den fungerte for nettsteder. For eksempel sidevisning: la oss si at vi har et stort innholdsnettsted, vi har enorme artikler, folk leser analyser. Jeg åpnet siden - jeg leste den, ingen flere hendelser skjer. Det vil si at Analytics ikke vet og kan ikke vite hvor lenge jeg har vært på denne siden.
For å måle tiden på denne siden avfyrer vi et arrangement. La oss si at hvert 15. sekund mens brukeren er på siden sender vi en hendelse eller sporer Scroll som en hendelse – det viser seg at vi gir Analytics beskjed om at brukeren fortsatt er på siden.
For applikasjonen kan du kjøre noe lignende. Ikke bare spor klikk på knapper, men også ting som Sveip, Zoom inn, Zoom ut – vi kan også sende hendelser til alle disse handlingene som er strengt gjeldende for applikasjonen. Det vil si at en Zoom inn skjedde på en skjerm, og en Zoom ut skjedde på en annen skjerm. Alt dette kan spores, og dette vil øke tiden brukeren samhandler med applikasjonen. Og hvis den er åpen og skjermen er mørk, så tror jeg det ikke er nødvendig å spore noe.
Slike ting som viralitet, organiske stoffer, etc. - er det mulig å spore i det minste viraliteten til en applikasjon eller i det minste anslå den omtrentlige verdien?
Estimer heller den omtrentlige verdien. Det er ingen viralitetsrapport i Google Analytics. Vi må tenke på forhånd og prøve å forestille oss hvordan søknaden vår kan avvike og hvordan handlingene våre kan påvirke dette.
Vi lanserte en annonse, etter den er det noen en lang hale, som alltid kommer gjennom - du må se segmentet. Det vil si at vi allokerer annonsetrafikk til segmentet, vi vet på hvilke datoer noen offline arrangementer finner sted og andre innholdsprosjekter finner sted.
La oss si du og jeg bil app, og vi holder et motorrally Moskva-Petushki, hvor vi promoterer denne applikasjonen - og det er reklame for applikasjonen på alle sider av bilene. Vi ser på datoene for dette bilrallyet (det er en merknad i Google Analytics, alt dette kan registreres etter tid) og dynamikken til installasjoner, etc.
Eller det var for eksempel nyheter på TV i dag. Følgelig ser vi på organisk trafikk, merkesiteringer i søk – alle disse tingene må kombineres. Du kan dele dette ned i segmenter og se hvordan annonsetrafikk påvirker organisk vekst.
Er organisk trafikk allerede synlig i rapportene dine?
Ja. I Analytics kan du se dette, det vil være to segmenter - to kurver - de følger hverandre eller så gjør de det ikke. Følgelig er det også mulig å evaluere kvaliteten på trafikken, for eksempel hva som er brukerinteraksjonstiden, om den er avtagende eller økende. Det vil si at vi tar med det publikummet eller ikke. Det er det samme med konverteringer.
Alle disse tingene kan vurderes av en rekke indirekte tegn. Naturligvis er det ingen direkte rapportering.
Det er et annet problem - svindel i mobilsegmentet: trafikk av lav kvalitet strømmer inn. Er det mulig å oppdage denne svindelen? Jeg vet hvordan jeg gjør dette på nettet. Det vil si, jeg ser kilder, jeg ser til og med på det samme Google-nettverket, det han ikke fanget, jeg fanger det selv og ser etter svindlere med tapte klikk, uansett hva - det er mange alternativer for å overliste meg. Jeg kuttet av hvert område i detalj.
Hvis du har noen mekanismer for å sile ut denne svindelen på mobil med samme Google Analytics?
Analytics er ikke laget for å fange tyver. Igjen, dette er en rekke indirekte tegn.
Jeg har ennå ikke hatt noen tilfeller der jeg fanget noen spesielt for mobilanalyse, men det var noen med nettsteder. Kunder kontaktet oss og spurte hva slags trafikk dette var.
Svindel kan sees av noen spesifikke interaksjonsindikatorer.
Det hender at de lager slike bannere at når jeg klikker på krysset, kommer jeg likevel til annonsen. Hvordan skal jeg forstå at noe er galt der på grunn av hvilken hendelse?
Det første tegnet er en høy fluktfrekvens. Hvis målet vårt er installasjoner og denne trafikken gir installasjoner, er det litt mer komplisert. Hvis vi ser et stort antall besøk Google-sider Play/App Store og få installasjoner, og for oss er denne trafikken betalt, da kan vi lure på hvordan dette skjer.
For øyeblikket, hvis det er en reklamekampanje, kan du gå og se på denne annonsen, be dine slektninger om å gå, kolleger til kolleger, slik at de ser på denne tingen fra forskjellige enheter (helst i forskjellige regioner) og ringe. Følgelig, hvis det er svindel, kan det i det minste bli fanget på denne måten.
Hvordan du skal oppføre deg med partnere er neste spørsmål, men Analytics selv vil ikke se fakta om svindel, men vil ganske enkelt fortelle deg at det er klart at de kommer og ikke installerer.
Spørsmål om restriksjoner på produktet når det gjelder volum, antall arrangementer osv. – gjelder de for mobil?
Ja. Begrensningen er generell for all Analytics og for enhver ressurs. Og det er flere begrensninger direkte for mobilapplikasjoner. Alt dette er beskrevet i dokumentasjonen.
For standard Google Analytics er dette 10 millioner treff per måned.
For én ressurs er denne begrensningen ganske fleksibel. Det vil si at hvis vi har 30-40-50-100, jobber vi normalt. Det eneste negative som skjer er at vi inkluderer sampling – nøyaktigheten av dataene lider. Vi ser de samme grafene og trendene, men relativt sett tar systemet i individuelle rapporter 10 % av denne trafikken som grunnlag for å beregne denne rapporten, og multipliserer den deretter i tankene. Dette er prøvetaking.
Med ankomsten av forhandlere i Russland, og med muligheten til å kjøpe Google Analytics Premium for disse nettstedene, inkludert applikasjoner, blir denne regelen strengere. Det vil si, vi varsler: "Kjære kunde, du har overskredet grensen med så mange ganger."
Hvis du har 10-20-50 millioner treff, blir det ingen slik melding. Hvis det er mye - 500 millioner per måned, så er det stor sannsynlighet for at et slikt varsel blir mottatt.
Er det mulig å i det minste ta rådata fra en mobilapplikasjon for å bygge din egen analyse?
Ja. Til Mobile API Det er ingen slike applikasjoner i applikasjoner akkurat nå, men jeg tror at under "paraplyen" til Universal Analytics vil den være tilgjengelig. Spesielt det faktum at User ID begynner å bli knyttet til mobile enheter, og dette er et tema nært API. Serveren jobber allerede med Stor Data og andre integrasjoner.
Jeg tror at dette emnet vil bli utviklet i nær fremtid, og API for mobilapplikasjoner vil enten være separat eller innenfor Core Reporting API, som for øyeblikket er tilgjengelig i Analytics. Jeg vet ikke hvordan det blir arkitektonisk, men det antyder selvsagt selv hva det blir.
Det er sikkert et slags veikart du har hørt om og som kollegene dine lar deg fortelle om. Hva vil skje? Når vil slike beregninger som Return Rade, LTV og noe annet vises? Når begynner Google Analytics å snakke til meg på mobilspråk?
Som et tre år gammelt barn prøver han å mestre språket til mor og far og sier allerede noe. I i dette tilfellet Return Rade på nettet har en lojalitetsrapport – ny og tilbakevendende. Det finnes lignende rapporter i mobil, bare de kalles litt annerledes, men du kan se og jobbe med dem der.
Når det gjelder LTV, er det ingen slik rapport, men den kan samles inn ved hjelp av tilpassede beregninger og parametere. Det vil si at konvensjonelt vet vi at denne brukeren i går kjøpte noe fra oss for 5 rubler, og vi skriver i en variabel for ham at han forlot 5 rubler hos oss. Hvis han kjøper noe annet for 5 rubler i morgen, kan vi ta de forrige 5 rubler og legge til ytterligere 5 til dem og få 10 rubler.
Igjen, du kan ikke forutse alle tilfeller. Vi kan ikke alltid forutse og forutsi at en gitt funksjon faktisk vil være vellykket. Og du kan gi muligheten til å konfigurere det du trenger selv ved å bruke de samme tilpassede variablene (brukerdefinisjoner på Universal Analytics-språket).
Det er variabler på treff-, økt- og brukernivå. Og bare for LTV er en økt på brukernivå bedre egnet, når vi tildeler en eller annen parameter til brukeren.
Alle snakker om det, men ikke alle bruker det, fordi det er en ganske spesifikk funksjon. Og segmenter deretter brukeren som forlot 10 rubler mot brukeren som la igjen 5 rubler, og sammenlign dataene om dem.
Generelt mangler du pedagogiske ting i enkelt språk.
Faktisk er det vestlige markedet mer forberedt og utdannet i denne forbindelse. De har ingen problemer med å kommunisere på mer fagspråk. Det vil si at folk der er kunnskapsrike, og du kan ganske enkelt fortelle dem: "Her er tilpassede variabler." Og som svar: "Ok, jeg skal gjøre det, jeg forstår alt."
Kanskje det er noen andre funksjoner, overraskelser, Tilbakemelding, push-varsler?
Intern kommunikasjon med produktsjefer er strukturert på en slik måte at en ting som passer blir fortalt oss om det. Det jeg snakket om den kombinerte funksjonaliteten til Tag Manager og Google Analytics, om mulighetene i dette systemet, dette er akkurat den typen funksjonalitet som blir tilgjengelig akkurat nå.
De snakket om eksperimenter i mobilapplikasjoner ganske nylig, de tester for tiden, og vil snart rulles ut. Vi kan allerede i en halv hvisking fortelle at det er eller snart blir.. Når det gjelder enkeltting, som det blir vanskelig for meg å si senere.
Er det noen tilbakemeldinger fra markedet?
Ja. Vi har utviklere, spesialister som kommuniserer innen Google med selgere – hos oss selger vi AdWords og i tillegg til dette har vi kundenes behov for analyser.
Vi kommer sammen, og denne kommunikasjonen går slik. Vi har en person i Øst-Europa, vi kommuniserer til ham at vi har slike og slike vanskeligheter, slike og slike muligheter og fantastiske konkurrenter - la oss se på grensesnittet sammen, kanskje noen ideer vil dukke opp.
Vi ser sammen, han kommer med ideer og han kan formidle dem til utvikleren. Utvikleren sier - "Ok, interessant emne, la oss se på". Det er slik kommunikasjon.
For ikke lenge siden annonserte Google ny tjeneste statistikk, som kalles Universal Analytics. Imidlertid begynte mange å bruke det ikke så aktivt som skaperne av dette systemet hadde planlagt.
Av denne grunn bestemte utviklerne seg for å gjøre overgangen til Universal Analytics-tjenesten obligatorisk. Nå vil du i en måned ha muligheten til å fortsette å bruke den vanlige Google-tjenesten, men etter dette blir du automatisk omdirigert til det nye systemet.
Hvordan er Universal Analytics så forskjellig fra den vanlige Google Analytics? I det store og hele er det svært få forskjeller. Den nye statistikktjenesten gir deg imidlertid mange nye funksjoner som vil være nyttige for deg. Det vil bli utvidede rapporter om trafikken til prosjektet ditt og effektiviteten til reklamekampanjer. Men hvis du har brukt Google Analytics lenge, vil du ikke merke stor forskjell.Den obligatoriske overgangen til en analysetjeneste skyldes utvikleres ønske om å kombinere flere verktøy til ett. På den ene siden er alt bra, fordi du vil ha tilgang til mer brede muligheter. En tvungen overgang til Universal Analytics-tjenesten er imidlertid ikke så ille for de som er vant til å jobbe i gammelt system. Men hva kan du gjøre hvis du ikke har så mye valg?
Men for å bruke den nye statistikktjenesten, må du gjøre noen justeringer på nettstedet ditt. Først av alt må du oppdatere sporingskoden. Uten dette vil ikke analysetjenesten kunne samle inn all informasjonen du trenger. Det er veldig enkelt å gjøre. I kontoinnstillingene dine må du velge en sporingskode, kopiere den til en fil og deretter laste den opp til hostingen din. I løpet av et par minutter vil Universal Analytics begynne å samle inn data fra prosjektet ditt.
Hva er Universal Analytics Som utviklerne selv sier, er Universal Analytics absolutt ny standard tradisjonell Google-tjeneste Analytics. Selv om han kunngjør et stort antall funksjoner som vil være tilgjengelig, er det ingen spesielle innovasjoner akkurat nå. Mest sannsynlig vil nye dukke opp i fremtiden funksjonalitet, men nå store forskjeller Det er ingen forskjell mellom den gamle og nye versjonen.Hvis du ennå ikke har byttet til den nye Universal Analytics-tjenesten, så gjør det raskt. Ellers vil du etter en tid bli tvunget til å bruke den nye tjenesten, og tilgangen til tradisjonell Google Analytics vil ganske enkelt bli blokkert.
Hei, kjære lesere av bloggsiden. Googles analysetjeneste regnes med rette som en av de mest funksjonelle på Runet-markedet, og samtidig er den helt gratis.
I denne artikkelen vil jeg introdusere deg til prinsippene for drift av dette systemet og enkle konsepter, innebygd i grunnlaget, slik at du selv med et nærmere bekjentskap med det forstår hva som er hva og ikke forvirrer brukere, økter (økter) og interaksjoner (treff), og forstår også forholdet mellom parametere og indikatorer.
I inneværende periode Google-systemet Analytics gjennomgår en oppdatering, fordi det erstattes av et mer avansert kompleks kalt Universal Analytics, hvis sporingskode allerede tilbys for installasjon. Derfor vil jeg i denne artikkelen beskrive de nye egenskapene som Google Analytics vil motta etter sin reinkarnasjon i UA (motta data fra alle enheter koblet til nettverket, etc.).
Funksjoner og prinsipper for drift av Google AnalyticsGoogle Analytics er et analysesystem som går langt utover mulighetene til vanlige, som Top100, og til og med Yandex Metrica. Dette systemet er like kraftig som det er vanskelig å mestre, spesielt for utrente brukere. Til tross for all dens imponerende funksjonalitet, har Googles hjernebarn en ganske høy inngangsbarriere, og mange bruker enten ikke denne analysen eller bruker bare en svært liten del av alle mulighetene den gir.
Med Google Analytics kan du samle inn og analysere data ulike enheter og digitale medier. På denne måten kan du for eksempel forstå hvordan kunder finner nettsidene eller mobilapplikasjonene dine og hvordan de samhandler med dem (vurdere brukeratferd). Selve analysesystemet består, kan man si, av fire blokker som utfører følgende funksjoner:
Med disse fire komponentene kan du samle inn, tilpasse og analysere data på tvers av nettstedet ditt. La oss starte i rekkefølge, nemlig med datainnsamlingsblokken. Hvordan gjøres utvinningen? nødvendig informasjon? Det stemmer, ved å bruke tellerkoden som er installert på nettstedet (eller mobilapplikasjonen). Generelt, som vanlig.
Denne sporingskoden inneholder en rekke instruksjoner til Google Analytics som forteller deg hvilke brukerinteraksjoner med nettstedet du bør ta hensyn til og hvilke data du bør samle inn. Metoden for datainnsamling bestemmes av det digitale miljøet som måleren opererer i. For eksempel, når du installerer det på et nettsted, brukes JavaScript-sporingskode. Og for å integrere målerkoden i en mobilapplikasjon brukes et såkalt utviklersett (SDK).
Brukeren, gjennom sine handlinger, gir liv til Google Analytics-sporingskoden (åpner en side på nettstedet ditt eller går til et nytt skjermbilde i applikasjonen din). Som et resultat samles det inn informasjon om alle handlinger som utføres, inkludert titler og URL-er til sider som vises, og andre ting, som deretter samles inn i en pakke (treff). Denne pakken sendes til systemserveren for å utføre neste trinn - databehandling.
Alle disse "rå" dataene på Google-serveren går gjennom silen av innstillingene du har gjort (din konfigurasjon), som lar deg sile ut det unødvendige i samsvar med den gitte måleplanen og de tiltenkte (forretnings-) målene. Hva betyr dette i praksis? Vel, for eksempel kan du angi et filter i Analytics-innstillingene for å filtrere ut data fra dine ansatte som besøker et nettsted eller en mobilapplikasjon. De vil ikke bli viderebehandlet og vil ikke påvirke resultatene som presenteres i rapportene. Dessuten vil disse dataene egentlig ikke bli samlet inn, og selv etter at du har kansellert filteret, vil du ikke kunne se det.
I tillegg til å samle inn data ved hjelp av telleren, er det mulig å importere denne informasjonen fra andre tjenester til "det gode selskapet". Du kan for eksempel koble Google Analytics-kontoen din til en konto i , eller i . I prinsippet kan du importere data til Analytics selv fra kilder som ikke tilhører Google (for eksempel samlet inn av deg selv).
Det som er bemerkelsesverdig er at det er på behandlingsstadiet at systemet kombinerer alle disse dataene fra forskjellige kilder (inkludert de som er samlet inn av tellerne), og de vil bidra til de resulterende rapportene. Google Analytics-rapporteringssystemet inkluderer ganske mange praktiske verktøy for visuell presentasjon av data. Men om ønskelig kan rapporter også nås via API hvis du for eksempel ønsker å lage egne rapporteringssystemer utenfor GA-grensesnittet.
La oss ta en generell titt på hvordan Analytics samler inn nødvendige data om nettstedet ditt. Selve samlingsmodellen tar hensyn til tre ting – brukere, økter (sesjoner) og interaksjoner.
Dette diagrammet har en hierarkisk struktur, som går ned fra brukeren til interaksjonen. Brukere skiller mellom de som besøker nettstedet ditt bare én gang og de som besøker det flere ganger om dagen. I Google Analytics-systemet regnes hvert besøk som en økt (økt), som innebærer muligheten til å gjenkjenne samme bruker (returnerende) i flere økter.
En økt fullført på nettstedet ditt består i sin tur av individuelle interaksjoner. For eksempel kan en bruker gå hjem og forlate umiddelbart, noe som resulterer i at bare én interaksjon blir registrert av Google: surfing. hjemmeside. Under en annen økt kunne brukeren også se videoen og foreta et kjøp. Dette vil resultere i tre interaksjoner.
Disse individuelle interaksjonene innenfor en enkelt økt (økt) kalles treff, som igjen er delt inn i grupper som refererer til enten sidevisning, transaksjon eller hendelsestreff. La meg understreke igjen hierarkisk datainnsamlingsskjema tatt i bruk i Google Analytics— hver interaksjon som spores av systemet tilhører en økt, og hver økt er knyttet til en tilsvarende bruker.
Som du allerede forstår, samler sporingskoden du installerte på nettstedet ditt, mobilapplikasjonen eller andre digitale miljøer direkte data (informasjon om brukerhandlinger). Den sender den innsamlede informasjonen til Analytics-kontoen din med det formål å behandle og generere rapporter.
Kobling av sporingskoden som er samlet inn til kontoen din, gjøres ved å bruke en unik identifikator innebygd i koden. For eksempel i eksempelet Google Analytics-kode for et nettsted eller en applikasjon.
Registrering med Google Analytics og kjøring av sporingskodenFaktisk er den nå ute av betatesting ny måte sporing, som ble kalt Universal Analytics (vi snakker om det litt senere) og koden som allerede tilbys å bli installert ved registrering på det offisielle nettstedet Google.com/analytics/ :
Vær oppmerksom på at du står fritt til å velge, ved hjelp av knappene øverst, hvor akkurat du ønsker å samle statistikk – på nettsiden eller i mobilapplikasjonen. Etter å ha fylt ut alle feltene i registreringsskjemaet i Analytics, vil du bli bedt om å godta vilkårene og kopiere sporingskoden med en unik identifikator til nettstedet ditt, om enn fra Universal Analytics:
La oss først se på aspektene ved GAs arbeid, og først da snakker vi om hvordan den nye UA (Universal Analytics) skiller seg fra den og hva som fikk Google til å utvikle den og gradvis gå over fra klassisk GA. De. La oss nå fortsette samtalen om Google Analytics. Så...
Sporingskoden samler inn informasjon om hvordan brukere samhandler med et nettsted eller en nettapplikasjon. Denne informasjonen samles inn i pakker og sendes til Googles servere (for eksempel i form av en liste over parametere i URL-en). Sporingskoden kan også gjenkjenne nye og returnerende brukere. Alle innsamlede data er knyttet til Google Analytics-kontoen din ved hjelp av en unik identifikator innebygd i sporingskoden. Vi snakket nettopp om dette.
Installere Google Analytics sporingskode på nettstedet dittFor å spore og samle inn data på nettsider, brukes en del av JavaScript-kode, som ble vist i forrige skjermbilde. Den inneholder en lenke til analytics.js-biblioteket, som kontrollerer typen data som samles inn på nettstedet. Naturligvis, for å samle inn all statistikk, må denne koden være til stede på hver side på nettstedet ditt.
(function(i,s,o,g,r,a,m)(i["GoogleAnalyticsObject"]=r;i[r]=i[r]||function())((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("opprett", "UA-51939022-1", "slaviali.ru"); ga("send", "sidevisning");
For å gjøre dette, legges det vanligvis til malfilen til nettstedet ditt (hvis det for eksempel fungerer). Så, for eksempel, kan du finne en fil i temaet ditt der "hodet" til dokumentet (nettsiden) er dannet, bestående av de lukkende og åpne Head-taggene. Rett før den avsluttende taggen kan du sette inn Universal Analytics-sporingskoden.
Hvordan JavaScript-sporingskode fungerer på et nettstedHvis sporingskoden er plassert på alle sidene på nettstedet, vil hvert anrop (åpnet av en bruker) danne et treff (et interaksjonselement). Hvis denne regelen brytes, vil du ikke få et fullstendig bilde av alle interaksjoner (utført innenfor en bestemt økt). I tillegg legger du til en sporingskode til det meste øverste del sidens kildekode sikrer at nettleseren, når den analyserer denne koden (starter fra toppen og går ned), aktiverer kjøringen av Analytics-skriptet.
Så selv om en bruker forlater før siden er ferdig lastet, vil deres interaksjon med nettstedet ditt telles. Analytics-koden kjører asynkront, dvs. kjører på bakgrunn mens nettleseren utfører andre oppgaver med å laste inn nettsideelementer. Dette lar deg igjen begynne å samle inn data før fullastet sider.
Etter at sporingskoden på en gitt side er utført, oppretter systemet anonyme unike identifikatorer beregnet på. Det er flere måter å lage slike identifikatorer på. Som standard bruker Google Analytics sin egen (les og hva de spiser), men du har muligheten til å lage og bruke din egen identifikator.
Under lasting JavaScript-sider Tellerkoden samler informasjon om selve nettstedet, for eksempel URL-en til gjeldende side. Telleren samler også inn informasjon om nettleseren som denne siden åpnes i, for eksempel navn eller språkinnstillinger. Og til og med om operativsystemet som denne nettleseren kjører under. All denne informasjonen pakkes og sendes til Gula-serveren som et sidevisningstreff. Og denne prosessen gjentas hver gang siden lastes inn i nettleseren.
Det som er bemerkelsesverdig er at alt dette vil fungere bra uten noen foreløpige innstillinger. Registrert med Google Analytics, mottatt koden og alt vil fungere utmerket, og du vil se de innsamlede dataene i form av sluttrapporter. Imidlertid er det også ekstra mulighet kodeinnstillinger som lar deg samle inn mer informasjon om brukere, deres økt(er) og interaksjoner med nettstedet ditt.
Hvordan Analytics SDK fungerer i mobilapplikasjonerMed Analytics kan du også samle... Imidlertid er prosessen noe forskjellig fra hvordan den gjøres når det gjelder et nettsted. Det er ikke JavaScript-kode som brukes, men den såkalte SDK (development kit), som vil være forskjellig for ulike operativsystemer(Android, iOS). Samtidig samles det inn data om akkurat hva brukeren ser i applikasjonen, hvor ofte han åpner den osv.
Disse dataene pakkes igjen inn i treff og sendes til Google Analytics-kontoen din, men ikke umiddelbart, men etter akkumulering på mobilenheten. Hvorfor gjøres dette?
Derfor samles innsamlede treff (pakker med innhentede data) på enheten og sendes av SDK-tjenesten til Google-servere hver halve time når du bruker Android OS og mye oftere for iOS (hvert annet minutt). Det som er bemerkelsesverdig er at du står fritt til å endre dette intervallet etter eget skjønn for å kontrollere batterilevetiden til mobiltelefonen til brukere av applikasjonen din.
SDK, så vel som Javascript-koden til telleren, kan skille (skille) brukere (mer presist, de mobile enhetene som applikasjonen kjører på). Når applikasjonen starter, en anonym unik identifikator, som deretter spores. De. den mobile enheten og dens bruker identifiseres (den første er merket, siden den andre er vanskeligere å merke).
Når du oppdaterer applikasjonen til en ny versjon, endres ikke enhets-IDen. Men når du installerer på nytt (avinstallerer og deretter installerer programmet), vil den gamle identifikatoren bli slettet og erstattet med en ny. En slik bruker vil ikke bli regnet som en returnerende bruker, men som en ny. SDK-en kan også endres for å samle inn tilleggsinformasjon om brukerne dine, deres økter og interaksjoner med applikasjonen.
Det som er bemerkelsesverdig er at Google Analytics kan samle inn data ikke bare fra nettsteder eller mobilapplikasjoner. Den støtter også andre enheter, som det ser ut til å være helt umulig å koble til dette systemet (terminaler for å akseptere betalinger, Minibank og så videre.). Ah, nei. Det er en spesiell protokoll med et navn som ikke kan uttales (Measurement Protocol), som lar deg sende data fra hvilken som helst enhet som er koblet til Internett.
Når du jobbet med nettsider og mobilapplikasjoner, skapte selve tellerkoden treff (pakker med innsamlet informasjon) og sendte dem til Google-kontoen din. Her må du lage de samme treffene selv. Hvordan dette gjøres er nøyaktig beskrevet i den nevnte uuttalelige protokollen og siden for utviklere.
Behandler data samlet inn av tellere i Google AnalyticsSå vi har snakket om datainnsamling i generelle termer; det er på tide å gå videre til blokkene som er ansvarlige for å behandle og sette dem opp. Samspillet mellom disse to blokkene lar deg strukturere og transformere de innsamlede dataene til informasjonen som kan sees i Analytics-rapporter. Hvordan virker det?
Systemet deler inn de innsamlede dataene etter brukere og økter (sesjoner), og ved å endre innstillingene kan du påvirke denne prosessen. I tillegg blir data samlet inn fra andre kilder (som ikke bruker Google Analytics-sporingskoden) blandet inn i den totale massen.
Dette kan være data fra Adwords, Adsense, Google Webmaster (ved å koble sammen kontoene til disse systemene) og andre kilder som ikke tilhører det "gode selskapet" (ved å laste ned en forberedt fil manuelt eller ved å bruke et spesialskrevet program som bruker mulighetene til Analytics API). Du kan også bruke verktøyet "importer forbruksdata", som brukes til å legge til informasjon om midlene brukt på tredjepartsannonsering (ikke Google), slik at du deretter kan evaluere effektiviteten til annonsekampanjedataene.
Alle disse sammendragsdataene vil gå gjennom filtrene du angir i innstillingene. Disse innstillingene forteller systemet hvilke data som skal inkluderes og hva som skal ekskluderes fra fremtidige rapporter. De kan også påvirke hvordan de innsamlede dataene formateres. Vel, til slutt blir all innsamlet informasjon strukturert og samlet inn i databasetabeller (DB). Generer evt kreves av brukeren En analyserapport basert på disse databasene vil ikke være vanskelig.
Hvordan Analytics skiller mellom brukere og økter (økter)På sidesiden pakkes data om brukere, økter (økter) og interaksjoner inn i treff, og de behandles i selve Analytics-systemet. Hvordan oppretter Google Analytics brukere? Når nettstedet eller mobilapplikasjonen din først lastes inn på en enhet (mobil eller stasjonær datamaskin), sammen med det første treffet (pakke med innsamlede data), opprettes en unik identifikator som tilsvarer denne enheten, og i fremtiden vil den bli knyttet til hvert treff sendt til systemserverne.
Når Analytics analyserer de innsamlede dataene, anser Analytics hver slik bruker som en unik bruker (selv om det i virkeligheten er en «dum» maskinvare, ikke en person). Hver ny identifikator som oppdages under analysen av innholdet i treff vil bli betraktet som en ny bruker. Hvis identifikatoren i neste treff viser seg å være påtruffet tidligere, vil en slik bruker (en "dum" maskinvare) anses som returnert.
Hvis brukeren (for eksempel ved å sette nettleserinnstillingene for å slette dem når programmet lukkes), så blir slike identifikatorer ødelagt. Det samme skjer ved sletting og reinstallering mobil applikasjon. Som et resultat vil en slik bruker bli ansett som ny, og ikke returnere, slik han egentlig er.
Hvis en person besøker nettstedet ditt fra en telefon, nettbrett, bærbar PC, etc. stasjonær datamaskin, vil Google Analytics telle dem som fire forskjellige brukere som standard, fordi sporingskoden vil tilordne forskjellige IDer til alle disse enhetene. Riktignok kan du endre måten identifikatoren opprettes og tilordnes i systeminnstillingene. I hovedsak vil dette tillate deg å kombinere brukerinteraksjon på tvers av flere enheter, dvs. få mer pålitelige data som utdata.
Hvordan oppretter systemet økter? I Analytics er en økt et sett med interaksjoner fra en bestemt bruker (bestående av individuelle typer treff) under spesifisert periode tid. Disse interaksjonene kan være sidevisninger, hendelser eller transaksjoner (kjøp) i en nettbutikk. Den samme brukeren kan gjøre flere økter, som kan skje innen samme dag eller med intervaller på flere dager, uker eller til og med måneder.
Etter slutten av en økt (økt), kan en annen startes. Men hva med systemet? Det viser seg at økten som standard anses som fullført etter en halvtimes brukerinaktivitet. Denne perioden kalles en session timeout og kjennetegnes ved at systemet i løpet av denne tidsperioden ikke mottar treff (pakker med data om handlinger på siden) fra en gitt bruker.
I dette tilfellet vil en ny økt starte etter at systemet mottar et nytt treff om handlingene til denne brukeren. Tidsavbruddet på en halv time er tatt som et gjennomsnittstall som passer for de fleste nettsteder. Men i sykan du stille inn tidsavbruddet som etter din mening vil være optimalt. Det viktigste er at dette lar deg spore statistikk mer nøyaktig og forstå prosessene som skjer på nettstedet ditt. For eksempel, hvis du har mange videoer som er lengre enn 30 minutter, er det fornuftig å øke tidsavbruddet for automatisk avslutning av økten.
Analytics-konfigurasjonsinnstillingerKonseptet med brukere og økter ligger til grunn for arbeidet til Google Analytics-tjenesten, og å forstå hvordan disse dataene trekkes ut fra råmatriser er viktig for å få maksimal informasjon fra de genererte rapportene. Det er også viktig å forstå hvordan systemet bruker konfigurasjonsinnstillinger (laget av deg) på de innsamlede dataene og hvordan det forbereder dem for rapportering.
Konfigurasjonsinnstillinger kan påvirke de resulterende rapportene som følger:
Det er et stort antall konfigurasjonsalternativer i Google Analytics. Kanskje til og med for mye, fordi det er veldig skremmende for en nybegynner. Men hvis vi blant dem skiller ut de viktigste verktøygruppene, får vi ikke mye:
Alle konfigurasjonsalternativer beskrevet ovenfor Google-innstillinger Analytics brukes på data før de aggregeres ( siste steg databehandlingsstadiet). Men under selve aggregeringsprosessen oppretter og distribuerer systemet rapportparametere på tvers av tabeller (indikatorer beregnes på nytt for hver parameter). Når du åpner en rapport i kontoen din, sender den først en spørring til aggregerte tabeller fylt med data. Som svar returneres spesifikke parametere og indikatorer til rapporten. Når du bruker API, sendes forespørsler om data fra aggregerte tabeller av applikasjonen du opprettet.
Alle data som samles inn av sporingskoden som har blitt behandlet vil være tilgjengelig for deg i form av rapporter i Analytics nettgrensesnitt, eller i ditt eget grensesnitt, som mottar data via API. Oftest brukes systemets webgrensesnitt for å få tilgang til rapporter. Det kan tenkes på som et lag på toppen av dataene dine som lar deg strukturere, segmentere og filtrere dem ved hjelp av et sett med analytiske verktøy. Ved å bruke API-en kan du legge til programmessig tilpassede applikasjoner analytiske data (for eksempel i administrasjonspanelet til CMS).
Alle rapporter er basert på kombinasjoner av parametere og indikatorer:
Ved å kombinere ulike parametere og indikatorer, kan Google Analytics-systemet generere nesten alle rapporter som er nødvendige for å evaluere markedsføringshandlinger og brukeratferd på et nettsted (eller mobilapplikasjon).
"Parameter" er ment å beskrive egenskapene til dataene. Trafikkkilden som den besøkende kom til nettstedet ditt fra kan for eksempel være:
Et eksempel på en bruker med nettstedet ditt kan være navnet på siden han ser på:
"Indikatorer" er kvantitativ måling data som kan brukes til å telle hyppigheten av hendelser som oppstår, for eksempel det totale antallet brukere på et nettsted eller en mobilapplikasjon.
Gjennomsnittsverdier kan også brukes som indikatorer, for eksempel gjennomsnittlig antall sider som er sett av en bruker på et nettsted i løpet av en økt (den samme beryktede indikatoren for visningsdybde, som antas å påvirke atferdsvurderingen av nettstedet ved å søkemotorer).
Oftest vises parametere og indikatorer i Google Analytics-rapporter i form av tabeller, hvor den første kolonnen inneholder verdien av en bestemt parameter, og de resterende kolonnene inneholder de tilsvarende indikatorene. Men når du oppretter rapporter, har hver av dem sitt eget omfang (som tilsvarer et visst nivå av hierarkiet av analytiske data relatert til enten brukere, økter eller treffinteraksjoner).
I de fleste tilfeller er det fornuftig å kombinere i rapporter bare de dimensjonene og målene som tilhører samme handlingsområde. For eksempel er «antall besøk» en øktberegning, så den kan bare brukes med parametere på øktnivå (som «trafikkkilde» eller «geografisk plassering»).
Det ville ikke være logisk å kombinere "antall besøk" med treffnivåparametere som "sidetittel". Eller, for eksempel, "varighet av besøk"-indikatoren (måler tiden en bruker brukte på sidene på nettstedet ditt) refererer til treffnivået og kan ikke brukes sammen med øktnivåparametere (alle med samme "trafikkkilde" eller "geografisk plassering").
Hvis du fordyper deg i essensen av parametrene og indikatorene, vil dette hjelpe deg med å få mer meningsfulle data som er nødvendige for å analysere ytelsen til nettstedet eller mobilapplikasjonen din.
Universal AnalyticsUniversal Analytics-tjenesten er ny Google standard Analytics. Snart vil alle kontoer bli pålagt å bruke Universal Analytics. For ikke lenge siden forlot den betatestingsstadiet, og nå er det på kontosidene dine i "Administrator"-fanen et tilbud om å bytte til det.
Sporingskoden (hvis du tok hensyn) inkluderer allerede UA-identifikatoren, noe som betyr at en av fordelene med Universal Analytics blir realisert automatisk - muligheten til å samle inn data fra alle elektroniske enheter koblet til Internett (ved å bruke en Java-skriptkode, eller ved å bruke en SDK, eller ved å bruke Measurement Protocol). Vi har allerede snakket om dette litt høyere.
I UA har muligheten nevnt ovenfor til å lage dine egne bruker-IDer som ikke vil være knyttet til enheten blitt tilgjengelig. Husker du at jeg ga et eksempel om pålogginger fra en mobiltelefon, nettbrett, laptop og datamaskin til samme person? I klassisk GA vil disse besøkene bli regnet som fire forskjellige brukere, men takket være Universelle innstillinger I Analytics kan du manuelt angi brukeridentifikasjon for nettstedet ditt, og i vårt eksempel vil vi telle én bruker.
Det er opp til deg å bestemme om du vil bytte til Universal Analytics eller forbli på GA inntil videre.
Lykke til! Vi sees snart på sidene til bloggsiden
Du kan se flere videoer ved å gå til ");">
Du kan være interessert
Ny bok: Google Analytics. Detaljert praktisk veiledning
HotLog - registrering i rangering av nettsteder og mottak av besøkstellerkode Hvorfor trenger du analyser, hvordan og hva er den beste måten å samle inn nettstedstatistikk?
Vi slapp ny bok"Innholdsmarkedsføring på sosiale medier: Hvordan komme inn i hodene til dine følgere og få dem til å bli forelsket i merkevaren din."
Abonnere
Nettanalyse er som å utvinne gull. Jo dypere du graver ned i gruven, jo mer skinnende metall får du og jo sterkere strømmen av gledestårer. Det samme gjelder informasjon om brukere. Jo mer du vet om dem, jo bedre kan du gjøre nettstedet ditt og virksomheten din. Derfor har vi i dag å gjøre med Google Universal Analytics. Dette er en ganske gammel oppdatering til analysesystemet, men ikke alle vet hvor mange kule funksjoner den la til. Vår artikkel vil bidra til å fylle hullene i kunnskap.
Hva det erDette er en analysesystemstandard som erstattet den gamle Google-versjon Analytics. Det ble lansert i beta i 2013, en fullverdig overgang skjedde i 2014. Universal Analytics hjelper til med å overvåke klienter og besøkende på nettstedet overalt: verktøyet tildeler hver bruker en bruker-ID, som tildeles ham for alltid og streifer fra enhet til enhet . Hvis samme person går inn på nettstedet fra en telefon og en datamaskin, vil Google Universal Analytics forstå dette og ta det i betraktning.
Dessuten. Verktøyet sporer enhver aktivitet til publikum: nettstedbesøk, handlinger i mobilapplikasjoner og til og med offline-kjøp. Det hjelper å evaluere brukeratferd som en helhet, i stedet for i løpet av et enkelt besøk. I fasjonable termer kalles dette "atferdssporing på tvers av plattformer." Nå kan du overvåke hvordan de oppfører seg Mennesker, men ikke besøkende. Tidligere var det nødvendig å trekke konklusjoner om effektiviteten til et nettsted basert på alle registrerte besøk. Samtidig kunne den samme personen først finne noe nyttig på telefonen, og deretter studere alt i detalj hjemmefra og konvertere til en kjøper. Men samtidig ble det første besøket på nettstedet regnet som ikke-konverterende og ubrukelig, selv om dette faktisk ikke er tilfelle.
Slik fungerer Google Universal AnalyticsEnklere enn den gamle versjonen av verktøyet. Tidligere brukte Analytics så mange som 5 forskjellige informasjonskapslerå samle inn besøksdata. De fortalte systemet hvor brukeren kom fra, hvilket nøkkelord han skrev inn i søket og annen viktig informasjon. Nå er alt annerledes – Universal Analytics bruker bare en spesiell bruker-ID. Så snart brukeren går til nettstedet, sendes denne identifikatoren til Googles servere, og alt annet beregnes der.
Ikke for alle
Ordningen fungerer kun for registrerte brukere. Som standard er alle besøkende på nettstedet nye. Men så snart en person registrerer seg og skriver inn brukernavn og passord, trekker systemet umiddelbart opp og tildeler ham en bruker-ID. Alt som en innlogget bruker gjør, registreres på hans personlige teller.
La oss se på et eksempel. La oss tenke oss at vi har en nettbokhandel
- En ny bruker kommer inn på nettstedet ved å klikke på en kontekstuell annonse, enheten er en smarttelefon. Den er tildelt ID_1. Mannen lette etter boken han trengte, fant den, men turte ikke bestille den med en gang – han ville gjøre alt fra hjemmedatamaskinen.
- Etter å ha kommet hjem går han igjen til butikkens nettside. Denne gangen er overgangen direkte og nettleseren er allerede en vanlig datamaskin. Den er tildelt ID_2. Brukeren registrerer seg, velger riktig bok og bestiller det. Alt dette er registrert på hans personlige teller.
- En uke senere får helten vår tilgang til nettstedet igjen ved å bruke en lenke fra sosiale nettverk (siste gang han abonnerte på VKontakte-butikken). Til å begynne med blir han tildelt ID_3, men så kommer han inn Personlig område og systemet henter den gamle identifikatoren – ID_2. En person legger inn en bestilling, og alle handlinger på siden blir registrert på den gamle telleren.
Bruker-ID-funksjonen kan aktiveres i delen "Administrator". Vi er interessert i menypunktet "Sporingskode" -> Bruker-ID.
Ok, men hva med de andre funksjonene? La oss finne ut av det nå.
Slik bruker du Google Universal Analytics Spor kunder offlineMeasurement Protocol vil hjelpe her - et spesielt verktøy for å koble sammen data fra ulike kilder. Kundeinformasjon fra CRM kan overføres til analysesystemet i CSV-format. Dette kan være kjønn, alder og andre data om klienter.
Measurment Protocol fungerer med alle enheter som er i stand til å sende en enkel HTTP-forespørsel, til og med en terminal og strekkodeskanner. Denne funksjonen er nyttig hvis kunder ofte betaler for kjøp kontant når de møter en kurer eller ved et hentepunkt. Den største vanskeligheten er å sørge for at betalingen er registrert på bruker-IDen spesifikk person, men det er fullt mulig å gjøre dette ved å bruke selve protokollen. Google selv skriver mer om dette.
Lag dine egne rapporterDenne funksjonen kommer godt med hvis du trenger noe spesielt. Det er her brukerparametere og beregninger kommer til unnsetning. De første hjelper til med å sortere brukere etter ulike egenskaper: by, trafikkkilde. søkeord og så videre. De andre er nødvendig for å spore spesifikke indikatorer med parametrene du trenger, for eksempel samtaler som er lengre enn 5 minutter eller konvertering blant kvinner. Det viktigste er å ordne sendingen av disse dataene fra CRM og tilbake.
Angi tidsavbrudd for øktenSom standard varer en økt i Google Universal Analytics 30 minutter, og kampanjer varer i 6 måneder. Hvis dette er for kort for deg, kan du justere ventetiden etter eget ønske, selv i 10 timer. Dette kan være nyttig hvis brukere må henge på siden i lang tid for å legge inn en bestilling (dette skjer). Du kan også konfigurere parameteren i Administrator-menyen, her:
Ingen husker nettadresser, alle søker bare etter dem etter firmanavn. Hvis du ikke gjør noe med det, vil slike overganger bli regnet som normale søketrafikk, selv om de faktisk allerede har funnet deg og kjenner deg. Universal Analytics vil hjelpe deg med dette. Gå til den samme administratormenyen og velg "Liste over ekskluderte søk" i supermenyen "Sporingskode" (den er i skjermbildet ovenfor).
Returner brukere til nettstedetUniversal Analytics har sitt eget remarketingverktøy. Den hjelper deg med å kjøre AdWords-annonseringskampanjer for målgrupper som allerede har besøkt nettstedet ditt. En bruker lette for eksempel etter et kamera på nettstedet ditt, fant det, så på det, men kjøpte det ikke. Hvis det er mange slike mennesker. du kan løpe reklamekampanje med et dynamisk attributt. I dette tilfellet vil annonsen inkludere det samme ukjøpte kameraet og si "vel, kjøp meg, du lovet." Du kan aktivere remarketing i den samme administratormenyen som alle er lei av:
Vurder sammensetningen av målgruppenDu kan konfigurere analysesystemet slik at det samler inn data om kjønn, alder og interesser til besøkende (akkurat som i Yandex.Metrica, ja). Med deres hjelp kan du segmentere målgruppe og ta den umiddelbart i sirkulasjon - lanser en annonsekampanje i AdWords for segmentet.
Spor veien til målhandlingen på alle plattformerBruker-ID-en som er knyttet til hver bruker er med på å avgjøre hvilke enheter personen brukte før et kjøp – jeg har allerede gitt eksempler på slike situasjoner. Ved hjelp av analyseverktøy kan du se hvor mange som ser på nettstedet fra en telefon og kjøper varer fra en datamaskin, eller omvendt. Dette vil hjelpe deg med å vurdere rollen til mobiltrafikk i ditt tilfelle. Hvis gadgetbrukere kjøper mye av deg, bør du tenke på å forbedre mobiloptimalisering og alt det der.
Google Universal Analytics er et veldig kraftig verktøy. Sammenlignet med den gamle versjonen av tjenesten er mye lagt til. Du kan legge til integrasjon med offline salg, sette opp remarketing, generere dine egne rapporter med nødvendige parametere og gjør en haug med andre nyttige ting. Ja, det er ikke alltid lett å finne ut hvordan et system eller en separat funksjon fungerer. Men hvis du kjemper deg gjennom alle feltene, kolonnene og grafene, vil resultatet være et stort utvalg av nyttig informasjon.
- Oversettelse
Alle virksomheter vil før eller siden gå på nett, og webanalytikere vil bli virksomhetsanalytikere. Nettelementer brukes allerede i forretningsanalyse.
En digital analytiker er en ganske snever spesialitet – det er bare en forretningsanalytiker som hovedsakelig jobber i den digitale verden og litt i den virkelige verden.
Snart blir det ingen splittelser. Ingen digital, ingen nett, ingen offline - bare alt sammen.
Relativt nylig lanserte Google Universal Analytics. Den har innebygget interessante muligheter for forretningsanalyse. Dessverre er det de færreste som vet hvilke muligheter vi snakker om.
Bruker-IDen bestemmes av analytikeren og sendes til GA gjennom en parameter i koden. User-ID inneholder ikke personopplysninger. For å kode brukeren kan du bruke en 64-bits hash.
Du kan se brukere med og uten bruker-ID. Over tid vil det blå feltet øke og tillate bedre studier av atferd. Men selv med så mange brukere kan User-ID allerede svare på et par spørsmål. For eksempel hvor mange som bruker desktop og mobilversjon. Eller finne ut om kjøpere faktisk søker på mobil og kjøper fra fasttelefon?
Selv om siden ikke er kommersiell, er det likevel viktig å få brukeren til å registrere seg på siden. Med User-ID er det lettere å analysere dette og komme frem til en passende løsning. Dette er en viktig markedsføringsoppgave. Menneskets psykologi må tas i betraktning.
L'Oreal Paris gjør dette veldig bra. De har mye interessant innhold, som får brukeren til å gå tilbake til siden igjen og igjen. Hver artikkel og produkt er utstyrt med en "Lagre"-knapp, som fungerer selv for ikke-påloggede brukere. Men hvis brukeren ikke vil miste bokmerkene sine, må han opprette en konto. Ved siden av hvert produkt er det en «Velg»-knapp, som lar deg velge artikler og produkter som er interessante for kjøperen, og dette fører også til innlogging.
Ikke vær den typen selskap som ber til gudene for å få viktig informasjon. Det er bedre å skape nye muligheter og grunner for kjøpere til å identifisere seg på nettstedet.
Du kan også motta rapporter om hvor mange som har tilgang til nettstedet fra forskjellige enheter.
Bare et par musebevegelser og her er de svarene på alle spørsmålene dine.
Dette er den enkleste representasjonen. Du kan spore inntekter og transaksjoner. Ved hjelp av UA kan du se hvor en person startet reisen og hvordan han samhandlet med nettstedet fra en eller flere enheter.
Importer Alle data som samles inn offline kan importeres til Google Analytics. Data fra CRM vil for eksempel utvide din forståelse av klienten betydelig.Det eneste GA kan fortelle oss om brukeren fra det første eksemplet er en unik ID.
Ved å øke størrelsen på databasen kan du legge til en annen nyttig informasjon om klienten.
Jo mer informasjon som legges til, jo mer kan den suppleres (men uten bruk av personopplysninger).
For å gjøre dette må du logge på kontoen din og klikke på "Importer data" i egenskapene. Data kan også importeres ved hjelp av Google Analytics Management API:
Rapportene du ser der vil avhenge av dataene som sendes til GA. Informasjonen kan for eksempel se slik ut:
Slik kan du analysere primære beregninger basert på sekundære beregninger. For eksempel etter utdanningsnivå.
Et annet eksempel: bruk reiseselskap. Delt inn i typer reisende:
Her kan du se en detaljert manual om import av data.
Protokoll for måling og dataoverføring Når noen handlinger skjer offline, er det mulig å overføre dem til GA gjennom en spesiell protokoll. Disse dataene kan knyttes til vanlig brukeraktivitet.Slik ser rapporten ut:
Den første og andre kolonnen er også tilgjengelig i vanlig GA. Men integrasjon med CRM-databasen åpner for flere muligheter: offline avslag, offline avtaler, etc. All denne informasjonen hjelper deg med å lære mer om potensielle kunder.
Enkelt kodeeksempel:
POST /collect HTTP/1.1 Host: www.google-analytics.com v=1 // Versjon av GA-protokollen. Konstant. &tid=UA-XXXX-Y // Eiendoms-ID &cid=555 // GA-klient-ID. Hentet fra sporingskoden. &ni=1 // Ikke-interaksjonstreff. &t=hendelse // Hendelsestrefftype. Obligatorisk. &ec=ClientOfflineConv //Hendelseskategori. &ea=OnlineLead // Hendelseshandling kreves. &el=OpportunityRegistered // Event Label. &ev=300//Hendelsesverdi (300)
- ec (kategori): Vil gruppere alle offline data.
- ea (handling): Handlingen som er tatt.
- el (etikett): Navn på hendelse. Vil endres sammen med endringen i brukerens status i databasen.
- ev (verdi): Må angis hvis verdien er knyttet til offline-data.
Funksjon 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"]); return $result; ) return false; ) funksjon socketPost($url, $post_string, $ua = null) ( $parts = parse_url($url); $port = isset($parts["port]) ? $parts["port"] : 80; $success = $fp = fsockopen($parts["host"], $port, $errno , $errstr, 30); if ($fp) ( $output = "POST" . $parts["path"] . " HTTP/1.1\r\n"; if (is_string($ua)) ( output .= "User-Agent: " . $ua . "\r\n"; ) $output .= "Vert: " . $parts["host"] . "\r\n"; $output .= "Innholdstype : application/x-www-form-urlencoded\r\n"; $output .= "Innhold-Length: " . strlen($post_string) . "\r\n"; $output .= "Tilkobling^ Lukk\r \n\r\n"; $output .= isset($post_string) ? $post_string: ""; $success = fwrite($fp, $output); fclose($fp); ) returner $success ? true: false ;)
Bonuser Det er et par andre ting som Universal Analytics kan gjøre enklere. For eksempel,