Page Audit

[davo]

I have a site that i'm developing where audit is important to prove commissions; ie has a client met the supplier through another means, or can it be proved that they visited this site prior to sale?

I don't suppose anyone is aware of a module that will simply log that where a user is logged in they have visited a particular page?

If not i'm sure I can develop something for this but don't want to waste my time on something that has already been done.

[mr-fan]

Maybe i get it wrong but could this not be set via a tracking tool like PIWIK

http://piwik.org/docs/ecommerce-analytics/

http://piwik.org/docs/tracking-goals-web-analytics/

http://piwik.org/docs/event-tracking/

just how i read your question - but it's nobuilt in PW but could integrated via API.

[davo]

Thank you. That makes interesting reading which I'll explore.

I was thinking of quite a simple audit really.

Something like;

If current user is not guest, write page id, user, date and time to another table. Maybe even use Ryan's flat table module for speed.

Suppliers often claim that the client introduction was made by another service. All my client needs to prove is their site was viewed prior to the sale taking place to prove on a balance of probabilities.

[mr-fan]

some smaller solution:

http://www.innovativephp.com/how-to-get-the-last-visited-page-url-in-php/

best regards mr-fan

[NooseLadder]

Maybe this module might help as a start. Login History

[adrian]

This sounds like a very easy thing to implement using the PW API. Do you want to log all the pages the logged in user visits, or just monitor one particular page?

You could certainly make use of Profields table to create a user visit log. In fact I use it already for a similar purpose.

Hopefully this will get you going. This assumes you have a page called visits and a Table field called visit_log with table sub-fields called date, user_id, and page_id

$visits = wire('pages')->get("/visits/");
$visits->of(false);

$visit = $visits->visit_log->makeBlankItem();
$visit->date = date("Y-m-d");
$visit->user_id = $user->id;
$visit->page_id = $page->id;
$visits->visit_log->add($visit);
$visits->save("visit_log");

PS You might want to make this Table field not editable (locked), or maybe even hidden from the editor as it will likely become extremely long and might have issues when displayed in the PW admin.

Something else to think about - you could add this field to a site-wide "visits" page like in my example, or have it attached to every page of interest on the site and then you wouldn't need the page_id subfield.

Edited August 5, 2014 by adrian
Added additional ideas

[davo]

This sounds like a very easy thing to implement using the PW API. Do you want to log all the pages the logged in user visits, or just monitor one particular page?

You could certainly make use of Profields table to create a user visit log. In fact I use it already for exactly that purpose.

Hopefully this will get you going. This assumes you have a page called visits and a Table field called visit_log with table sub-fields called date, user_id, and page_id

$visits = wire('pages')->get("/visits/");
$visits->of(false);

$visit = $visits->visit_log->makeBlankItem();
$visit->date = date("Y-m-d");
$visit->user_id = $user->id;
$visit->page_id = $page->id;
$visits->visit_log->add($visit);
$visits->save("visit_log");

Exactly what I was thinking, although I may well add in the referrer too mentioned above. That might well help us work out where traffic comes from.

[mr-fan]

Refferer from logged in users after login comes from the loginpage? Or did i geht this wrong?

@adrian it is every day amazing to read what could be done with the pw API ....

[davo]

Mr fan

The pages I want to audit can be viewed as a guest or logged in user. Logged in users just get extra functionality such as being able to add notes etc to a page.

My plan is to use the api to capture logged in users visiting a page.

If they aren't logged in I want to drop a cookie which will up date the audit log when they become logged in.

[davo]

Works perfectly:

What does this mean?

$visits->of(false);

[adrian]

Works perfectly:

What does this mean?

$visits->of(false);

http://cheatsheet.processwire.com/page/built-in-methods-reference/page-of-true-false/

http://cheatsheet.processwire.com/page/built-in-methods-reference/page-setoutputformatting-true-false/

Those should answer your question better than I can

Just had another thought on that solution that you might want to consider. You may want to check to see if there is already an entry for the current user and current page (maybe for the given day, or maybe ever) and not add an entry if it already exists. Of course this depends on your needs, but no point populating the table with unnecessary rows.

[davo]

Thank you, I'll have a read.

I know what you mean. I think I'll run the whole concept past the client and see what's most important for them. I could be they only want to see if the page has been visited "ever", ie if the introduction has ever been made then the criteria has been met.

I do have  a stage 2 in mind once this has settled. I'm thinking of:

Where a page has been visited and the user is guest, drop a cookie with a page ID in it. Then, when a logged in user visits that, PW collects any cookies and adds them to the audit log adding a logic to the row to say if the entry was generated from a logged in user or guest, but on a computer that is now associated with that account.

What do you think?

[adrian]

I think that sounds reasonable and doable, but of course cookies can be cleared and computers can be shared by multiple users, or a user may have multiple computers, so it can only be useful to a certain level of certainty if you are trying to find users who visited a page once as a guest and again when logged in. I guess it really comes down to the exact info the client wants to determine.

[davo]

Yes, I agree. It's just that extra scoop audit / me trying to be smart. It's possible someone may use the site and get information from it a long time before the officiallly register for it.

Although, with the multiple device issue, that could do the cookie sweep next time they're logged on to that additional device yes?

[davo]

Adrian

In the table field, I've tried to use the trash can to clear out some of the entries, it puts a line through the entry but when I come to save it, it doesn't delete the entries.

I've used the same field titles as above.

Do you also get the same issue?

[adrian]

Adrian

In the table field, I've tried to use the trash can to clear out some of the entries, it puts a line through the entry but when I come to save it, it doesn't delete the entries.

I've used the same field titles as above.

Do you also get the same issue?

No issues here - perhaps it might be best to post this question in the VIP board for pro fields for Ryan to investigate. Do you have the same issue with other table fields? Does it make a difference if the table rows are created via the admin or via the API?

[davo]

Odd, using the admin gui I can't add or delete row entries, but the api is still able to add rows. I'm logged in as a super user so access shouldn't be an issue.

On your version of this, did you use exactly the same field names as I have above? Even the date field?

Yes, I'll probably move this to vip for ryan.

[adrian]

Yep - same field names including "date". Hopefully Ryan can help you debug this one.