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.
You may need to know if the current page has any Google Optimize Experiment running, to track that info on any tool, or to fire some vendor tag based on the current experiments statuses.
The following snippet will take care of sending a dataLayer push if there’s any active experiment running, including:
The Experiment ID
The Optimize Container ID where the experiment is running on
The current experiment variation being shown to the current user/device
(function() {
for (var gtm in window.google_tag_manager) {
if (gtm.match(/^GTM/)) {
if (google_tag_manager[gtm].experiment) {
dataLayer.push({
'event': 'optimize-experiment-active',
'optimize-container-id': gtm,
'optimize-exp-name': google_tag_manager[gtm].experiment.split("$")[0],
'optimize-exp-variation': 'Variation: ' + google_tag_manager[gtm].experiment.split("$")[1]
});
}
}
}
})();
Then just create the needed dataLayer type variables to read the pushed data and use it on your tags/triggers.
I’ve been attending lately (and having) to some talks about the logs parsing from the SEO perspective, (from @David Sottimano on Untagged Conference and Lino Uruñuela during some dinner time), and I’ve decided to publish a WordPress plugin that I started to work on some years ago, and that for work reasons I had it left on my “I’ll do it” drawer and it never came back to my mind.
First thing I need to the point to, is that this is a BETA PLUGIN, so please careful of using it on a high load trafic or on a production site. I’ve running on this site for 4 days without any problems, but that doesn’t mean it’s free of bugs. Let’s consider this plugin for now as a proof of concept.
The main task of the plugin is to register the search bots visits to our wordpress site into Google Analytics, using the Measurement Protocol.
The working flow of the plugin is easy, it just checks if the current visiting User Agent is matching any known Crawler, and based on that info we’re sending a pageview to some Google Analytics Property. Please take in mind that it’s recommended to use a new property since, we’re going to use a lot of custom dimensions to track some extra info beside the visited pages =)
I used to had my own User Agents parser, but I ended using another well stablished (and for sure more reliable) library. When something works there’s no need to reinvent the wheel :). So this pluggin uses the PHP library for the uap-core project.
Let’s see a simple flow chart about what the plugin does:
I’m sure this was easy enough to understand. But don’t only want to check what pageviews were visited by a search bot, no we’re going further and we’ll be tracking the following:
And for sure you may find replies to a lot of more questions, since we’re using Google Analytics to track those visits, we’ll able to cross any of the dimensions at our needs.
Another cool thing of tracking the bots crawls within the Measurement protocol, is that we’ll be able to watch how our site is being crawled in the real time reports! 🙂
Setup
You’ll just need to download the plugin zip file from the following url, and drop it in your WordPress Plugins folder and configure the Google Analytics Property ID to where you want to send your data.
Used Custom Dimensions
You may be wondering why do we have the same bot info related dimensions duplicated and with a different scope, this is why because as I explained before we’re using the bot IP address to build up a clientID and an userID, and it may happen that Google uses the same ip for different bots (like for Desktop or Featured Phone). This way we can have the hit level info too in the case that user scope data get’s overriden 🙂
Another thing we may want to do, is to setup the session timeout limit to 4 hours within our profile configuration. Bots Crawls are not done the same wht as an user navigates the page, and we may be getting 2 pages hits per hour, so the default 30 minutes timeout makes not sense at all.
Let’s know see how the reports will look on Google Analytics 🙂
Consumed content by bots with an hourly breakdown
Total sessions and pageviews by search bot
Pages that returned an 404 and which bot was crawling it
Which pages did a certain bot crawled (User Explorer Report)
I’ve been told by a lot of clients that the way that Google Analytics cross-domain tracking works is “ugly”, referring to having the linker param attached to the URL.
I must admit is not elegant having all that long hash on the url, thougt it won’t affect the page functionality. In the other side there isn’t any other to pass the current client Id from the Universal Analytics cookie to the destination domain without dealing with server-side hacks (we can’t not read POST data in JS ,yet).
Browsers have the History API . Which holds the current user navigation history,allows us to manipulate it and is widely supported by browsers:
history api support by browser
If you ever dealed with an Ajax based website, I’m sure you have noticied that even if the page does not reload, the url gets changed.
The history API does allow us to play with the current user session history, for example:
window.history.length
The above line will return the number of elements in the session history, if you have browse 4 pages in the current it’ll return 4.
window.history.back()
Will return the user back to the previous page in the session.
But we’re going to focus on the pushState and replaceState methods. Those ones will allow us to add a new entry to the history record and will allow us to change the current page pathname without needing to reload the page.
I bet you’re guessing that we’re going to strip out the _ga parameter with those functions and you’re right. This won’t be harmful for the crossdomain tracking since we’re going to do it after the Google Analytics object has been created so it won’t affect our implementation but we’ll end showing the user a cleaned up URL after Google Analytics does all it’s cross-domain tracking magic.
We’ll using the “replaceState” in this example, to avoid users clicking on back button to be sent to the same. This method will just change the URL but WON’T add a new entry to the session history.
To achive this hack, we’ll be using the hitCallback for our Pageview Tag on Google Tag Manager.
In first place, we are going to need a variable that is going to take care of reading the current URL, cleaning it up, and manipulating the browsers URL using the History API.
I’m calling it “remove _ga from url pushState” , feel free to name it at your convenience:
function(){
return function(){
if (document.location.search.match(/_ga=([^&]*)/)) {
var new_url;
var rebuilt_querystring;
// A small function to check if an object is empty
var isEmptyObject = function(obj) {
var name;
for (name in obj) {
return false;
}
return true;
}
// Let's build an object with a key-value pairs from the current URL
var qsobject = document.location.search.replace(/(^\?)/, '').split("&").map(function(n) {
return n = n.split("="),
this[n[0]] = n[1],
this
}
.bind({}))[0];
// Remove the _ga parameter
delete qsobject['_ga'];
// Let's rebuilt the querysting from the previous object with the _ga parameter removed
var rebuilt_querystring = Object.keys(qsobject).map(function(k) {
if (!qsobject[k]) {
return encodeURIComponent(k);
} else {
return encodeURIComponent(k) + '=' + (encodeURIComponent(qsobject[k] || ""));
}
}).join('&');
// We want to if the current querystring was null
if (isEmptyObject(qsobject)) {
new_url = location.pathname + location.hash;
} else {
new_url = location.pathname + '?' + rebuilt_querystring + location.hash;
}
// Use replace State to update the current page URL
console.log(new_url);
window.history.replaceState({}, document.title, new_url);
}
}
}
Now we only need to add this new variable as the hitCallBack value for our pageview tag:
So this is what is going to happen now:
1. Google Analytics Object will be created 2. It will process the linker parameter, overriding the current landing domain clientId value as long as the linkerParam value is legit 3. After that the current page URL will be changed for the same URL but with the _ga parameters stripped out.
