This might sound like an inconceivable scenario: having a customer buy a widget, and then within the same visit, having the same customer buy another widget. I am actually quite happy to say that this happens more often than you would think, and to an extent where Yahoo! Web Analytics has developed instrumentation to take advantage of it.

If you track multiple sales on the same page during the same visit, you have to make sure that your ORDERID is unique. If your ORDERID value is fixed, you need to remove the variable altogether as it will otherwise not be recorded by the second sale action.

Keep in mind that this is closely connected to your choices and attitudes regarding how to count conversions in one visit (two sales or just one?). I will explore the topic of visitor conversion count methodology later in this chapter. But as a quick note, if you configure the sale actions on the page with multiple sale actions as Unique, then the reporting interface will display the number of unique sale actions in all the conversion reports. The only exception is the Conversion Summary report, which displays the total number of actions and the number of unique actions.

If you configure the sale actions on the page with multiple sales as not Unique, then the reporting interface will display the total number of sale actions in all the conversion reports. This will increase your conversion rate—not that this is bad, you should just be fully aware of what kind of numbers you are looking at. Therefore, in order to avoid this, I strongly suggest that you always configure the sale action as Unique if you have pages with multiple sales.

Now we are ready to move beyond just looking at the visit as a whole, as we've been doing, and into tracking multiple occurrences of the same action on the same page, whether a fixed or a custom action. Once you need to track multiple occurrences of the same action on a web page, you are required to move beyond the fixed tracking script introduced in Chapter 1. You are required to set up a tracking script object—which is super exciting, as you are now able to splash the code around the page as you want. And please take a mental note, as this is down the same alley as tracking more advanced Ajax elements, which we will talk about later in Chapter 5, "Advanced Instrumentation."

Let me show a quick example of how to set up the tracking script object and how to call it. The tracking script function created next, also sometimes called a wrapper function, is completely unique to your site and can be constructed any way you want. So our focus is on tracking multiple occurrences of the same action on the same page (applying two variables wouldn't work):

Version 4

var ACTION='01';
var AMOUNT='USD100.00';
var ACTION='01';    - ERROR, you cannot use the same variable twice
var AMOUNT='USD50.00'- ERROR, you cannot use the same variable twice

So to have two sales, not just in the same visit but on the same page, you could create a wrapper function like this:

Version 4

<script language="Javascript">
function recordsale(orderid, amount) {
       var tracking_object = createITT();
       tracking_object.ACTION = '01';
       tracking_object.ORDERID = orderid;
       tracking_object.AMOUNT = amount;
       tracking_object.submit_action();
}
</script>

Version 5

<script language="Javascript">
function recordsale(orderid, amount) {
var YWATracker = YWA.getTracker("1000123xxxx");
       YWATracker.setAction("01");
       YWATracker.setOrderId(orderid);
       YWATracker.setAmount(amount);
       YWATracker.submit_action();
}
</script>

Here I've created the Version 4 tracking object by writing var tracking_object = createITT(); and then applying the variables needed. I've then executed the tracking script by submitting it: tracking_object.submit_action();. You can extend beyond the three variables I applied here.

Now you know how to create the tracking script object, but bear in mind that no tracking is done unless the function is called from the page itself, as in clicking a link and calling the wrapper function:

<a href='/thankyou.html' onclick='recordaction(23453,100)'>Buy</a>

Or you could choose to create a complete wrapper function including the values and call it once the customer confirms the buy (typically by clicking the Buy button). With this method, everything is included in the tracking script object and it would look like this:

Version 4

<script language="Javascript">
function recordsale(orderid, amount) {
       var tracking_object = createITT();
       tracking_object.ACTION = '01';
       tracking_object.ORDERID = orderid;
       tracking_object.AMOUNT = amount;
       tracking_object.submit_action();
}

recordsale ('orderid 1', 'USD100'),
recordsale ('orderid 2', 'USD50'),
</script>

Version 5

<script language="Javascript">
function recordsale(orderid, amount) {
var YWATracker = YWA.getTracker("1000123xxxx");
       YWATracker.setAction("01");
       YWATracker.setOrderId(orderid);
       YWATracker.setAmount(amount);
       YWATracker.submit_action();
}

recordsale ('orderid 1', 'USD100'),
recordsale ('orderid 2', 'USD50'),
</script>

Here you are forced to inflate the ORDERID and AMOUNT values into the two recordsale function calls in the end to use it correctly.

Finally we come to some less strict scenarios, such as the need to record both a sale action and a newsletter signup action on the same web page. This is very much a continuation of the tracking script object debate from the previous section. You could create a wrapper function that looks like this:

Version 4

<script language="Javascript">
function recordaction(actionnumber) {
       var tracking_object = createITT();
       tracking_object.ACTION = actionnumber;
       tracking_object.submit_action();
}
</script>

Version 5

<script language="Javascript">
function recordaction(actionnumber) {
var YWATracker = YWA.getTracker("1000123xxxx");
       YWATracker.setAction(action);
       YWATracker.submit_action();
}
</script>

The good news is that Yahoo! Web Analytics has a shortcut to do this as well. When you need to track multiple actions on the same web page, you can do so by simply adding multiple actions in one request. So the code for the previous example of recording both a sale and a newsletter signup on the same page could look like this:

Version 4

var ACTION="01;02";
var AMOUNT="USD100.00;";

Version 5

YWATracker.setAction("01;02");
YWATracker.setAmount("USD100.00;");

Let's see a more detailed example so you can truly understand the syntax. This example shows how to record a sale action of USD (United States dollars) 100, a newsletter signup, and finally a pending sale of USD 2.50:

Version 4

var ACTION="01;02;PENDING_SALE";
var AMOUNT="USD100.00;;USD2.50";

Version 5

YWATracker.setAction("01;02;PENDING_SALE");
YWATracker.setAmount("USD100.00;;USD2.50");

Whether you assign newsletter signup to action number 02 is up to you, and you might have a different action named for newsletter signup. As we debated in the initial section about tracking conversion actions, you can use the following variables multiple times in one request:

I know that we have not yet discussed merchandizing variables, such as _S_UNITS, but it is important to note that they will only refer to the very first action in the previous list.

When I say on-click, I am talking about the onclick event registered on your web page objects. This event registers when the object has been clicked and provides you with an opportunity to execute a desired action on that click, such as record it. This is again a continuation of the tracking script object discussion from the previous sections, and you would in fact be able to use the same wrapper function from previous examples for this scenario:

Version 4

<script language="Javascript">
function recordaction(actionnumber) {
       var tracking_object = createITT();
       tracking_object.ACTION = actionnumber;
       tracking_object.submit_action();
}
</script>

Version 5

<script language="Javascript">
function recordaction(actionnumber) {
var YWATracker = YWA.getTracker("1000123xxxx");
YWATracker.setAction(actionnumber);
YWATracker.submit_action();
}
</script>

You could apply that wrapper function as the positive action to take on the onclick event, such as:

<a href="/leadsignup" onclick="recordaction(7) ">Submit Form<>

Remember that the previous wrapper functions do not record anything unless called.

The clicked-on object can be anything from an image, form dropdown, form submit, or just an ordinary web link (a download link or an exit link as well). Yahoo! Web Analytics has a great shortcut for tracking on-clicks like this using something called the s_action function.

When you use the _s_action function, only an action is recorded and not both an action and a page view, which would be collecting poor data, as you will be recording dual-page views. Using the _s_action variable is a two-step procedure.

In step 1, make sure that before positive on-click actions are called, you activate the ACTION variable. In most cases the ACTION variable will be empty.

Version 4

<script language="Javascript">
var ACTION='';
</script>

I'll provide several examples for step 2, which I am sure you can mold into a lot of good uses on your web property.

Version 4

For Version 5, which is a whole lot more flexible, you just create a wrapper function, which you call from the onclick. The following example of clicking an image uses the wrapper from earlier:

Version 5

Visit my LinkedIN profile <a onclick="recordaction('01')" href="
 http://www.linkedin.com/in/dennismortensen" ><img src="/images/linkedinlogo.gif"></a>

Tracking downloads and tracking exit links sections are both done automatically by Yahoo! Web Analytics. However, there might be scenarios where you would want to collect this as distinctive actions instead, for further and more detailed analysis.

To track downloads as actions:

<a href=" http://visualrevenue.com/blog/PDF/
Best-Pratices-for-Online-Travel-and-Hospitality.pdf" onClick="ACTION='05'">

To track exit links as actions:

<a href="http://kaushik.net/avinash/" onClick="ACTION='09'">

As indicated multiple places in this chapter, once you set up an action you have to decide whether it should be treated as unique or not unique in the reporting interface.

The rationale behind providing you with a choice for how you want the actions summed up is that different types of actions require different attitudes on how to sum them up. Even for similar actions, different companies might have different and legitimate reasons for summing up differently.

Envision a scenario where you would want to track downloads of a PDF whitepaper as an action. Using the on-click code example from before:

<a href=" http://visualrevenue.com/blog/PDF/Best-
Pratices-for-Online-Travel-and-Hospitality.pdf" onClick="ACTION='05'">

I suggest that you track it as a unique action by selecting the Unique checkbox when naming your actions, as shown in Figure 2.10.

Unique means that, should a visitor choose to download the whitepaper three times in the same visit, the choice is only counted once. That seems good data quality; the visitor can only read it once.

Figure 2.10. Unique Actions Setting

Another scenario where you would want to track the action as unique might be a sales lead signup page, where once again, a lead is still just one lead, no matter how many times the visitor signs up.

You should configure an action as non-unique (by leaving the checkbox empty), if every time that a visitor performs the action in question, it is of unique value. A sale would be such a case, where a sale is something that has value every time a visitor performs the action. Another example could be a comment provided to a blog, where every new blog comment might have value and it should be summed up in the system with a number that equals the actual number of comments to the blog.

Please note that this is only a configuration of the reporting interface and does not affect the actual data collection. This means that if four actions have been collected, Yahoo! Web Analytics does indeed hold the four actions, but reports on them depending on your Unique setting, which could be 1, 2, 3, or 4.

Tracking revenue in multiple currencies is tremendously valuable and super easy to deploy. As we know, recording the revenue of a sale demands that you inflate the AMOUNT variable.

The AMOUNT variable can only be used together with the sale ACTION. In most cases the AMOUNT variable is not a fixed variable, simply due to the nature of the sales process; you do not know what the final sales sum is going to be beforehand.

To set the tracking currency, you simply place the three-letter currency abbreviation directly in front of the revenue amount (see Figure 2.11). A sale of 33.58 British pounds would look like this:

Version 4

var ACTION='01';
var AMOUNT='GBP33.58';

Version 5

YWATracker.setAction("01");
YWATracker.setAmount("GBP33.58");

Remember that just because you see the reporting in GBP, you did not have to collect the revenue in that particular currency.

Figure 2.11. Currency tracking example

Table 2.2 is a complete list of all the supported revenue tracking currencies.

When using a commerce system or basic shopping cart, the value is likely to be inflated into the tracking code dynamically. The following example shows a sample tracking script with the AMOUNT variable inflated with two local commerce system variables named ccode and saleamount. Any local variables are unique to your commerce system.

Version 4

var ACTION="01";
var AMOUNT="<%ccode%><%saleamount%>" //(could equal:: VAR AMOUNT="USD100.00");

Version 5

YWATracker.setAction("01");
YWATracker.setAmount("<%ccode%><%saleamount%>");

Be aware that even though your revenue is tracked in your desired currency, the currency property of the project might override this in the reporting interface. If you set your default currency for the project to USD, all your campaign figures, sales figures, and other revenue tied in figures are converted to this currency.

Yahoo! Web Analytics uses monthly average exchange rates to convert the currencies into the project default reporting currency. This is important to know when you're trying to align the numbers with offline numbers. This means that a quarterly revenue report is calculated by the three months sums by the average currency value for those three months. However, any reporting user with administrator rights can override the default reporting currency and select a specific reporting currency. You can change your default currency under Settings > Personal Setup.

Once you select a user-defined reporting currency, all your reports except the Sales Details report will be displayed in your chosen currency. The figures displayed in the user-defined reporting currency are calculated in the same way as the figures in the project default reporting currency: by multiplying the revenue numbers obtained in the tracking currency with the monthly average exchange rates.

The AMOUNT variable holds all the characteristics of variables in general and can therefore not be longer than 75 characters. You must not use non-ASCII characters in the variable name and refrain from using any of the following characters as part of the value:

' < > # & ; : ? - * ~ ' ' ) ( = % ! "

As a final note and as a tradition throughout the system, you have access to the raw data collected—which for this section means the initial currency of the sale, also known as the tracking currency, no matter what the reporting interface is set to. This is to be found in the Sales Details report.

You have seen ORDERID introduced on several occasions before this section, simply because it is so closely tied into the sale ACTION and the AMOUNT (revenue) variable.

As with the AMOUNT variable, ORDERID is simple to deploy. It provides you not only with the opportunity to put sale activity in order, but also with the ability to truly utilize your exported raw data and have this tied directly into your CRM system. But even beyond that, you are provided with other opportunities, such as multiple sales in one session.

Tracking the ORDERID variable for a commerce site is almost obligatory, as this can improve the accuracy of monitoring your sales in both systems, making sure that there are no duplicate orders captured during a visit. This also shows why ORDERID is heavily used by the Yahoo! support teams when troubleshooting issues with revenue and sales tracking in general.

Furthermore, if you become advanced enough to use the application programming interface (API), ORDERID is absolutely necessary as a key to that system.

As you can see in the next example, the ORDERID variable goes hand in hand with the sale ACTION from a technical point of view, and from a rational point of view, the AMOUNT variable.

Version 4

var ACTION='01';
var AMOUNT='USD19.95';
var ORDERID='10099801';

Version 5

YWATracker.setAction("01");
YWATracker.setAmount("USD19.95");
YWATracker.setOrderId("10099801");

I think this is my last time repeating the general note that an ORDERID variable must not be longer than 75 characters and that you must not use non-ASCII characters. In addition to that, do not use any of the following characters in the name:

' < > # & ; : ? - * ~ ' ' ) ( = % ! "

These and other non-ASCII characters may have a negative effect on the general tracking script and the way it operates.

Yahoo! Web Analytics has designed a feature that allows you to avoid passing on your revenue in clear text over the Internet, for those clients and situations that warrant such a decision. In most cases, though, having a sale of $19.95 would look like this example:

Version 4

var ACTION='01';
var AMOUNT='USD19.95';

Version 5

YWATracker.setAction("01");
YWATracker.setAmount("USD19.95");

The information was transferred freely over the Internet as part of the checkout process. Remember that just by looking at the figure in your browser, it has been sent from the web server to the client. However, there might be situations where your revenue is not public knowledge. Imagine a shopping comparison site, such as Kelkoo (shown in Figure 2.12), which provides a free service for all its users to compare prices on a given product.

Figure 2.12. Kelkoo comparison price listing for laptops

Figure 2.12 shows prices for Sony laptops, but that does not mean that Kelkoo sells any of these products. Their business model, like any other shopping comparison site, is to charge on the click-out to the retailer, quite similar to a paid search. Therefore, the revenue Kelkoo generates by having a visitor click a retailer and go to their site is indeed confidential information. It's the same as if I go to Google and search for digital cameras—I would not know what the true cost per click is on any of the text ads.

This is not the only scenario. Many businesses offer a free service to consumers, and revenue is generated as a business-to-business activity. Here you would simply not want to pass the revenue figures in plain text through the Yahoo! Web Analytics tracking code. This technique will also prevent robots and spiders alike from gathering competitive intelligence on your website's revenue, margins, or general agreements with affiliates.

Revenue encryption is not automatically applied to all accounts, and you would have to request that it be added through the Yahoo! support organization. You are required to provide at least one encryption key, an element that I will discuss in a moment. Once the Yahoo! Web Analytics team has applied this key to the data collection service, you are ready to submit revenue in encrypted form.

I know this explanation is going to be a bit hairy, but it is unfortunately the only way to achieve what we are looking for. The first thing you should be aware of is that Yahoo! Web Analytics currently only supports encryption in the industry-standard Advanced Encryption Standard (AES) in Cipher Feedback (CFB) mode.

The key length should be a minimum of 16 and a maximum of 32 characters, and it must be a multiple of 8. You may supply an arbitrary number of keys to be used during decryption, but you must select one for each given amount.

To recap, collecting a USD19.95 sale, I would apply the following variables:

Version 4

var ACTION='01';
var AMOUNT='USD19.95';

This is where the change is going to happen when we want to use revenue encryption. The first thing you have to do is start all AMOUNT variables with AES (which is case sensitive) and follow that by the key ID number. You are allowed to have up to 10 different keys. And finally, as the third part of the AMOUNT variable, apply a colon character (:) and the encrypted data. This should result in a variable looking like this:

Version 4

var ACTION='01';
var AMOUNT=
 "AES1:F8A0998CAAC1C58145828B4318EB341268300CE0AAECC55A7E9BCA59BD2
43905A58F0944570D78DCA39DF6A8E74C867D"

Version 5

YWATracker.setAction("01");
YWATracker.setAmount("AES1:F8A0998CAAC1C58145828B4318EB34126
8300CE0AAECC55A7E9BCA59BD243905A58F0944570D78DCA39DF6A8E74C867D");

Here's a direct installation manual-like example to get you started:

Here's a detailed Version 4 example, applying the steps outlined earlier:

Long-winded, yes? Worth it? In a situation where you would not want to disclose your revenue data, surely! Now on to something a bit more down to earth: setting up fixed funnels for analysis.