Making Data Analytics Work for Library Archives and Special Collections
With Satya Achanta Venkata
We often think about the needs of the end user of a website, but what about when you have clients who leverage your website to serve the end user? How do you also serve them? ITHAKA works with hundreds of libraries who make their archives and special collections available to the end users on our research and teaching platform JSTOR. These contributors are part of our Open Community Collections program. Engineers are working on the Community Collections Dashboard to continuously improve the user experience and data analytics features available for libraries so they understand how their collections are being used.
Improving Data Analytics Features
Satya Achanta Venkata, an ITHAKA UI software engineer, is part of a team that makes the data analytics on community collections on the JSTOR website more useful for the collection contributors. He says that there is a particular process the team follows to figure out how to improve the data analytics features available to JSTOR’s library clients so that they get the data they need.
What Features Users Are Looking For
For several years, JSTOR library contributors had a data analytics dashboard in place that provided some basic data, including metrics like collection usage by country and total usage for the prior 12 months. Recently, a small feature change revealed that many libraries were looking for more robust data on usage of their collections. The team conducted user interviews with library contributors to get a better sense of what they needed.
“A lot of the feedback from the users related to usage over time. They asked, ‘How can I see my whole set of data instead of last year?’” Satya says.
Satya says that the user interviews the team conducted were somewhat open-ended, but the team did go in with “a set structure to ask about changes we thought we needed to make, and to see what users thought.” Since they already had a clue as to the problem, the team could focus in and ask in-depth questions about what the real need was and what solutions could meet that need.
In this case, the team learned that the librarians needed more customizable date ranges and more comprehensive collection use data.
While user interviews can provide terrific, targeted insights, Satya notes that this type of high-touch research isn’t always possible. ITHAKA has teams working with other types of users that have more guesswork given their diversity and scale. “For these teams, this process might involve more segmented A/B feature testing and segmented user behavior tracking on the website to find out the root need and improvements that can be made,” said Satya.
User Interviews Inform Software Design
Based on user interviews, the engineers designed a new feature where users could search any date range instead of preset ranges such as the previous 6 months for usage of their content on JSTOR.
Satya describes the process the team follows once a feature design is ready for review: “The whole team comes together and talks through various scenarios of the design. That helps us think through design from different perspectives, and to think about the user experience. We need to support [the majority of] use cases. That’s the important thing.”
Once the design is reviewed and improved if needed, the feature is pushed live. This process is made much easier by recent changes to ITHAKA’s technology and process for allowing software changes to be pushed live in parallel without disrupting the overall functionality of the website.
Technology Changes
Satya says that the biggest technology change involved in the Community Collections Dashboard usage date range feature expansion was that they had to move from using a cache to a database to store the amount of data needed to support queries on user analytics going back years. And they realized that if they were going to offer that much data, it needed to be retrieved quickly.
“The crux of this,” Satya says, “was driving the queries fast. When a UI talks to a backend service, it should respond within 30 seconds or Fastly cuts the connection. So we needed to get back results irrespective of date range within 30 seconds. Our backend engineering teams did a really good job of making that happen.”
Driving Better Results for Users
The team tracks how library contributors use the new Community Collections Dashboard, and “a lot have been using this feature,” Satya reports. “We have a way to track which libraries have been using the dashboard and what features they have been using. We generally have three or four new features in a single release, so we want to check which features are useful to users and take information from that to our next releases.”
“This was a big, useful change, because we recognized our solution wasn’t quite right and, with direct user input, adjusted to provide the data they need,” Satya says.
Want to know what it’s like working at ITHAKA engineering? Check out the ITHAKA jobs page.
