ROASが悪化しても判定できる、顧客台帳のつくり方：5つのステップで「数えられる」状態にする

顧客の台帳とは

顧客の台帳とは、誰が・いつ・何を・どの経路で買ったかが、顧客単位で1つに繋がって数えられる記録のことです（この定義は私たちの整理です）。顧客リストとの違いは「繋がって」の部分にあります。名簿が何枚あっても、受注の記録、会員の名簿、配信のリストが別々にあるだけでは、この記事では台帳とは呼びません。別々の記録を同じ顧客で突き合わせられる状態になって、初めて「数えられる」と言えます。

獲得した顧客を資産に変えていく階段の、これが1段目です。何が資産かを、数えられる状態にする ── 階段の全体像はROAS悪化時の打ち手の3群と階段で示したので、この記事は1段目だけを掘ります。

なぜ、台帳が先なのか

1　判定の物差しは、台帳からしか出ない

ROASの悪化が計測の欠落なのか効率の低下なのかを切り分けるにも（手順はROASの悪化の切り分け）、広告経由の成果を新規と既存に分解するにも、元になる実数の置き場は台帳です。新規獲得の効率と、既存売上のうち自社接点から立った割合という2枚のレポートも、出力元は同じ台帳です。切り分けも分解も、手法の問題である前に、台帳の欄の問題です。

欄が要ることの根拠として、1つだけ古い実験を引きます。eBayが自社の検索広告を止めた実験の論文（NBER Working Paper 20171、2014年5月。米国・著名ブランド1社・2012年ごろの実測で、この記事の取得日から約12年前のものです）は、ユーザーを利用の頻度と直近性で層に分け、広告の有意な効果が新規と、前年の購入が少なかった買い手に偏ることを報告しました（p.4、2026年10月16日取得。英文は原文［1］に置いています。訳は私たちのものです）。古く、日本の事例でもないため、この記事ではこの一点 ── 層で分けて判定するには、初回購入日と購入回数の欄が先に要る ── のためだけに使います。実験そのものの読み方は増分の測り方の記事で扱っています。

2　外部の識別子は、制度の側が絞った

顧客を1人に数える鍵を、広告プラットフォームの識別子に頼る方法は、制度の側が絞りました。Apple Developerの「User privacy and data use」のページには、iOS 14.5以降、他社のアプリやサイトを横断する追跡と端末の広告識別子の取得には、App Tracking Transparency（ATT）の枠組みでユーザーの許可が要る、とあります。許可がなければ、広告識別子の値はすべてゼロになります。ハッシュ化したメールアドレスなど別の識別子で代わりに追跡することも、許可なしには認められません。端末の特徴から識別子を導き出す方法（フィンガープリンティング）は、許可の有無にかかわらず認められない、とされています（いずれも2026年10月16日取得。英文は原文［2］に置いています。訳は私たちのものです）。

外の識別子が細るほど、突き合わせの鍵は自社が顧客から直接預かるもの ── 会員ID、注文に紐づく連絡先、同意 ── に寄ります。これは制度の変化の帰結であって、ツール選定の流行ではありません。

3　台帳側のデータは、計測の精度にも使われる

整った台帳は、判定の物差しになるだけでなく、プラットフォーム側の計測にも差し戻せます。Meta for Businessニュースの2022年2月14日の発表は、「広告主様がコンバージョンAPIを使用してイベントを送信すると、発見からコンバージョンまで、カスタマージャーニー全体を通して広告のパフォーマンスとアトリビューションの測定の精度が上がります。」と説明しています（2026年10月16日取得。原文［3］。鉤括弧の文言はMeta自身の公式日本語版から引いたものです）。送信する「イベント」の出どころが、自社側の記録です。同じ発表はドメインの認証にも触れ、「認証を行うことで、イベントの優先度を決定する権限が適切なアカウントに付与され、オプトアウトしているiOSユーザーのイベントを、関連するウェブページから測定できます。」としています（同発表）。

つまり台帳は、広告の外の施策のためだけの投資ではありません。広告の計測そのものが、自社側のデータの整いに依存する方向へ動いています。

台帳のつくり方 ── 5つのステップ

ここからは引いた資料にある手順ではなく、私たちのやり方です。台帳づくりは、道具の導入からではなく、いまある記録の整理から始まります。順番に意味があるので、5つのステップで進めます。

ステップ1　いまある記録を、3つの帳に棚卸しする

台帳は1枚の巨大な表ではなく、1行の単位が違う3つの帳の組で考えます。注文を1行とする受注の帳、顧客を1行とする会員の帳、接触を1行とする接点の記録です。ここまで「受注・会員・配信」と呼んできた3つ目がこの接点の記録にあたり、配信のリスト（送ってよい相手の名簿）は会員の帳の同意の欄に収まります。接点の記録に入るのは配信だけではありません。サイト内の行動 ── ページの閲覧、カートへの投入、動画の視聴など ── も、接触を1行とする同じ記録に入ります（この置き方は私たちの整理です）。最初に、この3つがそれぞれどこにあり、どの単位で1行になっているかを書き出します。書き出す項目は、帳の名前、置き場所（システム名・ファイル名）、1行の単位、鍵になり得る欄の有無、更新の頻度の5項目で足ります。よくある混在は、配信のリストに「メールアドレス」と「注文」が同居している、会員の帳に同じ人が旧IDと新IDで2行いる、店舗とECで別の名簿になっている、といった形です（ご相談をいただく中で繰り返し見る形で、統計ではありません）。

このステップが終わると、「どこに・何が・どの単位であるか」を1枚で言えるようになります。単位の違うものを1枚に混ぜると数えるたびに分母が揺れるので、混在の発見がこのステップの成果物です。どの帳を成果の「正」に置くか、チャネルをまたぐ重複をどう外すかはチャネルをまたいだ成果の重複で扱ったので、ここでは繰り返しません。

ステップ2　顧客を1人に数える鍵を決める

次に、顧客を1人に数えるための鍵を1つ決めて、3つの帳に通します。候補は会員IDのように自社が発番するものです。外部の広告識別子は、先に見たとおり制度の側で取得に許可が要る方向に動いているため、鍵の本線には置きません。過去の記録は全部を遡れなくても、鍵が通った日以降の分から「数えられる」範囲が始まります。遡れなかった期間の数字は捨てずに、「鍵が通る前の分」と注記して分けて読みます。遡及の完全さを待つより、数えられる範囲を今日から始めるほうが、判定は早く手に入ります。

このステップが終わると、同じ顧客を、帳をまたいで1人に数えられるようになります。

ステップ3　顧客1行の欄を埋める

判定に使う帳は、顧客を1行とする帳です。この1行に、鍵（会員IDなど、3つの帳に通る識別子）、初回購入日、直近購入日、期間あたりの購入回数、累計の購入金額、主な接点の経路、そして連絡の同意の状態が揃っていると、この記事で言う「数えられる」状態に近づきます（この欄の構成は私たちの整理です）。初回購入日は新規と既存の区別を、購入回数は広告が効く層・効かない層の分解を、同意の状態は既存客に触れ続ける施策に進めるかどうかを、それぞれ決めます。

欄と判定の対応は私たちの整理。「欠けていると起きること」も私たちの整理で、引いた資料の記述ではない。

経路の欄には、メール経由・広告経由といった関与の記録が入ります。この欄は便利ですが、各画面の計測の癖（窓・日付・重複）を引き継いでいることを忘れずに、成果の確定値ではなく関与の記録として扱います。このステップが終わると、新規か既存か、休眠か、触れてよい範囲か、を欄から言えるようになります。

ステップ4　新規と既存の分解を、1回やってみる

欄が揃ったら、初回購入日を使って、直近の月の広告経由とされる成果を新規と既存に分けてみます。これは台帳の検収です。分解が最後まで通れば、台帳は判定に使える状態です。途中で欄が足りずに止まったら、その欄の整備が施策より先です。分解の結果をどう打ち手につなげるかは、打ち手の3群と階段の記事に戻ります。

このステップが終わると、広告経由の成果のうち既存の買い手の割合を、1つの数字で言えるようになります。

ステップ5　更新の運用を決める

最後に、台帳を1回きりの集計で終わらせない運用を決めます。決めるのは3点です。更新の頻度（まず月次で十分です）、更新の責任者（どの帳からどの帳へ、誰が流すか）、そして定義の固定（新規・既存・休眠の定義と層の切れ目を、変えるときは日付つきで記録する）。定義が動くと、先月と今月の数字が比べられなくなります（この運用の3点は私たちの整理です）。

このステップが終わると、来月も同じ定義で数えられるようになります。ここまでが、この記事で言う「数えられる」状態です。データの揃い方には段階があり、揃う段階が上がるほど、判断できることと打てる手が増える、というのが私たちの整理です。次は、この台帳に広告費を突き合わせる段 ── 広告の採算を、管理画面ではなく台帳側で見る ── で、後続の記事で書きます。

あわせて押さえる言葉

獲得したあとの数字を、どこから見るか。論点だけ先に揃えます。
ご相談は営業を受ける場ではありません。一行でも構いませんし、フォームは7項目・3分で送れます。

30分の相談を申し込む

顧客の台帳について、よくある質問

ROASの改善と顧客の台帳は、何の関係がありますか？

管理画面のROASが悪化したとき、計測の欠落なのか効率の低下なのかを切り分けるにも、広告経由の成果を新規と既存に分解するにも、受注・会員・配信を顧客単位で突き合わせられる台帳が前提になります（この整理は私たちのものです）。台帳がないと、打ち手の良し悪しをあとから判定できません。

台帳づくりには、専用のツールが必要ですか？

この記事では道具を指定していません。要るのは、注文・顧客・接触という1行の単位が決まった3つの帳、3つを貫く鍵、顧客1行に初回購入日・購入回数・同意の状態などの欄が揃っていること、そして更新の運用が決まっていることです（この条件は私たちの整理です）。どの道具で実装するかは、記録の量と社内の体制で変わります。道具を替えても、1行の単位と鍵と欄が決まっていなければ数えられない、という順番は変わりません。

台帳に最低限そろえる欄は何ですか？

私たちの整理では、鍵（会員IDなど）、初回購入日、直近購入日、期間あたりの購入回数、累計の購入金額、主な接点の経路、連絡の同意の状態の7つです。初回購入日が新規と既存の区別を、購入回数が広告の効く層・効かない層の分解を支えます。層別の根拠は、eBayの実験が前年に1〜2点だけ買ったユーザーには統計的に有意な効果、前年に3回以上取引した消費者には有意な効果なしと報告していることです（NBER Working Paper 20171、p.4、2026年10月16日取得。訳は私たちのもの。米国・著名ブランド1社・2012年ごろの実測です）。

外部の広告識別子を鍵にしてはいけませんか？

制度の側が絞っています。Apple Developerの「User privacy and data use」のページには、iOS 14.5以降は追跡と広告識別子の取得にATTの枠組みでユーザーの許可が要り、許可がなければ広告識別子の値はすべてゼロになる、ハッシュ化したメールアドレスなど別の識別子での追跡にも許可が要る、とあります（2026年10月16日取得。訳は私たちのもの）。鍵の本線は、自社が発番し顧客の同意とともに預かる識別子に置く、が私たちの推奨です。

台帳が整うと、広告の計測も良くなりますか？

プラットフォーム側は、自社データの送信が測定の精度を上げると説明しています。Meta for Businessニュースの2022年2月14日の発表は、コンバージョンAPIでイベントを送信すると、カスタマージャーニー全体を通して広告のパフォーマンスとアトリビューションの測定の精度が上がる、としています（2026年10月16日取得）。送信するイベントの出どころが自社側の記録なので、台帳の整いは広告の計測にも返ってきます。

まとめ

顧客の台帳とは、誰が・いつ・何を・どの経路で買ったかが、顧客単位で1つに繋がって数えられる記録です。管理画面のコンバージョンと売上の実数の突き合わせも、広告経由の成果の新規・既存の分解も、この台帳が前提になります。

台帳が先である理由は3つです。判定の物差しが台帳からしか出ないこと。外部の識別子は制度の側が絞っており、突き合わせの鍵が自社の発番と同意に寄っていくこと。そして、コンバージョンAPIのように、自社側のデータがプラットフォームの計測の精度にも使われること（Meta for Businessニュース 2022年2月14日、2026年10月16日取得）。

つくり方は5つのステップです。3つの帳（受注・会員・接点）の棚卸し、顧客を1人に数える鍵の決定、顧客1行の7つの欄（鍵・初回購入日・直近購入日・購入回数・累計金額・経路・同意）の整備、新規と既存の分解による検収、そして更新の運用（頻度・責任者・定義の固定）。各ステップに「終わると言えるようになること」を置いたので、どこで止まっているかも言えます（このステップは私たちの整理です）。

経路の欄は、成果の確定値ではなく関与の記録として持ちます。ステップ5まで進めば、来月も同じ定義で数えられる状態です。次は、この台帳に広告費を突き合わせる段 ── 広告の採算を、管理画面ではなく台帳側で見る ── で、後続の記事で扱います。

台帳づくりに着手する前の現在地 ── 自社の売上のうち、新規の獲得と既存の継続がそれぞれどれだけを占めているか ── は、顧客資産化診断（7問・約3分）で分解できます。

出典と、書けなかったこと

引用した原文