診断レポートを先に送るアウトバウンドはどう作るのか

なぜ「最新の動画を拝見しました」がスパムに読まれるのか

アウトバウンドはこちらから先に連絡する営業で、相手が問い合わせてくるインバウンドの逆だ。ここ数年、海外で大きく流行したのがシグナル型アウトバウンドである。シグナルとは相手企業で最近起きた観測可能な変化を指す。新しい求人が出た、資金調達をした、代表が動画を上げた、といったものだ。それを検知してメールの一行目で触れながら本題に入る。

問題は、この検知と言及が自動化しやすすぎることにある。YouTube のタイトルを取ってきて要約し、「最近上げられた動画、印象深く拝見しました」を添えて本題へ移るスクリプトは半日で作れる。だから全員が同じものを送るようになった。受け取る側にとって、この一文はもう「自分を見てくれた」証拠ではない。ツールを回した証拠として読まれる。

AB180 で GTM（市場投入）を率いるチェ・ヒョンジョン氏はインタビューで、この打ち手はもう死んだと明言している。営業担当がやってはいけないことの一つが、全員と同じ行動を同じようにすることであり、シグナルへの言及がまさにそれに当たるという。同じインタビューで司会者は、月に300通近い協業提案メールを受け取り、その98%を捨てると語っている。形式がどれも同じだからだ。

では何が残るのか。自動化しやすいものではもう差がつかない。必要なのは、自動化しつつも作るのに実際に手間がかかるものを送ることだ。それが本稿の主題である。

代わりに何を送るのか — 相手が今日から使える文書

最初の接触で送るものは三段階で進化してきた。第一段階は良いメッセージを書くこと。第二段階は役に立つ資料を投げること。業界レポートのリンクや参考になる事例がこれに当たる。第三段階が今回の話で、相手のために成果物そのものを作って渡すことだ。

チェ氏が実演したのがこの第三段階である。海外のサブスクアプリ創業者を相手にしていると、彼らは決まって「まず何から直すべきか」という問いを抱えていた。そこで相手のアプリのストアレビューを集めて分析したレポートを作って送った。インタビューで映された画面によれば、Duolingo のレビュー1,000件を分析し、そのうち118件を離脱シグナルとして分類し、iOS と Android でレビューがどう分かれるか、繰り返し現れる八つのパターンは何か、そして何から着手すべきかまでを収めていた。

受け取る側にとってこれは広告ではない。自分の会社の話であり、自分がすでに気にしていた問いへの答えだ。だから最後まで読まれる。仕組みはこれで全部である。

狙う結果は二つある。一つは当然、商談につながること。もう一つは、今は買わなくても、その問題が実際に起きたときに真っ先に自分を思い出してもらうことだ。チェ氏はむしろ後者の確率が高いと言い、営業の核心を「顧客が問題を抱えたときに自分を探させること」と定義している。

だからレポートを設計するとき、一つ仕込んでおく。全部は渡さないことだ。「ここはご自身で確認できますが、ここは当社のデータがないと見えません」という箇所を残しておけば、会話を開く理由が生まれる。助けるだけで終わる資料は、お礼の一言で終わる。

レビューはどこから取るのか — App Store

App Store の公開レビューフィードのURLと、1〜10ページを巡回してレビューをJSONLに保存するcurlループをターミナルのモックで示す。

ここから先はインタビューには出てこない。動画は完成したレポートの画面を見せるだけで、どう集めたかは語らない。以下は同じものを作るために実際に使える経路だ。

アップルはアプリごとに顧客レビューのフィードを公開している。開発者アカウントも API キーもログインも要らない。URL さえ分かればブラウザでも開く。返却形式は JSON だ。

まず相手アプリの数値 ID が必要になる。App Store のウェブ URL の id の後ろの数字がそれで、検索 API からも直接引ける。

アプリ ID を探す

curl -s "https://itunes.apple.com/search?term=duolingo&country=kr&entity=software&limit=5" | jq -r '.results[] | [.trackId, .trackName] | @tsv'

レビュー500件を取得する

APP=570060128
for p in $(seq 1 10); do
  curl -s "https://itunes.apple.com/kr/rss/customerreviews/page=$p/id=$APP/sortby=mostrecent/json" | jq -c '.feed.entry[]? | {rating: .["im:rating"].label, version: .["im:version"].label, title: .title.label, body: .content.label}'
done > reviews-kr.jsonl

wc -l reviews-kr.jsonl

500件という上限はどこから来るのか

Appleレビューフィードの四つの上限 — 1ページ50件、ページは10まで、国を変えればさらに500件、並び順は新着順と参考度順の二つ。

上のループが1から10までしか回らないのには理由がある。このフィードは1ページに50件を返し、ページは10までしか存在しない。11ページを要求すると JSON ではなくエラーが返る。だから一つのストア、一つの国から得られる最大値が500件になる。

インタビューで語られた1,000件がどう可能になるかも、ここで説明がつく。URL の kr を us や jp に変えれば、その国のストアのレビューが別に500件ずつ出てくる。Android まで足せばさらに積み上がる。国を混ぜるときの注意は一つだけだ。市場ごとに不満の種類が違うので、国を項目としてデータに残しておく。そうしないと後から「課金不満が日本に集中している」といった話ができない。

並び順も変えられる。URL の sortby=mostrecent を mosthelpful にすると、役に立ったという票を多く集めたレビューが先に来る。直近のビルドで何が壊れたかを見るなら新着順、長く溜まった不満を見るなら参考度順がいい。

Google Play 側はどうするのか

グーグルはアップルのような公開フィードを用意していない。代わりにオープンソースのパッケージを使う。google-play-scraper が事実上の標準で、本稿執筆時点のバージョンは 10.1.3 だ。ここでのアプリ ID は数字ではなくパッケージ名で、Play ストアの URL の id= の後ろの値（Duolingo なら com.duolingo）をそのまま使う。

一回の呼び出しで最大200件が返り、次ページを指すトークンが一緒に付いてくる。そのトークンを再び渡せば続きが取れる。下のスクリプトは五回繰り返して1,000件を取る。

インストール

npm init -y
npm i google-play-scraper

reviews-play.mjs

import gplay from "google-play-scraper";

const out = [];
let token;

for (let i = 0; i < 5; i++) {
  const r = await gplay.reviews({
    appId: "com.duolingo",
    lang: "ko",
    country: "kr",
    sort: gplay.sort.NEWEST,
    num: 200,
    nextPaginationToken: token,
  });
  out.push(...r.data);
  token = r.nextPaginationToken;
  if (!token) break;
}

for (const r of out) {
  console.log(JSON.stringify({ rating: r.score, version: r.version, body: r.text }));
}

実行

node reviews-play.mjs > reviews-play.jsonl
wc -l reviews-play.jsonl

500件をどうやってレポートに変えるのか

生のレビューの山はそれ自体では何の意味も持たない。相手も自分のレビューは見られる。値が生まれるのは分類だ。軸を先に決めてすべてをその軸で分け、軸ごとに何件あるか、どのバージョンに偏っているかを数える。それがレポートの骨格になる。

軸は五つあれば足りる。以下はアプリ製品に広く使える基本形で、相手の業種に合わせて一つ二つ入れ替えればいい。

分類軸	何を入れるか	なぜ重要か
離脱シグナル	消した・解約した・別のを使う	売上に直結する唯一の軸
機能要望	これがなくて不便だ	ロードマップ優先度の根拠
課金不満	高い・返金されない・自動更新	サブスクでは離脱の一歩手前
不具合	特定の画面・特定のビルドで壊れる	バージョンと結ぶと原因が絞れる
称賛	これがあるから使っている	そのままマーケ文言になる

分類は人がやらない

500件を手で読むと一日が消える。それではこの方法は広がらず、広がらなければアウトバウンドではない。分類はモデルに任せ、人は軸を決める仕事だけを持つ。

コマンド一行で済む。以下は先ほど作った JSONL をそのまま標準入力に流し込む形だ。

分類する

claude -p "以下はアプリレビューの JSONL である。各行を離脱/機能/課金/不具合/称賛のいずれかに分類せよ。出力は CSV のみ：分類,評点,バージョン,原文引用（30文字以内）。判断が曖昧なら その他 とし、新しい分類を作るな。" < reviews-kr.jsonl > classified.csv

軸ごとの集計

cut -d, -f1 classified.csv | sort | uniq -c | sort -rn

レポートに必ず残すもの — 原文の引用

分類結果に原文の断片を添えさせるのには理由がある。要約だけのレポートは検証できず、検証できない文書は信用されない。「課金不満41件」よりも「課金不満41件、そのうちの一つはこういう文章だ」のほうがはるかに強い。

同時にこれは捏造を防ぐ装置でもある。モデルは存在しないパターンをもっともらしく作り出せるが、原文引用を強制すればその場で露見する。引用が元ファイルに実際にあるかの確認は grep 一回で終わる。

最終形は立派である必要はない。一枚の文書に四つあれば足りる。何件を見たか、軸ごとの件数と割合、バージョンや国と結びついた目立つパターンを二つ三つ、そして何から手を付けるべきかの推奨順序だ。最後の推奨順序が、相手に残る唯一の実行項目になる。

メール本文は最初の一行だけ変える

レポートが用意できたらメールを書く。ここでよくある失敗が、本文全体を相手ごとに書き直すことだ。時間もコストも増えるのに品質はむしろ落ちる。チェ氏の実務ルールは単純で、件名と挨拶のあとの一行目だけ相手に合わせて変え、残りは最も反応が良かったテンプレートをそのまま繰り返す。

一行目の中身はレポートから取る。分析はすでに済んでいるので、「レビュー500件のうち118件が離脱シグナルで、その半分が直近二つのビルドに集中していました」といった文が自動的に出てくる。これはクロールしてきた動画タイトルとは質が違う。相手が確認できる自社のデータだからだ。

相手が実際にそう扱われたかより、そう感じられるかが重要だ、というのがチェ氏の表現である。ただし、その感覚を作る素材が本物のデータであることが、死んだ打ち手との分かれ目になる。

返信がなくても次の会話が開く理由

レポートはリンクで送り、開かれたかどうかを追跡する。添付ではなくリンクを使う理由がこれだ。開いたか、何回見たかが残る。

そうすれば返信がなくても次の一手が生まれる。「開いていただいたようですが、この部分はさらにお手伝いできます」は、何の名分もなく送る催促メールとはまったく別物だ。相手が関心を示したという事実の上に立っているからである。

同じ構造は営業の外でも使える。インタビューで紹介されたもう一つの例が、製品インタビュー対象者の募集だ。自社製品を最近よく使っているユーザーの一覧を出しておき、一行目だけをその人の利用記録で埋めて15分のインタビューを依頼する。レポートの代わりに利用記録が素材に入っただけで、骨格は同じである。

今週のうちに一本作ってみるなら

全部そろえてから始めようとすると、始められない。一度回すのに必要な最小の手順は次の通りだ。

一つ、今提案したい会社のうちアプリがあるところを一社選ぶ。アプリがないなら素材を変えればいい。求人票、ウェブサイトの表示速度、検索での見え方など、外から観測できるものなら何でも同じ位置に入る。

二つ、上のコマンドでレビューを取得する。アップルだけで500件あるので、最初の一本にはそれで十分だ。ここまで10分。

三つ、五つの軸で分類し、軸ごとに件数を数える。ここでまた10分。

四つ、一枚の文書にまとめる。件数、パターンを二つ三つ、推奨順序、そして原文引用を数行。ここまで20分。

五つ、メールを書く。一行目はいま数えた数字で埋め、残りは普段のテンプレートのままにする。リンクで送り、開封を確認する。

一本を最後まで回してみれば、次からは対象を差し替えるだけになる。その時点からがこの方法がアウトバウンドになる地点だ。最初の一本に時間がかかるのは正常で、時間がかかるという事実こそが、この方法がまだスパムに読まれない理由でもある。