Is it possible to track custom vars in real-time GA view? - google-analytics

I am starting with Google Analytics and found custom variables very useful (using Classic Analytics now).
Exploring the panel I do see a section for custom variables under the non-real-time section. However, if I head to the real-time section, there is no evidence that custom vars are going to appear there (i.e. they can only be seen under the non-real-time section).
Checking the documentation does not clarify this as it does talk about custom vars but does not specify if they appear or not under the Real-Time section. Anyone knows?

It would be impossible for the documentation to list everything that is not the case, so if something is not documented and not visible in the interface it's in most cases safe to assume that it is not there.
However Google has documented what is visible in the real time reports and there is no report for custom vars.

Related

How to connect Google Analytics to Symfony 4?

I have a small blog on Symfony 4. I need to add views to the articles. Decided to use Google Analytics. But I did not find the normal documentation how to connect Google Analytics to the symfony 4.
In general, you simply have to append a script tag that is provided in Google Analytics' web interface. See either this or this answer on the help resource. Perhaps, that would be the best option for you, since you just have a simple blog. The script should probably be added in your base template, or the layout so that it renders just above the closing </body> tag.
Another option would be setting up a server-to-server interaction with GA. There are several bundles for that: one, two. But most probably you won't need that.
You can simply put the script in your default base layout like the conventional base.html.twig. If you want to minimize the interaction with the layout you can create a Twig function that returns the Tracking ID stored in parameters.yml, either use bundle that provides extra features for interaction with your server, have a look for GoogleAnalyticsBundle which is still maintained by a symfony core developer.

Google Adwords implementation via GTM - Please suggest correct implementation

I am trying to audit Google dynamic Remarketing tag on our website. It is done via GTM and from what i've read online, instead of using data layer passed through codebase variables it is using custom javascript. Below is the way it's implemented which is confusing. i just want to know if this is correct way of implementation or should i re do the tag?
we have a custom javascript variable "google_tag_params"
Then we have adwords Remarketing tag implemented which references data layer variable "google_tag_params" that fires on all pages
Then we have several other gtm tags : homepage, products, cart etc (custom html type) that populates the google_tag_params. Below is an example for the homepage which fires on homepage and products
Products
Any documentation which explains this current implementation will be helpful.
Thanks
This looks like a working implementation, although it negates pretty much all advantages of having a tag management system.
Remarketing attributes different weights to users depending on which pages they have visited - a user who has just looked briefly at the homepage is less valuable than a user who has looked at product categories or product details (plus the more you know about the products viewed the more precise you can tailor the ads to your clients taste, or so the theory goes). This is why you need to pass in data about the sites visited and the products viewed via a javascript object - the "google_tag_params".
Usually the data for this would be provided in the source code of your website - ideally in the datalayer format, although a global javascript variable works as well.
Apparently the site you are looking at does not do that. So the person who implemented this used custom HTML tags to create global JS variables with the necessary data. This puts the data in the global namespace. Then (s)he created a javascript variable that reads the js variable created from the tag and feeds it to the Adwords tag.
There are multiple custom HTML tags with definitions for the google_tag_params. I am pretty sure that if you look at the triggers you will see that they are fired on specific pages - "Homepage" only at the root page of your website, "Products Variables" on product details pages etc. That way the google_tag_params object contains the data that is required for the respective page type. Since the website does not provide product data there is some custom javascript in the "Products Variables" tag to extract data from the DOM.
Does this work ? Well, I guess so. Is it elegant ? Certainly not - two of the main advantages of GTM are encapsulation (the only global variable you need is the datalayer array, thus mitigating the risk of naming collisions) and a fairly robust selector engine. Your code as it is uses none of that.
Is is worth changing ? Maybe, a little. It would be a little more elegant if the google_tag_params would be created in a custom javascript variable (which takes the format of an anonymous function that returns a value). Also the DOM extraction code could be moved either to custom javascript variables or DOM type variables (which reads data from HTML elements without any custom code if you can come up with the proper selector). However while this means you have a nicer and marginally more reliable implementation this means some effort for basically the same outcome.
However a proper implementation would rely on a datalayer that is provided by your page (i.e. it is created via server-side code). DOM extraction is a fickle business and if you change your markup you will break your Adwords tracking.
If you cannot have a dataLayer implemented via server-side code then the pragmatic solution would probably be to leave things as they are. It does leave you open to a few problems (if you change the markup or introduce a global JS variable named "price" or "qty" then your implementation is screwed) but apparently this has done its job so far, so why go the extra mile.

Enhanced e-commerce using GTM but no in-page dataLayer

I am working on a project where I do not have access to page source nor can I ask client's IT team to create in-page/onload dataLayer e.g. having dataLayer before the tag. Is the idea of implementing enhanced e-commerce tracking remotely possible via dataLayer.push e.g. build dataLayer as you go?I have a very little knowledge of dataLayer.push (which I am starting to read up). Question is :
Is dataLayer.push the correct way move forward? Have anyone done this
before?
what issue I might face e.g. "add to cart" event, remove cart or
category page any working example? I still don't have a clear view of
the workflow here.
What are the downside of doing it this way beside "style/css" based
trigger might fall off during future site design update.
Thanks.
Your main problem is that you need to get the data from somewhere. Usually without a dataLayer this means DOM scraping and then assembling the scraped data into a dataLayer in a custom javascript function. Drawbacks are the same as with your stle/css based triggers:
Implementation is strongly coupled to the page layout
data might be missing, or require cleaning (if mixed with html or unrelated text)
potentially expensive in clients CPU time
custom javascript introduces new points of failure (i.e. can you test rigorously enough to guarantee that there are no side effects)
If you do workarounds around your client's ITs shortcomings remember that you own them - you will be responsible if the workarounds break, or have side effects, or need to be amended to account for new features. Make sure that you are very well compensated for that risk (and personally with the experience I have now I would not do this at all).
I think it's important to acknowledge here that the Data Layer is just one way of storing this information, and is used solely because it's possible to push data to it from the page.
If you can't write the code into the site itself, don't push information to the data layer. Just keep that information for yourself, in GTM's variables. You'll save yourself a huge headache, and a bit of computation too.
DOM scraping is a perfectly reasonable way to get hold of information, but you will run into some barriers.
You're going to have to write a lot of JavaScript to get the data you need.
Some buttons may turn out to be composed of several elements that you'll have to cover with your triggers etc.
Any changes to the site will potentially ruin your code.
Not everything is available to you, especially verification of data (checking if a purchase went through is probably no longer possible before reporting the transaction).

Upgrading to Google Universal Analytics

I have been searching around to find out anything that needs to be taken into consideration when upgrading to Universal Analytics.
I found this post:
Google Analytics - Upgrading to Async Code
He explains that if you are not doing anything advanced you should be ok. We have lots of event tracking in place that we would like to keep the same. We also have some Custom Variables I could do without and/or deal with in Custom Dimensions.
Other than that we have a fairly basic setup.
We do have a "keep alive" event in place also that helps determine an accurate time on site.
Another really important question has everything to do with being able to transistion from Classic analytics to Universal. Is this possible? I found an article that said it wasn't but that article was a couple months old and not sure if its still true.
Thoughts?
Universal Analytics is Google's newest tracking code. It is currently in beta phase, so you may want to hold off on it, depending on your resources... In principle it works more or less the same way as the async code. Here are the major points about it:
The syntax is different. All config/tracking is done by making a call to ga()
Some of the "config" arguments for things have been moved to the GA interface. For example, names and scope for custom variables are no longer passed as arguments on-page. They are now done within the GA interface. Actually to be more accurate, custom variables no longer exist. Google now has custom dimensions and metrics as a replacement. Custom dimensions are the closest translation to custom variables (they are pretty much the same in principle). Custom metrics are some kind of mix between dimensions and events.
Google currently does NOT offer a way to upgrade your profile(s)/account(s) to Universal Analytics style. In order to use Universal Analytics, you have to create a new account or profile. If you want to try Universal Analytics out, Google currently recommends implementing it along side the traditional or async version you already have implemented.
Google has not currently officially stated when or if they will provide a means to migrate existing profiles, though I personally think they eventually will, since preserving historical data and reducing time and costs associated with migrating is a huge concern to everybody.
In addition to #Crayon-Violent's answer, be aware that the current Core Reporting API (v3) doesn't support retrieving custom dimension/metric data.
This month Google anounced that classical analytics properties can be upgraded to Universal without any data loss.
Universal Analytics is a set of technological innovations that improve
the way data is collected and processed in Google Analytics. The
Universal Analytics Upgrade is a process you can use to upgrade all of
your classic Google Analytics properties into Universal Analytics
properties without losing any data or changing your account settings.
All Google Analytics properties will soon be required to use Universal
Analytics. Any properties that don’t follow the upgrade process will
be auto-transferred to Universal Analytics in the future.
You can upgrade your analytics property from analytics admin panel. https://developers.google.com/analytics/devguides/collection/upgrade/
In case of upgrade problems you can refer to Google group:
https://groups.google.com/forum/#!forum/ua-upgrade
I recently inherited a project loaded with Google Analytics and I had never worked with them before. The code migration to Universal Analytics was straightforward with the exception of moving from Custom Vars to Dimensions. Google's documentation does little to highlight this.
After some digging around I found a couple of things that I think may help others that are migrating:
1) Set up or edit custom dimensions & metrics
Note that when you set up the Dimensions you are provided with code snippets that you can copy & paste into your project.
2) How to use the code to send custom dimensions & metrics
This docmentation will help you understand the provided code snippets and learn how to better work with them.
I hope this info spares others some of the pain that I experienced going through this.
I've created a plugin like jQuery Migrate to backward compatibilty of eventTracking and other features.
Allow developers to migrate old methods _gaq.push() to ga() object.
https://github.com/empiricompany/universal-analytics-migrate

How do I add order information from Google Checkout into my database?

I have implemented Google Checkout sandbox for testing buy button which successfully allows user to place their orders. I want to add order of Google Checkout sandbox to my database by using asp.net.
Can anyone tell me how can I implement this scenario?
There are multiple interfaces to Google Checkout . By far the easiest is a buy now button, which is what it sounds like you've implemented. Now the limitation with that method is that it places one item into a cart at Google and that's the end of the interaction. So you need to process the order in the Merchant center. Nice and simple for small sites processing few orders. But doesn't sound like what you want. At the other end of the spectrum, you can do a custom cart using the html or xml interfaces. Using the xml interface, you have complete control of the order. Google will then do call backs on complete order to post the cart back to your site. Taken to the extreme, you can automate pretty much anything that could be done in the merchant center: canceling orders, issuing refunds, etc.
It's all a question of trading off integration effort with control. They offer a number of different integration patterns. There's a nice comparison on in the developer docs. But with the buy now buttons, I don't believe that anything ever comes back to your system, and it sounds like you want the order details back on your system/site. You may also want to take a look at Ways to integrate with Google Checkout and pick the integration pattern that makes the most sense for you.
I don't have ASP.Net code to hand you, but I'm sure it's doable and there are examples in the developer docs.
See this site for Checkout Client Libraries & Sample Code (including .NET and Classic ASP):
http://code.google.com/apis/checkout/samplecode.html

Resources