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

Első adatvezérelt projekt

Sok cél, sok adat, sok elemzési lehetőség, sok információ… Egy már működő vállalkozás esetében egyik pillanatról a másikra adatokat bevonni a döntési folyamatokba nem is olyan könnyű. Ennek az oka pedig az, hogy rengeteg fajta adatvezérelt projekt létezik. Így kiválasztani az elsőt, ami igazán hasznos, nehéz.
Most felsorolok 3 projektet, amelyek az elmúlt évek tapasztalatai alapján jó első lépések lehetnek az adatvezéreltség rögös útján.

1. Konverzió optimalizálás AB-teszttel

Ez a projekt iszonyatosan egyszerű és rögtön látványos eredményt hoz, ami nem más mint a konverziónövekedés. Azt pedig mindenki szereti. :-) (Az AB-tesztelésről már többször is írtam, úgyhogy most a részletekbe nem mennék bele.) A folyamat az, hogy:

I. Megkeresel egy UX-problémát a honlapodon.
II. Keresel rá alternatív megoldásokat.
III. Teszteled, hogy melyik a legjobb megoldás.
IV. A legjobb megoldást kiteszed élesbe.
V. Újrakezded egy új problémával.

Amit sosem szabad kihagyni, az az AB-tesztet megelőző kutatás. Sokszor látom, hogy az emberek elkezdenek csakúgy megérzésből AB-tesztelni. Néha összejön, néha pedig nem… Amit mi szeretünk csinálni: teszt előtt hőtérképes elemzés, Google Analytics elemzés és legalább 3 user-teszt egy adott oldalra. Ez alapján sokkal célzottabb és hatékonyabb AB-teszteket tudunk összerakni.

2. Stratégia adatalapon

A hosszútávú döntésekben segít. Éppen emiatt nem olyan látványos és azonnali az eredménye. Amiért mégis szokták szeretni a döntéshozók, mert konkrét számokat látnak a stratégiáik mögött.

Sokfajta metódus létezik. Én a 4DX módszertant találtam eddig  a legjobbnak. Ennek a lényege, hogy van egy főcélod (pl. bevétel?) és keresel ehhez támogató alcélokat (ún. lag-ek) és az alcélokat támogató tevékenységeket (ún. lead-ek). A struktúra akkor működik, ha minden eleme mérhető is.

3. Triggerek és automation-ök

Ebben a pontban általában e-mail marketing-ről beszélünk. De lehet szó push-notification-ökről, sms-kampányról, in-site pop-up-okról, akármiről.

A lényeg, hogy ha követed a felhasználóid viselkedését, akkor bizonyos viselkedésminta aktiválhat bizonyos üzeneteket. Pl. ha látod, hogy egy felhasználó 100-szor megnézte a landing-edet, de még egyszer sem vásárolt onnan, akkor küldhetsz neki egy levelet, hogy személyes support-ot kínálsz neki, hogy könnyebb legyen a vásárlás.
Ha látod, hogy egy másik felhasználó vásárolt nálad 10 terméket, küldhetsz neki egy e-mail-t, hogy köszönöd a hűségét, itt egy 50%-os kupon, etc…

Ezek az ún. triggerek azonnali és látványos hatást fejtenek ki a lemorzsolódó felhasználók visszatérésére, hiszen személyre szabott üzenetet küld a megfelelő embereknek a megfelelő pillanatban.

Merre tovább?

Ez a 3 projekt (1. kutatás + AB-teszt, 2. Stratégia felépítés, 3. Trigger-ek beállítása) az, ami legjobb első adatvezérelt projektek között van. Látva az eredményességüket pedig könnyebb már továbblépni a saját adatbázisok felépítése és a finomabb (és még hasznosabb) adatos projektek felé.

Többet akarsz tudni a témáról? Gyere el az Adatvezérelt Marketing Tréningünkre!

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)

Vendégblog: A kis herceg és a Big Data – így kezdj neki

Pusztai Ádám Big Data cikkEheti vendégbloggerünk Pusztai Ádám, aki az adatlaboros egyetemista képzésünket is látogatta. Ádám egyébként Veszprémben végzett vegyészmérnökként, emellett pedig a Big Data az egyik fő érdeklődési területe… A következő profi összefoglalója a Honnan (és hogyan) tanuljunk a Big Data-ról címet is kaphatta volna.


“Ami igazán lényeges, az a szemnek láthatatlan.”
A kis herceg remekül összefoglalta az adatelemzés és adatbányászat lényegét. Az utóbbi időben egyre inkább érdekel ez a téma, ezért gondoltam, hogy utánanézek, ki mit mond róla, és ha beleásnám magam, akkor hogyan kezdjem el. Tuti recept szerintem nincs, de én így álltam neki:

Gyűjtögetés
A taktika az volt, hogy felütöttem a Google-t a “big data”, “how to start big data learning”, “big data 101” címszavaknál, és gondolkodás nélkül megnyitottam az összes első oldalas találatot. Ezek között voltak hasznos oldalak, kevésbé hasznosak, egyáltalán nem témába illőek (rossz SEO), és voltak összegyűjtött listák is.

Ezeket a találatokat bedobáltam egy dokumentumba, de ebben a formában teljesen használhatatlan volt, úgyhogy elkezdtem rendszerezni.  Ezután már csak azt kellett kitalálni, melyikkel résszel kezdjem.

A terv
Úgy gondoltam, egy kis ráhangolódás nem árt, ezért először olyan TED videókat kerestem, amik kapcsolódnak a témához. Itt találsz 13 előadást az adatokról, ebben a videóban pedig Hans Rosling elképesztő statisztikáit láthatod (mozgó bogyók, úristen mennyire menő!).
Többször is előkerült ez az infografika azzal a tanáccsal, hogy vallásos áhítattal kövessem. Nem mondom, hogy így van, de néha kelet felé fordítom és napjában ötször ránézek.

Első lépésként olyan forrásokat kerestem, amik helyre teszik a fejemben azt, hogy a Big Data mire jó, milyen technikákkal lehet és érdemes nekifogni ilyen elemzéseket végezni, és ehhez milyen technikai háttér szükséges részemről. Az ajánlások alapján a következő könyveket szereztem be (mindegyik ingyenesen elérhető):

Egyelőre az első hármat olvasom, aztán majd kiderül, hogy a keményebb programozás témájú könyvek hogy mennek. Annak érdekében, hogy ne csak könyvekből kelljen kihámoznom a lényeget, találtam online kurzusokat mind általánosan Big Datára, mind pedig programozásra is. A következőket ajánlom:

Online kurzusok / Big Data:

Online kurzusok / Programozás:

A végén járok a Codecademy-s Pythonnak és a CodeSchool-os R-nek, a Datacamp lesz a következő utánuk. Mindkét nyelv tetszik, sokban hasonlítanak a Matlabra, amit az utóbbi években használtam (nem feltétlen adatbányászatra).

Trello tábla gyűjtemény
Egy elvetemült figura készített egy hatalmas gyűjteményt, külön táblákra rendszerezve az ő forrásait, aszerint, hogy melyik cikk, online kurzus, könyv, blog, képregény(?), és a többi. Itt megtalálod.

Gyakorolni, gyakorolni, gyakorolni
Megvan a tudás a fejedben, a rendszerek a lelki szemeid előtt, most ki kellene próbálni mindezt. De hogyan? Ha nincs kéznél egy irdatlan méretű adatbázisod, ne ess pánikba, ilyeneket is találtam:

  • Quandl: ingyenes/korlátozott hozzáférés rengeteg adatbázishoz: https://www.quandl.com/
  • egyéb gyűjtemények:

A versenyszellem is segíthet. A Kaggle olyan oldal, ahova adatelemzős feladatokat töltenek fel (például a GE, az Amazon, vagy a Microsoft), és benevezhetsz a saját algoritmusaiddal és megoldásaiddal az adott contest-re, magyar szemmel nézve nagyon szép díjazásokért. Ráadásul még tutorial oldaluk is van, érdemes rápillantani arra is.

Alapok, technikák, gyakorlás – nekem ez a tervem a nyárra. Te hol tartasz?

Pusztai Ádám

Adatsztori 2. rész: tinilányok, müzli, kauzalitás

Nemrég hallottam Dr. Mine Cetinkaya-Rundel professzor asszony webináriumán az egyik legjobb esettanulmányt a korreláció vs. kauzalitás problémájának szemléltetésére:

2005-ben volt egy kutatás, ahol több mint 2000 darab 9 és 19 év közötti lányt kérdeztek reggelizési szokásaikról. A felmérés része volt, hogy az év során egyszer véletlenszerűen megkérdezték a lányokat arról, hogy mit ettek az elmúlt 3 napban. Azt találták, hogy azok a lányok, akiknél a válasz az volt, hogy müzlit ettek reggelire, szignifikánsan alacsonyabb testzsír-index-szel rendelkeztek, mint azok, akik valami mást.

A kutatás következtetése: a müzlitől soványabb leszel.
Csakhogy ez a következtetés: HIBÁS!

Miért?Mert ez a kutatás egyedül azt mutatja meg, hogy van valamilyen összefüggés a müzli és a testzsír-index között, de az ok-okozati kapcsolatot nem lehet belőle megállapítani. Gondolj bele! Valójában 3 jó megoldás is létezik:
1. Lehet, hogy – valóban -, aki müzlit eszik, az soványabb lesz.
2. De az is elképzelhető, hogy az eleve soványabb emberek valamiért jobban szeretik a müzlit. Tehát a soványság következménye a müzlifogyasztás.
3. Vagy esetleg valami külső okból származik mindkét dolog (soványság, müzlifogyasztás) és köztük közvetlen ok-okozati összefüggés nincs is. Pl. aki eleve egészséges életmódot folytat, az szeret müzlit enni és a testzsír-indexe is alacsonyabb, hiszen pl. sportol is. De ez nem azt jelenti, hogy a müzli önmagában soványabbá tesz, jelentheti azt is, hogy a sportos emberek fejében az van, hogy müzlit kell enniük.

Dr. Mine Cetinkaya-Rundel
Dr. Mine Cetinkaya-Rundel ábrája -korreláció vs. kauzalitás


Mi a tanulság ebből?
A fenti probléma egy közismert adatelemzési problémakör része az adatvezérelt üzletek világában is. A neve: korreláció vs. kauzalitás. Az általános megállapítás az, hogy ok-okozati viszonyt (kauzalitást) soha sem lehet megállapítani visszatekintő elemzésekből. Ezekből mindig csak és kizárólag összefüggést (korrelációt) lehet kikövetkeztetni.
A kauzalitás tényleges megállapítására egyedül az ún. kontrollcsoportos vizsgálatok valóak. Tehát a fenti példában a korrekt megoldás az lett volna, hogy a lányokat két csoportra szedik és az egyik csoportnak müzlit adnak enni minden reggelire, a másiknak pedig akármi mást. Majd figyelik, hogy hogyan változik a testzsír-indexük. Ha itt nyer a müzlis szegmens, akkor már valóban mondhatjuk, hogy a müzli soványabbá tesz.

Ez a módszertan az offline világban elég nehézkes, habár vannak rá példák…
Az online világban viszont nagyon egyszerűen kivitelezhető: ez az, amit A/B tesztelésnek neveznek. Jellemzően a korreláció vs. kauzalitás problémáját akkor érdemes A/B teszteléssel megoldanod, ha egy új funkciót (új feature-t) vezetsz be az oldaladon. Ilyenkor ugyanis el tudod dönteni, hogy valóban az új feature volt hatással a közönséged elköteleződésére (jó eset) vagy a közönséged eleve elkötelezettebb része érdeklődött az adott funkció iránt (kevésbé jó eset).

Összefoglalva: semmilyen kérdőív eredményből, felmérésből vagy visszatekintő elemzésből ne vonj le elhamarkodott következtetéseket! Próbálj helyettük minél több AB-tesztet és/vagy kontrollcsoportos vizsgálatot végezni!

Mester Tomi

Top-Adatelemző/BI eszközök (, amelyekről nem gondolnád, hogy ingyenesek)

Micsoda!? Ingyenes A/B tesztelő szoftver? Ingyenes hírlevél motor? Ingyenes funnel-metrika/KPI-metrika építő eszköz?
Nos, igen. Létezik. Minden cégnek és minden projektnek más-más adatelemző/big data/BI eszközcsomag az optimális. Azonban vannak tool-ok, amelyek mindenkinek alapvetés kellene, hogy legyenek. A vicc pedig az, hogy ezek ingyenesek. Legalábbis egy bizonyos cégméretig. Pl. ott az Optimizely – mindenki csak annyit tud róla, hogy kb 30.000$-nál kezdődik az éves előfizetésük, de azt már kevesen tudják, hogy 50.000 egyedi látogató/hó méretig (ami lássuk be, nem kevés) teljesen ingyenes. Nézzük szépen sorban a legmenőbb eszközöket, amelyeknek hasonlóan barátságos az árazási modelljük.

Mixpanel
mixpanel logoVan Google Analytics-ed? Szuper. Mi hiányzik belőle? Pl. az egyedi mérések és definíciók. Vagy az, hogy minden egyes felhasználót/felhasználói szegmenst vagy csoportot e-mail cím szerint láss. Vagy az, hogy ha egy user-ed eljutott valameddig a vásárlásban, de utána abbahagyta folyamatot, autamatikusan kapjon egy visszacsábító e-mail-t (, aminek a tartalmát akár A/B tesztelheted is)?
Ezt mind-mind tudja a Mixpanel. Sőt ennél még sokkal többet. Gyakorlatilag mindent, amit egy saját big data adatbázissal meg tudsz csinálni.
Az ára pedig 25.000 egyedi felhasználóig ingyenes.
Implementálás – megfelelő szakértelemmel – pár óra.mixpanel
Optimize.ly
Optimizely logoA/B tesztelő motor. A legjobb. Komolyan, az Adatlaborral sok ügyfélnél, sok fajta A/B tesztelő eszközt használtunk és végül az Optimizely mellett tettük le a voksunkat. (A VWO a második a sorban, de ott gyakran váratlan bug-okba, kis hibákba futottunk, ami bizony elég idegesítő tud lenni.) Ami csábító benne, hogy WYSIWYG, azaz “What you see is what you get” (azt kapod, amit látsz), tehát ha egy egyszerűbb tesztet össze akarunk dobni, akkor nem kell programoznunk, hanem elég egy grafikus felületen dobozokat tologatnunk.
Emellett kb. minden integrálható bele, pl. a fent említett Mixpanel, de a Google Analytics, a CrazyEgg, a Mouseflow és minden egyéb tool is.
Persze egy-két trükkel és best practice-szel még jobban ki tudjuk aknázni a tudását (pl. honlapátirányításos A/B teszt), de ha az árazáshoz jutunk megint meglepő fordulatot látunk (ahogy fent is írtam):
50.000 egyedi user/hó méretig ingyenes. (Ha pedig ezt túlléped, egyszerűen csak leáll a teszt.) Ebben az a szép, hogy 50.000 user-ből 100-ból 99 projektben már simán jönnek ki szignifikáns eredmények, úgyhogy ennél nagyobb motorra – legalábbis magyar viszonylatban – nincs is szükség.

Mouseflow
A Mouseflow-val 3 dolgot tehetsz meg:
1. Felveszed a látogatóid egérmozgását és visszanézed.
2. Ezekből kattintási/egérmozgatási hőtérképet készítesz.
3. Görgőzési hőtérképet készítesz.
Mind a három iszonyatosan fontos ahhoz, hogy megértsd, hogy mi miért és hogyan történik a honlapodon. Meglepődnél, hogy mennyire máshogy rajzolódik ki egy-egy kattintáshőtérkép egy-egy CTA gomb körül, ahhoz képest ahogy az a dizájnered vagy a Te fejedben megjelenik. Itt egy rövid videó a Mouseflow-ról:

A Mouseflow-nak is van ingyenes verziója, amiért 100 képernyőfelvételt nézhetsz végig havonta. Ez amúgy önmagában érdekes és hasznos is, azért egy hőtérképre inkább jobb a small csomagjuk (1000 felvétel/hó 15$-ért) vagy esetleg a medium (10000 felvétel/hó 60$-ért).
Implementálás – kb. 10 perc. :-)

Összefoglalás
Ez a 3 eszköz általában minden igényesebb adatelemzési/online termékkutatási projektnél jelen van. Azt hozzá kell tenni, hogy alternatíváik vannak. Egyrészről, amit tudni kell, hogy egy bizonyos méret után a házon belül fejleszett big data eszközök már jobban megérik anyagilag. Másrészt pedig más ár-érték arányban az alábbi tool-ok szolgálhatnak még jó példaként:
1. Mixpanel helyett: KISSmetrics
2. Optimizely helyett: VWO
3. Mouseflow helyett: ClickTale vagy CrazyEgg

Ha arra vagy kíváncsi, hogy hogyan lehet ezeket az eszközöket stratégiailag is alkalmazni, ne hagyd ki a ma esti (hétfő 04.13. 19:00) Big Data Adatstratégia webináriumunkat!

Mester Tomi

Ha Arany és Petőfi miatt vagy itt…

… akkor jó helyen jársz. Az Adatlabor csinálta a kutatást. (inspirácóért köszönet Kajtár Róbertnek) Itt megmutatok néhány technikaibb háttér-infot az elemzésről. Röviden újra összefoglalom az eredményeket. (Ha a kódolás részét túl bonyolultnak érzed, ugord át nyugodtan.) A kutatás célja az volt, hogy kiderítsük, melyik költőnknek a legnagyobb a szókincse, azaz melyik költőnk használ legtöbb »egyedi« szót verseiben. Az eredmények röviden:

egyedi szavak egyedi szótövek leírt szavak egyedi szótő arány
1 Arany János 59697 ~16.000 287425 20.77%
2 Vörösmarty Mihály 43938 ~12.000 214104 20.52%
3 Petőfi Sándor 32855 ~9.600 154721 21.23%
4 Ady Endre 30243 ~10.400 124574 24.28%
5 Babits Mihály 27116 ~11.000 398003 6.81%
6 József Attila 19635 ~8.200 62811 31.26%

Tehát, ahogy azt magyar órán is megtanulhattuk: Arany János a nyertesünk.

Több részletet: az origo-s cikkben olvashatsz.

Nézzük a technikai hátteret az egész mögött.
1. Milyen technológiát válasszunk?
Ez nem volt nehéz döntés. Csak egy gondolat: a Big Data nagyjából 1 milliárd sornyi adatnál kezdődik és mivel ennyit együtt sem írtak költőink, bár használhatnánk Big Data script-eket, ez amolyan ágyúval verébre megoldás lenne.
Egyébként Apache Pig-ben egy szószámláló script kb így néz ki hozzá:

A = load './input.txt';
B = foreach A generate flatten(TOKENIZE((chararray)$0)) as word;
C = group B by word;
D = foreach C generate COUNT(B), group;
store D into './wordcount';

(Forrás: itt)

A másik nyelv a Python lehetne, de az igazság az, hogy ilyen “kicsi” (pár százezer sor) adatmennyiséggel még egy egyszerű Bash script is megbirkózik és ott lényegesen rövidebb a kód:

cat text.txt \
|tr -d '[:punct:]' \
|sed 's/[[:upper:]]*/\L&/' \
|tr ' ' '\n' \
|wc -l

Az első sor beolvassa az adott szöveget, a második kiveszi a központozást, a harmadik gondoskodik arról, hogy a kisbetű-nagybetű ne számítson külön szónak (pl. mondat eleji “Kalap” és mondatközepi “kalap”) – a negyedik sor, minden szót egy új sorba tesz, az utolsó pedig megszámolja, hogy hány sorunk van.

Ha az egyedi szavakra vagyunk kíváncsiak, ki kell szednünk a szóismétléseket és minden egyedi szót csak egyszer számolni. Ehhez beteszünk az utolsó előtti sorba még egy kódot.

cat text.txt \
|tr -d '[:punct:]' \
|sed 's/[[:upper:]]*/\L&/' \
|tr ' ' '\n' \
|sort -u \
|wc -l

A szótövezés (azaz a “kalaptól” és “kalapban” szavak hasonlóságának felismertetése) egy kicsit bonyolultabb folyamat, úgyhogy abba nem is nagyon mennék bele.

Még a top 100 kifejezés listának a kódja lehet érdekes. Ez írja ki, hogy pl. mi volt az Ady Endre által legtöbbször leírt száz szó.

cat text.txt \
|tr -d '[:punct:]' \
|sed 's/[[:upper:]]*/\L&/' \
|tr ' ' '\n' \
|sort |uniq -c |sort -nr| head -100

Ha csak a Toldit elemezzük, akkor a legtöbbször használt kifejezések (az ún. stop-word-öket, mint pl. “a”, “az”, “hogy”, “is”, stb… eltávolítva):

65 Toldi
54 Miklós
29 jó
28 király
27 György
21 Isten
19 szépen

Egyébként a kutatás relatív egyszerű volt, az egész elemző script tokkal vonóval 40 sor — de jellemzően maga az adat megszerzése (versek lekérése) és letisztítása volt ebből 35 sor, a számláló megírása pedig 5.

Ígérem, ez volt a legtechnikaibb cikkünk! :-)

Tomi

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!

Jön a ChartCube!

Egyre többször találkozom mostanában a ChartCube nevű új adatvizualizációs alkalmazással, ami végtelen Excel táblázatokat alakít pillanatok alatt szép és könnyen értelmezhető chart-okká, automatikusan.

Ugyebár egy átlagos üzleti jelentés úgy néz ki, hogy a felelős ember elkezd dolgozni Excel-ben, különböző forrásokból összeszedi azokat az adatpontokat, amik a riportjához kellenek. Gyárt néhány szép chart-ot, amiket bemásol egy e-mail-be, ahol elindul a beszélgetés az adatokról. Mi a probléma? Hogy nehezen kezelhetőek a chart-ok, nem módosíthatóak, szükség esetén nem tudunk még egy szinttel mélyebbre menni, csak ha az eredeti riport gyártóját megkérjük és hát egyébként is nehezen hordozható az egész rendszer.

Ezeket a problémákat oldja meg  a ChartCube. Lényegében felgyorsítja az adatalapú kommunikációt a cégen belül. Talán a Forbes fogalmazta meg a legfrappánsabban – “a prezentáló kezébe elemzést, az elemzők kezébe prezentációt ad”.

A videójuk pedig többet mond ezer szónál is:

Ajánlom kipróbálásra!
Mester Tomi