こんにちは、こんばんは。
サーバーサイドエンジニア（社内ではAPIエンジニアとも呼称します）の@bravewoodと申します。一部の人からはウッディと呼ばれていて気に入っております。
キャリア初期にウノウラボに大変な憧れを抱いていた身としては、ウノウの流れをくむメルカリでこうしてBlogを書くことができ感動しきりです。
さて、本日はCRMツールについてお話しします。技術的な話は少なめで、CRM周りの開発やPlanningについてざっくりとお話しします。
APIエンジニアとは
まず、メルカリ社内においてAPIエンジニアとは、商品や取引などの各種データや機能を各クライアントから呼び出すための「API」を開発することを主としたエンジニアを指します。
クライアントにはiOSやAndroidのアプリとWeb、その他複数のサブシステムがあり、各担当のエンジニアと密に連携を取り、高速かつ安定したAPIを開発・維持することが役目です。
私はこれまで主に、プロモーションやUS向けの機能の開発、CRMツールの開発、Web版の開発などを担当してきました。
今日はそのうち、内製CRMツールについてPostします。
CRMとは
CRMとは、「Customer Relationship Management」の略で、お客様の満足度やロイヤリティを高め、売上や収益の向上を狙う手法のことです。^1
メルカリでは現在、内製・外製両方のCRMツールを使い、プロモーション（日本ではキャンペーンなどとも言います）に関するお知らせ、あるいはお客様に認知を図るための通知などを行っておりますが、その中でも特にメルカリが内製ツールにこだわる理由の1つとして、例えばポイントやアプリ内バナー、プライベートメッセージといったメルカリ独自機能を柔軟にカスタマイズすることにより、より目的に合った施策の実行が可能という点があげられます。
メルカリにおける通知
メルカリでは主に以下のような通知をユーザーに送ることができます。
- プッシュ通知
- スマホのロック画面などにも表示されることから認知性は非常に高い一方、1度クリックすると消えるなど揮発性があります。
- アプリ内通知
- アプリアイコンや、アプリ内TOPメニューのバッジ数に連動させることができるため認知性は高く、また情報はメルカリのデータベースに保存しているため揮発性はありません。
- プライベートメッセージ
- バッジなどとは連動しないため認知性は低い一方で、文字数などに上限がなく長文を使う案内などに向いています。こちらもメルカリのデータベースに保存しているため揮発性はありません。
- Eメール
- ユーザーが利用するメールアドレスに送信するため認知性は高く、HTMLも使うことができるため自由なデザインを行うことができます。
内製CRMツール
現在内製CRMツールでできることの一部を紹介します。
- プッシュ通知の配信
- プライベートメッセージの送信（アプリ内通知を連動させて送り、認知性の低さを補っています）
- Eメールの送信
- ポイントの付与
- 文言のABテスト
- バナーの自動生成
- 配信状況ダッシュボード（Mackerel APIからデータを取得し簡易表示）
また、特徴としては、
エンジニア以外（特にプロデューサーと言われる企画職の人）でも使えるよう操作画面をWeb UIで実装しています。
また送信関連の機能はUIと疎結合にするためにAPIとして実装しており、これらはPHPのコードで記述することで柔軟かつ高速に開発できるのが特徴です。
この仕組みは、Q4M使ったメッセージキュー、APIエンジニアの@travailが作っているphp-Parallel-PreforkというPHPによるpreforkサーバエンジンを使って実現しています。
CRMツールのカイゼン
CRMツールを使った通知は、主に全ユーザーに向けた大量配信となることが特徴です。
メルカリでは現在JP・USに会員・非会員合わせて数千万単位のユーザーを抱えているため、これらの規模で配信するために行った工夫をいくつか時系列に沿ってご紹介します。
バージョン1: バッチ
バッチ手動実行 + CSV
送信対象をCSVで管理し、これをAPIのリポジトリにコミット、本番サーバーにて手動でバッチを実行します。
送信時にはエンジニアがsshでバッチサーバーにログインし、手動で実行していました。
これには以下のような課題がありました。
- APIリポジトリに対象ユーザーの一覧をcommitせねばならずレビューやリリースなどの手間がかかる
- 土日やUS時間に合わせるために深夜などにエンジニアリソースを確保しなければならない
- プロデューサーなど非エンジニアが気軽に実行できない（対象者が少ない通知や実験的な通知にも手間がかかっていた）
バージョン2: Web UI
かつてはエンジニアが手動で実行していましたが、Web UI化により非エンジニアでも処理を実行することが可能になりました。また、土日や深夜などにエンジニアリソースを確保する必要も無くなりました。
しかし新たに以下のような課題が生じました。
- ユーザー数の増加により、送信処理の実行時間が数時間にも及ぶようになった
- 狙った時間にプッシュ通知が着信できない
- 長時間サーバーやSREチームのリソースを使ってしてしまう
バージョン3: プッシュ通知の高速化
メルカリではプッシュ通知配信のミドルウェアに、SREチームの@cubicdaiyaが開発しているGaurunを使っております。
Gaurun単体ではこの時点で超高速に配信することが可能でしたが、
バージョン2までの配信では1ユーザーに対して1 WorkerでGaurunにHTTPでリクエストを送っていることがボトルネックとなっていました。
そこでGaurunには10件単位でプッシュ通知を配信する、1 Workerで複数のユーザーに通知を行うという処理に変えたところこれまで数時間かかっていたプッシュ通知が数十分で配信できるまでに改善することができました。
この時に私のチームのプロデューサーが言っていたセリフを思い出します。
「全米にボタン1つで手軽にプッシュ通知の配信ができるようになってハッピー！」
大人のスタートアップを標榜するメルカリでは、お客様はもちろん従業員もハッピーでなければならないと私は思うのです。
さらなるKaizen
私の所属するチームは、8月にUS出張を行っており、この際にUSのCRマネージャーとCRMツール周りの企画を行いました。
その後フィードバックを受けて、以下の改善を行いました。
ユーザーの時間帯にあった通知
プッシュ通知は明らかにユーザーの行動を促すという意味で効果のある施策ですが（各種数字をモニターしており、プッシュ通知の配信後、明らかにグラフに変化が起きます）、一方でユーザー視点で言えば、配信されるのに適切な時間があるはずです。
また、一気に大量のプッシュ通知を配信することでユーザーのスパイクが起こりサービスへの負荷となる可能性もあります。
そのための施策として、プッシュ通知の配信時間をユーザー毎ににあった時間帯に変更するという実装を行いました。
配信処理の自動実行
Web UI化されたとはいえ、必ず誰かが実行ボタンを押さなければなりませんでした。
私のチームはUS向けの開発を行っておりますので、時差が問題になっていました （JST -> PDTで 16時間あります）。
そこで、指定の時間に自動で実行される機能を追加しました。
専用Queueの利用
メルカリでは現在CRM以外にも各種Queue/Workerを利用して様々な処理を行っております。
Q4MにおいてJobはFIFOで処理されます。
何も考えずにあらゆるJobが同様のQueueを使うと、重たい処理がQueueを占有してしまい、他のJobが長い間実行されません。
そこでCRM専用のQueue/Workerを作り、CRMの処理が他のJobに邪魔されないようにしました。
また、SRE視点でいうと、Queue/Workerを分けることにより、モニタリングやチューニングを個別に行えるというメリットもあり非常に有益です。
さいごに
このように、われわれのようなスタートアップ企業では、本体サービス・アプリ以外でも、CRMなどの周辺ツールにおいても事業の成長に合わせて様々な改善や機能追加を常に行っています。
このような機能開発にも積極的に加わっていただける仲間を募集しております！
