Adobe DTM’s built-in element capture for onclick event listeners are pretty useful. One of the most useful resources on the internet around this topic is Jim Gordon’s amazing infographic, where you can find a list of all possible variables you can use with DTM.
I was reading the other day the very interesting article published by Adam Greco about Creating Conversion Funnels via Segmentation for Adobe Sitecatalyst where he basically breaks down visits into four different segments, depending which section of the site a user visited during a session. One of the things that a couple of colleagues debated was the first segment called “Awareness”.
According to Adam;s post, we include in the awareness segment people who have come to your website, but never seen a product, attempted to download a trial of it or purchased it. They simply express an interest because they saw an ad, heard something or read an article about it.
I was recently asked – due to some issues with Adobe T&T – to run a test with Optimizely, one of the most popular AB Testing and Personalisation platforms in the digital space right now. While implementation with Google Analytics is pretty straightforward, there were some challenges I had to face with Adobe Sitecatalyst (as expected) and deployment via DTM.
Optimizely offers an integration feature for Adobe Analytics (Screenshots below) from which you can activate the tool and use its interface in order to push Experiment Names into Prop and/or Evar, similar to AAs for Target (A4T) plugin and to custom dimensions for those using Google.
Deploying code via DTM is fairly straightforward, but Optimizely documentation seems more tailored to native JS deployments of Adobe Analytics and hardcoded RSIDs which caused a couple of issues with our current setup.
Thanks to the help of our awesome Adobe Specialist Alex Brown, we managed to come up with a solution:
The majority of the time landing page analysis is the primary focus of any web analyst when carrying out a web site review. However, little attention is given to visitor departure pages, also known as the Exit Rate.
This lack of focus is somehow understandable, especially on heavy acquisition web sites, where CMOs and Heads of Digital spend heavy budgets on biddable media and want to know which channel performs best when it comes to their KPIs. Consequently, the focus goes to landing page optimization metrics, in order to analyse visitors. It’s important that you don’t, however, ignore your visitors and what they do next.
Most of the time this happens because unlike the Bounce Rate, there isn’t a set rule for the Exit Rate. A visitor could end the visit at any moment without a meaningful reason, thus it is harder to explain. I believe that an exit rate analysis can give you a lot of important answers as to why particular visitor segments are exiting your site prematurely.
Today I am going to publish a post around Google’s new hot topic, Accelerated Mobile Pages (AMP) and how to set it up in Wordpress web sites. After reading this post you will learn how to add the following WordPress features to your AMP pages:
- Google Analytics
- Google Adsense
- Related Posts
- Featured Image
- SEO Meta Data
- Social Sharing Buttons
What is Accelerated Mobile Pages (AMP) and how is it different to Responsive Design
In this post I will show you how to use the standard CSV report from Google Analytics in order to do path analysis and identify how users navigate through your web site and which particular journey results in a successful conversion. A lot of people and digital marketers pay attention to landing page performance, relevant behavioral and conversion metrics (conversion rate, bounce rate, etc). However, in many cases the bounce rate is low on the landing page, but high on the next page that catches the user’s attention.
I decided to write a post about the Google Analytics code, primarily for people new to the web analytics world. Even if this a very old topic that has been exhausted by various renowned bloggers, I realised that a lot of people still struggle to understand the basic differences between Google Analytics tracking code versions.
Hopefully in this post I will clarify the main differences and modifications that you can do to your Google Analytics code, when to use each version, and what you’ll get in return. I will also cover how to do the same modification with Google Tag Manager. If you do not know what Google Tag Manager is, Google recently released a series of videos that will help you understand the basics.
I will not go through the old school Urchin.js code, and dive directly to the codes you are most likely to see in various web sites today.
One of the coolest features Google AdWords released towards the end of last year was the “AdWords Customer Match” lists for Retargeting. Ok it is not as good as Facebook’s Email look alike feature but still it can be extremely powerful, especially for companies that offer various types of account upgrades or Product trials.
This is not going to be a big post as it will discuss a bit about one of the silliest adobe sitecatalyst barries, the known to all of us from Google Analytics “Visitor Type”.
In GA, on the Audience report, you can select the Behaviour tag and then click on “New vs Returning”. This will automatically categorise
Then GA provides you
Unfortunately Adobe Analytics do not provide you a “User Type” report by default, however this is an easy fix by creating a couple of Visit type segments on your own.
The first segment you will create is the New Visitor one. We will name this “Visit Type: New visitor”
In this post I am going to explain how to install google analytics universal with Google Tag Manager.
I am assuming you are familiar with GTM and how this tool can make your life easier but in case you aren’t here a small video from Google discussing some of the key concepts: