Archive for 'Uncategorized'
One of my newest clients is in a highly competitive business in which they sell similar products as other retailers. These days, many online retailers have a hunch that they are being “Amazon-ed,” which they define as visitors finding products on their website and then going to see if they can get it cheaper/faster on Amazon.com. This client was attempting to use time spent on page as a way to tell if/when visitors were leaving their site to go price shopping. Unfortunately, I am not a huge fan of time spent on page, since a page could have wide varieties of time spent on page due to many other reasons other than price shopping (i.e. working, going to the bathroom, yelling at kids-in my case, etc.). Because of this, I wanted to come up with an alternative way to see if price was a potential reason for lost business. However, before I share my idea, I want to add a disclaimer that there is no [legal] way to really know if people are leaving your site to buy something elsewhere due to price, but the technique I will show may shed some light on how pricing impacts your conversion rates.
Competitor Pricing – Step 1
The first part of my competitive pricing solution requires that for some or all of your products (SKU’s), you have detailed competitor pricing. Many of my clients have teams that are constantly monitoring competitive websites and documenting the current prices for some or all of their products. If your organization doesn’t have this, my solution will not work (so you can stop reading now!). If you do have this information, you will need to create a spreadsheet that has your product ID’s (values passed to the Products Variable) and your competitors’ price in the next column. If you have multiple competitors, you can add a new column for each one:
Next, you will have to talk with your Adobe Account Manager to create a new DB Vista Rule. As a refresher, a DB Vista Rule allows you to populate SiteCatalyst variables with values from a database lookup table stored on Adobe’s secure servers. This will allow you to pass in the competitor price for each product viewed and added to cart on your website via a server-side lookup. The Adobe Engineering Services team can walk you through how to upload the competitor prices to DB Vista and how to updated it over time. Keep in mind that you will need to have a process in place that updates competitors’ prices as they change, preferably within the hour so your data is accurate. This is often done by FTP’ing changes on an hourly basis. Creating a DB Vista Rule will cost you a one-time fee of a few thousand dollars, but that you can maintain it yourself thereafter. If you want to save some money, you can ask your internal developers if they can ping a similar competitor cost table in real-time as visitors are on your site, but in my experience, the work effort around that is much more than the cost of the DB Vista Rule.
Competitor Pricing – Step 2
Once you have a way to send competitor prices (by Product ID) into SiteCatalyst, where should it go? What I propose is that you pass the Product ID, your price and your competitors’ price, concatenated in a string to a new Conversion Variable (eVar). Since your visitors may view multiple products, you will also want to make this a Merchandising eVar using Product Syntax. I recommend that the data be passed when visitors view the product detail page or add a product to the shopping cart. For example, if a visitor views SKU # 10010100 and your price is $30.00 and your competitors’ price is $29.50, you would pass this:
In this case, the product ID is available on the page, as is your current price. The only data point you don’t have is your competitors’ price, which can be added to the string via the DB Vista Rule. This allows you to capture all of the key elements needed to do analysis. For example, if you add the Product Views success event to this new eVar report and filter for the above product ID, you will see all of the different pricing permutations between you and your competitor for the selected date range:
Next, you can add Cart Additions or Orders to the report to see how often each product converted with the given pricing spread:
In this fictitious example, you can see that Orders per Product View was up significantly when pricing was the same or better than the competitor for the product in question.
But there is even more information you can glean when we apply SAINT Classifications. For example, you can classify the product with just the pricing range difference to boil this data down to a finite number of rows in a way that is a tad easier to interpret:
Taking this concept one step further, you can apply another SAINT Classification that takes the Product ID out of the equation to see how the pricing spread impacts all products:
For those that really need things spelled out for them, you can use SAINT to create the highest level view of your pricing by boiling the data down to cases where you were higher, lower or the same with respect to pricing:
Obviously, the last few reports can still be viewed by Product by simply using the Products variable breakdown, but I think they show a good high-level view of pricing impact. Keep in mind that each of these rows can be trended over time in SiteCatalyst or ReportBuilder to see a long-term effect.
For those of you who like to kick things up a notch, you can also use the same DB Vista Rule to incorporate your product margin to the new eVar. If you upload your product costs to the DB Vista table, you can have the rule calculate the difference between your price and your cost and add the result as another parameter to the eVar. Then, via SAINT Classifications, you can split this out and see cases where your price is higher than your competitor broken down by your margin:
In this case, the product in question has a cost of $26.00 so the difference is passed as the last parameter to the eVar so we can include it in our analysis. This allows us to create new SAINT Classification where we can see Orders/Product View (or Cart Addition) for all products by the product margin amount:
Since all SAINT Classifications can be broken down by each other, this also allows us to see our conversion rates by price difference broken down by product margin amount:
Keep in mind that all SAINT Classifications are eligible for use in Segmentation, which means that you can now build a segment using pricing differential to competitors and product margin as criteria when doing web analysis! Also, if you want to learn how to add product costs as a new metric with which you can calculate product margin as a KPI, check out my old blog post from 2008 on how to do that.
As I stated early on, there is no way to make a direct connection between people looking at your site and then price shopping on another site, but my theory is that if you consistently under-perform when you are priced higher than your known competitor(s), this approach may give you some data to validate your theories. Obviously, there are other factors such as shipping, taxes, etc. that can have a major factor, but some of those can be included in this solution as well by simply adding additional parameters to the eVar shown above. Other ways to do similar competitive analysis include using Voice of Customer surveys to ask your visitors if they are price shopping, or moving all SiteCatalyst and competitive data into Adobe’s Data Workbench product. Either way, if you like the concept, you can give it a try or contact me if you want some assistance. If you have other ways to do this, feel free to leave a comment here. Thanks!
In working with a client recently, an interesting question arose around cart additions. This client wanted to know the order in which visitors were adding products to the shopping cart. Which products tended to be added first, second third, etc.? They also wanted to know which products were added after a specific product was added to the cart (i.e. if a visitor adds product A, what is the next product they tend to add?). Finally, they wondered which cart add product combinations most often lead to orders.
I had to admit that I was surprised that no one had asked me these questions in the past (a rarity for an old-timer like me!). However, I love getting new questions since it allows me to come up with cool ways to answer them. Therefore, in this post, I will share some of the ideas that I am proposing to this client in case your organization has similar questions.
Product Cart Order Sequence
To tackle the question of which products are added to the cart first, second, third, my first instinct was to try out the cool new sequential segmentation in Adobe Reports & Analytics (SiteCatalyst). This feature has been around in Ad Hoc Analysis (Discover) for a while, but is new to Adobe Reports and Analytics. However, the more I thought about this, the more I realized that sequential segmentation wouldn’t help very much. The only scenario in which I think it might help, is if you want to know exactly how often Product A was followed by Product B and then Product C and an order took place thereafter. If you know the sequence you are looking for, you can isolate it and look at any report (i.e. Visits, Orders) using sequential segmentation.
But my client is looking to do more exploration and find out which products are added first, second, third, etc. Therefore, my thoughts turned to my old friend Pathing. Pathing is a great way to see a sequence of anything happening on a website/app. In this case, the sequence I am looking to see is products added to cart. Therefore, a cool way to answer this question would be to create a new Traffic Variable (sProp) and pass the Product ID’s (or Names) of each product added to the shopping cart to the variable when a Cart Addition takes place. Once this is done, you can enable Pathing on this new “Products Added to Cart” sProp so you can see all of the available pathing reports. For example, you can open the Full Paths report to see the most popular product combinations added to the shopping cart. Obviously, the first batch of entries in this report will be cases with just one product added:
However, when you get deeper into the results, you will start to see multi-product combinations:
Of course, you can narrow these paths to a specific product in this report using the “Showing Paths containing” feature:
Or you could also use the next page flow report to see products added after a specific product (in this case an Exit means that no other products were added to the cart in the same visit):
Or you could see similar information using Pathfinder:
As you can see, by simply passing product ID’s (or names) to a new sProp, you can gain insight into which products are added the most and in which combinations.
If you have a Product Category SAINT Classifications for your Products variable, you can also see all of the above sports by Product Category in Discover (Ad Hoc Analysis) by using pathing on classifications. Or you could always pass in the Product Category to another sProp if it is known at the time as suggested in the comments by Jan Exner.
But What About Orders?
While the preceding concept may be interesting, it falls short of the original goal because it doesn’t show which of these cart addition sequences leads to orders. While you could segment on visits with an order and then look at the remaining paths, I prefer to visualize the actual paths and see exactly when the order took place. Therefore, to add this component, I suggest that you pass the phrase “order” to the same new traffic variable on the order confirmation page. By including this one new value, it will be included in the pathing reports and can be used in any of the reports above or the fall-out report. You can also use the previous page flow report beginning with the “order” value to see the most common cart addition product sequences (paths) that lead to success:
This is probably best done in Ad Hoc Analysis (Discover) where you can have unlimited branches in the report, but you can still extract value from this in Adobe Reports & Analytics.
Other Pathing Reports
While I haven’t had much time to play with this concept, I would imagine that you could also extract some useful information from the additional pathing reports that are enabled when you turn on pathing for this new “Products Added to Cart” sProp. For example, if you want the “411″ on a particular product being added to the cart, you can open the Summary report:
You could also see how often each product was the only product added to the cart or abandoned in the cart by using an Exit Rate formula (Exits/Visits). Keep in mind that if a visitor adds another product to the cart, the product in question will no longer be an “exit” as far as this report is concerned, so the exit rate below is the combination of single carts + abandons per visit:
You may even be able to use the “Page Depth” (even though they really aren’t pages!) to see how often a particular product was the first one added to cart, second, etc… I say may, because this is what I think this report is showing, but I need Ben Gaines to verify this for me!
Lastly, if you care about Cart Removals (which is not something I normally care about since many people simply exit instead of removing products), you could also include them in this approach. To do this, you’d have to change the values you pass to the sProp to be “Add:[Product ID or Name]” and then use “Remove:[Product ID or Name]” instead of just passing in the product ID or name.
As those of you who have read my posts in the past know, sometimes, I come up with crazy ideas like this and they work out, but other times they don’t. If you think this concept is interesting, feel free to give it a try, but keep in mind that this is just a concept for now until I get some clients to do more experimentation…Enjoy!
Happy summer (almost)! After getting many requests over the years, I am finally bringing my one-day intensive Adobe SiteCatalyst (Analytics) “Top Gun” Training class to New York City. I will be hosting the class on Friday, July 25th. This has been made possible by our friends at eClerx who have graciously provided a conference room at their New York office. For those unfamiliar with my class, the goal is to teach the inner workings of SiteCatalyst in a way that helps you know how it can be applied to daily business questions. While the class doesn’t get into code, it is pretty deep into the features and functions of the SiteCatalyst product. It does not cover daily use of the interface (since that is pretty easy), but rather, is geared towards those who “own” SiteCatalyst within the enterprise or developers who want to understand the differences between an eVar and an sProp. The morning of the class closely mirrors the first section of my SiteCatalyst Handbook and the afternoon session resembles the third section of my book.
Unfortunately, the room can only hold 16 people so if you are interested, I suggest you sign-up sooner, rather than later as there is a good chance the seats will be gone relatively quickly based upon past cities in which I have conducted the same class. To learn more about the class, see pricing information and to register, please use this link: http://bit.ly/top-gun-nyc.
If New York isn’t in the cards for you, don’t forget that two months after this class, I will be conducting the same class in Atlanta as part of our ACCELERATE conference.
In the recent white paper I wrote in partnership with Adobe, I discuss ways to re-energize your web analytics implementation. Often times, this involves re-assessing your business requirements and rolling out a more updated web analytics implementation. However, if you decide to make changes to your implementation in a tool like Adobe Analytics (SiteCatalyst), at some point you will have to make a decision as to whether you should pass new data into the existing report suite or begin fresh with a new report suite. This can be a tough decision, and I thought I would use this blog post to share some things to consider to help you make the best choice for your organization.
Advantages of Using The Existing Report Suite
To begin, let’s look at the benefits of using the same report suite when you re-implement. The main one that comes to mind is the ability to see historical trends of your data. In web analytics, this is important, since seeing a trend of Visits or Orders gives you a better context from which to analyze your data. In SiteCatalyst, you get the added benefit of seeing monthly and yearly trend lines in reports to show you month over month and year over year activity. Obviously, if you decide to start fresh with a new report suite, your users will only see data from the date you re-implement in the SiteCatalyst interface.
Another benefit of continuing with your existing report suite is that you will retain unique visitors for those that have visited your site in the past and have not deleted their cookies. When you begin with a new report suite, all visitors will be new unique visitors so you will be starting your unique visitor counts over from the day you re-implement. Starting with a new report suite will also result in some recency reports(i.e. Visit Number, Returning Visitors and Customer Loyalty) being negatively impacted. Additionally, using an existing report suite allows you to retain any values currently persisting in Conversion Variables (eVars). Often times you have eVar values that are meant to persist until a KPI takes place or until a specific timeframe occurs. If you create a new report suite, all eVars will start over since they are tied to the SiteCatalyst cookie ID.
Another area to consider is Segmentation. It is common to use a Visitor container within a SiteCatalyst segment to look for visitors who have performed an action at some point in the past. This segment will rely on the cookie ID so if you begin with a new report suite, you will lose visitors in your desired segment. For example, let’s say you have a segment that looks for visitors who have come from an e-mail at some point in the past and ordered in today’s visit. If you create a new report suite, you will lose all data from people who may have come from an e-mail prior to the new report suite being created.
If your end-users have dashboards, bookmarks and alerts setup, using the existing report suite will avoid the need to re-create them in the new report suite for variables that remain unchanged. Depending upon how active your users are, this can have a significant impact, as re-creating these can result in a lot of re-work.
There are many other items to consider, but these are the ones that I have seen come up most often as advantages of keeping the existing report suite when re-implementing.
Advantages of Using A New Report Suite
So now that I have scared you off of using a new report suite when re-implementing, let me take the counter-arguement. Despite all of the advantages listed above, there are many cases in which I recommend starting with a brand new report suite. The most obvious is when the current implementation is proven to be grossly incorrect or misaligned. I often encounter situations in which the current implementation hasn’t been updated for years and not at all related to what is currently on the website (or mobile app). If what you have doesn’t answer the relevant business questions, all of the advantages listed above become obsolete. In this situation, seeing historical trends of irrelevant data points, losing eVar values or report bookmarks isn’t a big deal. You may still lose out your historical unique visitor counts since that is out-of-the-box functionality, but I don’t think this justifies not starting with a clean slate. If you are not sure if your current implementation is aligned with your latest business goals, I highly recommend that you perform an implementation audit. This will help you understand how good or bad your implementation is, which is a key component of making the new vs. existing report suite decision.
The next situation is one in which the current implementation is using many of the allotted SiteCatalyst variables, but the new implementation has so much data to collect that it has to re-use the same variables going forward. This gets messy since it is easy to re-name existing variables, but you cannot remove historical data from them. Therefore, if you convert event 1 from “Internal Searches” to “Leads,” because you no longer have a search function and are out of success events, you can get into trouble when your end-users view a trend of leads for this month and see that they are a fraction of what they were last year! Your users may not understand that the data they are seeing from last year is “Internal Searches” and not “Leads,” and may sound off alarms indicating that the website is broken and conversion has fallen off the cliff! While you can do your best to annotate SiteCatalyst reports and educate people, the re-use of existing variables is always a risk, whereas using a new report suite does not require the re-use of existing variables and can avoid this confusion. Where possible, I suggest that you use previously unused variables for your new implementation so this historical data issue doesn’t affect you. Obviously, this requires that your existing implementation isn’t using most or all of your available SiteCatalyst variables. Hence, one key factor when deciding whether to use an existing report suite or create a new one is counting the number of incremental variables you will need variable slots for and determining whether you have enough to avoid having to re-use old variables for new data. If you have enough, that may tip the scale to re-use, but if you don’t, it may make you lean towards a new report suite.
When it comes to historical trends, one thing to keep in mind is that even if you choose to create a new report suite, it is still possible to see historical trends for data that the new and old report suites have in common. This can be done by importing data into the new suite using Data Sources. This is most effective when the data you are uploading are success events (numbers) and a bit more difficult for eVar and sProp data. The main benefit of this approach is that it allows your SiteCatalyst users to see the data from within the SiteCatalyst interface. Another option is to use Adobe ReportBuilder. Within Excel, you can build a data block for the data in the old report suite and then another data block for the same data in the new report suite and then merge the two together in a graph using two data ranges. Doing this allows you to create charts and graphs that span the old and the new, but these are only available in Excel and not in the SiteCatalyst interface.
Another justification for starting with a new report suite is that your current suite has data that is untrustworthy. I often talk to companies who say that they simply do not trust that the data in SiteCatalyst is correct. As I mention in the white paper, trust is an easy thing to lose and a hard thing to earn back. Your SiteCatalyst reports can be correct nine times out of ten, but people will focus on the one time it was wrong. When this happens too often, it may be time to start with a new report suite and make sure that anything added to this new suite is validated and trusted. This can help you create a new perception and help you re-build the trust that is so essential to web analytics.
As you can see, there are many things to consider when it comes to re-implementation and report suites. The current state of your implementation and its data will be the biggest decision points, but every situation is different. Hopefully this helps provide a framework for making the decision and allows you to weigh the pros and cons of each approach.
Those of you who have read my blog posts (and book) over the years, know that I have lots of opinions when it comes to web analytics, web analytics implementations and especially those using Adobe Analytics. Whenever possible, I try to impart lessons I have learned during my web analytics career so you can improve things at your organization. However, much of what I have written in the past has been product-related, covering features, functions and implementation tips. Obviously, there is much more than that involved when it comes to success in web analytics.
As some of you may know, the last role I held when I worked at Omniture (prior to Adobe acquisition) was one in which I was tasked with “saving” accounts that had gone astray. I encountered many accounts that had either a dysfunctional web analytics program or implementation. One way or another, they were not getting the desired value from their investment in SiteCatalyst. In my time serving this role, I came to see many common characteristics of those who were having problems and identified specific ways to address them to get clients back on track. After I left Omniture, I joined Salesforce.com as the head of web analytics. In that role, I encountered similar issues, as the Salesforce.com implementation and program had many of the same problems I had seen while at Omniture. Over the next few years, I had the opportunity to test out my “client-saving” techniques in a real life setting and had some great success in turning around the web analytics program at Salesforce.com.
While at Web Analytics Demystified for the past three years, I have continued my mission to help ailing web analytics programs and had the good fortune to work with some great clients. These clients have entrusted me to show them how to bring their web analytics programs back from the abyss or to improve good things they are already doing. Working with the great partners at Web Analytics Demystified, I have been able to learn and improve upon things I have done in the past. Last year at the Chicago eMetrics conference, I documented my lessons learned into a forty-five minute presentation entitled “Bringing your Web Analytics Program Back from the Dead!” I was a bit worried that no one would actually show up to my session, since coming was an implicit admission that things weren’t going so well. But to my surprise, there was standing room only! Jim Sterne informed me that I had about 95% of all attendees in my breakout session! I was excited to share my experiences and afterwards, received a great response from the crowd, as well as a rush of people attacking me at the stage with follow-up questions. Apparently, I had hit some sort of nerve with the topic (Note: This summer I will be presenting a follow-up session at Chicago eMetrics on the topic)!
Since then, I wondered how I could share this information with more folks who may be interested in improving or re-energizing their web analytics programs and/or implementations. I considered writing a book on the topic, but having recently written a book, I knew that this was a massive undertaking and that my busy schedule wouldn’t allow it. Instead, I decided to partner with my old friends at Adobe to create a new white paper on the topic. In this white paper, I have tried to get down to the core tenants of my approach to reenergizing web analytics programs and synthesized it to under twenty pages of content. While most of the concepts in the paper were learned working with Adobe clients, I believe that the principles will apply to any web analytics technology or program. In fact, I believe that the white paper would also apply to non-web analytics programs, as much of it goes back years to by time working at Arthur Andersen in the nineties.
Therefore, without any more preamble, I am pleased to announce the immediate availability of this new Adobe-sponsored white-paper entitled “Reenergizing Your Web Analytics Program.” I hope that you will take the time to read it and take advantage of some of the lessons and techniques I have learned over the past 10+ years so that you and your organization can improve your program/implementation. As a young industry, I think it is the responsibility of us “old-timers” to pass on what we have learned so others don’t have to “reinvent the wheel.”
Click here to download white paper
A big thanks goes out to my friends at Adobe for sponsoring this white paper and making it happen. Enjoy!
I recently had a client pose an interesting question related to their shopping cart. They wanted to know the distribution of money its visitors were bringing with them to each step of the shopping cart funnel. For example, what percent of visitors have between $25 and $50 in their cart when they reach the “Billing” step of the conversion funnel? Does this percentage remain constant throughout the funnel or are there significant drop-offs? Unfortunately, this is not something that can be easily derived in SiteCatalyst, but with a bit of creativity, I will show you how you can add this data to your implementation.
Calculating Current Order Value
The first step in this process is to work with your developers to create a new Counter eVar that will hold the current order value. As soon as a visitor adds an item to the cart, pass the dollar amount associated with that cart addition to the Counter eVar (in addition to passing it to a currency event as prescribed in my “Money Left On Table” blog post). This value will be bound to the Cart Addition success event and future cart events unless it is modified. If the visitor adds more products to the cart, pass in those amounts and if the visitor removes an item from the cart, subtract it from the Counter eVar value (remember you pass values to Counter eVars using the “+” or “-” sign). I would expire the Counter eVar at the Purchase or Visit (if your site doesn’t have a persistent cart).
By having these values in the Counter eVar, you will end up with many different dollar amounts when you open the eVar report with one of your cart events. Here is an example of what the eVar report might look like:
Obviously, this report is not that readable, so the next step is to classify it into meaningful groupings, such as Under $20, $21-$35, $36-$50, etc… This will allow you to analyze the data in buckets and look for insights. Which groupings you choose are up to you and you can use SAINT to have multiple groups, such as every five dollars, every ten dollars, etc… Here is what it might look like after the SAINT Classification:
This general concept is similar to one that I described in my Revenue Bands post, but in that scenario, we were just passing the final order amount to a regular text eVar. The difference here is that we are using the Counter eVar to adjust the order value up or down as it progresses through the cart process.
Once we have the current order values tied to each stage of the cart funnel and have grouped them accordingly using SAINT, our next challenge is to compare the distributions. There are a few different comparisons you can make with this data, so I will touch upon each of them. The first one you might want to see is whether the various percent distributions are steady or going up/down over time. In this case, you may not care about the actual raw numbers that are associated with each order value range, but rather, are most likely more interested in the percent of the total. For example, it may not be that interesting that 2,500 checkouts fell into the range of $15-$25, but it may be interesting to know that this dollar range represented 15% of all visits to the checkout step of the funnel. If you could see this percentage, then you could trend it over time and see if that $15-$25 bucket is increasing, decreasing or steady over time.
To see these percentages, you have two options, the first is to download data to Excel and create formulas to calculate the percent and trend it over time. If you want to use the SiteCatalyst interface, the best way to do this is to employ the “Total Metrics” feature. This feature allows you to create a calculated metric that divides the row value by the total at the bottom of the report. For example, if you wanted to calculate the percent of each dollar band while at the Checkout step, you would divide Checkouts by Total Checkouts using a formula like the one shown here:
This formula moves the percent shown in the regular eVar report front and center so it is the actual metric of the report. To visualize this better, let’s look at the previously shown report with this new metric column added:
As you can see, the percentages that were previously on the right side of the column (more as an FYI), are now present by themselves as a real metric in SiteCatalyst. Now you can use this percentage as a true metric, meaning that you can trend it over time and see its historical performance:
This allows you to see how each dollar amount band does and do some hard-core web analysis!
Another analysis you may want to do with this data is to see the drop-off between the dollars amount percentages added to cart, the percentages making it to checkout, etc… This is a bit more complex because you are looking at one dollar amount grouping, but seeing how it changes as visitors get further in the cart process. Unfortunately, there is no great SiteCatalyst report for comparing different percentages over time, so this analysis will have to be done in Excel.
To begin, you will want to create additional “Total” metrics like the one shown above for the other cart steps that you care about. In SiteCatalyst, this is what a report might look like, though it is limited in its use. In this case, the client has a customization step in the funnel, a billing page step and then a checkout step. Using the “Total” metrics, you can compare the changes in dollar amounts at the various steps of the funnel:
In this case, we are looking to see how consistent the percentages are across each row and seeing if we can identify any problem areas. However, to do analysis on this, Excel might be a better tool since it is easier to compare the percentages between different columns. Also keep in mind that you can break this report down by Product or Product Category to see how these percentages change by Product.
If your website has discrete steps in its funnel and if you are curious to see how much money visitors have at each step of the cart, the preceding is one way to do this. In addition to what I have shown here, having this information can be useful in other ways. For example, if you want to build a segment of all cases in which a visitor had more than $100 at the checkout step, but did not purchase, the eVar described here can be used as part of your segment criteria. I am sure there are many other ways to use this data as well, but hopefully this gives you some food for thought.
If your web analytics work covers websites or apps that span different countries, there are some important aspects of Adobe SiteCatalyst (Analytics) that you must know. In this post, I will share some of the things I have learned over the years related to currencies and exchange rates in SiteCatalyst.
When you work for a multi-national organization, the first decision you have to make is whether you plan to have a different report suite for each country website or whether you will combine all data into one report suite and use segmentation for day-to-day analysis. For the pros and cons of this decision, I suggest you refer to this old post that covers multi-suite tagging vs. segmentation. As noted in that post, one of the downsides of using one report suite and segmentation is that you cannot have a different currency for each country. I find this very limiting, so let’s assume that you have a different report suite for each country site in your organization. When implementing each report suite, you will assign a currency that the report suite will use. For example, if the report suite is for Japan, in the Administration Console, you will make the currency Japanese Yen:
Once you do this, you just need to make sure that when you pass Revenue and currency success events that you set the s.currencyCode variable to the appropriate currency code for that country (i.e. JPY). This will tell SiteCatalyst that the numbers you are passing should be stored as Japanese Yen. If you are using multi-suite tagging and sending a second copy of data to a global report suite, then Revenue and currency success events will be translated into the currency of the global report suite (i.e. US Dollars) using the currency exchange rates found on xe.com. This allows your users in one country to see data in their own local currency, while letting executives see data rolled-up in a master suite in one unified currency.
One-Report Suite Only
As mentioned above, if you don’t have a separate report suite for each country site, either having just one report suite for the entire organization or a report suite for a region that contains multiple currencies, you cannot take advantage of the preceding currency translation feature. In this case, you have two choices. Your first choice is to use the same currency for all countries and pass data in that currency at the time of data collection. For example, if you have a European report suite, you may choose to use Euro as the primary currency and translate British Pounds and other non-Euro currencies into Euros at the time data is passed into SiteCatalyst. The second option is to pass currency amounts into a Numeric Success Event in a way that is currency agnostic. In this approach, you would not use the out-of-box Revenue event and instead would create a custom Numeric success event and pass in the raw numbers in the currency of that country. For example, if a 200 Euro order takes place in Germany, you would pass in a value of 200 and if a 300 British Pound order takes place, you would pass in a value of 300 to the Numeric success event. At the same time, you should pass in the currency the order took place in to an eVar. Once you have the raw transaction amount and the currency type, you can download the data to Excel using Adobe ReportBuilder and translate the raw Numeric success event numbers into the appropriate currency using a lookup table and referencing the eVar that indicates the currency. While this will not provide a way to see local currencies within the native SiteCatalyst interface, you can at least have your Excel dashboards show local currencies. Obviously you can use both of these approaches concurrently, using a master currency for the region and then providing local currencies in an Excel dashboard.
Pegged Exchange Rates
Over the years, I have worked with several clients that use “pegged” exchange rates. In this scenario, their organization uses one set of currency exchange rates for the entire fiscal year instead of using the daily exchange rates. This causes a problem for Adobe SiteCatalyst, since its default behavior is to use the daily exchange rates found on xe.com. Keep in mind that the local currencies in country-specific report suites will be fine since they are not being translated into a master currency. In this scenario, the only figure that is negatively affected is the currency amount in your global report suite, since that is when currency translation occurs. For example, if you collect an order for 300 Euro in Germany and the German report suite is set to Euros, everything will be fine. However, when that 300 Euro order is sent to the global report suite (let’s assume it is a US-based organization), it will be translated into US Dollars by default using today’s exchange rate instead of your pegged exchange rate (which can be quite different).
Unfortunately, there isn’t a way to override this default behavior, so I recommend using a DB VISTA rule to have SiteCatalyst lookup the pegged exchange rates published by your organization. As currency data is collected, you can use DB VISTA to bypass or overwrite the exchange rate translation done by SiteCatalyst with the rates approved by your organization. Unfortunately, DB VISTA rules cost a few thousand dollars, but in this case, it is probably worth it to have your global currency figures reflected correctly.
Interface Currency Setting
The last area related to currencies I want to cover is the currency setting found within the SiteCatalyst interface itself. I call this out because it can be very dangerous if you do not understand it. In the Report Settings area of the left navigation, there is a way to change the currency that you see when using SiteCatalyst. Here is what it looks like:
From this screen you can change the currency setting you use. Here is an example of me changing it from US Dollars to Euros:
Doing this will now show currency reports in Euros:
The dangerous part of this feature is that it seems like it does more than it actually does. How awesome is it that we instantaneously converted all of our data from US Dollars to Euros? Unfortunately, this is a mirage. Using this feature simply translates all historical data into the new currency (Euros in this case) using the current exchange rate. This means that historical data is not converted using the exchange rate that was present at the time the data was collected. Therefore, if the exchange rate has changed significantly, our data will be off. This is why it is important that you educate your users about this feature before they start using it and present inaccurate data to people in your organization.Once you understand how this feature works, you may re-think using this feature and proactively discourage its use!
In the last few years, people have become accustomed to using multiple digital devices simultaneously. While watching the recent winter Olympics, consumers might be on the Olympics website, while also using native mobile or tablet apps. As a result, some of my clients have asked me whether it is possible to link visits and paths across these devices so they can see cross-device paths and other behaviors. This type of linking has long been available using advanced tools like Adobe Data Workbench (formerly known as Visual Sciences or Discover on Premise or Adobe Insight), but in this post I wanted to share some things you can do in SiteCatalyst (Adobe Reports & Analytics) as well.
Authenticated Visitors Only
The first thing to note, is that it is not easy to link visitors hitting your website and native apps if they are not authenticated via some sort of identifier (ID). As you probably know, visitors have different SiteCatalyst Visitor ID’s on each device, so it is hard to know which ID’s represent the same person. However, if your website/native app allows visitors to login using a customer ID or loyalty ID, you have more options available to you. Adobe has one approach called “visitor stitching” that you can read about here, but I have not seen many clients use that successfully. The reason I don’t see this working is that it requires a large change to your SIteCatalyst implementation involving replacing the out-of-the-box Visitor ID with your own Visitor ID. This can have some major ramifications (i.e. distorted unique visitor counts) and many of my clients aren’t ready for that type of risk.
However, this solution can be modified a bit to be a bit more useful and that is what I am going to discuss here. Instead of replacing the Visitor ID on your main report suite, I advocate creating a new “Authenticated Only” report suite in SiteCatalyst in which you send only authenticated traffic. This new report suite would most likely be populated using a VISTA Rule. When data is sent to this new report suite, the s.visitorID would be set to your own authenticated ID so it matches up across any device.
Let’s look at an example. Imagine that Joe Smith visits your website and views a few pages as an anonymous (non logged-in) visitor. Then on the fifth page of the visit, he authenticates. From that point on, you can send all of his traffic to a multi-suite tagged Authenticated Only report suite as a secondary server call. Next, let’s assume that Joe takes a break from your website and begins using one of your native mobile apps. Upon using the native app, he authenticates so all of his data also goes to the Authenticated Only report suite as a secondary server call. Since both of these actions are time-stamped, in the Authenticated Only report suite, you would see activity from both of Joe’s sessions, and in the order they took place. For example, in a path report you might see a series of pages Joe viewed while on the website and then in the next page flow report, see a path from a page on the website to a page found in the native app. Obviously, there is no direct link between these pages, but by passing both data elements to the same report suite, SiteCatalyst sees them as being consecutive. This can provide insights into when people are moving between different devices and what content they view on each. When it comes to pathing, you might want to consider setting a new version of the page name variable in which you pre-pend the digital channel to the page name (i.e. web:home page vs. app:home page) so when you see pages in pathing reports, you know which device the visitor was on when they viewed the page:
Seeing paths across multiple devices is cool, but that is only the tip of the iceberg! Since data coming from both platforms have the same Visitor ID, all eVars that you set will retain their values across devices since eVar values are tied to the Visitor ID. For example, if a visitors’ City is passed to eVar4 on the website, its value will persist for all actions taking place on the native app. This means that any Success Events set on the native app can be attributed to the visitor’s City, even though they never input the city within the mobile app! The same is true in reverse, as eVars captured in the native app will be available to the website. This eVar persistence can be very powerful when you think about things like Campaign Tracking Codes, which can be collected in either platform and extended to the other.
Another cool aspect of this solution is that you can do cross-device Segmentation. For example, you might want to build a “Visit” segment in which visitors viewed more than one device and XYZ actions took place. This would now be possible using the Authenticated Only report suite since the behavior on both devices looks to SIteCatalyst as if it all took place in one session (which it did!).
Another bonus of this solution is the ability to use the SiteCatalyst feature of Participation. Participation is only visit-based, so you can only see which pages within the visit led to Success Events (i.e. Orders). But when visitors switch devices, they are creating a new visit, which breaks Participation. But with this solution, any pages viewed on one device would show as having contributed (Participated) to success taking place on the other device, since both devices are included in the same visit!
As always, there are a few caveats to any solution. The following are a few things to keep in mind before getting overly excited:
- Sending traffic to another report suite will use additional secondary server calls which has a cost implication. To estimate how much this solution would cost, look at how many page views you have for authenticated pages (pages viewed by people who are logged in) and you will get a good approximation of how many additional server calls you will have to pay for
- VISTA Rules also cost a few thousand dollars so that is another cost you would have to incur
- Using this solution assumes that all of your report suites are set-up consistently, meaning that the same Success Events, eVars and sProps are used for your website and native app suites. You should be doing this as a best practice anyway for creating global report suites, but in case you are not, be sure to only pass in the variables that are common to both via the VISTA rule or you will get different numbers or values in the Authenticated Only report suite. Keep in mind that you can use VISTA rules to change the Event/eVar/sProp numbers on the fly if it is too difficult for you to sync up your implementations right away (though I don’t recommend doing this in VISTA as a long-term solution since it can be easily broken)
- Any pages view before visitors authenticate will not be captured in the new Authenticated Only report suite. This means that you will not be getting the full picture of the visit in this new report suite. For example, you may not get the accurate entry page or miss the passing of some campaign tracking codes, but there are some more advanced techniques you can use to store this information and pass it on the first authenticated page
- Using this approach with native mobile apps that store offline data is not recommended since the offline data timestamps can mess up your data collection and eVar attributions
Outside of these few caveats, if you want to see cross-device behavior, this is a relatively simple (and cheap) solution. Obviously, if you want to get much deeper into cross-channel behavior, you may want to investigate Adobe’s Data Workbench or tools like Causata (now owned by NICE). If you are interested in seeing how your visitors float between your digital channels/devices, feel free to give this approach a try…
Recently, I have had a few clients ask me the following question:
How can I determine which onsite search terms have the highest exit rate on the search results page?
This question also appeared on the Adobe Analytics message board. While it is easy to see how often visitors exit from your search results page, that analysis won’t show you which specific onsite search terms had higher or lower exit rates. Of course, you could pick one specific onsite search term and segment on that to see exit rates from the search results page for that term, but that is a non-scalable approach if you want to see this for multiple search terms or for all of them in descending order. So I thought I’d share some ideas on how you can tackle this type of analysis in Adobe SiteCatalyst.
Option #1 – Search Term Exit sProp
The first thing that comes to my mind to solve this problem is Pathing. Once pathing is enabled on an sProp, you can see entries and exits. In this case, you can pass in the onsite search term to a new Traffic Variable (sProp) on the search results page. You are probably already storing onsite search terms in an sProp so you can see search term pathing (seeing search terms used before and after other search terms). However, this sProp will be a bit different. For this sProp, all you want to know is whether they exited or not. To accomplish this, have your developers pass a value of “[did not bounce]” to the sProp if the visitor reaches any page on your website after the search results page. By passing this “dummy” value, you are ensuring that SiteCatalyst won’t see an exit if they reached a page beyond the search results page.
Once this is done, you can open this new sProp and add the Exits metric and see a list of search terms with the most exits in descending order:
If you see the “[did not bounce]” item, you can simply exclude that from the report using a search filter.
Option #2 – Pages After Search Terms
There may be cases in which you also want to see where visitors went after seeing search results for a specific onsite search term if they did continue their path. There are a few ways to do this. One way is to build a segment that isolates visits in which the onsite search term you care about was used and then look at the path reports for that segment. A downside of this approach is that it will include paths taking place before and after the search term was used unless you use Discover (Ad Hoc Analysis). Therefore, the way I would approach this is to continue building upon the concept above, but tweak it a bit.
The tweak you will make is to not pass the “[did not bounce]” value on the page after the search results page, but rather, to pass the s.pagename value to the new Search Term Exit sProp described above. Since this can be confusing, here is a recap of the tagging steps you’d want to tell your developer. On each page of the site except for the search results page, pass the value being passed to s.pagename to your new Search Term Exit sProp. When visitors are on the search results page, have your developer pass the onsite search term to the new sProp (I recommend inserting the phrase “term:” to make it clear which items in the new sProp are search terms and which are page names). Believe it or not, that is it! For example, if a visitor is on the Greco Inc. home page and then searches for “boots” and then goes back to the home page, here are the three values that you would pass to the new Search Term Exit sProp respectively:
By doing this, your end-users can open the Next Page Flow report for this new sProp, choose the onsite search term (“term:boots” in this case) and then see the path flows after the search term. The way pathing works, it will only show paths taking place after “term:boots” and the exit percent will be people who exited right from the search results page. Here is what the report might look like:
In SiteCatalyst, you can only see two levels of paths from the onsite search term, but if you have access to Discover (Ad Hoc Analysis), you can see an unlimited number of paths emanating from the onsite search term. As you can see, this version of the solution provides everything that option one provided, but also shows you the specific pages visitors viewed after each onsite search term. It is up to you to decide how much analysis you want to do and what questions you want to answer.
Another side-benefit of this approach is that you can take advantage of fall-out pathing reports. Let’s say that you want to know how often visitors searching for “boots” make it to the shopping cart or to the order confirmation page. To do this, you can create a fall-out report that starts with “boots” and then add your cart and order confirmation pages to the fall-out report as checkpoints.
In Discover, you can even group onsite search terms into buckets using the grouping feature and do a similar fall-out report from a group of terms leading to carts or orders!
I am sure there are many more ways to answer these types of questions, but for those focusing mainly on SiteCatalyst, I hope that this is helpful.
As someone in the web analytics field, you probably hear how lucky you are due to the fact that there are always web analytics jobs available. When the rest of the country is looking for work and you get daily calls from recruiters, it isn’t a bad position to be in! At Web Analytics Demystified, we have more than doubled in the past year and still cannot keep up with the demand, so I am reaching out to you via this blog post. As you may have read in Eric Peterson’s blog post, earlier this year we have begun placing qualified web analytics folks at great clients and started a staffing business. This business grew out of requests by our clients and other friends in the industry for good people they could either hire or “rent” for long term projects. Since we know the folks at companies looking for people and also know many of the people in the industry, it seemed to make sense that we would help play match-maker.
However, what is most exciting to me, is our Team Demystified staffing area. Through Team Demystified staffing, we make you a virtual member of our Demystified team and place you on long-term engagements with us and our clients. This means that you get to work side-by-side with me and my partners. Through our online collaboration tools, you have a direct line into everyone at Demystified when you have questions or want advice on how to handle a situation at a client. In addition, we provide free training on web analytics tools like Adobe SiteCatalyst, Adobe ReportBuilder, Adobe Target and Google Analytics. If you are an independent contractor or at a job that is not satisfying, Team Demystified offers an opportunity to work with the best people in the industry, at amazing clients and help boost your career. Consider it to be an MBA in web analytics, only you get paid instead of paying for it!
Therefore, if you have business or technical skills related to web analytics, we want to hear from you. Even if our current opportunities aren’t right for you, we’d like to have you in mind as new opportunities arise. You can find my contact information on our website or send an e-mail to Wendy Greco.
Additionally, if you happen to be attending Adobe Summit in Utah, the Demystified team will be there. If you are interested in learning more about Team Demystified, please contact Wendy and she can arrange a time for you to meet with one of us to learn more.