Managing www’s in the Pages report
(Applies to: software)
If this is happening then your underlying problem is that your site server is set up wrong. Talk to somebody in charge of the servers and ask about making all requests for “yoursite.com” redirect (301 type) to “www.yoursite.com.” If they tell you they don’t know how to do it, question their right to hold their current position. They’ve already got one foot over the line by letting this happen in the first place.
Meanwhile, here is a more constructive workaround if you use software. You have to make a change in a config file. If you re-analyze data, the old data will be corrected. If you don’t re-analyze old data, your new data will be okay, but any page reports referring to old data will show those problem domain names. It’s best to re-analyze. Re-analysis is one of the perks of having the software version of WebTrends.
Here’s the trick. Add the following line to the [profile] section of the profile’s .wlp file:
overridemultihome = 1
This line forces WebTrends to ignore the “host domain” field of logs. WebTrends will instead display, as the domain in pages reports, whatever you entered as the Web Site URL field in the Home tab of the profile’s setup.
You have to be a little careful. This is all or nothing. All domain names in the logs will be overridden. If your logs have other important domains in them, think about other solutions such as editing the logs before analyzing them.
However, domain name filters (applied at the profile level) will still work! The multi-home domain filter takes effect before the domain name suppression happens.
What? You don’t know about .wlp files? See the .wlp file topic.
8 comments
Not sure I understand your advise about “rolling” it over and how easy it is etc.
To me, this isn’t a technical decision, but a marketing and reporting decision.
I’m happy to learn if I am incorrect, and happy to continue thread as well.
If you setup DNS to resolve the same for domain.com and http://www.domain.com, you get 2 entries as discussed.
If you set up a error based re-direct and or a client side re-direct, you cold lose your referrer data when the re-direct occurs (based on choices).
If you set up a http server side re-direct you need to be careful of how you code it as the URL typed and URL re-direct need to be the same or it doesn’t re-direct.
Marketing loves to drop the “www” as it looks cool without it. Reporting is a problem as you written there are now 2 entries and using multi-home domain in wlp can aggregate more than you choose.
Therefore, I’m a proponent of the multi-home domain and ensuring that I don’t have too many different domains in the same log. Our Webserver software is capable of seperating the log files at the time they are written to help in this matter.
Again, always eager to learn. – Dave
Dave, you’re an honorary Outsider.
You’re right about the various types of re-direct and “rolling over” was too vague. 301, server-side, redirect then. I’ve changed the text.
You’re right about no www being a marketing preference much of the time. It looks cooler. However, a server-side redirect allows the use of the non-www version in any links or destination URLs (where coolness counts) while at the same time accomplishing the reporting goal of flipping the visitor over to www once they arrive on the site, where coolness in the address bar doesn’t matter. (Or so we hope. If the coolness factor is still effective in the address bar, then subtleties in tiny design & IA details matter far more than in our wildest dreams, and we’d better start testing shades of font color and differences between Verdana’s and Arial’s effects.)
I think the strongest reasons for getting all hits on the same site domain are: 1) not needing webserver software to compensate, and 2) not offending search engines, which supposedly dislike finding the exact same page associated with two sites, and “www” and “non-www” apparently can count as “two sites.”
I still want to stand behind my snarky remark about “letting this happen in the first place,” although I will get off my high horse to do the standing.
Speaking in terms of “usually” and “my experience,” the situation seems to happen most of the time because somebody in IT didn’t know enough to realize it can be done, and/or knew about it but didn’t think it mattered enough to set up that redirect, and/or let marketing’s preferences roll them over without offering constructive alternatives. Your own alternative solution, using webserver software to sort things out first, is obviously not in the category of not-knowing, not-caring, but it’s the exception.
Always learning, I now understand that Apache server has a simple domain re-write capabilitiy that I can’t or don’t know how to do with SunOne JWS. If/When we change over, That is one of my first features to learn.
As I understand it, the http server will re-write on the fly and add/remove the www for us, thus (hopefully) providing single entries in the logs. – - Dave
A question about this. I think one of the things that could also be impacted by the change to overridemultihome = 1 would be that all offsite links would now appear as onsite, correct? This would then invalidate the offsite links reports. I am correct about this?
Bob – I don’t think so, but I will do some testing to be sure. What overridemultihome does is make WebTrends ignore the “host domain” field in the logs. The offsite links that are collected by the Advanced SDC tag don’t insert anything into the host domain field — they change the URI field, the WT.es parameter, and the WT.ti parameter. I’ll have to check on this list also — we have changed the basic tag a bit so our tag affects the title and URI parameter a bit differently.
But right now my money is on testing showing that the offsite links still show as offsite, with the foreign domain displaying as usual in the URL.
Just to make things more complicated, you actually have touched on an interesting issue, or flaw, in the SDC tag that we’ve recently discovered. There are some situations where the tag clears the host field — hits with no host at all. This means filtered based on site host, or domain, don’t affect these hits. More testing by The Outsiders and we’ll publish the details. (Yes, we have told WebTrends about it.)
Hi Rocky,
Would this trick work for forcing https links on say a pages report for a secured site?
Hi Adam, no, it only has to do with the domain’s prefix, not the http/https part of the address.
Leave a Comment