Tracker: consecutive goal conversions from same visitor create new visit

[clarkf]

The handleKnownVisit function in core/tracker/visit.php has a check which fall back to a new visit if no rows were changed in the database update, treating it as if the visit information was bogus and the visit wasn't in the database.

The problem is that if two visits from the same visitor happen within the same second, it can result in no change to the database even though the record is present (because we only have second resolution on the action times).

Solution might be to use getInfo on the result rather than getAffectRows since getInfo reports both the # of rows that matched and # of rows that were changed.

FYI, this doesn't happen all that often, but if you are tracking a goal which occurs early in the visit (e.g., java installed) then it will happen every time and result in copious new visits and visitors.

[vipsoft]

If you did a re-installation (dropped & recreated the database tables), you have to clear your browser cookies so that they don't show up as bogus cookies.

[matt]

clarkf, assuming you verified the issue with a fresh install,can you please submit a patch?

[matt]

quoting vipsoft (PDO doesn't have a getInfo equivalent, so that's not a solution, assuming this is a problem...)

[vipsoft]

Marking this as Bogus/Invalid. The timestamp isn't used in the UPDATE statement's WHERE clause. Thus the only case where the UPDATE fails to update any rows is where the idvisit or visitor_idcookie don't exist -- as in the case where the Piwik tables are recreated (e.g., re-install) but the user hasn't cleared the browser's cookie cache.

[vipsoft]

Having read comment:ticket:1108:4, I'm re-opening this one.

The symptoms described in 1107 and 1108 have the same root cause: there's a race condition where simultaneous (or near-simultaneous) tracking requests (for a new visitor) are received and processed by the tracker, and neither request contains a tracking cookie.

[matt]

See if still necessary after #134

[matt]

this bug was fixed in r3509