@peterbo opened this Issue on March 17th 2011 Contributor

I have reproduced this in my own piwik instance and in another one. Goal values are not always or not at all recorded, although the goal is successfully triggered with the given value (tracked via firebug).

See Forums: http://forum.piwik.org/read.php?5,73517

@peterbo commented on March 17th 2011 Contributor

Attachment: This is recorded now
goals-now.JPG

@peterbo commented on March 17th 2011 Contributor

Attachment: This was recorded in former versions
goals-then.JPG

@mattab commented on March 18th 2011 Member

This bug might be because of race conditions that the trackGoal requests arrives beforer the trackPageView request. Can you please try, removing the trackPageView call, and see if the revenue is always correctly tracked?

In any case this is bug of course, just trying to confirm

@robocoder commented on March 25th 2011 Contributor

Peter, can you confirm this is duped/fixed by the patch in #2168?

@robocoder commented on March 29th 2011 Contributor

ignore comment:2

I suspect the problem is the request is being truncated by the web server or php (eg suhosin).

The new tracking requests are much longer and in the case of trackGoal(), revenue happens to be last parameter in the request (while idgoal is the first).

@robocoder commented on March 29th 2011 Contributor

(In [4231]) refs #2195 - move revenue parameter closer to start of request (in event request string is truncated)

@peterbo commented on March 29th 2011 Contributor

Thanks Anthon, I'll apply your patch and in later test stages try to switch to POST the tracking request. Reporting here when tests passed!

@robocoder commented on March 29th 2011 Contributor

[4231] isn't a fix per se. If your server has limits on the length of the URL requested, query parameters, or client headers, then data may still be truncated. So, you should still take a look at your system config.

  • Apache's LimitRequestLine directive (default 8K)
  • IIS <requestLimits> (default maxUrl 4K, default maxQueryString 2K)
  • lighttpd (total of 64K for client headers)
  • nginx (total of 4K or 8K for the client header)
  • Suhosin's suhosin.get.max_value_length setting (default 512 bytes)
@mattab commented on April 11th 2011 Member

Assuming the bug comes with a URL exceeding limits, the proper fix to this issue would be to POST the data when there is too much of it, similar to what GA recently released in their JS (probably via Iframe or other mechanisms for cross domain POSTing)

This Issue was closed on April 26th 2011
Powered by GitHub Issue Mirror