Journals do in fact contain dates for both sets of data (really they contain pretty much everything), but it won’t be easy. First obstacle will be figuring out how to get the dataset, which is every journal file for every team member which was created during the analysis period. These can be found here:
%LOCALAPPDATA%\Autodesk\Revit<Product name and release>\Journals
Since these are saved in their user profile you can’t just log in as a different user and grab them yourself unless it’s an admin account for the machine. Talk to your IT department to see about how to go about getting these some other way. Once you overcome that issue and get all the files, you can really see the scale of your request: there is a new journal file created every time a user opens Revit - so if they close and reopen it every two hours there will be 20 journals in a week. That’s a lot of files on a team of 10, and file names (but not paths) will overlap in some cases as the names generated are just a number sequence.
Not only are there alot of files here, but the files have a lot of data in them. Every command (even mouse movements and clicks) is recorded so it’s a LOT of data to look though. With all the files, you are easily looking at a few million data points.
The audit and purge commands are easy enough to find once you get the data set. Search “audit” and “purge” in your most recent journal (assuming you’ve both audited and purged in your last Revit session) to see what I mean. Keep in mind there are additional commands entered between the initial “audit” and “purge” entry and the actual command execution. Things like those pop up windows where you have to hit “ok” or “cancel”, the “select all,” “select none,” or individual selections, heck even closing the window counts. So look for the completion of these. Transaction OK is a good indicator.
Finding the completed command and tying it to the correct document is simple enough for the audit command as the “audit” entry will always be a little bit above the open command. Unfortunately, this isn’t the case for the purge command. Because a user can have multiple documents open in the same session, and that the purge command isn’t associated with something which always indicates the active document, you need to confirm which document was purged. This happens somewhere above the command. So after you find the completed purge command you need to comb backwards in the journal file to get the name of the document which was active when the command was run.
So while it’s doable, I wouldn’t recommend it. Journal mining is a big, complex thing. It should really only be done when you’re dealing with a current, active issue. Attempting to go backwards and find when stuff was running correctly, while doable, isn’t fun and will cost you more time than you’ll gain from it.
The best way to find when a file was purged? Look at the file size over time. If the file size is reduced, it means someone ran a Purge command (unless someone deleted a sizable part of the model, which the team would likely know about). The historic file sizes can be taken from backups, but is more useful when logged periodically in a spreadsheet or csv.
The best way to find when a file was audited? Assuming it’s not in the slog files (a long shot as I don’t see any difference between open and open with audit in my test file), my guess is that the journals are in fact the best method. However, that would be so painful I wouldn’t bother.
Personally I always lived by this rule for audits on my projects: If I have to ask when the file was last audited, it’s been too long so do an audit right now.