私は現在、2 つの別個のニュースレター データベースを持っています。1 つは簡単なオプトインで、メール アドレスを入力するだけでメールを受け取ることができます。もう 1 つは、本格的な顧客アカウント データベース (ユーザー名、パスワード、住所、注文履歴など) です。どちらも基本的に同じニュースレターを受け取ることになります (可能な場合は、いくつかのセグメンテーションと動的なコンテンツを行います)。さらに、オプトイン テーブルには、さまざまなマーケティング イニシアチブが連絡先に関するデータを収集した 1 回限りの列があることに注意してください (連絡先が [オンライン/オフライン] に登録された場所と、それがどのプロモーションに属していたか、連絡先の場合は郵送先住所)。持っているなど）。
私はこの 2 つのリストを何年もセットアップしてきましたが、顧客が単純なオプトインからアカウントの作成、電子メール アドレスの更新などに移行するにつれて、管理がますます難しくなっています。アカウントからニュースレターの設定を管理するのは理にかなっています。しかし、既存の顧客がオプトインに電子メール アドレスを入力する (またはその逆) 場合があり、重複の管理が複雑になることがあります。また、2 つのデータベース間で多くの重複データを処理する必要があります (テーブルだけでなく、複数のデータベースにまたがるのは困難です)。
複雑なことに加えて、サードパーティのサービスを使用してニュースレターを送信しています。頻繁に実行され、双方向の同期を行うプロセスがいくつかあります。そのため、どのデータベースから変更をプル/プッシュするか、どのソースが最後に更新されたかなどを判断するために、毎回ジャグリングを行う必要があります。連絡先がオプトイン リストから顧客リストに移動している場合、変更をプッシュし、古い関係を無効にする必要があります。彼らがオプトインに自分自身を追加し、他のデータベースに既に電子メールがある場合、それらを無視するようにフラグを設定します-それはすべて頭痛の種です.
今、これはかなり一般的な状況でなければなりません。私がアクセスするほぼすべての e コマース サイトには、このような異なるリストが少なくとも 2 つあります。私の質問は、彼らがそれをどのように扱っているかです。ベストプラクティスは何ですか?
私の見方では、次の 2 つのオプションがあります。
同じデータベースで 2 つの異なるテーブルを使用します (これは、私が現在行っている方法にかなり近いものです)。これにより、物事を分離して整理し続けることができますが、競合/重複する情報について同時に両方のリストを効率的にチェックできます. 私はまだ同じ問題の多くを抱えています (関係の移動または「マスター レコード」の定義、重複データ、変更の伝達など) が、少なくともいくつかのことを簡素化する必要があります。
すべての連絡先が共有する単一のテーブル (NewsletterContacts などと呼びます) を作成します。オプトイン ユーザーはおそらく直接追加されますが、顧客アカウント テーブルのエントリは同期する必要があります。ただし、これにも多くの欠点があります。顧客アカウント テーブルへの変更は、メール ソフトウェアにプッシュする前に NewsletterContacts にプッシュする必要があります。そのデータベースには非常に複雑なコンテンツが含まれていました。一部のレコードには住所やソースなどがあり、他のレコードには電子メール アドレスだけがあり、他のレコードには他のすべての種類の情報が含まれる顧客アカウント テーブルが示されていました。 .
TL,DR:重複することがわかっている場合、2 つの別々のニュースレター リストをどのように管理しますか?