E-commerce bug: orders from registered users creates a new visit

[Glisse1]

In the attached pictures we have (by coincidence) two new orders one after another:

• first order is from a registered user with visit id 9128..the order they make creates a separate visit with id 9131
• the second order with visit id 9129 is from an unregistered user, and everything is as it should.

Not sure if this minor bug is related to the upgrade to version 2.10.0, or by the starting to use the official wordpress integration plugin for woocommerce.. its one of the two i guess.

[tsteur]

Which "custom" plugins are you using? I don't think I understood the problem. Can you maybe try to explain it differently? Are you saying there was one order by one registered user but two visits?

So if an unregistered users put somethings in the basket, then login to order which creates a second new? This was originally fixed in #6313 I think but probably the log_conversion table is not updated correctly.

[Glisse1]

Yes, I am saying that there was one order by one registered user with two visits, one of the visits being only the order revenue value itself. I was online when it happened so it was like this: the user got on my site (visit id 9128), logged in immediately (action that did NOT create a new visit, it remained 9128, as it should) then they added some products to cart, navigated to shop page... but when they actually finished the order that new visit #9131 was created. After the order was done , the user actually visited one more page, and they were returned to visit id 9128..so this means that visit 9131 was only and only created for the order revenue and nothing more.

By contrast the unregistered user with visit id 9129 placed the exact same order and everything was continuous in one visit.

I am using the (official?) woocommerce integration plugin, advertised via 2.10.0 changelog, that is https://wordpress.org/plugins/woocommerce-piwik-integration/

[Glisse1]

Follow up: I have created a test user to conduct the steps myself: it seems that it is not related ONLY to finalizing the order, but rather the action of adding to cart also does trigger a new visit ID.

So it went like this.. visit id 9245, saw 3 pages.. after adding the product to cart it created the visit id 9246 and moved me there.. visited one more page, it remained there, on 9246.. visited one more page and then added another product to cart, it returned me to 9245.. visited 2 more page remained on 9245, finalize the order, sent me back to 9246. Must be noted that the second visit created it is NOT recognized as being of the test_user, like the first one.

So, it seems that for a registered user both adding products to cart and finalizing the order creates a new visit id, and it continues there.

[tsteur]

Thx for detailed steps! I will try to reproduce as well. Just one question: Were you logged in all the time and was a userId (testme I presume) from the beginning set?

[Glisse1]

Just the first page (the one with the blue icon) was in a logged_out state.. i logged it immediately, everything afterwards is in logged_in state as the test_user

[tsteur]

I tried to create a Fixture to reproduce this issue here: https://github.com/piwik/piwik/commit/fc27ed879cc3a13f352ef31bff4db7cd43aa77a3 but I cannot reproduce it this way. Maybe I am doing something wrong or it is related to JS and that JS sends values. Does JS always send a VistiorId along with every request etc? Thinking about working on #7066 but will first try some more things

[tsteur]

@Glisse1 can you maybe send us a link to the shop? You can send it to hello at piwik.org if you don't want to comment it here.

[tsteur]

Can you maybe also execute those queries and send to the same email the output? That'd be helpful:

select * from piwik_log_conversion where idvisit = 9245;
select * from piwik_log_conversion where idvisit = 9246;

select * from piwik_log_conversion_item where idvisit = 9245;
select * from piwik_log_conversion_item where idvisit = 9246;

select * from piwik_log_link_visit_action where idvisit = 9245;
select * from piwik_log_link_visit_action where idvisit = 9246;

select * from piwik_log_visit where idvisit = 9245;
select * from piwik_log_visit where idvisit = 9246;

[tsteur]

Thanks for sending us the link! I ordered a few products and noticed it is an implementation problem. But it is not necessarily your fault as I think we can prevent this kind of issue in the problem. I will try to work on a patch.

Somewhere in the HTML there is the following:

var _paq = _paq || [];
_paq.push(["addEcommerceItem","1","PRODUCT",[],"7","1"]);
_paq.push(["addEcommerceItem","3","PRODUCT",[],"20","1"]);
_paq.push(["trackEcommerceOrder","#NUMBER", "37","27","0","10"]);

Further down there is the "default" tracking code:

var _paq = _paq || [];
_paq.push(['setUserId', 'USERNAME']);
_paq.push(['trackVisibleContentImpressions', true, 750]);
_paq.push(['trackPageView']);
_paq.push(['enableLinkTracking']);
....

This means the trackEcommerceOrder is executed before the setUserId meaning Piwik cannot find th UserId when tracking the ecommerce order meaning it creates a new visit. Make sure to always call setUserId first in your website. I will try to work on a patch in Piwik so that this is no longer needed. The patch should then be included in the next Piwik release.

BTW: I'm based in New Zealand and couldn't access your website for some reason. Only via Phone / 3G. It worked with a european proxy/VPN though. Not sure why I couldn't access your website directly, not even a ping was possible. Maybe a problem with my provider.

Please cancel the order :)

[Glisse1]

Ok, I used to have (as recommend in general when it comes to javascript) the piwik tracking code in footer.php.. so this means that piwik-woocommerce integration plugin i installed injects the code before the footer, and it was causing the problem you speak of.. i moved the piwik tracking code to the header and it is working fine now...such an easy fix.. that is, if you know what the problem is :D

As for the blockage, It`s definitely about your provider.. i have visitors from all over the world, not just europe..

Thx for the fix, and keep up the good work!