Today I’m releasing a small Custom Template for Google Tag Manager that will take care of notifying the dataLayer about if Google Analytics is currently being blocked by the browser.
Some days ago, I published the following tweet, to get some user’s feedback on Twitter. The approach not really bad, but having to deal with code is not the best solution for most people.
I remember someone asking how to detect if GA was being blocked by user’s browser some weeks ago ( can’t remember who was, I’m sorry ), what about this approach using feach API?. anyone can bring up any handicaps about doing it this way? Gist > https://t.co/jLBRoBOVkMpic.twitter.com/zVvqMDJxGw
I decided today to build a quick Custom Template to take care of checking if Google Analytics is being blocked. We’ll simply using the sendPixel library from Custom Templates. If you didn’t know if sendPixel library allows you to fire an onSuccess or onFailure callback functions.
Then based on these callbacks the template will be push the data accordinlty to the dataLayer. And from there you may do whatever your want, like notifying an external application with an event, or showing the user any alerts ( this was just a dummy idea, please don’t annoy the users on this ).
sendPixel(url, onSuccess, onFailure)
The Custom Template has some configurations available to fine-tune que current behaviour of the tracking.
You can decide if sending an event if GA is being blocked or if GA is NOT being blocked
You can individualy define the event names for each of the previous pushes
You can set how often you want to the template to check if GA is being blocked. On each pageview, once per session ( 30 min ) or a personalized time period.
About one month ago I started to work on a Google Tag Manager Custom Template for Yandex Metrica, I must say it was my first contact with it apart from installing the default snippet some years ago on this same blog.
In order to ease my testings for the template I ended building a Browser Extension which I’m releasing today for Chrome, Firefox and Opera.
I tried to cover all the differents hits that Yandex may send, but of course I may be missing some of them ( more likely to be on the beta JS library ). The extension currently support the following hit types:
Hit (Fields Reported: URL, Title, Referrer, full payload details)
setUserID (Fields Reported: UserID, full payload details )
params (Fields Reported: Key,Value Up to 5 levels , full payload details )
userParams (Fields Reported: Key,Values Object , full payload details )
notBounce(Fields Reported: none , full payload details )
webvisor (Fields Reported: All Post Payload for webvisor is reported in a beautified way, full payload details )
ecommerceDetail (Fields Reported: Product Details , full payload details )
ecommerceAdd (Fields Reported: Product Details , full payload details )
ecommerceRemove (Fields Reported: Product Details , full payload details )
ecommercePurchase (Fields Reported: Purchase Details+Product Details, full payload details )
It may happen that the extension is not able to detect the hit data type, and it will be shown as undetected row:
Don’t worry about this kind of rows in the reports they will be gone gradually as long I continue learning about Yandex Metrica Protocol and API.
I’d define the current extension status somewhere between Alpha and Beta. So have in mind that you may find bugs while using it in your sites. Please don’t hesitate to contact me so that way I can improve the extension functionality. 🙂
Algolia is a company that offers a Search_as_a_service tools. They offer a Real Time services, which can be improved by sending events about users interactions over the products your site like add to carts, adds to wishlists, clicks after search, filters use, or conversion.
This library currently allows to track 3 main types of events: – Clicks (clickedObjectIDsAfterSearch , clickedObjectIDs, clickedFilters) – Conversions (convertedObjectIDsAfterSearch, convertedObjectIDs, convertedFilters) – Views (viewedFilters, viewedObjectIDs)
From now on you can setup your Algolia’s Search Insights, via Google Tag manager using a Custom Template.
At this first Release the following functionality is implemented on the Custom Templates
Methods/Events
viewedFilters
viewedObjectIDs
clickedObjectIDsAfterSearch
clickedObjectIDs
clickedFilters
convertedObjectIDsAfterSearch
convertedObjectIDs
convertedFilters
Events Variables
userToken
index
eventName
objectIDs
filters
queryID
positions
Advanced Settings
Manage if the current user has Opted Out
Override the default cookie duration (default value 6 months)
Region value setting from the Init Tag
User Token persistance. You can define the User Token within the Init tag and it will be persisted to the subsecuent events sent to Algolia Search Insights
Barilliance, is a eCommerce personalization tools for eCommerce including cart abandonment/retargeting emails and personalized product recommendations.
The tag setup is pretty easy, just add your account id into the unique available place in the tag configuration 🙂
It’s been a while since my last post ( Shame on me!) , but the new Custom Templates feature has been a great addition to Google Tag Manager the last week.
I’ve been playing the last days with this new feature, trying to build a more complex template, so I decided to try to implement a full Yandex Metrica Custom Template for Google Tag Manager.
What’s supported:
Method ( track types )
Init
Outbound links ( Fields: URL )
File Downloads ( Fields: URL , Referrer )
Reach Goals ( Fields: Target, Order Price, Currency )
Hit ( Fields: URL, Referrer, Title )
User Id ( Fields: User Id )
Session Pameters ( Fields : Parameters Map )
User Parameters ( Fields : Parameters Map )
Not Bounces
Tracking features supported on the tracker:
Enabling/Disabling default Data Sending ( default pageview, useful for SPA Sites )
Enabling Hash Tracking
Disabling sending pages to Yandex Index
Loading the Script library from the alternative CDN
Enabling/Disabling Accurate Track Bounce tracking
Enabling/Disabling Click Maps tracking
Enabling/Disabling Track Links ( including extensions personalization)
Enabling/Disabling Webvisor
Enabling Disabling the Debugging Cookie
Ecommerce Tracking ( data layer variable name can be personalized )
I’ve included some advanced features ( I’m new to Yandex Metrica, so I had no time to properly test them yet )
Debug Mode can be enabled from Init Tag without the need of setting up a QueryString parameter
Today is a big day!, I finally managed to put some of my internal debugging snippets within a single Chrome Extension and I’ve just released it on the Chrome Webstore so everyone can try and use it.
To install it you will need to visit the extension page on the Google Chrome Webstore, you can there just clicking on the screenshot below:
NOTE: The first time you open the extension panel. It may be show an empty report, just click F5 to start seeing data. This will be fixed on next release.
The extension focuses on debugging Google Tag Manager implementations ( most information reported is related to dataLayer information ), and it does also offer some information about Google Analytics hits being sent from the current loaded page ( ok folks: only Universal Analytics is supported, if you’re using the legacy GA library (ga.js) please give your implementation/client a bit of love and upgrade to Universal Analytics ).
The current extension release provides the following information:
dataLayer pushes list ( including some profiling details, like the time passed between pushes )
Current push details and current dataLayer model status for each dataLayer push
Google Analytics hits sent by the current page.
Along with the pieces on info abouve the following features are available:
All dataLayer pushes are shown in a prettified way, so they are more readable and easy to use.
You can individually copy to the clipboard any push details in a formatted way ( useful for when making documentation for clients )
Hits payload are shown in a prettied and formatted way, making the debugging even easier.
You can filter the hits by the UA property ( great for when you’ve some big implementations sending hits to different properties )
You can filter the hits by the type ( event, timing, pageview, etc )
You can see the details about how each GA hit was sent, using GET, POST, or if it was sent using image or beacon transports
You can easily view the current hit payload size and if it contains any Enhanced Ecommerce Data
The current GTM Debug Extension is somewhere between Alpha and Beta stages, so don’t be so hard with it. I’m already aware of it having some weird behaviour over some websites and it would be really helpful if you could take 5 minutes to report these bugs to me. I’ve opened a Google Group in order to be able to get feedback and bugs reports. You can find it on the following link: https://groups.google.com/forum/#!forum/gtm-debugger-extension
If you are working on a client website and want to expose the website, you can reach me through twitter or use this website’s contact form :).
Looking forward for your comments in order to improve the extension! 🙂
The code above will show that ugly error into your browser console, despite you didn’t do anything really bad at all. ( I don’t really get why the FBEvents.js doesn’t just silently ignore the init if the pixel Id is already initialized :X )
This said, let’s explain how Facebook Pixel works:
As you can see each ‘init‘ method call, puts that pixel id into an internal array. And then each track call will loop through that array firing a hit for each already “initialized pixel id” on it.
Yep, this means that after a pixel has been initialized any call to the “track” or “trackCustom” method will forcedly be sent for all current initialized pixels !! Meaning that you won’t be able to control which pixels should be sending the current action. I can’t really understand why each pixel doesn’t own their own namespace to have a better control.
Now let’s see which would be the best way to setup our Facebook Pixels using Google Tag Manager.
1. One that that is going to take care of initializing all our Facebook Pixels.
2. On each different action we want to track on FB (eg: “Add To Cart”, “ViewContent”). We’ll be adding just the method call, since the main library an object are already in place!
Techie Fix Alternative
Another way of fixing this error is checking if the current pixel we’re using is already initialized before calling the “init” method. As usual some coding may help us, we can check it using the following JS snippet:
if (window.fbq.__fbeventsModules.fbevents().getState().pixels.map(function(pixel) {
return pixel.id;
}).indexOf('MY_FB_PIXEL_ID') == -1) { // PIXEL NOT INITIALIZED. DO YOUR STUFF }
I know … It’s been a while since my last post, but I’ve been saving myself for something big. Over the last months I had the chance to run a big migration from Google Tag Manager over Tealium that had taken most of my time.
Along with this extension release I want to say that I might start a new series of blog posts related to Tealium, based on my experience with this Tag Manager System.
One of the biggest problems I had when working with Tealium, is that debugging it was some kind difficult, specifically when talking about the utag.link calls . So I coded a extension for Chrome that was throwing all the debug info I needed to the browser console in order to make my daily work easier.
This past week I decided that I was going to release it, since I think it could be useful for some other people. So I spent the last week building a new UI for the Tealium Debugger instead of having to swin around all that flood of console debug output.
Extension Features:
Pretty print of UDO data and data pushed via utag.link calls.
You’ll be able to easily check the values types. Inclusing the arrays values preview when hovering them ( there’s no need to expand them to view what data they hold)
Keep navigation data
The extension will kept the previous visited pages data in place
All data related to current loaded Tealium enviroment
You can easily see what account, profile and enviroment had been loaded for the current page. And of course the publication time for the current profile.
[BETA] – View which tags had been fired
You will be able to check which assets/tags had been loaded through tealium for each visited page. This feature is currently in Beta, and it’s likely going to be improved in a future.
Please have in mind this is my very first Chrome Extension and that it may be buggy or it may not be working fine for some websites. If it’s not working for your site please let me know so I can take a look to it. And of course any feedback will be gratefully welcomed.