Showing posts with label Tag Management. Show all posts

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

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.

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!

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!

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.

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.

Wednesday, October 31, 2018

Adobe Experience Platform SDK Setup (iOS)

There were 178 billion apps (statista) downloaded in 2017. With that amount of volume, it'll be unthinkable for any major organization today to not have a mobile app that allows existing and potential customers to interact with its brand. Most Apps regardless of their purpose have some kind of analytics tracking embedded in them and one of the tracking solutions they leverage is Adobe Analytics.

Adobe Experience Platform SDK (informally known as SDK V5.0) was recently launched and it aims to give clients more flexibility around mobile SDK deployment as it leverages Launch by Adobe to publish changes in an external environment outside of the native app. This was not the case with the previous version v4 of the SDK. The reason why that's exciting is because any configuration changes to the SDK around Analytics can now be done in Launch without having to go through the App Store. There are other differences between the two versions which is covered in more detail here.

There are two primary methods to setup the AEP SDK which are either using CocoaPods or the manual method but in this post, I'll cover how to set this up manually. A lot more information is provided in the Mobile team's official documentation but my aim is to take their instructions and document it visually using my sandbox. I'm covering two main components of this setup which leverage Launch by Adobe and XCode (V10) to setup the SDK.

Launch by Adobe Setup

This is a big enhancement of this SDK over V4.0 where we're now able to deploy the configuration library using Launch by Adobe as opposed to the ADBMobile.json config file that we have with V4.0. The primary advantage of this is that we're able to make basic configuration changes such as changing report suites, enabling/disabling tags, activating the Experience Cloud ID service etc. directly in Launch without having to go through the App Store. There will obviously be a need to publish the app at the start to the App Store to submit the app. Please note that we currently cannot setup any trackAction (clicks) or trackState (page views) calls in Launch and need to do that directly in the App so that does require us to to go through the App Store for each change. Let's go through the steps.

Create a mobile property in Launch and select the platform as Mobile.

We then setup extensions in Launch and by default, you should see two extensions already added called "Mobile Core" and "Profile" which are explained below. I'm not going to cover these in detail as we only need to add some basic details to the Mobile Core extension. Additionally, we also need to add the Adobe Analytics from the Catalog and install it. Let's review these extensions.

Mobile Core: This provides essential SDK related functionality as well as the library to deploy the Experience Visitor ID service
Profile: It stores user attributes on the client and more details can be found here
Adobe Analytics: It provides the Adobe Analytics library to the SDK.

Add your tracking server

Add your report suite and tracking server

Once we've installed the extensions, we need to retrieve the iOS libraries that are accessible in the Environments section in Launch. This snippet contains a reference to libraries that need to be included in XCode to deploy the SDK (see below).

Finally, we need to publish these extensions to either the development or production environment depending on the scenario. Note that you can also disable Analytics tags from the App by publishing it in Launch if required.

XCode Setup

Before diving in, I highly recommend that you review the steps outlined in Adobe's official documentation on configuring the SDK. Some of what I'll cover is outlined in the documentation but I'm including a lot more detail in the form of screenshots from XCode which the documentation doesn't include. So, let's continue.

Download XCode and setup a basic App which allows you to simulate an iOS App experience.

Download the AEP iOS SDK from Adobe Experience Platform's Github branch located here.

The downloaded zip contains a bunch of files and folders but the one we need to use is called "iOS" which contains two sub folders called "device-only" and "universal".

The "iOS" folder needs to be added to XCode and mapped to the Target in XCode. Once the mapping is done, we need to add some frameworks to the "Embedded Libraries" section in XCode to provide the necessary libraries to the SDK. Please note that for an actual iOS Apps, you need to use the frameworks present in "device-only" but for Simulators (my use case), you need to use the frameworks present in the "universal" folder. I've tried to color code the relevant details in this screenshot.

Once the required frameworks are added, we need to reference all libraries and call specific methods to activate lifecycle calls, enable logging and other methods as explained here. I'm using Objective C but the documentation covers Swift and Android syntax as well. Please note that I copied the installation code directly from the Environments section in Launch (covered above) and included it in XCode which ties the SDK with Launch. I've included these methods in the AppDelegate.m file of my App. The integration with Launch is done via the configureWithAppID call to which we pass the Launch App/Environment ID.

Once the basic lifecycle tracking methods are added, we can add a trackState (page view) method call to trigger an event. I'm basically sending data to the "screenName" variable populated with a value of "homeview". That is typically done in the ViewController.m file.

Finally, we need to make sure that the App build is successful and test the Analytics call. In my case, I'm looking for the variable called "screenName" which is populating in the debugging console as shown below.

The Adobe Experience Platform SDK is still relatively new and is being evolved but the process of installing the SDK is fairly easy once you get through the initial learning curve. I will continue to keep track of all upcoming features and will write about other functionalities tied to Launch by Adobe to trigger different types of mobile events.

Sunday, March 25, 2018

HTML5 Video Tracking using Launch by Adobe

Tracking interactive media such as video is often a mandatory requirement for clients as they want to gauge the effectiveness of media on their website or app to influence ad revenue or sales. Companies like Youtube, Hulu, ABC or Comcast put a lot of emphasis on tracking video metrics. More the video views, more their ad revenue so it's usually one of the first platforms they want to measure.

Tracking video players typically requires developers to embed code into the video player and fire off tracking beacons triggered from an analytics platform's plug-in. Plug-ins such as Milestone (legacy) and platforms such as Heartbeat (latest) for Adobe Analytics allow clients to track video on their website. Every video implementation I've been involved with (including HTML5), requires both the developer and the technical consultant to implement custom JavaScript logic within the video player and Tag Manager respectively.

Recently, I was involved in helping a client migrate from their legacy (H) code's Milestone tracking code hosted via on-page Analytics code onto the latest analytics (AppMeasurment) library in the Launch by Adobe tag management platform. Sounds simple right? Nope, as their video player (HTML5) had a ton of JavaScript code embedded within the video player and in the analytics configuration file. After looking into our internal documentation, it was apparent that there was no easy migration path as their Milestone library was implemented along with the legacy analytics H code and isn't compatible with the newest AppMeasurment library. The other thing that was challenging is that Milestone video tracking method is no longer supported by Adobe.

This prompted me to host a HTML5 video player with NO video related JavaScipt code, I repeat NO embedded JavaScript code on my own sandbox environment and implement a basic instance of the Launch Tag management solution with AppMeasurement. After validating the approach, I asked the client to implement the same methodology on their own website and it met their requirement.

Please note that to capture video name, I updated the video ID in HTML to capture a user friendly video name that is the only piece of video related 'code' I added on the page. The other thing to keep in mind is that my approach leverages link tracking events to track video events. Below are the steps I took to track metrics such as video start, video 25%, 50%, 75%, 100% complete and dimensions such as friendly video name and others.

Inject Launch by Adobe async JS library: Adobe recommends injecting the async Launch library in the head of the page as it's faster and non-blocking.

Implement AppMeasurement code in Launch: Implement the latest AppMeasurement code in Launch which is what I did for my client. Here's a general screenshot of the extension.

Track Video Name in Launch: We create a data element to capture the video name using the video ID HTML tag where we embed a friendly name. There are other approaches to grab this from the page by writing custom code but I did this to make the migration process seamless for my client. Below is a screenshot of what the video ID looks in the HTML.

Next, we create a simple data element in Launch where our data element captures a "DOM Attribute" called "video" as shown below that is tied directly to our HTML.

Create a Rule to track Video Start: Once we've setup the data element to capture the video name, we now need to setup individual rules in Launch to capture video events. The first video event we want to create is the video start event where we trigger the video event when 1% of the video has been viewed. This made sense to my client as he agreed that unless a user has viewed 1% of the video, it's not really a 'true' video start. So in the scenario, we'd choose the "Data Element Type" as "Media Time Played" triggered when 1% of the video has played. I've added a caveat at the end of the article to explain why we didn't use the "Media Play" event type.

Next, we scroll down to the "Actions' section to set our analytics variables and send a beacon for the video start event as shown below. Please note that we need to do this for each rule we'll create for tracking video events.

The next two steps show what we need to populate in the "Adobe Analytics - Set Variables" and "Adobe Analytics - Send Beacon" actions. Please note that we've defined unique analytics events for each milestone event and an eVar to capture the video name.

Create Rules to track Video Milestones 25%, 50%, 75% Events: We now setup milestone events to track 25%, 50% and 75% complete video events which is a very common tracking requirement for videos. The screenshots below show how we set it up for 25% video complete event but the same steps need to be followed for 50% and 75% complete events where the 25% trigger needs to be replaced with 50% and 75% accordingly.

Create a Rule to capture Video Complete: The last step is to capture the video complete event that can be captured by choosing the "Media Ended" event type in the rule as shown below.

Validate the Video Events: We now test our setup by loading the video in a browser and filtering for "/b/ss" which is a filter we apply to test the Adobe Analytics image request. In the following screenshots, I've included analytics image request for video start, 25% complete and video complete events.

The very last step of the process is for us to validate the data in the Adobe Analytics UI. The following screenshot shows how the report will look like with all video events successfully setup.

Finally, I want to add a few caveats about my post as video tracking is generally very involved:

HTML5 is typically the easiest video player to implement analytics tracking on but other players like Brigtcove, YouTube or JW Player may not work with this approach as they are not directly part of the HTML like HTML5 is and typically require additional JavaScript code embedded in the player and page. For other players, it is recommended to use the Heartbeat or traditional video tracking methods.

My method fires the video start event when 1% of the video is completed so if a video is 10 minutes long, it may take 6 seconds to fire the start event. "Video Start" event type in Launch on the other hand, triggers a beacon every time a video is played which causes duplication of the start event.

There are many other attributes that are associated with video that are not tracked here. Some of them are Content type, Player name, Show/Episode name/Season (TV shows) or Ad related attributes tied to a campaign.

I hope you like this post but I'd like to know if you have alternative ways by which you track video players. As always, comments and feedback is welcome.

Product Management Insight