Formiranje URL adrese sa RegEx za Omnicomov OCP u Google Analitici

Jedan od najzastupljenijih CMS platformi u Srbiji (i regionu) pored globalnih CMS sistema je i OCP kompanije Omnicom.

Česta situacija koju korisnici sistema imaju, ukoliko koriste Google Analytics alat, je URI (sve posle imena domena u URL-u). Svaka nova verzija stranice ili template ima novi broj.

Da biste u Google Analitici imali lepe podatke tj URI, i sa takvom informacijom pravili ciljeve (Goals) potebna je mala intervencija.

Funkcionalnost filtera koji postoji u svakom pogledu na informacije (View) omogućava ovaj zahvat.

Ukoliko želite da proverite kako filter radi i da li zadovoljava vaše potrebe, neophodno je da napravite novi pogled (View). Ovo je jedan od najbitnijih koraka, kako ne želite da vršite aktivnosti nad osnovnim profilom gde vam se slivaju sve informacije.

Nakon kreiranja i podešavanja pogleda, otići ćete do filtera za taj pogled i podesiti ga prema sledećem principu.

Kreiranje novog filtera u Google Analitici

Kreiranje novog filtera u Google Analitici

Kreiranje filtera (1/2) u Google Analitici

Kreiranje filtera (1/2) u Google Analitici

Kreiranje filtera (2/2) u Google Analitici

Kreiranje filtera (2/2) u Google Analitici

Suština je u korišćenju RegEx-a Google Analitike.

Preuzimanjem sadržaja iz URI-a i kreiranjem filtera (.*)\.[0-9]+(\.html.*) svaki URI se dekomponuje na više elementa.


URI: /nice-day-in-tasmania-2.87.html?param=32345

se razlaže na elemente korišćenjem RegEx

Prvi deo URI-a koji predstavlja stranicu /nice-day-in-tasmania-2 postaje prva varijabla ($A1) korišćenjem otvorenih i zatvorenih zagrada,  verzija stranice sa tačkom   .87  postaje običan element detektovana kao broj [0-9]+, dok sve ostalo što dolazi posle broja (uključujući i tačku pre ekstenzije) .html?param=32345 postaje druga varijabla ($A2).

Kako smo tokom filtriranja iz URI-a kreirali dve varijable, u poslednjem polju možemo poslati polju koje se tiče URI-a novu vrednost (umesto one koja je stajala i koja je uključivala numeričku verziju template-a) – $A1$A2.

Sada će vaši URI-ji u Google Analitici imaju formu sa kojom možete lakše da radite sve lepe i napredne stvari.

Google Analytics lost guide for solving returns and changes in ecommerce

Dealing with ecommerce in Google Analytics is always a challenge – taking into account all details you need to fulfill in order for data to be stored properly. Once things start behaving strange (wrong calculation during submission of ecommerce data) you have to make things right. And the question beckons: “How to reverse transactions in Google Analytics?

Disclaimer: following post is summary of various posts across internet, Google help and real life experience dealing with storage of data. Presumption of how data is stored is based on deduction and knowledge about database architecture. 

Google help on that matter is pretty straightforward – explaining how to cancel transaction or initiate return, but you have to read every single word in order to understand what happens deep down inside Analytics engine.

Some of the colleagues in Analytics community went through explaining how to handle returns (using tools available within Analytics), older tracking code setup explains inner working and some new (regarding analytics.js setup).

Purpose of this “lost guide” is to explain how this really works and how to deal with adjustments of values, using Measurement protocol.

How ecommerce data is stored within Google Analytics?

Pretty simple, if you think of it, but never explained in details. Two tables, one for transaction information (invoice header), and second with items data (invoice items). Connecting tissue is transactionID.

How google analytics store data?

How Google Analytics store data?

Important this to mention, if you are familiar with databases – when sending data to Google Analytics servers you are not updating anything! You are merely sending additional row of data which is summarized within GA interface.

Due to the nature of Bigtable it is not really possible to update things and work in SQL matter (sorry for tech talk here). This means that data is stored as it comes. Outcome is that, if you have transaction on Monday and some change happening of Friday, on your graph within GA interface you will see changes on both days. This can mislead people looking at graphs and not selecting right time period.

Looking at interface and data (presuming you selected period between Monday and Friday) information about transaction (revenue, tax, item info) will be summarized correctly.

There is no reference integrity between two tables

You think it would be easy?

If you change data on item level (somebody returned one item out of 2) and you inform GA servers about this change, transaction data will not reflect this change. This means that transactionId used to connect data between two tables is just for reference, not for automated update of transaction data.

Once you update item information, update transaction information as well. GA will not do this for you.

How to change things quickly?

The best way is to have the change of item and transaction data on the same day when purchase occurs, but it is not always the case. Returns (partial) or errors get noticed when some time passes. The easiest way is to use Universal Analytics and its measurement protocol to send information.

This is plain URL you place in browser’s address bar and hit Enter. if_unknown)&t=transaction&ti=transactionId&tr=value_of_transaction_with_dot&ts=shipping_value_with_dot&tt=tax_value_with_dot&cu=currency_code if_unknown)&t=item&ti=transactionId&in=item_name&ip=value_of_item_with_dot&iq=quantity_with_dot&ic=item_SKU&cu=currency_code

With two hits to Google Analytics server you will solve your (or your client) problem.

Things to take into consideration…

  • Values (numeric) are always delimited with dot “.”
  • When sending data, both for transaction and items, if they contain the same values, storing will not occur
  • If you want to decrease quantity of certain item, use negative quantity
  • Date and time of storing data is when it occur
  • Data stored on Google Analytics servers can not be “erased”, you can only sum it up
  • Negative quantity will decrease quantity but have in mind that value must be positive (-1*1000 will decrease quantity of item by 1 and decrease value) / in other way if you put positive quantity and negative value you will increase quantity but decrease value


Every hit to collection with Measurement protocol will collect some “extra information” like location, source/medium… which will change your other reports. This is important to have in mind.

Verification of Session flow in Ecommerce – GTM and Google Analytics way

Let’s jump into Google Tag manager (GTM) wagon and contribute to solutions we came across our cases.

In our company culture is always present question on data quality we work with. Google Analytics data as primary storage point is crucial to decision making and data analysis. Problem we faced at one point in time was – how to detect breaking steps in sales funnel per user session? Google Analytics can give pretty nice information on selected data summarized and split into steps – but we needed to  understand more per user session. Beside this problem we had to be certain that data stored in ecommerce part is in line with internal sales system.

We can not guarantee that data stored in Analytics regarding sales (ecommerce) part is 100% correct, as sales process is not hosted on client servers and in complete client control – that we can analyze server logs and all process steps.

System in place, with multi step goals, different payment processors depending on currency used became serious challenge involving wide range of talents, tools and resources.

Main goals of GTM and GA setup was

  • identify steps in process where users stop or generate error (with complete trace per user and session and position in process)
  • verify  ecommerce data collected on thankyou page with processing system(s) information

Second goal concerning verification of GA ecommerce data and external system was finished with standard reporting set from GA. On the other hand, first request showed to be bigger issue.

Google Analytics is storage engine, that does computation of multiple metrics attaching them to specific dimensions. In this process happens sampling. If you have big set of data, in order for system to be responsive and fast – sampling must occur. We had to deal with specific people and their problems on daily basis in order to debug process and avoid sampling.

In order to be able to analyze anything we had to add additional information using session level custom dimension information. As GA is prohibiting storing any kind of personal information in GA we had to rely on unique session identification provided by server. Using this variable (and including it within data layer pushed to GTM) we were able to follow specific user and his flow through site, identifying steps in sales funnel where user stops or goes further.

On top of other data layer variables – user language, site language, location and pages in sales funnel we were able to detect faulty scenarios in sales process.

In terms of outcome – detecting faulty scenarios in sales funnel worked flawlessly giving us and developers insight where to look for breaking points. This lead to cutting development cycles from more than 24 hours (mostly waiting for processing logs) to less than 2 hours.

For second problem – quick integration with SuperMetrics for Google Docs solution and active follow up on client side provided insights in quality of data stored in Analytics. At the end small difference occurred between Analytics and sales system, showing that root cause of difference exist due to nature of processing system – even if transaction information sent to website cleared as OK in next few minutes payment processor can decline payment and cancel sales.

If you need more details or more graphic explanation of process – respond :).