Wednesday, December 23, 2009

Widget Analytics in Omniture – Part 2 of 3

National Geographic Photo of the Day Widget

In part one of this article, “Widget Analytics in Omniture – Part 1 of 3”, I discussed widgets, how they are used by Business, and the metrics used to track business goals. In this section will outline how to implement those metrics in Omniture.

Widgets are usually intended to support branding, reach, and acquisition. So widget metrics are for the most part campaign metrics, not much different than those used for emails, banner ads, or your direct mail promotion. And like other campaign metrics, you need to track activity on sites other than your own.

Again, here are the metrics we want to get:

Metric
1. Reach by widget (count of domains)
2. Which domains have placed the widget?
3. Widget placements per domain
4. Which domains have distributed the most widgets?
5. Specific places the widget was placed.
6. Acquisition by site (UU per domain where user clicked or interacted with the widget)
7. Repeat use for a Widget (user must have clicked or interacted) across all domains
8. Impressions for a widget across all domains
9. Impressions for a widget per domain
10. Unique user presentations for a widget across all domains
11. Unique user presentations for a widget per domain
12. Count of clicks (or whatever you deem an interaction) to a widget across all domains
13. Count of clicks to a widget per domains
14. Count of clicks to a given link in a widget.
15. CTR of a widget across all domains
16. CTR of a widget per domain
17. Site activity driven by a given widget

Implementation Approach

The implementation will require getting information on “clicks” and “impressions” for the widget overall and by domain. In addition to the hosting domain, we will want to know the specific pages the widget is on. We will need the Page View, Visit, and Monthly Unique Visitors metrics. To track the users that the widget drives back to your site, we will use a tracking code.

Here is a detailed list of each metric with the implementation approach:

Metric Approach
1. Reach by widget (count of domains)Pass a variation of the widget name for impressions and the domain for the third party page into variable 2. Use the page view metric.
2. Which domains have placed the widget?Pass a variation of the widget name for impressions and the domain for the third party page into variable 2.
3. Widget placements per domainA given domain may place the widget on many pages. Pass the URL for the third party page into variable 5. Correlate the widget name in variable 1 to the host page name in variable 5 then add the number of pages.
4. Which domains have distributed the most widgets?Set up the distribution to that it is always initiated by a click on a link in the widget. Use this click as a proxy for grabbing the widget. Get the counts per domain in variable 4. Use the page view metric.
5. Specific places the widget was placed. Pass the URL for the third party page into variable 5.
6. Acquisition by site (UU per domain where user clicked or interacted with the widget)Pass the widget name and the domain for the third party page into variable 2. Use the monthly unique visitors metric.
7. Repeat use for a Widget (user must have clicked or interacted) across all domains Pass the widget name into variable 1. Use the visit and monthly unique visitors metrics.
8. Impressions for a widget across all domainsPass the widget name + impression identifier for impressions into variable 1. Use the page view metric.
9. Impressions for a widget per domain Pass a variation of the widget name for impressions and the domain for the third party page into variable 2. Use the page view metric.
10. Unique user presentations for a widget across all domainsPass a variation of the widget name for impressions into variable 1. Use the monthly unique visitors metric.
11. Unique user presentations for a widget per domain Pass a variation of the widget name for impressions and the domain for the third party page into variable 2. Use the monthly unique visitors metric.
12. Count of clicks (or whatever you deem an interaction) to a widget across all domainsPass the widget name into variable 1. Use the page view metric.
13. Count of clicks to a widget per domainsPass the widget name and the domain into variable 2. Use the page view metric.
14. Count of clicks to a given link in a widget. Pass the widget name and the linkID into variable 3. Use the page view metric.
15. CTR of a widget across all domains Pass a variation of the widget name for impressions into variable 1. Use the page view metric as the denominator. Pass the widget name into variable 1. Use the page view metric as the numerator.
16. CTR of a widget per domainPass a variation of the widget name for impressions and the domain for the third party page into variable 2. Use the page view metric as the denominator. Pass the widget name and the domain for the third party page into variable 2. Use the page view metric as the numerator.
17. Site activity driven by a given widget For each link that needs to be tracked to its destination, pass a tracking code in the destination URL query string. This is recorded in the Campaign variable.

Implementation

The Omniture set up is straight forward. As in any other tag based tracking you will need a beacon. You will need to set up some variables to record the clicks, impressions, domains, and page names. You will need to configure the s-campaign variable to look for your tracking code.

Beacon

To pass this information the widget will need to call a beacon that can pass the information to Omniture. For html based widgets the beacon call is part of the code. For mobile widgets you will likely use the Omniture Action Script and it will be part of the flash file. For compiled applications, access to the beacon or the beacon itself will be built into the code.

Clicks, Impressions, Domains, and Page Names

You will need five variables to contain the following:

  1. Widget Name
  2. Domain + Widget Name
  3. Widget Name + Link ID
  4. Domain + Widget Name + Link ID
  5. Host page name (url)

Using an OnClick event, you will pass your beacon the name of the widget (or a widget ID) and an identifier for the link that was clicked. You will need to have your developers write some additional code to grab the host page name and then from that derive the host site’s domain.

  • [domain]_[widgetID]_[linkID]

Some more code will parse the values into the 5 variables. These will be sent in a single Custom Link call (not as a Page View). Alternatively, you can create an Omniture Vista Rule to parse the values into the 5 variables. You will need to use a consistent separator for the values in order for the parsing to work. In the example above, I have used an underscore. You could use any character so long as the character will only appear in the value as a separator.

For impressions, every time your widget is displayed, pass a value for the impression. The value should be the Widget name with an added modifier to identify it as an impression. For example, [widgetID]-imp. In this case there will be no linkID or you could pass a linkID of “imp” in addition to the “imp” passed as part of the Widget Name.

For the [widgetID]_[linkID] values, every link in the widget will pass the same WidgetID but different link identifiers. For example, if the widget is called “ticker” and there are three links in the widget, the values for the OnClick event would be:

  1. ticker_1
  2. ticker_2
  3. ticker_3

Because Omniture can only accept a 100 character string, you may need to pay attention to the number of characters you allow for the Widget Name and Link ID. It depends on how verbose the naming tends to be at your company.

For the Host page, pass the URL of the page into a variable. The temptation will be to pass this into the Page Name variable. However, in most cases, you will want to use a different variable. I will discuss this more when we consider report suites set up.

You will also need to set up a correlation between the widget name and the host page name.

Tracking Codes

Tracking codes will use a 6th variable. This will likely be the Campaign variable that is pre-defined in Omniture.

Omniture has a beacon plug-in for just this purpose. You list the value of your tracking parameter in the plug in and Omniture will grab the value of that parameter and put it into the variable. For example, if you have chosen to use “cid” as the parameter and “wgt_ticker” to identify your widget, the link might look like:

  • http://www.webmd.com?cid=wgt_ticker

You will use the query string for all your Widget’s links that drive to your site or another destination you want to track. Use the same tracking code for all the links in the widget that need to be tracked to the destination.

This chart outlines the implementation above by variable:

Omniture Field Name Business Name Implementation
s_accountAccount IDThis is the name of your Omniture report suite
Prop1Widget NamePass the [widget-name]
Prop2Domain + Widget NamePass the [domain name of the host page]_[widget-name]
Prop3Widget Name + Link IDPass the [widget-name]_[link id]
Prop4Domain + Widget Name + Link IDPass the [domain name of the host page]_[widget-name]_[link id]
Prop5Widget Host Page NamePass the [URL of the host page]
Prop6Report SuiteIf you use multi-suite tagging, you will need to pass the value for the destination Omniture report suite. If you don’t, this is not needed.
s_campaignTracking CodeSet up Omniture to look for your tracking code parameter. For example “cid”. Add the value for that parameter into the link href in the widget.

One thing to consider is whether to put this tracking in your regular report suite or put it in its own report suite. While these can be custom link calls and do not have to be counted as a page view, they will count as visits and visitors. If you are wildly successful, this will affect your site calculations for Page Consumption and Repeat Use. While widgets are your content, one could argue that the activity does not take place on your site and should not be counted as if it did.

Extra Credit

The above implementation uses custom link calls and various “prop” variables. For reporting, you will need to do a simple calculation to get the CTR metrics discussed above.

However, it has been suggested that if the same approach were done using Omniture “evars” instead of props, this CTR calculation can also be automated. Note that I have not tried this myself yet. With that disclaimer, I pass the thought along.

In addition to passing the values as outlined above into evars instead of props, pass a success event along with each impression. Pass a second success event along with each click. You can then create a calculated metric using the two custom event counters and view the calculation for each widget and each domain the widget is on.

Lastly…

One thing to keep in mind is that these are custom link calls and for most contracts (so far as I know), there is a cost for each call. Be mindful that you are tracking impressions and clicks in a viral situation that can rapidly expand the number of those calls and therefore your costs.

The same general approach used for Omniture can be translated for use in other analytics tools such as Unica or Web Trends. Of course this is not the only approach I have seen nor is it the only approach one can use in Omniture. What is best for you will depend on the metrics you need.

In part three of this article, I will go through how these metrics are pulled from Omniture and what those reports might look like.

Labels: , , , , , ,

0 Comments:

Post a Comment

Links to this post:

Create a Link

<< Home