Robbin

However, ba+? could be written much simpler to match this pattern.

why not use ba only that will match only one character of a after b. ba+? looks like it might work but confuses.

Is ba+? formulation needed because GA RegEx is different or is this your way of matching a pattern of ba ?

Thank you in advance for your reply.

Alexander

/Category/default\.aspx

That way, Category/Product1 (etc) will still get included. The exclude I did above is very specific and doesn’t encompass the other pages that you want included.

http://www.domainname.com/Category/default.aspx —– Filter out this page

But keep track for all page under http://www.domainname.com/Category/Product1, http://www.domainname.com/Category/Product1 , etc.

Nice post …

Edward

My apologies Alan. Please take my prior in the positive light of good intent, and not as the ravings of a pompous windbag. No matter how accurate the latter may be.

Cheers!
- Steve

So let Google worry that these are slightly slow. People used to say, don’t use a star * because it slows down the processing. And does anyone listen? No. And their processing is just fine (well, if it isn’t fine, it’s not because of their choice of RegEx…)

Chapter 4 of the O’Reilly “Mastering Regular Expressions” (MRE) has a … deep explanation of these “lazy” expressions as Jeff refers to them. “Greedy” or “Lazy”. Sigh. IT people and the art of *bad* punning.

Alan, lazy expressions are, in my experience, generally slower than greedy ones. I have a program that does a lot of matching using the actual PCRE library[1]. Lots of ‘[^ ]+ ‘ (left_square not space right_square plus space) style of thing. Replacing with ‘.+? ‘ (dot plus question space) to get the equivalent lazy?
Go from ~ 80,000 lines/sec to ~65,000 lines/sec. If you read on to Chapter 6 in MRE, Jeff explains the whys and hows of this observed slowdown.
Without going into the detail, lazy expressions can cause the underlying engine to do more work. Of course, by “tomorrow” there may be new and improved optimisations that render the previous statements incorrect. [2]

Now as far as GA is concerned? Super speedy regex’s aren’t something we really need to worry about. Google do, we don’t. Yet. In that situation, I recommend going for what you find easiest to *understand*.

Do be aware that: “.*?/” vs ‘[^/]*’ will give different answers! They are not identical as written. What you probably want to compare with is: ‘[^/]*/’.

Cheers!
- Steve

[1] http://www.pcre.org. Has links to the Perl RegEx docco. Which could be a bit … hairy for many readers. And very perl specific.
[2] The optimisation we use is to have two regex’s. One, using greedy, is for most of the work. If that fails, we switch to the slightly more complex, plus lazy usage to try and match a 2nd time. Thus we get the best of both worlds. Speed and Correctness. It’s possible that Justin (who knows way more about GA ins and outs than me) may know of a way to expose and use such a double hit filter????