Pécsi Tudományegyetem Pollack Mihály Műszaki Kar Műszaki Informatika Szak Data Mining

Pécsi TudományegyetemPollack Mihály Műszaki KarMűszaki Informatika SzakData Mining 21. Előadás Dr. Pauler Gábor, Egyetemi Docens PTE-PMMFK Villamos Intézet Számítástechnika Tanszék Iroda: Boszorkány u., B épület 101 Tel: 72/503-650/3725 E-mail: gjpauler@acsu.buffalo.edu

Az előadás tartalma A fogyasztói kártya fogalma, jogi szabályozása Fogyasztói kártya rendszer filozófiák Korábbi fogyasztói kártya menedzsment elméletek A House of Profit modell • Hardver és szoftver környezet • Bemenő adatok • Aggregációs dimenziók • Tényadatok a pénztári termináloktól • Tényadatok az árazásból • Tényadatok a nészámlálási hivataltól • Az aggregáció problémái • A fogyasztói kártyák háztartásokba csoportosítása • Az aggregáció alapmértékegységének kiválasztása • Termék kategória hierarchia létrehozása • A háztartások geokódolása és CBG-hez csatolása • A geokódolás adatforrásai • A geokódolás menete • A geokódolás eredményei

A fogyasztói kártya fogalma 1 A fogyasztói kártya (Loyalty Card): olyan vevők számára kibocsátott vonalkódos-, mágneses-, chipkártya, amely lehetővé teszi olcsó, gyors, tömeges azonosításukat, esetleg a kapott kedvezmények, privilégiumok adatait is tárolja (ezüst/ arany/ platina kártya) Előnyei: • A kártyára történő feliratkozáskor szocio-demográfiai infókat szerezhetünk meg a vevőtől: a jövőbeli kedvezmények fejében átadja bizonyos személyes adatait, úgy hogy másnak nem adhatjuk tovább: • Ez lehetővé teszi a vásárlások és a kapott kedvezmények vevőre, üzletre, eladóra, termékfajtára, mennyiségekre, időben történő nyomonkövetését

A fogyasztói kártya fogalma 2 • Ezen infók elemzésével lehetővé válik személyre becélzott termékkínálat, árazás és promóciós akciók: egyedi árengedmények (sales), kuponok (coupon), árukapcsolás (bounding), ezzel magamhoz tudom kötni a vevőt a versenyben Nehézségei: • A kártyák kibocsátása, a kártyaolvasokolvasók és más hardverek, szoftverek óriási beruházási költséget jelentenek egy áruházlánc esetén • A kártya használata a fogyasztótól plusz erőfeszítést és személyiségi jobainak egy részéről történő lemondást követel, ezért jutalmazni kell • Az adatok megszerzése fejében kiadott jutalmak, árengedmények egy az egyben csökkentik a profitot • Előre kell jelezni, mely fogyasztói csoportnak érdemes kedvezményeket adni, ki fog ezért többet venni profitabilis cikkekből. Ha mindenkinek vakon szórom a kedvezményeket, soha nem térül meg a beruházás

A fogyasztói kártyák jogi szabályozása USA: Senate Bill 926 The supermarket Club Card Disclosure Act • A fogyasztó beleegyezésével gyűjthet csak adatokat • Nem kérheti a kártya kiadásához a személyi azonosítót és a társadalombiztosítási számot • Nem adhatja el az adatokat senkinek (miért is tenné?...) • Elemezheti a fogyasztói csoportok demográfiai és vásárlási adatait, de egyénekét nem! • Nincs megadva, hogy egy csoport hány főből állhat... Magyarország: „A polgárok személyi adatainak és lakcímének nyilvántartásáról” szóló 1992. évi LXVI. törvény II. Fejezete: • 3.§ (1) „Személyes adat akkor kezelhetõ, ha a) ahhoz az érintett hozzájárul.” • 10.§ (1) „Az adatkezelõ köteles gondoskodni az adatok biztonságáról, köteles továbbá megtenni azokat a technikai és szervezési intézkedéseket és kialakítani azokat az eljárási szabályokat, amelyek e törvény, valamint az egyéb adat- és titokvédelmi szabályok érvényre juttatásához szükségesek.” • 17.§ (1) „Az érintett, jogainak megsértése esetén, az adatkezelõ ellen a bírósághoz fordulhat.” Az USA-ban ez egy gumi jogszabály, a hazai szabályozás elvileg szigorú, de a szankciók csak ejnye-bejnyére korlátozódnak: óriási anyagi érdekek állnak mögötte, hogy így legyen!

Diszkont-szemlélet A kártya célja, hogy a fogyasztói kötődést növelje Engedményeket ad, hogy növelje az eladásokat és a forgalmat Mindenki számára azonos tömeg-promóció Árútömeg-növelés a cél Relációs adatbázist igényel Csak a teljes üzletlánc hatékonyságát méri a versenytársakhoz Eladás-orientált menedzsment Példák: Safeway, UK 1998, 10M kártya, bukás 2000-ben, $42M veszteség ASDA, UK 1999, 360K kártya, visszatér a tartósan alacsony árakhoz (EDLP) Adatbázis Marketing-szemlélet A kártyák nem generálnak fogyasztói kötődést Engedményt ad, hogy infót gyűjthessen a fogyasztóról, és kiválassza a legjobbakat Szelektív promóció az értékes fogyasztóknak A cél a profit OLAP rendszert igényel Fejlett benchmarking rendszer (versentársak, üzletek, régiók) Egyéniesített marketing-orientált menedzsment Példák: Tesco, UK 1998 14M kártya Sainsbury, UK 1999 13M kártya Erős versenyben, igényes fogyasztóknál sikeresebb!!! Fogyasztói kártya rendszer filozófiák

Korábbi fogyasztói kártya menedzsment elméletek: A gyakorlatban legelterjedtebb Recency-Frequency-Monetary (RFM) modell (Bellman, 2001; Bult andWansbeek, 1995; Hughes, 1995; Sachs, 1997; Schoenbachler et al., 1997; Raider, 1999) a fogyasztói kártyákat három változó szerint kvintilisekbe csoportosítja: • Utolsó vásárlás óta eltelt idő, hét (R=1..5), • Vásárlási gyakoriság, n/hét (F=1..5) • Összesített eladások, $ (M=1..5) • Az R  F  MDescartes-szorzattal kontingencia táblát csinál, és kiszámítja a gyakoriságot125cellában • A legértékesebb, és legnagyobb létszámú cellákat választja ki Direct Mail promócióra (Pl. R5F5M5, R4F5M5, R5F4M5, R5F5M4 stb.) Előnyei: • Egyszerű és könnyen érthető • Alacsony számolásigényű Hátrányai: • Elszigetelt fogyasztói kártyákat vizsgál teljes háztartások helyett • Nem vizsgálja a profitot és a profitabilitást, volumen orientált. Pedig saját eredményeink szerint a gyakrabban vásárló – értékesebbnek gondolt – fogyasztók profitabilitása jelentősen alacsonyabb. Van a vásárlóknak egy jelentős rétege, az akcióvadászok (Cherrypickers), akik pl. munkanélküliek, nyugdíjasok, unatkozó háziasszonyok, így van idejük hetente hatszor vásárolni, és levadászni minden kis akciót. • Nem vizsgálja, mennyit vásároltak a versenytársaknál • Az eladások (M) egyszerű összegzése figyelmen kívül hagyja az értékes, de újonnan csatlakozott fogyasztókat

A House of Profit modell fogalma: • fogyasztói kártya- és népszámlálási adatokból indul ki • Szegmentációt hajt végre a fogyasztók közt • A szegmenseken belül loglineáris regressziós keresletbecslési-árrugalmassági módszerrel elemzi a termékek üzleten belüli versenyét • Vezetői döntéstámogatást ad árazási- és árukapcsolási akciók tervezéséhez, valamint a forgalom- és profit optimalizációhoz Az igényelt hardver és szoftver környezet: • SUNY Bioinformatics SuperCluster 2000db×(1.5GHz CPU+512MB RAM+40GB HDD) 10%-a, Unix Solaris operációs rendszer (lásd: Supercomputer.wmv ) • Adatbázis Oracle 11.0-ban (lásd: http://www.oracle.com ) 150GB/év = 750GB (világelső: Wal-Mart 3000GB) Dr. Pauler Gábor – Dr. Alan Dick: House of Profit modell

A fogyasztói kártyrendszerből származó bemenő adatok 1 Aggregációs dimenziók: • A Pops áruházlánc 168üzlete (Store) NY, OH, PA államokban, amelyek 5 földrajzi régióba (Region) × 5 versenycsoportba (Competitive Cluster) tömörülnek. Ez utóbbi a versenykörnyezet keménységét fejezi ki az adott üzlet számára • 260 vasárnaptól-szombatig tartó hét (Week)(2000 május – 2005 május), amelyek negyedévekbe (Quarter), majd évekbe (Year) csoportosulnak • 4.3M fogyasztói kártya (Bonus Card)(világelső:Tesco 12M) 2.8M háztartásba (Household) csoportosítva, amelyek 3 Lojalitási (Loyalty) kategóriába × 4 Profitabilitási (Profitability) kategóriába = 12 szegmensbe (Segment) csoportosulnak, és ezek mindegyike három részre van vágva az abszolút $ profit (Profit Cut) szerint (negatív, a szegmens mediánja alatti, szegmens mediánja feletti) • Ezenkívül a háztartások régiókba is tömörülnek, a nekik legtöbbet eladó üzlet (Best Store) régiója szerint • Valamint a háztartások az állandó lakhelyük szerint 500-1500 háztartásból álló népszámlálási körzetekbe (Census Block Group, CBG) is csoportosulnak • 215000 féle egyedi vonalkóddal (UPC Code) azonosított termék, amelyek egy 5 szintű hierarchikus rendszerben 450 funkcionális alkategóriába (Functional Category Hierarchy) csoportosulnak, amelyek 44 termék főkategóriába (Supercategory) vagy 2600 márkába (Brand) tömörülnek. Ez utóbbiak lehetnek nemzeti márkák (National Brand) vagy a lánc saját kereskedelmi márkája (Private Label Brand) • 1100M megvásárolt tétel (Item)évente, amelyek 100M vásárlási tranzakcióba (Tranaction) csoportosulnak

Az üzletek pénztári termináljai által automatikusan gyűjtött tényadatok (Transaction Files): • A vásárlás időpontja: YYYY-MM-DD HH:MM:SS • Az üzlet kódja (Store Code) • A vásárló fogyasztói kártya kódja (Card Code) (0, ha nem kártyás vásárlás) • Az eladott termék vonalkódja (UPC Code) • Az eladott termék mennyisége (Quantity) • Mértékegysége (Measure Unit):db (Pieces)| font (Lb)| uncia (FlOz) • Forgalma (Actual Sales), $ • Profitja (Actual Profit), $ • Az ezt csökkentő üzleti- (Store), gyártói- (Manufacturer), fogyasztói kártya kupon (Bonus Card Coupon) beváltások: • A kuponok vonalkódja • Számuk, $ • Névértékük, $ • A fizetés módja (Method of Payment): készpénz (Cash), bankkártya (ATM Card), csekk (Cheque), szociális étkezési utalvány (Food Stamp) A fogyasztói kártyrendszerből származó bemenő adatok 2

Az áruházlánc árazási döntéseiből származó tényadatok (Cost Files): • Árazási hét kódja (Week) • Árazási régió kódja (Region) • A termék vonalkódja (UPC Code) • Egységára (Unit Price), $ A népszámálálási hivataltól (US Census Bureau) származó tényadatok: • A népszámlálási körzet (CBG) kódja • Népessége (Population), fő • Területe (Area), négyzetmérföld • Háztartások száma, db • Népesség nem| kor| jövedelem| képzettségi| foglalkozási| etnikai| ingatlan kategóriákban (Gender| Age| Income| Education| Occupation| Race| Real estate Category), fő • Termék főkategória kódja (Supercategory) • Átlagos potenciális fogyasztás (Potential Sales) a termékkategóriában, $/fő/év A fogyasztói kártyrendszerből származó bemenő adatok 3

Lojalitás # LojKód * LojNév Szegmens # SzegKód * SzegNév * LojKód * ProfKód Háztartás # HáztKód * Cím, demo * Duráció * CBG Kód * SzegmKód * LegjobbÜzl Kártya # KártyKód * VevőNév * HáztKód Profit # ProfKód * ProfNév Üzlet # ÜzlKód * RégióKód * VersCsp VersCsop # VersCsp * CsopNév Árazódás # ÁrazKód * VonalKód * Hétszám * RégióKód * EgységÁr * EgysKtg Kupon # Vonalkód * Típus * Engedm * ÁrazKód Dimenziók Régió # RégióKód * RégióNév Termék # Vonalkód * Leírás * TermKód TermCsop # TermKód * TermNév * FelettKód Nap # Dátum * HétSzám Hét # HétSzám * NegyÉv Negyedév # NegyÉv * ÉvSzám Év # ÉvSzám Tényadatok Tétel # TételKód * Mennyiség * TranzKód * ÁrazKód Tranzakció # TranzKód * Dátum * ÜzletKód * KártyaKód Fogyasztás # FogyKód * Fogyaszt * TermKód * CBG CBG # CBGKód * Terület * Demogr. Aggregációs szintek A kártyarendszer bemenő adatainak aggregációs diagrammja A rendszert egy OLAP Aggregációs diagrammon a következőképpen ábrázolhatjuk: • A háztartásokból egy igen sokfelé ágazó hierarchikus dimenzió bomlik ki • A termékcsoportok maximum 5 szintű hierarchiát alkotnak, de mivel nincs mindig kibontva az 5 szint, rekurzív szerkezetű dimenzióként ábrázoljuk • A rendszer gyorsítása érdekében 3 helyen is előaggregációt alkalmazunk: • A Háztartásoknál, • Egy kombinált táblában a Szegmensek × Régiók × Versenycsoportok × Termékcsoportok szintjén • Egy kombinált táblában a Szegmensek × Régiók × Versenycsoportok szintjén

Az aggregáció első problémája a fogyasztói kártyák háztartásokba csoportosítása (Householding): Egy-egy fogyasztói kártya forgalma külön-külön torz képet adhat: pl. a papa csak sört vesz, ezért alkoholistának nézzük, a mama csak zöldséget, ezért vegetáriánusként azonosítjuk, holott ketten együtt átlagos fogyasztású háztartást alkotnak. Ezért kell a kártyákat háztatásokba csoportosítani A fogyasztó a kártyára történő felíratkozáskor egy normalizálatlan címet ad meg, gyakran lakásszám nélkül Ezért, ha a HázSzám, KözterületNév, KözterületTipus, IrányítóSzám szerint normalizáljuk a címeket, és ezen mezők egyezése alapján próbáljuk a kártyákat háztartásokba csoportosítani Beleütközünk a problémába, hogy gyanúsan sok kártyát csoportosít egybe: pl. lakásszám híján egy tömbház, vagy nyugdíjasotthon összes lakóját egy háztartásba rakja Ezért a konzervatív megközelítést követjük: megköveteljük a CsaladiNév mező egyezését is. Ezzel elbukjuk ugyan az együtt lakó diákok, élettársak, férj nevét fel nem vett feleségek azonosítását, de tapasztalataink szerint ez még mindig a kisebbik rossz Biztonsági korlátként, semmiképpen nem csoportosítunk egy háztartásba három kártyánál többet (töröljük a 3 kártyánál nagyobb létszámú csoportokat (HAVING COUNT(CardCode)>3), és ezeket a kártyákat külön háztartásonként APPEND-eljük A kártyarendszer bemenő adatainak aggregációs számításai 1

Az aggregáció második problémája az alapmértékegységének (Basic Measure Unit) kiválasztása: Az aggregáció hierarchikus szintjein nem jó keverni különféle mértékegységeket, mert ez hibákhoz vezethet Így az összes monetáris mérték $/hét/háztartás-szintű átlagként kell, hogy megjelenjen a kimutatásokban Ez azért szükséges, mert az egyes szegmensek/ $ profit csoportok/ régiók /versenycsoportok és összes kombinációik eltérő számú háztartást tartalmaznak, tehát adataik csak akkor összehasonlíthatóak, ha beosztunk a háztartások számával Az egyes háztartások eltérő számú hetet tölthetnek a rendszerben egy adott negyedévben. Pl. ha egy új, jó vevőnk van, aki sok profitot termel, de csak 4 hete van a rendszerben, nyilván nem képes abszolút mértékben annyi proftot termelni, mint egy közepes vevő, akinek erre 13 hete volt. Így hajlamosak lennénk alulértékelni egy jó, de új vevőt. Ezt korrigálandó, osztjuk az adatokat a rendszerben töltött hetek számával (Duration) Azonban, a nagyon új vevőknél bizonytalan, hogy a jövőben is fennmarad kedvező teljesítményük: általában a klubkártya kiváltásakor mindenki vásárol egy nagyot, de lehet, hogy többet soha!! Ezért a 2 hétnél fiatalabb vevőknél a Duration értékét egy előzetes lekérdezéssel felnyomjuk 13 hétre, ami majd leviszi az átlagaikat, hogy ne lehessen őket túlértékelni 1-2 jó kezdő vásárlás alapján. Nem felejtjük el, hogy a hierarchkus rendszerek aggregációs szabálya szerint az átlagokat NEM tároljuk az előaggregációs szinteket képező táblákban, mivel az átlagok nem aggregálhatók tovább Ehelyett, külön-külön aggregáljuk a $ mennyiségeket, a durációs heteket, a háztartások számát, és CSAK a végső kimutatás számol ezekből átlagot A kártyarendszer bemenő adatainak aggregációs számításai 2

Az aggregáció harmadik problémája a megfelelő termékkategorizációs rendszer (Product Category Hierarchy) megléte: Az áruházláncok termékkategorizálási rendszerei hagyományosan raktárkészlet-nyomonkövetési célra készültek, így osztályonként dobják szét az árukat nem a fogyasztási funkcionalitásuk szerint. Ezenkívül gyakran nem frissítik őket rendesen, mert ez a nagyméretű kategorizáció még mindig papíron van és nem adatbáziskezelőben: pl. több alkategóriát hoz létre ugyanarra, mert elfelejti, hogy már csinált egyet, Vagy pl. ideiglenes akciók termécsomagjai számára külön főkategóriát hoz létre, Vagy pl. nem tud utólag plusz kategóriát beszúrni, ezért új termékeket máshova sorol be, stb. Így nagy szükség van egy a termékek funkció-hierarchiáját leképező, többszintű, flexibilisen bővíthető, a népszámláls kategorizációjával kompatibilis, adatbázisban tárolt termékkategorizációra. A termékkategóriákat nem folyamatos sorszámozással, hanem 11 jegyű decimális számkódolással jelöljük: 200000 Coffee 201000 Full cof f ee 201100 Full Bean coffee 201110 Full Bean coffee flav ored 201111 Full Bean coffee flavored pre mium 201112 Full Bean coffee flavored sta ndard 201120 Full Bean coffee un flavored 201121 Full Bean coffee unflavored pre mium 201122 Full Bean coffee unflavored sta ndard 201200 Full g round coffee 201210 Full ground coffee flav ored 201211 Full ground coffee flavored pre mium 201212 Full ground coffee flavored sta ndard 201220 Full ground coffee un flavored 201221 Full ground coffee unflavored pre mium 201222 Full ground coffee unflavored sta ndard A kártyarendszer bemenő adatainak aggregációs számításai 3 CCSSSSPBBBB Ahol: • CC – kétjegyű főkategória kód 0..44 (a 0 az egyéb termék kategória) • SSSS – négyjegyű specifikációs kód, általában termék| változat| árfekvés| méret kibontásban • P – kereskedelmi márka jelző {0,1} (Opcionális, nem mindig használjuk) • BBBB – négyjegyű márka kód (Opcionális, nem mindig használjuk) A kategóriákat lásd: PopsTermKateg.doc

Az aggregáció negyedik problémája a háztartások lakhelyének geokódolása, és CBG-tagságuk azonosítása (Geocoding): Nem elég azt tudni, hogy miből mennyit adtunk el egy háztartásnak, azt is jó lenne tudni, menyit vásárolt a versenytársaktól. Pl. lehet hogy valaki csekély keresletű vevőnek tűnik, valójában azonban nem az, csak máshol vásárol Egy háztartás összkeresletére vonatkozó becslés szindkált kutatásokban (pl. Spectra: http://www.spectramarketing.com/products/m_consumer360.jsp , A. C. Nielsen: http://www2.acnielsen.com/products/cps_homescan.shtml ) átlag 1$-ba kerül háztartásonként. Ez elviselhetetlenül nagy költséget jelentene 2.8M háztartás esetén A CBG-k termékkategóriánkénti fogyasztási átlagai viszont csak 500$-ba kerülnek az egész USA tekintetében (pl. Bureau of Labour Statistics: http://www.bls.gov/cex/home.htm ). Ezek 500-1500 háztartás átlagai, és összemossák a családméret és az életciklus egyedi különbségeit, viszont a CBGk elég homogének jövedelem és vagyon tekintetében Ha az akciók tervezésével nem megyünk le háztartási szintig, hanem csak CBG-kben gondolkodunk, akkor ezek átlagai megfelelő közelítést adnak, mert a a családméret és az életciklus okozta egyedi forgalmi különbségek CBG szinten kölcsönösen kioltják egymást Ezen adatok felhasználásához automatikusan meg kell határozni a háztartások CBG-tagságát az állandó lakcímük alapján A CBGk egy NY, OH, PA államokat tartalmazó vektortérképen sokszögekként definiáltak (pl. A US Census Bureau TIGER elektronikus térképe: http://www.census.gov/geo/www/tiger/ ). Ha a háztartások lakcímét egy (szélesség, hosszúság) kordinátába tudjuk geokódolni (pl. ESRI ArcView-val: http://www.esri.com/software/arcgis/arcview/index.html ), akkor megvizsgálhatjuk, hogy ez a koordináta mely sokszögbe esik, és így a háztartásra rácsatolhatók a CBG átlagos adatai. Lássuk ezt részletesen! A kártyarendszer bemenő adatainak aggregációs számításai 4

NyBlkGroup.DBF Tiger Data Demográfia Szöveges Geokodol.DBF Saját Export Címek Szöveges Road.DBF Tiger Data Utcanevek Szöveges Geokódol.dbf # KártyaKód * Cím * Irányítószám * Tiger ID * CBGKód Geokódol.dbf # KártyaKód * Cím * Irányítószám * Tiger ID Road.dbf # Tiger ID * KezdőSzámBal * KezdőSzámJobb * VégSzámBal * VégSzámJobb * Utcanév * Utcatipus * IrSzámBal * IrSzámJobb * KezdPontTigerID * VégPontTigerID NyBlkGrp.dbf # CBGKód * Lakosságszám * Terület * Népsűrűség * Korösszetétel * Jövedelem * ÖsszKereslet * Tiger ID Geokódol.dbf # KártyaKód * Cím * Irányítószám Geokódol.shp # Tiger ID * Szélesség * Hosszúság Road.shp # Tiger ID * Szélesség * Hosszúság * KövPontTigerID NyBlkGrp.shp # Tiger ID * Szélesség * Hosszúság * KövPontTigerID A geokódolás adatforrásai 1 NyBlkGroup.SHP Tiger Data Poligonok Bináris Geokodol.SHP ArcView output Pontok Bináris Road.SHP Tiger Data Vonalak Bináris • Az ESRI Inc. ArcView geokódóló szoftvere a földrajzi alakzatokat a következőképp tárolja: • Egy *.SHP formátumú bináris fájl tárolja a Tiger-ID elsődleges kulcssal azonosított alakzatok koordináta-pontjait és az őket összekötő adatokat • Ehhez mindig egy azonos nevű *.DBFdBase VI formátumú adatbázis fájl társul, ami a Tiger-ID-n keresztül csatol alfanumerikus információkat az alakzatokhoz • 2 TIGER fájlt vettünk és konvertáltunk: • Road.DBF/.SHP szakaszokat tároló adatbázis NY állam utcahálózatárol • NyBlkGroup.DBF/.SHP poligonokat tároló adatbázis NY állam CBG -iről • Ezenkívül van egy saját Geokodol.DBF adatbázisunk, amely normalizálatlan lakcímeket tartalmaz, amikből csak az irányítószám van különválasztva, ehhez kell SHP-t csinálni • A fájlokban lévő adatbázistáblák ER diagrammon ábrázolva • A geokódolási folyamat menete: • A Geokodol.DBF-hez létrehozunk egy Geokodol.SHP-t, ami a cimek koordináta pontjait tartalmazza • Majd a Geokodol.SHP koordinátáinak NyBlkGrp.SHP-hez történő m:1 csatolásán keresztül m:1 kapcsolatot hozunk létre a Geokodol.DBF és a NyBlkGrp.DBF közt

A Geokódolás adatforrásai 2 katt • A geokódolandó címeket MSAccess-ből DBaseIV-be exportáljuk Fájl|Export|Fájl tipus: dBase IV (File|Export|Files of type: dBase IV) menüvel, a következő táblastruktúrával a Geokodol.DBF-be • A Road.DBF táblastruktúrája a következő- képpen néz ki Az ArcView a Geokodol.Address mezőt némi mesterséges intelligencia bevetésé- vel házszámra, közterületnévre és közterü- lettipusra normalizálja (ez utóbbiak rövidí- tését is kezeli): • Ezen mezők, valamint a Geokodol.ZIP tartalmát egyezteti a Road tábla FeName, FeType, ZIPL, ZIPR mezőivel (ez utóbbi kettőből találja ki az utca bal-/jobb oldalát) • Az oldalnak megfelelően a házszám FRADDL..TOADDL vagy FRADDR..TOADDR kezdő/végházszámok közti tartományba esését vizsgálja • Találat esetén a cím koordinátáit a szakasz kezdő/végpont közti arányosítással számítja ki a házszámok alapján: X = (HazSzam-FRADDL)×FNODE(X)+(TOADDL-HazSzam)×TNODE(X) / (TOADDL-FRADDL) (21.1) Y = (HazSzam-FRADDL)×FNODE(Y)+(TOADDL-HazSzam)×TNODE(Y) / (TOADDL-FRADDL) (21.2) katt katt

A Geokódolás adatforrásai 3 A NyBlkGroup.DBF tartalmazza a CBG-k összes fontos demográfiai és fogyasztási jellemzőit is, CBG-szintű átlagokként: • Lakosságszám • Népsűrűség • Korösszetétel • Etnikai összetétel • Családi állapot, családméret • Ingatlan tulajdonlás • Termékkategóriánként összesített fogyasztások

A Geokódolás menete 1 katt katt katt • Indítsuk el az ArcView-t • A File|Extensions menüvel nyissuk meg az Extensions ablakot • Ebben jelöljük be a Geoprocessing-et, ami meghívja a geokódolást végző programmodult • Az ArcView-ban projekteket (Project) lehet építeni, amit *.PRJ kiterjesztéssel menthetünk el File|Save project as... menüvel • A projekt nézetekből (View) áll, egy üres nézetet minden projekthez automatikusan hozzáad • A nézet témákat (Theme) tartalmaz. A View|Add theme menüvel adjuk hozzá a Road.SHP/Road.DBF párt a nézethez, amit a kapcsolóját bejelölve grafikusan is megjelenít • A View|Geocode Addresses menüvel indíthatjuk a geokódolási varázslót katt katt katt katt katt katt

A Geokódolás menete 2 katt katt katt Megjelenik a Geocode Adresses beállítóablak: • A Reference Theme-nél állítsuk be a szakaszos adatbázist, amiben keres: Road.SHP • A Using Address Style-nél állítsunk US Streets with Zone-t (normalizálatlan címek és irányítószám) • Az Address Table-nél állítsuk be a címeket tartalmazó adatbázist: Geokodol.DBF • Itt Address Field-nek adjuk meg az Address-t, Zone Field-nek a Zip-et • Geokódolás közben mutathatja, hol tart, erre Display Field-nek adjuk meg a tábla elsődleges kulcsát, a Cardcode-t • A Geocoded Theme-nél adjuk meg a geokódolás eredményét tartalmazó *.SHP/*.DBF fájlpár nevét és elérési útját • A Geocoding Preferences gombra kattintva állíthatjuk a címnormalizáció betűzési érzékenységét (Spelling Sensitivity), minimális illesztési értékét (Minimum Match Score) • Ezután a Batch Match gombbal indíthatjuk a geokódolást katt katt katt katt katt katt katt katt

katt A Geokódolás menete 3 katt • Majd a View-ban megjelennek új Theme-ként a geokódolt címek • A bekapcsológombbal térképre rakhatjuk őket, majd dupla kattintással a Legend Editor-ban formázhatjuk a megjelenésüket • A View|Add theme menüvel adjuk a View-hoz a CBG-k poligonjait tartalmazó NyBlkGroup. SHP/ .DBF párt, majd a bekapcsológombbal rakjuk térképre (a térképen a kitakarások a Theme gombok egérrel történő áthuzogatásával rendezhetők) • Ezután dupla kattintással a Legend Editor-ban formázhatjuk a megjelenését: • Classification field-nél állíthatjuk a színezéssel megjelenített mezőt • Classify gombbal állíthatjuk a kategóriák számát • Color Ramps-nál a színfokozati skálát katt-katt katt katt-katt katt húz katt katt katt-katt katt katt katt katt

A Geokódolás menete 4 • Ezután a View|GeoProcessing Wizard menüvel indítjuk a va- rázslót: • Bejelöljük, hogy hely szerinti csatolást végzünk • Kiválasztjuk Geokodol1.SHP pontokat és NyBlkGroup.SHP poligonokat tartalmazó témá- kat, amiket úgy csatol, hogy a pontok poli- gonokba esését figyeli: • A poligonokat egy algoritmus feldarabolja háromszögekre. Egy (X,Y) pont (X1,Y1), (X2, Y2), (X3, Y3) háromszögbe esését a következő egyenletrendszer (a, b, g≥0)-ra történő megoldhatóságaként teszteli: X = a×X1 + b×X2 + g×X3 (21.3) Y = a×Y1 + b×Y2 + g×Y3 (21.4) 1 = a + b + g (21.5) katt katt katt katt

A Geokódolás menete 4 katt katt • A Geokodol1.SHP csatolt témát kijelöljük • A Theme|Table menüvel megtekinthetjük az adatbázis tábláját • File|Export menüvel indítjuk a tábla exportálását • Export Format-ként dBaseIV-et választunk • Megadjuk az eredményfájl nevét és elérési útját katt katt katt katt katt

A Geokódolás eredményei • Az eredményfájlként lementett dBaseIV adatbázis tábla tartalmazni fogja • Minden geokódolt címhez az illetékes CBG kódját a BKG_KEY mezőben, • Illetve demográfiai, fogyasztási adatait • Lássunk egy összefoglaló ábrát a geokódo- lás menetéről: CBG adatok lekérdezése Census Block Group sokszögek Geokódolt cím a CBG-hez térbelileg társítva Utca vektorok

Szakirodalom RFM modell: • Bellman, L.M. 2001. Bricks and mortar: 21st century survival, Business Horizons 44 (3) p. 21. • Bult, J.R., Wansbeek, T. 1995. Optimal selection for direct mail, Marketing Science 14 (4) p. 378-394. • Hughes, A.M. 1995. Making database pay off using recency, frequency and monetary analysis, Journal of Database Marketing v. 3, p. 77-89. • Raider, A. 1999. Programs make results out of research, Marketing News, Chicago, June 21, vol. 33, p. 14. • Sachs, W.S. 1997. How to find and cultivate customers through direct marketing, Journal of Consumer Marketing, Spring, v. 14, p. 179. • Schoenbachler, D.D. et al. 1997. Understanding consumer database marketing, Journal of Consumer Marketing 14 (1), p. 5. Szindikált kutatásokat végző cégek: • Spectra Marketing Inc. honlapja: http://www.spectramarketing.com • A. C. Nielsen Inc. honlapja: http://www2.acnielsen.com USA Népszámlálási adatbázisok: • US Census Bureau: http://www.census.gov/main/www/access.html • Bureau of Labour Statistics: http://www.bls.gov/cex/home.htm Elektronikus térképek geokódoláshoz: • US Census Bureau TIGER:http://www.census.gov/geo/www/tiger/ • Tiger formátum  SHP fájlformátum konverter szoftver: http://www.bluemarblegeo.com/products/translator.php Geokódoló szoftver: • ESRI ArcView: http://www.esri.com/software/arcgis/arcview/index.html

Pécsi Tudományegyetem Pollack Mihály Műszaki Kar Műszaki Informatika Szak Data Mining