Canister-side usage metrics, good solutions?

Hi all,

I wanted to start a conversation around usage metric gathering on the IC.

Client-side metrics (Google Analytics, Matomo, etc) are easy to implement on the IC, as frontend code just needs to include the relevant snippet and user behavior can be tracked (ethically or not), which works exactly the same on the IC as it does in Web2.

Server- (or canister-) side metrics are another story. Server-side metrics are metrics gathered on the server, like for instance the number of times a particular page was loaded. In general it it less intrusive because no extra code is running in users’ browsers, and there are fewer privacy concerns if the server only tracks which pages were loaded, not by whom.

Given the current system API this cannot be implemented in canisters for query calls, and update calls are often too slow to serve actual pages. A workaround is to still use client-side code to increment e.g. a canister counter through update calls. Unfortunately this again involves code running in the user’s browser, and (due to the limited interface the system API gives the canisters) no effective IP filtering can be done to differentiate legitimate calls from spam calls. This means the actual metrics may not at all reflect reality.

What solutions have people come up with? What would an ideal solution look like, is this something we should try to defer to boundary nodes?

4 Likes