Povezivanje offline i online trgovine uz Google Analytics

Temelj digitalnog marketinga je mjerljivost i naravno konstantna optimizacija. Problem u mjerenju, točnije u dijelu mjerenja koje se bavi atribucijom, izuzetno je prisutan u situaciji kada tvrtka prodaje usluge i proizvode isključivo offline ili u miksu online i offline.

Primjer A

• Potencijalni kupac posjeti stranicu domain.com koristeći google / cpc
• Na stranici pogleda sve bitne informacije o proizvodu no posjet ne završava direktnom kupnjom
• Za dva dana isti taj posjetitelj dolazi u offline trgovinu i izvršava kupovinu
• Zaključak cijele priče je, ako koristimo npr. Google Analytics je kako google / cpc ne radi svoj posao jer nema direktne konverzije i možda još bitnije nismo u mogućnosti povezati kupnju i izvor prometa na stranicu – atribucija.

Primjer B

• Potencijalni kupac posjeti stranicu domain.com koristeći google / cpc
• Na stranici direktno kupi proizvod
• Za mjesec dana automatski se naplaćuje obnova pretplate / ugovora
• Ukoliko ne pošaljemo taj podatak u Analytics gledamo samo inicijalnu kupovinu korisnika no ne vidimo i ukupnu vrijednost kupca (kanala) te nam također izračun isplativosti može biti i više no nedostatan.

Primjer C

• Potencijalni kupac posjeti stranicu domain.com koristeći google / cpc
• Na stranici direktno kupi proizvod no uz odabir neobvezujuće ponude, virman ili Cash On Delivery
• Transakcija se može ali i ne mora bilježiti u Google Analyticsu jer u nekim slučajevima čak oko 50% takvih kupnji neće biti realizirano
• Morate se odlučiti – ako bilježite kao transakciju onda korisitite GA više za praćenje namjere kupovine no ako ne bilježite te odgođene kupovine kao transakcije dolazite u situaciju gdje ‘kažnjavate’ izvore prometa.

Rješenje nije jednostavno ali postoji. Problem s kojim se trgovci najčešće suočavaju je najjednostavnije opisan u tri dijela:

1. Trgovac mora doraditi i isplanirati sustav za mjerenje – Google Analytics
2. Trgovac mora doraditi svoj poslovni sustav
3. Trgovac mora doraditi svoj POS

Prije same tehnike izvođenja potrebno je u Google Analyticsu razlikovati dvije dimenzije bez kojih cijela priča oko povezivanja offline i online nema smisla.

Client Id – link

• Identificira uređaj / browser.
• Client Id je obavezan!

Situacija A – spremamo client Id iz uređaja s kojim je korisnik recimo isprintao kupon
Situacija B – ne spremamo client Id već dodjeljujem client Id u trenutku transakcije u offline trgovini (ovdje nam je potreban useri d kao identifikator – primary key)

User Id – link

• Identificira korisnika na više uređaja / browsera.
• User Id nije obavezan.

Situacija A – ne koristimo user Id – ako ne koristimo feature Google Analyticsa User Id View i nemamo CRM logiku poslovnog sustava
Situacija B – koristimo User Id view i pratimo korisnika na više uređaja to omogućava cross device praćenje i atribuciju (tema za neki naredni članak)

Odlučiti kako će se transakcije slati u GA (koji izvor prometa)

Sve informacije koje se šalju u Google Analytics iz offline svijeta dolaze u GA putem Measurement Protocola. Informacije kako MP radi i što vam sve treba nalaze se ovdje:

1. Measurement protocol pregled
2. Primjer i upute za slanje Enhanced ecommerce transakcije
3. Hit builder – Alat za testiranje hitova (osobito ecommerce transakcija u ovom slučaju)

Zvuči jednostavno ali nije jer tu ipak imamo neke dodatne opcije (kako slati izvor prometa):

1. Slati custom izvor prometa u obliku pos / offline (source / medium) – ovo radimo najčešće kada se transakcija doslovno dogodi offline
2. Uopće ne slati izvor prometa – ovo najčešće radimo kod odgođenih transakcija ili kada želimo u izvještajima vidjeti online izvor prometa (obzirom kako će ovo biti prepoznato kao direktni promet u igru ulazi last non direct attribution model koji prepisuje direkt zadnjim poznatim izvorom prometa unutar 6 mjeseci koliki je standardni campaign timeout)
3. Slati online izvor prometa u slučaju kada radimo recurring billing i sl. – ovo je ujedno i najteži način jer moramo poslovnom sustavu poslati još jednu informaciju do koje više nije ni tako lako doći

Napraviti dokumentaciju koja opisuje dvije glavne stvari kako bi cijeli model funkcionirao:

1. Client Id / User Id – ukratko bez ove dvije informacije krajnji cilj – atribucija online > offline neće funkcionirati, barem ne u Google analyticsu. Ove dvije vrijednosti koristimo kao primary key – povezivanje posjetitelja u online i offline svijetu.
2. Definirati ‘payload’ – što će Analytics primiti kao povratnu informaciju iz poslovnog sustava trgovca (ecommerce transakciju – dolaskom Enhanced Ecommercea ovo je postalo malo kompliciranije jer se transakcija šalje uz postojeći hit – event ili pageview (preporuka je pageview jer se neće stvarati čudni pageless sessions – sessioni kojima je landing page (not set)))

Rješenje za Primjer A (Online posjet > Offline kupovina)
Opcija A – Kupac na stranici printa kupon na kojem se nalazi i client Id i / ili user Id kupca (non PII vrijednost! – guglajte:)). Prije transakcije čitač skenira vrijednosti i sve je spremno. Na POSu se bilježi transakcija uz dodatna polja client Id i user Id kupca i šalje poslovnom sustavu koji podatke o transakciji šalje Google Analyticsu.

Opcija B – Kupac na stranici ispuni i pošalje formu – lead. Uz sadržaj poruke šalje se opet i client Id koji se sprema u bazu. Ako i kada korisnik kupi online i kada se u CRMu transakcija zabilježi (promjeni status korisnika / leada) sustav šalje transakciju u Google Analytics.

Kod obje opcije kada se šalje transakcija možete generirati source i medium dimenzije koje odgovaraju offline kupnji npr. pos / offline. U toj situaciji online izvori prometa zaduženi za online transakciju biti će vidljivi u MCF izvještajima (Assisted, First Click).

Dodatna opcije razlikovanja offline i online kupovine koje ne uključuju manipulaciju izvora prometa mogu se odraditi i na slijedeći načine:

1. U transaction ID dodati sufiks – offline
2. U Affiliation polje umjesto ‘Store name’ postaviti ‘Store name Offline’
3. Custom dimenzija koja za svaku transakciju nosi vrijednost Online ili Offline

Rješenje za Primjer B (Automatska obnova pretplate / ugovora)
Prilikom prve kupovine poslovni sustav osim transakcije mora zabilježiti i client Id parametar. Pri obnovi pretplate u Analytics se šalje transakcija uz client Id (ako koristite Enhanced Ecommerce to znači slanje pageview hita koji sadrži i EE dio informacija). User Id uvijek stoji kao opcija i tu je bitan samo ako koristite User Id view feature. Obzirom da obnova pretplate može ići i nakon podužeg vremenskog razdoblja savjet je poslati i inicijalni izvor prometa (kod prve transakcije). To se može napraviti da u bazu spremite ili gclid parametar ako je riječ o AdWordsu ili UTM parametre ako je riječ o kampanji ili referrer informaciju.

Rješenje za Primjer C (odgođena kupovina)
Korisnik prilikom kupovine napravi odabir plaćanja pouzećem što nećete odmah zabilježiti kao transakciju no u poslovni sustav se sprema client Id parametar. Kada se status narudžbe promjeni u ‘realizirano’ poslovni sustav šalje u Google Analytics pageview hit i dodatne informacije o transakciji (ako je riječ o Enhanced Ecommerce rješenju) – client Id naravno obavezan a user Id kao opcija. Za ovaj primjer nemojte slati informacije o izvoru prometa ako je razdoblje od trenutka narudžbe do transakcije relativno kratko.

Kako bi sve radilo potrebno je:

1. čitati (na stranici), spremiti (u bazu) i ponovno poslati podatke (iz sustava u Google Analytics) uz client Id / user Id parametar
2. Koristeći measurement protocol poslati pageview ili transaction (i item hit) u Google Analytics
3. Shvatiti koje posljedice ima manipulacija izvora prometa