今回はSalesforceのAIであるEinstein Discoveryを使ってレコメンデーションエンジンを作ってみます。
リコメンドのビジネス適用
言うまでもなくレコメンドは生活の一部です。我々の周りはレコメンドに満ちています。みなさんもAmazonやNetflixでおすすめされるサービスを元に購入判断している機会も多いと思います（私は多いです）
実際のビジネスでリコメンドを利用していますか？
リコメンド機能を実装するにはそれなりの開発が必要になることが多いのでプロジェクトが必要です。
しかしEinstein Discoveryを使えばノーコーディングです。時間も手間も圧倒的にかかりませんのでこれを機に実際のみなさんのビジネスにおすすめを適用してみましょう！
Salesforceでのリコメンド利用
Salesforceのユーザーは営業部門やサービス部門の利用者が多いです。
ベテラン営業の方が顧客にどの製品を提案すればニーズがあるのか暗黙的に判断できます。
また、フィールドサービスにおいて経験のある方は、製品と兆候の組み合わせで携行する部品を選択できますので一次解決率高いです。
上記の例は、どちらもAIの予測を使っておすすめを表示することで業務改善ができそうです。
- 顧客の属性や過去の取引状況から、次に買う製品を予測する
- 製品と故障箇所、兆候から故障箇所を予測する
ことにより、従業員の作業効率が向上できそうです。
Einstein Discoveryでのおすすめ予測
Discoveryを使っておすすめするにはちょっと工夫が必要になります。
なぜならDisocoveryが予測の目的にできるのは数値項目もしくはバイナリ項目（Yes/Noなどの２項目)である必要があり、製品のように複数カテゴリがある項目を目的とすることができないからです。
Einstein Discovery使用事例の定義
https://help.salesforce.com/articleView?id=sf.bi_edd_plan.htm&type=5
どの結果 (KPI など) を探索する必要があるか?
Einstein Discovery は、継続的な結果 (基準) またはバイナリの結果 (2 値テキスト) に
関連したパターンを検出します。
予測できるパターン
どのようなデータ形式だと予測できるのか、見てみましょう！
予測できる場合の例
🚢 タイタニック号の乗客データ
タイタニック号の乗客データから「生存フラグ」を予測することはできます。
「生存フラグ」が「生存」と「死亡」の２種類、バイナリ項目のため目的に使用することができます。
| 生存フラグ | 乗客クラス | 性別 | 年齢 |
|---|---|---|---|
| 死亡 | ロウワークラス | 男性 | 22 |
| 生存 | アッパークラス | 女性 | 38 |
| 生存 | ロウワークラス | 女性 | 26 |
| 生存 | アッパークラス | 女性 | 35 |
| 死亡 | ロウワークラス | 男性 | 35 |
予測できない場合の例
🏬 購買データから購買製品の予測
企業属性から売れる製品を導こうとしても、「購買製品」には３種類以上の項目があるため、バイナリ項目ではないです。そのため予測できません。
| 購買製品 | セグメント | 業種 | 従業員数 | 売上 | 顧客ID |
|---|---|---|---|---|---|
| セキュリティ管理 | A | 金融 | 1000 | 100000 | A-Company |
| ドキュメント管理 | B | 製造 | 1800 | 50000 | B-Company |
| コミュニケーション連携 | C | 不動産 | 30 | 3000 | C-Company |
| ドキュメント管理 | B | 製造 | 300 | 45000 | D-Company |
| ドキュメント管理 | C | 建設 | 2000 | 120000 | E-Company |
予測できるようにデータ変換
売れる製品を予測したいのですが、「購買製品」はバイナリではないので予測できないのが問題でした。
ならばデータ変換してバイナリにしましょう！「ドキュメント管理」を追加しました。これならどうでしょうか？
| ドキュメント管理 | 購買製品 | セグメント | 業種 | 従業員数 | 売上 | 顧客ID |
|---|---|---|---|---|---|---|
| No | セキュリティ管理 | A | 金融 | 1000 | 100000 | A-Company |
| Yes | ドキュメント管理 | B | 製造 | 1800 | 50000 | B-Company |
| No | コミュニケーション連携 | C | 不動産 | 30 | 3000 | D-Company |
| Yes | ドキュメント管理 | B | 製造 | 300 | 45000 | D-Company |
| Yes | ドキュメント管理 | C | 建設 | 2000 | 120000 | E-Company |
これではドキュメント管理が売れた顧客に対して「Yes/No」でフラグづけしていますのでバイナリ項目です。
これなら問題なく予測できます。やった！！
複数製品問題
しかし、このデータでできるのは「ドキュメント管理が売れるか？」という予測になってしまいます。
ドキュメント管理以外の製品予測はできません。
もちろん他の製品も予測したいですよね。その場合、製品の数だけ予測が必要になり運用が結構ハードになります。製品追加の度に予測もメンテが必要になり、おすすめしません。
製品と顧客をクロスで縦変換してみた
ではこの形ではどうでしょうか？顧客x製品分のデータを用意しました。
| 購買フラグ | 顧客ID | 製品 | セグメント | 業種 | 従業員数 | 売上 |
|---|---|---|---|---|---|---|
| Yes | A-Company | セキュリティ管理 | A | 金融 | 1000 | 100000 |
| No | A-Company | ドキュメント管理 | A | 金融 | 1000 | 100000 |
| No | A-Company | コミュニケーション連携 | A | 金融 | 1000 | 100000 |
| No | D-Company | セキュリティ管理 | C | 不動産 | 30 | 3000 |
| Yes | D-Company | ドキュメント管理 | C | 不動産 | 30 | 3000 |
| No | D-Company | コミュニケーション連携 | C | 不動産 | 30 | 3000 |
これなら製品と顧客IDごとに一行になっているため、相性の良い製品と顧客属性を予測できます。
一つのストーリで複数製品の売れる度合いを予測できるので顧客に対してどの製品が相性が良いか、一覧表示できますね。
データ変換方法
ちなみにこの形にするのはちょっと手間がかかりそうです。Tableau Prepを使うと便利です。
手順としては
- 顧客IDと製品でのマトリックステーブルを作成
- 顧客IDと製品を含む購買履歴データを取得
- １と２をJoinしてフラグ付する
流れになります。
Tableau Prepを利用したクロスデータ作成方法はこちらの記事も参考にしてください
注意点
- 顧客x製品分の行数が発生するので、それなりのデータ量になります。BtoCとかだときついかもしれません。。。
- シングルモデルで全部の製品をレコメンドするのは精度が出ない可能性もありますので、実務的にはいくつかのカテゴリ別に予測した方が良い結果が得られると思います。
- Discoveryは項目カテゴリ１００を越える場合は「その他」に丸められてしまいます。製品種類などが多い場合は、製品カテゴリレベルで予測するなどの工夫が必要です。
ストーリー作成
データができたらストーリーを作成してみます。
今回は、顧客属性として「セグメント・業種・従業員数・売上」がありますが、実際には社内で設定した想定シェアや営業ポテンシャルなどのデータも組み込むとより正確な予測ができるようになります。
ストーリでの注意点
今回の製品x顧客マトリックスでのデータ形式を作成した場合「購買フラグ」のYesとNoの割合はかなり偏りがある可能性が高いです。製品が100種類存在し、顧客企業が平均して５つの製品を購入している場合だと95％の確率でNoになります。
このような場合モデルは作成されますが閾値コントロールにより全てNoと予測されることがあるので注意してください。
AIからしてみれば全部Noと予測すれば９５％の確率で正解するので、最適な答えであることは理解できるのですが、おすすめしてもらいたい立場からすれば「全部No」だと意味がないです。
閾値設定
Discoveryでは閾値のコントロールができるので、混合行列を確認しつつ「予測-肯定」にある程度の割合に入るように設定しましょう。
予測用のデータの作成
モデルができたので、予測に入ります。モデルのInputが顧客属性と製品のマトリックスだったので、予測データも同様のフォーマットを用意し、「予測購買フラグ」を付与してもらいます。
予測用データ作成の方法もモデルデータ作成時と同様の手順となります。
顧客データと製品データを元にJoinして作成します。
今回は新たな顧客X-CompanyとZ-Companyに対しておすすめをしてもらおうと思います。
| 顧客ID | 製品 | セグメント | 業種 | 従業員数 | 売上 |
|---|---|---|---|---|---|
| X-Company | セキュリティ管理 | A | 建築 | 1000 | 160000 |
| X-Company | ドキュメント管理 | A | 建築 | 1000 | 160000 |
| X-Company | コミュニケーション連携 | A | 建築 | 1000 | 160000 |
| Z-Company | セキュリティ管理 | C | 製造 | 130 | 3000 |
| Z-Company | ドキュメント管理 | C | 製造 | 130 | 3000 |
| Z-Company | コミュニケーション連携 | C | 製造 | 130 | 3000 |
レシピで予測
このデータをデータセットとして保存したらレシピで予測を付与します。
予測結果ですが、顧客ベースで分析しても良いですし、製品ベースで分析するのにも使えます。
例えば顧客画面に埋め込んで使用すると、該当顧客にフィット度の高い製品をおすすめしてくれますし、レシピではおすすめ理由も表示されるので納得度が高いです。
まとめ
いかがだったでしょうか？ノーコーディングではありますが、データ変換のあたりのハードルは少々高い感はあるかと思います。
しかし、手順を把握してしまえばビジネスユーザーの方でも実装できるレベルだと思っています。
みなさんも是非ビジネスにレコメンドを実装して業務効率を向上しましょう！