社内システムを理解している情シスだからこそできることがある
筆者がよく目にする具体例を挙げると、「クロスデバイスでの顧客識別と顧客体験の提供」の議論がある。
「顧客識別」の段階では、ファーストパーティCookieの扱いが頻繁に論点になる。既知の通り、現在はJavaScriptを利用したウェブサービスの種類が多く、自社のウェブサイトやモバイルサイトに複数のウェブサービスを導入していることが通常である。
また、今の消費者はスマートフォンなどのモバイル端末を含め、複数のデバイスでインターネットを利用することがすでに主流となっていることから、「顧客の利用するデバイスをまたがって、一貫した顧客体験を提供する」ためにどうするかという検討を進めている企業も多い。
消費者の立場に立てば、ある企業のPC向けサイトでは、「あなたにはAがおすすめ」と言われ、同じ企業のモバイルサイトでは「あなたにはBがおすすめ」と言われることは、決して「良い顧客体験」とは言えないし、そんな企業のおすすめは信用できない。
さて、このような状況下で、パッケージアプリケーションのベンダーが業務部門に提示する顧客識別の解決策は「（そのベンダーが提供する）○○ツールがセットするCookieを利用して対応しましょう」というものが往々にして多い。
Cookieの発行と読み込みが、あたかもそのベンダーが提供している特定の製品でしかできないような考え方に基づいた解決策だ。
（本連載の読者には釈迦に説法だが）もともとCookieは、インターネット利用者の利便性を高めるためにウェブアプリケーションサーバで自由に発行、読み込みできる技術である。にも関わらずこのような提案をすることが多いのだ。これは、決して最適解とは言えない。
もしこの場に情シス部門がいれば、自社で発行するCookieは当然ファーストパーティたり得るため、業務部門側では思いつかない選択肢をいとも簡単にこの場面で提示できるはずだ。
さらに、「顧客識別」のために自社で発行するCookieであれば、その読み込みは、そのチャネル（顧客接点）が定める利用規約の範囲において自由である。
そして、「顧客理解」という分析段階においては、Cookie内のIDと顧客IDや名寄せIDを紐づけるためにわざわざ外部ベンダー側のデータ保管領域にデータを飛ばさずとも、自社内の分析環境で自由に紐付けして分析が行える。元々ファイアウォールの中でのデータの扱いは、情シス部門が得意とする守備範囲である。
また、「顧客とのコミュニケーション」においても、情シス部門がデータを活用し攻めに転じられるシーンがある。
いざ実行する、という段階だ。
