Let’s look at an example from the retail world today: the “thank you page” or order confirmation page.
For your friendly marketer, this is without doubt the most important page. When someone sees this page, they have just bought something, i.e. they have given your company money. This is likely very closely in line with the overall goals of your business, to put it mildly.
So let’s treat it properly and tag it up like there is no tomorrow.
Three things to note in that example:
- We are using the “purchase” event. This is a built-in success event with special meaning. It should be used for purchases or other transactions that involve money. In the reports, it will show up as the “Orders” metric, but it will also fuel the “Units” and “Revenue” metrics in conjunction with the
s.productsvariable allows you to specify what has been bought, how many of it, and for how much. It is actually more complex, see Adam Greco’s post on the products variable, but these three elements should really be there. You can put more than one product ID or SKU into the variable, separated with comma.
s.purchaseIDvariable should be set on every purchase. It is used by the system to deduplicate purchases. (Think about users saving the confirmation page to their machine, then looking at it later. Yes, they do that. And yes, it would track the purchase again if you did not set
s.products variable can take a lot more information, but we’ll leave that for later. The interesting bit for now is that, yes, you can use any event with the
s.products variable, but only in conjunction with the “purchase” event will most of the data be used.
Let’s look at another example: a visitor is looking at a page that shows a product. The tagging might look like this:
We are using a “prodview” event here, another built-in event.
Note that we are also using “event5” along with it. We call that one “Product View (custom)”. This is a general rule: for some of the built-in events, notable Page Views and “prodView”, you should add a custom event. Your friendly marketer will love you for it.
Note that the value in the
s.products variable is a lot simpler now — we only passed the product ID or SKU, nothing else. As we said above, the other values wouldn’t make sense here, because they are silently ignored with any event except “purchase”.
Between looking at a product and actually paying for it, visitors usually have to hop through some hoops: the basket and a checkout process. Let’s start with the basket.
The built-in events to be used with baskets are:
- “scAdd” — to be sent when products are being added to the basket,
- “scOpen” — to be sent when the first product is being added to the basket, i.e. the basket is “opened”,
- “scView” — to be sent when visitor looks at the basket, and
- “scRemove” — to be sent when something is removed from the basket. This is not used very often.
The “sc” in all of those stands for “shopping cart”.
Most retailers use “scAdd”, “scOpen” and “scView”. Very few use “scRemove”. It is good practice to set “scOpen” in the
s.doPlugins() method in the
There is an out-of-the-box event for when the visitor starts the checkout process: “scCheckout”. You can use it like so:
Note that again, we’re listing the product IDs or SKUs but no quantities or prices, because the system wouldn’t use them.
Even though there is only the “scCheckout” event, we don’t think tagging the checkout process is complete. Almost every checkout we know has more than one step, be that on multiple pages or a single one.
We strongly encourage you to tag the other steps as well using custom events!
If your checkout has 3 steps (Payment Info, Shipping Info, Final Ok) then you need “scCheckout” on the first and two custom events on the other two steps.
If you send the above events along with the
s.products variable when appropriate, your friendly marketer can run a pretty good analysis on a couple of things:
- She can build a funnel that tells her how people progressed through the steps: Visits (or Product Views) > Cart Adds > Checkouts (plus more checkout steps) > Purchases. This helps with understanding the order flow. Are there any steps that make people give up?
- She can report a list of products with these metrics. She can order them by any of the metrics to see which ones are looked at most often versus actually purchased.
- She can create calculated metrics like “View to Purchase Conversion Rate” or “Basket to Purchase Conversion Rate” to further analyse product popularity.
- She can subrelate products and campaigns to see click-through and conversion rate for her campaigns.
The good thing in retail is that transactions happen online. The reporting shows transactions and money, which is what most businesses ultimately care about. It makes it somewhat easy to see what should be done, what should be tracked and whether any changes made have a positive or negative effect.
If you want to go further, you need to add two things into the mix:
- The cost — you are tracking revenue above, not gains. Adding cost of goods to the analytics will allow the marketer to also take into account margin.
- Returns — people send stuff back. If you want to completely understand your business, you need to take that into account.
Both of these can be done with Adobe Analytics, and we’ll write about how to do them later.