Shiny Usage Tracking in Posit Connect
🤔 Who actually used my Shiny app and for how long? ↗️ Is viewership increasing? Did my CEO use it?! Did you know? Posit Connect can record event-style usage information which is intended to answer questions like this and is accessed via the Posit Connect Server API. Please note: during the meetup you can ask questions here anonymously as well: rstd.io/connect-meetup-questions We will walk through several examples for getting started with the Posit Connect usage data designed to help you answer questions like: Who is visiting my content? What reports are most common? Has viewership increased over time? During/after the meetup, you can use the GitHub repo to create the dashboard in your own Connect environment as well and schedule the report to be distributed through email (with inline graphics). The goal for this code is that it is generic enough so that you can copy/paste it into your own R session and run it successfully. In order for the code to work in your environment, you need two pieces of information unique to your enterprise: Posit Connect's server path A Posit Connect API Key We’d love to hear your feedback and learn how you have taken this API and created dashboards for your own organizations as well. Helpful Links: Follow-up thread on community.rstudio.com: https://community.rstudio.com/t/rstudio-connect-usage-data-thread-to-discuss-ideas-improvements/130581 Contribute to open-source examples: https://github.com/sol-eng/connect-usage Posit Connect Server API: https://docs.rstudio.com/connect/api/ Cookbook: https://docs.rstudio.com/connect/cookbook/ R Client: https://pkgs.rstudio.com/connectapi/ Python Client (mostly deployment): https://github.com/rstudio/rsconnect-python/ Cole's slides: https://github.com/RStudioEnterpriseMeetup/Presentations If you ever have questions about Posit Connect or any of our professional products, you can use this link to chat with our team: rstd.io/chat-with-rstudio
image: thumbnail.jpg
Transcript#
This transcript was generated automatically and may contain errors.
joining us today. Welcome to the RStudio Enterprise Community Meetup. I'm Rachel calling in from Boston today. I'm also joined by Tom behind the scenes helping out with logistics. Thank you, Tom. If you've just joined now, feel free to introduce yourselves through the chat window and say hello, maybe where you're calling in from. I do want to take a moment to say it's nice to be able to share some space right now with the community.
What we do at RStudio is only made possible because of a big-hearted community. We are beneficiaries of so many selfless community members, many who are affected by the war in Ukraine. So we want to also use this opportunity to support these folks back in any way that we can. Two of our community members, Sep and Birla, had shared a few ways we can all help, which I'll share in the chat. If you do have other information to share, please feel free to do so in the chat as well.
Thank you all. For today's meetup, we are joined by my colleague, Cole, who is one of our solutions engineers here at RStudio. Cole is going to show you how you can extend Connect with the server API to see more advanced usage metrics for your content. Things like who's actually using my app and for how long, if your CEO actually used it, is viewership increasing, answers that can help focus and justify your efforts.
After Cole's presentation, we will have lots of time for Q&A as well. So wherever you're watching from right now, if that's LinkedIn or Twitter or YouTube, you can ask questions in the chat, and that will be aggregated for us here. Thank you all so much for making this a welcoming community. We really want to create spaces where everybody can participate and we can hear from everyone. I want to reiterate that we love to hear from everyone, no matter your level of experience in the field. And one quick note, if you would rather ask questions anonymously, you can do so as well through Slido. Tom will share on the screen here a short link for that, as well as in the chat. But with that, thank you all again for joining us. I would love to turn it over to you, Cole.
Overview of the RStudio Connect server API
Awesome. Hello, everyone. So the link to the slides will also be up on the screen, so if you all want to follow along yourselves. But yes, what we're going to be talking about today is on RStudio Connect, tracking usage data. So I'm going to give you a quick outline of what that looks like. The technical term for this is instrumentation data. So we'll get into that in a minute. But this is all predicated on the RStudio Connect server API. And so we're going to start with that, and then we're going to show some examples. They're all open source, as should be expected. And then some kind of ways to get involved, and then the time for questions that Rachel mentioned.
So to get started, we're going to focus on the RStudio Connect server API. So if you're familiar with Connect, which again is a professional product that RStudio sells to companies for their data science teams, it has a server API, which is important to distinguish between that, which is a part of the product and versioned with the product, and the APIs that you might develop in R and Python using frameworks like Plumber, Flask, that kind of thing. So the server API has public documentation. There's also a version hosted with your Connect server, because again, this changes over time. There's some example ways to use the cookbook, sorry, use the API with the cookbook. And then there are some client libraries that can be useful. So the R library is a little bit more well-developed. Here is the link to that R package. It's not on CRAN yet, unfortunately. Sorry. Hopefully soon. But the rsconnect-python package is the analog on the Python side of the house. But really the goal for the RStudio Connect server API is that anything you can click on and do in the UI of Connect should also be able to be done programmatically via the API.
To give you a quick overview of the types of things that the server API might be used for, on the left-hand side, we have the types of things that are publicly documented in the API. This is using a recent version of Connect. But if you're anything in the last six months or so, should have all of these. But there's a bunch of types of reports and things like that, that you could build off of the server API. Specifically, something that we highlighted recently is Connect widgets, which allows you to build landing pages and things like that for customizing the way into content. And then what we're going to be focused on today is specifically who looked at this report recently. So that use case is where instrumentation data sits. So it's just a part of the RStudio Connect server API. If these things over here on the right are really exciting to you, those are either experimental APIs in the connectapi package, or are not possible today, unfortunately, in the API. So we're always happy to hear feedback requests, feature requests, those types of things.
What is instrumentation data?
So if we move on, then, to what is this instrumentation data? So you could call it usage data. I really wanted to use the term instrumentation. So that way, if you're searching through the docs, you know the magic word for your search engine foo. But really, instrumentation data is course data that we store inside of Connect's database automatically for you when people visit your applications. So again, any application visited on Connect has this data stored in the database. Now, the types of motivating questions that might lead you into this area, you've kind of seen who looked at this report recently, or which apps are most popular, those types of things. But it's important to keep in mind, this is more data than logs are. So it's not logs that you can just add stuff into by printing to the terminal. And it's also not like a Google Analytics type of who clicked on this button, who clicked on this tab, that type of thing. But I'll show you an example in a minute of what that data looks like. And it does record the user name of user or the user GUID, the user identity, if users are logged in. If users aren't logged in, it still records the data. But obviously, there's no user ID associated with it.
instrumentation data is course data that we store inside of Connect's database automatically for you when people visit your applications.
So if you want to try to remember the term instrumentation data, you can think about it, we're instrumenting your content. We're not editing your content. We're not monkeying with your content or anything like that. We're just instrumenting it. And we're logging when we serve content from our API. So the way that you access this data, it's all stored in the database. The way you access it is through the server API. And when you do that, you can see the data. So here, I've loaded that data inside of RStudio. And you can see here, this is for a Shiny application. And Shiny applications store the content GUID. So that's the unique identifier for a piece of content, a Shiny app in this case. The user GUID. So you can see some NAs there from anonymous users, people that weren't logged in to connect. You can see a user GUID for users that are logged in, that visited an application. And then you can see the start and end time. We also have a little version flag here. So that way, if we need to change this in the future, we can. For everything else on Connect, so Flask apps, Plumber APIs, static content, what you'll see instead is there's a different API request. And what you will see is just a visit time. So there's not a notion of a session, so to speak. And so what you see is just, hey, there was a visit at this time. So you don't get this start and end kind of notion of how long were things open for. But everything else does have data. So again, no matter what you're deploying to Connect, you will have usage data here. And you can retrieve that using the API.
Example report and application
So I'm going to pivot from this. This is hopefully a bit of a high-level overview of what is this stuff. Again, it's course data that we gather for you on your applications. If you didn't know about this feature and you've had Connect for a while, hopefully, if you have a recent enough version, we've been capturing it for a long time. And so you have a bunch of data there that you get to go analyze. I also want to note before we get into the examples here that the idea behind this, we talked about building a bunch of dashboards and stuff like that inside of Connect on this. But we thought about our users, our data scientists, no matter what we build, they probably can build something better. So the goal of the API was to make this extensible, make it something that you can build your own reports, your own applications to display this data, analyze it however is most useful to you. But we want to have the examples out there in the world so that you have a place to get started.
So the first case I'm going to look at here is an example report. And this is a static. It's generated with R Markdown. It's a static report actually written by Sean Lopp, if any of you have met him in the past. And so he wrote this report that, again, generated with R Markdown. It retrieves all the data and then stores a static report on your server. So this is really useful if you want to do something like run it on a schedule and just get this report in your email. And so I have links here in the slides to the source code for the application as well as an example dashboard.
So let's take a look at that real quick. So this is the report as it's deployed on our Connect server. Again, this is public. This URL you should be able to visit in your browser. It's linked there in the slides. And it's got some nice little client-side functionality. So you get these little tooltips and stuff. But we're only just showing kind of the top five most popular Shiny applications here on the top, as well as the top five most popular static content. So you see some APIs here, some Streamlit stuff. And this is a static site. So this is just JavaScript and HTML that's out there. And then the most popular users and, you know, for each different content types.
But what's cool about this is on Connect, right, we have the feature to ship emails whenever a report runs. And so we also this is I just generated this email preview so that you could see what it might look like in your email inbox. And so this is an email that could get sent out to the data science team and say, hey, look, these are the most popular applications for the last 30 days. So if something like this seems useful for you, again, good news. This is out there on the internet. All of the source code is here. All you have to do is add your environment variables, which new versions of Connect automatically do this for you. So you literally can just type in this URL. And there's a manifest here. So you can use get back deployment and deploy it to your Connect server if you want. And I hope it works. If it doesn't, please open an issue. Because we would love to make sure that it works for you.
So we have got the R Markdown example. Yeah, I think in YouTube, you can slow things down if I'm talking too fast. So yeah, so let's go from the report to the application. So an application, as you might expect, is a little bit more interactive. And so I wrote this last night, so I may have bugs. But I felt like we needed an application to go with this. There's some really good ones in the community. But I wanted just a simple example for you all to take a look at. And the idea here is that you could interactively explore the data a little bit. It's less static. It's not going to show up in your email inbox. But it gives you a little bit more opportunity to float through the data yourself. However, data volume matters a lot more. And it just so happens that our Connect server that we use for demos is really busy. It gets lots of traffic. And as a result, I had to be a little crafty about how I implemented it. But it is public. This URL is also available if you want to go poke around. And it's kind of fun. You can edit the timeline and look at what applications, who is viewing it, and then which owner is most popular, if you will. Which I promise I didn't plan things this way. I just happen to own an app that's kind of popular. But it's also kind of fun seeing my name as the MVP.
So you can monkey around with this. Again, all of the source code is on the internet. And you should be able to deploy this to your server and poke around. Again, only the top 20. Because we have tons of apps on this server. And down here, you can see I'm using a package called Apex Charter. Which you can interact. As you interact with this, you can see the data modified there on the side. Which is actually kind of funny. Because you can see there's a little bug there. It says Edgar, but I clicked on Andre. That's awesome. Always good finding bugs in open source packages.
Community examples and next steps
So, in this repo... So, this is one of the things I'll talk more about in a second. But this repository is where we've tried to centralize a little bit the examples for usage data inside of RStudio Connect. Or instrumentation data, if you want to use the formal term. And there are a couple of other examples here. So, ConnectViz is a package that a community member has been maintaining and building. And so, this is just a kind of teaser for them and an example there. There's also a Connect Analytics package, which similarly is maintained by a member of the community. And I'm sure there are many more awesome examples out there. We've talked to a bunch of customers that have built their own dashboards. Sometimes they can't share those, though. Because of NDAs and all that jazz. But we still love seeing this kind of stuff. And we love whenever it's useful for y'all.
So, I want to recap. All of this data is automatically stored by Connect. So, Connect has it. As a publisher or an administrator to a Connect server, you have access to this data. Something I didn't mention is that if you're a publisher, you don't get, like, see the entire world privileges like I have as an administrator. But you can see all of the usage data for your applications. And so, these reports still should be, excuse me, useful for you. And so, you can still deploy these applications, that kind of thing. You just need to use the API key of an administrator if you want kind of global see all of the reports, that kind of thing.
So, we started a discussion on RStudio community. So, if you want to be a part of a discussion that lives a little bit longer than this livestream, then this is a good place to do that. Then there are the open source examples, which we love contributions, issues, comments, those types of things. You can also build your own open source packages or tooling to make this kind of display easier. And then whether or not you are able to, in your workplace, share this data publicly or these reports in the code publicly, we would still love to hear it. So, feel free to contact your CS rep. We can customer success representative. And we would love to hear what's going on, whether there are new features you need, whether things have worked well. RStudio Connect team loves to have that feedback as well. And then feature requests, again, are always welcome as well.
So, hopefully, this has been an interesting kind of teaser to get the usage data in your brain and starting to, like, think about what are some cool things that you could build. These are some sample questions that maybe if you want to respond to in the chat, would be most welcome. I have to admit, I'm both surprised and appreciative. I wanted to show this. This is a bit of a last minute thing. I built a realtime usage data dashboard, too. And this one is watching our demo server just in case, like, everybody at once just all tried to, like, jump on our demo server and started to, you know, suffer. But nobody did. So, it's good. We had a workshop this morning. So, you can see this big spike here. You can see my testing here and here. And then this is the workshop probably wrapping up. And this is y'all not bum rushing my server. So, thank you. But at the same time, if you do visit the application URL, so, the Shiny app URL, then this number should start increasing. So, maybe that's, I don't know, a teaser introduction to breaking my server and making me work hard. So, good times. But I would love to open for questions.
Q&A
Yeah, I can help pull questions up for you, Cole. And Tom, if you could put the link to the Slido on the screen, that would be helpful, too. So, you can ask questions either in YouTube live if you're there, if you're on LinkedIn, you can put them in the comments. Or you can ask questions anonymously through that Slido link on the screen. But Cole, one of the questions that came earlier was, is this feature included in all RStudio Connect licenses or is it a premium thing that not everybody would have?
Yeah, that's a great question. So, this is included in all RStudio Connect licenses. So, any RStudio Connect will have this. The one caveat is that API hosting is a base feature, I think, maybe? Standard feature? Standard? I forget all the names. Standard, thank you. And so, obviously, we don't have instrumentation data for content that can't be deployed to Connect. So, if you want to publish a Plumber API or a Flask API or something like that, that is a feature that requires the standard kind of license. So, that's the only limitation that I think should be there. So, if you have a Connect server, you should have this data available to you. It's a great question.
Cole, can I ask you a question as someone who manages our own internal server? Is there something that you would wish that this dashboard had or something that you're hoping the community might be able to help contribute to?
Yeah. So, this is partly one of the things that I... This is kind of a fun backstory. So, I used to be a Tableau administrator. And Tableau has a similar type of instrumentation data, usage data, that kind of thing. And I had this little chart that I really liked that I built with a packed bubble plot. And so, then you could click on the bubbles, and it would filter the other bubbles. And it was just kind of fun. I don't know how useful it was. I mean, there might be some data viz experts who are like, yeah, don't use packed bubble charts. Anyways, packed bubble charts are... I don't know. I couldn't find a good library for them inside of the R ecosystem. So, my goal with this little demo application was to be able to click on the little bars and it filtered things. And I ran out of time. So, I didn't do that. So, I think really interactive dashboards that allow you to kind of dive through the data is where the Connect viz package is going, is where there are a lot of opportunities for this type of thing. And so, I would really love to see those types of apps out there more of, like more of the interactive kind of dive through the data. Because it does, it takes time to build those types of things. But we love to celebrate them on the Connect usage repo. And we would love to contribute. And sometimes just time gets in the way of building applications. I've had this idea... Actually, this real-time dashboard, Delio, this has been an idea in my head for like two years or more. Yeah, three and a half. Three years and some change. And I finally coded it up this morning. So, anyways, I would love to see more stuff like this. Because I feel like my imagination is not quite as robust as a lot of the people in our community. So, I'm just mostly excited to see what they dream up.
I'm glad we gave you the inspiration to make that this morning.
I see there's quite a few anonymous questions coming in too. And one was, when will the connectapi be released to CRAN? Or do you have an anticipated date?
Yes. Such a good question. Well, unfortunately, I don't know. Because I was hoping to do it by the end of last year. So, I am delayed. But that said, we are kind of leaning for soon-ish. So, anyways, if you are using the connectapi package and have... I would love if you could update to the most recent version and make sure there are no bugs. Having some issues come in would be a good sanity check that like, okay, we need to fix these bugs before we put it on CRAN. But yes, we are planning to put it on CRAN in the near-ish future. But there's just a lot of other priorities that kind of get in the way sometimes. So, we're also trying to restructure that. So, I'm not the bottleneck on that either. So, apologies for the delay. This is something we've been wanting to do for a long time. And hopefully, it'll be soon-ish-y.
Soon-ish-y. I like it. Can you reiterate how people could access it today if it's not on CRAN?
Yes. That's a fantastic question. So, inside of your RStudio session, which... One moment, please. Here we go. I'm gonna move my little dashboard away. So, if you're inside of RStudio, this is me inside of RStudio. And what you want to do is you want to use the remotes package or DevTools and install GitHub. And then RStudio slash connectapi. And that should get you the latest version. Unless you have a bad GitHub pat in your environment. Unsetenv GitHub pat. Then it won't work. And you'll look silly on your demo. And in my case, I have the latest version. So, it's not going to ask me to install it unless I say force true. And then it's gonna ask me to install the entire world. But I'm gonna say no, thank you. And then I'm gonna have another problem. Good times. So, this is why live coding demos can be problematic. But anyways, this code should generally work most of the time. Remotes, install GitHub, RStudio slash connectapi. And then soon as she, we will have installed that package as connectapi and the world will be a much happier place and I won't have this issue.
Awesome. Thanks, Cole. There was a question that was, will this be available later? Will this recording be available later? And yes. On the RStudio YouTube, the link that you're on right now, if you're watching it on YouTube, will just turn into the recording there.
Another question was, could you speak to the development alignment of the connectapi versus rsconnect API releases, which is recommended to incorporate?
Interesting. I'm not sure I'm completely following that question. I'll try to speak to it. I think the rsconnect API releases, is that talking about the RStudio Connect server API releases? That sounds, yeah, that makes sense. Okay. Cool. I'm tracking here, I think. So, inside of, and I'll clarify the question a little bit in case somebody's confused. So, inside of our documentation, right, we have this API reference. And this is always, this URL that's public is always for the most recent version of connect. So, you can see this is a release that we did really recently. I think this was last week, maybe. So, I haven't even updated our demo server yet because I've been focusing on preparing for this webinar. But if I go to my connect server and I go to the documentation tab, you can see I'm running a different version of connect. And so, I'm not using the same version of the API that, like, that is public on the internet. So, if I click on this server documentation, again, this is in my connect, you know, installation, if you will, you can see it has a different version of the API. And so, what the question is asking about is I have a version of connect installed and there's a latest version of connect installed that's on the internet. Like, that has the documentation hosted on the internet. And if you're wondering why this dark theme is there, it's just a browser add-in. So, it's the same. It's the same exact documentation. But and the question is, okay, well, how does connectapi track against this? So, the good thing is we try to change this connect server API relatively infrequently. And so, there's not a whole lot of changes that happen. Now, occasionally changes do happen. And so, what we try to do within the connectapi package is to track the latest. And so, if you go to RStudio connectapi, pass the bison. I hope those are bison. I don't know what they are. Horned creatures. So, if you look at the connectapi package, there is a magic variable somewhere that has the version and there's a function that, like, shows what version. And it'll warn you if the version's different. But this is the version that we have tested with connectapi and that we have our little integration test suite and everything's happy-go-lucky. So, we will bump this soon to the newest version of connect and make sure that everything works and all that jazz. If the version of connect that you're using is different from this version, then we'll throw a little warning, like, hey, just so you know, the version that you are using of connect is different from the version that we tested the package with. That warning is mostly an FYI. And most of the time, it's not going to have issues. And so, that's a good thing. Normally, things are pretty backwards compatible. We try to be really careful about breaking backwards compatibility, both on the connect side as well as on the connectapi side. But there are occasionally breakages. So, for instance, one of those is the ACL, like, how you look at which users have accessed applications. We did throw in a warning of, like, hey, this version of connectapi, 0.1.0.9027. These versions will get nicer whenever we go to CRAN. We change things, right? So, this API is deprecated. You should not be using this function. Instead, you should be using this get content permissions function. So, we try to be really careful about backwards compatibility. Hopefully, it's all just always happy-go-lucky. If you run into issues, again, issues are welcome. And we try to also warn you. If we know that we broke something, we try to update things there. We also try to throw things in this giant news file. So, you'll see some breaking changes here. We changed, like, for instance, the signature on some of these vanity URL changes when the APIs went public. So, anyways, there are a couple of places to check. And then we try to warn you if you're running into something that is a breaking change for sure.
And the last thing is, if you're using experimental API, we also warn you and say, hey, this is experimental, just so you know it might change. So, the way that I recommend to generally use this package is to if you have content that depends on it, whenever, like, try to coordinate development on that with the upgrade of connect. And kind of you might want to upgrade connect and then upgrade the connectapi package. And that should generally keep you happy. We talk about that here as well. Kind of how to manage this kind of stuff. And feedback, again, is always super welcome. So, that was a lot to say. But hopefully that was a useful answer to your question. We do our best. And it's kind of hard to do sometimes.
Thanks, Cole. There's quite a few questions coming in on Slido right now. And most upvoted one so far is, is there a technical difference with the instrumentation data that is available with the built-in SQLite config of RStudio Connect versus Postgres config?
Yeah, that's such a good question. Man, that's awesome. So, yes. So, the instrumentation data is the same. However, there is a caveat. And the caveat is an unfortunate one that I'm hopeful we get a chance to remedy at some point soon-ish. You can see how I think about things. I just want everything to be soon-ish. The instrumentation data is in a separate area, if you will, inside of the database. And so, when you switch from SQLite to Postgres, we don't yet have a way to migrate all of that data from SQLite to Postgres. So, the data is the same on both ends. But SQLite and Postgres and all of other databases out there in the world have their own way of notating things like dates and booleans and all that kind of jazz. And so, as a result, the migration story is not a very good one today. But that's something that we, again, would love to improve. And if you are in this case where you're like, man, we're thinking about switching to Postgres and we don't want to lose all our data, definitely reach out to us. We would love to kind of chat with you through that experience. And so, that's the one caveat. This is a really good question because there shouldn't be and we want there not to be a difference at all between the two and to be able to have a smooth migration story. But today, the migration story is the weak spot in that kind of setup. So, yes. No difference unless you're trying to switch across, in which case the history won't be maintained. So, you want to be thoughtful about that if you can be. And reach out to us, again, if you're having trouble because that's always helpful.
Thanks, Cole. Another question was, could you clarify between Connect Widgets and today's examples with the instrumentation data?
Yes. Man, these questions are so good. So, if we go to GitHub and go to Connect Widgets, so, the Connect Widgets package is really oriented around a custom kind of dashboard, if you will, like landing page for RStudio Connect content. So, what that would look like is inside of... So, remember, there were a couple of different things and we're really focused on this. Who looked at this report recently? Connect Widgets is really focused on this landing page. So, for instance, if I had a bunch of applications, let's say I have a bunch of applications that are focused on usage, I might want a landing page that's just for applications that are oriented around usage. So, I might tag them all and say all of these applications have a usage tag on it. And then I might build a report using Connect Widgets to say these are all the reports that are... Show you your usage data. So, that somebody could go to, you know, connect.com slash usage, whatever my Connect URL is, slash usage, and then I would get a landing page and it would have like quick links to all of the other usage dashboards. So, that I could kind of go to the one that I want and flip between them easily and that kind of thing. So, Connect Widgets is really about the landing page. And so, what that would look like is on RStudio Connect in a... So, Connect Widgets is really focused on pages like... We have a lot of content on this server. So, patience is good. This page, right? So, Connect Widgets is really about changing the experience of finding content and, you know, giving you some customization for this kind of meta, like inside of Connect, building landing pages for Connect. The usage dashboard is all about who is using the other applications on Connect and how much. And so, what's kind of interesting is that though they hold different kind of homes and use cases, you could tie them together, right? Like, for instance, you could tie together and have a report that displays all the content that is most popular. So, you could do all kinds of things. They're scoped in different kind of spaces. The Connect Widgets package uses the Connect API as well. It doesn't use the connectapi package yet because connectapi is not on CRAN. But eventually, these things will all be hopefully tied together nicely. And yeah. So, if you're wanting to display content, use Connect Widgets. If you're wanting to look at usage data, use instrumentation data. And if you want those things together, you can do that. So, good times.
Thanks, Cole. I see Sam had asked a question earlier on Slido that was, is there a similar capacity available for Shiny server open source to track many apps on the server?
That is a great question. I don't believe so. I think I have to admit I'm very rusty on Shiny server. So, yeah. I don't believe so. Although I know that there have been kind of DIY approaches to using things like Matomo is an open source Google Analytics. There's some other alternatives as well. Yeah. Tom has got a really cool link here that I want to share on usage metrics. Does this talk about Shiny Server Pro? Yeah. Cool. Let me find where's brave. So, this is a anyway, there are ways to do this. They are a bit old. But they should still work. And so, this is an example, I believe, using Google Analytics or Matomo in this case for tracking. And this would be the more granular data around your application, right? So, you could do things like who clicked on which button, that kind of stuff. So, there definitely are options to do it. It is a little bit more DIY, unfortunately. Connect and Shiny Server are very different beasts. So, the mechanism is very different. But you totally can accomplish those types of things using open source tooling and building that type of capability, for sure. And even more granular. Again, if you whether you're using Connect or Shiny Server Pro or Shiny Server, rather, you can use these more granular analytics to get data around who's using which buttons kind of like a standard website. And so, that should all be possible.
Thanks, Cole. That was actually one of the other questions on Slido. If you could see exactly who was viewing the app, and how would you be able to do that in the dashboard?
Right. So, and that's thinking about like more of like a real-time sense, I imagine. I think to know like exactly who from your company was viewing it and when. Yeah. So, that is definitely doable. And so, is this the app? Yeah, yeah. So, and you can see that here, right? So, these are the owners of the application. So, the people that have built applications on the server. But these are the viewers of the application. And so, I didn't hook up the click the other direction, right? That if I click on this, it goes back and filters the timeline. But the data is very granular. And so, if you remember back to in our presentation, when we show the example data, this user GUID here is the user within your application. So, there's another endpoint that allows you to retrieve the users and do a join and get the user data. And so, the username can be, I mean, their email address, I mean, whatever, right? Can be correlated with the application. And you can see the time, right? So, you can see who visited when. And I have aggregated that in this example. But inside of the code, you can see all of these examples. So, if you look at where I'm getting the viewer from. So, there's the viewer. So, I'm taking the raw Shiny data. I'm filtering if there is a timestamp selected, a time window selected. Then I'm grouping by the user ID, tallying. And then I'm joining the user data based on the GUID and the username. And then arranging, descending by the count. And so, hopefully, these examples can kind of sharpen your appetite a little bit and get you thinking about this. Because you do have that granular data. And I just kind of didn't show a very user-specific view, I guess, within the application that I built as an example.
Yep. Thanks, Cole. Yeah, I think I messed up reading that question out. Because they're also asking or saying a report on what user is using which app. Like Shiny or R Markdown would be useful, too. Maybe more like user-focused reports, too. Yeah. Yeah, exactly. And so, you could totally think about like it's a small modification to this application that when I click on David, let's say, it filters the timeline. So, I can see when is David most active. It could filter the owner, like which reports does David like to view, right? Like who is David's app builder, if you will. And it could filter this by app to see what are the apps that David's viewing. So, you could totally build these types of interaction for sure. And again, this example app is just using Shiny data. But again, inside of the source code, you can see this nice little commented outline here that is how you would retrieve the static usage data. I was originally doing that. You can see it took about three minutes to run that request. I have a cache. So, it's good. But I wasn't displaying the data. And so, I didn't put it in here. But again, uncommenting this and then creating a view for it or aggregating it in, and you would have the Markdown reports and API requests and all of those things in there as well. So, yes, all of that granularity of who's looking at which app, when, and if you're on a Shiny app, how long, right? All of those questions can totally be answered. And the limitation right now is just the quality of our examples. But again, ConnectViz has some other examples that are good. Connect Analytics has some. So, there's some other examples in the open source community you can use.
I see Lauren commenting, am I in the top three in the viewer list? I love Connect. Yep. Yep, we're really in the top two if we discount all the people who use our server that aren't users, right? They're just kind of public visitors. So, yeah, it's fun. I know this question was showing previously. Thank you, Tom. The question was, is it possible to know which Shiny tab or table is mostly viewed and clicked? That would be a nice feature. Also, a good feature would be to predict the next visit.
Yes. See, these are the types of things that I feel like, yeah, there should be like a hackathon for like viewer trendline prediction. Yeah. So, these are great. Yeah. We love feature requests. The reason that we don't have more granular data is because when RStudio Connect is serving your application, we get the request for the application or for the API or those types of things. The more granular data happens inside of your application, right? Inside of the front end of the application. So, that's sitting different from us. And in order to get more granular data, we would have to like start monkeying with the R process, which is kind of gross. We don't want to do that. And so, really, that's where I think there are open source kind of initiatives there on the more granular data. I think there's like a Shiny analytics package. There are the Google analytics or Matomo analytics that I mentioned that are pure front end kind of analytics. So, it's not something that we have a plan to build currently for like, again, the more inside of an application, what's going on, what's most popular. But there are kind of patterns there. And so, it's just kind of more on the open source ecosystem today. But yeah, if we can find a way to do that, that would be, I agree, that would be very cool to just kind of get it for free.
Definitely. Another question was, how stable is the connectapi R package? It seems like a lot of functions were changed recently.
Yeah. So, that's a great question. So, stability is always in the eye of the beholder, I would say. And so, if you look at the questions that have changed recently, right, one of the things about our news file is because we've never released a CRAN, like everything just gets piled up. So, when you look at recent, this is like over the past couple years. And generally speaking, I feel like I haven't really done much on this package over the last couple years. So, from my point of view, it feels like it hasn't changed that much. What has changed and why there are some of these breaking notes, it's also worth noting these breaking notes are kind of like a very, very particular person's breaking notes, right? Like, for instance, we renamed the argument to a function. So, technically, it would break, but literally, all you have to do is change server to host, or something like that, host to server. And that'll resolve the issue. So, we try to make these breaking notes. So, it's like, hey, these are the things to look at. But once an API is stable and documented and public, that's where things definitely slow down and are more stable. And you can see in our documentation that most of the functions that used to be experimental inside of connectapi are now stable. And so, as we move all of them to being publicly documented stable APIs, the stability of connectapi will continue to improve. But yes, generally speaking, I have had to do very little in the way of changing these reports. Once I switched them over to connectapi a couple years ago and then left it, connectapi was not the reason that they broke. If that is helpful at all. But again, we would definitely be open to resolving issues and things like that if you all find them. But the goal is to be as stable as possible. And that's sometimes hard to balance with, like, having the new feature for the new people that are trying to have the new features.
Definitely. I see there was another question earlier that was around, I think it maybe was with John. It was, does the R package connectapi have to be updated at the same time as the RStudio Connect server?
So, generally speaking, no. And the reason is because of that
