2017/09/27に開催した 「レバレジーズ x ビズリーチ」マーケツール連携の裏側全部語ります。で使用したスライドです。

1. BizReach x Marketo連携

2. # 大内 允介（おおうち まさゆき）
# 株式会社ビズリーチ
# カスタマーサクセスグループ エンジニア リーダー
# 愛知県名古屋市出身
# 工学部 応用理工学
# 2015年10月 ビズリーチ入社
# 前職はSIerで社内システムの開発
自己紹介

3. 自己紹介
名刺を忘れる大失態...。
後ほど個別にお話させてください

4. # BizReach x Marketo連携
# Marketoのリード登録/更新
- 課題
- 解決策
# Marketoのリードトラッキング
- 課題
- 解決策
# Marketo連携での失敗談
Agenda

5. ・求人紹介メール
・その他一括メール
BizreachとMarketoの関係
Amazon SES
求職者
・メールマガジン
・CRMメール
・フィジビリ施策系
Amazon RDS
Amazon EC2
Amazon EC2
Marketoと既存のメールシステムを組み合わせてメール送信している。

6. なんでMarketoだけにしないの？

7. ・求人紹介メール
・その他一括メール
BizreachとMarketoの関係
Amazon SES
求職者
・メールマガジン
・CRMメール
・フィジビリ施策系
Amazon RDS
Amazon EC2
Amazon EC2
求職者（リード）に紐付くデータでセグメントする
場合はMarketoは大得意！
CRMメールや個人の属性に沿ったメールは
Marketoから送信するようリプレイス

8. ・求人紹介メール
・その他一括メール
BizreachとMarketoの関係
Amazon SES
求職者
・メールマガジン
・CRMメール
・フィジビリ施策系
Amazon RDS
Amazon EC2
Amazon EC2
求人の情報など、求職者（リード）に紐付かない
データはMarketoには連携しづらい。
求人のレコメンドメールなどは
既存のメールシステムをそのまま利用。

9. ・求人紹介メール
・その他一括メール
BizreachとMarketoの関係
Amazon SES
求職者
・メールマガジン
・CRMメール
・フィジビリ施策系
Amazon RDS
Amazon EC2
Amazon EC2
本日はここを話します！

10. Marketo連携
REST API Munchkin API (JavaScript)
リードの登録/更新だけでなく様々な機能 Cookie情報とリードの紐付け
任意のField（会員IDなど）で連携可能 メールアドレスでのみ連携可能
リクエスト数上限あり（ 50,000 / 日） 上限なし
Marketo連携でまずやることはリードの登録更新とリードトラッキング！
REST API と Munchkin API (JavaScript)を利用します。

11. Marketoのリード登録/更新

12. 会員登録 リード登録
「求職者情報」をAPIでMarketoに連携し、リードを登録・更新する。
退会
リード更新
レジュメ更新
リード更新
REST API によるMarketo連携
リード削除
ID: 100
ID: 100
ID: 100

13. 会員登録 リード登録
退会
リード更新
レジュメ更新
リード更新
REST API によるMarketo連携
リード削除
ID: 100
ID: 100
ID: 100
「求職者情報」を、REST API使って単純にMarketoに連携するだけ？

14. API叩くだけではうまくいきません

15. （Marketoが特別な訳ではなくて、外部連携系の APIではごく自然な話）
REST API Munchkin API (JavaScript)
リードの一括登録/更新など様々な機能 Cookie情報とリードの紐付け
任意のField（会員IDなど）で連携可能 メールアドレスでのみ連携可能
リクエスト数上限あり（ 50,000 / 日） 上限なし
REST API にはリクエスト数に上限があります。
課題：APIのリクエスト上限の壁

16. すべての情報をリアルタイムで連携した場合、
APIのリクエスト数上限（50,000 / 日）を超えてしまう！
BtoCの会員制サービスの場合、ユーザーの状態変化や行動が非常に多い。
職務経歴書の更新などはまとめてやりますよね？
ビズリーチの会員数は何十万人。
会員が職務経歴書を更新する度に、 APIを叩いていたら大変！
課題：APIのリクエスト上限の壁

17. だったらどうするの？

18. ・求職者ID
・メールアドレス
・姓、名
・性別
・現住所
・生年月日
・転職意向、転職経験
・プレミアムフラグ
・求職者ステータス
・求職者クラス
・求職者登録日
・最終ログイン日
・レジュメ最終更新日
・業種、職種
・メルマガ配信フラグ
・スカウト利用フラグ
Marketoへの連携項目を確認してみる
・スカウト受信数
・スカウト開封数
・メッセージ開封数(すべて)
・返信数
・応募数
・ヘッドハンターへの相談数
・気になる求人数
・興味ある(タレントプール)数
・求人検索数
・レジュメ更新数
・メール開封数
・メールクリック数
・ログイン数
・スカウト受信数
・レジュメ被検索数
・レジュメ被閲覧数
求職者情報 求職者行動データ(1週, 2週, 4週, 13週, 26週)

19. ・求職者ID
・メールアドレス
・姓、名
・性別
・現住所
・生年月日
・転職意向、転職経験
・プレミアムフラグ
・求職者ステータス
・求職者クラス
・求職者登録日
・最終ログイン日
・レジュメ最終更新日
・業種、職種
・メルマガ配信フラグ
・スカウト利用フラグ
・スカウト受信数
・スカウト開封数
・メッセージ開封数(すべて)
・返信数
・応募数
・ヘッドハンターへの相談数
・気になる求人数
・興味ある(タレントプール)数
・求人検索数
・レジュメ更新数
・メール開封数
・メールクリック数
・ログイン数
・スカウト受信数
・レジュメ被検索数
・レジュメ被閲覧数
求職者情報 求職者行動データ(1週, 2週, 4週, 13週, 26週)
即時性は必要
Marketoへの連携項目を確認してみる

20. ・求職者ID
・メールアドレス
・姓、名
・性別
・現住所
・生年月日
・転職意向、転職経験
・プレミアムフラグ
・求職者ステータス
・求職者クラス
・求職者登録日
・最終ログイン日
・レジュメ最終更新日
・業種、職種
・メルマガ配信フラグ
・スカウト利用フラグ
・スカウト受信数
・スカウト開封数
・メッセージ開封数(すべて)
・返信数
・応募数
・ヘッドハンターへの相談数
・気になる求人数
・興味ある(タレントプール)数
・求人検索数
・レジュメ更新数
・メール開封数
・メールクリック数
・ログイン数
・スカウト受信数
・レジュメ被検索数
・レジュメ被閲覧数
求職者情報 求職者行動データ(1週, 2週, 4週, 13週, 26週)
即時性は不要
Marketoへの連携項目を確認してみる

21. APIのリクエスト上限の回避方法
REST API は1回のリクエストで300リードまで登録更新可能。
それならまとめた方が絶対お得！
前回実行時から更新があった場合のみを連携対象とする。
思い切ってリアルタイム更新をやめる！
求職者情報と行動データで、それぞれ連携する頻度を変える！
即時性の求められる求職者情報は15分間おきに連携。
即時性の必要のない行動データは24時間おきに連携。
Point

22. 会員登録
リード登録
15min
15min
15分ごとに、「求職者情報」をMarketoに連携する。
退会
リード更新
レジュメ更新
リード更新
求職者情報の連携
ID: 100
ID: 100
ID: 100

23. ログイン
リード更新
24hour
24時間ごとに、「行動データ」をすべて集計して連携する。
職務経歴書被閲覧
応募
リード更新
行動データの連携
求人検索
スカウト受信
職務経歴書被検索
ID: 100
ID: 100

24. リード情報が常に最新な訳ではない。
例）退会後、15分間はメールが届く可能性がある
→ 許容できるラインを見つける必要がある！
メリット
APIのリクエスト制限は問題なし！（しばらくは...）
デメリット
APIのリクエスト上限の回避
思い切ってリアルタイム更新をやめる！
求職者情報と行動データで、それぞれ連携する頻度を変える！

25. リードの登録更新はなんとか出来た！

26. Marketoのリードトラッキング

27. Munchkin APIによるMarketo連携
ログイン
ログアウト
求人特集閲覧
メッセージ閲覧
応募
Activity登録
Activity登録
Activity登録
Activity登録秘密鍵＋メアド
秘密鍵＋メアド
秘密鍵＋メアド
秘密鍵＋メアド
秘密鍵＋メアド Activity登録
ページ遷移やクリックごとに、「行動データ」をJavaScriptで連携する。

28. Munchkin APIによるMarketo連携
ログイン
ログアウト
求人特集閲覧
メッセージ閲覧
応募
Activity登録
Activity登録
Activity登録
Activity登録
タグ（JavaScript）を埋めて、行動データをMarketoに連携するだけ？
秘密鍵＋メアド
秘密鍵＋メアド
秘密鍵＋メアド
秘密鍵＋メアド
秘密鍵＋メアド Activity登録

29. タグ追加だけではうまくいきません

30. REST API Munchkin API (JavaScript)
リードの一括登録/更新など様々な機能 Cookie情報とリードの紐付け
任意のField（会員IDなど）で連携可能 メールアドレスでのみ連携可能
リクエスト数上限あり（ 50,000 / 日） 上限なし
課題：重複リードが生まれる
Munchkin API （JavaScript）は任意のField（会員ID）で連携できない。
（メールアドレスと秘密鍵を暗号化した文字列で、リードを一意に特定する）

31. アドレスは異なるが、会員 IDが同じリードが存在することに。
REST API連携に、会員IDでリードを特定出来ない！
古いメールアドレスにもメールが
メールアドレスの変更情報が連携される前にページ遷移すると、
アドレスが一致するリードが存在しないため新規作成されてしまう！
BtoCの会員制サービスの場合、ユーザーはメールアドレスを変更する。
課題：重複リードが生まれる

32. メールアドレス変更時に、最大15分間はリードを更新できていない。
メアド変更直後に連携されてしまうと、重複リードが作成されてしまう！
ログイン
メアド変更
メッセージ閲覧
ページ遷移
Activity登録
リード登録
Activity登録秘密鍵＋メアド
秘密鍵＋メアド
秘密鍵＋新メアド
課題: Munchkin API によるリード重複
求職者ID：100
aaa@xxx.com
求職者ID：100
aaa@xxx.com
求職者ID：100
bbb@xxx.com

33. だったらどうするの？

34. と言いつつ、実はまだ解決できてません

35. 案1: Munchkin API の呼び出し頻度を変更する
メールアドレスが変更された場合
リードが更新されるまでの15分間はリードトラッキングを行わない！
ログイン
メアド変更
ページ遷移
リード更新
Activity登録秘密鍵＋メアド
秘密鍵＋新メアド
求職者ID：100
bbb@xxx.com
求職者ID：100
bbb@xxx.com
15min
ページ遷移
Activity登録

36. 案1: Munchkin API の呼び出し頻度を変更する
メールアドレスが変更された場合、
リードが更新されるまでの15分間はリードトラッキングを行わない！
メリット
デメリット
リードの重複を簡単に防ぐことが出来る。
（連携前に更新有無を確認するだけ）
トラッキングされない情報が数％発生する。
→これを許容できれば、それで良い。

37. 案2: KARTE x Marketo連携を利用する
ｘ

38. 案2: KARTE x Marketo連携を利用する
現状リアルタイムで行動データがトラッキング出来ているKARTEを利用。
KARTEに溜まった行動データをMarketoに連携できる？（一括 or 即時）
リード連携
カスタムアクティビティー連携？
イベント（行動データ）連携
求職者情報連携

39. 案2: KARTE x Marketo連携を利用する
メリット
すべての行動のトラッキングが可能！
Marketo と KARTE の連携施策が打てる！
連携はやや複雑になる....
カスタムアクティビティー連携でAPIを利用する必要がある？
リクエスト制限でAPI使用できない場合、トラッキングデータが
リアルタイムでなくなる。（＝トリガーにしづらい）
デメリット
現状リアルタイムで行動データがトラッキング出来ているKARTEを利用。
KARTEに溜まった行動データをMarketoに連携できる？（一括 or 即時）

40. 引き続き、検討を進める必要はあるが...

41. この後の懇親会で解決されるかも？

42. Appendix: Marketo連携での失敗談

43. システム障害を完全に防ぐことはできません！（外部連携の場合は特に）
外部連携APIの予期しない失敗
タイムアウトやアクセストークンの有効期限切れ が発生し、リードの最新化に失敗した。
リカバリ策を後回しにしていたため、すべて手作業で修復。
Marketoのリードデータを何度も洗い替えする事態に。
ほんと辛かった.....。

44. AmazonSQSを利用した自動リランの仕組みを導入しました。
・アクセストークンの有効期限切れの場合は、再取得して、即時リラン。
・それ以外の原因で失敗した場合は、 SQSに積んで、次回実行時にリラン。
自動リランの仕組みを導入
Amazon RDS Amazon EC2
Amazon SQS
更新失敗したIDを
キューに積む
次回実行時に
キューからIDを
取得してリラン

45. 手動リランは可能か？
自動リランされる？
メンテナンス時の対応は必要か？
障害を起こさないように作るのではなく
障害が起きても問題ないように作る！
失敗からの学び
リカバリー策を考えるのは当たり前の話だけど、
ツール導入を焦ると、自動リランとか後回しにしてしまいがち ....
Point
問題が起きる前からリカバリー策を考えておく！