We would like to propose an advanced page to allow users to generate a tailor made javascript code for their pages.
Some options that this Javascript Tracking tag generator would include are:
Others:
Could we display a notice about each method pros and cons to help the user pick a method tailored to its needs?
see also #1657
Such JS tag config screen would have a checkbox "Track unique visitors across subdomains of $WEBSITE_HOST"
which would add the following line:
piwikTracker.setDomainName('.example.org')
which will force 1st party cookie to be set across
all subdomains (see #409 )
If we push the use of asynchronous tracking code, how do we update the documentation, since there will be 2 ways of configuring the tracker? For example, we could have an inlined panel with 2 tables that would display the same tracking code type in all panel. Or, we could simply only display the doc for the asynchronous code.
I'm also wondering if we could, by default, load the JS from piwik/js/ ? Is there any known blockers from doing it by default (any misconfiguration/missing extension) that are not tested for or handled in all cases? we couldn't really add one more failure option at this level (the "there is no data" FAQ is already quite big).
Replying to matt:
I'm also wondering if we could, by default, load the JS from piwik/js/ ? Is there any known blockers from doing it by default (any misconfiguration/missing extension) that are not tested for or handled in all cases? we couldn't really add one more failure option at this level (the "there is no data" FAQ is already quite big).
The code that serves static files is fairly robust now (especially with the double compression problem fixed).
+1 Most users who run ABP use subscriptions. Imagine my surprise to see that the latest EasyPrivacy subscription still has piwik.js|php blocked, but ga.js was recently removed from the list. boggle
Oh that doesn't make much change at all! but maybe with 1st party cookies they will remove it directly.
we will leave the piwik.js for 1.2 but if all goes well we could def move to /js in 1.3, which this ticket will be in I think
There could also be an pre-checked option:
tracker.setDomains('*.piwik.org');
which would ensure clicks to sub domains are not tracked as outlinks.
Even, the JS tag could be pre-filled with the Alias URLs filled in for this website as to keep some domains appearing in the list when it is important (eg. tracked in a different website).
Please add to the inline text and/or documentation/faq that the user may need to "escape" the pasted tracking code when using a template or an app with its own templating system.
From #2182, we could inspect the main URL and alias URLs, to see if there are any secure URLs. An example, where a hosting provider might have a shared SSL certificate:
var pkBaseURL = (("https:" == document.location.protocol) ? "https://host123.example.net/~account/example.com/piwik/" : "http://example.com/piwik/");```
scratch that I made an assumption. To be more general, it would require a couple of new parameters (or settings, if you want it persistent) to specify the tracker URL (secure vs non-secure); default would be the current URL.
Other ideas/requirements:
In f1f29bce4942e0429a98e7dcec6e86dd89853f5c: Refs #1845, added new admin page where users can create their own custom JavaScript tracking code snippets and image tracking link HTML.
Notes:
In c6ac229c8e7d6cf032d50ae604f829933b11fd73: Refs #1845, switch to async JS in other places and apply fixes to tracking code admin page & other pages.
Notes:
In 8c0bbda883334c2136e6cb3a3b6cff34745c625e: Refs #1845, change code in proxy-hide-piwik-url/piwik.php to use async code.
In b562ded89964307f83379c8b4e6b2366b77208b9: Refs #1845 Adding failing JS test for use case discussed
Goal: . make it hard to misuse API
Bug: if trackPageView is pushed to async before setTrackerUrl, the request will not be tracked.
Solution: setTrackerUrl should be executed first even if i was async "pushed" at a later stage (Benaka has patch).
In c405a15af93d981bee32d26a8f38ee1371d9be78: Refs #1845
In ffa2c8acf5d396662fe1b378d97deeac2bb2195c: Refs #1845
In 3cee71c1c3bf1d46b75672c466452ab05e5b1d41: Refs #1845, display current site's host in help text/description of tracking code admin page's inputs.
In 51e6c3539a948521b31cea6a8aed8287cf2650ea: Refs #1845, make sure current site host is used in default alias in merge alias option description and in group by domain description.
In a74a4f350dc8f4802e6774fd739644d45ee45612: Refs #1845, fix user settings site selector regression.