RSS 2.0
  • Home
  • About
  • MBA Guide
  • Print Ad Blog
  •  

    Estimating Demand Impact And Conversion Rates

    December 30th, 2008

    I was recently working on an interesting project where I was estimating the demand impact of a change that we had implemented to our site.  Without getting into the details, a change was made so that the customer would be less distracted during their shopping experience.  This then – hopefully – keeps the visitor more engaged with the site and if everything else goes well, they will then buy.

    The tricky part is that the likelihood to convert changes at different points on the site, though it is a bit difficult to get it.

    For example, if all a visitor sees is the homepage, they are going to convert at some percent.  Assume 10% for easy math.  If a visitor doesn’t bounce – meaning come to the site, see one page, and leave – say the percent to convert increases to 20%.  If the visitor then sees a product page they are now going to convert 30% of the time.  And finally if they enter the checkout process they will convert 40% of the time.  The point is that the level that the customer is at in the site changes the likelihood of conversion.

    This seems like it would be a very obvious thing, and to a certain extent it is.  The key component here is not that these differences exist and you know about them.  The key is taking that knowledge into account when making an estimate for demand impact of a change.

    If visitors have all of these different conversion points and a change is made that causes 1,000 visitors to not leave the site you need to take these conversion points into account.  Saying that the 100 more people will buy (using 1,000 visitors * 10 % conversion from homepage) is just as misleading as saying that 400 people will buy (using 1,000 visitors * 40% conversion rate from checkout pages).  When making a demand impact, make sure that you include a few inputs for these different areas.

    For example: 100 visitors * 10% + 300 * 20% + etc.  As long as the percents add up to 100% and the visitors add up to your total you are in good shape.  You can then take this number times your average order value and you now have a demand estimate.  Note that you could even take this a step more and apply a different average order value to people who have been in different areas of the site.  For instance someone who is shopping for Outerwear or A laptop will probably have a different average order value then an individual looking at flip-flops or computer cables.

    Ultimately you can segment this to any level that you are able to get.  Just make sure that the work that you put into arriving at the final number is worth it – especially if you are using the Omniture Excel Client.  Make a judgement call.  If it is just going to be small dollars or you really just need a ballpark then take the 1,000 visitors * 25% or something like that.  It is a guess, but it should be an educated guess.  Each different analysis will require varying levles of confidence.

    Have you done anything like this before?  How did it go?

    This has been a Thought From The Cake Scraps.



    You Are Being Tracked: Product Page Finding Methods

    October 13th, 2008

    More often than not if you are somewhere you know how you got there.  Hopefully you don’t have too many weeknights (weekends I will exclude) where you just wake up and have no idea how you got to where you are.  You may be smart enough to know how you arrived at a particular location, but your website – at least by default – is not.

    This post covers the principle of having a Product Page Finding Method (PPFM) tag on your site.  If your site was successful in getting a visitor to a product page, you should really know how they got there.  And if you are a visitor you should know that this is one more way you are being tracked.  For more information on being tracked check out my posts on Internal Campaigns and E-Mail tracking.  I will point out now that this post is less about describing to a visitor how they are being tracked and more about how a website should track the visitor.  This is because a PPFM tag is less common and may not apply to many sites a visitor may go to.  Nevertheless, it is still something to keep an eye out for.

    Back to tracking how a visitor got to a product page.  The easy solution is a ‘Next Page’ or ‘Previous Page’ report.  This will tell you what pages a visitor was going to or coming from, respectively.  It may seem like the answer to our question of how the visitor arrived at a product page, and it does at a simplistic level, but is of no use for aggregating data.  Consider an index page that lists all of a companies laptops.  How often does a customer click through to an individual laptop (a product page)?  There is no easy answer to this if you have more than a few laptops displayed.  A PPFM tag will solve this problem.

    If you add a PPFM – that’s Product Page Finding Method – tag to each link on the index page then when the visitor clicks through to a product page you can tell Omniture to look for PPFM=INDEX_Laptops01 and it will store it to an e.var ( a commerce variable).   Then you can run a report in Omniture and look for instances of INDEX_Laptops01.  Compare that to the Page Views for your laptop index page and you have the rate at which a person is clicking form that index page to a product page.

    Another trick is to make sure that all of your index pages are tagged and have INDEX in the PPFM tag.  That way you can actually do a search to pull back all instances of an index page click on any index page.  With any luck you have your pages named in a similar fashion – so you can get total index page views – and you can then get a site-wide rate that people are clicking though to your products from your index pages.

    Now that we understand the concept of a PPFM, lets look at a few other uses for it.

    Basically, you should not have an instance where a customer navigated to a product page and you do not know how they got there.  Other ways they could get to that product page include a ‘direct to product page’ search and a cross-sell placement from another product page.

    The ‘direct to product page’ is useful if you have a search box that will allow a customer to go directly to a product page without going through an index page.  An additional way to tag this would be to have a search results tag – for instances when a search returns many products – and then any click from that index/search page to a product page would give credit to the search tag.

    The cross-sell tag would be used on any product page where you are displaying some other products the customer might also like to buy.  Any click on these links will bring the customer to another product page and then the cross-sell tag would get credit.  You might also have a similar tag for items displayed in the cart.

    The last thing to discuss is credit.  On a $100 order who gets the credit.  The simple way to do it is the last used tag.  The bad part is that with this method if a customer uses and index for the first 3 items and the last item they clicked a cross-sell item, the cross-sell tag will get all of the $100 attributed to it.  That isn’t really accurate.  The better way is to distribute the $100 via linear attribution.  That means that in the example above each of the index pages would get $25 and the cross-sell would get $25.  The tricky part here is that if a customer is browsing they may click to 10 different products from 10 different index pages and each of the index pages would get 1/10 a share of the revenue even though the customer only bought from one of the index pages.  Just something to keep in mind.

      With this tagging in place on your site you should always be able to answer how a customer arrived at your products.  It does not quite answer the question on a page by page basis – i.e. for Product A the PPFM tags used to arrive there were cross-sell 24%, indes 53% etc. – but it will give you a much better idea, on the whole, how your visitor is getting to your product pages.  Just a little tip that can save a ton of work

      This has been some Thoughts From The Cake Scraps.


      If Only It Were Bigger…

      August 26th, 2008

      I get all sorts of spam in my e-mail about making things bigger, but none of them are for the one thing I really want bigger: the interface for Omniture Excel Client.

      It took me some time to get used to the Excel Client that Omniture offers.  Mostly it was because I was not sure what reports I needed or how I wanted the data.  That makes looking for an easy way to get the data difficult.  After a few weeks working with Omniture I was comfortable enough to begin using Omniture Excel Client (OEC) on a regular basis.  Life is filled with peaks and valleys from there on out.

      Because the interface is connecting to Omniture it is inherently slow to do pretty much anything.  Now it is not horrible (most of the time) but when working in Excel changes are instant – think changing the font – and working in this slower interface takes some getting used to.  I will dedicate some future post to the issues and gleeful moments I have with the OEC but for now lets get back to the size issue.

      OEC does not allow you to re-size the interface that you are working in.  So, for instance, if I am using the “Pages” or “Most Popular Pages” report and I see a list of page names, part of the names get cut off.  There is no side scrolling option to be found.  You just have to sit there and wonder what the full page name really is.  I will point out that this may not be an issue for lots of people, but if your site is large enough page names can get pretty long.  Also, I am a fan of descriptive page names so that when you see just the page name it is informative.  Names such as “Brand” “Item” “Size” or “Gender” “Size” “Shirt Type” are much better than a product number for page names.

      So the real question here is why is the interface of OEC set up this way?  Did they not do QA testing on this?  I don’t have the answers.  All I know is that adding a side scrolling bar – not my favorite option but better than nothing – cannot be all that difficult to add into the interface.  Never mind that this issue persists in the newest version of OEC. Long page names are a reality and while you can use the search or advanced search to narrow your results it is a pain to have to do. Plus, OEC doesn’t save your advanced search so if you get results and need to edit it – such as exclude an additional word or phrase – be prepared to re-enter the entire search. Lots of NOT fun here too.

      I am not sure what it will take for Omniture to fix this.  Apparently they have not got the notice that size matters.