What to action on in a Page that changed

A page is very important in e-tail. It is not any other webpage. The more the visits to a page, the more important it is in the purchase path - and the higher is the impact that can be delivered.

No wonder merchandising teams are trying out different versions of the page. These are usually based on intuition & experience. It is the job of the analytics teams to work with the merchandising teams to ensure these decisions are based on data.
Unfortunately analytics role today in the world of simple web tools is just about providing visits and leakage information for the page OR running a simple A/B test (resulting in 2.5% upside which when annualized becomes a big number). The role of analytics should be much more than analyzing upside and annualizing the results of the A/B tests. Analytics should be able to get back and say what drove the upside/downside. I am presenting an approach that will help the same.

1. Starting Point: Make a list of levers that the merchandising teams have in changing the page
The levers fall into 2 broad buckets
a. Layout Changes
What changed in the layout? Some sample list could be
i. Rotating Banner instead of a static one OR position of Banner Changed
ii. New Links added, Old links removed
iii. Links rearrranged etc.

b. Feature Changes:
i. Page links to a page with a new feature

Step 2a: Create a segment to isolate the entries to the page
Step 2b: Create separate segments to isolate next clicks to pages from the page X
This is where it is imperative that you have a real web analytics tool at hand. You cannot do this in basic tools like SiteCatalyst or CoreMetrics or Discover. You need Insight/Visual Sciences

Step 3: Repeat Step 2 for the page 'before' and 'after' if you are doing an anachronistic analysis or repeat for the versions of the page being tested

Step 4: Tabulate as follows:


Cursory look reveals that for all landings on the page,
* Overall conversion of page improved
* Next clicks were fairly similar
* Bounces were little reduced
* Newly added Page E doing well
* Page A with changed features doing well

Now this can be translated as per our step 1 framework as follows:

Clearly upside in conversion is coming from the new Page E visits, from changed features on Page A & increased visits to Page A that has higher conversion. So business knows what improved

Advantages of my method.

1. Upside might not be coming from the changes to Page X that is being tested but rather because it leads to page Y with a new feature.
In such cases, my method captures the source of the changes
2. In cases where the page does not work, the merchandising & Design teams know what exactly to go and fix

If you need the raw xls for the analysis or help in how to set these things up in a web analytics tool like Insight, get in touch with me at rkirana@gmail.com

Getting the $ from folks that come to Support Site

'How to get folks to buy more' is every marketer's problem.
Getting support folks to buy is the latest buzz in both offline and online contexts. In the offline world, when somebody calls in, the rep tries to sell -
Hey! you need more RAM OR your HDD is close to full - increase capacity OR there is a brand new processor that your motherboard supports
This is not tried on everybody - An experienced rep can make out who to sell and who not to - who to pitch and who not to

How do we replicate the same in the online world?
First step is to find out 'as-is' i.e. how much $ do I make out of the support site today? This is in the online context presents some problems.

Complexity 1: I came to the support site to check my order status :)
Online world presents a unique complexity because after making a purchase on any e-commerce site like Amazon, folks tend to visit the support site to check order status. These are not folks that are getting us revenue $ from the support site.
They have to be excluded

Complexity 2: X landed on support site while Y navigated to support site from purchase site. X and Y are different

The behavior of the folks that land on a support site and path over to the e-commerce site is very different from folks that navigate to the support site and then went over to the purchase site
Both of these have to be treated as separate segments

Complexity 3: I came to check my order status after purchasing from the support site :)

Visitors that bought from a link to purchase site from the support site may actually come back to the support site to check their orders.They should not be excluded



Here is my stepwise approach to solving this problem
Step 1: Separate segments for Landings and Non-Landings
Create 2 segments of visits:
a) Those that land on support site - call as X
b) Those that did not land on support site - call as Y
X and Y are mutually exclusive


Step 2: For X, the bucket that landed on the on the support site and buy in the same visit
The $ that results from these folks is the purchases that they made on the support site. Call this $A

Step 3: For Y, the bucket that did not land on the support site
Step 3a: Visit Segment of folks that made a purchase and checked order status. Call this M
Step 3b: Visit Segment of folks that made a purchase and did not check order status. Call this N
Step 3c: Visit Segment of folks that visited support before before the e-comm site. Call this P.
Now N intersection P -> Count the revenue for these folks. Call it $B
Step 3d: Visit Segment of folks that visited support and went to e-comm site before returning to the support site. Call this Q
Now revenue for Q intersection M is $C

Total Revenue is $A + $B + $C.
More on how to improve revenue for these folks in one of the subsequent posts.

If you need help in how to set these things up in a web analytics tool like Insight, feel free to drop a mail at rkirana@gmail.com