Is there a way to report on who is viewing Skuid pages? We are looking to get metrics on which pages are or aren’t being used. Most are hosted on VisualForce pages and SalesForce allows you to report on the view counts per security profile per page. However, I’d like also to get counts and last viewed dates for our pages by specific user. Is that possible?
You could create a custom object called “page tracker” and then create an on-page-load triggered action sequence to create a new record in a model on that object that records the user’s name, the page name (a text value you would set), and the current date time). Then you could add that action sequence to any squid page and you would have a central repository that would track all the page visits.
Thanks for the interesting suggestion but I was hoping that information was captured by Skuid in a way that was reportable, rather than having to add an action sequence to most pages. Since user preferences are retained for things like filter options, I assume last viewed info is stored. The question is whether that info is exposed to clients to report on.
Frequently requested. Not yet tackled.
The filter memory and tab placement memory are interesting ideas. I’ll look into those.
We wrote a report on SkuidLabs showing a pretty straight forward way of reporting this out.
@Rob_Hatch Thanks for sending the specs.
I don’t think I’ll go the route of creating a custom model and action since we have almost 200 pages and I’d rather not have to add this action to even 20% (though the roadmap cross-page resource feature could help!) and will keep with just reporting on the profile level that SalesForce offers.
But if you have the resources to tackle adding a way to expose Skuid page visits per user, I’m sure other customers have a similar use case in that they’d like to know which pages are being used by whom, and which are not.
Oh yes - we’ve had lots of conversations about it and heard the need from all sorts of customers. There are just some interesting wrinkles about how far down the usage track we go, and how we do it so we don’t crush your salesforce instance with tons of data records (which can get expensive)