Assign specific stat group for Sierra REST API Requests
We would like for Vega to allow specifying a statistics group w/Sierra REST API requests similar to what the III mobile app does.
Vega has never sent a statistics group with Sierra REST API requests (ex. renewals) and the current behavior is that the request is logged under statistics group 0. We only learned of this - up until recently, the requests were actually falling under the stat group assigned for our Classic WebPAC web transactions.
We would prefer keeping stat group 0 for issues/errors (bad login used for SDA, i.e., no locations served assigned) vs. certain Vega transactions.
Also, we DO have a stat group assigned for our fines payment in Vega, so would like to use that same stat group for all Vega transactions.
It is helpful for us to understand how people are interacting with our system - be it the mobile app, the classic WebPAC, Vega or in person, and assigned stat groups help paint that picture.
May be able to combine this idea with https://ideas.iii.com/forums/951766-vega-discover/suggestions/48751838-configure-vega-fine-payment-to-a-specific-stat-gro
Alison Pruntel
shared this idea
-
Elizabeth Swift
commented
We need to be able to see where patrons are interacting with our system.
-
Victor Zuniga
commented
Yes, this will be a great addition. I know that in recent upgrades to the Patron REST API, there is the ability to assign a value for the stat group. You still rely on the vendor to make this change.
It would be great for library staff members to control this feature via the user interface.
-
Jenny Ertel
commented
Looking at our stats for January, renewals and fines paid through Vega are going to stat group 0, while holds placed through Vega appear still to be going to stat group 800. So, it doesn't look like everything Vega-related is going to 0, either.
We, too, would appreciate the ability to assign a single stat group unique to all things Vega. As it is, because group 0 also includes unneeded no-location stats, we have to do some stat-group-splicing in Excel every month after running our Decision Center reports to make sure we’re accounting for Vega renewals in our total circulation numbers whilst avoiding any group 0 checkouts, which are obviously not from Vega. This inconvenience is frustrating and not something we care to have to do every month for the foreseeable future.
-
Brian Jones
commented
It would make statistical analysis of circulation easier to have the correct stat group - for us, zero can apply to some other situations aside from Vega.
-
Jessica O'Neil
commented
I fully agree with Bob Gaydos's comment that many libraries rely on statistics to report to our stakeholders and the public accurately, so Vega renewals and transactions should be separated out.
-
Martin Boyce
commented
If there was an option to choose a stat group for Vega renewals/transactions, we would also use it. It would be good to be able to differentiate transactions between platforms. It also seems like an easy thing to implement - adding one extra key/value pair to the payload for API requests. Would need some UI in Vega admin to allow libraries to set the stat group variable, but not too hard I suspect.
-
Bob Gaydos
commented
Our library depends heavily on stat groups for our circulation statistics and general troubleshooting. We are not currently Vega customers, and without this feature we would not consider migrating to the product.