Secara umum, orang tidak suka menerima email yang tidak diminta. Namun demikian, mereka terkadang berlangganan buletin untuk mendapatkan diskon atau mengikuti perkembangan produk baru. Artikel ini akan menyajikan satu pendekatan untuk merancang database buletin.
Mengapa Khawatir Tentang Email Buletin?
Pelanggan buletin mewakili kelompok klien yang sangat berharga – mereka tertarik dengan produk kami, mereka mempercayai kami, dan mereka menghabiskan waktu untuk meninjau penawaran dan promosi kami. Terlebih lagi, mengirim email ke klien adalah salah satu alat termurah dalam pemasaran online. Namun, ini perlu dilakukan dengan hati-hati – data harus diperbarui setiap hari (karena orang berlangganan dan berhenti berlangganan) dan berkualitas tinggi (kami tidak ingin mengirim email yang tidak diinginkan, karena berdampak negatif pada citra merek).
Jadi timbul pertanyaan tentang bagaimana mengelola proses ini untuk mendapatkan data berkualitas dan memperbaruinya setiap hari. Ada banyak pilihan ...
Dan Pemenangnya adalah...
Analisis pelanggan! Saat ini, faktor terpenting untuk tetap menjadi yang terdepan dalam persaingan adalah menemukan wawasan dari data dan membuat keputusan bisnis atas dasar itu. Bukankah lebih bagus untuk melihat sejarah pengiriman buletin dan menganalisis intensitas dan efektivitasnya? Untuk setiap pelanggan? Dan kemudian menggabungkannya dengan data pembelian, mengungkap minat pelanggan, menyiapkan rekomendasi individu, dan mengirimkannya menggunakan email yang dipersonalisasi?
Pendekatan seperti itu pasti akan meningkatkan tingkat konversi (CR) kami. Tingkat konversi adalah salah satu indikator kinerja utama pemasaran online yang paling penting; ini menunjukkan berapa banyak orang yang melakukan pembelian setelah melihat beberapa materi promosi kami (iklan, buletin, dll). CR yang tinggi berarti peningkatan efektivitas bisnis.
Sekarang setelah kita memahami beberapa pemasaran yang terlibat, mari masuk ke model data!
Mari Mulai Membuat Model Database Buletin!
Menggali lebih dalam, kita melihat bahwa dua tabel utama dalam model adalah client dan newsletter tabel.
Karena kami sebagian besar akan tertarik pada analisis klien, client tabel harus tetap berada di tengah model. Dalam tabel ini, setiap klien memiliki id unik mereka sendiri . Kami juga akan menyimpan informasi seperti first_name klien dan last_name , informasi kontak (email , phone_number , alamat jalan), birthday , create_date (ketika catatan pelanggan dimasukkan ke dalam database) dan source_id mereka – yaitu apakah mereka terdaftar di situs kami atau beberapa mitra bisnis memberikan data mereka kepada kami.
newsletter tabel menyimpan data tentang setiap pembuatan buletin. Buletin dapat diidentifikasi berdasarkan id uniknya . Masing-masing dijelaskan dengan name (mis. “Koleksi pakaian wanita baru – Musim Gugur 2016”), email subject (“Pakaian paling modis untuknya – beli sekarang!”), html_file (file yang berisi kode HTML untuk buletin tertentu), type buletin (mis. “koleksi baru”, “buletin ulang tahun”) dan create_date .
Persetujuan Pemasaran
Untuk mengirimkan informasi pemasaran (melalui pos, telepon, email atau SMS), perusahaan perlu mendapatkan persetujuan dari pelanggan mereka. Dalam model kami, persetujuan disimpan dalam tabel terpisah bernama marketing_consent . Itu menyimpan informasi tentang kumpulan persetujuan pemasaran saat ini untuk semua pelanggan kami. Persetujuan dikodekan sebagai variabel boolean – TRUE (setuju dengan komunikasi pemasaran) atau FALSE (tidak setuju).
Sangat penting untuk menyimpan informasi mengenai kapan pelanggan setuju untuk menerima iklan melalui setiap saluran komunikasi. Juga bermanfaat untuk merekam saat mereka menarik persetujuan mereka untuk setiap saluran. Untuk tujuan tersebut, consent_change tabel dirancang.
Setiap perubahan memiliki id yang unik dan ditugaskan ke klien tertentu oleh client_id mereka . Saat klien meminta untuk dihapus dari email buletin, buletin id dari channel tabel juga akan disimpan di consent_change channel_id tabel atribut. new_consent atribut adalah nilai boolean (BENAR atau SALAH) dan mewakili persetujuan pemasaran baru.
update_date kolom berisi tanggal saat pelanggan meminta perubahan. Struktur ini memungkinkan kami untuk mengekstrak satu set persetujuan untuk semua klien pada hari tertentu. Ini sangat berguna jika klien mengeluh tentang menerima email setelah mereka berhenti berlangganan buletin kami. Dengan informasi ini di file, kami dapat memeriksa kapan berhenti berlangganan terjadi dan mudah-mudahan mengonfirmasi hal ini dilakukan setelah buletin email dikirim.
Menjaga agar Pengiriman Tetap Teratur
Merancang model basis data yang sempurna untuk pengiriman buletin bukanlah hal yang mudah. Mengapa? Yah, jelas kita harus dapat mengidentifikasi setiap pembuatan buletin tunggal (artinya tata letak, grafik, produk, tautan, dll). Kita juga tahu bahwa satu kreasi dapat dikirim beberapa kali:manajer dapat memutuskan bahwa satu ember email akan dikirim di pagi hari ke separuh klien dan di malam hari ke separuh lainnya. Jadi, sangat penting untuk mencatat klien mana yang menerima buletin mana dan kapan. Inilah sebabnya mengapa bagian model ini terdiri dari tiga tabel:
newslettertabel – yang telah kami jelaskan sebelumnya.newsletter_sendouttabel – yang mengidentifikasi satu pengiriman. Misalnya, buletin Natal (id =“2512”) dikirim melalui email pada tanggal 10 Desember pukul 6 sore. Pencatatan ini memungkinkan pemasar mengirim buletin yang sama ke kelompok pelanggan yang berbeda pada waktu yang berbeda.sendout_receiverstabel – yang mengumpulkan data tentang penerima dari setiap pengiriman. Akan ada satu record untuk setiap email dari setiap pengiriman. Setiap baris memiliki tiga kolom:id(mengidentifikasi peristiwa pengiriman email ke klien),client_id(mengidentifikasi klien dari database kami) dannl_sendout_id(mengidentifikasi pengiriman buletin).
Inilah Model Buletin Lengkapnya:
Ada ide tentang cara meningkatkan model ini?
Salah satu cara yang mungkin adalah menambahkan response meja. Ini akan menyimpan reaksi pelanggan – apakah mereka membuka email, mengklik iklan, atau tidak pernah melihat pesan karena ditandai sebagai spam. Di mana kita harus menambahkan response tabel ke model kita dan relasi mana yang harus diterapkan? Bagikan pemikiran Anda di bagian komentar di bawah.
