getPercentPageViewed plug-inA few lucky Site­Cat­a­lyst users got a sneak pre­view show­ing of our Sum­mit ses­sion, and the nearly unan­i­mous reac­tion was that one of our three advanced tac­tics really stood out as the most excit­ing: the get­Per­cent­PageViewed plug-in, which (as the name sug­gests) allows Site­Cat­a­lyst to cap­ture the per­cent­age of a page (ver­ti­cally) that the user has viewed. Best of all, the plug-in is com­pletely free and avail­able to all Omni­ture users. You can down­load it, along with basic doc­u­men­ta­tion and instal­la­tion instruc­tions, from within Site­Cat­a­lyst by going to Help > Home, and then choos­ing Sup­port­ing Docs > Imple­men­ta­tion > Plug-ins from the left nav­i­ga­tion menu.

getPercentPageViewed—an overview

Omni­ture already offers a num­ber of tools to help you under­stand what users are doing on your site. As far as page design and lay­out analy­sis are con­cerned, you’re prob­a­bly famil­iar with ClickMap, which applies a graph­i­cal over­lay to links and but­tons to show you which page ele­ments your vis­i­tors are click­ing (and how often they’re click­ing them). But this is just one gauge of page con­sump­tion. There are plenty of sce­nar­ios 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 dis­posal? Are users find­ing the page ele­ments that you want them to find? This is exactly what the get­Per­cent­PageViewed plug-in does. It cal­cu­lates the length of the page (even adjust­ing if users resize their browser) and then deter­mines how far down vis­i­tors go before click­ing away. This value updates as the user scrolls, and will always retain the max­i­mum per­cent­age viewed—even if the user later scrolls back up to the top.

To imple­ment the plug-in, you will need the following:

  1. Two Cus­tom Traf­fic (s.prop) variables.
  2. A cor­re­la­tion between the two variables.

That’s it. You can do more with addi­tional s.prop vari­ables and cor­re­la­tions, but we’ll start out with just these two items.

NOTE: The plug-in can (obvi­ously) only deter­mine 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 reli­able way to cap­ture this data for a given page is on the next page view. Thus, we’re really cap­tur­ing “per­cent­age of pre­vi­ous page viewed,” but we can still marry this to the cor­rect page name for analy­sis. I’ll explain how to do it below.

First Cus­tom Traf­fic vari­able: Per­cent­age of Page Viewed

To the developer’s enor­mous credit, the plug-in is extremely easy to imple­ment. Instruc­tions are avail­able in the Knowl­edge Base, but essen­tially you drop the bulk of the code into your plug-ins sec­tion where you prob­a­bly already have other code snip­pets such as get­Query­Param and get­Val­Once. Then, within the s_doPlugins() func­tion, you make a call to the plug-in as shown below (using s.prop1 as our Cus­tom Traf­fic variable):

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

Sim­ple. How­ever, this doesn’t really give us any­thing action­able on its own. Just a bunch of num­bers rep­re­sent­ing the raw per­cent­ages viewed for all pages on your site:

getPercentPageViewed plug-in

The really use­ful data comes when we also cap­ture the pre­vi­ous page name (or pre­vi­ous site sec­tion, pre­vi­ous search term, etc.) into a sep­a­rate Cus­tom Traf­fic vari­able and enable a cor­re­la­tion between these two variables.

Sec­ond Cus­tom Traf­fic vari­able: Pre­vi­ous Page Name

As described above, the sec­ond Cus­tom Traf­fic vari­able cap­tures the pre­vi­ous page name so that we can break down page name by per­cent­age of page viewed, since that is where the magic hap­pens. For­tu­nately, there is another plug-in (avail­able in the same loca­tion as get­Per­cent­PageViewed) called get­Pre­vi­ous­Value which makes cap­tur­ing the pre­vi­ous page name easy. Instal­la­tion of get­Pre­vi­ous­Value is very sim­i­lar to instal­la­tion of get­Per­cent­PageViewed, and you would call the plug-in as shown here (using s.prop2 to cap­ture the pre­vi­ous page name):

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

That’s it. So, finally, com­bin­ing the two into a con­di­tional, here’s how we rec­om­mend imple­ment­ing 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 Cus­tom Traf­fic report in Site­Cat­a­lyst with a bunch of raw per­cent­ages, and another Cus­tom Traf­fic report that looks very sim­i­lar to your Pages report, except that it shows the pre­vi­ous page name for each page view.

Cor­re­la­tion

Adam Greco wrote about data cor­re­la­tions in a pre­vi­ous blog post, and I highly rec­om­mend read­ing his advice if you’re unclear on how cor­re­la­tions work or on how to set them up. In this case, you will want to enable a cor­re­la­tion between the two Cus­tom Traf­fic reports that cor­re­spond to the vari­ables that you’re using to grab the per­cent­age of page viewed and the pre­vi­ous page name. Once the cor­re­la­tion has been set up, you can go to the Pre­vi­ous Page Name report and click the green cor­re­la­tion icon to break down any page name by the Per­cent­age of Page Viewed report, giv­ing you some­thing like this if you chose to break down the “Home” page name:

getPercentPageViewed plug-in

This is start­ing to become use­ful. We can see that our home page typ­i­cally gets users to view around 50% of the page. If we have impor­tant links, ads, videos, etc., we prob­a­bly should put them in the top half of the page. Or maybe the page is alto­gether too long and could be shortened.

Another use­ful way to look at this data involves group­ing the var­i­ous per­cent­ages in the report using SAINT. Look­ing at the raw per­cent­ages (0−100) is a good start, but buck­et­ing can help bring to the fore­front trends that may be harder to see by view­ing the per­cent­ages as-is. And because you can add mul­ti­ple clas­si­fi­ca­tions to any report, you can actu­ally slice and dice your per­cent­ages in a vari­ety of ways: quar­tiles, quin­tiles, deciles, etc. This gives you eas­ily digestible reports, such as this one:

getPercentPageViewed plug-in

Where this gets even cooler is in the con­text of A/B test­ing. You can send var­i­ous page lay­out names into a Cus­tom Traf­fic report (using get­Pre­vi­ous­Value, of course) and cor­re­late with per­cent­age of page viewed to see how the dif­fer­ent options engage users dif­fer­ently. You’ll already know what they clicked, thanks to ClickMap or other reports, but the get­Per­cent­PageViewed plug-in can help you see how dif­fer­ent vari­ants affect page consumption.

You can do some great things with these reports.

  • On the sur­face of it, you can let your team know exactly how much “real estate” they real­is­ti­cally have to work with on key pages.
  • Key fea­tures that you want to high­light can be moved into the appro­pri­ate loca­tions where you know most users will see them.
  • Where appro­pri­ate, pages can be short­ened to lengths more suit­able to actual user behavior.
  • Cal­en­dar events can help show how site/page changes affected consumption.
  • Com­par­ing to ClickMap or cus­tom link data, you can under­stand the rela­tion­ships between view­ing a cer­tain por­tion of the page and click­ing on links within that por­tion of the page.

A few final ques­tions (and answers)

Q: Should I use a Cus­tom Con­ver­sion (eVar) vari­able as well (or instead)?

A: My feel­ing is gen­er­ally that a Cus­tom Traf­fic approach is best. Because the per­cent­age of page viewed is going to be cap­tured on every page, there isn’t much value to the per­sis­tence offered by eVars. The only use case that I can imag­ine for eVars in this sce­nario is the abil­ity to under­stand how page con­sump­tion on the entry page affects con­ver­sion (which could be accom­plished by using the plug-in to pop­u­late an eVar set to “Orig­i­nal Value” so that the entry page receives credit for the con­ver­sion). For the major­ity of users, the real value here is sim­ply in under­stand­ing how page lay­outs and lengths are work­ing, which can be accom­plished using a Cus­tom Traf­fic variable.

Q: What hap­pens if users aban­don my site? Do we still get to see how much of the page they viewed?

A: Because the plug-in cap­tures the per­cent­age of the pre­vi­ous page that the user viewed, if users close their web browsers, click a browser book­mark, or enter a dif­fer­ent URL in their address bar, Site­Cat­a­lyst will not receive the per­cent­age for that final page (as there is no “next page” on which to cap­ture the data). How­ever, if the user clicks an exit link, the per­cent­age of the page that the user viewed will be cap­tured prior to the user leav­ing your site.

Q: What if users resize their browser horizontally?

A: It will have no effect on the plug-in’s abil­ity to cap­ture the per­cent­age ver­ti­cally. If resiz­ing the browser changes the max­i­mum length of the page, the plug-in will adjust to it.

We have already seen Site­Cat­a­lyst users do some great analy­sis and opti­miza­tion based on this func­tion­al­ity, so hope­fully you’re as excited about this new plug-in as I am. Next time, we’ll cover the final topic from my Sum­mit ses­sion: par­tic­i­pa­tion. (Adam already described this fea­ture, but we have a few things to add.) Of course, if you have any ques­tions about get­Per­cent­PageViewed, either based on this blog post or on the con­tent we shared at Omni­ture Sum­mit (or if you asked a ques­tion at Sum­mit and we didn’t get a chance to answer it!), please let me know by leav­ing a com­ment here. You can also con­tact me via Twit­ter (@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).