Showing posts with label javascript. Show all posts
Showing posts with label javascript. Show all posts
Sunday, December 8, 2019
Saturday, April 20, 2019
Implement CTR tracking in Adobe Analytics via Launch
A client asked me to come up with a solution on how to track Click Through Rate (CTR) without tracking clicks due to server call constraints. Historically, I've always tracked Click Through Rate on a particular page by capturing the page name in an eVar along with a custom event for page view. For clicks, I've used a custom link name eVar and a custom click event. Then I would create a calculated metric which divides the custom clicks by custom page views (CTR %) and include that as a metric in the page name report.
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
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.
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.
Sunday, February 3, 2019
DTM to Launch Migration Tool Overview
There's a lot of buzz currently about upgrading from Dynamic Tag Manager to Launch by Adobe and there's a ton of good materials out there to help us plan and execute the migration successfully. Right off the bat, the three part series from 33Sticks comes to mind which I highly recommend you to read before this. My post will cover Adobe's migration tool which in my opinion provides a rather seamless method for upgrading to Launch. I'll share my experience with it and supplement the information that the Launch product team has already provided. I'm also not trying to provide a complete roadmap to migrate as there's already great content for it but I'm simply giving my opinion on this handy utility. Let's get started!
The migration tool is basically accessed by clicking the 'Upgrade to Launch' (highlighted in Red) button in DTM as shown below.
When you click this button, a popup will appear that shows you two check boxes and an 'Upgrade' button. The first checkbox allows you to use the same DTM embed code with Launch post migration. The second checkbox disables the existing property in DTM.
Once you click 'Upgrade', you'll see a brief message stating that the property is being migrated. Once that goes away, you'll see a link which will take you directly to the newly migrated Launch property. The new property in Launch contains the timestamp in its name as shown.
An important point to note is that only items that have been published in DTM will get migrated and anything that's unapproved in DTM will not get migrated to Launch. Here's a link from Adobe's documentation that covers what all will be migrated (Adobe Analytics, ECID, rules and data elements).
In case you want to migrate any additional rules that weren't previously migrated during the first round, you can migrate the property from DTM again. In my case, I forgot to publish a few rules in DTM that weren't migrated before so I ended up migrating the property again which added a second property in Launch with a different timestamp. Personally, I would recommend that you migrate just once and publish everything in DTM beforehand.
Now that we've seen what the migration tool does, I want to share how I would approach a migration with this tool.
Before I begin, I want to share that I've upgraded a few clients using this tool as well as migrated clients by creating a brand new property in Launch. There's no hard and fast rule around which method to choose as both options will get you the desired results but if you have a very complicated Analytics set, the migration tool might be a better solution. Let's go through what my approach would be with the migration tool.
If you had Audience Manager deployed via server side forwarding (SSF) in DTM, the AAM module will get copied over to Launch and the module will be present in the Analytics extension. My recommendation is for you leverage the in-built SSF integration for AAM inside the Analytics extension. Let's take a look.
Comment out the AAM module code in the library and save changes.
Choose 'Manage the library for me' option to let Launch host your Analytics library as well as automatically upgrade you AppMeasurement library. Also 'globalize' your Analytics object so that you can leverage the object elsewhere in Launch and in the browser console.
Finally, check the checkbox as shown below to enable the automatic AA->AAM SSF integration in Launch.
So that's a wrap. I hope you found this walkthrough helpful in case you decide to go with the migration tool but whatever approach you choose, it's imperative to have a sound migration plan and validation strategy.
Overview
The migration tool is basically accessed by clicking the 'Upgrade to Launch' (highlighted in Red) button in DTM as shown below.
When you click this button, a popup will appear that shows you two check boxes and an 'Upgrade' button. The first checkbox allows you to use the same DTM embed code with Launch post migration. The second checkbox disables the existing property in DTM.
Once you click 'Upgrade', you'll see a brief message stating that the property is being migrated. Once that goes away, you'll see a link which will take you directly to the newly migrated Launch property. The new property in Launch contains the timestamp in its name as shown.
An important point to note is that only items that have been published in DTM will get migrated and anything that's unapproved in DTM will not get migrated to Launch. Here's a link from Adobe's documentation that covers what all will be migrated (Adobe Analytics, ECID, rules and data elements).
In case you want to migrate any additional rules that weren't previously migrated during the first round, you can migrate the property from DTM again. In my case, I forgot to publish a few rules in DTM that weren't migrated before so I ended up migrating the property again which added a second property in Launch with a different timestamp. Personally, I would recommend that you migrate just once and publish everything in DTM beforehand.
As far as the (migrated) rules are concerned, Launch creates a new rule to fire off an Analytics beacon (see below) in addition to the ones that get migrated.
Now that we've seen what the migration tool does, I want to share how I would approach a migration with this tool.
My Migration Approach
Before I begin, I want to share that I've upgraded a few clients using this tool as well as migrated clients by creating a brand new property in Launch. There's no hard and fast rule around which method to choose as both options will get you the desired results but if you have a very complicated Analytics set, the migration tool might be a better solution. Let's go through what my approach would be with the migration tool.
- Treat this migration as an opportunity to do a cleanup of unnecessary data elements and rules and validate your data layer and tags in general.
- Create a thorough launch schedule/plan to QA your staging environment and sure all tags are firing as expected. There's a lot of good material out there on how to build use cases and leverage QA tools & extensions to perform validation but that's a separate post for some other day but give this step the utmost importance.
- Your launch plan needs to include a timeline of how long your tags will be tested in staging and when can they be pushed to production. I would typically give it about a month (depending on the complexity of your site) from when you begin testing in staging to when you can deploy Launch in production.
- Make sure to publish all rules, data elements and tools in DTM that you want to migrate to Launch. As mentioned earlier, only Adobe Analytics and Experience Cloud ID Service tools will be migrated so other solutions such as Target or Ad Cloud will have to be created separately in Launch.
- Click the 'Upgrade to Launch' button and do not select any of the checkboxes in the popup. The reason why I wouldn't select the DTM embed code option is because it's recommended to deploy Launch asynchronously which doesn't require the legacy pageBottom() call. As this call will have to be removed, there's no real advantage in keeping the DTM tag as you'll still need a release cycle to make this change. The other checkbox to disable the DTM property shouldn't be checked as you may need to go into DTM later.
- Once the new (migrated) Launch property has been created, click into the property and do a quick sanity check to make sure all rules, data elements and the Analytics/ECID extensions have been copied over correctly. At this time, add any extensions in Launch that didn't get copied over from DTM such as Target. I've covered AAM separately in the last section.
- Replace your existing DTM code hosted in your staging environment with the Launch embed code to begin your tag validation. Click the 'Environments' tab and copy the development script as shown below.
- Test in staging and closely follow your migration plan. After meeting all your validation criteria, publish your new Launch property in production.
Audience Manager SSF Migration
If you had Audience Manager deployed via server side forwarding (SSF) in DTM, the AAM module will get copied over to Launch and the module will be present in the Analytics extension. My recommendation is for you leverage the in-built SSF integration for AAM inside the Analytics extension. Let's take a look.
Click 'Open Editor' in the Analytics extension.
Comment out the AAM module code in the library and save changes.
Choose 'Manage the library for me' option to let Launch host your Analytics library as well as automatically upgrade you AppMeasurement library. Also 'globalize' your Analytics object so that you can leverage the object elsewhere in Launch and in the browser console.
Finally, check the checkbox as shown below to enable the automatic AA->AAM SSF integration in Launch.
So that's a wrap. I hope you found this walkthrough helpful in case you decide to go with the migration tool but whatever approach you choose, it's imperative to have a sound migration plan and validation strategy.
Sunday, December 9, 2018
Fix Variable Stickiness on Click Events in DTM & Launch by Adobe
This post covers a fix for a very common issue where page load variables tend to 'stick' or 'persist' on the subsequent click event. I'm leveraging the clearVars() function and covering exit link tracking in this case but the same logic can be applied to other types click events too. We will cover this fix keeping in mind both DTM and Launch by Adobe so without any further delay, let's jump right in!
Before we dive into the issue, we have to take a look at the HTML structure of our page. For the purposes of this post, I'm using my demo site as an example. In the screenshot below, we can see that all of our internal site links start with ".." and our external link pointing to http://www.adobe.com starts with "http://". We can use this distinction as a condition in our Tag Manager.
Given that DTM is still a populate Tag Manager that will eventually be sunsetted, it makes sense to cover how to resolve this issue in this TMS.
The first step is to disable automatic exit link tracking in DTM. We do that by unchecking the "Track outbound links" checkbox in the Adobe Analytics tool.
The next step is to create an Event Based Rule tied to the anchor ('a') element with the event handler of 'click'. The reason we do that any link on the site can be an exit link so it makes sense to simply look for the presence of an anchor link.
The next step is to disable any tracking under of the Adobe Analytics section.
The final step is to add some custom code to fire our own exit link tied to the exit link starting with "http" (covers both http: and https:) where we only include eVar3 (Page Name) as part of our exit link call along with the exit link URL passed to the s.tl() call. Note that I'm using s.clearVars() to remove the extra event6 from my call.
Once published, we can see that on click of the exit link, we're only seeing eVar3 being passed but no longer seeing custom event6 being populated in the image request.
In the Code Editor, I've used the exact same code as DTM except for the clearVars() function as I'm leveraging Launch to do that.
After publishing the code, we can see the exact same image request as we saw in case of DTM, where we're only capturing eVar3 along with the exit link URL.
So, that's it! Hope you enjoyed this post and can make use of what I've done (or something better) to solve this common issue.
Overview of the Issue
Before we dive into the issue, we have to take a look at the HTML structure of our page. For the purposes of this post, I'm using my demo site as an example. In the screenshot below, we can see that all of our internal site links start with ".." and our external link pointing to http://www.adobe.com starts with "http://". We can use this distinction as a condition in our Tag Manager.
Here's an example of a page view call (from my test site) where we have a custom Page View event (event6) and an eVar (eVar3) to track the Page Name.
On click of an exit link, we see that event6 and eVar3 get carried over on the next call.
So, let's discuss how to fix this in both DTM and Launch by Adobe.
DTM Fix
Given that DTM is still a populate Tag Manager that will eventually be sunsetted, it makes sense to cover how to resolve this issue in this TMS.
The first step is to disable automatic exit link tracking in DTM. We do that by unchecking the "Track outbound links" checkbox in the Adobe Analytics tool.
The next step is to create an Event Based Rule tied to the anchor ('a') element with the event handler of 'click'. The reason we do that any link on the site can be an exit link so it makes sense to simply look for the presence of an anchor link.
The next step is to disable any tracking under of the Adobe Analytics section.
The final step is to add some custom code to fire our own exit link tied to the exit link starting with "http" (covers both http: and https:) where we only include eVar3 (Page Name) as part of our exit link call along with the exit link URL passed to the s.tl() call. Note that I'm using s.clearVars() to remove the extra event6 from my call.
Once published, we can see that on click of the exit link, we're only seeing eVar3 being passed but no longer seeing custom event6 being populated in the image request.
Launch By Adobe Fix
Now, let's take a look at how to tackle the exact same issue in Launch by Adobe. Given that Launch has an in-built action for clearing variables, we will leverage that instead of passing it in the custom code.
The first step is to disable exit link tracking from Launch by Adobe by unchecking the 'Track outbound links' checkbox in the Adobe Analytics extension.
Next, I've created a new rule and am using the 'mouseover' event (which I really like as I'm able to test links by right clicking instead of clicking to monitor image requests). For Actions, I'm using 'Adobe Analytics - Clear Variables' and then just selecting 'Adobe Analytics - Set Variables' to put in my custom code in the JavaScript Editor. Note that I've not chosen the 'Send Beacon' action as we're doing our own custom event handler.
The first step is to disable exit link tracking from Launch by Adobe by unchecking the 'Track outbound links' checkbox in the Adobe Analytics extension.
Next, I've created a new rule and am using the 'mouseover' event (which I really like as I'm able to test links by right clicking instead of clicking to monitor image requests). For Actions, I'm using 'Adobe Analytics - Clear Variables' and then just selecting 'Adobe Analytics - Set Variables' to put in my custom code in the JavaScript Editor. Note that I've not chosen the 'Send Beacon' action as we're doing our own custom event handler.
In the Code Editor, I've used the exact same code as DTM except for the clearVars() function as I'm leveraging Launch to do that.
After publishing the code, we can see the exact same image request as we saw in case of DTM, where we're only capturing eVar3 along with the exit link URL.
So, that's it! Hope you enjoyed this post and can make use of what I've done (or something better) to solve this common issue.
Sunday, September 30, 2018
Adobe Analytics Reporting Issues and Tips
It's been a while since I've been a full time analyst but I do get to dabble in data in my current role as Technical Consultant. This post covers some of the reporting/segmentation challenges I've faced with Adobe Analytics and some tricks I've learnt in my role. My primary purpose of writing this post is to share it with other technically focussed users and capture it for my own documentation. Let's get started!
- Cardinality Issue: One issue that has caused me some strife is the Unique Exceeded issue where only the top 500,000 rows for a particular month are shown. This happens when cardinality for a particular dimension (E.g. Page URL) is very high and Analytics outputs a string called "Low Traffic" as shown below where it's the most popular data point. This means that any segments leveraging Page URL will not show accurate results as only the top 500,000 values are shown in the UI.
- How to Address the issue: I can think of 2 solutions to tackle this issue:
- Add Dimensions with Low Cardinality: In your implementation, define a unique page name or sub sections for a combination of URLs and capture query string in a separate variable to keep the URL clean. Basically, look at alternative dimensions that have a low cardinality.
- Leverage DataWarehouse: DataWarehouse (shown below) allows you to export more than 500K rows so you can essentially, export as many rows and then filter the data offline.
- Single Page App Issue: In a recent client scenario, we had a situation where they had a Single Page App (SPA) built using AJAX and the UI experience changed but the page didn't refresh. These experiences often times leverage callback functions which developers can configure so that we can fire off "artificial" page views even if the page doesn't reload.
- Issue: My client wanted to see how many users landed on the SPA experience when the "cmpid" URL query parameter was present. They populated an Analytics event tied to this query string but saw a very high number of instances which exceeded the actual page views on this landing page. The issue was tied to the fact that the Analytics URL (highlighted in Red) did not get updated when in fact, the SPA URL changed (highlighted in Green) for additional steps in the flow. Given that the Analytics URL is used to evaluate if the query string is present, the instances of the event kept getting inflated despite the fact that "cmpid" was not present anymore.
- Solution: The solution was to update the Analytics URL by overriding the s.pageURL (Analytics URL variable) with document.URL using JavaScript. This allowed us to ONLY track events when "cmpid" was populated.
- Visitor Stitching Segment: A very common use case for enterprise clients is to stitch visitors across mobile app and mobile web where they want to attribute downstream events to visitors coming from a mobile app to a mobile web view. An example is a conversion funnel that is embedded in a native app where there is a mix of native app screens and web specific HTML or AMP pages. It will make sense to define a unique variable to differentiate between mobile app and mobile web and use that in a segment as shown below.
- Sequential Segmentation: Sequential segments are explained very well here and I highly recommend you read this but my example is much simpler and deals with a recent question I got from a client.
- Question: How many people stayed on the "about-us" page for at least 2 minutes and then clicked on the "visit-homepage" link?
- Answer: The answer is a simple sequential segment which did take me a few tries and it's shown below:
- Exclude Segments Work Well: I've used exclusion segments quite extensively to remove users tied to a particular dimension or event. I've also used exclusion as an option to create "inverse" segments to test my results. Below is a simple example of an Exclude segment that worked really well for me recently where I had to exclude visits who spent less than 15 seconds on a page:
- Finally, a Segmentation Container Primer: I'll wrap up by covering a simple yet confusing concept of segment container which has often stumped me. It's the general difference between the various segment containers (namely Visits, Visitors and Hit) and when to use these. In the following screenshots, we see how each container affects the underlying data.
- Hit Container: This container when applied, yields the fewest page views and instances as it confines the data to the actual hit level. The requirement for this container to work is for the variable to be set in the image request. It will show the lowest number of page views or instances.
- Use Cases: Apply this when you want to get the most accurate results for a particular dimension or event. E.g. You can use this container if you want to get actual page views or video views for a particular time frame or search term. You should also use Hit level segments to create Virtual report suites.
- Visit Container: This container shows data for a particular visit where something happened without a gap or timeout of 30 minutes. The will show page views or instances that are more than that of a 'Hit' container and less than that of a 'Visitor' container.
- Use Cases: If you're looking to analyze user behavior that can only happen within the same visit such as Bounces, Click on a Call to Action on the Homepage, Landing page Visits tied to a marketing campaign etc.
- Visitor Container: This container will show data tied to a Visitor cookie (typically 2 years) and will show all page views and instances for the lifetime of the Visitor. This will show the most number of page views or instances as the scope of this is the biggest among the three containers.
- Use Cases: If you're looking to find out total revenue captured across all visitors or to see how many visitors traversed from a mobile app to a mobile web view.
I hope these tips will help you answer some simple, yet confusing concepts that often requires additional investigation and can lead to unforeseen delays.
Saturday, August 25, 2018
3rd Party Pixel Implementation in Launch by Adobe
Launch by Adobe is gaining a lot of popularity among clients who are either migrating from Dynamic Tag Management or from a different Tag Management system. I've already helped a few clients migrate to Launch and have experienced how robust this TMS is especially in terms of managing the firing of Adobe specific tags and other 3rd party scripts. A 3rd party script or tag is a snippet of code that is deployed either on marketing landing pages or purchase funnels to attribute marketing campaigns to conversion activities.
Launch has a lot of 3rd party tags (see example below) that are supported as extensions which can be deployed via a user friendly UI and the list is ever growing but there will always be a need to deploy 3rd party tags that won't be available in the catalog.
Launch has a lot of 3rd party tags (see example below) that are supported as extensions which can be deployed via a user friendly UI and the list is ever growing but there will always be a need to deploy 3rd party tags that won't be available in the catalog.
As an example, below is a screenshot from the Adobe Advertising Cloud extension UI that makes it very easy to deploy this pixel without writing any custom JavaScript.
This post shows how to deploy a 3rd party tag called PepperJam not yet added to Launch and covers the various steps needed to to get it done successfully. Let's take a look.
- Evaluate 3rd Party Tag Deployment Documentation: Typically, you will get a tag deployment/requirement documentation from your vendor. Once you get the 3rd party tag documentation from the agency or vendor, make sure to go through it to understand the JavaScript snippet, where the tag needs to fire, what attributes need to be passed and how to test the snippet. These are some of the key questions required that need to be answered before deploying any 3rd party tag.
- Capture all relevant Meta Data using Data Elements: In this case, the vendor requires us to capture the currency code, order total, order ID and a query string parameter called "clickid" that needs to be persisted for the visitor. In the next two screenshots, we create two data elements. The first data element captures the order total by tying directly to a data layer/JSON attribute on the page called dataLayer.orderTotal. The second data layer captures a query string parameter called "clickid" that needs to be persisted for the visitor and we've used the "Visitor" duration. This post covers persistence in Launch in more detail.
- Create a Rule: The first step in a Launch rule is to create an event. In this case, our event is page load and we're going to choose "DOM Ready" to fire this event. DOM ready is an event which is executed when the document object model has loaded. The next step is to choose a condition. In our case, we want to fire the pixel on a page called activewear.html. You can validate the condition by putting in the URI in the Regular Expression Tester as shown below.
- Implement the PepperJam Pixel: The last step in the pixel implementation process is to add an action within the existing rule. We do that by clicking on "Open Editor" and pasting the JavaScript snippet provided by the vendor. Take note of the two highlighted data elements in the screenshot from the code snippet which have been manually added to the pixel to pass additional meta data.
- Validate the PepperJam Pixel: The final step is to validate the pixel in a browser. As per the first screenshot below, we can see that additional attributes (meta data) such as amount and Click ID are populating based on the data elements tied to the data layer and query string parameter respectively. The second screenshot shows that the Click ID is still populated even if the clickid query parameter is not populated in the URL as we created a Visitor based data element.
Hope you found this post useful. Is there a 3rd party pixel that you've deployed in Launch that isn't supported via an extension yet?
Subscribe to:
Posts (Atom)