施策実施に必要な情報を収集する難しさ
自力で8カラムを揃えようとすると、多くの工程をたどる必要がある。
A社のシステムでは、資料を請求した顧客には「顧客ID」が振られ、口座を開設すると「口座ID」にもデータが入る。そこにフラグを立てて「口座IDが入っていない人＝まだ口座登録がなされていない人」を抽出する。さらに「資料請求データ」には「資料請求日時」が複数履歴管理されているため、その中から最新のものを絞り込んでフラグを立て、その日付から経過日数を集計する。こうして「口座IDが入っていない人」と「最新の資料請求から4日たった人」のデータを抽出し、顧客IDによって統合する。さらに「アクセスログデータ」の「サイトアクセス日時」から最新のデータを抽出し、さらにそこから経過日数を算出する。これもまた顧客IDで統合して10工程、ここでようやく必要な8カラムが揃うというわけだ。
このタスクを行うためには、加工用SQLと統合用SQLが必要となり、それを準備するにはSQLが使えるエンジニアの稼働が必須になる。しかしながら、A社のマーケティング部門にはSQLを扱える人がいなかったため、外部に依頼をする必要があった。情報システム部門の社内エンジニアに施策のためのデータ作成を依頼したところ、エンジニアはWebサイトの改修など他タスクを優先していたため、施策の準備にあてられる工数は限定的だった。結果、施策の実現に必要なデータが作られず、施策の実施ができなかったというわけだ。
そこで、社内エンジニアに頼らずマーケターが自ら手を動かして施策のためのデータ作成ができるよう、ノーコードかつGUIでのデータの加工／統合ができる「b→dash」の導入が決定された。
