startup címkével jelölt bejegyzések

Online kutatásmódszertan – a keretrendszer, amit az Adatlabornál használunk

Az elmúlt 2 évben sok online projekt elemzését készítettük el – főleg webshop és startup vonalon. Így óhatatlanul is kialakult egyfajta keretrendszer, amit mostmár folyamatosan használunk. Ezt az anyagot általában az Adatvezérelt Marketing Képzésünk bevezetéseként szoktam bemutatni, de most szerettem volna nagyobb közönséggel is megosztani.

A keretrendszer – azaz az elemzési folyamat, amit használunk, nagyon egyszerű és 4 lépcsőből áll.

online kutatásmódszertan
Az Adatvezérelt Marketing Képzés vetített anyagából

Online kutatásmódszertan – a keretrendszer, amit az Adatlabornál használunk bővebben…

A “leggonoszabb” és egyben leghatékonyabb tesztelési módszer

This article is available in English here:
http://data36.com/the-most-evil-but-also-most-efficient-testing-method/

Hallottál már az ún. gettó-tesztelésről? A másik neve egy kicsit barátságosabb: fake-door-testing (mostantól a cikkben is inkább ezt használom).

A fake-door-testing egy nagyon egyszerű módszer, amely során úgy mérjük fel az igényt egy új termékre (vagy egy termék új funkciójára), hogy közben csak nagyon minimálisan van szükségünk tényleges fejlesztésre.
A folyamat négy lépésből áll: A “leggonoszabb” és egyben leghatékonyabb tesztelési módszer bővebben…

Visszatérő felhasználók mérése

Ha online bizniszben mozogsz, akkor az alábbi 2 cél biztosan szerepel a listádon:
1. Minél több új felhasználót behozni.
2. Minél több már meglévő felhasználót többszörösen visszatérő felhasználóvá konvertálni.

A visszatérő felhasználók mérése az egyik olyan terület, ahol már a definíciók szintjén is kérdésekbe fogsz ütközni, illetve ahol esetleges rossz definíciók okán a legkönnyebben becsaphatod magad. Ez a cikk ezt a problémát próbálja megelőzni! :-)

Visszatérő felhasználók mérése bővebben…

A nagy Big Data félreértés

“A Big Data olyan mint a tiniknél a szex:

  1. mindenki erről beszél
  2. senki sem tudja igazán, hogy hogyan kell csinálni
  3. mindenki azt hiszi, hogy  a többiek csinálják
  4. ezért mindenki azt mondja, hogy ő is csinálja.”

(Dan Ariely)

Biztosan hallottad már a fenti mondást. Félig vicces, de félig igaz is. Manapság már a csapból is a Big Data folyik és ennek a legfőbb oka nem a technológia terjedése, hanem az, hogy az újságírók és a marketingesek rájöttek, hogy ennek a két szónak az említésével szinte bármit el lehet adni. A másik oldalról viszont a valódi adat-szakemberek ritkán írnak közérthető cikkeket a témában, hiszen őket a technológia érdekli.
Ezt az űrt szeretném betölteni ezzel a rövid kis cikkel. Mi az a Big Data? Érthetően, de marketing bullshit nélkül.

Small Data

Kezdjük onnan, hogy mi az a small data? Az adatelemzés alapjainak alapjait a népszámlálás teremtette meg, ahol már évszázadokkal ezelőtt is kérdezőbiztosok mindenféle érdekes dolgokat kérdezgettek az emberektől. Ennek a következő evolúciós lépcsője a kérdőívezés lett, ami mind a mai napig egy gyakran használt piackutatási módszer. Mi a baj a kérdőívezéssel? Egyrészt a mintavétel: még a legprecízebb, legkörültekintőbb mintavétel is tévedhet. Hogyan reprezentálhatná hűen 2.000 ember válasza egy millió ember gondolatait? Persze vannak korrekt statisztikai módszerek, de a hibázás lehetősége mindig fennáll. A másik probléma a válaszok minősége. Az emberek hazudnak és gyakran nem is tudják, hogy hazudnak. Ha Téged megkérdeznek, hogy mi a kedvenc színed, lehet, hogy ma azt mondod, hogy a piros… aztán 1 hét múlva rájössz, hogy amúgy az összes pólód sárga és elbizonytalanodsz. De addigra már leadtad a válaszodat, a nagy üzletemberek pedig már döntéseket hoztak az alapján.

Ezek tipikus small data-s problémák.

Majdnem Big Data

Ezekre a problémákra ad választ a big data-s gondolkodás mód. Ha big data alapon gondolkozunk, akkor nem megkérdezzük az embereket, hanem a megfigyeljük viselkedésüket. Így nem tudnak nekünk (és maguknak) hazudni. Emellett pedig nem csak 2.000 embert figyelünk meg, hanem az összeset.

Értelemszerűen ez a legkönnyebben a számítástechnikai és az ahhoz kapcsolódó területeken történhet meg, ahol minden kattintásból és egérmozgásból új adatsor születhet.

Ezen a logikán keresztül születtek meg az olyan ismert és használt projektek, mint a Google Analytics, a CrazyEgg vagy a Mixpanel.

Bár ezekben a projektekben minden felhasználó/látogató viselkedését letárolták, de még mindig nem számítanak Big Data-nak, mivel relatív még mindig elég kicsi adatmennyiségről és korlátok között mozgó, nem túl rugalmasan kezelhető adathalmazokról beszélünk (pl. csak az előre meghatározott riportokat lehet legyártani, nem lehet kettőt kombinálni)… De akkor mi a tényleg nagy?

Big Data

Az elmúlt évek (évtizedek) egyik fontos trendje volt, hogy az adattárolás ára folyamatosan és nagy erővel csökkent. Mára elértük azt az állapotot, hogy olyan olcsó adatot tárolni, hogy inkább elmentünk mindent és nem törlünk ki semmit. És ez a kulcsa a Big Data-nak! Letárolunk minden adatot, amit csak tudunk és nem törlünk ki belőle semmit, még évekre visszamenően sem. Ezt jellemzően már nem Analytics-szerű programokba pakoljuk, hanem saját adattáblákba (pl. SQL) vagy log-okba.

Így előbb vagy utóbb akkora adatbázisok jönnek létre, amivel egy számítógép már nagyon nehezen birkózik meg. Egy terabájtos nagyságú adathalmazt Excel-ben vagy SPSS-ben nyilván meg se próbálunk megnyitni. De egy rendes SQL lekérdezés is akár órákon, sőt napokon keresztül futhat rajta. Egész egyszerűen akármivel próbálkozik az ember (R, Python, etc.), azt látja, hogy elérte a számítási kapacitás tetejét és nem tudja értelmes időn belül feldolgozni az adatait.

És ekkor jönnek képbe a Big Data technológiák – aminek az alapja, hogy az adatainkon innentől fogva nem egy számítógép dolgozik, hanem akár több tíz vagy száz vagy még több. Legtöbbször ezek a cluster-ek könnyen és szinte végtelenül skálázódnak: minél több az adatunk, annál több erőforrást tudunk bevonni a feldolgozásába. Így újra normális idő alatt tudjuk elemezni az adatainkat. Viszont sok-sok számítógépet egybekötni és egyszerre dolgoztatni egy elemző script-en: új infrastruktúrát és új technológiát igényelt. Így született meg a Big Data technológiák széles tárháza és így kerültek be a köztudatba az olyan fogalmak, mint a Hadoop, a YARN, a Spark, a Pig és a többi divatos Big Data technológia.

Big Data evolúció cégen belül

Nézzük egy startup esetében, hogy működik a Big Data evolúció.

1. Először a korai szakaszban nincs adatelemző a cégnél, de nem akarnak vakon repülni. Ezért fel-setup-olnak egy Google Analytics-et, egy Mixpanel-t, meg egy CrazyEgg-et és nézegetik az adataikat.

2. Megvan az első 10.000 felhasználó. A cégvezetés rájön, hogy a Mixpanel és a CrazyEgg kezd drága lenni, meg amúgy sem mutatnak elég részletes riportokat. Így elkezdenek saját SQL táblákat építeni és szabad szöveges log-okat gyártani. Ezt pedig valaki elemezgeti, különbözős SQL, Python vagy R script-ekkel.

3. Továbbra is növekszik a felhasználószám és az elemző(csapat) ekkor már arra panaszkodik, hogy 10-20 perc alatt sem futnak le az elemző script-jeik. Aztán, amikor elérik a több órás futás időket, rájönnek, hogy szükség lesz egy Big Data technológiára és elkezdik guglizni, hogy mi is az a Hadoop… :-)
Remélem ez a rövid összefoglaló segít eloszlatni egy kicsit a ködöt a Big Data mítosz körül. Ha pedig több tudásra van szükséged a témában, a szeptember 17-i Big Data tréningünkre még van 2 hely.

Hamarosan folytatom a témát egy új cikkel! Ha értesülni akarsz róla, iratkozz fel!

Tomi

Egy Játék mérése: gamification vs. retention

Múlt héten tettem ki az egyszamjatek.eu című kísérletünket a Facebook oldalunkra.

A játék nagyon egyszerű volt: mondj egy pozitív egész számot és ha ez a legkisebb olyan szám, amit más ember nem mondott Rajtad kívül, akkor nyertél. (Egyébként magát a játékot Mérő László találta ki.)
Összesen 7 forduló volt. Minden fordulóban 24 órán keresztül lehetett játszani. Így összesen 7 nyertest hirdethettünk.

A cél kettős volt:
1. Vizsgáljuk, hogy mi a nyertes stratégia. (Ezt ígéretemhez híven csak azoknak publikáljuk, akik játszottak. Sorry…)
2. Modellezzünk egy gamification alapú startup-ot és vizsgáljuk, hogy a játékélmény milyen hatással van a visszatérésre, illetve, hogy ezt hogyan lehet mérni.

Ezt a cikket azért írom, hogy ha esetleg online játék fejlesztésében vagy, láss néhány ötletet (konkrét példán keresztül is), hogy miket, miért érdemes mérni és elemezni.

Összehasonlítani nem akarom akármilyen más app vagy SaaS szoftver eredményeivel ezt a játékot, hiszen ez csak egy kísérlet, meg amúgy is tök más, mint akármi más, ami értelmes. :-) De azért nem árt ha tudod, hogy egyetlen mérőszám volt, amit boost-olni akartam az egész folyamat során: ez pedig a daily retention – azaz minél többször, minél sűrűbben visszahozni a játékosokat.

Ehhez egyetlen “marketing stratégiát” használtam – mindenki, aki adott napon játszott, kapott egy direkt email-t az eredményekről és egy linket a következő napi játékhoz. Ez a tool működött is – a leveleknek átlagosan 80%-os megnyitási aránya volt, amit kifejezetten erősnek mondanék.

mailchimp megnyitas és CTR - játék
mailchimp megnyitas és CTR

Nézzük mi a helyzet az aktív játékosok számával! Az első nap csináltam a játéknak egy nyitópromo-t (néhány csoportba és FB-oldara kitettem a játékot.) Így 296 emberrel indult a verseny az első nap. Ehhez csatlakozott az utolsó napig innen-onnan még 38 ember (valószínűleg meghívásos alapon, hiszen ezután már nem hirdettem). Tehát összesen 334-en játszottak.

A lenti ábra azt mutatja, hogy mekkora volt a napi visszatérés, azaz az előző nap játékosai közül hány % játszott az adott napon.

daily retention - egyszamjatek.eu - játék
daily retention – egyszamjatek.eu

Ha megfigyeled, két mélypont van. A 2. nap, amikor 30% körüli a retention és az 5. nap, ahol 50% körül van. A többi napon 60% felett megyünk, sőt az utolsó napokon felszökik 100% felé, ami azt jelenti, hogy olyanok is visszajöttek, akik régebben játszottak!
Ki találod mi történt a 2. és 5. napon? Elárulom, ezeken a napokon véletlen délután 4-kor küldtem ki a hírlevelet, amit reggel 9-kor kellett volna. Tanulság ebből a chart-ból: reggel kell kiküldeni a leveleket…

Nézzünk egy klasszikus kohorsz elemzést! Minden sorban az adott nap regisztrált user-eket látod és minden oszlopban azt, hogy hány maradt meg belőlük X nappal később.

kohorsz elemzés játék
kohorsz elemzés

Mi látszik itt? Az, ami már a retention riportból is elkezdett kiderülni. Az első napon regisztráltak, ha ki is hagytak egy-két napot, vissza-visszajönnek 2-3 nap után. Lehet, hogy az ideális játékciklus nem 1 nap lenne, hanem 2?

Kedvenc riportom: aktív user-ek vs. retaining user-ek.

aktiv user-ek vs. retaining user-ek
aktiv user-ek vs. retaining user-ek

Ahogy azt írtam, az első nap után már semmit sem tettem bele a marketing-be. Ez az ábra mutatja a legjobban: ha lecsökken a user bázis, akkor ott szűrve szépen csak a “legjobb” felhasználók maradnak bent. Nekik magas lesz a visszatérésük és valószínűleg ez a néhány (35-40) user volt az is, akik behozták az utolsó pár napon a +10 új user-t – mindenféle költségek nélkül.

2 érdekesség a Gamification hatásáról:
1. Volt egy feltűnő trend a nyertes játékosok körében. Ez a 7 játékos, miután nyertek, már sokkal kisebb eséllyel jött vissza játszani. Lehet, hogy őket valahogy máshogy kellett volna visszacsábítani egy második körre?

játszott - nyert - nem játszott
játszott – nyert – nem játszott

2. A Power User-eknek (azaz, azok a játékosoknak, akik mindennap játszottak), több mint 50%-a mindennap ugyanazt a számot játszotta meg. (Az egyik nyertes egyébként pont közülük került ki.)

———————————————————————————

Akárhogy is, számomra ez egy izgalmas kísérlet volt – sok olyan dolog kiderült belőle, amiket már máshol is mértünk, de a titoktartás miatt nem publikálhattam! :-)

Remélem hasznosnak találtad és ha szeretnél feliratkozni az Adatlabor hírlevélre, ne habozz!

Tomi

Mobil App mérések – miért, mit és hogyan?

Tudtad, hogy a letöltött mobil app-ok 80%-át az első használat után törlik a felhasználók a telefonjukról? Hogy bent maradj a kellemes 20%-ban, elengedhetetlen, hogy reagálj a user-eid viselkedésére! Ehhez pedig mérned kell. Ugyanúgy, mint desktop-os internetes alkalmazásoknál… habár az elmélet és a gyakorlat is egy kicsit más. Ebben a cikkben leírom azt a néhány best practice-t, amivel már könnyen el tudod kezdeni a mobil app-od mérését!

MIÉRT MÉRJEM A MOBIL APP-OM?

Az egyik legfontosabb kérdés, hogy miért is mérsz? Erről már többször is írtam, de nem győzöm mindig hangsúlyozni, hogy akármit is mérsz: legyen egy jól definiált üzleti célod!
Ezt a célt állapotban két dolog határozza meg (Rajtad kívül). Az egyik, hogy milyen bizniszben vagy, a másik pedig hogy milyen szakaszában a növekedésnek.

Ha pl. egy érett e-commerce bizniszen dolgozol, akkor az egyik legfontosabb célod a Revenue, azaz a bevételed lesz.
Ha egy korai fázisú startup-on, akkor inkább az engagement-re és az activation-re fókuszálj, azaz arra, hogy a felhasználók egyáltalán megértsék a termékedet és elkezdjék használni – no meg persze, hogy elégedettek legyenek vele.
Egy feltörekvő média oldalnak pedig általában a retention-re fekteti a hangsúlyt, tehát a visszatérő látogatók számára és a visszatérések sűrűségére.

Ha megvan a célod, akkor már könnyen választ adhatsz a miért-re. Azért mérsz, hogy ezt a célt minél könnyebben elérd és ha nem sikerül, akkor megértsd, hogy miért nem sikerült. És persze, hogy tudd, hogy hol, mikor, mit és hogyan kell változtatnod.

MIT MÉRJEK A MOBIL APP-OMBAN?

Egy mobil app persze elég speciális biznisz. Van egy-két dolog, amit a legtöbben mérnek és ami gyakorlatilag kikerülhetetlen, ha ezen a területen dolgozol. A 3 leggyakoribb:

1. Onboarding funnel

Mobil App Onboarding Funnel
Mobil App Onboarding Funnel

Ahogy a képen is látszik, az onboarding során lépésről lépésre kiesnek az emberek. pl. 1300-an letöltik az app-ot, 800-an elindítják, 400-an beregisztrálnak, 100-an pedig elkezdik használni tényleg a terméket, stb, stb… A lényeg, hogy lásd, hogy hol esnek ki a legtöbben és, ha ez a szám nagyon nem illik az elképzeléseidbe, akkor tudd, hogy ott valamit változtatnod kell.

A mobil app-oknál a legtöbb onboarding funnel így néz ki.
1. lépés: Letöltések száma (pl. 1000 db)
2. lépés: Launch (pl. 800 db)
3. lépés: Regisztráció (pl. 600 db)
4. lépés: Elkezdik használni a terméket (pl. 400 db)
5. lépés: Végére érnek az első körnek, a tanulási (más néven onboarding) folyamatnak (pl. 200 db)

Az 5. lépés egyébként trükkös, ezért szét szoktuk bontani 3-4 allépésre. Akkor vesszük úgy, hogy egy felhasználó elérte az 5. lépést és “onboarded” lett, ha már tudjuk, hogy minden olyan funkciót használt, ami kell ahhoz, hogy értse a termék előnyeit.
pl. ha egy idegenvezető mobil app-od van, ami a füledre mondja egy városban, hogy merre menj és mit kell tudni a nevezetességekről, akkor valami ilyesmi lehet az onboarding funnel-ed vége:

4. lépés: Kiválaszt a user egy túrát.
5. lépés: Odamegy a túra kezdőpontjára.
6. lépés: Elindítja az audio guide-ot.
7. lépés: Eljut a túra felére.
8. lépés: Végigér a túrán.

Aki végigért a túrán, nagy eséllyel találkozott az app összes főfunkciójával és érti, hogy mi a jó benne. Utána, hogy újra használja-e már, az egy másik kérdés.

2. Retention – visszatérés

Az egyik legütősebb metrika a felhasználó elégedettség vizsgálatára: a visszatérések száma és aránya. Tehát azok közül, akik múlt héten használták az app-odat, hányan használják újra. Itt nem feltétlenül megnyitásról beszélünk, hanem pl. egy core-feature használatáról (mint pl. a spotify-nál a zenelejátszás).

Itt is érdemes Neked definiálnod, hogy mi az ideális visszatérési sűrűség. Pl. ha egy média app-od van (, ahol naponta jelennek meg új cikkek,) vagy egy self-tracker alkalmazásod (, ahova minden reggel beírod, hogy milyen kedved van), akkor érdemes napi retention-t mérned. Egy Uber típusú app-nál a heti retention már logikusabbnak tűnik, egy repülőjárat kereső alkalmazásnál pedig akár a (több-)havi retention is indokoltnak tűnhet, hiszen a legtöbb ember amúgy sem utazgat minden héten vagy hónapban repülővel. (Azért törekedj minél kisebb retention time-ot belőni, mivel ha változtatsz valamit az app-odban és szeretnéd a retention-re gyakorolt hatását látni, mindig annyit kell majd várnod az első adatpontodra, amekkorára a retention definíciód be van állítva.)

Ha ez megvan, akkor nincs más dolgod, minthogy meghatározd a napi, heti vagy havi visszatérő látogatóid számát és arányát. És, hogy próbáld ezt a számot minél magasabbra tolni!

A retention címszó alatt még több dolgot is mérhetsz. Pl. a churn, azaz a lemorzsolódások aránya (pl. hányan uninstall-álták az alkalmazást, vagy hányan nem tértek vissza legalább a retention time-od 10-szereséig.) Vagy idetartozik az active/passive user-ek aránya. Azaz, hogy az összes user-edből hány % aktív.

3. Revenue – bevétel

A bevételt is többféleképpen mérheted. Itt persze attól is függ a dolog, hogy pontosan, hogy monetizálsz (fizetős app? reklámokból? in-app eladásokból? stb…), de a leg fontosabb alapmérések:

  • Első fizetésig eltelt idő
  • Fizetős user-ek aránya (hány ingyenes felhasználóra jut egy fizetős)
  • Havi átlagos bevétel user-enként
  • CLV – Customer Lifetime Value: Ez már egy összetettebb számítás, ami megmutatja, hogy az adott lemorzsolódási arányok és havi átlagos bevételek mellett egy user kb. mennyi pénzt termel az applikáción keresztül Neked onnantól, hogy beregisztrált, egészen addig, hogy letörli az app-ot.
    customer lifetime value mobil app mérés

Ez most csak 3 dolog – onboarding, retention és revenue -, de az alapok lefektetéséhez elég, aztán lehet továbbrészletezni még…

HOGYAN MÉRJEM A MOBIL APP-OM?

A millió dolláros kérdés: milyen eszközzel mérjem a mobil app-omat?
A jó hír hogy rengeteg lehetőség van…
Amit mindenképpen ajánlok az a Google Mobile Analytics. Ingyenes, mindent tud, ami kellhet. A korlátai pedig ugyanazok, mint a Google Analytics-nek. Csak report-olásra jó.
Ha szeretnél eggyel továbblépni, akkor itt is a Mixpanel az egyik legerősebb játékos a piacon. A Mixpanel-lel már viselkedés alapján tudsz szegmentálni, automatizált e-mail marketing-et beállítani, stb…
Ezeken kívül még rengeteg tool létezik, pl. az ingyenes Flurry Analytics vagy a kifejezetten crash-ek mérésére szolgáló Crashlytics – de azt is kevesen tudják, hogy az Optimizely-t is lehet használni mobil app AB-tesztelésre…

Egy szó mint száz

A lehetőségek és az eszközök adottak! Kezdd el mérni az app-odat és meglátod, sokkal tudatosabban, gyorsabban és eredményesebben tudsz majd fejlődni!
Sok sikert!

Ha szeretnél még ilyen cikkeket olvasni, iratkozz fel a hírlevelünkre!

Mester Tomi

Hogyan mérd az MVP-det?

Mostanában több viszonylag korai fázisú – MVP startoltatás előtti pillanatokban levő – startuppal is dolgoztunk 1-2-3 konzultáció erejéig – és mindig ugyanaz volt a kérdés: ha megvan az MVP, akkor hogyan – és főleg mit mérjünk?

Itt 3 főelv van:
1. Az OMTM-elv
One Metric That Matters – azaz egy darab célt jelölj ki! Egyet és ne többet! És ezt az egy célt helyezd a méréseid fókuszába. Hogy ez mi legyen azt iszonyatosan fontos már a startolás előtt, a legelején eldönteni.
Sok olyan cég van, aki megérzésből nyomja a dolgokat és adatok nélkül dönt. Aztán vagy bejön nekik vagy nem. De a másik véglet sem jobb – ha az ember 40 dolgot figyel egyszerre, akkor előbb-utóbb azon kapja magát, hogy egész nap csak a chart-okat nézegeti, de értelmes és értékes döntést még nem sikerült hoznia. Ha túl sok mindent mérsz, az összezavarhat. Legyen meg a fókusz: Mérj egy dolgot és határozza meg az, hogy merre mész tovább!

2. Engagement központúság
És hogy mi legyen az a bizonyos “Egy Mérés, Ami Számít”?
Természetesen ez a termékedtől függ, de MVP fázisban az biztos, hogy ez a metrika valahol az engagement, azaz a felhasználói elégedettség környékén keresendő.
NEM jó OMTM a regisztrált felhasználók száma. A regisztrált felhasználók száma semmilyen érdembeli visszajelzést nem ad a termékedről, maximum a value proposition-ödről (de azt jó esetben validáltad már eddigre landing page tesztekkel és kvalitatív vizsgálatokkal) vagy a marketing erődről. Egy csomó embert hallok büszkélkedni, hogy elérte a 1.000 (2.000, 5.000, stb…) regisztrált felhasználót. De ha ebből 10-15 aktív felhasználója van, akkor bizony az a 2.000 nem sokat ér.
NEM jó OMTM a bevétel nagysága/fizetések száma sem. Ehhez még túl korai szakaszban van a termék – úgyse fog elég pénz bejönni, akkor meg kár ezen stresszelni magadat.

A jó OMTM a termék használatára vonatkozik. Használják-e az emberek a főfunkcióidat? Minden funkciót használnak vagy csak néhányat? Úgy használják, ahogyan tervezted? És a legfontosabb: az első látogatás/regisztráció után visszajönnek mégegyszer használni a termékedet?

Jó mérőszámok lehetnek:
– az aktivált felhasználók száma  (pl. a Spotify-nál aktivált felhasználó az, aki beregisztrál és meg is hallgat legalább egy számot – a Prezinél aktivált felhasználó, aki beregisztrál, elkészíti és bemutatja az első prezijét, stb…)
– az aktivált felhasználók aránya (ugyanaz, mint a fenti, csak %-ban, hogy lásd, hogy a regisztráltak mekkora része aktiválódik)
– a visszatérő felhasználók aránya. Hányan döntenek úgy, hogy újra használják a termékedet?
– a visszatérés ideje. Mennyi idő után jönnek vissza az emberek? 1 nap, 1 hét, 1 hónap?

És emellett persze folyamatosan monitorozd azt, hogy melyik feature-öket használják az emberek és melyikeket nem.

3. Csináld meg egyszerűen!
Ebben a szakaszban az a lényeg, hogy gyorsan tudj mérni – ne tölts vele túl sok időt. Mivel lehet ezt megoldani? Ha csak nincs a kisujjadban a log-gyártás, akkor smart tool-okkal. Tök őszintén: valószínűleg egy jól beállított (konverziók, demográfia, stb.) Google Analytics is elég lesz. Ha pro akarsz lenni, akkor vagy egy Kissmetrics-et vagy egy Mixpanel-t felteszel az Analytics helyett, de ennél többre valószínűleg tényleg nem lesz szükséged ebben a szakaszban.

Mégegyszer összefoglalva:
1. Egy dolgot mérj!
2. Ez az egy dolog a termék használatára és a felhasználói elégedettségre fókuszáljon!
3. A lehető legegyszerűbben valósítsd meg (Analytics, Kissmetrics vagy Mixpanel)

Ha pedig egy szinttel feljebb lépnél, gyere el az Adatvezérelt Marketing Képzésünkre, ahol beszélünk linkkövetésről, AB-tesztelésről, UX kutatásról, a lepattanó user-ek visszanyeréséről és megannyi finomságról, ami ebbe a cikkbe már nem fért bele (még 6 szabad hely van)! :-)
http://adatlabor.hu/adatvezerelt-marketing-trening/

Mester Tomi

(Inspiráció: leananalyticsbook.com)

Interjú – Termékfejlesztés a Skyscanner-nél

Skyscanner logoTavaly októberben robbant a hír, miszerint a Skyscanner felvásárolta a Distinction-t. Azóta az átállás végbement és az egykori Distinction most már 100%-ban a Skyscanner mobilapplikációinak a fejlesztéséért felel. Ennek a zászlóshajója a Flights alkalmazás.  Az egyik cél, hogy a “Travel is mobile” koncepcióhoz híven az egész utazási élményt lefedjék és egy egységes megoldást kínáljanak rá. Kardos Lacival, a Skyscanner Apps Tribe-jának egyik product managerével beszélgettem a célokról, a kihívásokról, stratégiákról és arról, hogy milyen módszerekkel és hogyan fejlesztenek.

Kardos Laci - Skyscanner
Kardos Laci —— Product Manager @Skyscanner

Tomi: Hogy néz ki a cég felépítése jelenleg?
Kardos Laci: Per pillanat a Skyscanner szervezeti modellje a Spotify-jéhoz hasonló. Vannak tribe-ok, azon belül squadok, a squadokat átívelően vannak chapter-ek és guild-ek. Mi, a budapesti csapat, és számos kolléga a cégből, akik korábban szintén mobilapplikációkkal foglalkoztak alkotjuk az Apps Tribe-ot. Az Apps Tribe termékvezetője Orosz Bálint, Kapui Ákos pedig a technológiai vezetője. Magának az Apps Tribe-naka zászlóshajója a Flights, ez az elsődleges termék. A cég hosszútávú stratégiájának egyik eleme, hogy a teljes Travel világot felölelje, tehát ne szeparáltan foglalkozzon a “Hotels”, a “Flights” vagy a “Car Hire” alkalmazásokkal, hanem hogy egy globális utazási megoldást kínálhassunk. Gondolj bele, mennyi macerával jár az utazás: nem csak a foglalás, hanem a repülőtéri dolgok, majd maga a repülés, utána az ottlét… mi ezt az egészet ilyen egyszerűvé szeretnénk tenni (csettint).

Most hogy látod, hol lesztek 1 év múlva? 3 év múlva? 5 év múlva?
A cél az, hogy pár éven belül egy szignifikánsan, mérőszámokkal is alátámaszthatóan erős travel brand legyünk. A cég gyorsan növekszik, mi pedig iszonyúan élvezzük ezt. A Distinction-korszakból hoztuk magunkkal az erős delivery hangulatot. Szeretünk “szállítani”, tolni és vinni előre, és így jó dolgok tudnak születni. Mindemellett nagyon fontos, hogy a jó terméket szállítsuk a megfelelő módon. Itt jön a képbe az, hogy product discovery-ben is erősek vagyunk.

Hogyan méritek a sikerességét egy terméknek?
Ez egy olyan kérdés, amire válaszként egyértelmű, bevált módszert még nem tudok adni, tekintettel arra, hogy még nem adtunk ki alkalmazást a felvásárlás óra. Egyébként eddig a legfontosabb metrikáink közé a “conversion” jellegűek tartoztak.. A Flights-nál például az, hogy az emberek hány százaléka megy át tőlünk végül a külső szolgáltatók oldalára (pl. a légitársaságok foglalási oldalára) és az, hogy akik átmennek, ténylegesen vesznek-e jegyet. Alapvetően a legtöbb fejlesztett kiadás vagy akár az A/B-tesztek ezeket az arányokat próbálják javítani. Életképesség szempontjából persze esszenciális, hogy magas legyen a konverziód, de ami egyre fontosabb, az az, hogy hogyan tudjuk a “frequency of use”-t, azaz a folyamatos visszatérést növelni. Ugyanis az utazás az nem csak arról szól, hogy az ember egyszerre lefoglal mindent, és onnantól kezdve nem is foglalkozik vele, nem is gondol arra, hogy hova fog utazni. Inkább úgy működik, hogy először csak eljátszik a gondolattal, megnézi a blogokat. Azután lefoglalja a repjegyet, majd a szállodát. Utána megnéz valamilyen térképes szolgáltatást. Megtervezi a helyi közlekedést, hogy hogyan fog eljutni a reptértől a hotelig. Aztán azon gondolkozik, miket érdemes megnézni az adott városban. Ezek a mélységek nálunk még nincsenek benne a termékben. Éppen emiatt a jövőben ezekre jobban figyelünk majd. Így rákényszerítjük magunkat arra, hogy olyan termékekkel jöjjünk elő, amelyeket az emberek gyakran fognak használni.

A cél tehát, hogy az utazás előtt minél többször elővegyék az app-ot?
Így van. Vagy az utazás alatt. Ha belegondolsz, maga a bepakolás a bőröndbe is egy “pain-in-the-neck”. Utána elrepülsz és előveszed a mobilod, hogy keress rajta helyeket, látnivalókat. Az utazás élményéhez alapvetően hozzákapcsolódik a mobil. Ez az, ami nagyon fontos. És ez az, ami egy hatalmas lehetőség a Skyscanner-nek. Az egyik erősségünk, hogy nagyon jó technológiai háttérrel rendelkezünk és teljesen transzparens módon jelenítjük meg az utazási ajánlatokat. Mi minden árat mutatunk, legyen az egy ügynökségé vagy magáé a szolgáltatóé. A jegyfoglalás egyre inkább a mobil platformok irányába tolódik el. És az utazás is esszenciálisan mobil. Mobillal utazol, mobillal fényképezgetsz, majd mindezt mobilon osztod meg és azt mások is mobilon nézik meg.

És ez a stratégiai váltás igényelte azt, hogy bejöjjön a Distinction a képbe?
Igen. A stratégiában mi ezt úgy fogalmazzuk meg, hogy a mobile-first vagy “Travel is mobile.” A másik jelmondatunk pedig, hogy “Travel is social”. Utazol valakivel, utazol valakihez vagy elutazol valakitől, vagy inspirálódsz valakinek az ötlete alapján.

Az hogy eddig nem volt release, azt jeleneti, hogy teszteket nem is nagyon csináltatok?
Nyilván a jelenlegi app-okban számos analitikai könyvtár található, amiken mérjük ezeket a dolgokat. De mi, mint csapat, nem csináltunk még óriási teszteket, mert még nem tart ott a termék. Azok a termékek/feature-ök, amiket mi építünk, egyébként eleve A/B teszt formájában fognak kimenni, tehát először a felhasználók X százaléka fogja megkapni. Összehasonlítjuk a régit és az újat.
Ezenkívül ott van a Hotels app. Annak is hasonlóképpen megy a fejlesztése. Egyébként a Hotelst mi készítettük eredetileg, még a Distinction korszakban.

Hogy néz ki a csapat?
Alapvetően “cross-functional product squad”-ok és “technológiai squad”-ok vannak. Az előbbiben van egy product manager/owner, egy researcher, egy designer – az én csapatomban például pont kettő –, egy tech lead, fejlesztők és tesztelők. Ezek közepes méretű csapatok, tehát körülbelül 8 fősek, amik nagy valószínűséggel szét fognak bomlani kisebb egységekre, ahogy növekszünk. És ott vannak a technológiai squad-ok is. Azok főleg fejlesztőkből állnak Természetesen ott is van egy squad-lead.

Mit csinál a researcher a csapatban?
A researcher-nek a feladata nálunk gyakorlatilag az, hogy a világból insights-okat szedjen össze és azokat a megfelelő formában átadja a termékcsapatnak. Ebbe természetesen beletartozik a kvantitatív és a kvalitatív kutatás is. A researcher pozíciót tehát nagyon flexibilisen értelmezzük. Vannak benne UX research (usability tesztek, interjúk, stb.) és adatelemzési feladatok is.

Hogy néz ki egy ilyen folyamat nálatok?
A termékfejlesztési folyamat erősen támaszkodik a kutatásra. Ez azt jelenti, hogy egészen a kezdeti szakasztól, amikor még nincs semmiféle fejlesztés vagy design, már olyan dolgokkal kezdünk el foglalkozni, amik insight-okból származnak. Pl. korábbi interjúkból derül ki, hogy van igény valamire. Mi ezek alapján kezdünk el dolgozni megoldásokon, designokon, prototípusokon. Azután ezeket validáljuk. Tipikusan teszteltetjük őket különböző felhasználókkal az irodánkban. Sok esetben ezek kód nélküli prototípusok. Ezeket sok szempontból vizsgáljuk. A legfontosabb kérdés, hogy értékes lenne-e a termék vagy funkció a felhasználóknak? Számtalanszor kiderül, hogy nem és akkor ezeket a funkciókat eltávolítjuk a prototípusból vagy megpróbáljuk őket átdolgozni. Közben folyamatosan vizsgáljuk a dizájnok használhatóságát is. Végül amikor eljutunk egy olyan fázisba, amikor azt lehet mondani, hogy ez a termék/feature értékes, használható és megvalósítható, akkor megszületik a döntés, hogy mit is fejlesszünk le. Csak ezután zajlik le a fejlesztés és ezután jöhet a release. Minden terméknek van egy célja. A release során kvantitatív mérésekkel vizsgáljuk, hogy ezt a célt elérjük-e. Ezt a felhasználók tényleges termékhasználata alapján tesszük. A mérésekből levont következtetések alapján aztán iterálunk a terméken.

A kód nélküli teszteket egyébként hogyan kell elképzelni?
Egy egyszerű drótváz jellegű prototípust képzelj el. Csinálunk képernyőket és ezeket összelinkeljük egymással. Nagyon fontos, hogy a tesztek ritmusa adjon egy alapritmust az egész termékfejlesztésnek. Ha jön egy felhasználó, akkor mutatni akarunk neki valamit. Elérakunk egy prototípust, a researcher feladata pedig, hogy végigcsinálja a tesztet. A csapat elemi érdeke pedig, hogy megpróbáljon minél több teszten bent lenni egy héten. Hiszen nem csak a designer-nek, a product manager-nek vagy a researcher-nek, hanem a fejlesztőnek is fontos, hogy lássa, hogy amit megcsinált, az vajon működik, értékes, használható-e. Ezek nagyjából félórás tesztek. Van amikor szcenáriókra épülnek. Tehát pl. “képzeld el, hogy utazni szeretnél és elkezded használni az app-ot, amit letöltöttél” – iOS-en, Androidon, akár tableten vagy telefonon. A felhasználói teszt alatt látjuk, hogy hol hal el a folyamat – közben pedig beszélgetünk a tesztelővel, hogy megértsük a miérteket is. Utána a csapattal átbeszéljük, hogy mi az, amit tanultunk, amit hallottunk. Hiszen előtte voltak feltételezéseink és a teszt végén pedig ezek vagy igazolódnak vagy nem. Ilyenkor látjuk, hogy mi az, ami nem működik, mi az, ami nagyon jól működik és néha látunk olyan dolgokat, amikre esetleg nem is gondoltunk. A tapasztalatom az, hogy az értékesség és a használhatóság kérdéskört 3-4 tesztből meg lehet ítélni.

Van még valami, amin dolgoztok mostanában?
Azon dolgozunk, hogyan építsünk fel egy hosszú távon használható Analytics rendszert, ahol minden egyes felhasználói interakciót naplózunk egy big data store-ba, amit azután lehet elemezni,akár mélyebb statisztikai módszerekkel (korrelációkat megállapítani, stb…). Vagy a klasszikus termékdöntésekhez szükséges módszerekhez is használhatjuk majd ezt: egy funnel-t meg lehet vizsgálni, egy cohort-ot ki lehet elemezni, stb. Mindezt szeretnénk kiegészíteni egy A/B-teszt (feature-switching) megoldással, amivel gyorsan lehet variánsok teljesítményét mérni. Ráadásul szeretnénk, ha ez az első nagyobb release-re megépülne és tudnánk használni. Szerencsére a cégen belül ez nem csak a mi feladatunk, más squad-ok is dolgoznak rajta velünk együtt Edinburgh-ban, Barcelona-ban és más helyeken is, úgyhogy rájuk tudunk építeni.

Milyen érzés egyébként egy ekkora cég részévé válni egyik pillanatról a másikra?
Egy integrációnak számos aspektusa van: kulturális és szervezeti is. Ez a folyamat zajlik most. Iszonyatosan jó az anyacég, rengeteget tanulunk tőlük és ők is sokat szeretnének tanulni tőlünk. Például, hogy milyen is az a Distinction-kultúra, milyen és hogyan lehet átvenni elemeket, amelyek nagyon jól működnek nálunk. Nekünk meg az segít, hogy nagyságrenddel nagyobbak, infrastruktúrát és folyamatokat tekintve.

Köszönöm szépen!

Big Data webinár II. rész — STARTUP + ADAT — stratégiák nem csak startup-oknak

(Ha nem voltál az I. részen, ne ijedj meg, anélkül is érteni fogod) A II. rész több stratégiával, több módszertannal és több esettanulmánnyal.
Itt tudsz regisztrálni:     adatlabor3.eventbrite.co.uk

Adatlabor logoIdőpont: Március 18. szerda 18.00-19.30

A tartalma pedig:
Az adatelemzés az (online) üzleti stratégia szerves része. Ezzel értheted meg a felhasználóidat: mik a problémáik és hogyan tudsz nekik ebben segíteni. Ez pedig hosszú (és rövid) távon számodra is profitábilis. De hol is érdemes kezdeni? Ez a webinárium rendet rak a káoszban és olyan módszertanokat és példákat mutat be, amelyek a gyakorlatban hasznosíthatóak.
(Note: a webinárium akkor is hasznos, ha éppen nem startup-on dolgozol, de szeretnéd az online üzletedbe bevezetni az adatvezérelt szemléletet.)

Tárgyalt módszertanok:
– AARRR (Dave McClure): Tesztelési stratégiák és fejlődési pontok adatvezérelt meghatározása.
– 4DX (The 4 Disciplines of Execution): Mérhető célok beállítása, a köztük levő összefüggések megkeresése és a célirányos üzletfejlesztés.
– E-commerce startup mérések
– A/B tesztelés: best practice-ek (és worst practice-ek).
– Mi az a Big Data igazából? Mikor van rá szükség? Hogyan lehet implementálni?
– Esettanulmányok

A gyakorlatban az Adatlaborral mi magunk is ezeket az adatelemzési stratégiákat és módszertanokat használjuk, a saját ügyfeleinknél, úgyhogy 100%-osan valós üzleti példákból merítkezünk.
75 perc + Q&A

Mester Tomi adatlabor
fotó: Hámori Zsófia

Előadó:
Mester Tomi üzleti intelligencia elemző és tanácsadó, az adatlabor.hu alapítója és szakmai vezetője. Növekedésben levő cégeknek segít az adatelemzési és big data stratégiájuk kidolgozásában – továbbá abban, hogy ezeket az eszközöket a vevőszerzés, a magasabb vevőelégedettség és végeredményben persze a több profit elérésére tudja felhasználni minden partnere. Korábban a Prezi.com-nak dolgozott. Jelenlegi ügyfelei az e-kereskedelem, az online média és az online szolgáltatások területéről érkeznek.
Másik szenvedélye a nyilvános beszéd. Alapítótagja és CC-szintű beszélője az első magyar nyelvű Toastmasters klubnak. Előadó továbbá adatelemzés témában olyan fórumokon, mint a TEDx, BI Forum, Internet Hungary, PechaKucha Nights, Global E-commerce Summit 2015 @Barcelona, stb. Több info itt.

Ára: 4000 ft + ÁFA

Tehát a jelentkezés mégegyszer:
LINK: adatlabor3.eventbrite.co.uk
ÉS A GYORS REG:

Tomi

Az Evolution előadás margójára: Az A/B tesztelés 4 szabálya

Note: ezt a bejegyzést az Evolution konferenciás előadásomhoz kapcsolódóan írtam. De azért bárkinek hasznos lehet… :-)

A legfrissebb statisztikák szerint az online szolgáltatók 91%-a tudja, hogy mi az az A/B tesztelés, de csak 11% az, aki ténylegesen (legalább egyszer) futtatott A/B tesztet az oldalán. Pedig az A/B tesztelésnek forintban mérhető, azonnali haszna van. Egy külföldi esettanulmány:

A fab.com e-commerce startup egyetlen dolgot tesztelt az oldalán. A lenti két képen látszik is: az “Add to cart” gomb színét.

fab AB teszt piros

fab AB teszt piros
Az oldalra érkező látogatók fele-fele arányban véletlenszerűen kapták meg vagy a piros vagy a kék verziót. Ekkora látogatószámnál viszonylag kevés tesztből kiderült a válasz a kérdésre: melyik gombszín hoz több kattintást, ezáltal magasabb konverziót és több profitot. Az eredmény pedig megdöbbentő: 49%, ami éves szinten dollár-milliókat(!) jelent a fab.com-nak. A kísérlet beállítása és elindítása nettó 2 óra munkát jelentett nekik. Azt hiszem, ezek után nehéz lenne azt mondani, hogy az A/B tesztelés nem hasznos.

De hogyan is kell A/B tesztelni? Íme 4 szabály, amit én a legtöbbször látok elrontani olyan ügyfeleknél, akik maguknak kezdték el csinálni az A/B tesztjeiket. (Ezt nem amolyan “cikizés”, csak azért írom le, hogy más ne essen ezekbe a gyakori hibákba! :-))

1. Egy időben fusson a két verzió!
Tehát az nem A/B teszt, hogy februárban kiteszem az egyik verziót, márciusban pedig a másikat és mérem, hogy melyik hoz több kattintást… Miért nem? Azért, mert ebben az esetben közbeszólhat a szezonalitás. Azaz lehet, hogy márciusban nagyobb igény van az adott termékre (pl. tavaszi cipő), mint februárban volt és ez is befolyásolja a konverziót. Egy korrekt A/B tesztben a különböző verziók egymással párhuzamosan, egy időben futnak.

2. A teszt csoport és a kontroll csoport azonos összetételű legyen!
Pl. ha a fizetős felhasználóim perszonalizált hírlevelet kapnak, az ingyenes felhasználóim pedig nem, akkor a hírlevélből jövő átkattintási arányok nem csak azért lesznek eltérőek, mert más a levél tartalma, hanem azért is, mert más a felhasználói csoportok elkötelezettségi szintje. Ha a fizetős felhasználók teljesen ugyanazt a levelet kapnák, mint az ingyenesek, könnyen lehet, hogy mivel ők elkötelezettebbek a termék iránt, amúgy is többen kattintanának. Éppen ezért, ha tényleg a levél tartalmát akarod tesztelni, akkor vagy a fizetős felhasználókat kell véletlenszerűen két csoportba osztanod, vagy az ingyeneseket. A lényeg, hogy a kontroll csoport és a teszt csoport azonos típusú embereket tartalmazzon.

3. Legyen célja a tesztnek!
És ez nem csak arról szól, hogy ne dolgozzunk feleslegesen, hanem arról is, hogy ténylegesen: egy A/B tesztet csak akkor lehet kiértékelni, ha az ember már a tervezés fázisban eldönti, hogy mi lesz az az 1, maximum 2 mérőszám, aminek a változását figyeli és ami alapján azt mondja, hogy az egyik verzió sikeresebb, mint a másik (mint pl. a fab.com esetében a gombra kattintás).

4. Csak egy dolgot változtass!
Ezt nehéz betartani és általában nem is szokták. De vedd figyelembe, hogy minél több elemet változtatsz a két verzió között, annál nehezebb lesz eldönteni, hogy pontosan melyik volt a kulcselem, ami az egyik verziót sikeresebbé tette, mint a másikat (pl. a fab.com csak a kék és a piros gomb közötti különbséget mérte.

És hogy hogyan is kell beállítani egy A/B tesztet? Természetesen ebben mi is tudunk segíteni, de ha egyedül szeretnél belevágni, ezen 3 platform valamelyikét tudom ajánlani:
Visual Website Optimizer
Optimize.ly
Google Analytics Experiments

FOLYTATÁS: Szignifikáns vagy sem? Így mérd az AB-teszted eredményességét! 

Mester Tomi