@joneduca opened this Issue on March 11th 2016

This happens in v2.15.

If a page sends two conversion calls that are processed in the same second, only the first one is saved to the database. This prevents from recording several conversions that happen in the same page at the same time and you don't want to (or you can't) record those as several items for the same conversion.

Currently this is due to the primary key in the conversions table.

@sgiehl commented on March 11th 2016 Member

Is your problem to log more than one item conversion at a time? If so you only need to set a unique item sku for tracking?

Maybe post a small example code which fails for you.

@tsteur commented on March 13th 2016 Member

Yes, this is a limitation of the current implementation. There's probably already an issue for this but couldn't find it right now so will leave this issue open. Maybe @mattab has an idea re an existing issue

@tsteur commented on November 15th 2018 Member

User reported it again in https://github.com/matomo-org/matomo/issues/13719

I'm not sure but it looks to me potentially like an easy fix in https://github.com/matomo-org/matomo/blob/3.7.0-rc2/core/Tracker/GoalManager.php#L674-L676 to not use the request timestamp but also some additional random numbers (eg 5 random numbers completed with the last bit of the timestamp or something)

@tsteur commented on November 15th 2018 Member

@mattab @sgiehl @diosmosis any idea why we use the timestamp there?

@mattab commented on November 19th 2018 Member

The idea of using the timestamp I believe is to prevent 2 same requests sent at the same time to trigger 2 goals. So they have to be at least 1 second apart to trigger a new goal. But if it creates other bugs, we should rather remove this timestamp in the cache buster :+1: @tsteur

Powered by GitHub Issue Mirror