@anonymous-matomo-user opened this Issue on June 18th 2012

This is the original post here : [http://forum.piwik.org/read.php?2,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

@anonymous-matomo-user commented on June 18th 2012
@anonymous-matomo-user commented on June 18th 2012
@mattab commented on June 19th 2012 Member

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: http://www.e-nor.com/blog/web-analytics/tracking-traffic-from-press-releases-in-google-analytics

@anonymous-matomo-user commented on June 19th 2012

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.

@mattab commented on August 22nd 2012 Member

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).

@BeezyT commented on September 25th 2012 Member

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.

@mattab commented on October 7th 2012 Member

(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.
@mattab commented on October 7th 2012 Member

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).
@diosmosis commented on February 10th 2013 Member

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

@anonymous-matomo-user commented on February 10th 2013

In 306903417533764104be0a18540b6194da923708: Fixing test failure regression introduced in previous commit.

refs #3232

@mattab commented on February 11th 2013 Member

In 4124ad4e250b0e62d8a21627e425b5f2b6c3845b: refs #3232 Minor changes

@mattab commented on February 11th 2013 Member

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. 
@diosmosis commented on February 11th 2013 Member

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

@mattab commented on February 11th 2013 Member


  • I think this new label change + "Default (No)" will help understanding the feature better: Keep Page URL fragments when tracking Page URLs [ No (default) ]
@mattab commented on February 15th 2013 Member

In d8dd525cb28003343483118f8aaac18bee6d308b: Refs #3232, tweaks

This Issue was closed on February 15th 2013
Powered by GitHub Issue Mirror