This client didn't want to use ActivityMap due to security constraints as they had some links which had borderline sensitive information. The other requirement was to control the logic that constitutes a "click" but a majority of my clients use ActivityMap though and I do like it. So, they asked me how to calculate CTR WITHOUT capturing a click event as they were concerned about server calls which is a fair ask. After a few unsuccessful tries, I eventually stumbled upon this article from Adam Greco. This post will cover how to implement Adam's solution using Launch and show how that materializes in actual reporting.
What we need to set this up
- A Tag Management Solution like Launch or some other TMS
- A custom plug-in called getPreviousValue which will allow us to capture the value of the previous page name
- A JavaScript variable to capture the previous page name
- Products string
- s.pageName
- 1 eVar (Merchandizing eVar to capture Page Name)
- 2 events (Clicks, Page Impressions)
Implementation In Launch
The first step is add the getPreviousValue plug-in to the custom code section of the Adobe Analytics extension instead of a rule. This is how I implement plug-ins in Launch so that they're readily available across the board and populate on every hit if needed.
The next step is to create a global page load rule tied to DOM Ready where we need to add some more custom code to track to wrap this solution up.
This is the crux of the solution where use the products string to create "fake" products and store the previous page name in a global variable called PrevPn. The code captures the current page name on page view along with a unique page view event (event7) on page view. On the next page, our code populates the current page name (eVar7) tied to event7 (Page Impressions) and also captures the previous page name in the same eVar7 along with a separate event8 (Page Clicks). Please note that we've assigned "fake" SKUs of "imp" and "click" in the products string which will show up in the Products report. Also, the if statements are key for this to work as each condition is meant to identify a page view with or without a previous page name.
This is the crux of the solution where use the products string to create "fake" products and store the previous page name in a global variable called PrevPn. The code captures the current page name on page view along with a unique page view event (event7) on page view. On the next page, our code populates the current page name (eVar7) tied to event7 (Page Impressions) and also captures the previous page name in the same eVar7 along with a separate event8 (Page Clicks). Please note that we've assigned "fake" SKUs of "imp" and "click" in the products string which will show up in the Products report. Also, the if statements are key for this to work as each condition is meant to identify a page view with or without a previous page name.
Click to zoom in
Validation
In my sandbox site, I can see that I'm capturing both the current (company) and previous page name (activewear) in the products string after clicking a link.
Reporting
The first step is to create a calculated metric to calculate CTR (Page Clicks/Page Impressions) which I've shown here.
The next step is to put it all in a report to show how it all comes together. This report shows the merchandizing Page name along with the custom events and a calculated metric to capture CTR.
Drawback of this Solution and an Alternative
There's no way to differentiate which link performed well but an alternative will be to store the link name on click in a cookie and then retrieve that on the next hit in a separate merchandizing eVar within the products string. This will be in addition to the existing solution to track CTR based on the page name eVar.
So, that's a wrap and hope you like it! With this, we're able to implement a solution that captures the CTR on a page without tracking clicks thereby saving server calls.
No comments:
Post a Comment