Previous Page Variable
I believe that every SiteCatalyst implementation should have a Previous Page sProp. There! I said it (I feel like I am channeling Avinash!). In past blog posts I have touched upon the use of a Previous Page sProp, but I feel like I have not done it justice and wanted to take time to explain it in greater detail. In this post, I will describe why I think this variable should always be set and provide some examples of its use.
Why You Need a Previous Page sProp
I find that in the web analytics world, I often receive the following question:
“What page was the visitor on when he/she _______?”
You can fill in the blank with many things. Here is a list of the ones I have been asked:
- …searched for this phrase in our internal search box…
- …clicked on a button to go to a web lead form…
- …downloaded a white paper…
- …added products to the shopping cart…
- …clicked on a banner advertisement…
- …started using the ROI calculator…
- …clicked to fill out a website survey…
I could go on for days and never come to the end of these types of questions! People want to know this information because it helps them get inside the head of their visitors. Often times it leads to navigation or content changes. Regardless of the reason, I assure you that you will be asked this question at some point and the truth is that it is not easy to answer with out-of-the-box functionality (i.e. Pathing). The good news is that setting the Previous Page sProp is easy and will pay great dividends down the road…
How To Set the Previous Page sProp
Setting the Previous Value sProp could not be easier. All you have to do is use the Previous Value JavaScript Plug-in to pass the previous page name to a new Traffic Variable (sProp). You can even see a detailed description of the code for this in Ben Gaines’ great Summit blog post. If you need help, call your Omniture Account Manager, Omniture Consulting or ClientCare.
Once you have your JavaScript setup to pass the Previous Page Name to the sProp, you need to enable a Traffic Data Correlation to any sProp for which you want to create a breakdown. For example, if you want to see what pages visitors were on when they searched for a particular internal search term, you would correlate the Previous Page Name sProp with the Internal Search Term sProp…
…so you can see a report like this:
In addition, if you are familiar with correlations, you may recall that they are bi-directional, so in addition to seeing the pages people searched for specific terms from, you can also see the converse. In this case, that would mean seeing all of the internal search terms visitors searched for on a specific page:
As you can see here, we see the same “4” searches for the phrase “chatter” from the selected page as we saw in the first internal search term report (in this case I am just using Internal Search as an example, but if you want to learn more check out my Internal Search post).
One Is Usually Enough
However, one word of caution, I have seen many clients implement several Previous Page sProps and I am not a fan of doing this as I will now explain. Let’s say you want to see what page people were on when the searched on a specific search term (as described above) and you also want to see what page they were on when the downloaded files on your site. A lot of people will set two Previous Page sProps in this situation – one for the search term and one for the file downloads. In my opinion, this just wastes a variable, wastes correlations and causes confusion for your users. The truth is that all you need is one Previous Page sProp to answer both questions. Since on each page there will be one and only one Previous Page value, there is really no reason to do this multiple times.
I have seen some clients who have chosen to pass the Previous Page Name to an eVar. There are some interesting uses of this. For example, if you want to see what pages visitors were on when they added a specific product to the shopping cart, you can pass the Product Name to the Products Variable, set the Cart Add Success Event and the Previous Page Name to an eVar. The main issue you will run into is that Conversion Subrelations are an “all or nothing” proposition so you can only do breakdowns by eVars that have Full Subrelations.
One final tip that I will throw out there is to consider having your developer pass a value of “[NO PREVIOUS PAGE AVAILABLE]” (or something similar) to the Previous Page sProp on entry pages (or any other time no Previous Page is available). I find that this is easier than dealing with questions around “Unspecified” in correlation reports and it is easier to remove this value using the search box than it is to hide the “Unspecified” values.
Final Thoughts
As I mentioned in the beginning, I highly recommend that you have a Previous Page sProp for all of your key report suites and add correlations as needed. If you have any questions/comments, feel free to leave them here…
