Address Bar Sharing Analytics is a new feature that measures how often users share your site by copying the page URL from their address bar and sending it via email, IM or other channels. This type of sharing is often the biggest source of viral traffic to your site but is misreported by traditional site analytics tools as “direct traffic”. Address Bar Sharing Analytics depends on a cutting-edge browser feature called the History API. You can use it on any page but it will only be active for site visitors who are using a supported browser.
How it Works
Address bar share tracking works by appending a special tag to your URL once your page has loaded. Your URLs will start to look like this:
In this case, “#AHb4gs1hwck” is a semi-random value which identifies each page view. When a user clicks on an URL like this we’ll know that they were the recipient of an address bar share and we’ll count a share and a click for your site. This tag contains the time that the page was viewed by the sharer so we can properly attribute the share. If that recipient subsequently shares your page to someone else, we’ll be able to measure it separately as a “reshare”, taking into account the various generations of your viral sharing.
Note: these types of tags (called URL fragments) will not affect your SEO because they are discarded by search engines during web crawling.
You can activate address bar share tracking on pages that have AddThis installed, using a client api parameter:
var addthis_config =
This will activate address bar share tracking for all pages that have addthis code except for your homepage. Many users like to have clean homepage urls so we leave it alone by default. You can customize this behavior with the data_track_addressbar_paths configuration option:
var addthis_config =
Your address bar shares and clicks will show up in several places in the analytics console:
As a new service called “Address Bar Sharing” throughout the reports.
Added to the total shares, clicks and viral lift in your summary report.
The interests of clickers on address bar shares will be factored in to your audience report.
A new service detail page for address bar shares, with content shared via the address bar.
Our URL tagging relies on a cutting-edge browser feature called the History API. There are other techniques for tagging URLs but we avoid them because they break browser functionality. Our coverage will grow as users update their browsers but currently address bar share tracking is only available in these browsers:
This means that we can only directly measure a portion of your address bar shares. We cover 45% of browsers worldwide according to statcounter. Our analytics console will show you the number of actual shares measured and an extrapolation of the total amount based on the mix of browsers who share on your site using our buttons.
SEO & Address bar sharing
Our address bar sharing uses URL fragments so it is compatible with search engines. These fragments will not affect your SEO because search engines discard them when indexing the web. URL fragments are also not transmitted from browsers to web servers so our tags should be compatible with other web analytics tools.
URL Fragment Compatibility
What if my site uses URL fragments?
If you use fragments to reference in-page anchors, for example a table of contents which links to: http://www.example.com/help.html#getting-started
your links will continue to work properly. Similarly, if a user clicks a link to your site that contains a fragment, the page will scroll to your anchor as expected and we won’t modify the URL. We respect your fragments in these cases, however this limits our ability to detect whether users subsequently share since the URL won’t have our tracking fragment. You may have more shares and clicks than we report in our analytics, depending on how often URLs with fragments are shared.
If your site makes extensive use of fragments to create dynamic “hash-bang” or AJAX URLs it is probably not compatible with Address Bar Sharing Analytics.
For example: http://twitter.com/#!/addthis
In this example, the #! fragment will be present on every page view, conflicting with the URL fragment that we would place. We’re looking into solutions that will address this compatibility issue. However, instead of hash bang URLs, we recommend using the History API (on supported browsers) to store your dynamic state in the URL path and parameters, leaving our fragment intact.
Was this article helpful to you?
Last modified: December 8th, 2015