Endrede transaksjoner i Looker Studio

Selv om hensikten med utvidet netthandel er å spore de endelige transaksjonene forbundet med kjøp samt visse brukerinteraksjoner før slike kjøp, finnes det visse scenarioer der utvidet netthandel kan brukes til spore transaksjoner som ikke nødvendigvis er endelige. Disse scenarioene omfatter blant annet reservasjoner og skjemaer for potensielle salg som sendes inn. I slike tilfeller kan det være fremtidige transaksjoner som fører til endringer i de endelige inntektene og de aktuelle produktene.

Funksjonalitet i utvidet netthandel

Du bør kjenne til følgende funksjonalitet i utvidet netthandel når du skal deduplisere transaksjoner:

  • Når det sendes et treff sammen med en transaksjon, fører denne transaksjonen til at det totale antallet transaksjoner som er registrert i transaksjonsberegningen i GA, øker. Dette skjer uansett om transaksjonen har den samme ID-en som en tidligere transaksjon.

  • Når et treff sendes sammen med en refusjon, øker antallet refunderte produkter, men transaksjonsberegningen påvirkes ikke.

  • Hvis det sendes én transaksjon pålydende X kr og en påfølgende transaksjon pålydende -X kr, utlignes inntektsberegningen, men antallet transaksjoner blir to, ikke én.

  • Hvis det sendes én transaksjon pålydende X kr og en påfølgende refusjon pålydende X kr, påvirkes verken antallet transaksjoner eller inntektsberegningen. Beregningen for refusjonsbeløp øker med X kr, mens beregningen for antallet produktrefusjoner øker med én. Antallet produktrefusjoner øker med én for hvert produkt som refunderes.

  • Hvis du sender flere transaksjoner med den samme ID-en og så sender en full refusjon, blir den siste transaksjonen refundert, men det tas ikke høyde for de foregående transaksjonene.

Endring av transaksjoner

I bunn og grunn er det ikke mulig å ta høyde for transaksjonsendringer med standardoppsettet. Utvidet netthandel er utviklet for å måle tilfeller der brukere har passert returpunktet i en kjøpssyklus, ikke når brukere i stor grad kan endre det de kjøper.

Nedenfor beskriver vi ett av alternativene du kan bruke til å opprette rapporter som tar høyde for endrede transaksjoner. Det finnes andre løsninger på dette, men vi ser ikke nærmere på disse her.

Opprett egendefinerte rapporter

Du må bruke Looker Studio for å få den ønskede rapporteringen. For å få rapportene du vil ha, bør du bruke en kombinasjon av refusjoner og transaksjoner. Du må overholde reglene nedenfor for å påse at det virkelig tas høyde for endrede transaksjoner.

  • Hvis en kunde endrer transaksjonen sin ved å ta med produkter som øker den tilknyttede inntekten, skal bare tilleggsinntekten sendes i en ny transaksjon. Den nyeste transaksjonen skal altså ikke omfatte de totale transaksjonsinntektene, men den skal ha den samme transaksjons-ID-en som den gamle transaksjonen.

  • Når et produkt fjernes fra en transaksjon, må du sende et refusjonstreff.

  • Oppgi alltid produktene som fjernes, samt inntekten, produktinntektene og antallet produkter forbundet med den aktuelle refusjonen. Oppgi dette selv ved fulle refusjoner.

Det må opprettes en egendefinert beregning som alltid har verdien «1», og som bare sendes når kunder ber om en full refusjon, ikke ved delvise refusjoner. Den egendefinerte beregningen skal ha treffomfang og er påkrevd ettersom det ikke finnes noen beregning hvor det totale antallet fullt refunderte transaksjoner telles.

Slik oppretter du Looker Studio-rapporter

  1. Opprett en ny Looker Studio-datakilde ved å knytte hovedrapporteringsvisningen til Looker Studio

  2. Opprett disse feltene i datakilden:

    1. Dedupliserte transaksjoner

      1. Formel: count_distinct(transactions)

    2. Antallet endelige transaksjoner

      1. Formel: antallet dedupliserte transaksjoner – verdien i den egendefinerte beregningen for refunderte transaksjoner

    3. Endelig inntekt

      1. Formel: inntektene – refusjonsbeløpet

    4. Endelige produktinntekter

      1. Formel: produktinntektene – refusjonsbeløpet for produktet

    5. Endelig antall produkter

      1. Formel: antallet – antallet refundert

Beregningsfeltene i Looker Studio-datakilden er nødvendige for at du skal kunne opprette en fullstendig deduplisert transaksjonsberegning som også fjerner refusjoner. I de andre beregningene der verdier kalkuleres, skal du også ta med inntekts-, produktinntekts- og kvantitetsberegninger som tar høyde for refunderte inntekter og produkter.

Begrensninger

Den største utfordringen ved å utarbeide egendefinerte rapporter og gå utenom de ordinære rapportene i GA, er at visse funksjoner, for eksempel multikanalstrakt- og attribusjonsrapportene kanskje ikke blir særlig nyttige, i og med at transaksjoner ikke dedupliseres.

Var dette nyttig for deg?

Hvordan kan vi forbedre den?
Søk
Slett søket
Lukk søkefunksjonen
Hovedmeny
4731818256156289550
true
Søk i brukerstøtte
true
true
true
true
true
69256
false
false