Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracker: consecutive goal conversions from same visitor create new visit #1107

Closed
anonymous-matomo-user opened this issue Jan 12, 2010 · 7 comments
Assignees
Labels
Bug For errors / faults / flaws / inconsistencies etc.

Comments

@anonymous-matomo-user
Copy link

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.

@robocoder
Copy link
Contributor

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.

@mattab
Copy link
Member

mattab commented Jan 14, 2010

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

@mattab
Copy link
Member

mattab commented Jan 14, 2010

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

@robocoder
Copy link
Contributor

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.

@robocoder
Copy link
Contributor

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.

@mattab
Copy link
Member

mattab commented Jun 21, 2010

See if still necessary after #134

@mattab
Copy link
Member

mattab commented Jan 5, 2011

this bug was fixed in r3509

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug For errors / faults / flaws / inconsistencies etc.
Projects
None yet
Development

No branches or pull requests

3 participants