Blog Post: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. 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).
Author: Date Created:March 10, 2010 Date Published: Headline:Summit Topic #2: getPercentPageViewed plug-in Social Counts: Keywords: Publisher:Adobe Image:https://blogs.adobe.com/digitalmarketing/wp-content/uploads/no-image/no-image.jpg

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).