Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Page URLs reports: allow to aggregate Hash tag values #3232

anonymous-piwik-user opened this Issue · 15 comments

4 participants


This is the original post here : [,90224]


I hope I'm not missing anything, but I thought I'd post something in here before I went crazy. I have built an AJAX application that relies on hash tags to navigate through the page. We need to keep track of each of the individual hash tags, but the only report I'm aware of that shows the pages that a user has visited is logging in to the Piwik Dashboard and going to Actions>Pages. I've attached two screenshots to help show my point. One is of the Piwik interface and you can see one of the files (2551-0.php) is the only page in it. The second screenshot shows my database and the log_action table showing that there are different hash tags being recorded for 2551-0.php.

My question is if I'm missing something and need to set a preference somewhere to show all the different hash tags within a given page, or if this is a (un)known issue that has(n't) been addressed.

Response by matt:

you are right this is an issue that hasn't been dealt with yet. What happens is that we record the pages with the hash, but then at archiving time, we actually aggregate on the URLs without the hash.

we could probably easily allow to keep the hash values and show stats for each hashvalue. please create a ticket if you want this
Keywords: ajax, hashtag, hash, hash value


There are several ways we could deal with this issue:

  • Configuration file setting "piwik wide" to enable "Keep Hash tag values in the Page URLs"
  • We could add a per-website setting "Keep Hash tag values in page Urls"
  • Provide a Javascript function allowHashTags() that would forward the hash tags only if called -- otherwise the JS and PHP tracker would remove hash tags.

Also see this interesting post for a use case of tracking with hash tags:


If I could offer my opinion, in my case, this would be great as a global setting. I have about 700 sites (and climbing) that are using this hashtag feature.


Alternatively we could also have a setting "Disable hash tags" which could be enabled by default, where hash tags are used for campaigns tracking (eg. #pk_campign=X&pk_kwd=Y), but are removed before being recorded in log_action.

Let's do this new default setting (disabled hash tag, default is disabled, when enabled it will track each hash tag as different pageview).


I think it's important to be consistent between the actions report and the database. This means that when hash tags are enabled, they should be recorded in the DB and shown in the pages report. When they are disabled, they should be included in neither of them.


(In [7113])
Refs #3332

  • Transition works for Page titles with hierarchy (eg "$Category / $name")
  • URL metadata:
    • is only available on non Summary rows.
    • It is now set to the page with highest number of visits, when page names do overwrite.
  • However now, by default we do track keep hash tags and we do not aggregate them in one page URL.
    • Refs #3232 Will be nice to have, to allow to "not track fragment" by default. See stub processUrlFragment(). More to do: Admin UI, Tests w/ and wo/ hash tags, w/ Capital letter in hostname
    • URL being tracked, and URL read from the logs (for backward compatibility) are now cleaned: hostname is lowered, and URL Fragment is kept/removed.

Here is a proposal spec:

  • New Global setting "Remove hash tags from the Page URL"
    • By default, we will remove all hash tags as of the release containing this fix
  • Each website by default use the global setting, but can overwrite and change the value.
    • Below the textarea "Excluded parameters" is the new setting
    • DB: a site has a new column "url_fragment" with values 0 (use default), 1 (keep fragment), 2 (delete fragment). Update sets all sites to 0 to use default (ie. remove all hash tags).

In ac59017: Fixes #3232, add ability to discard URL fragments when tracking for all websites or for just some websites.


In 3069034: Fixing test failure regression introduced in previous commit.

refs #3232


In 4124ad4: refs #3232 Minor changes


Code review

  • Nice commit, I like your naming choices & General Setting UI.
  • for this preference, a new column is not necessary as most users don't need to change the default. So I suggest instead to add, below the tooltip of the "URLs" columns, the following:
  Keep Page URL fragments when tracking Page URLs [ No (default) ] ```

SELECT values are eg. 
* No (default)
* Yes
* No

This way the setting is not very visible (good because it's not used often) and it does not add more horizontal scrolling. 


In da85ebe: Fixes #3232, remove keep url fragments column in website table and move to under URLs column in edit mode.



  • I think this new label change + "Default (No)" will help understanding the feature better: Keep Page URL fragments when tracking Page URLs [ No (default) ]

In d8dd525: Refs #3232, tweaks

@anonymous-piwik-user anonymous-piwik-user added this to the 1.11 - Piwik 1.11 milestone
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.