Egendefinerte dimensjoner og beregninger fungerer på samme måte som standarddimensjonene og -beregningene i Analytics-kontoen din. Forskjellen er bare at du oppretter førstnevnte selv. Du kan bruke dem for å samle inn og analysere data som ikke spores automatisk i Analytics.
Du finner følgende informasjon i denne artikkelen:Oversikt
Med egendefinerte dimensjoner og beregninger kan du kombinere Analytics-data med data som ikke er tilknyttet Analytics, for eksempel CRM-data. Eksempel:
- Hvis du lagrer kjønnet til påloggede brukere i et CRM-system, kan du kombinere denne informasjonen med Analytics-data for å se sidevisninger etter kjønn.
- For spillutviklere kan beregninger som «oppnådde nivåer» eller «beste poengsum» være mer relevante enn forhåndsdefinerte beregninger som skjermvisninger. Hvis du sporer disse dataene via egendefinerte beregninger, kan du spore utviklingen i de viktigste beregningene, som vises i egendefinerte rapporter som er fleksible og oversiktlige.
Egendefinerte dimensjoner kan bli vist som primære dimensjoner i egendefinerte rapporter. Du kan også bruke dem som segmenter og sekundære dimensjoner i standardrapporter.
Forutsetninger
Egendefinerte dimensjoner og beregninger er bare tilgjengelig i områder der Universal Analytics er aktivert, eller som inneholder minst én rapporteringsvisning for apper. Det finnes støtte for egendefinerte dimensjoner og beregninger i Google Analytics SDK-ene for Android og versjon 2.x eller nyere av iOS, analytics.js samt Measurement Protocol.
For at du skal kunne bruke egendefinerte dimensjoner og beregninger, kreves det tilleggskonfigurasjon i Analytics-kontoen og sporingskoden din. Når du har gjennomført begge trinnene i konfigurasjonen, kan du bruke slike dimensjoner og beregninger i rapportene dine.
Grenser og forbehold
I hvert område finnes det 20 indekser du kan bruke med henholdsvis de ulike egendefinerte dimensjonene og de ulike egendefinerte beregningene. I 360-kontoer finnes det 200 indekser du kan bruke med henholdsvis de ulike egendefinerte dimensjonene og de ulike egendefinerte beregningene.
Du kan ikke slette egendefinerte dimensjoner, men du kan slå dem av. Vi anbefaler at du unngår å bruke egendefinerte dimensjoner på nytt. Når du endrer navnet på, omfanget til og verdien for en egendefinert dimensjon, kan både de gamle og de nye verdiene tilknyttes enten det gamle eller det nye dimensjonsnavnet. Dette fører til at data flettes sammen i rapportene på en slik måte at du ikke får atskilt dem korrekt med filtre.
Visse egendefinerte dimensjoner kan ikke brukes i kombinasjon med demografisk informasjon i rapporteringen. Du kan komme til å oppleve at visse terskler aktiveres – eller at visse elementer ikke er kompatible med andre elementer – i API-et eller rapporteringen når du ber om egendefinerte dimensjoner med demografiske data.
Livssyklusen til egendefinerte dimensjoner og beregninger
Fire faser inngår i livssyklusen til egendefinerte dimensjoner eller beregninger:
- Konfigurasjon: Du definerer de egendefinerte dimensjonene og beregningene med en indeks, et navn og andre egenskaper, for eksempel omfang.
- Innsamling: Du overfører verdier for de egendefinerte dimensjonene og beregningene til Google Analytics fra implementeringen din.
- Behandling: Dataene dine blir behandlet basert på definisjonene av egendefinerte dimensjonene og beregningene samt eventuelle filtre i rapporteringsvisningen.
- Rapportering: Du utarbeider nye rapporter med utgangspunkt i de egendefinerte dimensjonene og beregningene dine i Analytics-brukergrensesnittet.
Konfigurasjon
Før du kan overføre verdier for egendefinerte dimensjoner og beregninger til Analytics, må du først definere dem i et Analytics-område. I hvert Analytics-område finnes det 20 indekser du kan bruke med henholdsvis de ulike egendefinerte dimensjonene og de ulike egendefinerte beregningene.
Når du definerer en egendefinert dimensjon eller beregning, må du spesifisere navnet på og andre konfigurasjonsverdier for den aktuelle beregningen eller dimensjonen. Analytics tilordner så beregningen eller dimensjonen et indeksnummer, så du kan finne den igjen senere. Egendefinerte dimensjoner har disse konfigurasjonsverdiene:
- Navn: Dette viser til navnet på den egendefinerte dimensjonen, slik det vises i rapportene.
- Omfang: Her oppgis det hvilke data den egendefinerte dimensjonen eller beregningen skal brukes på. Finn ut mer om omfang.
- Aktiv: Her blir det indikert hvorvidt verdien for den egendefinerte dimensjonen eller beregningen skal behandles. Inaktive egendefinerte dimensjoner kan fortsatt vises i rapportene, men de tilhørende verdiene blir ikke behandlet.
Egendefinerte dimensjoner har disse konfigurasjonsverdiene:
- Navn: Dette viser til navnet på den egendefinerte beregningen, slik det vises i rapportene.
- Type: Her blir det avgjort hvordan den egendefinerte beregningen skal vises i rapportene.
- Minimums- og maksimumsverdi: Dette viser til minimums- og maksimumsverdien som skal behandles og vises i rapportene dine.
- Aktiv: Her indikeres det hvorvidt verdien for den egendefinerte beregningen skal behandles. Inaktive egendefinerte beregninger kan fortsatt vises i rapportene, men de tilhørende verdiene blir ikke behandlet.
Du kan definere egendefinerte dimensjoner og beregninger i Analytics-brukergrensesnittet.
Når du har definert en egendefinert dimensjon eller beregning, bør du (om mulig) unngå å endre navnet eller omfanget. Under Hensyn å ta ved implementering finner du mer informasjon om hvordan rapporteringen kan påvirkes av endringer i disse verdiene.
Innsamling
Verdiene for de egendefinerte dimensjonene og beregningene blir sendt til Analytics i form av en indeks- og verdiparameter. Dette skjer på innsamlingstidspunktet. Indeksparameteren tilsvarer indeksnummeret Analytics tilordner den aktuelle egendefinerte dimensjonen eller beregningen i løpet av konfigurasjonsfasen.
I motsetning til andre typer data blir egendefinerte dimensjoner og beregninger sendt til Analytics som parametere knyttet til andre treff, for eksempel hendelser, sidevisninger eller netthandelstransaksjoner. Verdiene for de egendefinerte dimensjonene eller beregningene må derfor angis før det sendes et sporingskall, ellers blir ikke verdiene sendt til Analytics.
Når du skal angi verdien for en egendefinert dimensjon, kan koden bli seende slik ut:
ga('create', 'UA-XXXX-Y', 'auto');
// Angi verdien for den egendefinerte dimensjonen i indeks 1.
ga('set', 'cd1', 'Level 1');
// Send verdien for den egendefinerte dimensjonen med et sidevisningstreff.
ga('send', 'pageview');
Ulike typer egendefinerte beregninger
Egendefinerte beregninger av tids- og heltallstypen må sendes som heltall, mens egendefinerte beregninger av valutatypen kan sendes som faste desimalverdier i samsvar med den lokale valutaen.
Behandling
Når egendefinerte dimensjoner blir behandlet, avgjør omfanget hvilke treff en bestemt egendefinert dimensjon skal brukes på, mens filtrene for rapporteringsvisninger avgjør hvilke treff og tilhørende verdier som til slutt blir tatt med i rapporteringen.
Omfang og prioritet
Omfanget bestemmer hvilke treff som skal knyttes til verdien for en bestemt egendefinert dimensjon. Det finnes fire omfangsnivåer. Disse er produkt, treff, økt og bruker:
- Produkt: Verdien blir brukt for produktet den er tilordnet (bare Utvidet netthandel).
- Treff: Verdien brukes for enkelttreffet den er angitt for.
- Økt: Verdien brukes for alle treffene i én enkelt økt.
- Bruker: Verdien brukes for alle treffene i nåværende og fremtidige økter inntil verdien endres eller den egendefinerte dimensjonen deaktiveres.
Hvis omfanget til en egendefinert dimensjon er på produktnivå, blir verdien kun brukt for produktet der verdien er angitt. Ettersom flere produkter kan sendes i ett treff, kan flere egendefinerte dimensjoner med omfang på produktnivå sendes i ett treff.
Omfang på treffnivåNår en egendefinert dimensjon har omfang på treffnivå, brukes verdien bare for treffet der verdien er angitt. Dette er illustrert i figur A, figur B og figur C nedenfor:
Omfang på øktnivå
Når to verdier med øktomfang er angitt i den samme indeksen i en økt, blir den sist angitte verdien prioritert, og den brukes for alle treffene i denne økten. I figur D nedenfor overskriver den sist angitte verdien alle tidligere verdier for denne indeksen:
Omfang på brukernivå
Hvis to verdier for en egendefinert dimensjon med brukeromfang er angitt i den samme økten, blir den sist angitte verdien prioritert i den gjeldende økten, og den brukes i fremtidige økter for den aktuelle brukeren.
I figur B nedenfor brukes CD-verdien A for alle treffene i økt 2, akkurat som en CD på øktnivå. I figur C brukes CD-verdien A fortsatt for treff i økt 3 på grunn av at CD1 har omfang på brukernivå, ikke omfang på øktnivå:
Filtre
Du kan bruke filtre for rapporteringsvisninger sammen med egendefinerte dimensjoner og beregninger på flere måter.
Hver enkelt verdi for egendefinerte dimensjoner og beregninger er knyttet til treffet den ble mottatt med, uavhengig av omfanget. Hvis dette treffet filtreres med et filter for rapporteringsvisninger, kan den egendefinerte dimensjonen eller beregningen også bli filtrert, avhengig av det aktuelle omfanget:
- Treffomfang: Både egendefinerte dimensjoner med treffomfang og alle egendefinerte beregninger blir filtrert dersom treffet de er tilknyttet, også ble filtrert.
- Økt- eller brukeromfang: Egendefinerte dimensjoner med bruker- eller øktomfang blir ikke filtrert selv om treffet de er tilknyttet, er filtrert. De tilhørende verdiene brukes fortsatt for alle treff i den gjeldende økten samt treffene i fremtidige økter hvis dimensjonen har brukeromfang.
Du kan også bruke egendefinerte dimensjoner til å opprette filtre for rapporteringsvisninger. I så fall filtreres treff i henhold til omfanget til den egendefinerte dimensjonen. Hvis du for eksempel filtrerer på verdien for en egendefinert dimensjon med brukeromfang, filtreres nåværende og fremtidige økter fra gruppen av brukere som er knyttet til denne verdien.
Rapportering
Etter at innsamlingen, konfigurasjonen og de andre behandlingsfasene er gjennomført, får du tilgang til de egendefinerte dimensjonene og beregningene via grensesnittet for brukerrapportering.
Egendefinerte dimensjoner og beregninger er tilgjengelig i egendefinerte rapporter og kan brukes med avanserte segmenter. Egendefinerte dimensjoner kan også brukes som sekundære dimensjoner i standardrapporter.
Eksempler
I eksemplene nedenfor viser hvordan en spillutvikler kan bruke egendefinerte dimensjoner og beregninger for å tilegne seg ny kunnskap om spillernes atferd.
En spillutvikler har nylig gitt ut et nytt spill.
I den nåværende Analytics-implementeringen registreres det en skjermvisning hver gang en bruker spiller et nivå. Utvikleren vet allerede hvor mange ganger hvert nivå er spilt. Nå ønsker hen å få svar på disse mer avanserte spørsmålene:
- Hvor mange ganger er enkle nivåer spilt, sammenlignet med middels eller vanskelige nivåer?
- Hvor mange nivåer er spilt hver dag i løpet av en tre dagers gratis prøveperiode?
- Hvor mange nivåer har brukerne spilt i prøveperioden sammenlignet med antallet nivåer spilt av brukere som har betalt for spillet?
For å få svar på disse spørsmålene brukes egendefinerte dimensjoner for å opprette nye grupperinger av treff, økter og brukere.
I tillegg selger utvikleren noen ekstrafunksjoner som gjør brukeropplevelsen enda bedre, for eksempel tilleggspakker. Utvikleren bruker allerede kategori- og variantfeltene, men ønsker et ekstra felt for å måle styrken på tilleggspakkene som kjøpes. På denne måten kan utvikleren fastslå om tilleggspakker med visse styrker er mer populære enn andre.
Omfang på treffnivå
Vi ser nærmere på et eksempel på hvordan spillutvikleren kan bruke egendefinerte dimensjoner på treffnivå for å finne ut hvor mange nivåer av hver vanskelighetsgrad – enkel, middels eller vanskelig – som er spilt.
Med skjermvisninger sporer utvikleren allerede hvor mange ganger hvert nivå spilles. Nå ønsker utvikleren å finne ut hvilken vanskelighetsgrad som blir spilt mest.
Rapporten blir seende slik ut:
| Vanskelighetsgrad | Skjermvisninger |
|---|---|
| enkelt | |
| middels | |
| vanskelig |
Før egendefinerte dimensjoner ble tatt i bruk, kunne utvikleren se det totale antallet skjermvisninger på hvert nivå. Hen kunne imidlertid ikke gruppere disse skjermvisningene etter vanskelighetsgrad.
Hvis det benyttes en egendefinert dimensjon på treffnivå, kan vanskelighetsgraden knyttes til hver skjermvisning, slik at hvilken vanskelighetsgrad som spilles mest, fremgår av rapportene.
Hvorfor brukes omfang på treffnivå?
Brukere kan spille flere nivåer i løpet av én økt. Bruk av omfang på treffnivå innebærer at en vanskelighetsverdi bare knyttes til skjermvisningen den ble sendt med. Dette gjør at skjermvisninger på ulike nivåer kan forbindes med unike vanskelighetsgrader.
Konfigurasjon
Det første du må gjøre for å implementere en egendefinert dimensjon, er å define dimensjonen i områdeinnstillingene i Administrator-delen i Analytics. I dette eksempelet ser definisjonen av den egendefinerte dimensjonen slik ut:
| Indeks | 1 |
| Navn | Difficulty |
| Omfang | Hit |
| Aktiv | true |
Innsamling
Utvikleren sporer allerede hvert nivå i spillet med en unik skjermvisning. For å knytte vanskelighetsgraden til hvert nivå må verdien for den egendefinerte dimensjonen angis rett før kallet som skal spore skjermvisningen.
Implementeringen kan bli seende slik ut:
ga('create', 'UA-XXXX-Y', 'auto');
// Angi verdien for den egendefinerte dimensjonen i indeks 1.
ga('set', 'cd1', 'easy');
// Send verdien for den egendefinerte dimensjonen med et sidevisningstreff.
ga('send', 'pageview', '/level_1/');
I dette eksempelet er den egendefinerte dimensjonen angitt rett før skjermvisningen på det aktuelle nivået spores. Dermed knyttes vanskelighetsgraden til skjermvisningen, og skjermvisningstreffene kan grupperes etter vanskelighetsgrad i rapportene.
Behandling
Når treffene er samlet inn og sendt til Analytics, blir dataene behandlet, og verdiene for de egendefinerte dimensjonene brukes på treff i henhold til det aktuelle omfanget.
Her er et eksempel på hvordan de innsamlede dataene kan se ut for én spiller som har spilt seks nivåer i løpet av én økt:
userId = 5555 Session 1: H1: screen_name=/level_1/ cd1_value=easy H2: screen_name=/level_2/ cd1_value=medium H3: screen_name=/level_3/ cd1_value=hard H4: screen_name=/level_4/ cd1_value=easy H5: screen_name=/level_5/ cd1_value=medium H6: screen_name=/level_6/ cd1_value=medium
Merk at bruken av omfang på treffnivå sikrer at hver vanskelighetsverdi bare knyttes til skjermvisningen som den ble sendt med.
Rapportering
Ettersom hver skjermvisning er knyttet til en unik vanskelighetsverdi, kan en utvikler – når denne informasjonen er ferdig behandlet – opprette en rapport med både skjermnavn og vanskelighetsgrad som dimensjoner og skjermvisninger som beregning:
| Skjermnavn | Vanskelighetsgrad | Skjermvisninger |
|---|---|---|
| /level_1/ | enkelt | 1 |
| /level_2/ | middels | 1 |
| /level_3/ | vanskelig | 1 |
| /level_4/ | enkelt | 1 |
| /level_5/ | middels | 1 |
| /level_6/ | middels | 1 |
Du kan opprette en egendefinert rapport med vanskelighetsgrad som primærdimensjon for å gruppere skjermvisninger og finne ut hvor mange ganger hvert vanskelighetsnivå er spilt:
| Vanskelighetsgrad | Skjermvisninger |
|---|---|
| enkelt | 2 |
| middels | 3 |
| vanskelig | 1 |
I denne rapporten kan du se at middels vanskelighetsnivå oftest ble spilt. For å skaffe deg denne statistikken må du gruppere skjermvisninger etter egendefinerte dimensjoner på treffnivå.
Omfang på øktnivå
Nå ser vi på et eksempel på hvordan spillutvikleren kan bruke egendefinerte dimensjoner på øktnivå for å se hvor mange nivåer som er spilt per hver dag i løpet av en tre dagers gratis prøveperiode.
Utvikleren vet allerede hvor mange ganger hvert nivå er spilt, ettersom en skjermvisning spores for hvert nivå. Nå ønsker utvikleren å finne ut hvor mange nivåer som er spilt per dag.
Rapporten som utvikleren ønsker å opprette, ser slik ut:
| Prøvedag | Skjermvisninger |
|---|---|
| Dag 1 | |
| Dag 2 | |
| Dag 3 |
Utvikleren bruker en egendefinert dimensjon på øktnivå og kan derfor gruppere skjermvisningene etter de enkelte dagene som inngår i prøveperioden. Dermed kan hen se hvordan dette tallet endres når brukeren bruker mer tid i en kostnadsfri prøveperiode.
Hvorfor brukes omfang på øktnivå?
Du kan bruke omfang på øktnivå for å gruppere hele økter – og alle de tilhørende komponenttreffene – under én prøvedagsverdi på en effektiv måte.
Selv om du kan oppnå den samme funksjonaliteten med omfang på treffnivå, kan du enkelt angi en prøvedagsverdi med minst mulig tilleggskode hvis du holder deg til omfang på øktnivå.
Konfigurasjon
Den egendefinerte dimensjonen «Prøvedag» defineres med disse verdiene i områdeinnstillingene i Google Analytics-brukergrensesnittet:
| Indeks | 2 |
| Navn | Prøvedag |
| Omfang | Session |
| Aktiv | true |
Innsamling
Utvikleren sporer allerede hvert nivå i spillet med en unik skjermvisning. For at du skal kunne knytte en dag til alle skjermvisningene i en økt, må verdien for den egendefinerte dimensjonen bare angis én gang per økt.
Utvikleren angir den egendefinerte dimensjonen når brukeren starter spillet for første gang:
ga('create', 'UA-XXXX-Y', 'auto');
// Angi verdien for den egendefinerte dimensjonen i indeks 2.
var day = getDayOfTrial();
ga('set', 'dimension2', day );
// Send verdien for den egendefinerte dimensjonen med et sidevisningstreff.
ga('send', 'pageview', '/level_1/');
Merk deg at egendefinerte dimensjoner på øktnivå kan angis når som helst i løpet av økten,. I dette eksempelet er det imidlertid hensiktsmessig for utvikleren å fastslå prøvedagen og således angi verdien i begynnelsen av økten.
Behandling
Når treffene er samlet inn og sendt til Analytics, blir dataene behandlet, og verdiene for de egendefinerte dimensjonene brukes på treff i henhold til det aktuelle omfanget.
Her er et eksempel på hvordan de innsamlede dataene ser ut for én spiller som spilte spillet to ganger den første dagen, én gang den andre dagen og én gang den tredje dagen:
userId = 5555 Session 1: H1: screen_name=/level_1/ cd2_value=1 H2: screen_name=/level_2/ H3: screen_name=/level_2/ Session 2: H4: screen_name=/level_3/ cd2_value=1 H5: screen_name=/level_4/ H6: screen_name=/level_4/ Session 3: H1: screen_name=/level_1/ cd2_value=2 H2: screen_name=/level_2/ H3: screen_name=/level_3/ Session 4: H1: screen_name=/level_3/ cd2_value=3
Legg merke til at verdiene for de egendefinerte dimensjonene bare er sendt med én skjermvisning per økt.
Omfang på øktnivå sikrer at prøvedagsverdien knyttes til alle treff i denne økten, ikke bare treffet den ble sendt med.
Rapportering
Etter behandlingen knyttes verdiene for de egendefinerte dimensjonene på øktnivå til alle skjermvisningene som mottas i den samme økten. Utvikleren kan nå opprette en rapport med prøvedag og skjermnavn som dimensjoner og skjermvisninger som beregning:
| Prøvedag | Skjermnavn | Skjermvisninger |
|---|---|---|
| 1 | /level_1/ | 1 |
| 1 | /level_2/ | 2 |
| 1 | /level_3/ | 1 |
| 1 | /level_4/ | 2 |
| 2 | /level_1/ | 1 |
| 2 | /level_2/ | 1 |
| 2 | /level_3/ | 1 |
| 3 | /level_3/ | 1 |
Til slutt kan utvikleren opprette en egendefinert rapport med prøvedag som primærdimensjon for å gruppere skjermvisninger etter dag og finne ut hvor mange nivåer som er spilt på hver dag i prøveperioden:
| Prøvedag | Skjermvisninger |
|---|---|
| 1 | 6 |
| 2 | 3 |
| 3 | 1 |
Dataene viser at flest nivåer ble spilt på den første dagen, med merkbart færre nivåer på den andre og tredje dagen. For å skaffe deg denne statistikken må du bruke egendefinerte dimensjoner på øktnivå til å gruppere flere økter og de tilhørende komponenttreffene etter én enkelt verdi.
Omfang på brukernivå
Til slutt ser vi på et eksempel på hvordan spillutvikleren kan bruke egendefinerte dimensjoner på brukernivå for å finne ut hvor mange nivåer som er spilt av betalende brukere sammenlignet med de som benytter seg av en gratis prøveperiode.
Som i tidligere eksempler spores allerede det totale antall ganger hvert nivå blir spilt, per skjermvisninger. Utvikleren ønsker imidlertid nå å gruppere skjermvisninger etter gratisbrukere og betalende brukere.
Rapporten som utvikleren ønsker å generere, ser slik ut:
| Spillertype | Skjermvisninger |
|---|---|
| Kostnadsfri | |
| Betalende |
Med en egendefinert dimensjon på brukernivå kan utvikleren hente ut disse dataene ved å knytte alle skjermvisningene for en bestemt bruker, i alle nåværende og fremtidige økter, til en verdi for spillertype.
Hvorfor brukes omfang på brukernivå?
Med omfang på brukernivå kan du enkelt gruppere alle komponentøkter og -treff for en bruker etter en enkeltverdi. Dette er ideelt for verdier som ikke endres ofte for en bestemt bruker, for eksempel spillertype i dette eksempelet.
Den samme funksjonaliteten kan oppnås med omfang på treff- eller øktnivå, men omfang på brukernivå gir den mest hensiktsmessige løsningen med minst mulig kode.
Konfigurasjon
Den egendefinerte dimensjonen Spillertype defineres under Administrator med disse verdiene:
| Indeks | 3 |
| Navn | Spillertype |
| Omfang | User |
| Aktiv | true |
Innsamling
Som i tidligere eksempler sporer utvikleren allerede hvert nivå med en skjermvisning. Når disse skjermvisningene skal grupperes etter spillertype, trenger utvikleren bare å angi Spillertype-dimensjonen når brukeren starter spillet, og en ekstra gang hvis en bruker senere betaler for å få tilgang til fullversjonen av spillet.
Utvikleren angir den egendefinerte dimensjonen når brukeren starter spillet for første gang:
ga('create', 'UA-XXXX-Y', 'auto');
// Angi verdien for den egendefinerte dimensjonen i indeks 3.
ga('set', 'dimension3', 'Free' );
// Send verdien for den egendefinerte dimensjonen med et sidevisningstreff.
ga('send', 'pageview', '/level_1/');
Utvikleren kommer også til å angi den egendefinerte dimensjonen når brukeren betaler for fullversjonen av spillet:
ga('create', 'UA-XXXX-Y', 'auto');
// Angi verdien for den egendefinerte dimensjonen i indeks 3.
ga('set', 'dimension3', 'Paid' );
// Send verdien for den egendefinerte dimensjonen med et sidevisningstreff.
ga('send', 'pageview', '/level_1/');
Behandling
Som i tidligere eksempler blir dataene behandlet etter at de er samlet inn, og verdiene for de egendefinerte dimensjonene brukes på treff i henhold til det aktuelle omfanget.
Her er et eksempel på hvordan de innsamlede dataene ser ut for én spiller som spilte spillet to ganger som gratisbruker og én gang som betalende bruker:
userId = 5555 Session 1: H2: screen_name=/level_1/ cd3_value=free H3: screen_name=/level_2/ Session 2: H1: screen_name=/level_2/ H2: screen_name=/level_3/ H3: screen_name=/level_3/ Session 3: H1: screen_name=/level_3/ cd3_value=paid H2: screen_name=/level_4/
Legg merke til at verdien gratis i økt 1 gjelder for alle treffene i denne økten samt i økt 2, inntil den nye verdien betalt angis i økt 3.
Rapportering
Etter behandlingen knyttes verdiene for den egendefinerte dimensjonen «Spillertype» til øktene der de ble angitt, samt eventuelle fremtidige økter og treff.
Utvikleren kan nå opprette en rapport med spillertype og skjermnavn som dimensjoner og skjermvisninger som beregning:
| Spillertype | Skjermnavn | Skjermvisninger |
|---|---|---|
| Kostnadsfri | /level_1/ | 1 |
| Kostnadsfri | /level_2/ | 2 |
| Kostnadsfri | /level_3/ | 2 |
| Betalende | /level_3/ | 1 |
| Betalende | /level_4/ | 1 |
Til slutt kan utvikleren opprette en egendefinert rapport med «Spillertype» som primærdimensjon for å gruppere skjermvisninger etter spillertype og finne ut hvor mange nivåer som er spilt av henholdsvis kostnadsfrie brukere og betalende brukere:
| Spillertype | Skjermvisninger |
|---|---|
| Kostnadsfri | 5 |
| Betalende | 2 |
Ifølge dataene kan du se at kostnadsfrie brukere har spilt flere nivåer enn betalende brukere. For å skaffe deg denne statistikken må du bruke egendefinerte dimensjoner på brukernivå til å gruppere brukere og de tilhørende komponentøktene og -treffene etter én enkelt verdi.
Omfang på produktnivå
Vi ser nærmere på et eksempel på hvordan spillutvikleren kan bruke egendefinerte dimensjoner på produktnivå for å finne ut hvilken styrke de kjøpte tilleggspakkene har – svak, middels eller sterk.
Utvikleren sporer allerede antall kjøpte tilleggspakker via Utvidet netthandel. Nå ønsker utvikleren å finne ut hvilken styrke som blir mest kjøpt i tilleggspakker.
Rapporten blir seende slik ut:
| Styrke for tilleggspakken | Produktinntekter |
|---|---|
| svak | |
| middels | |
| sterk |
Før egendefinerte dimensjoner ble tatt i bruk, kunne utvikleren se de totale produktinntektene fra tilleggspakkene, men ikke gruppere disse inntektene etter styrken på tilleggspakken.
Med en egendefinert dimensjon på produktnivå kan styrken knyttes til hvert produkt, slik at rapportene kan indikere styrken som kjøpes mest (samt visninger, klikk og andre handlinger i Utvidet netthandel).
Hvorfor brukes omfang på produktnivå?
Brukere kan kjøpe flere tilleggspakker i ett og samme kjøp. Bruk av omfang på produktnivå innebærer at en styrkeverdi bare knyttes til produktet den ble sendt med. Dermed kan hver tilleggspakke som kjøpes, knyttes til en unik styrke.
Konfigurasjon
Den egendefinerte dimensjonen «Styrke for tilleggspakken» defineres med disse verdiene i områdeinnstillingene i Administrator-delen i Analytics:
| Indeks | 4 |
| Navn | Styrke for tilleggspakken |
| Omfang | Product |
| Aktiv | true |
Innsamling
Utvikleren sporer allerede hvert kjøp av tilleggspakker i spillet. For at utvikleren skal kunne knytte styrken til de enkelte tilleggspakkene sammen med de aktuelle kjøpene, må verdien for den egendefinerte dimensjonen angis sammen med produktinformasjonen.
Hvis denne dimensjonen legges til i produktet, kan resultatet bli noe slikt:
ga('ec:addProduct', { // Angi produktdetaljer i productFieldObject.
'id': 'P12345', // Produkt-ID (streng).
'name': 'Powerup', // Produktnavn (streng).
'category': 'Extras', // Produktkategori (streng).
'variant': 'red', // Produktvariant (streng).
'price': '10.00', // Produktpris (valuta).
'quantity': 2, // Produktantall (tall).
'dimension4': 'strong' // Egendefinert dimensjon med produktomfang (streng).
});
ga('ec:setAction', 'purchase', {
'id': 'T12345',
'revenue': '20.00'
});
ga('send', 'pageview'); // Send transaksjonsdata med første sidevisning.
I dette eksempelet er den egendefinerte dimensjonen angitt sammen med produktinformasjonen. Dermed knyttes styrken til denne tilleggspakken.
Behandling
Som i tidligere eksempler blir dataene behandlet når treffene er samlet inn og sendt til Analytics, og verdiene for de egendefinerte dimensjonene brukes på produktene de ble angitt med.
Her er et eksempel på hvordan de innsamlede dataene kan se ut for én spiller som har kjøpt tre tilleggspakker i én økt:
userId = 5555
Session 1:
H1: product_name=powerup cd4_value=weak
product_name=powerup cd4_value=strong
H2: product_name=powerup cd4_value=weak
Merk at bruken av omfang på produktnivå sikrer at hver tilleggspakkeverdi bare knyttes til produktet som den ble angitt med.
Rapportering
Ettersom hvert produkt er knyttet til en unik styrkeverdi, kan en utvikler – når denne informasjonen er ferdig behandlet – opprette en egendefinert rapport hvor inntekt inndelt etter «Styrke for tilleggspakken» fremgår:
| Styrke for tilleggspakken | Produktinntekter |
|---|---|
| svak | 200,00 |
| sterk | 100,00 |
I denne rapporten gir svake tilleggspakker mest inntekter.
Egendefinerte beregninger
Omfang
I likhet med egendefinerte dimensjoner kan egendefinerte beregninger ha ulike omfang. Egendefinerte beregninger på treffnivå blir knyttet til alle dimensjonene på treffnivå som de ble sendt med. Tilsvarende blir egendefinerte beregninger på produktnivå bare knyttet til produktene de ble sendt med. Eksemplene nedenfor illustrerer disse to typene egendefinerte beregninger.
Eksempel på en egendefinert beregning med treffomfang
I eksemplene ovenfor har spillutvikleren sporet hvert spill på et nivå som en skjermvisning. I hver av de genererte rapportene brukes skjermvisningsberegningen til å representere en spillers forsøk på å fullføre et nivå.
Utvikleren ønsker imidlertid også å se fullføringsandelen på hvert nivå.
For å fastslå fullføringsandelen bruker utvikleren en ny egendefinert beregning med navnet Nivåfullføringer, og den sammenlignes med skjermvisninger på hvert nivå.
Rapporten som utvikleren ønsker å generere, ser slik ut:
| Skjermnavn | Skjermvisninger | Nivåfullføringer |
|---|---|---|
| /level_1/ | ||
| /level_2/ | ||
| /level_3/ |
Gode grunner til å bruke egendefinerte beregninger
I mange tilfeller kan du bruke hendelser, skjermvisninger og/eller en egendefinert beregning for å spore viktige beregninger. Med egendefinerte beregninger får du imidlertid mer fleksible og mer lesbare egendefinerte rapporter. Det blir dermed enklere å spore viktige beregninger.
I dette eksempelet kan ikke nivåfullføringer spores som skjermvisninger uten at antallet skjermvisninger per nivå telles dobbelt. Du må derfor bruke et annet alternativ.
Du kan bruke en frittstående hendelse, men den hierarkiske oppbygningen gjør at det blir vanskelig å opprette den ovennevnte rapporten med skjermvisninger og nivåfullføringer samlet under én dimensjon.
På grunn av de ovennevnte begrensningene, og fordi nivåfullføringer er en svært viktig beregning for denne utvikleren, er det mest hensiktsmessig å spore nivåfullføringer som en egendefinert beregning.
Konfigurasjon
Den egendefinerte beregningen «Nivåfullføringer» defineres med disse verdiene i Administrasjon-delen i brukergrensesnittet:
| Indeks | 1 |
| Navn | Nivåfullføringer |
| Omfang | Hit |
| Formateringstype | Integer |
| Aktiv | true |
Innsamling
Utvikleren sporer allerede starten på hvert nivå med en skjermvisning. Nå ønsker utvikleren å spore en nivåfullføring med den nye egendefinerte beregningen.
I likhet med egendefinerte dimensjoner blir egendefinerte beregninger sendt til Analytics som parametere knyttet til andre treff. Når verdien for en egendefinert beregning skal sendes, må utvikleren også sende et ekstra treff for å registrere at brukeren fullfører et nivå. I dette eksempelet utløses det en hendelse når nivået er fullført, og en egendefinert beregning knyttes til denne hendelsen.
Denne implementeringen kan se slik ut:
ga('create', 'UA-XXXX-Y', 'auto');
// Øk beregningen for nivåfullføring med 1.
ga('set', 'metric1', 1 );
// Send verdien for den egendefinerte dimensjonen med et hendelsestreff.
ga('send', 'event', 'Level', 'completion');
Behandling
Dataene om én spiller som i løpet av én økt spiller tre nivåer i spillet, blir seende slikt ut før de behandles:
userId = 5555 Session 1 H1: type=screen_view screen_name=/level_1/ H2: type=event screen_name=/level_1/ cm1_value=1 H3: type=screen_view screen_name=/level_2/ H4: type=screen_view screen_name=/level_2/ H5: type=screen_view screen_name=/level_2/ H6: type=event screen_name=/level_2/ cm1_value=1 H7: type=screen_view screen_name=/level_3/ H8: type=event screen_name=/level_3/ cm1_value=1
Rapportering
Etter behandlingen kan utvikleren opprette en rapport med skjermnavn som dimensjon og skjermvisninger, totalt antall hendelser og nivåfullføringer som beregning:
| Skjermnavn | Skjermvisninger | Totalt antall hendelser | Nivåfullføringer |
|---|---|---|---|
| /level_1/ | 1 | 1 | 1 |
| /level_2/ | 3 | 1 | 1 |
| /level_3/ | 1 | 1 | 1 |
Ettersom utvikleren har sporet nivåfullføringer som en egendefinert beregning, fjernes fremtidige behov for å filtrere ut fullføringshendelser fra det totale antallet hendelser.
I stedet kan utvikleren enkelt opprette denne egendefinerte rapporten med den egendefinerte beregningen «Nivåfullføringer»:
| Skjermnavn | Skjermvisninger | Nivåfullføringer |
|---|---|---|
| /level_1/ | 1 | 1 |
| /level_2/ | 3 | 1 |
| /level_3/ | 1 | 1 |
Dataene antyder at nivå 2 faktisk er forholdsmessig vanskeligere enn nivå 1 og 3, ettersom det bare har en fullføringsandel på 33 % basert på skjermvisninger. Hvis utvikleren sporer nivåfullføringer som en egendefinert beregning, er det enkelt å få svar på spørsmål om viktige beregninger og opprette lettfattelige rapporter som kan deles med andre.
Eksempel på en egendefinert beregning med produktomfang
I eksemplene ovenfor sporer spillutvikleren hvert kjøp av en tilleggspakke. Det finnes flere beregninger som kan knyttes til hvert kjøp, for eksempel kvantitet og produktinntekter.
Spillutvikleren har nylig gjennomført en kampanje der alle brukerne fikk en kreditt på NOK 1000. Spillutvikleren ønsker å måle hvilke tilleggspakker folk kjøper med kreditten sin.
Utvikleren bruker en ny egendefinert beregning med navnet «Brukte kreditter» for å finne ut hvilke kreditter som er brukt for hvert produktkjøp.
Rapporten som utvikleren ønsker å generere, ser slik ut:
| Styrke for tilleggspakken | Produktinntekter | Brukte kreditter |
|---|---|---|
| sterk | ||
| middels | ||
| svak |
Konfigurasjon
Den egendefinerte beregningen Brukte kreditter defineres under Administrator med disse verdiene:
| Indeks | 2 |
| Navn | Brukte kreditter |
| Omfang | Product |
| Formateringstype | Integer |
| Aktiv | true |
Innsamling
I likhet med egendefinerte dimensjoner på produktnivå blir egendefinerte beregninger på produktnivå sendt til Analytics som parametere knyttet til produktinformasjonen.
Denne implementeringen kan se slik ut:
ga('ec:addProduct', { // Angi produktdetaljer i productFieldObject.
'id': 'P12345', // Produkt-ID (streng).
'name': 'Powerup', // Produktnavn (streng).
'category': 'Extras', // Produktkategori (streng).
'variant': 'red', // Produktvariant (streng).
'price': '10.00', // Produktpris (valuta).
'quantity': 2, // Produktantall (tall).
'dimension4': 'strong', // Egendefinert dimensjon med produktomfang (streng).
'metric2': 5 // Egendefinert beregning med produktomfang (heltall).
});
ga('ec:setAction', 'purchase', {
'id': 'T12345',
'revenue': '20.00'
});
ga('send', 'pageview'); // Send transaksjonsdata med første sidevisning.
Behandling
Dataene om én spiller som kjøper noen tilleggspakker, kan se slik ut før de behandles:
userId = 5555
Session 1
H1: type=screen_view screen_name=/level_1/
H2: type=screen_view screen_name=/level_2/
product_name=powerup cd4_value=weak cm2_value=5
product_name=powerup cd4_value=strong cm2_value=5
H4: type=screen_view screen_name=/level_2/
product_name=powerup cd4_value=medium cm2_value=1
product_name=powerup cd4_value=weak cm2_value=10
Rapportering
Etter behandlingen kan utvikleren opprette en rapport med «Styrke for tilleggspakken» som dimensjon og «Produktinntekter» og «Brukte kreditter» som beregning:
| Styrke for tilleggspakken | Produktinntekter | Brukte kreditter |
|---|---|---|
| svak | 20 | 15 |
| sterk | 10 | 5 |
| middels | 10 | 1 |
Dataene tyder på at spillerne bruker kredittene på svake tilleggspakker. Utvikleren fikk høyest fortjeneste på middels tilleggspakker.
Hensyn å ta ved implementering
Husk på følgende når du skal implementere egendefinerte dimensjoner eller beregninger:
Endring av eksisterende dimensjoner eller beregninger
Når du endrer navnet på eller omfanget av eksisterende egendefinerte dimensjoner eller beregninger, kan dataene dine påvirkes på disse måtene:
- Endring av navn: Dette har innvirkning på data som allerede er behandlet. Du må bruke det nye navnet om du vil ha tilgang til gamle data.
- Endring av omfang: Dette påvirker ikke data som allerede er behandlet. Bare nye data blir behandlet med det nye omfanget.
- Endring av aktivitetstilstand: Aktiv-feltet avgjør om verdiene for de egendefinerte dimensjonene eller beregningene faktisk blir behandlet. Når
usanner valgt, vises den egendefinerte dimensjonen eller beregningen fortsatt i rapportene, men ettersom de aktuelle verdiene ikke blir behandlet, har den ingen tilknyttede data.
Tenk langsiktig når du angir omfang
Når du skal bestemme hvilket omfang du vil bruke for en bestemt egendefinert dimensjon, bør du vurdere hvor ofte du forventer at verdien blir endret. Hvis du har en verdi som kan bli endret mange ganger i løpet av en økt, for eksempel navnet på et nivå i et spill, bør du bruke treffomfang og angi verdien før hvert treff. På den annen side kan en egendefinert dimensjon som kjønn angis bare én gang på brukernivå. Hvis du skal sende en kjønnsverdi med hvert treff, fører det til unødig mye arbeid. Hvis du konfigurerer en egendefinert dimensjon som endres ofte, med brukeromfang, blir mange treff feilaktig knyttet til denne verdien.