Hi @ArnY thanks for investigating so much already and looking so deep into it.

In general I can say that custom variables work quite well here. So it might be related to a specific browser or server.

Which browser are you using? Do you have some details about the server? On which OS is it running and what's the Piwik version?

There's a JSON decode which should convert that string that you mentioned in the forum to an array.

Can you maybe try if it still occurs if you track only one custom var? eg _paq.push(['setCustomVariable', 1,"Site","SET",'page'])

Since I noticed the bug on our production server on a segment which
averaged around ~30,000 monthly before the bug and ~230 after (but all
segments are impacted), if this was a browser related bug, that would
mean that 99.993% of the browsers suddendly handled the javascript wrong.

I removed my fix ($keyValue=json_decode($keyValue)) and only left one
custom variable. The problem still occurs:

DEBUG Actions[2015-10-17 09:55:04] [979f0] Invalid custom variables
detected (id=1)

I agree there's something strange with the fact that a very small
percentage of the visits are still being accounted...

On 10/17/2015 08:50 AM, Thomas Steur wrote:

Hi @ArnY https://github.com/ArnY thanks for investigating so much
already and looking so deep into it.

In general I can say that custom variables work quite well here. So it
might be related to a specific browser or server.

Which browser are you using? Do you have some details about the server?
On which OS is it running and what's the Piwik version?

There's a |JSON decode| which should convert that string that you
mentioned in the forum to an array.

Can you maybe try if it still occurs if you track only one custom var?
eg |_paq.push(['setCustomVariable', 1,"Site","SET",'page'])|

—
Reply to this email directly or view it on GitHub
#9027 (comment).

Arnaud Abélard
jabber: arnaud.abelard@univ-nantes.fr / twitter: ArnY
Administrateur Système

DSI Université de Nantes

I can confirm the problem on ubuntu 14.4, php-5.5.9.
I can reproduce it with piwik 2.13.0 and 2.15.0rc3

One more intresting thing.

If I set the value of my custom variable to "m.jobsintown.de", the value is tracked. Means, the type of $keyValue in https://github.com/piwik/piwik/blob/master/core/Tracker/Request.php#L553 is an array.

_paq.push(['setCustomVariable', 1,"Domain","m.jobsintown.de",'visit']);

if I set the value to "www.jobsintown.de" $keyValues is a json encoded string.

_paq.push(['setCustomVariable', 1,"Domain","www.jobsintown.de",'visit']);

That's very weird. I tried to reproduce but couldn't.

I just had a look at the website and it is actually sent differently to Piwik:

_cvar:{"1":"[\"Domain\", \"www.jobsintown.de\"]"}

vs

{"1":["Domain","m.jobsintown.de"]}

After debugging further I noticed that you are using Prototype 1.6.0.3 which is known to be buggy re JSON. Please update Prototype to a more recent version.

See eg #2165 or #7945 (comment)

After upgrading prototype, the problem was fixed.

Thank you very much!

Spot on! We used prototype.js 1.6.0.3 too but I actually upgraded it a few days ago for a completely unrelated reason! I had slightly modified Request.php to send to syslog user-agents of browsers encountering the problem and upgrading prototype.js did fix most of the problem, but even after the upgrade I'm still getting non decoded json arrays for each custom variables (about 1% of the visits). Most of them are using webkit browsers: Chrome and Safari. Might not be important, I just wanted to mention those, just in case.

Thanks anyway!

Those browsers probably still use the cached prototype.js

On 10/27/2015 07:27 PM, Thomas Steur wrote:

Those browsers probably still use the cached prototype.js

—
Reply to this email directly or view it on GitHub
#9027 (comment).

My thought too, i'll keep an eye on it.