Use URL Search/Replace to Undo Hard-Coded Content Groups

URL Search & Replace – using it to remove hard-coded content groups from your reports.


This post is about a specific use for the Webtrends “URL Search and Replace” functionality.  We wrote about URL S&R in a general way in this post.

You should know about URL S&R because once in a while it’s very helpful.  Irreplaceable, in fact (haha).


Basically, what URL Search/Replace does is this:

The first task the Webtrends processing engine performs is to look at the URL of the hit it’s about to process and to check whether any “Search and Replace” rule matches that URL.  If yes, it makes the specified change then sends the altered hit to be processed as usual.  If no, it sends the original hit, unchanged, to be processed as usual.  That’s it.  The important thing that makes it so useful is that Webtrends does this before absolutely any other processing of that hit.

I don’t know of any other web analytics tool that allows this, but I could be wrong.

Examples of uses:

  • Take a dedicated landing page URL and add the WT.mc_id parameter that you should’ve put there in the first place, but forgot to do, in order to get the traffic to show in campaign reports that depend on seeing WT.mc_id.
  • Change “redir.jsp?” into “” so you can see redirects in pages reports in a less confusing way.
  • Remove the parameter “sessionID=whatever” from all URLs in case you have those kinds of archaic things happening.
  • (if you process server logs rather than SDC data) change an important image into a page file, i.e. change “importantimage.jpg” into “importantimage.html”.

And, the subject of today’s post …

  • Make Webtrends completely ignore any hard-coded content groups (WT.cg_n) and only use the UI-defined content groups you have turned on for that profile.

Why?  If you have hard-coded content groups, they will show up everywhere  – in content group reports and also in content group path reports.  If you want to look at back-and-forth travel among a few select content groups that you defined in the UI, those hard-coded groups mess up everything.  (I know some of you out there have discovered Content Group paths, so this post is for you!)

The answer to the mess is to devote a profile to those select UI-defined content groups and, in that profile, make Webtrends blind to the hard coded ones.

Here’s how:

Since hard-coded content groups contain the text “WT.cg_n=<something>&” you can “remove” them all with this configuration in the S&R interface:

    • Replace from
    • Start of first
    • WT.cg_n=
    • Up to
    • End of next
    • &
    • with
    • <empty field> (i.e. nothin’)

Note that this will leave any content subgroups in place, which is not a big deal – these don’t show in Content Group reports, the Content Group dimension, Content Group paths, or anything else.  If you really want to suppress the subgroups also, use the specification below which relies on the fact that the WT.sys parameter pretty much always follows WT.cg_n.  (You might want to check with a debugger or in an actual log file to be absolutely sure)

    • Replace from
    • Start of first
    • WT.cg_n=
    • Up to
    • Start of next
    • WT.sys=
    • with
    • <empty field>

That’s it.  Once you have made the S&R rule, just turn it on for the selected profile.  Make sure only the important UI-defined content groups are active in that profile.

If you have any other outrageous examples of using URL S&R, let us know!


I realize that Webtrends probably prefers that we only use hard-coded content groups and that they (Webtrends) are trying to lead us in that direction.  It’s true that UI-created content groups use processing time and may not make it easy to architect some functions and reports.  But I think that’s a bit wrong-headed, because the UI-based ones are so much more versatile.  Google Analytics’ recent addition of content groups to their UI is, I think, validation of this.  First of all, UI-defined content groups can be created really fast.  Second, they can be turned on and off as needed, just by assigning/unassigning them to a profile, individually.  Agree?  Disagree?  Feel free to write to us.