Pre­vi­ously, I’ve dis­cussed how visit and vis­i­tor mea­sure­ment works in Site­Cat­a­lyst. How­ever, there are some nuances that I haven’t men­tioned, and which can wreak havoc on an oth­er­wise solid imple­men­ta­tion. I have seen numer­ous cases of good devel­op­ment ham­pered by minor errors which cause visit and vis­i­tor infla­tion, so I’d like to dis­cuss briefly a few ways that you can ensure that you aren’t dupli­cat­ing these metrics.

Make sure that key con­fig­u­ra­tion vari­ables are always consistent—even across col­lec­tion methods

This is a com­mon prob­lem which is, unfor­tu­nately, easy to make. You’ve imple­mented a first-party data col­lec­tion domain in JavaScript (in your s_code.js file) using the s.trackingServer and s.trackingServerSecure vari­ables. For exam­ple:


This will cause the s_vi cookie to be set on, and read from, the “myawe​some​site​.com” domain. Now let’s say you begin to imple­ment Site­Cat­a­lyst in a Flash appli­ca­tion that will live on your site. You down­load the Action­Source code and com­po­nent from Site­Cat­a­lyst. In your excite­ment, you for­get to imple­ment the two vari­ables dis­cussed above:


This will cause your Flash appli­ca­tion to use a dif­fer­ent data col­lec­tion domain than your JavaScript code. The result? One vis­i­tor ID value for JavaScript image requests and a sep­a­rate vis­i­tor ID value for Flash image requests, which means that you’ve dupli­cated vis­its and unique vis­i­tors for any­one who touches both your Flash and your non-Flash implementation.

The same thing applies (although a bit dif­fer­ently) when mix­ing JavaScript and Data Inser­tion (XML) API imple­men­ta­tion. There, you would want to read and parse the vis­i­tor ID cookie value in your API imple­men­ta­tion and pass it using the <vis­i­torid> ele­ment. If you pass a dif­fer­ent <vis­i­torid> value, or leave <vis­i­torid> out of your imple­men­ta­tion, Site­Cat­a­lyst will not tie the data passed via the API to the data passed using JavaScript, even if all of this data came from the same user.

Leave that s.visitorNamespace vari­able alone

This applies pri­mar­ily to those imple­men­ta­tions based on third-party data col­lec­tion domains. As described briefly above, the data col­lec­tion domain deter­mines where the vis­i­tor ID is set; as such, it must be con­sis­tent from page view to page view and from visit to visit. The s.visitorNamespace vari­able con­trols the sub­do­main for data col­lec­tion. Because it fre­quently matches or sug­gests the name of your orga­ni­za­tion, you may feel tempted to change it when your company’s name changes or when you are intro­duc­ing a new brand.


These two vari­ables (given the absence of the s.trackingServer and s.trackingServerSecure vari­ables) will cause the data col­lec­tion domain to be “myawe​some​site​.112​.2o7​.net.” Chang­ing the vis­i­tor­Name­space vari­able will not pre­vent data col­lec­tion, so it’s pos­si­ble that a change here would go unde­tected. But since the data col­lec­tion domain has changed, every vis­i­tor will be treated as brand new. This is com­monly called “vis­i­tor cliff­ing.” Since every vis­i­tor becomes a new vis­i­tor, unique vis­i­tor met­rics will spike; “life­time” reports, such as Return Fre­quency, Visit Num­ber, and Orig­i­nal Refer­ring Domain will be “reset.”

Within a sin­gle site, stick to one global JavaScript file

I can­not think of a good rea­son to have mul­ti­ple s_code.js files on a sin­gle web site, but I do see this from time to time. I under­stand that cer­tain pages may require dif­fer­ent vari­ables to be set in dif­fer­ent ways (e.g., you use “cid=” in the query para­me­ter to cap­ture cam­paign track­ing codes on pages owned by your team, but another team uses “cam­paign=” and can­not change this), but this should still be pos­si­ble by set­ting vari­ables dynam­i­cally within a sin­gle file. Using mul­ti­ple s_code.js files only increases the like­li­hood of a dis­crep­ancy between key con­fig­u­ra­tion vari­ables, such as those dis­cussed above. For exam­ple, if you use a first-party data col­lec­tion domain, this may be set in one file, but not in another, which would cause the sec­ond file to rely on a third-party domain. The effect would be sim­i­lar to the point above regard­ing the inclu­sion of s.trackingServer and s.trackingServerSecure in all forms of data col­lec­tion; because the two JavaScript files would not con­tain the same con­fig­u­ra­tion vari­ables, you would end up with mul­ti­ple vis­i­tor IDs and, thus, mul­ti­ple vis­its and vis­i­tor counts.

So what can you do to detect these prob­lems when they occur (so that you can cor­rect them using the infor­ma­tion above)?

1. Always debug using vis­its and visitors—not just page views
Check­ing your Pages report and your Cus­tom Traf­fic reports is impor­tant, but they may not always tell the whole story—at least when show­ing the Page Views met­ric. A visit may involve a num­ber of page views for a cer­tain line item in a Cus­tom Traf­fic report, but if the num­ber of vis­its matches the num­ber of Page Views, you might have a prob­lem with visit and vis­i­tor mea­sure­ment. Also, make sure to com­pare vis­its and vis­i­tors to pre­vi­ous time peri­ods. Some spikes are nat­ural and good—the result of mar­ket­ing efforts—but sud­den spikes in vis­its and vis­i­tors that cor­re­spond to imple­men­ta­tion changes made on your web site can be a sign of trouble.

2. Check “life­time” reports
If you typ­i­cally see 60% first-time vis­its, and that num­ber jumps to 90% all of a sud­den, it prob­a­bly isn’t that you’re dri­ving away your loyal cus­tomers. Rather, you may be see­ing vis­i­tor cliff­ing in action.

3. Use a packet mon­i­tor while brows­ing your site
There are a num­ber of debug­ging tools that will show you the data col­lec­tion domain that your Site­Cat­a­lyst imple­men­ta­tion uses. You can use these tools to detect changes—both against his­tor­i­cal data col­lec­tion, and from image request to image request on your site. For exam­ple, Tam­per Data for Fire­fox will show all image requests and will update with new ones as you browse. Sim­ply look at the begin­ning of each request URL to con­firm that the data col­lec­tion domain is con­sis­tent. For bonus credit, you can double-click the “Cook­ies” details for each request to ensure that the s_vi value is con­sis­tent from request to request.

For­tu­nately, issues involv­ing visit and vis­i­tor infla­tion are rare. These issues prob­a­bly aren’t affect­ing your data, but when they do arise, they can be dif­fi­cult to trou­bleshoot and can give even the best ana­lysts severe headaches. I don’t want that to hap­pen, so I hope this helps you under­stand the process that you might fol­low in val­i­dat­ing an imple­men­ta­tion against visit and vis­i­tor infla­tion, as well as what you can do if you are see­ing strange things in your data.

As always, please leave a com­ment with any ques­tions, thoughts, or sug­ges­tions that you may have! I’m also avail­able Twit­ter, Friend­Feed, LinkedIn, or by e-mailing omni­ture care [at] omni­ture dot com.