Feature request : mod_rewrite track final page

[dandumit]

First of all a BIG THank you for this beautiful and useful application.
I am using a solution based on PrestaShop.
For SEO purposes it's using mod_rewrite .
Clickheat traces the original page url . IT would be more usefull to track destination page + posibility to filter on parameters sent.
For example , on this URL
.index.php.id_product.1119.controller.product.utm_source.shopmania.utm_medium.cpc.utm_campaign.direct_link

It would be usefull to track/view together all pages like:
.index.php.controller.product.

regardless of other parameters. This will allow to track user interest on all generic product page.

Br,
Daniel

[dugwood]

Hello Daniel,

As a default, we track the full page's URI, as the page may be really different with query parameters (especially on an ecommerce website).

On your example, I don't see any SEO/mod_rewrite active: if it was the case, you won't have any index.php nor controller in your URL: ClickHeat is run from the user's browser, not on the server, so the URL you have is the URL the user sees. So you may have a big issue here (not related to ClickHeat).

Now, for the useful stuff: you may have selected «use webpage's URL» in the Javascript copy/paste code. If that's the case, you would see:

clickHeatGroup = encodeURIComponent(window.location.pathname+window.location.search);

If you want to remove the query string parameters, remove the search concatenation, like this:

clickHeatGroup = encodeURIComponent(window.location.pathname);

This way all pages will be grouped against the URL part without query parameters (part after the ?).

I'm closing this, but reply or reopen if it's not good enough for you :-)

[dandumit]

First of all , thank you again for fast and complete answer !
I like a lot your solution. I like that it's using text files not databases and I like that is light!
I was 99% sure about this answer.
I am willing as well to help on this product features increase.
This application it's very good and important for eCommerce sites.

What I am proposing : to have option to paste on a config section of clickheat the .htaccess part with rewrite rules, parse passed url against those rules and group results on those + option to include some or all parameters passed.

What do you think ?
Please note that I am willing to help here !

BR,
DAniel

[dugwood]

Daniel, I don't think it's a good idea to mix rewrite rules with ClickHeat. ClickHeat doesn't know about it, and I think it's a good thing:

• the client (either you or the ecommerce's owner) don't know about these rules: can't understand why the URLs are not the same as the website's ones (or the one found in Analytics solutions)
• this means that ClickHeat needs to access a specific file: it may not be available, for example in distant mode
• most of the time the rewrite rule is very similar to the original path: /index.php?product_id=12 will be rewritten as /products/12-some-keywords.html, so you can still group both with a main information (product_id or /products/) and a unique identifier (12)

Removing some parameters could be an improvement of the app, or perhaps the other way around: only include product_id for example.

Regards,
Yvan.

[dandumit]

Thank you for answering at object and very pertinent.
Adopting your approach (running on same server as the application) gives some good advantages even over high paid applications.

In eCommerce a lot of people tries to improve a form and general customer interaction with site.
Some of them are doing does A/B testing when they have enough traffic.
(it's not my case and it's not the case for many other )

This improvement it's based on formatting some simple templates/web forms like is product from . product list /etc.

That's why I think that would be a welcome improvement. Indeed users cannot/do not know about .htaccess file but this can be read automatically by application. However further more , translating url's and selecting only some parameters may be a bit tricky and probably will be needed a database.

And last not least, if I can help on this development please tell me !

Thank you,
DAniel

[dugwood]

I understand your need... but it's a big work, should I say a huge one. And it doesn't take care about other webservers: lighttpd, nginx...

Following the KISS principle, this is not something I would agree upon.

If you do some A/B testing, then you may have another information: either it's a user's cookie, or a PHP variable that you can add in the clickHeatGroup definition using a simple <?php echo $testAorB ?>.

Removing parameters from the URL is quite easy, and may just be added in the pasted code. But that's a new development... maybe I'll think about it, it's a good idea (=> open a new issue for this if needed).

The best clickHeatGroup is the one you create (either manually or using PHP), because it will reflect your real application. Instead of .index.php.product_id.12, you could write product-12, which is far better in the dropdown list :-)

[dandumit]

Loading those records on a database, processing would be easy. however like you said this means a lot of development. There are more things to have in mind when removing from parameters. Like what image will be served from site ? For example : Minimum product id ? Maximum id ? Tomorrow I will try to look on code to see how complicate would be to use for example an sqlite database instead of file storage. However I don't know how to interpret rewrite rules. I cannot implement this by myself. Thank you, DAniel

…

On Thu, Jan 25, 2018 at 1:05 PM, Yvan ***@***.***> wrote: I understand your need... but it's a big work, should I say a huge one. And it doesn't take care about other webservers: lighttpd, nginx... Following the KISS principle, this is not something I would agree upon. If you do some A/B testing, then you may have another information: either it's a user's cookie, or a PHP variable that you can add in the clickHeatGroup definition using a simple <?php echo $testAorB ?>. Removing parameters from the URL is quite easy, and may just be added in the pasted code. But that's a new development... maybe I'll think about it, it's a good idea (=> open a new issue for this if needed). The best clickHeatGroup is the one you create (either manually or using PHP), because it will reflect your real application. Instead of .index.php.product_id.12, you could write product-12, which is far better in the dropdown list :-) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#21 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAo7WM9XaeH3ZYX_FrWVmfs0bRC7bCqLks5tOF_fgaJpZM4RsjGI> .

[dugwood]

You have to define what you want to look at. Although I've done it somehow differently on https://github.com/dugwood/botsector by narrowing doing depending on the path, but this will group pages based on path, not on page format.

So if you know that some pages are look-alike, you may group these together using the manual clickHeatGroup. On the contrary if you want to analyze every page separately, you just leave it to the full url group.

It's difficult to do this without a database. My plan was in the long run to group everything in a database, where you would have been able to filter by url, just like you can do with Analytics and the like. That's the 2.0 that may be created one day :-)

[dandumit]

Excellent function ! we are just few little steps close to a very nice functionality. Meanwhile I have been lurking about a function that does what mode_rewrite of apache does : take as input "beautifull url" apply rules from .htaccess returns and records "ugly url". Now apply "clickHeatGroup" over list of "ugly url" will result that WONDERFUL functionality that even paid services do not have !

…

On Thu, Jan 25, 2018 at 3:35 PM, Yvan ***@***.***> wrote: You have to define what you want to look at. Although I've done it somehow differently on https://github.com/dugwood/botsector by narrowing doing depending on the path, but this will group pages based on path, not on page format. So if you know that some pages are look-alike, you may group these together using the manual clickHeatGroup. On the contrary if you want to analyze every page separately, you just leave it to the full url group. It's difficult to do this without a database. My plan was in the long run to group everything in a database, where you would have been able to filter by url, just like you can do with Analytics and the like. That's the 2.0 that may be created one day :-) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#21 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAo7WItcmVedY9GAMlrlUtuocrgw_8ryks5tOIMugaJpZM4RsjGI> .

[dugwood]

I've added it here: #22

Thanks for your ideas and needs :-)