Good news is that the Sentry DSN is now an env variable SENTRY_DSN , so feel free to plug in your own there (same goes for the desktop connectros, if you guys are compiling your own versions).
Re matomo, we can’t do that atm, our company is entirely focused on Speckle and it really helps us knowing how usage/adoption is affected by the decisions we make. So please consider leaving telemetry on if you’d like to support what we do
The frontend looks easy enough, the server would probably require a change to the matomo-tracker library. I think we are most interested in matomo stats from the client side anyway so if I put a PR in your happy to use the setTracker command and have a environment variable for the second Matomo tracker?
Also what are your thoughts on having separate environment variables for disabling matomo and sentry? As for some installations we would want to enable our own sentry error capture but might not be allowed to send anonymised stats to your matomo for regulatory reasons.
Not setting the SENTRY_DNS var will disable it. There’s a superflous extra var (DISABLE_TRACING) that I should remove at one point:
For matomo, it can be disabled via DISABLE_TRACKING:
Re the secondary tracker: this sounds like a good idea! We can easily add that for the server side, unsure at the moment how easy that would be for the frontend. This will be a good way for both of us to get the data we need!
I’ve raised this as an issue that will make its way in our next sprint - and we’ll aim to have something in place by end of the month. Does this timeline sound ok? We want to do this ourselves so we internally “grok” it, as it’s quite important
We’d be happy to join a call and share our thoughts on general event logging if that helps with the grokking. We are currently in experimenting with a single logging function in the desktop clients that passes on the events to multiple services (so that we can evaluate them), but a similar approach would work for this situation. There is also the Kafka integration we rolled into v1 that covers similar ground.
Hey @teocomi - it is important to us to see how many of our team members are using our v2 server. While we could deploy a patched version that only points to our matomo server, we would prefer to deploy the vanilla image. Would you be open to a stop-gap PR that allows a second matomo server to be defined in ENV variables and just sends all events to both servers?