getPercentPageViewed plug-inA few lucky SiteCatalyst users got a sneak preview showing of our Summit session, and the nearly unanimous reaction was that one of our three advanced tactics really stood out as the most exciting: the getPercentPageViewed plug-in, which (as the name suggests) allows SiteCatalyst to capture the percentage of a page (vertically) that the user has viewed. Best of all, the plug-in is completely free and available to all Omniture users. You can download it, along with basic documentation and installation instructions, from within SiteCatalyst by going to Help > Home, and then choosing Supporting Docs > Implementation > Plug-ins from the left navigation menu.

getPercentPageViewed—an overview

Omniture already offers a number of tools to help you understand what users are doing on your site. As far as page design and layout analysis are concerned, you’re probably familiar with ClickMap, which applies a graphical overlay to links and buttons to show you which page elements your visitors are clicking (and how often they’re clicking them). But this is just one gauge of page consumption. There are plenty of scenarios where it would be great to know not just what the user clicked, but also what the user saw. How much real estate do you really have at your disposal? Are users finding the page elements that you want them to find? This is exactly what the getPercentPageViewed plug-in does. It calculates the length of the page (even adjusting if users resize their browser) and then determines how far down visitors go before clicking away. This value updates as the user scrolls, and will always retain the maximum percentage viewed—even if the user later scrolls back up to the top.

To implement the plug-in, you will need the following:

  1. Two Custom Traffic (s.prop) variables.
  2. A correlation between the two variables.

That’s it. You can do more with additional s.prop variables and correlations, but we’ll start out with just these two items.

NOTE: The plug-in can (obviously) only determine how much of the page the user has viewed after the page has loaded, and only as the user scrolls. This means that the only reliable way to capture this data for a given page is on the next page view. Thus, we’re really capturing “percentage of previous page viewed,” but we can still marry this to the correct page name for analysis. I’ll explain how to do it below.

First Custom Traffic variable: Percentage of Page Viewed

To the developer’s enormous credit, the plug-in is extremely easy to implement. Instructions are available in the Knowledge Base, but essentially you drop the bulk of the code into your plug-ins section where you probably already have other code snippets such as getQueryParam and getValOnce. Then, within the s_doPlugins() function, you make a call to the plug-in as shown below (using s.prop1 as our Custom Traffic variable):

// capture the percentage of previous page viewed
s.prop1=s.getPercentPageViewed();

Simple. However, this doesn’t really give us anything actionable on its own. Just a bunch of numbers representing the raw percentages viewed for all pages on your site:

getPercentPageViewed plug-in

The really useful data comes when we also capture the previous page name (or previous site section, previous search term, etc.) into a separate Custom Traffic variable and enable a correlation between these two variables.

Second Custom Traffic variable: Previous Page Name

As described above, the second Custom Traffic variable captures the previous page name so that we can break down page name by percentage of page viewed, since that is where the magic happens. Fortunately, there is another plug-in (available in the same location as getPercentPageViewed) called getPreviousValue which makes capturing the previous page name easy. Installation of getPreviousValue is very similar to installation of getPercentPageViewed, and you would call the plug-in as shown here (using s.prop2 to capture the previous page name):

// pass the previous page name into prop2
s.prop2=s.getPreviousValue(s.pageName,'gpv_pn')

That’s it. So, finally, combining the two into a conditional, here’s how we recommend implementing these two plug-ins:

// capture previous page name; if it exists, capture percent of page viewed
s.prop2=s.getPreviousValue(s.pageName,'gpv_pn');
if (s.prop2){
s.prop1=s.getPercentPageViewed();
}

At this point, you’ll have a Custom Traffic report in SiteCatalyst with a bunch of raw percentages, and another Custom Traffic report that looks very similar to your Pages report, except that it shows the previous page name for each page view.

Correlation

Adam Greco wrote about data correlations in a previous blog post, and I highly recommend reading his advice if you’re unclear on how correlations work or on how to set them up. In this case, you will want to enable a correlation between the two Custom Traffic reports that correspond to the variables that you’re using to grab the percentage of page viewed and the previous page name. Once the correlation has been set up, you can go to the Previous Page Name report and click the green correlation icon to break down any page name by the Percentage of Page Viewed report, giving you something like this if you chose to break down the “Home” page name:

getPercentPageViewed plug-in

This is starting to become useful. We can see that our home page typically gets users to view around 50% of the page. If we have important links, ads, videos, etc., we probably should put them in the top half of the page. Or maybe the page is altogether too long and could be shortened.

Another useful way to look at this data involves grouping the various percentages in the report using SAINT. Looking at the raw percentages (0-100) is a good start, but bucketing can help bring to the forefront trends that may be harder to see by viewing the percentages as-is. And because you can add multiple classifications to any report, you can actually slice and dice your percentages in a variety of ways: quartiles, quintiles, deciles, etc. This gives you easily digestible reports, such as this one:

getPercentPageViewed plug-in

Where this gets even cooler is in the context of A/B testing. You can send various page layout names into a Custom Traffic report (using getPreviousValue, of course) and correlate with percentage of page viewed to see how the different options engage users differently. You’ll already know what they clicked, thanks to ClickMap or other reports, but the getPercentPageViewed plug-in can help you see how different variants affect page consumption.

You can do some great things with these reports.

  • On the surface of it, you can let your team know exactly how much “real estate” they realistically have to work with on key pages.
  • Key features that you want to highlight can be moved into the appropriate locations where you know most users will see them.
  • Where appropriate, pages can be shortened to lengths more suitable to actual user behavior.
  • Calendar events can help show how site/page changes affected consumption.
  • Comparing to ClickMap or custom link data, you can understand the relationships between viewing a certain portion of the page and clicking on links within that portion of the page.

A few final questions (and answers)

Q: Should I use a Custom Conversion (eVar) variable as well (or instead)?

A: My feeling is generally that a Custom Traffic approach is best. Because the percentage of page viewed is going to be captured on every page, there isn’t much value to the persistence offered by eVars. The only use case that I can imagine for eVars in this scenario is the ability to understand how page consumption on the entry page affects conversion (which could be accomplished by using the plug-in to populate an eVar set to “Original Value” so that the entry page receives credit for the conversion). For the majority of users, the real value here is simply in understanding how page layouts and lengths are working, which can be accomplished using a Custom Traffic variable.

Q: What happens if users abandon my site? Do we still get to see how much of the page they viewed?

A: Because the plug-in captures the percentage of the previous page that the user viewed, if users close their web browsers, click a browser bookmark, or enter a different URL in their address bar, SiteCatalyst will not receive the percentage for that final page (as there is no “next page” on which to capture the data). However, if the user clicks an exit link, the percentage of the page that the user viewed will be captured prior to the user leaving your site.

Q: What if users resize their browser horizontally?

A: It will have no effect on the plug-in’s ability to capture the percentage vertically. If resizing the browser changes the maximum length of the page, the plug-in will adjust to it.

We have already seen SiteCatalyst users do some great analysis and optimization based on this functionality, so hopefully you’re as excited about this new plug-in as I am. Next time, we’ll cover the final topic from my Summit session: participation. (Adam already described this feature, but we have a few things to add.) Of course, if you have any questions about getPercentPageViewed, either based on this blog post or on the content we shared at Omniture Summit (or if you asked a question at Summit and we didn’t get a chance to answer it!), please let me know by leaving a comment here. You can also contact me via Twitter (@OmnitureCare).

17 comments
Jorgen Nybrolin
Jorgen Nybrolin

I have further questions. We are running 10 different newspaper websites. As you know the length of a newspaper site varies all the time, which make the percentage calculation irrelevant if you would like to measure how many visitors that have seen a certain ad that is placed x pixels down on the website. This question from our advertisers is very common (and relevant!): How many of your visitors have seen my ad since it not placed on top? Is it possible to use Omniture to measure how deep pixelwise the visitors have scrolled down?

Jorgen Nybrolin
Jorgen Nybrolin

Since it was your consultant that set up the correlation I really hope it´s correlated with "Previous page" and not by Page. We have now got a new script from ClientCare, who told us you have upgraded the plugin and informed us: ----------------------------------- The newer version of this plug-in handles the "previous value" login internally through the s_ppv cookie Therefore your code needs to be amended similarly. So, for example, instead of: /* Get Percent Page Viewed */ s.prop19=s.getPreviousValue(s.pageName,"s_pv"); if (s.prop19){ s.prop20=s.getPercentPageViewed(); } You would simply replace this with: s.prop20=s.getPercentPageViewed(s.pageName); -----------------------------------------------

Jorgen Nybrolin
Jorgen Nybrolin

We have just recently set up the possibility to get the reports for "Percent page viewed". A great report, but when I look at a specific page (makes a correlation with Previous page viewed), we get a huge amount of "Unspecified". For some pages is "Unspecified" listed for more than 50% of all the page views. How come so many page views are listed as "Unspecified"? Why can´t the script get the needed value for so many page views? Is there certain browser that you know don´t deliver this value to the script=

Dan
Dan

Hi Ben, How can I QA this to make sure this is recording the % of page viewed accurately? Say a visitor scrolls down 45% of the page. Can this plugin really tell me that visitor saw 45% of the page, and not 40%, 50% or 60%?

James
James

This is great! Very very very useful, simple, and brilliant. Looking forward to it.

Melvin
Melvin

Nice write up, Ben. May I know the way to get the data correlated to section ?

Jonathan Kay
Jonathan Kay

Nice write-up Ben. Looking forward to using the report as were were considering an alternative vendor for this.

Vitor Lopes
Vitor Lopes

Hi Ben, I have two questions: 1 - Where does the plugin get initialized, in s_doPlugins? 2 - Why not use the onunload event to track the percentage of the current page viewed? Regards, Vitor Lopes

Brad
Brad

If 17.96% saw "up to 25%" than how could only 14.74% have seen "up to 75%" since 25 would be included in "up to 75%"? Or does "up to 75%" really mean "between 51 and 75%"?

Analyticist
Analyticist

Great stuff, Ben. THanks. So, when a user grabs the scrollbar and scans to the end of the page, then goes back to the top without releasing, is that recorded as 100%?

Ben Gaines
Ben Gaines

Great question. I'm fairly sure that it's possible, although I'm not aware of a plug-in currently in existence that outputs the value in pixels rather than a percentage of the total page. SiteCatalyst is somewhat at the mercy of the browser, but as long as the pixel value is available to JavaScript (or some other method for outputting it to JavaScript), then it should be possible. That would be a great item to suggest at the Idea Exchange!

Ben Gaines
Ben Gaines

It sounds like you're running a correlation here. Which elements are you breaking down? Is it Percent of Page Viewed broken down by Pages, or is it Percent of Page Viewed broken down by Previous Page (as explained in the post)? In either case, you will see a certain number of "unspecified" page views whenever the Percent of Page Viewed variable had a value but the other variable (Pages or Previous Page) did not.

Ben Gaines
Ben Gaines

Dan, That is exactly what the plug-in does, QAing it can be a bit tricky; it uses the same javascript properties and methods that you would use in QAing it, so I'm not sure there is an "independent" way to test it out. For example, you could alert out the percent viewed as you click a link on the page to see how much you've viewed to that point, but you would probably do it using roughly the same logic that the plug-in uses. Does that make sense? Thanks, Ben

Ben Gaines
Ben Gaines

Really glad to hear it, Jonathan. Those who have implemented it thus far have reported really good things. Please let me know if you run into any questions as you're implementing the plug-in(s) or running initial reports. And look for additional plug-in enhancements in the future (which I will try to announce here).

Ben Gaines
Ben Gaines

Vitor, Great questions. 1.) The plug-in gets initialized when the s_code.js file loads (so, in other words, it is initialized on page load). 2.) Using onunload has one major disadvantage: Sending data as the user leaves the page would dramatically inflate the number of Omniture server calls that the site generates. While this may technically work in many cases, we doubt that the added benefit is worth the cost of the additional server calls. I hope this helps! Ben

Ben Gaines
Ben Gaines

The labels could probably have been more intuitive. What I had in mind was the following categories: Up to 25% = 0-25% Up to 50% = 26-50% Up to 75% = 51-75% Up to 100% = 76-100% Keep in mind that the plug-in only passes the *maximum* percentage viewed. Obviously, 100% of users technically fall into the top group, but they will only be counted in the group that represents the lowest point on the page that they saw. Also, I should mention here that the numbers are completely fake. They don't even necessarily add up. They are almost entirely random, for display purposes only. The screen shots are really just intended to show what the reports would look like post-implementation.

Ben Gaines
Ben Gaines

We tested this (as did you!) and confirmed that the plug-in DOES record that as 100% (as it should).