Shipping, Discounts & Taxes [SiteCatalyst]

If you are an online retailer, it is likely that your orders that contain shipping, discounts and/or taxes. Over the years I have seen some good and bad ways to track shipping, discounts and taxes in SiteCatalyst so I thought I would share some tips that I have found helpful.

The Basics

To start, let’s talk about why you might want to track shipping, discounts and taxes in SiteCatalyst. If you sell products in retail stores and online, your customers have an opportunity cost associated with shipping. Customers can often save money by coming to your physical store to get a product, but there may be a convenience factor associated with having products shipped. By tracking the total shipping dollars associated with each product, it’s possible to see which products are commonly shipped and the associated dollars. You can also look at shipping dollars as a standalone metric to see if shipping dollars per order are going up or down over time. The same concept applies to product discounts. You may have co-workers who want to see which products have been discounted and the amounts of the discounts. Tax amounts tend to be less meaningful from a web analytics perspective, but I will demonstrate how to track them in case your organization needs to track them for some reason.

The general method of tracking shipping is to use a Currency Success Event to store the amount the visitor spends on Shipping and the Products variable to connect that shipping amount to the Product ID. This is done through the product string syntax and might look like this:

s.events="purchase,event30";

s.products=";111;1;400;event30=5"

In this case, you have a scenario in which a visitor has purchased one unit of product ID#111 for $400 and is paying $5 in shipping. The latter is stored in success event 30 and can be viewed trended or broken down by Product.

If you also want to track discounts associated with the purchase, you can dedicate another currency success event to discounts. Discounts would work the same way as shipping in that it would be set in the products string using another currency success event. If there was a $10 discount for the product shown above, the syntax might look like this:

s.events="purchase,event30,event31";

s.products=";111;1;400;event30=5|event31=10"

Tax amounts are tracked in a similar manner. The syntax you might use if the preceding order had a tax amount of $32 is as follows:

s.events="purchase,event30,event31,event32";

s.products=";111;1;400;event30=5|event31=10|event32=32"

When this is done, if the preceding order were the only one to take place on your website, you would end up with a report that looks like this:

As you can see, tracking shipping, discounts and taxes is not that difficult and only involves using three new currency success events and the products string. However, things can get a bit trickier as I will show in the next section.

Fake Products?

One strange thing I have seen over the years related to tracking shipping, discounts and taxes is treating these as separate products. I am not quite sure why companies do this, but I am not a fan of this approach. This method adds a fake product called “shipping” or “taxes” to each applicable order and attributes the full shipping or tax amount to these fake products. Here is what the syntax might look like:

s.events="purchase,event30";

s.products=";111;1;400,;shipping;;event30=5.5"

This results in a Products report that looks like this:

As you can see, all shipping dollars are associated with the fake product of “shipping” instead of the products that drove shipping.

This approach can also wreak havoc on reports that use the Orders metric, like Merchandising reports, which will often show greater than 100% due to these fake products. Here is an example:

If you break down the above report by Product, you can see that the culprits are these fake products:

For all of the above reasons, I am not a fan of this “fake product” approach.

Multiple Products

Tracking shipping, discounts and taxes gets more difficult when visitors purchase multiple products concurrently. For example, there may be cases in which a visitor purchases three products and two have a shipping cost or discount, but the third product does not. I have a feeling that the multiple product scenario is what causes people to implement the preceding “fake product” method, but I think this is a lazy approach.

The more precise way to track shipping and discounts for multiple products is to associate the exact dollar amounts for each to each of the products being purchased as shown in the first examples above. If multiple products are purchased and we cared about tracking shipping and discounts, the resulting syntax might look like this:

s.events="purchase,event30,event31";

s.products=";111;1;400;event30=5|event31=10,;222;1;200;event30=2|event31=5"

In this example, two products were purchased and each has its own shipping and discount amount, correctly lined with the the product that drove these amounts.

However, there may be cases in which you cannot identify the exact amounts by product. In this case, you have a few options. The first (and preferred) option is to proportionally allocate shipping/discount amount based upon the purchase prices. For example, if someone purchases three products of amounts equal to $250, $100 and $50 and the shipping is $40, you could assign shipping amounts of $25, $10, $5 respectively. The same proportional approach would apply to discounts and taxes. While this isn’t perfect, it may be the best that you can do without working with IT to get the exact amounts per product. It is also something that can be done with some fancy JavaScript so you don’t have to get time with your IT folks. Another approach I have seen used is to simply put all shipping into the product with the largest revenue amount, but this will make your shipping data pretty inaccurate.

To summarize, tracking shipping, discounts and taxes is something you should consider for your SiteCatalyst implementation if you sell products online. However, the approach you take may depend upon what data you can get from your IT folks. Hopefully this post help outline some of the choices you have so you can determine which approach is the best for you.