That’s an artifact from the old site that we haven’t gotten rid of yet. Most links do not contain the page # and the photo # in them anymore - just the root reference (gallery #, popular scope, etc) and then the photo # after the hash.

We’ll track down the remaining lagged ones and sort them out.

Still doesn’t solve the urchinTracker problem, though, AFAICT.

Your example refers to page “123″ containing a subsection identifier of “456.”

Looking at a real SmugMug example such as today’s popular picture of a Wren, I see you are referencing the originally loaded URL as the page identifier, and then treating each subsequently loaded picture as a referenced subsection. Example: 124727245#53105411

It would make more sense to me if you instead used the URL of each picture being loaded, changing the displayed URL of the second picture to just 53105411, as the entire page has changed to represent that picture and its associated data, including the photographer, set, comments, etc. When that URL is shared you would be better representing the photographer and better tracking his photos by using his photo as the loaded page URL.

Basically what I’m saying is the destination photo becomes the newly loaded “page” loaded into urchinTracker and the last “page” is the referrer. Currently the entrance point receives too much weight, especially in the user-facing display URL.

Yes, except there’s a bug (or design?) in Google Analytics that drops everything after the hash, which nukes most AJAX apps tracking:

http://www.smugmug.com/gallery/123#456 becomes http://www.smugmug.com/gallery/123, and so does every other “page” in that gallery.

We’ve worked around it, but it’s nasty. We’d love to a real fix.

Yahoo Mail (Oddpost) and Windows Live Mail aren’t released products, though.