First things first. You give me more credit than I am due. I am notthe creator of the plugin, merely a contributor building on the work of those before me. DrByte was the originator, with many before me adding to the functionality. A few years back in an effort to return to the community what I had seen as improvements for the way it worked in support of what I wanted to get out of it, I reached out to ask if it was okay to return to others what I had done and was encouraged to do what might seem to provide benefit to others.

So... The next thing and this is laid out in the forum, but the most recent version really is an old version that has SQL for a new install that works out-of-the-box. So there is a lot of functionality that was added that does not appear in the latest version. Still "works" the same, but is missing several options.

In order to "restore" the download back to where it should be would require repackaging the download and this time with the correct new user sql... But, in parallel with that, another ZC contributor was also working on a change to bring the code more in line with the expectations of the ZC team, but the work was incomplete... So, this left two major issues to try to address for the next upload... Well then some other things came up and unfortunately User Tracking hasn't made it back onto my radar yet because of other priorities.

But, let's leave that behind for the moment.

The history... For the date 14 Oct 2015, only clicks that are made from 0000.00 to 2359.59 will be associated with that day. If a customer is navigating the site beginning the day before, then the first click that occurs on the current day will be logged as occurring on today with a start time of the first click made during the current day. The end time is related to the last time that the customer clicked while their session was active (~15 minutes since last click/recorded action, etc). Items in the list (at least in the truly more recent version) are such that they are listed by the most recent end time being at the top, regardless of what the start time was. So someone that just started shopping could show up next to someone that had been browsing for an hour.

So, the big thing, assuming that the version running tracks like expected, then the individual that made the purchase should appear on the left side of the rows of data at least at the point that they would need to be logged in... As far as protecting customers? Would agree that do not necessarily want to post all of the customer details (ip address, username, items reviewed, session IDs, etc...)

Basically, the code records when a page is loaded to the point of displaying the entire screen (at least makes it to the footer of the page and that the footer is displayed on every page including the checkout pages). Right now anything that can be determined will help back track to what is/was going on... The first thing is to identify available information about the recent purchase(s)... Once that is identified, can then work backwards from there...

If need be, you could go to phpmyadmin and review the logged data for the ip address that you supposedly have identified/are looking for...

For the purchase that went through successfully, should see on the left side the name of someone logged in, otherwise the name would/should be Guest located just under the phrase Session ID.