The visit ID lasts for 30 minutes (by default), unless you have the option to extend the visit duration for 30 minutes from the time of your visitor’s last pageview. You may want to use different settings to avoid this problem. The visit_id value is stored in a cookie, so no caching should affect its current value and/or expiration.
Thread Starter
pepe
(@pputzer)
Well, how do you explain then that completely different requests from different computers and browsers get the same visit_id for a whole day long until I increase the option value?
MySQL [wordpress]> select visit_id, ip, language, browser_id, dt from <prefix>_slim_stats where visit_id = 30585 order by dt desc;
+----------+------------+----------+------------+------------+
| visit_id | ip | language | browser_id | dt |
+----------+------------+----------+------------+------------+
| 30585 | 1434432034 | de-de | 1346 | 1423391968 |
| 30585 | 1434432034 | de-de | 1346 | 1423391967 |
| 30585 | 1434432034 | de-de | 1346 | 1423391950 |
| 30585 | 1434432034 | de-de | 1346 | 1423391930 |
| 30585 | 1434432034 | de-de | 1346 | 1423391907 |
| 30585 | 1434432034 | de-de | 1346 | 1423391779 |
| 30585 | 1434432034 | de-de | 1346 | 1423391772 |
| 30585 | 1434432034 | de-de | 1346 | 1423391746 |
| 30585 | 1434432034 | de-de | 1346 | 1423391735 |
| 30585 | 1434432034 | de-de | 1346 | 1423391734 |
| 30585 | 1434432034 | de-de | 1346 | 1423391492 |
| 30585 | 1434432034 | de-de | 1346 | 1423391455 |
| 30585 | 1434432034 | de-de | 1346 | 1423390908 |
| 30585 | 1434432034 | de-de | 1346 | 1423390903 |
| 30585 | 1434432034 | de-de | 1346 | 1423390786 |
| 30585 | 1434432034 | de-de | 1346 | 1423390746 |
| 30585 | 1434432034 | de-de | 1346 | 1423390729 |
| 30585 | 1434432034 | de-de | 1346 | 1423390721 |
| 30585 | 1434432034 | de-de | 1346 | 1423390720 |
| 30585 | 630173798 | de-at | 1958 | 1423390639 |
| 30585 | 1534152733 | de-de | 1346 | 1423390378 |
| 30585 | 630173798 | de-at | 1958 | 1423390044 |
| 30585 | 630173798 | de-at | 1958 | 1423390040 |
| 30585 | 630173798 | de-at | 1958 | 1423390018 |
| 30585 | 630173798 | de-at | 1958 | 1423389981 |
| 30585 | 630173798 | de-at | 1958 | 1423389956 |
| 30585 | 1534152733 | de-de | 5027 | 1423389519 |
| 30585 | 630173798 | de-at | 1958 | 1423389396 |
| 30585 | 1574664158 | de-de | 1346 | 1423382288 |
| 30585 | 1349357394 | de | 5114 | 1423382011 |
| 30585 | 1350289418 | de-de | 5112 | 1423352714 |
That’s just a partial excerpt of that visit_id. The first few lines are of course from the same user, but the rest are also quite obviously different people.
Interesting. If you look at the source code, you’ll notice that the tracker attempts to read the cookie, and if this user doesn’t have an active session (visit_id == -1), it increments the value and stores the new one in the database:
https://plugins.trac.ww.wp.xz.cn/browser/wp-slimstat/trunk/wp-slimstat.php#L1004
For some reason, in your case either the SELECT MAX(visit_id) or the update_option are failing.
If the user sends a valid (signed) visit_id, the tracker uses that one for the session:
https://plugins.trac.ww.wp.xz.cn/browser/wp-slimstat/trunk/wp-slimstat.php#L1017
Am I missing something?
A possible explanation is that this person is using a VPN and/or spoofing his IP address and user agent string to look like he is not the same person.
Thread Starter
pepe
(@pputzer)
I don’t think you are missing anything. There is no spoofing going on (some of the erroneously grouped visitors consist of myself and webpagetest.org). Unfortunately, I haven’t got a clue how to debug this, as I haven’t yet found a way to provoke the hickup. It just happen’s once in a while and goes away when I update the option manually.
Addendum: It may have something to with this ticket: https://core.trac.ww.wp.xz.cn/ticket/25623
Looking at your mysql error log could be a good starting point. You may want to search for errors related to Slimstat’s tables.
