The magical # [ˈɑːktoʊθɔːrp]

But is this the only way the fragment can be used?

As you can put almost everything into the fragment it can also be used as a method to add query parameters to a page which is not sent to the server and thus can only be evaluated on the client. With this method it is possible to add state to a page without generating a new URL concerning SEO.

The case:

Sometimes it is necessary to track an interaction which at the end transitions to a new page. For example a user clicks on a product link on the product list and is immediately directed to the detail view of this product. Lets assume we want to know at which index the product was on the product list so that we can use this information to reorder the sorting on that product list in the future. To receive this information we would have to send a request to a tracking server with a specific key-value pair.

Possible solutions:

There are some solutions you could think of.

• One way is to send a client-side tracking request before the browser transitions to the next page. This approach has one big downside: We never know if the request actually succeeded. Some browsers kill all connections before loading a different page. To handle this we could wait until the request was successful and afterwards direct the user to the detail view page. But this is just as silly as it sounds.
• Another way is to somehow get the information to the next page and track it there. But how do we get this tracking information to the next page?
  • On one hand we could add a query parameter to the detail view page. This would result in a whole lot of different URLs for the very same product. This is not a good idea. First, it will destroy the caching mechanism of the site because each parameter added to the URL results in a new resource. And second, it will lead to a SEO problem: duplicate content.
  • On the other hand we could store the tracking information in a cookie. But then we would have problems managing the cookie values. The cookie size would increase and because they are always sent to the server we would also have an increase in traffic. Furthermore, you could get in trouble with multi tabbing because cookies aren’t stateless.

Our solution:

As you may have guessed - we store the tracking information inside the fragment. On the detail view page we extract this information, send the request and afterwards “clean up” the fragment. We decided to use the variable “t” and a json object as value.

Our link looks like this:

<a href=”/p/a-great-shoe-123456#t={‘listposition’:3}”>Shoe</a>

On body load a little javascript snippet (1) reads the fragment of the url, parses the value of variable t and sends this object to our tracking server. After this is done it removes variable t from the fragment. By doing this we make sure that if a user reloads the page or sends the link to a friend the tracking request is not sent again.

For reading and manipulating the fragment we use the open source jQuery plugin “BBQ"(http://benalman.com/projects/jquery-bbq-plugin/)

1) Snippet to extract tracking information and send it to our tracking server:

var trackingHash = $.bbq.getState('t'),
    t;
try {
    if (trackingHash) {
        t = JSON.parse(trackingHash);
        if (t) {
            sendData(t); // a function to send our data to the tracking server
            hash = $.deparam.fragment();
            delete hash.t;
            /* we do not want to create a new state in the browser so that the back button still works. */
            window.location.replace('#' + $.param(hash));
        }
    }
} catch (ignore) { }

Further use of this technique:

Of course tracking is not the only reason to add information to a new page. We also use this technique to execute a javascript function onload based on variables set in the fragment. For example, to open a layer immediately on a page or to directly switch to a tab other than the default tab and even to select the correct variation on a product detail view page.