<script> (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){ (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o), m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m) })(window,document,'script','//www.google-analytics.com/analytics.js','ga'); ga('create', 'UA-XXXX-Y'); ga('send', 'pageview'); </script>
But GA Universal is providing a special userId parameter in the configuration to setup your custom ID for GA cookies instead of the random userId. This significant change helps us to track users on multiple devices, because we can use custom visitor ID based on customer email or ID in your database to merge smartphone/laptop/pc sessions into one cross-device session.
So let’s add userId options to auth users and save GA auto-generated cookie id only for non-auth visitors.
<?if ($isAuthenticatedUser):?> ga('create', 'UA-XXXX-Y', {'userId': '<?=$userId?>' }); <?else:?> ga('create', 'UA-XXXX-Y'); <?endif;?>
$isAuthenticatedUser
- true, if current visitor is authenticated
$userId
- authenticated user’s unique id from database
This small change makes a significant difference: from now on all users who sign in to your website will be tracked correctly through all those devices. But as well as using a new GA Universal account, I’d recommend you also keep the Classic GA code on your website until GA Universal collects enough data.
As you can see, the _ga cookie was changed after users’ authorization, but it works properly and all history from the visitor session will be merged into the customer session. So, despite the fact of changing ID, the session transition in GA works perfectly well, because at the moment when the user sees the first page after authorization (or registration) - GA gets access to legacy visitor id_ga value and new setup by userId parameter. All those allow GA to merge 2 user sessions: before and after sign in (sign up) into 1 global session. The result: you will observe smooth session startup from the first visit and flowing through all user's devices.
We’ve tested it for the last 4 months and it works brilliantly!
The next big change is a measurement protocol. With the help of this new version you can track actions internally from your application without having to add some ugly paraments to urls to tell GA about a successful payment or registration.
The simple code looks like this:
$ch = curl_init(); curl_setopt($ch, CURLOPT_URL, "https://example.com/path/for/soap/url/"); curl_setopt($ch, CURLOPT_POST, 1); curl_setopt($ch, CURLOPT_POSTFIELDS, array( ‘v’ => 1, ‘tid’ => ‘UA-XXXX-Y’, ‘cid’ => $_COOKIE[‘_ga’], ‘t’ => ‘pageview’, ‘dp’ => ‘/payment/success’, )); curl_exec($ch);there:
v
- protocol version, now "1"tid
- GA tracking idcid
- client id (it can be md5(email) or md5(id) for auth user)t
- hit type (pageview/event)dp
- page for pageviewThis code will send pageviews to GA for the page “/payment/success”. You can use it in your application to track any actions. Also there’s the same simple code for event tracking (if you want to use it in a/b testing or fire some application event).
$ch = curl_init(); curl_setopt($ch, CURLOPT_URL, "https://example.com/path/for/soap/url/"); curl_setopt($ch, CURLOPT_POST, 1); curl_setopt($ch, CURLOPT_POSTFIELDS, array( ‘v’ => 1, ‘tid’ => ‘UA-XXXX-Y’, ‘cid’ => $_COOKIE[‘_ga’], ‘t’ => ‘event’, ‘ec’ => ‘payment’, // category ‘ea’ => ‘small’, // package ‘el’ => ‘small package 1 year subscription’, // label ‘ev’ => ‘324’, // value of this action $324 in my case )); curl_exec($ch);