会員統合（顧客統合）について(後編）
会員統合の後編です。
前回は会員情報の分類分け７種と、４つの統合ルールを説明しました。
後編は、分類７種と４つの統合ルールの紐付けを解説いたします。
結論
1.基本情報：イ．選択
2.拡張情報：イ．選択
3.従属情報：ロ．付替 or 二．対象外
4.履歴情報：ロ．付替 or 二．対象外
5.サマリ情報：ハ．再計算
6.ログ情報：ロ．付替 or 二．対象外
7.高揮発性情報：二．対象外
解説
1.基本情報：イ．選択
2.拡張情報：イ．選択
1.基本情報と2.拡張情報の一部は、顧客自身が企業を利用する前からの固有情報で、必然と機微な情報、個人情報となると前回説明しました。システム側ではどちらを選択するか判断できない情報です。
理想的なのは、将来を見越して、特定のDBには機微な情報を集めておくようにすると、セキュリティ対策も簡略化できると考えます。特定のDBのみ防御を高くする設計をする事が可能になります。
3.従属情報：ロ．付替 or ハ．再計算 or 二．対象外
4.履歴情報：ロ．付替 or ハ．再計算 or 二．対象外
逆に、企業を利用した後に発生するような、会員と1:nで紐づく情報は、基本「ロ．付替」になります。企業内のルールに則って付与された情報なので、顧客に選択権を与えると「煩わしい」印象を与える事になります。ルールに則って統合すべきです。
但し、従属・履歴情報の中には、単純な付替で解決できない情報が含まれます。分かりやすいのは、会員のセグメント情報です。会員情報を統合する事により、企業が顧客を評価する度合いが変化する事もあるからです。この場合はハ．再計算が正解です。
逆にクレーム情報といったネガティブ情報については、単純な付替ができない情報です。クレーム度合いの強い方を残すのか、クレームのメモはどう統合するのか、イレギュラー処理が必要な情報は、二．対象外で、個別処理を組むべきです。
5.サマリ情報：ハ．再計算
サマリ処理はほぼ「ハ．再計算」が正解です。サマリ処理の場合はきちんと名寄せが出来ていれば、後は計算リソースの問題となるだけですが、名寄せの問題が解決できていない場合は問題です。例えば、事業所・エリア間で同じ顧客を異なるIDで管理していて、同じ顧客として認識できない問題です。これは別のテーマとして近日中に扱う予定です。
6.ログ情報：ロ．付替 or 二．対象外
ログは情報の種類によって仕分けが必要です。顧客が自身の個人情報をどのように変更したか、などといったログ程度であれば二．対象外で統合元のログを削除して、統合先のログに、今回の統合情報を追加すればいいだけです。逆に顧客のWeb行動分析に用いるログであれば、ロ．の付替が適切です。
7.高揮発性情報：二．対象外
これは説明不要でしょう。セッション情報等は統合不要です。
まとめ
書いていて難しいと感じた所は、BtoBの業種とBtoCの業種では、顧客統合の問題課題が異なる事です。どちらかというとB to Bが難しいと考えます。
何故ならば、B to Bの場合、企業が顧客の情報をSFAなどで蓄積した事があったとします。これは、完全に企業側が溜めた情報であり、企業の責任において名寄せ、統合が必要になります。責任もリソースも全て企業が担うのです。私が従事する現場においても、B to C案件は名寄せが、ユーザ要求として発生、優先課題として挙げられます。
逆にB to Cは、Cに当たる顧客が、Webを通じて顧客情報を入力するシーンが多い為、統合の責任は、一部Cである顧客が担う部分があります。企業は勝手に名寄せし、どちらを残すか判断できない、いや判断しなくとも良いのです。B to C企業は「顧客を勝手に統合できない」を前提として、１つのシステムに１人の顧客が複数のIDを持つ事を容認します。顧客が自分の情報が分かれている事に不利益を感じた時に統合できるルール作りが優先される課題です。
共通する事は、顧客がBであってもCであっても、顧客の不利益にならない統合ルール作りを前提として、統合ルールの方針作りを定めていくべきでしょう。
以上です。有難うございます。
おまけは、新千歳空港３階フードコートに出来た「まつじん」
リーズナブルにソウルフードを頂ける店です。
