Egendefinerte dimensjoner og beregninger

Inkluder ikke-standarddata i rapporter.

Egendefinerte dimensjoner og beregninger fungerer på samme måte som standarddimensjonene og -beregningene i Analytics-kontoen din, med den forskjellen at du lager dem selv. Du kan bruke dem for å samle inn og analysere data som ikke spores automatisk i Google Analytics.

Denne artikkelen omhandler disse emnene:

Oversikt

Ved hjelp av egendefinerte dimensjoner og beregninger kan du kombinere Google Analytics-data med eksterne data, for eksempel CRM-data. Vi tar et eksempel:

  • Hvis du lagrer kjønnet til påloggede brukere i et CRM-system, kan du kombinere denne informasjonen med Google 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. Ved å spore disse dataene med egendefinerte beregninger kan du spore fremdrift i forhold til viktige beregninger i egendefinerte rapporter som er fleksible og oversiktlige.

Egendefinerte dimensjoner kan bli vist som hoveddimensjoner i egendefinerte rapporter. Du kan også bruke dem som segmenter og sekundære dimensjoner i standardrapporter.

Forutsetninger

Egendefinerte dimensjoner og beregninger er bare tilgjengelige for områder som er slått på for Universal Analytics, eller som inneholder minst én rapporteringsvisning for apper. Egendefinerte dimensjoner og beregninger støttes av Google Analytics-SDK-ene for Android og iOS 2.x eller senere, analytics.js og Measurement Protocol.

Ved bruk av egendefinerte dimensjoner og beregninger må du foreta ytterligere konfigurasjon i Analytics-kontoen og sporingskoden din. Når du har gjennomført begge trinnene i konfigurasjonen, kan du bruke egendefinerte dimensjoner og beregninger i rapportene dine.

Begrensninger og forbehold

20 indekser er tilgjengelige for ulike egendefinerte dimensjoner og 20 indekser for egendefinerte beregninger i hvert område. Premium-kontoer har 200 tilgjengelige indekser for tilpassede dimensjoner og 200 for tilpassede beregninger.

Egendefinerte dimensjoner kan ikke slettes, men de kan slås av. Vi anbefaler at du unngår å prøve å bruke egendefinerte dimensjoner på nytt. Når du redigerer navnet, omfanget og verdien for en egendefinert dimensjon, kan de gamle og de nye verdiene kobles sammen med navnet på den gamle eller den nye dimensjonen. Da flettes data sammen i rapportene dine på en måte som ikke kan nøyaktig skilles med et filter.

Livssyklusen til egendefinerte dimensjoner og beregninger

Livssyklusen til en egendefinert dimensjon eller beregning har fire faser:

  • Konfigurasjon – du oppretter egendefinerte dimensjoner og beregninger med en indeks, et navn og andre egenskaper, for eksempel omfang.
  • Innsamling – du sender verdier for egendefinerte dimensjoner og beregninger til Google Analytics fra implementeringen din.
  • Behandling – dataene dine blir behandlet basert på definisjonene av egendefinerte dimensjoner og beregninger samt eventuelle filtre i rapporteringsvisningen.
  • Rapportering – du lager nye rapporter basert på egendefinerte dimensjoner og beregninger i brukergrensesnittet i Google Analytics.

Konfigurasjon

Før du kan sende verdier for egendefinerte dimensjoner og beregninger til Google Analytics, må de først defineres i et Google Analytics-område. Hvert Google Analytics-område har 20 tilgjengelige indekser for egendefinerte dimensjoner, og ytterligere 20 indekser for egendefinerte beregninger.

Når du oppretter en egendefinert dimensjon eller beregning, angir du et navn og andre konfigurasjonsverdier i en bestemt indeks. Egendefinerte dimensjoner har følgende konfigurasjonsverdier:

  • Navn – navnet på den egendefinerte dimensjonen slik det blir vist i rapporter.
  • Omfang – angir hvilke data den egendefinerte dimensjonen eller beregningen skal brukes på. Finn ut mer om omfang.
  • Aktiv – hvorvidt verdien for den egendefinerte dimensjonen eller beregningen skal behandles. Inaktive egendefinerte dimensjoner kan fortsatt vises i rapporteringen, men de tilhørende verdiene blir ikke behandlet.

Egendefinerte beregninger har følgende konfigurasjonsverdier:

  • Navn – navnet på den egendefinerte beregningen slik det blir vist i rapporter.
  • Type – bestemmer hvordan verdien for den egendefinerte beregningen skal vises i rapporter.
  • Minimums-/maksimumsverdi – minimums- og maksimumsverdiene som skal behandles og vises i rapporter.
  • Aktiv – hvorvidt verdien for den egendefinerte beregningen skal behandles. Inaktive egendefinerte beregninger kan fortsatt vises i rapporteringen, men de tilhørende verdiene blir ikke behandlet.

Egendefinerte dimensjoner og beregninger kan opprettes i brukergrensesnittet i Google Analytics.

Når du har opprettet en egendefinert dimensjon eller beregning, bør du om mulig unngå å redigere navnet eller omfanget. Under Hensyn å ta ved implementering finner du mer informasjon om hvordan endringer av disse verdiene kan påvirke rapporteringen.

Innsamling

Verdier for egendefinerte dimensjoner og beregninger blir sendt til Google Analytics på innsamlingstidspunktet som en kombinasjon av indeks- og verdiparametere. Indeksparameteren tilsvarer indeksen for den egendefinerte dimensjonen eller beregningen som blir opprettet i konfigurasjonsfasen.

I motsetning til andre typer data blir egendefinerte dimensjoner og beregninger sendt til Google Analytics som parametere knyttet til andre treff, for eksempel sidevisninger, hendelser eller netthandelstransaksjoner. Således må verdier for egendefinerte dimensjoner eller beregninger angis før et sporingskall sendes for at denne verdien skal bli sendt til Google Analytics.

Når du skal angi verdien for en egendefinert dimensjon, kan koden eksempelvis se slik ut:

ga('create', 'UA-XXXX-Y', 'auto');

// Angi verdi for egendefinert dimensjon i indeks 1.
ga('set', 'dimension1', 'Level 1');

// Send verdien for den egendefinerte dimensjonen med et sidevisningstreff.
ga('send', 'pageview');

Typer av egendefinerte beregninger

Egendefinerte beregninger med typen Heltall eller Tid må sendes som heltall, mens egendefinerte beregninger med typen Valuta 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 datautvalgsfiltre avgjør hvilke treff og tilhørende verdier som til slutt blir inkludert i rapporteringen.

Omfang og prioritet

Omfanget bestemmer hvilke treff som skal knyttes til verdien for en bestemt egendefinert dimensjon. Det finnes fire omfangsnivåer: produkt, treff, økt og bruker:

  • Produkt – verdien brukes for produktet den er angitt for (bare Utvidet netthandel).
  • Treff – verdien brukes for enkelttreffet den er angitt for.
  • Økt – verdien brukes for alle treff i én økt.
  • Bruker – verdien brukes for alle treff i nåværende og fremtidige økter, inntil verdien endres eller den egendefinerte dimensjonen deaktiveres.
Omfang på produktnivå

Når en egendefinert dimensjon har omfang på produktnivå, brukes verdien bare 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.

Figur A: Brukeren sender to treff (H1, H2). H2 har CD1-verdien A. Denne verdien brukes bare for H2.


Figur B: Brukeren sender et tredje treff (H3). H3 har ingen CD-verdi.


Figur C: Brukeren sender et fjerde treff (H4). H4 har CD1-verdien B. Denne verdien brukes bare for H4.


Omfang på øktnivå

Når to verdier med øktomfang er angitt i samme indeks i en økt, blir den sist angitte verdien prioritert, og brukes for alle treff i denne økten. I figur D nedenfor overskriver den sist angitte verdien alle tidligere verdier for denne indeksen:

Figur A: Brukeren sender et treff (H1) uten CD-verdi.


Figur B: I samme økt sender brukeren et annet treff (H2) med CD1-verdien A. Øktomfanget fører til at verdien A også brukes for H1.


Figur C: Brukeren sender et tredje treff (H3). Selv om ingen CD1-verdi sendes med H3, fører øktomfanget til at verdien A brukes automatisk for H3.


Figur D: Brukeren sender et fjerde treff (H4) med den nye CD1-verdien B. Øktomfanget fører til at verdien B brukes for alle treffene i økten, og verdien A overskrives i de tidligere treffene.


Omfang på brukernivå

Hvis to verdier for en egendefinert dimensjon med brukeromfang er angitt i samme økt, blir den sist angitte verdien prioritert for gjeldende økt, og brukes i fremtidige økter for den aktuelle brukeren.

I figur B nedenfor brukes CD-verdien A for alle treff i økt 2, akkurat som en CD på øktnivå. I figur C, i motsetning til omfang på øktnivå, brukes imidlertid CD-verdien A fortsatt for treff i den tredje økten på grunn av at CD1 har omfang på brukernivå:

Figur A: Brukeren har en økt med tre treff (H1, H2, H3). Ingen CD-verdier er angitt.


Figur B: Den samme brukeren gjennomfører en annen økt, med tre nye treff. CD1-verdien er A i H3. CD1-verdien brukes deretter for alle treff i økten.


Figur C: Brukeren gjennomfører en tredje økt med tre nye treff. CD1-omfanget på brukernivå fører til at verdien A brukes for alle treff i økt 3.

Filtre

Datautvalgsfiltre kan brukes 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 omfang. Hvis dette treffet filtreres med et datautvalgsfilter, kan den egendefinerte dimensjonen eller beregningen også bli filtrert, avhengig av omfanget:

  1. Treffomfang: Både egendefinerte dimensjoner med treffomfang og egendefinerte beregninger blir filtrert hvis treffet de er knyttet til, også er filtrert.
  2. Økt- eller brukeromfang: Egendefinerte dimensjoner med bruker- eller øktomfang blir ikke filtrert selv om treffet de er knyttet til, er filtrert. De tilhørende verdiene brukes fortsatt for alle treff i gjeldende økt, samt fremtidige økter hvis dimensjonen har brukeromfang.

Egendefinerte dimensjoner kan også brukes til å konstruere datautvalgsfiltre. I så fall filtreres treff i henhold til omfanget for 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 med brukere som er knyttet til denne verdien.

Rapportering

Når innsamling, konfigurering og andre behandlingsoperasjoner er fullført, blir egendefinerte dimensjoner og beregninger tilgjengelige via grensesnittet for brukerrapportering.

Egendefinerte dimensjoner og beregninger er tilgjengelige i egendefinerte rapporter, og kan brukes med avanserte segmenter. Egendefinerte dimensjoner kan også brukes som sekundære dimensjoner i standardrapporter.

Eksempler

Eksemplene nedenfor viser hvordan en spillutvikler kan bruke egendefinerte dimensjoner og beregninger for å få kunnskap om spilleratferd.

En spillutvikler har nylig gitt ut et nytt spill.

I den nåværende Google Analytics-implementeringen registreres en skjermvisning hver gang en bruker spiller et nivå. Utvikleren vet allerede hvor mange ganger hvert nivå er spilt. Nå ønsker man å få svar på disse mer avanserte spørsmålene:

  1. Hvor mange ganger er enkle nivåer spilt, sammenlignet med middels eller vanskelige nivåer?
  2. Hvor mange nivåer er spilt hver dag i en 3-dagers gratis prøveversjon?
  3. Hvor mange nivåer er spilt av brukere i prøveversjonen, sammenlignet med 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.

For øvrig selger utvikleren noen ekstrafunksjoner som forbedrer brukeropplevelsen, for eksempel tilleggspakker. Utvikleren bruker allerede kategori- og variantfeltene, men ønsker et ekstra felt for å måle styrken på tilleggspakker 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.

Utvikleren sporer allerede hvor mange ganger hvert nivå spilles, ved hjelp av skjermvisninger. Nå ønsker man å finne ut hvilken vanskelighetsgrad som blir spilt mest.

Rapporten ser slik ut:

VanskelighetsgradSkjermvisninger
enkel 
middels 
vanskelig 

Før egendefinerte dimensjoner ble tatt i bruk, kunne utvikleren se totalt antall skjermvisninger på hvert nivå, men kunne ikke gruppere disse skjermvisningene etter vanskelighetsgrad.

Ved hjelp av en egendefinert dimensjon på treffnivå kan vanskelighetsgraden knyttes til hver skjermvisning, slik at rapportene kan indikere vanskelighetsgraden som spilles mest.

Hvorfor omfang på treffnivå?

En bruker 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 som den ble sendt med. Dermed kan hver nivåskjermvisning knyttes til en unik vanskelighetsgrad.

Konfigurasjon

Det første trinnet i implementeringen av en egendefinert dimensjon er å definere den i områdeinnstillingene under Administrator i Google Analytics. For dette eksempelet ser definisjonen av den egendefinerte dimensjonen slik ut:

Indeks1
NavnVanskelighetsgrad
OmfangTreff
Aktivsann

Innsamling

Utvikleren sporer allerede hvert nivå i spillet med en skjermvisning. For å knytte vanskelighetsgraden til hvert nivå må verdien for den egendefinerte dimensjonen angis rett før kallet for sporing av skjermvisningen.

Implementeringen kan se slik ut:

ga('create', 'UA-XXXX-Y', 'auto');

// Angi verdi for egendefinert dimensjon i indeks 1.
ga('set', 'dimension1', '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 nivåskjermvisningen spores. Dermed knyttes vanskelighetsgraden til skjermvisningen, og skjermvisningstreffene kan grupperes etter vanskelighetsgrad i rapporter.

Behandling

Når treffene er samlet inn og sendt til Google Analytics, blir dataene behandlet, og verdier for egendefinerte dimensjoner brukes på treff i henhold til omfanget.

Her er et eksempel på hvordan de innsamlede dataene kan se ut for én spiller, med én økt, som har spilt seks nivåer:

userId = 5555
Økt 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 den respektive vanskelighetsverdien, kan en utvikler etter behandlingen opprette en rapport med både skjermnavn og vanskelighetsgrad som dimensjoner og skjermvisninger som en beregning:

SkjermnavnVanskelighetsgradSkjermvisninger
/level_1/enkel1
/level_2/middels1
/level_3/vanskelig1
/level_4/enkel1
/level_5/middels1
/level_6/middels1

Det kan opprettes en egendefinert rapport med vanskelighetsgrad som primærdimensjon for å gruppere skjermvisninger og finne ut hvor mange ganger hvert vanskelighetsnivå er spilt:

VanskelighetsgradSkjermvisninger
enkel2
middels3
vanskelig1

I denne rapporten er middels vanskelighetsnivåer mest spilt. Det er mulig å tilegne seg denne kunnskapen ved å bruke egendefinerte dimensjoner på treffnivå til å gruppere skjermvisninger.

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 for hver dag i en 3-dagers gratis prøveperiode.

Utvikleren vet allerede hvor mange ganger hvert nivå er spilt, ettersom en skjermvisning spores for hvert nivå. Nå ønsker man å finne ut hvor mange nivåer som er spilt hver dag.

Rapporten som utvikleren ønsker å opprette, ser slik ut:

PrøvedagSkjermvisninger
Dag 1 
Dag 2 
Dag 3 

Ved å bruke en egendefinert dimensjon på øktnivå kan utvikleren gruppere skjermvisninger etter hver dag i prøveperioden og se hvordan dette tallet endres når en person bruker mer tid i en gratis prøveperiode.

Hvorfor omfang på øktnivå?

Du kan bruke omfang på øktnivå for å gruppere hele økter, og alle tilhørende komponenttreff, på en effektiv måte under én prøvedagsverdi.

Omfang på treffnivå kan brukes for å oppnå den samme funksjonaliteten, men ved bruk av omfang på øktnivå kan du enkelt angi en prøvedagsverdi med minst mulig tilleggskode.

Konfigurasjon

Den egendefinerte dimensjonen Prøvedag defineres i områdeinnstillingene i Google Analytics-brukergrensesnittet med disse verdiene:

Indeks2
NavnPrøvedag
OmfangØkt
Aktivsann

Innsamling

Utvikleren sporer allerede hvert nivå i spillet med en skjermvisning. For å knytte en dag til alle skjermvisningene i en økt trenger du bare å angi verdien for en egendefinert dimensjon én gang per økt.

Utvikleren angir den egendefinerte dimensjonen når brukeren starter spillet:

ga('create', 'UA-XXXX-Y', 'auto');

// Angi verdi for egendefinert dimensjon i indeks 2.
var day = getDayOfTrial();
ga('set', 'dimension2', day );

// Send verdien for den egendefinerte dimensjonen med et sidevisningstreff.
ga('send', 'pageview', '/level_1/');

En egendefinert dimensjon på øktnivå kan angis når som helst i løpet av økten, men i dette eksempelet er det hensiktsmessig for utvikleren å fastslå prøvedagen og således angi verdien på begynnelsen av økten.

Behandling

Når treffene er samlet inn og sendt til Google Analytics, blir dataene behandlet, og verdier for egendefinerte dimensjoner brukes på treff i henhold til 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
Økt 1:
H1: screen_name=/level_1/  cd2_value=1
H2: screen_name=/level_2/
H3: screen_name=/level_2/

Økt 2:
H4: screen_name=/level_3/  cd2_value=1
H5: screen_name=/level_4/
H6: screen_name=/level_4/

Økt 3:
H1: screen_name=/level_1/  cd2_value=2
H2: screen_name=/level_2/
H3: screen_name=/level_3/

Økt 4:
H1: screen_name=/level_3/  cd2_value=3

Legg merke til at verdier for egendefinerte dimensjoner 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 egendefinerte dimensjoner på øktnivå til alle skjermvisninger som mottas i samme økt. Utvikleren kan nå opprette en rapport med prøvedag og skjermnavn som dimensjoner og skjermvisninger som en beregning:

PrøvedagSkjermnavnSkjermvisninger
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øvedagSkjermvisninger
16
23
31

Dataene viser at flest nivåer ble spilt på den første dagen, med merkbart færre nivåer på dag 2 og 3. Det er mulig å tilegne seg denne kunnskapen ved å bruke egendefinerte dimensjoner på øktnivå til å gruppere flere økter og tilhørende komponenttreff etter en enkeltverdi.

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 brukere av en gratis prøveversjon.

Som i tidligere eksempler spores allerede det totale antall ganger hvert nivå blir spilt, ved hjelp av skjermvisninger, men utvikleren ønsker nå å gruppere skjermvisninger etter gratisbrukere og betalende brukere.

Rapporten som utvikleren ønsker å generere, ser slik ut:

SpillertypeSkjermvisninger
Gratis 
Betalende 

Ved hjelp av en egendefinert dimensjon på brukernivå kan utvikleren få disse dataene ved å knytte alle skjermvisninger for en bestemt bruker, i alle nåværende og fremtidige økter, til en spillertypeverdi.

Hvorfor omfang på brukernivå?

Med omfang på brukernivå kan du 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:

Indeks3
NavnSpillertype
OmfangBruker
Aktivsann

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 dimensjonen Spillertype 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:

ga('create', 'UA-XXXX-Y', 'auto');

// Angi verdi for egendefinert dimensjon i indeks 3.
ga('set', 'dimension3', 'Free' );

// Send verdien for den egendefinerte dimensjonen med et sidevisningstreff.
ga('send', 'pageview', '/level_1/');

Utvikleren angir også den egendefinerte dimensjonen når brukeren betaler for fullversjonen av spillet:

ga('create', 'UA-XXXX-Y', 'auto');

// Angi verdi for egendefinert dimensjon 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 når de er samlet inn, og verdier for egendefinerte dimensjoner brukes på treff i henhold til 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
Økt 1:
H2: screen_name=/level_1/ cd3_value=free
H3: screen_name=/level_2/

Økt 2:
H1: screen_name=/level_2/
H2: screen_name=/level_3/
H3: screen_name=/level_3/

Økt 3:
H1: screen_name=/level_3/ cd3_value=paid
H2: screen_name=/level_4/

Legg merke til at verdien free i økt 1 gjelder for alle treff i denne økten samt i økt 2, inntil den nye verdien paid 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 en beregning:

SpillertypeSkjermnavnSkjermvisninger
Gratis/level_1/1
Gratis/level_2/2
Gratis/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 gratisbrukere og betalende brukere:

Spillertype Skjermvisninger
Gratis5
Betalende2

Dataene viser at gratisbrukere har spilt flere nivåer enn betalende brukere. Det er mulig å tilegne seg denne kunnskapen ved å bruke egendefinerte dimensjoner på brukernivå til å gruppere brukere og tilhørende komponentøkter og -treff etter en enkeltverdi.

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 man å finne ut hvilken styrke som blir mest kjøpt i tilleggspakker.

Rapporten ser slik ut:

Styrke for tilleggspakkenProduktinntekter
svak 
middels 
sterk 

Før egendefinerte dimensjoner ble tatt i bruk, kunne utvikleren se de totale produktinntektene fra tilleggspakker, men kunne ikke gruppere disse inntektene etter styrken på tilleggspakken.

Ved hjelp av 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 omfang på produktnivå?

En bruker 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 som den ble sendt med. Dermed kan hver tilleggspakke som kjøpes, knyttes til en unik styrke.

Konfigurasjon

Den egendefinerte dimensjonen Styrke for tilleggspakken defineres i områdeinnstillingene under Administrator i Google Analytics med disse verdiene:

Indeks4
NavnStyrke for tilleggspakken
OmfangProdukt
Aktivsann

Innsamling

Utvikleren sporer allerede hvert kjøp av tilleggspakker i spillet. For å knytte styrken til hver tilleggspakke må verdien for den egendefinerte dimensjonen angis med produktdataene.

Denne dimensjonen kan eksempelvis legges til i produktet på følgende måte:

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 Google Analytics, og verdier for egendefinerte dimensjoner brukes på produktene de ble angitt med.

Her er et eksempel på hvordan de innsamlede dataene kan se ut for én spiller, med én økt, som har kjøpt tre tilleggspakker:

userId = 5555
Økt 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 den respektive styrkeverdien, kan en utvikler etter behandlingen opprette en egendefinert rapport som viser inntekter etter styrken på en tilleggspakke:

Styrke for tilleggspakkenProduktinntekter
svak200,00
sterk100,00

I denne rapporten gir svake tilleggspakker mest inntekter.

Egendefinerte beregninger

Omfang

I likhet med egendefinerte dimensjoner kan egendefinerte beregninger ha ulike omfang. En egendefinert beregning på treffnivå blir knyttet til alle dimensjoner på treffnivå som den ble sendt med. Tilsvarende blir en egendefinert beregning på produktnivå bare knyttet til produktet som den ble sendt med. Eksemplene nedenfor illustrerer disse to typene av egendefinerte beregninger.

Eksempel på 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å å vite fullføringsgraden for hvert nivå.

For å fastslå fullføringsgraden bruker utvikleren en ny egendefinert beregning med navnet Nivåfullføringer, og sammenligner denne med skjermvisninger for hvert nivå.

Rapporten som utvikleren ønsker, ser slik ut:

SkjermnavnSkjermvisningerNivåfullføringer
/level_1/  
/level_2/  
/level_3/  

Hvorfor bruke en egendefinert beregning?

I mange tilfeller har du muligheten til å bruke hendelser, skjermvisninger og/eller en egendefinert beregning for å spore viktige beregninger. Egendefinerte beregninger kan gi mer fleksible og mer lesbare egendefinerte rapporter, og er således en praktisk måte å spore viktige beregninger på.

I dette eksempelet kan ikke nivåfullføringer spores som en skjermvisning uten å telle antall skjermvisninger per nivå dobbelt opp, og du ønsker derfor å finne et annet alternativ.

Du kan bruke en frittstående hendelse, men den hierarkiske oppbygningen ville ha gjort det 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 under Administrasjon i brukergrensesnittet med disse verdiene:

Indeks1
NavnNivåfullføringer
OmfangTreff
FormateringstypeHeltall
Aktivsann

Innsamling

Utvikleren sporer allerede starten på hvert nivå ved hjelp av en skjermvisning. Nå ønsker man å spore en nivåfullføring med den nye egendefinerte beregningen.

I likhet med egendefinerte dimensjoner blir egendefinerte beregninger sendt til Google 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 brukeren som fullfører et nivå. I dette eksempelet utløses 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 for én spiller som spiller tre nivåer i spillet i én økt, ser slik ut før behandlingen:

userId = 5555
Økt 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, antall hendelser og nivåfullføringer som beregning:

SkjermnavnSkjermvisningerAntall hendelserNivåfullføringer
/level_1/111
/level_2/311
/level_3/111

Ettersom utvikleren har sporet nivåfullføringer som en egendefinert beregning, elimineres fremtidige behov for å filtrere ut fullføringshendelser fra alle hendelser.

I stedet kan utvikleren enkelt opprette denne egendefinerte rapporten med den egendefinerte beregningen Nivåfullføringer:

SkjermnavnSkjermvisningerNivåfullføringer
/level_1/11
/level_2/31
/level_3/11

Dataene antyder at nivå 2 faktisk er forholdsmessig vanskeligere enn nivå 1 og 3, ettersom det bare har en fullføringsgrad på 33 % basert på skjermvisninger. Ved å spore nivåfullføringer som en egendefinert beregning kan utvikleren enkelt få svar på spørsmål om viktige beregninger og opprette forenklede rapporter som kan deles med andre.

Eksempel på 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 antall og produktinntekter.

Spillutvikleren har nylig gjennomført en kampanje der alle brukerne fikk en kreditt på 1000 kroner, og ønsker å måle hvilke tilleggspakker folk kjøper med denne kreditten.

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, ser slik ut:

Styrke for tilleggspakkenProduktinntekterBrukte kreditter
sterk  
middels  
svak  

Konfigurasjon

Den egendefinerte beregningen Brukte kreditter defineres under Administrator med disse verdiene:

Indeks2
NavnBrukte kreditter
OmfangProdukt
FormateringstypeValuta
Aktivsann

Innsamling

I likhet med egendefinerte dimensjoner på produktnivå blir egendefinerte beregninger på produktnivå sendt til Google Analytics som parametere knyttet til produktdataene.

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 for én spiller som kjøper noen tilleggspakker, kan se slik ut før behandlingen:

userId = 5555
Økt 1
H1: type=screen_view screen_name=/level_1/
H2: type=screen_view screen_name=/level_2/
    product_name=powerup cd4_value=weak cm4_value=5
    product_name=powerup cd4_value=strong cm4_value=5
H4: type=screen_view screen_name=/level_2/
    product_name=powerup cd4_value=medium cm4_value=1
    product_name=powerup cd4_value=weak cm4_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 tilleggspakkenProduktinntekterBrukte kreditter
svak2015
sterk105
middels101

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:

Redigering av en eksisterende dimensjon eller beregning

Når du redigerer navnet eller omfanget for en eksisterende egendefinert dimensjon eller beregning, kan dataene bli påvirket på følgende måter:

  • Redigering av navn: påvirker data som allerede er behandlet. Gamle data er bare tilgjengelige ved bruk av det nye navnet.
  • Redigering av omfang: påvirker ikke data som allerede er behandlet. Bare nye data blir behandlet med det nye omfanget.
  • Endring av aktiveringstilstand: Aktiv-feltet avgjør om verdier for egendefinerte dimensjoner eller beregninger faktisk blir behandlet. Når usann er valgt, vises den egendefinerte dimensjonen eller beregningen fortsatt i rapportene dine, 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å. Sending av en kjønnsverdi med hvert treff ville ha medført unødig mye arbeid, og hvis du konfigurerer en egendefinert dimensjon som endres ofte, med brukeromfang, blir mange treff feilaktig knyttet til denne verdien.

Var denne artikkelen nyttig?
Ja
Nei