Sokszor van szükség telefonszámok kezelésére, amelyek különböző adatforrásokból, vagy CRM rendszerekből érkeznek. Hogy tároljuk ezeket és hogyan ellenőrizetjük ezeket egyszerűen Python-al.
a felületre egy (szám) mezőt és készen vagyunk.” Nem egészen!!! Elsőre tűnik csak triviálisnak, de hamar rájövünk hogy nem ennyire egyszerű. Gondoljuk át hogy mire használjuk, és mi a célunk vele, és csak utána fejlesszünk.
gyorsan növekszik. • USA-ban okostelefonok aránya az összes mobil telefonhoz viszonyítva: – 2008. január: 10% 2011. január: 40% – 2009. január: 16% 2012. január: 48% – 2010. január: 24% jelenleg: >50% • A fejlődő országokban a mobil telefonok több mint fele immáron internet képes. Ezek a készülékek mindig velünk vannak.
a HTML5, és CSS3 támogatása. 2. Felhasználók érzékenyebbek a felületekre (UI), és a felhasználói élményre (UX). 1. Egyaránt működő megoldások desktop-on és mobil-on. 2. Jobban elmosódnak az országhatárok a mobilitásnak köszönhetően. 3. Egyre több szolgáltatás követeli meg telefonszámok megadását, megjelenítését. 3. Direkt marketing kampányok átalakulnak, az eDM új virágkorát éli Telemarketing és Mobil marketing kampányokkal kiegészítve. Piaccal lépést kell tartani, a régi módszerek már kevesek!
(Mozilla Firefox, Google Chrome) • WebKit dominanciája a mobil (85%*) és desktop (48%**) piacon (Google Chrome, Apple Safari) • A HTML5 és CSS3 funkciók gyors implementálása. • Folyamatosan gyorsuló JavaScript feldolgozók. Egyre kevesebb a régi böngészők aránya, és több nagy vállalat már visszamenőleg csak az utolsó két böngésző verziót támogatja fejlesztéseiknél. (pl.: Google***) * http://www.netmarketshare.com/browser-market-share.aspx?qprid=1&qpcustomb=1 ** http://www.w3schools.com/browsers/browsers_stats.asp *** http://googleenterprise.blogspot.hu/2011/06/our-plans-to-support-modern-browsers.html
természetes. Soha ne kínáljunk olyan felületet, ahol akár egy pillanatra elbizonytalanodik a felhasználó. – Felhasználók saját maguk tagolják a telefonszámaikat az alapján, ahogy számukra legkönnyebb megjegyezni. Soha ne korlátozzuk őket egy konkrét formátumra, és mindig engedélyezzük a speciális karakterek és a vágólap használatát. (pl.: 06 (30) 1234-387-et könnyebb megjegyezni, mint +36 30 123 4387-et) * – Soha ne korlátozzuk a telefonszámot egy országra, az emberek mobilisak, és semmi nem garantálja hogy nem külföldi veszi igénybe a szolgáltatást, vagy csak külföldi telefonja van.** – Ne vezessük félre, vagy tegyük egyértelművé, hogy hova mit írhat, vagy adjunk számára példát. *** * Nagyobb eséllyel hibázik a telefonszám megadásakor, és nehezebben ellenőrzi. ** Hamis telefonszámot fog megadni, mivel nem adunk lehetőséget. *** Rossz formátumú telefonszámot ad meg, ami inkonzisztenciát okoz az adatbázisban konvertálás nélkül.
Korlátozott formátum, Csak szám karakterek, Vágólap nem működik, … Bizonytalanság: “+36”, “06” vagy “0036”-al kezdjem? Beüthetek egyáltalán “+”-ot, vagy csak szám szerepelhet? ”0”-val kezdődhet, vagy levágják, sőt “06”-ról tudják majd hogy mi, ha az az oldal nyelve angol, de a cég magyar? mentés után facebook.com gmail.com
a Google-től. és a HTML5 kódot*: <input type="tel" tabindex="0" name="RecoveryPhoneNumber" id="RecoveryPhoneNumber" value="”> * iOS-en és Android-on a telefonszám tárcsázó billentyűzet jelenik meg, ez által a felület mobil kompatibilis is.
minden esetben az adott ország hivatalos nemzetközi formázásával egyezzen meg! • Ezt felismerik az okostelefonok, így közvetlen hívás is kezdeményezhető a honlapról. • Felhasználók ismerik a saját formázásukat, nem lesz idegen számukra, és egységessé teszik a megjelenő adatokat. import phonenumbers pn = phonenumbers.parse( '301234655', 'HU' ) print phonenumbers.format_number( pn, phonenumbers.PhoneNumberFormat.INTERNATIONAL ) # +36 30 123 4655 Lehetőség van telefonszámok nemzetközi, helyi, és E164 formázására, és parse- olására függetlenül a telefonszámban szereplő karakterektől. Ország átadása nélkül megpróbálja behatárolni az országot, azonban UI és UX szempontok alapján ezt a felületről érdemes bekérni.
illetve az értékesítés-ösztönzés fontos formája. Valamely reklámeszköz felhasználásával a megcélzott személyekkel történő közvetlen (direkt) kapcsolatfelvételre és (marketing)kommunikációra törekszik.” – Wikipédia Sok formája ismert, korábban a levélcsomag, telemarketing és az email marketing volt a legjelentősebb. Új kategóriaként jelent meg a mobil marketing. Utóbbi formái: • SMS: Marketing kommuniációs üzenet SMS-ben kerül kiküldésre az ügyfél mobiltelefonjára. • MMS: Az üzenetek képeket, videókat, hangokat tartalmazhatnak kommunikáció gyanánt. • Mobil alkalmazások: Okostelefonok alkalmazásai számos típusú üzenetet támogatnak. (pl.: Push Notifications, Rich Push Notifications, Interactive Ads) • Helyszíni marketing: Üzenetek közvetlenül az ügyfél mobiltelefonjára küldődnek megadott helszíneken. • QR kód: 2D-s bárkód amely pl. speciális kedvezményeket, termék adatokat tartalmazhat kódolt URL formájában.
az ügyfelek számára, ezért fontos hogy minimalizáljuk a hibás és rossz formátumú telefonszámokat. Számokat továbbá szét kell választani országkód, és vezetékes- vagy mobiltelefonszám alapján. Utóbbira a felhasználókat ne kérjük meg, túl sok hibás adathoz vezet. SMS kampányoknál a fizetés legtöbbször feladás alapján történik, felesleges költségek csökkentéseként, igyekezni kell a nem valós számokat megjelölni, és a jövőben telefonszám ellenőrzéskor kizárni őket. (pl.: +36 30 111 1111) Adatbázisban E164 formátumban érdemes a számokat tárolni!
1. Kiválasztja a felületről a nemzetközi hívószámot (pl.: “Magyarország (+36)”) 2. Beüti, vagy bemásolja tetszőleges formátumban a telefonszámot. (pl.: “(20) 123- 45/67” 2. Űrlap küldéskor konvertálunk és ellenőrzünk. 1. Normalizáljuk a telefonszámot E164-re. 2. Ellenőrizzük, hogy megfelelő hosszú és létező körzetszámmal rendelkezik. 3. Besoroljuk, hogy vezetékes- vagy mobiltelefonszám. 4. Ellenőrizzük, hogy nem szerepel-e már az adatbázisban elutasított státusszal. 5. Hiba esetén visszajelzünk a felületnek, különben eltároljuk. 3. Tároljuk adatbázisban. 1. A E164 formátumban tároljuk direkt marketing kiküldések és felületi megjelenítés miatt. 2. Tároljuk a besorolás típusát (vezetékes, mobil, …) 3. Tároljuk, hogy ellenőrzött vagy elutasított telefonszámról van-e szó.
(akár FK, akár VARCHAR-ként). 5. Minden telefonszámot külön rekordként tárolunk, és FK-vel kötjük a megfelelő felhasználóhoz. 4. Felületen formázottan jelenítjük meg 1. Felületen hivatalos nemzetközi formátumra formázzuk a tárolt számokat. 5. Telemarketing és mobil marketing kampánynál ellenőrzünk 1. Ha a telefonszámra nem tudunk SMS-t küldeni, vagy hívást kezdeményezni elutasítottnak kell jelölni a rekordot. 2. Sikeres megkeresés esetén ellenőrzött-nek kell jelölni a rekordot. 3. Kiküldéseket elutasított címekre soha sem szabad kezdeményezni. 4. Űrlap kitöltéskor és tároláskor nem szabad sem már elutasított telefonszámú személyt felvenni. 5. Kiküldéskor csak aktív elemekre szabad a kiküldést elvégezni.
amely feldolgoz, formáz, tárol és ellenőriz nemzetközi telefonszámokat. Java csomagot az Android framework-ben is használják a 4.0-ás (Ice Cream Sandwich) verzió óta. Neve: libphonenumber 2011. közepe óta elérhető portolása Python nyelvben. https://github.com/daviddrysdale/python-phonenumbers Azóta sok javításon esett át, és már alkalmazás fejlesztések alapjául is szolgálhat!
kulcs, szekvencia user_id INT4 Idegen kulcs, amely egy felhasználó elsődleges kulcsára hivatkozik territory VARCHAR(3) Régió neve, pl.: HU, FR e164 VARCHAR(15) E164 formátumú, normalizált telefonszám type INT4 Telefonszám típusa, number_type függvény visszatérési értéke. validated BOOL Sikeres üzenet küldés esetén TRUE, sikertelen esetén FALSE. Amíg nem történt kiküldés alapértelmezetten NULL. active BOOL Telefonszám aktív állapotú-e. Alapértelmezetten TRUE értékkel hozzuk létre. date_of_validation TIMESTAMP Ellenőrzés utolsó ideje. Minden üzenet küldéskor frissül. Telefonszámokat érdemes külön táblában tárolni, előzményként. Régi telefonszámokat nem töröljük, csak az active állapotukat módosítjuk.
telefonszámmal regisztrálni felhasználókat az oldalra, így elkerülhető a telefonszám duplikáció. • Nem engedünk elutasított telefonszámmal rendelkező felhasználókat az oldalra regisztrálni, így kordában tartható a rossz számok aránya. • Ha egy telefonszám ellenőrzésének dátuma kellően rég, levesszük az elutasított (pl.: 1 év) és ellenőrzött (pl.: 0,5 év) állapotát. • Az E164 mezőben egységes formában tároljuk így a telefonszámokat, konzisztens adatszerkezetet hozunk ez által létre. • A Territory, Type, Validated oszlopokat másodlagos indexekkel kell ellátni. • Egy felhasználóhoz lehetőségünk van több telefonszámot kezelni, de korlátozhatjuk akár típus alapján is (pl.: 1 vezetékes, 1 mobil szám). • Nem aktív telefonszámok kezelésével, és az azokhoz tartozó ellenőrzés állapotának tárolásával pontosabb eredményeink vannak hibás (nem létező) telefonszámok regisztrációjának megakadályozásához. (pl.: +36 30 111 1111)
ország milyen csatornájára szeretnénk üzenetet küldeni. (pl.: Magyar Mobil) • Leválogatásnál csak az aktív, nem elutasított (NULL, vagy TRUE értékű) telefonszámokat szabad figyelembe venni. • Sikeres üzenet küldésnél ellenőrzött státuszt kap, sikertelen küldésnél elutasítottat. Mentjük az ellenőrzés idejét is adatbázisba. De miért is kell ilyen szigorúnak lennünk?