Observar sense veure l'usuari

Necessito saber què s’ha trencat. No necessito saber a qui se li ha trencat. Aquesta distinció defineix tota la capa d’observabilitat.

El context

Una app sense observabilitat és una app que descobreix els seus bugs pel canal de suport. Una app amb observabilitat salvatge — full session replay, GPS coords als errors, tracking d’esdeveniments d’usuari — descobreix els bugs abans, però treu confiança a una base d’usuaris que precisament viatja per desconnectar.

L’equilibri no és evident. El primer instint era no posar-ne. El segon instint era posar-la tota. Cap dels dos és correcte.

La decisió

Sentry SaaS (regió EU) amb scrubbing agressiu:

• Errors backend + frontend + service worker, sí.
• PII (email, IP, nom) scrubbed a nivell de SDK abans d’enviar.
• Coordenades GPS mai s’envien a Sentry, ni al context d’error ni als breadcrumbs.
• Sample rate < 100% per a transactions (cost + soroll).
• Breadcrumbs UI sense valors d’inputs, només noms d’accions.

Per què EU i no US. La majoria d’usuaris reals seran europeus (camper culture). Tenir les dades a EU simplifica la història GDPR — un menys formulari de data processing addendum, un menys argument per a legítim interès. La diferència de latència és menyspreable per a dades d’error.

Què no és

Per ser explícit:

• No és analítica. No mesuro retenció, funnels o cohorts. Si en algun moment cal, l’eina serà independent i opt-in.
• No és session replay. No gravo què cliques. No tinc cap eina capaç de reproduir la teva sessió.
• No és sempre-encès al telèfon. El SDK no es carrega abans que l’usuari accepti la política de privacitat; no s’inicia el service worker amb tracking.

El que ve

Falta una peça per tancar el cercle que va obrir el primer post. Vam començar amb tres modes — planificar, conduir, recordar — i n’he explicat dos. Al pròxim, i últim, post de la sèrie: el mode recordar. Què passa amb el viatge quan tornes a casa, com el blog generat deixa de ser text d’usar i llençar i es converteix en l’artefacte que te’n pots endur.