一般的に、人々は迷惑メールを受信することを好みません。それにもかかわらず、彼らは割引を受けたり、新製品を最新に保つためにニュースレターを購読することがあります。この記事では、ニュースレターデータベースを設計するための1つのアプローチを紹介します。
ニュースレターのメールが気になる理由
ニュースレターの購読者は、非常に価値のあるクライアントのグループを表しています。彼らは私たちの製品に興味を持っており、私たちを信頼しており、私たちのオファーやプロモーションのレビューに時間を費やしています。さらに、クライアントに電子メールを送信することは、オンラインマーケティングで最も安価なツールの1つです。ただし、慎重に行う必要があります。データは毎日更新する必要があり（ユーザーが登録および登録解除するため）、高品質である必要があります（ブランドイメージに悪影響を与えるため、不要なメールを送信したくない）。
したがって、高品質のデータを取得して毎日更新するこのプロセスをどのように管理するかという疑問が生じます。たくさんのオプションがあります...
そして勝者は...
顧客分析！今日、競合他社に先んじる上で最も重要な要素は、データから洞察を見つけ、それに基づいてビジネス上の意思決定を行うことです。ニュースレターの送信履歴を調べて、その強度と有効性を分析するのは素晴らしいことではないでしょうか。顧客ごとに？次に、購入データに参加し、顧客の興味を明らかにし、個別の推奨事項を準備し、パーソナライズされた電子メールを使用してこれらを送信しますか？
そのようなアプローチは確かに私たちのコンバージョン率（CR）を上げるでしょう。コンバージョン率は、最も重要なオンラインマーケティングの主要業績評価指標の1つです。販促資料（広告、ニュースレターなど）を見た後、何人の人が購入したかを示しています。 CRが高いということは、ビジネスの有効性が高まることを意味します。
関連するマーケティングの一部を理解したので、データモデルに取り掛かりましょう！
ニュースレターデータベースのモデリングを始めましょう！
掘り下げてみると、モデルの2つのメインテーブルがclient およびnewsletter テーブル。
主にクライアント分析に関心があるため、client テーブルはモデルの中心にとどまる必要があります。この表では、各クライアントに固有のidがあります。 。クライアントのfirst_nameなどの情報も保存します およびlast_name 、連絡先情報（email 、phone_number 、番地）、birthday 、create_date （顧客のレコードがデータベースに入力されたとき）およびそのsource_id –つまり、彼らが私たちのサイトに登録したか、ビジネスパートナーが私たちにデータを提供したかどうか。
newsletter テーブルには、すべてのニュースレターの作成に関するデータが格納されます。ニュースレターは、固有のidに基づいて識別できます。 。それぞれがnameで記述されています （例：「新しい婦人服コレクション– 2016年秋」）、メールでsubject （「彼女にとって最もファッショナブルな服–今すぐ購入！」）、html_file （その特定のニュースレターのHTMLコードを含むファイル）、ニュースレターのtype （例：「新しいコレクション」、「誕生日のニュースレター」）およびcreate_date 。
マーケティングの同意
マーケティング情報を（郵便、電話、電子メール、またはSMSで）送信するには、企業は顧客の同意を得る必要があります。このモデルでは、同意はmarketing_consent 。これは、すべてのお客様の現在の一連のマーケティング同意に関する情報を保持します。同意はブール変数としてコード化されます– TRUE（マーケティングコミュニケーションに同意する）またはFALSE（同意しない）。
顧客が各通信チャネルを介して広告を受け取ることに同意した時期に関する情報を保存することは非常に重要です。また、各チャネルの同意を撤回した時期を記録することも有益です。そのような目的のために、consent_change テーブルが設計されました。
各変更には一意のidがあります client_idによって特定のクライアントに割り当てられます 。クライアントがニュースレターのメールからの削除をリクエストすると、ニュースレターのid channel テーブルはconsent_change テーブルのchannel_id 属性。 new_consent 属性はブール値（TRUEまたはFALSE）であり、新しいマーケティング同意を表します。
update_date 列には、顧客が変更を要求した日付が保持されます。この構造により、特定の日にすべてのクライアントの一連の同意を抽出できます。ニュースレターの購読を解除した後、クライアントが電子メールの受信について不満を言った場合に非常に役立ちます。この情報をファイルに保存しておくと、購読解除がいつ行われたかを確認でき、メールマガジンの送信後にこれが行われたことを確認できます。
発送を整理する
ニュースレターの送信に最適なデータベースモデルを設計するのは簡単なことではありません。なんで？もちろん、単一のニュースレターの作成（レイアウト、グラフィック、製品、リンクなど）を識別できる必要があります。また、1つの作品を複数回送信できることもわかっています。マネージャーは、1バケットの電子メールを午前中にクライアントの半分に送信し、夕方に残りの半分に送信することを決定する場合があります。したがって、どのクライアントがどのニュースレターをいつ受信したかを記録することが重要です。これが、モデルのこの部分が3つのテーブルで構成されている理由です。
newsletter表–前に説明しました。-
newsletter_sendoutテーブル–単一の送信を識別します。たとえば、クリスマスニュースレター（ id =“ 2512”）は、12月10日の午後6時にメールで送信されました。この記録管理により、マーケターは同じニュースレターを別々の顧客グループに異なる時間に送信できます。 -
sendout_receiversテーブル–各送信の受信者に関するデータを収集します。各送信からの電子メールごとに1つのレコードがあります。各行には3つの列があります：id（クライアントに電子メールを送信するイベントを識別します）、client_id（データベースからクライアントを識別します）およびnl_sendout_id（ニュースレターの送信を識別します。）
完全なニュースレターモデルは次のとおりです：
このモデルを改善する方法について何かアイデアはありますか？
考えられる1つの方法は、response テーブル。これにより、電子メールを開いた、広告をクリックした、またはスパムとしてマークされたためにメッセージが表示されなかったなど、顧客の反応が保存されます。 response 私たちのモデルへのテーブルとどの関係を適用する必要がありますか？以下のコメントセクションであなたの考えを共有してください。