Selama enam bulan terakhir, saya sering mulai mendengar di konferensi dan dari kenalan tentang berbagai produk berdasarkan konsep "kualitas pengalaman" (QoE). Istilah ini menjadi semakin populer. Cukup banyak penelitian yang sedang dilakukan untuk menciptakan metode baru untuk menentukan kualitas persepsi pengguna layanan atau layanan tertentu, tetapi sekarang saya tidak ingin menggali teori yang tertarik untuk dapat google sendiri.
Pesan iklan mengatakan bahwa produk ajaib ini dapat:
- Untuk mengidentifikasi masalah dengan kualitas komunikasi untuk CPE, termasuk ke peralatan pelanggan,
- Tingkatkan LTV (LifeTimeValue),
- Analytics Clickstream, yaitu, kemampuan untuk melacak situs yang dikunjungi, termasuk situs pesaing,
- Cari tahu berapa banyak alamat IP virtual di belakang alamat IP asli,
- Menentukan layanan / peralatan yang digunakan pelanggan (SIP, OTT, smart house, smart tv, peralatan jaringan),
- Untuk setiap pengguna, prioritaskan lalu lintas dan batasi protokol berbasis L7 tertentu,
- Integrasi yang mudah dengan OSS / BSS.
Karena tugas utama saya adalah untuk menemukan pelanggan yang tidak puas dengan kualitas Internet dan umumnya menyelesaikan masalah pelanggan churn dalam segala hal (saya bekerja dalam satu, bukan operator telekomunikasi terkecil di departemen kualitas layanan), produk ini (kami akan menyebutnya "QoE" untuk kenyamanan. ), dengan kata-kata manis dari penjual dan pemasar, menyelesaikan masalah ini. Tapi ini semua dalam teori, dan sampai Anda melihat sendiri dalam praktiknya, Anda tidak akan mengerti. Itulah sebabnya saya ingin berbagi dengan rekan kerja sisi praktis dari solusi ini, tanpa kemasan pemasaran yang indah.
Saya akan segera melakukan reservasi yang saya tidak akan panggil vendor, kalau tidak mereka akan mempertimbangkannya untuk iklan, dan tidak ada yang akan membayar saya untuk ini. Saya hanya bisa mengatakan bahwa ini adalah pabrikan Rusia, di mana ada solusi (perangkat keras dan perangkat lunak) untuk memfilter URL, DPI, dan produk berdasarkan prinsip QoE berdasarkan DPI ini.
Oleh karena itu, saya akan memberi tahu dan menunjukkan fungsionalitas apa yang berhasil saya uji, masalah apa yang muncul selama pengujian dan saya akan merangkum hasil subjektif saya.
Mulai pengujian
Saya tidak akan secara khusus menjelaskan bagaimana saya menerima peralatan untuk pengujian, karena tidak ada yang istimewa terjadi pada tahap ini. Singkatnya, mitra vendor dari perusahaan NAG dengan cepat menghubungi saya.
Kami meminta klarifikasi informasi tentang tugas-tugas yang ingin kami selesaikan menggunakan QoE, topologi jaringan, volume lalu lintas dan data orang penghubung dari perusahaan kami. Setelah itu, mereka mengirim tautan ke akun pribadi Anda, tempat Anda bisa berkenalan dengan produk secara langsung.
Akun pribadi
Setelah otorisasi, sebuah dasbor muncul, menunjukkan:
- Pelanggan aktif
- Pelanggan RTT / RTT Buruk (Round Trip Time) Buruk
- Paket dari / ke pelanggan,
- Nilai rata-rata RTT.
Jujur saja, konsep "RTT yang mengerikan" entah bagaimana keliru. Untuk beberapa orang, 10 ms dianggap mengerikan, untuk yang lain - 100 ms. Tetapi, beralih ke dukungan teknis dari vendor, saya menemukan bahwa penyedia menentukan indikator "horor" dan menuliskannya dalam konfigurasi QoE.
Masalah untuk pelanggan tertentu
Saya segera menemukan pelanggan bermasalah yang mengalami penundaan serius. Misalnya, lebih dari 4,5 ms
Di sini Anda dapat melihat data peralatan klien, dalam hal ini memiliki TP-LINK. Juga, panjang kabel pelanggan dan kesalahan CRC terlihat.
Hanya referensi cepat: Circular redundancy check (CRC) adalah cara untuk mendeteksi perubahan kecil pada blok data. Jenis deteksi kesalahan ini sangat berguna saat mengirim data paket melalui jaringan seperti SynqNet. Sementara penghitung kesalahan paket memeriksa paket yang hilang atau tidak sah, penghitung kesalahan CRC memeriksa validitas data dalam paket.
Kita dapat menyimpulkan bahwa kabel rusak atau ada masalah di dalam apartemen.
Anda dapat menampilkan masalah utama: misalnya, pelanggan segmen menurut kelompok kabupaten tergantung pada waktu dan RTT, Anda dapat memfilter dan mengelompokkan berdasarkan berbagai kriteria:
- Jumlah CRC per minggu,
- Sakelar akses
- Layanan
- Saklar tulang punggung,
- Kontrak
- Distrik
- Vendor perangkat pelanggan
- Panjang kabel.
Kami mencantumkan sakelar backbone dengan memfilter menurut wilayah. Hasilnya, kita akan melihat jumlah pelanggan pada sakelar utama. Ada 99 pelanggan di satu, 64 di yang lain, dll. Anda juga dapat melihat penundaan rata-rata pada sakelar backbone.
Yang terpenting, saya tertarik menemukan sakelar pengereman. Seperti yang dapat Anda lihat dari tangkapan layar di atas, sakelar ini adalah yang pertama dalam daftar dengan 99 pelanggan. Kita bisa masuk ke datanya dan melihat apa yang salah dengannya.
Kami mengklik sakelar, memfilter menurut kriteria "Sakelar Utama", mengelompokkan menurut kriteria "Sakelar Akses". Jadi akan jelas sakelar akses mana yang “terburuk” pada sakelar trunk ini:
Akibatnya, sakelar akses terburuk (disorot dengan warna merah) akan ditampilkan - ia memiliki RTT terbesar.
Sekarang kita pergi ke saklar akses terburuk ini dan lihat gambar berikut:
Kami melihat banyak sesi dengan penundaan lama. Jika Anda melihat pelanggan pada sakelar akses ini, Anda dapat melihat mereka yang memiliki kesalahan pada port - ini adalah masalah dengan kabel. Pada tangkapan layar di bawah, pelanggan nomor 12 terlihat, yang memiliki 898 kesalahan.
Anda dapat segera melihat pelanggan dengan RTT besar, misalnya, 10.5
Kami pergi ke pelanggan dan melihat gambar berikut:
Untuk setiap pengiriman ulang lima menit, pelanggan memiliki kerugian sekitar 2%. Kemungkinan besar, dia perlu mengubah router Wi-Fi. Klien ini pasti perlu ditangani.
Pelanggan dengan Internet yang buruk secara konsisten
Ini adalah salah satu alasan utama yang mendorong saya untuk mencoba QoE. Anda dapat menarik semua pelanggan dengan RTT yang buruk dan bekerja secara individual dengan masing-masing. Misalnya, buka statistik dalam daftar untuk nomor pelanggan 3.
Pelanggan ini tidak memiliki kesalahan pada port, kabelnya 37 meter. Kemungkinan besar, masalahnya terletak di apartemen pelanggan.
Masalah dengan Wi-Fi Vendor
Seperti yang saya pahami, ia bekerja seperti ini: informasi dihapus dari server DHCP pada MAC perangkat pelanggan. Dengan demikian, semua vendor Wi-Fi ditarik keluar:
Yang paling populer dan dengan RTT normal ternyata adalah Zyxel, ia memiliki 9307 pelanggan.
Terburuk di bawah ini, dengan RTT 15.2 dan di bawah.
Dijual kembali Internet
Saya juga menemukan fungsi yang menunjukkan pelanggan dengan jumlah sesi.
Anda dapat segera melihat pelanggan dengan banyak sesi. Mari kita pergi ke pelanggan di nomor 1.
Di bagian Log Clickstream, Anda dapat melihat berapa banyak perangkat yang saat ini dimiliki oleh pelanggan:
Seperti yang kita lihat, pelanggan memiliki 100 perangkat. Pelanggan seperti itu pasti menjual kembali Internet. Apa hubungannya dengan itu? Misalnya, kami berencana untuk mentransfer pelanggan tersebut ke layanan sebagai badan hukum.
Analisis clickstream
Tampaknya semuanya sederhana di sini: clickstream menunjukkan perangkat mana yang pelanggan gunakan, situs mana yang mereka kunjungi, browser apa yang mereka gunakan. Informasi ini tidak begitu menarik bagi saya, tetapi ternyata perlu bagi pemasar kami. Misalnya, mereka tertarik dengan skenario berikut:
1) Penjualan layanan TV kami kepada pelanggan yang memiliki Smart TV. Untuk melakukan ini, Anda dapat memfilter berdasarkan agen pengguna: SmartTV dan menampilkan pemilik TV pintar. Kemudian masalah teknologi: menelepon pelanggan atau menawarkan surat untuk menghubungkan tarif dengan TV.
2) Cari pelanggan potensial yang tidak puas yang tertarik pada situs pesaing. Di bagian yang sama, "Clickstream logs" kami mengarahkan URL pesaing yang menarik ke baris "domain", dan, sebagai hasilnya, kami mendapatkan daftar berikut:
Selain itu, Anda dapat kembali ke awal pengujian saya dan memeriksa kualitas RTT (mungkin pelanggan memiliki masalah dengan router Wi-Fi-nya).
Selanjutnya informasi ini dapat ditransfer ke pemasaran, pusat panggilan, mereka tahu apa yang harus dilakukan. Paling tidak, mereka akan berkomunikasi dengan pelanggan tentang kepuasan mereka dengan kualitas layanan kami.
Log koneksi
Ada fungsi log koneksi yang dengannya Anda dapat menentukan berapa banyak alamat virtual di belakang satu alamat asli.
Faktanya, grafik ini menunjukkan kepadatan penyedia NAT. Grafik ini menunjukkan bahwa NAT masih dapat dipadatkan.
Log DPI
Di sini Anda dapat melihat otonomi TOP, aplikasi.
Anda dapat melihat aplikasi spesifik dalam konteks kualitas komunikasi, dan dari mana otonomi mengalir, misalnya, Dunia tank:
Tidak ada yang tidak biasa: ini dituangkan dengan GCORE, tidak ada rem yang sebenarnya.
Anda dapat pergi ke GCORE mandiri dan melihat apa lagi yang dituangkan dari kami di dalamnya:
Anda juga dapat membuat filter yang menarik. Misalnya, tampilkan Rusia AS dengan penundaan lebih dari 16 ms.
Dengan kata lain, Anda bisa memahami ke mana peering melewati Barat
Akibatnya, kami mendapatkan daftar AS:
Hasilnya:
Untuk tugas saya, secara umum, produk ini cocok, karena tanpa banyak kesulitan saya bisa menemukan semua pelanggan bermasalah dengan RTT lebih besar dari 4-5 c, menunjukkan alasannya (kabel putus, virus, dll.) Dan menunjukkan area "masalah" - menunjukkan pelanggan jalan dan IP - menunjukkan . Saya juga ingin mencatat fitur yang berguna - pencarian pelanggan yang sudah mempertimbangkan pelarian mereka ke pesaing.
Apa yang ingin saya lihat dalam versi produk yang akan datang adalah otomatisasi. Artinya, di sini sistem menemukan pelanggan yang sudah mulai mengunjungi situs web pesaing, akan lebih nyaman bagi saya untuk menerima pemberitahuan melalui surat tentang peristiwa semacam itu.
Dalam hal otomatisasi, akan lebih mudah jika kita dapat berintegrasi dengan VoIP kami, sehingga dalam hal RTT "mengerikan" di pelanggan, pusat panggilan kami akan secara otomatis memanggil klien tersebut sesuai dengan skenario yang telah ditentukan.
Tetapi untuk saat ini, kami, sebagai penyedia, harus menyelesaikan masalah arus keluar pelanggan sehubungan dengan layanan dukungan dan pusat panggilan dalam mode manual atau semi-manual. Dalam waktu dekat kami ingin beralih dari pengujian ke implementasi.
PS: Jika itu menarik, saya dapat berbicara tentang bagaimana kami bekerja dengan pelanggan yang ingin melarikan diri ke pesaing. Dan juga tentang bagaimana kami akan mengintegrasikan produk ini ke jaringan kami.
Secara umum, tulis komentar yang mana dari topik ini yang ingin Anda lihat sebagai artikel berikutnya, dan saya akan mengirim materi ke editor situs - mungkin mereka akan setuju untuk mempublikasikan kreasi saya.