プラットフォームは何が悪かったかを教えてくれません
GoogleのAPIドキュメントは失敗の仕方をはっきり述べています。正しく書式化されていないデータもそのまま受け入れられる――"but it can't be matched with a customer." 受け入れられたのにマッチしない状態は、アップロードされて無視された状態と見分けがつきません。つまり診断はあなたの仕事です。以下の原因は、確認コストの安い順に並べてあります。
1. ハッシュ化した1つの列を複数プラットフォームで使い回した（30秒）
Google Adsは + 付きのE.164形式の電話番号を指定し、Metaは国番号付きの数字のみを指定しています――例示は 16505551212 です。同じ番号を両方の方法でハッシュ化すると、無関係な2つのダイジェストになり、それぞれ片方のプラットフォームでしかマッチしません。一方はきちんとマッチするのにもう一方がほとんどマッチしないなら、ほぼ確実にこれが原因です。
2. 表示上の値をハッシュ化した（1分）
(650) 555-1212 は 16505551212 ではありませんし、John@Example.com ――大文字と末尾の空白付き――は john@example.com ではありません。どちらのプラットフォームも小文字化と空白除去を明記しています。ハッシュ化したつもりのものと、セルの実際の中身を突き合わせてください。ノーブレークスペースに注意を。TRIM() はこれを除去せず、CSVエクスポートは目に見えない形でこれを混入させます。
3. 二重ハッシュ化または切り詰め（1分）
SHA-256の16進ダイジェストはちょうど64文字です。=LEN(B2)=64 を列に沿って引き下げれば、すでにハッシュ化済みの値の上で数式が走ったケース（128文字の無意味な入力から、ダイジェストのダイジェストが出てくる）と、切り詰められたセルを一度に捕まえられます。
4. エンコードの誤り（5分）
Base64での出力、あるいは小文字が指定されているのに大文字の16進――Metaは小文字16進を明示しています。きれいな検証方法はこうです。Metaが公開しているテスト値 john_smith@gmail.com をハッシュ化し、公開されているダイジェスト（62a14e44…f62f）と比較する。形式か大文字小文字が違って出てくるなら、問題はリストではなくツールの側です。
5. スプレッドシートが先にデータを壊していた（10分）
失われた先頭のゼロ、指数表記になった長い番号、数式として解釈された +44 のセル――すべて無音で、すべてハッシュ化より前に起こります。生の列をスクロールし、E+ と不自然に短い番号を探してください。これはその場では直せません。プレーンテキストの列に取り込み直して作り直してください。
6. プラットフォーム固有のルールを飛ばした（10分）
Googleはメールアドレスに関してGmail固有のクリーンアップを明記しています――ドットと + 以降の除去は gmail.com / googlemail.com のアドレスに限られます。Gmailアドレスの多いリストを一律に正規化すると、まさにその行だけ成績が落ちます。
7. そもそも書式の問題ではなかった
正直な最終節です。マッチングはプラットフォームにログインしているユーザーに対して行われます。古いリスト、小さすぎるリスト、役職アドレス（info@、accounts@）ばかりのリストは、ハッシュ化がどれほど完璧でもうまくマッチしません。1から6まですべて問題なければ、直すべきはリストの質――新しさと実在する個人のアドレス――であって、もう一度の書式調整ではありません。
Hash Dataの位置づけ
上記の失敗のほとんどは、「正しく正規化する」と「正しくハッシュ化する」の隙間で起こります。Hash Dataはその隙間をシートの中で埋めます。=HASHPHONE() は番号をE.164に正規化して1ステップでハッシュ化し、各アルゴリズムの関数はプラットフォームが期待する標準的な16進形式を出力します。
出典
- Google Ads API – Get started with Customer Match – 2026年8月20日閲覧
- Google Adsヘルプ – 顧客データファイルの形式を設定する – 2026年8月20日閲覧
- Meta – Conversions API customer information parameters – 2026年8月20日閲覧