Opened 4 years ago

Closed 3 years ago

Last modified 3 years ago

#1107 closed Bug (fixed)

Tracker: consecutive goal conversions from same visitor create new visit

Reported by: clarkf Owned by: matt
Priority: normal Milestone: Future releases
Component: Core Keywords:
Cc: Sensitive: no

Description

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.

Change History (15)

comment:1 Changed 4 years ago by vipsoft (robocoder)

  • Milestone set to 1 - Piwik 0.5.5
  • Owner set to matt

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.

comment:2 Changed 4 years ago by matt (mattab)

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

comment:3 Changed 4 years ago by matt (mattab)

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

comment:4 Changed 4 years ago by vipsoft (robocoder)

  • Resolution set to invalid
  • Status changed from new to closed

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.

comment:5 Changed 4 years ago by vipsoft (robocoder)

  • Resolution invalid deleted
  • Status changed from closed to reopened

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.

comment:6 Changed 4 years ago by vipsoft (robocoder)

  • Priority changed from major to normal
  • Status changed from reopened to new

comment:7 Changed 4 years ago by matt (mattab)

  • Milestone changed from 0 - Piwik 0.6.3 to Features requests - after Piwik 1.0

See if still necessary after #134

comment:8 Changed 3 years ago by matt (mattab)

  • Resolution set to fixed
  • Status changed from new to closed

this bug was fixed in r3509

comment:9 Changed 3 years ago by matt (mattab)

  • Summary changed from Tracker: consecutive actions from same visitor create new visit to Tracker: consecutive goal conversions from same visitor create new visit

comment:10 Changed 3 years ago by titimonmmm

comment:11 Changed 3 years ago by titimonmmm

comment:12 Changed 3 years ago by titimonmmm

comment:13 Changed 3 years ago by titimonmmm

comment:14 Changed 3 years ago by titimonmmm

comment:15 Changed 3 years ago by titimonmmm

Note: See TracTickets for help on using tickets.