Product analytics per a startups: què mesurar des del dia 1

Estàs a punt de llançar el teu producte i arriba el moment d'instal·lar una eina d'analítica. La resposta per defecte és gairebé sempre la mateixa: Google Analytics. Tothom ho fa, és gratis, n'hi ha prou amb un script i ja tens dades.

GA és una eina molt potent. Està enfocada sobretot a entendre tràfic web i campanyes de màrqueting —d'on venen les visites, quines pàgines veuen, quines campanyes converteixen— però la versió actual (GA4) també incorpora funcionalitats que permeten fer anàlisi de producte: events personalitzats, funnels i retenció.

Però si estàs construint un producte —un SaaS, una app, una eina— les preguntes que importen són d'una altra naturalesa:

• Els meus usuaris entenen com funciona el producte?
• Quants arriben al moment que els aporta valor?
• Per què els que se'n van se'n van?
• Quines funcionalitats es fan servir i quines no?

GA pot respondre aquestes preguntes fins a cert punt, però la seva UX i el seu model de dades estan pensats al voltant de la sessió de navegació, no al voltant de l'usuari i les seves accions dins del producte. Per això hi ha una categoria d'eines específiques anomenades product analytics: dissenyades des de zero per centrar-se en l'usuari i el seu comportament. A la pràctica, és habitual que els dos convisquin: GA per a màrqueting i adquisició, una eina de product analytics per a tot el que passa un cop l'usuari entra al producte.

Abans d'instal·lar res, la pregunta correcta és una altra:

Quines decisions vols prendre amb les dades?

Aquest article parteix d'aquí: definir què necessites saber i com una eina com PostHog t'ajuda a respondre-ho des del primer dia.

Què hauries de poder respondre des del dia 1

L'objectiu de l'analítica de producte no és recollir dades, sinó respondre tres preguntes. Si no pots respondre-les, no estàs mesurant el que importa.

1. Els usuaris arriben al moment de valor?

Cada producte té un moment concret en què l'usuari pensa “això m'és útil”. A la indústria s'anomena activació , i té casos famosos:

• Slack: un equip que ha enviat 2.000 missatges
• Dropbox: un fitxer en una carpeta en un dispositiu
• Facebook (en els seus orígens): 7 amics afegits els primers 10 dies

Per al vostre producte, heu de tenir una resposta concreta a aquesta pregunta abans d'instrumentar res. Si no en tens, no és un problema d'analítica — és un problema de producte que has de resoldre primer.

Un cop definida, vols saber: quin percentatge dels usuaris que s'hi registren arriba? Quan triguen? On abandonen pel camí?

2. Què fan realment dins del producte?

El que tu imagines que fan els teus usuaris i allò que realment fan són dues coses diferents. Gairebé sempre.

Vols saber quines funcionalitats es fan servir, quines passen desapercebudes, i on hi ha fricció. Aquesta informació et permet prioritzar millor: deixar de polir coses que ningú no toca i invertir on el comportament real ho demani.

3. Tornen?

Adquirir usuaris és el principi. El que fa que un producte creixi és que tornin. Vols saber quin percentatge torna després del primer ús, amb quina freqüència i quins comportaments del primer dia estan correlacionats amb una retenció més alta. Aquesta correlació és or: et diu què hauries d'optimitzar a l'onboarding.

Si podeu respondre aquestes tres preguntes, ja esteu prenent millors decisions que la majoria de startups que coneixem.

Per què PostHog

Hi ha diverses eines de product analytics al mercat, i l'elecció depèn del context de cada equip. PostHog és una de les que recomanem per a startups en fase inicial pels següents avantatges:

Tot en una mateixa eina. Esdeveniments, funnels, retenció, session replay, feature flags i A/B testing en un únic producte. Per a un petit equip, no haver d'integrar i pagar tres o quatre eines diferents és un guany operatiu real.

EU Cloud disponible. Per a startups europees, aquest punt és més important del que sembla. Pots triar que les teves dades es processin i s'emmagatzemin en infraestructura europea, cosa que simplifica considerablement la conversa amb el teu DPO i la teva política de privadesa.

Tier gratuït utilitzable. El pla gratuït cobreix volums realistes per a una startup en fase d' early traction - al voltant d'un milió d'esdeveniments al mes a l'hora d'escriure aquest article (verifica les xifres actuals a la pàgina de pricing abans de comptar-hi). Pots arribar lluny abans de prendre decisions de pagament.

Què configurar des del primer dia

Tothom comença amb la temptació d'instrumentar-ho tot. Sis mesos després, ningú recorda què vol dir un esdeveniment amb un nom críptic com "button_click_3" i el dashboard fa por. La regla pràctica és la inversa: instrumenta poc, instrumenta bé i amplia quan tinguis preguntes que realment no puguis respondre.

Aquests són els quatre fonaments que has de tenir des del dia 1.

Identificació d'usuaris correcta

Aquest és el punt on la majoria d'implementacions fan aigües i no se n'adonen fins mesos després, quan els funnels donen números que no quadren.

PostHog -i qualsevol product analytics seriós- treballa amb dos tipus d'identificadors: anònim (generat al navegador la primera vegada que algú entra al teu lloc) i identificat (el teu user ID intern, que assignes quan l'usuari es registra o fa login). El moment crític és el signup: just després de crear l'usuari, has de trucar a la funció d'identificació de l'eina per lligar la sessió anònima amb l'user ID definitiu. Si no ho fas correctament, els esdeveniments del visitant anònim queden orfes i no es lliguen a l'usuari registrat. Resultat: el funnel "landing → signup → onboarding" s'ensorra perquè abans i després del signup són dos usuaris diferents als ulls de l'eina.

A la inversa, al logout cal fer un reset de la sessió per evitar barrejar dades de diferents usuaris en dispositius compartits — pensa en un ordinador d'oficina o un mòbil que es presta.

Si tens app mòbil i web, planteja't des del principi com identificaràs el mateix usuari en ambdós llocs (sol implicar passar l'user ID des del backend en fer login). És una conversa de mitja hora amb el vostre equip que t'estalvia setmanes de neteja de dades més endavant.

Un sol funnel, ben definit

Resisteix la temptació de muntar deu funnels el primer dia. Comença amb un: el camí des de la primera visita fins al moment de valor.

Per a un SaaS típic seria alguna cosa com: visita a la landing → inici del signup → signup completat → onboarding completat → primera acció de valor. La clau és el darrer pas: aquesta “primera acció de valor” no és un esdeveniment genèric, és l'acció concreta que vas definir com a moment de valor abans de començar.

Aquest funnel us donarà la xifra més important que mesuraràs els primers mesos: el percentatge d'usuaris nous que arriben al valor. Si esteu per sota del 20-30%, no teniu un problema d'adquisició — teniu un problema de producte. I cap inversió en màrqueting no et resoldrà això.

Session replay, amb les precaucions que no surten als tutorials

El session replay és potent, sobretot per detectar fricció a l'onboarding que cap funnel et mostrarà. Però té tres costos reals que cal conèixer abans d'activar-lo en producció.

Privadesa. Per defecte, el replay pot capturar el contingut dels inputs. Això inclou contrasenyes, dades de targeta, missatges privats. Cal activar el masking d'inputs a la configuració i marcar explícitament els elements sensibles perquè no es gravin (totes les eines de session replay tenen mecanismes per fer-ho). Si tractes dades mèdiques, financeres o de menors, la conversa amb qui porti el compliment legal no és opcional.

Cost. El replay genera molt volum. Enregistrar el 100% de les sessions encareix la factura ràpidament. Una taxa de mostreig del 10-25% és suficient per a la majoria de casos, i la pots pujar temporalment quan investiguis un problema concret.

Segmentació mínima

No cal muntar un sistema complex d'audiències. Però sí que has de capturar tres propietats des del primer esdeveniment:

• Canal d'origen (paràmetres UTM capturats al primer touch i persistits a l'usuari, no només a la sessió).
• Tipus de compte (free, trial, paid — actualitzat quan canvia).
• Cohort de signup (mes d'alta, com a mínim).

Només amb aquests tres atributs pots respondre al 80% de les preguntes que et faràs els primers sis mesos: la retenció és pitjor en usuaris que vénen de paid social? Els del pla free completen l'onboarding al mateix ritme que els de trial? El producte funciona millor per a la cohort d'aquest mes que per a la de fa tres mesos?

La resta de segmentació pot esperar fins que tingues preguntes que aquestes tres no et resolguin.

Errors habituals

Veiem aquests errors repetidament a startups que ens demanen ajuda amb la seva analítica:

Mesurar massa coses des del principi. Cinquanta esdeveniments instrumentats el primer mes és un símptoma, no un èxit. Vol dir que no has decidit quines preguntes importen. Sis mesos després, ningú recorda què mesura cada esdeveniment i tothom evita afegir-ne de nous per por de trencar alguna cosa. Comença amb pocs i ben definits.

No tindre un moment de valor definit. "Vull veure com es fa servir el producte" no és una pregunta. "Quin percentatge d'usuaris crea el primer projecte els primers 7 dies" sí. Si no ho pots formular així, instrumentar és prematur.

Confiar només als dashboards. Els números et diuen què passa, no per què. Un funnel que cau a l'onboarding et diu on, però necessites veure tres session replays per entendre que els usuaris no troben un botó. Combina sempre quantitatiu i qualitatiu.

No actuar sobre les dades. Mesurar i no canviar res és pitjor que no pas mesurar. Genera la sensació de control sense els resultats. Si la teva ràtio d'activació fa tres mesos que és al 18% i no ho has tocat, l'analítica no és el teu problema —la priorització ho és.

Tractar el deute d'instrumentació com a invisible. Cada esdeveniment mal nomenat, cada propietat inconsistent, cada funnel que no quadra perquè algú va canviar el flux i no va avisar - això és deute tècnic, igual que un test trencat. Inclou-ho a la teva planificació; no ho arrossegueu fins que ningú es fiï ja de les xifres.

Conclusió

Al principi, és fàcil pensar que el problema és tenir més dades. Gairebé mai no ho és. El problema és tenir preguntes millors — i, sobretot, actuar sobre les respostes.

Una analítica que no canvia decisions és overhead disfressat: genera la sensació de control sense resultats. Quan instrumentes alguna cosa nova, la primera pregunta no hauria de ser "com ho mesuro" sinó "què faré diferent quan tingui la resposta". Si no teniu una resposta clara a la segona, no val la pena respondre la primera.