You can clone with
HTTPS or Subversion.
Since 1.2 the Goalmanager uses the refering URL and the current URL, not the entry URL to determine the referer. But only the entry URL has campaign infos, so this info is lost.
The Goalmanager should use the existing data from the current Visitor and not analyze the referer a second time.
setConversionAttributionFirstReferrer( bool ) Set to true to attribute a conversion to the first referrer. By default, conversion is attributed to the most recent referrer.
If that doesn't give you the desired effect, please post samples showing observed and expected results.
I have tested setConversionAttributionFirstReferrer( true ), but this changes nothing.
I made some tests:
On www.example.org i have a link to www.mysite.com/site1.html?utm_campaign=testcampaign&utm_source=testsource, piwik is configured to use utm_campaign and utm_source as keyword and referer.
If i hit this link a new Visitor is tracked as an vistor from testsource with keyword testcampaign. Everything is ok. In the database the log_visit table shows me:
referer_type = 6
referer_name = testsource
referer_keyword = testcampaign
If i now go to a second site where i track manualy a goal, a conversion is tracked, but in the log_conversion table it shows me:
referer_type = 3
referer_name = example.org
referer_keyword = NULL
I take a look on the core/Tracker/GoalManager.php an this happens becaus the GoalManager analyses the referer again.
$referrer = $referrer->getRefererInformation($refererUrl, $currentUrl = '', $idSite);
Because the currentUrl is empty, the referer Class cannot detect the campaign.
I have made a patch that fixes this for me.
Thanks for the patch lcb! I will commit soon
Actually, the patch is not enough. Technically, we should detect the campaign parameters in the piwik.js and store the "campaign name & keyword" in the cookie.
Imagine the use case
We could maybe just store the actual parameters, pre-parsed, in the first party cookie.
Currently these parameters are piwik_campaign and piwik_kwd
Maybe the best solution would be to move the Campaign detection in the piwik.js all together, similarly to what GA and others are doing?
Let's do the server-side patch first.
Then create a new ticket to move the logic/storage into piwik.js since this impacts a number of tickets (#79, #517, #604, #855, #1042).
(In ) Refs #2168: thanks lcb for report & patch
This will attribute the campaign correctly, if the Goal happens on the first Visit.
The campaign will not be attributed when Goals are triggered on subsequent visits and when a Campaign was the Referer used to reach the website, in a previous visit.
Proposal for fix: piwik.js will detect the campaign name & keyword parameters in the landing URL, when the visit is new. It will then store in a separate new cookie (same lifetime as referer cookie).
The values to store are the name and keyword. When a campaign is stored in the cookie, the _ref cookie is NOT deleted.
Later, we might decide to align with GA campaign tracking model ( 4 dimensions).
Also we might decide to attribute conversions differently (both to websites & campaigns) that is why we must store the URL ref and the campaign name/keywords at the same time.
The piwik.php tracker will then read these values and pick which one is preferred (the campaign is by default, higher priority than another URL referer)
Sounds good. (Other than the first party cookie overhead on each request and GET request length limits...)
As an update to my previous implementation suggestion, I propose that campaign name/keyword are stored in the _ref cookie along with ref url & ref timestamp, as to simplify cookie space (if there is no campaign, or no referer, the first (or last) fields are empty as they are fixed size)
I have to stop for the day, here is patch of current status
What is missing:
I noticed the JS fails JSLint, Anthon do you run the piwik.js via the online test tool when the test fails? (just checking)
feedback welcome... i'll finish tomorrow
I haven't looked at the patch, but yes, ci has a job to test against the latest online jslint.
(In ) refs #2168 - fix bug per matt's email
OK thanks for the JS review I'll change it
I'm adding the JS tests, this stuff is cool man!!
The test framework can use mock functions (replacing setCookie/getCookie) for testing. This will make it easier to test the code that loads the visitor and referrer cookies, and that handles a new visit.
(In ) Fixes #2168
Refs #2222 Accurate Paypal tracking (or any other third party "after the fact" Goal conversion): implementation is now done, we must write some kind of guide and test
(In ) fixes #2285, refs #2168