Every e-commerce web site has one or more “processes” – sequential steps the user has to go through, to accomplish a goal. The most important process for most e-businesses is the “checkout” process (aka the “purchase” process). In this post, we will create discuss how to create events that track processes, and discuss the characteristics you should build into these events.
At the fundamental level, a client sends a request, and the server sends back a response (view). You should create two process events for each step, one to recognize and count the request, and another that recognizes the response. When tealeaf recognizes a request event, you know the user actively asked for the next step of the process, and when tealeaf recognizes the response, you know the system presented the information to the user. In my post V8 Event Naming Conventions I discuss how to create event names that reflect this difference. The request event can be based on the URL of the page, and the view event is best based on a unique pattern present in the response when the page is successfully rendered.
However, before we go much further, there are major differences between Apache/IIS/ColdFusion server technology when it comes to how the technology uses the URL, and this difference makes a huge difference in how the Request for a step is recognized. <Insert moew on rthis>
Now that we are all using the same event names to mean the same logical view of the steps regardless of our site’s technology, onward!
Conceptually, a simple checkout process is “Cart View”, “Billing Info”, “Final review” and Confirmation. This produces and eight step checkout processes
Process Step Events for Every Step
The eight steps that measure every step occurrence are P:CartViewR:E, P:CartViewV:E, P:BillingInfoR:E, P:BillingInfoV:E, P:FinalReviewR:E, P:FinalReviewV:E, P:ConfirmationR:E, and P:ConfirmationV:E. When we create the events, base the R events on the URL of the page, and V events on the page title or some other string in the response that positively and uniquely identifies the page. Set the event type as ‘count”, evaluate on every hit, and do not add any report group yet.
These events tell us how many times each process step occurs, even if they occur multiple times in a session.
Session Events for Each Step of the Process
The eight Session steps that measure “the session had one or more occurrences of a process step” are named P:CartViewR:S, P:CartViewV:S, P:BillingInfoR:S, P:BillingInfoV:S, P:FinalReviewR:S, P:FinalReviewV:S, P:ConfirmationR:S, and P:ConfirmationV:S. Create each of these based on the presence of the corresponding :E event being in the session. Set the event type as ‘count”, evaluate at the end of the session, and do not add any report group yet.
These events tell us how many visitors got to each step of the checkout process during their sessions.
Pyramiding the Session Events
Now string the process steps together by creating the following events. It’s easy to see why they are called pyramiding events. Event type is count, evaluate at the end of the session, and no report group. These tell us how many visitors saw each step, and did not miss a step. They are the most accurate source of information for conversion ratios, and will be used for error detection as well, as will be shown later.
P:Step1R:S - P:CartViewR:S
P:Step1R&1V:S - P:CartViewR:S AND P:CartViewV:S
P:Step1R&1V&2R:S - P:CartViewR:S AND P:CartViewV:S AND P:BillingInfoR:S
P:Step1R&1V&2R&2V:S -
P:Step1R&1V&2R&2V&3R:S -
P:Step1R&1V&2R&2V&3R&3V:S -
P:Step1R&1V&2R&2V&3R&3V:S -
P:Step1R&1V&2R&2V&3R&3V&4R:S -
P:Step1R&1V&2R&2V&3R&3V&4R&4V:S - P:CartViewR:S AND P:CartViewV:S AND P:BillingInfoR:S AND P:BillingInfoV:S AND P:FinalReviewR:S AND P:FinalReviewV:S AND P:ConfirmationR:S AND P:ConfirmationV:S
Simple Count and Conversion Ratio Reports:
It is straightforward to create reports that show the counts for each event, and the ratio between any two of them. You can generate step-step ratios, or ratios from first step to any subsequent step, including confirmation.
In the chart examples throughout this post, the site had a seven-step process, so the pictures do not “quite” match up to the events described in the post. I wanted to use a very short hypothetical process for the text, to keep the post focused on core concepts. I trust you will not have any problem making the correlation and bridging the discrepancies between the charts and the text.
Pyramid Event Counts
Pyramid Event Ratios
Dimensions and Report Groups
How can we “slice” these numbers to get focused information? By using Dimensions and Report Groups! Lets examine the possibilities.
Things that are unchanged throughout the session (on the site I’m using for this post) include the AKAMI Country Code and the Session’s First Hit Referrer Domain
Things that may change at any time in the session include the Point Of Sale (POS) which the user can control (it changes the language) and is found in each response, the Currency of the purchase (which is based on the country in which the credit card is issued), and is always present in the CartView response, and the AmountList, which is a grouping, or “bucketing” of the cart’s sale amount. Another item that changes (but usually only once) is the customer’s loyalty program level if they sign-in.
Now, if we want to know the event counts for each country as reported by Akamai, we add a report group to each event that consists of a dimension that is populated by an event that fires on the first hit of the session and whose value is the value of the Akamai Country Code in a http header. Then in the report builder, we can drag the FirstSeenAkamaiCountryCode:E-F dimension to the chart of event counts, and filter on the top five. This groups the events by the country code that was seen on the first request of the session, and tells us which country has the highest number of visits to each step. Do this on the chart of conversion ratios, and it tells us which country has the highest (or lowest) conversion ratios
Now, if we want to know the event counts for referring domain, we add a report group to each event that consists of a dimension that is populated by an event that fires on the first hit of the session and whose value is the value of the domain portion of the HTTP_REFERRER. Then in the report builder, we can drag the DomainSessionReferrer:E-F dimension to the chart of event counts, and filter on the top five. This groups the events by the domain of the referrer that was seen on the first request of the session, and tells us which referrer has the highest number of visits to each step. Do this on the chart of conversion ratios, and it tells us which referrer has the highest (or lowest) conversion ratios.
If we want to know the event counts by POS, we add a report group to each event that consists of a dimension that is populated by an event that extracts (from every hit) the POS from the response, and in the report builder we can drag the POS:E-L dimension to the chart, and filter on the top five. This groups the step events by the POS that was last seen in the session. It is important to note that the POS can change after the last step of the process. The pyramid events are session events, and are evaluated at the end of the session. The value of POS stored in the report group for the pyramid events will be whatever POS was last seen in the last hit of the session.
Two-Dimensional Report Group
When the site is multi-currency, you cannot add the amounts of orders together. Adding Yen to Yuan to Reals to Peso to dollars makes no sense. It is important to consider both the amount and the currency together as a two-part object. We can accomplish this with a report group having two dimensions, Currency:E-L and AmountList:E-L. Populating these dimensions can be done with an advanced mode event. The details are beyond the scope of this already-too-long post, but can be found here. <insert>
Now in the report builder we can drag the Currency:E-L and the AmountList:E-L dimensions to the chart. We lose the graphical representation, but the tabular data shows which currency and amount buckets are the best performing. (I have no idea why there are [Null] entries – looks like I’ve got some troubleshooting to do :-)
Multi-dimension Report Groups
For fine-grained analysis, create report groups of multiple dimensions (up to four dimensions). For example, a report group consisting of the dimensions POS:E-L/LoyaltyStatus:E-L/DomainSessionReferrer:E-F lets us investigate the relationships between these three constraints on the purchase process events.
<insert>
Other dimensions you may want to consider adding are TrafficTypeE-F,BrowserType:-F,BrowserVersion:E-F,SessionDurationList:H
Make sure you look at the TrafficType:E-F dimensions or via searching, to see if there are robots getting to the first part of your process
What is “abandonment”
Abandonment is simply any session that has the first step of the checkout process,and not the last step. Use these two conditions to create a simple session event for P:Abandonment:S Since this means our customer left empty-handed, companies want to spend a fair amount of resources to investigate why this happens.What companies need are a way to quantify how much revenue is lost when an abandonment occurs. For this example, we will focus on the amount (and currency) that was in the last P:CartViewV:E of the session.
Extracting “loss” on an abandonment
Scraping off the amount and the currency from a response can be tough. The details are here <insert xref>.To summarize you need two advanced mode events (BB) with three regular expressions (RE). Both events use one same RE to recognize the entire class element that encloses the the currency and amount substrings. Each BB event uses one of the other two REs, to split the substrings out of the class element string. If you are lucky, the developers have repeated that pattern everywhere. If not, you may be looking at multiple Regular Expressions in these events.
Two dimensions are populated by these BB events StoreLastSeenRevenueCurrency:BB and StoreLastSeenRevenueAmount:BB, called RevenueCurrencyList:E-L and RevenueAmountList:E-L. The dimensions are populated with the “Last” value of the BB event, which itself fires on each occurrence of the event P:CartViewV:E.
The two dimensions can be combined into a single report group and attached to any checkout process event, but wait…. lets not waste a multi-dimension report group. The final report group we attach to abandon will have more dimensions…
The amount and currency that is being abandoned…
Extracting Error Messages
See <insertt xref here> for details. To populate the two dimensions x and Y, It takes two BB events with multiple Regular Expressions. These BB events look at a page for any class, span , or div pattern that contains the error class element, extract either the language-specific error message or the language independent error code, repeats down the whole page view, and aggregates these one or more substrings into one large aggregate string.
You can attach these dimensions to a step event, but they will always have the last seen event value – even if the last seen error was two hits back. Instead, we create an event G:AnyVisibleFieldError:E, and attach the two dimensions to this event along with the URL (Normalized) dimension. This provides an event whose dimensions can tell us “what is the most common error” for any specific URL or groups of URLs. That’s pretty potent! If you attached just these to the P:Abandoned:S event, you would know what error messages were seen last most often when visitors abandoned. Again, lets not waste a multi-dimension report group..
Top Error messages…
To find out which error message was last seen most often and sort by revenue lost, create a report group with all four dimensionss we’ve discussed
a/b/c/d
Now chart the P:Abandoned:E event in the report builder to see the culmination of our efforts which error messages are seen for the largest amount of abandoned shopping carts, grouped by currency and amount list and errormessage (and errorcode)…
Throw in the revenue amount list to group these
The P:Abandoned Event
- Evaluate at End of Session
- Fires if teh session has a ProcessStart and NOT a ProcessEnd event
- Numeric Type of value
- Store the value amount shown at ProcessStart
- Report group contains RevenueCurency:E-L; RevenueAmount:E-L and AggregateVisibleFieldErrorMessage:E-L
I hope this has helped you understand process events, and given you some ideas for expanding your use of tehm.
No comments:
Post a Comment