Metrics API

[tdstein]

We currently have a visits and usage API. Both resources return similar information, therefore it is reasonable to facade both resources behind a single interface.

My recommendation is to create a package named analytics (or similar) that contains a MetricEvent resource type. This Resources implementation would combine the results of visits and usage. The MetricEvent would contain a merged version of both resources and a reference to the original dataset.

[jonkeane]

That sounds reasonable. I know that we do not want to depend on pandas or polars, but I suspect a prime use case for these will be "I want a dataframe of this stuff so I can plot it" and so my main concern is how easy it is to get to that point. Do Resources have an easy way to make that happen already? I looked briefly to see if I could find an example of that, but might have missed it!

[tdstein]

A list of type List[Resource] can be converted directly into a Pandas DataFrame. Here's an example using the User resource.

users: List[User] = client.users.find()
df = pd.DataFrame(users)

[jonkeane]

Awesome, that's fantastic

[tdstein]

I have a working prototype available here: #170

Try it out via:

pip install git+https://github.com/posit-dev/posit-sdk-py.git@8fb160c565cc7f34dba8b26df1cbb4df5cb614e2

>>> from posit import connect
>>> client = connect.Client()
>>> views = client.metrics.views.find()
>>> import pandas as pd
>>> pd.DataFrame(views)

[jonkeane]

I tried it out on dogfood which has a decent amount of content I have access to.

>>> start = datetime.now()
... views = client.metrics.views.find()
... print(datetime.now() - start)
0:00:12.606470
>>> pd.DataFrame(views)
...
29815 rows × 9 columns

I was at first a little surprised it took 12 seconds, but close to 30k views in total, so maybe that's to be expected. We certainly don't need to optimize that just yet (but the time might come).

Doing a simple count of most popular content is easy enough:

>>> recent_views = pd.DataFrame(views)
... recent_views['content_guid'].value_counts(ascending=False).reset_index()
  | content_guid | count
-- | -- | --
8c30146e-1537-4986-a9d4-4e997bc9c2a5 | 3329
44cde4c3-65ee-4d93-8d10-4906ad57dc07 | 2606
e054cbe2-7381-4a50-8a1e-2c6298b95316 | 1343
c34bd4ac-be20-4de4-8d0d-ddefda14c51c | 993
5c18555f-21a7-4e59-ae56-2ded318b10ef | 953
... | ...
3085c2d6-42dc-4d8f-8d13-1069a347f203 | 1
d9e0793f-6748-485f-b875-ceb816303701 | 1
e94e1bd9-266a-4bb5-8b68-678bdc7ea8d5 | 1
24d482ed-dd2b-4d49-9d61-bd7d370310b9 | 1
eb6ad7fa-0d81-4424-84de-b6a129a54b6e | 1

2553 rows × 2 columns

[tdstein]

Nice! Yes, there is room for speedup via parallelization, but since the maximum fetch size is 500, there is only so much we can do on the client side.

In most cases, I am interested in the metrics for a single application, so the slowness of a full fetch doesn't bother me too much.