Imagineu que sou un emprenedor en creixement que acaba de crear un lloc web i una aplicació mòbil (per exemple, per a una botiga de bunyols). Voleu connectar l'anàlisi d'usuaris amb un pressupost reduït, però no sabeu com. Tothom al voltant utilitza Mixpanel, Facebook analytics, Yandex.Metrica i altres sistemes, però no està clar què triar i com utilitzar-lo.
Què són els sistemes analítics?
En primer lloc, cal dir que un sistema d'anàlisi d'usuaris no és un sistema d'anàlisi de registres del propi servei. El seguiment del funcionament del servei se centra en l'estabilitat i el rendiment, i els desenvolupadors el realitzen per separat. L'anàlisi d'usuaris es crea per estudiar el comportament de l'usuari: quines accions realitza, amb quina freqüència, com reacciona davant les notificacions push o altres esdeveniments del servei. A nivell mundial, l'anàlisi d'usuaris té dues direccions: l'anàlisi mòbil i l'anàlisi web. Malgrat les diferents interfícies i capacitats dels serveis web i mòbils, treballar amb el sistema d'anàlisi en ambdues direccions és aproximadament el mateix.
Per què fer-ho?
Es necessiten analítiques d'usuaris:
- per controlar què passa en utilitzar el servei;
- canviar el contingut i entendre on desenvolupar, quines funcions afegir/eliminar;
- per trobar allò que no els agrada als usuaris i canviar-ho.
Com funciona?
Per estudiar el comportament dels usuaris, cal recopilar un historial d'aquest comportament. Però què cal recollir exactament? Aquesta pregunta representa fins al 70% de la complexitat de tota la tasca. Molts membres de l'equip de producte han de respondre junts a aquesta pregunta: cap de producte, programadors, analistes. Qualsevol error en aquest pas és costós: és possible que no recolliu el que necessiteu i podeu recollir alguna cosa que no us permeti treure conclusions significatives.
Un cop hàgiu decidit què col·leccioneu, heu de pensar en l'arquitectura de com recollir-lo. L'objecte principal amb què treballen els sistemes analítics és un esdeveniment. Un esdeveniment és una descripció del que va passar que s'envia al sistema d'anàlisi en resposta a una acció de l'usuari. Normalment, per a cadascuna de les accions seleccionades per al seguiment al pas anterior, l'esdeveniment sembla un paquet JSON amb camps que descriuen l'acció realitzada.
Quin tipus de paquet JSON és aquest?
El paquet JSON és un fitxer de text que descriu el que va passar. Per exemple, un paquet JSON pot contenir informació que l'usuari Mary va realitzar l'acció de joc Iniciat a les 23:00 del 15 de novembre. Com descriure cada acció? Per exemple, l'usuari fa clic en un botó. Quines propietats s'han de recollir en aquest moment? Es divideixen en dos tipus:
- súper propietats: propietats característiques de tots els esdeveniments que sempre estan presents. Aquesta és l'hora, l'identificador del dispositiu, la versió de l'API, la versió d'anàlisi, la versió del sistema operatiu;
- propietats específiques de l'esdeveniment: aquestes propietats són arbitràries i la principal dificultat és com seleccionar-les. Per exemple, per al botó "comprar monedes" d'un joc, aquestes propietats seran "quantes monedes ha comprat l'usuari", "quant costen les monedes".
Un exemple de paquet JSON en un servei d'aprenentatge d'idiomes:
Però per què no recollir-ho tot?
Perquè tots els esdeveniments es creen manualment. Els sistemes d'anàlisi no tenen un botó "desa-ho tot" (i això no té sentit). Només es recullen aquelles accions de la lògica del servei que siguin interessants per a alguna part de l'equip. Fins i tot per a cada estat d'un botó o finestra, no tots els esdeveniments solen ser d'interès. Per a processos llargs (com ara un nivell de joc), només el principi i el final poden ser importants. El que passa al mig potser no s'ajunta.
Per regla general, la lògica del servei consta d'objectes: entitats. Pot ser una entitat de "moneda" o una entitat de "nivell". Per tant, podeu compondre esdeveniments a partir d'entitats, els seus estats i accions. Exemples: "nivell començat", "nivell acabat", "nivell acabat, raó - menjat per un drac". És aconsellable que es tanquin totes les entitats que es puguin "obrir" per no vulnerar la lògica i no complicar el treball posterior amb l'anàlisi.
Quants esdeveniments hi ha en un sistema complex?
Els sistemes complexos poden processar diversos centenars d'esdeveniments, que es van recopilar de tots els clients (gestors de producte, programadors, analistes) i es van introduir amb cura (!) en una taula i després en la lògica del servei. Preparar esdeveniments és un gran treball interdisciplinari que requereix que tothom entengui què cal recollir, atenció i precisió.
Què serà el següent?
Diguem que tenim tots els esdeveniments interessants. És hora de recollir-los. Per fer-ho, heu de connectar l'anàlisi del client. Aneu a Google i busqueu analítiques mòbils (o trieu entre les conegudes: , , , , , ). Agafem l'SDK del lloc web i l'incorporem al codi del nostre servei (d'aquí el nom "client", perquè l'SDK està integrat al client).
I on recollir els esdeveniments?
Tots els paquets JSON que es crearan s'han d'emmagatzemar en algun lloc. On seran enviats i on es reuniran? En el cas d'un sistema analític de client, és el mateix responsable d'això. No sabem on són els nostres paquets JSON, on és el seu emmagatzematge, quants n'hi ha o com s'hi emmagatzemen. Tot el procés de recollida el realitza el sistema i no ens importa. Al servei d'anàlisi, tenim accés a un compte personal, on veiem els resultats del processament de dades de comportament inicials. A continuació, els analistes treballen amb el que veuen al seu compte personal.
En les versions gratuïtes, les dades en brut no es poden descarregar normalment. La versió cara té aquestes característiques.
Quant de temps trigarà a connectar-se?
Les analítiques més senzilles es poden connectar en una hora: serà App Metrika, que mostrarà les coses més senzilles sense analitzar esdeveniments personalitzats. El temps necessari per configurar un sistema més complex depèn dels esdeveniments seleccionats. Es presenten dificultats que requereixen un desenvolupament addicional:
- Hi ha cua d'actes? Per exemple, com arreglar que un esdeveniment no pot passar abans que un altre?
- Què fer si l'usuari ha canviat l'hora? Has canviat la zona horària?
- Què fer si no hi ha Internet?
De mitjana, podeu configurar Mixpanel en un parell de dies. Quan es preveu recollir un gran nombre d'esdeveniments específics, pot trigar una setmana.
Com triar quin necessito?
Les estadístiques generals funcionen bé en tots els sistemes analítics. Molt adequat per als venedors i els venedors: podeu veure la retenció, quant de temps han passat els usuaris a l'aplicació, totes les mètriques bàsiques d'alt nivell. Per a la pàgina de destinació més senzilla, les mètriques Yandex seran suficients.
Quan es tracta de tasques no estàndard, l'elecció depèn del vostre servei, tasques analítiques i esdeveniments que cal processar per resoldre'ls.
- A Mixpanel, per exemple, podeu executar proves A/B. Com fer-ho? Creeu un experiment en el qual hi haurà diverses mostres i feu una selecció (assigneu tals usuaris a A, altres a B). Per a A el botó serà verd, per a B serà blau. Com que Mixpanel recull totes les dades, pot trobar l'identificador del dispositiu de cada usuari d'A i B. Al codi de servei, mitjançant l'SDK, es creen retocs: aquests són llocs on alguna cosa pot canviar per a la prova. A continuació, per a cada usuari, el valor (en el nostre cas, el color del botó) s'extreu de Mixpanel. Si no hi ha connexió a Internet, se seleccionarà l'opció per defecte.
- Sovint, no només voleu emmagatzemar i estudiar esdeveniments, sinó també agregar usuaris. Mixpanel ho fa automàticament, a la pestanya Usuaris. Allà podeu veure totes les dades permanents d'usuari (nom, correu electrònic, perfil de Facebook) i l'historial de registre d'usuari. Podeu veure les dades dels usuaris com a estadístiques: El drac va menjar 100 vegades, va comprar 3 flors. En alguns sistemes, es pot descarregar l'agregació per usuari.
- Quina és la frescor principal ? Connecta el visitant del servei amb el seu perfil de Facebook. Per tant, podeu conèixer el vostre públic i, el més important, convertir-lo en un públic publicitari. Per exemple, si vaig visitar un lloc una vegada i el seu propietari va activar la publicitat (públic que es pot omplir automàticament a l'anàlisi de Facebook) per als visitants, en el futur veurem publicitat d'aquest lloc a Facebook. Per al propietari del lloc, això funciona de manera senzilla i còmoda; només cal que recordeu posar un límit diari al vostre pressupost publicitari. L'inconvenient de l'anàlisi de Facebook és que no és especialment convenient: el lloc és bastant complex, no s'entén immediatament i no funciona molt ràpidament.
Gairebé no cal fer res i tot funciona! Potser hi ha alguns inconvenients?
Sí, i un d'ells és que sol ser car. Per a una startup podria ser d'uns 50 dòlars al mes. Però també hi ha opcions gratuïtes. L'aplicació Yandex Metrica és gratuïta i adequada per a les mètriques més bàsiques.
Tanmateix, si la solució és barata, l'anàlisi no es detallarà: podreu veure el tipus de dispositiu, sistema operatiu, però no esdeveniments específics, i no podreu crear embuts. Mixpanel pot costar 50 dòlars l'any (per exemple, una aplicació amb Om Nom pot menjar tant). En general, l'accés a les dades és força sovint limitat en tots ells. No inventeu els vostres propis models i els llanceu. El pagament s'acostuma a fer mensualment/periòdicament.
N'hi ha d'altres?
Però el pitjor és que fins i tot Mixpanel considera els volums de dades inherents a una aplicació mòbil activa com una aproximació (indicat obertament directament a la documentació). Si compareu els resultats amb l'anàlisi del servidor, els valors divergiran. (Llegiu sobre com crear les vostres pròpies anàlisis del costat del servidor al nostre proper article!)
El gran desavantatge de gairebé tots els sistemes analítics és que limiten l'accés als registres en brut. Per tant, executar el vostre propi model amb les vostres dades aparentment no funcionarà. Per exemple, si mireu els embuts a Mixpanel, només podeu calcular el temps mitjà entre passos. No es poden calcular mètriques més complexes, per exemple, el temps mitjà o els percentils.
A més, sovint manca la capacitat de realitzar agregacions i segmentacions complexes. Per exemple, la compra en grup complicada "per unir usuaris que van néixer l'any 1990 i van comprar almenys 50 bunyols cadascun" pot no estar disponible.
Facebook Analytics té una interfície molt complexa i és lenta.
Què passa si encenc tots els sistemes alhora?
Bona idea! Sovint passa que diferents sistemes produeixen resultats diferents. Diferents números. A més, alguns tenen una funcionalitat, d'altres en tenen una altra i d'altres són gratuïts.
A més, es poden encendre diversos sistemes en paral·lel per fer proves: per exemple, per familiaritzar-se amb la interfície d'una de nova i passar-hi gradualment. Com en qualsevol negoci, aquí cal saber quan aturar i connectar les analítiques fins a tal punt que en pugueu fer un seguiment (i això no alentirà la vostra connexió a la xarxa).
Ho vam connectar tot i després vam llançar noves funcions, com afegir esdeveniments?
El mateix que quan connecteu analítiques des de zero: recull descripcions dels esdeveniments necessaris i utilitzeu l'SDK per inserir-los al codi del client.
Espero que les respostes a les preguntes més freqüents us siguin útils. Si us han ajudat a entendre que les analítiques del costat del client no són adequades per a la vostra aplicació, us recomanem que proveu les analítiques del costat del servidor. En parlaré a la següent part, i després parlaré de com implementar-ho en el vostre projecte.
Només els usuaris registrats poden participar en l'enquesta. si us plau.
Quins sistemes d'anàlisi de clients feu servir?
-
Mixpanel
-
Facebook Analytics
-
Google Analytics
-
Yandex Metrica
-
Altres
-
Amb el teu sistema
-
Res
Han votat 33 usuaris. 15 usuaris es van abstenir.
Font: www.habr.com