クーパンOpen APIで得られる顧客データとは

端的に言えば、クーパンのOpen APIはストア運営に必要なものはすべて提供する一方で、顧客マーケティング用のリスト構築に必要なものはほとんど提供しません。商品、注文、在庫、出荷・返品センター、交換・キャンセル依頼、顧客からの問い合わせ、そして精算まで取得できます。しかし、購入者のメールアドレスは空の文字列として返り、顧客の実際の携帯番号も、生の電話番号ではなくプロキシ中継番号に置き換えられるケースが増えています。

ShopifyやAmazonに慣れた方であれば、この境界線がいかに重要かを、連携コード作成前に理解しておく必要があります。API経由で取得した連絡先データを前提に構築したCRM、ウィンバック用のメールフロー、あるいはチャネルをまたいだ顧客名寄せのプロジェクトは、依存しているデータをいつまでも受け取れません。ですから、この「壁」がどこにあるのか、そしてなぜそれがクーパンが将来ふさぐ予定の穴ではなく恒久的な設計思想なのかを、正確に把握しておく価値があります。

Open APIは本来何のためのものか

クーパンのOpen APIが公開しているのは運用オブジェクトです。ショッパー（買い物客）を覗き込む窓ではなく、ストアの操作パネルだと考えてください。

各エンドポイントでは、ストア運営者が日々触れるものを管理できます。

• 商品・出品 — カタログ項目とその属性の作成・更新
• 発注（注文） — 出荷が必要な注文の取得
• 在庫 — 在庫数の同期
• 出荷・返品センター — アカウントに紐づく物流拠点の住所
• 交換・キャンセル依頼 — 返品、交換、キャンセルの各フロー
• 顧客からの問い合わせ — 出品に対して購入者が寄せる質問
• 精算 — 支払いの照合ができる金銭面の情報

これだけあればストアをプログラムで運営するには十分です。しかし、エンドユーザーを完全に把握・管理することはできません。この区別は意図的なものです。マーケットプレイスは、出品者がストアフロントを運営する一方で、クーパンがショッパーのアイデンティティの管理者であり続けるように設計されているのです。

越えられないプライバシーの壁：メールアドレスは空で返る

購入者のメールアドレスは、この境界線を最もわかりやすく示す例です。というのも、部分的にマスクされて届くのではなく、そもそもまったく届かないからです。

クーパンが公表しているセキュリティ・プライバシーポリシーによれば、購入者のメールアドレスのフィールドは、注文一覧のレスポンス、単一注文のレスポンス、そしてクーパンの顧客問い合わせのレスポンスのいずれでも、空の文字列として返ります。途中で切り詰められているわけでも、トークン化されているわけでも、遅延して後から取得できるわけでもありません。単に空欄のままです。

これは欧米のセラーがクーパン連携に持ち込む思い込みのなかで最も多いものであり、数か月後にリテンション計画を静かに崩壊させる原因になります。購入後のマーケティング施策全体が「メールリストをエクスポートできる」ことを前提にしているなら、その計画は永遠に空のままのフィールドの上に建てられていることになります。エンジニアリングの工数を投じる前に、クーパン自身の開発者向けドキュメントで各フィールドの正確な挙動を確認できます。どのフィールドに値が入り、どのフィールドが入らないのかについては、そこが正式な情報源です。

実際の電話番号の代わりに「安心番号」

返品集荷や交換の調整のために顧客へ連絡する必要がある場面では、クーパンは顧客の実際の携帯番号ではなく、プロキシ中継番号を渡すケースが増えています。

こうしたプロキシ番号は一般に安心番号（안심번호）と呼ばれます。安心番号は、通話やメッセージを実際の顧客へ転送しつつ、生の電話番号を出品者に一切見せません。これによって、配送業者の手配や交換の確定といった物流面のタスクは完結できる一方で、根底にある個人を特定できる情報（PII）はクーパンが保持し続けます。

設計にあたって押さえておきたい実務上の性質が2つあります。

• 中継番号は顧客のアイデンティティではありません。 それは特定の取引ステージに紐づくルーティング用の識別子です。後で保存して再マーケティングに使える連絡先ではなく、運用上のトークンとして扱ってください。
• 再取得が必要になる場合があります。 返品や交換フローのあるステージで表示された安心番号は、後のステージで必要になる番号とは異なっていたり、相対的に有効期限が切れていたりすることがあります。したがって、番号を無期限にキャッシュするのではなく、都度クエリし直す設計にすべきです。

これはメールに関するルールとまったく同じ論理を、運用上どうしても必要なフィールドに適用したものです。クーパンはタスクを完結させるのにちょうど足りるだけのものを渡し、常設の連絡先レコードを構築できるようなものは一切渡しません。

なぜこうなっているのか、そしてなぜ元に戻らないのか

これらは一時的なAPIの制約ではありません。規制に基づく設計上の選択であり、時間とともにマスキングは緩むのではなく、むしろ増える方向を示しています。

韓国の個人情報の枠組み、すなわち個人情報保護法（개인정보 보호법、PIPA）の下では、購入者の連絡先データは保護対象の個人情報であり、マーケットプレイスはそこで行われる取引の主たるデータ管理者（データスチュワード）と位置づけられます。出品者はその下流にいる当事者です。クーパンによるマスキングは、生のPIIを何千もの第三者出品者に渡すのではなく、この制度下で自らの義務を果たすための方法なのです。原文にあたりたい場合は、政府の法令ポータルであるlaw.go.krで条文そのものを読むことができます。

意思決定者としての正しい読み方はこうです。顧客の識別情報は、自社が保持できるものには決してならないと想定して計画してください。この枠組みの下では、そもそも保持できないように設計されているからです。

「クーパンを自動化する」とは実際どういうことか

クーパンにおける自動化は現実的であり、価値も高いものです。ただし、それは壁のマーケティング側ではなく、運用側に存在します。

連携でできること・できないことの現実的な線引きは次のとおりです。

• 自動化できること： 出品の作成・更新、注文のフルフィルメント、在庫同期、返品・交換の調整、精算の照合。これらは反復的でミスの起きやすいタスクであり、APIが真価を発揮する領域です。
• 自動化できないこと： エクスポートした連絡先リストを使ったD2C（消費者直接）マーケティング。エクスポートできるメールもなければ、ダイヤルできる生の電話番号もありません。

クーパン上でのD2Cマーケティングは、抽出して外部システムに読み込む連絡先リストではなく、クーパン自身のプラットフォーム内ツール、すなわち広告、プロモーション、プラットフォームが管理するメッセージング面を通じて行う必要があります。これはクーパン連携のゴールを捉え直すことにつながります。つまり、あなたが自動化するのはストアであり、顧客へのリーチはプラットフォームの囲われたツールの内側で行うということです。プラットフォーム内のパフォーマンスツールが実際にどのようなものかを知りたい方には、Sales Radarが日次のパフォーマンスデータを週次のアクションに変える方法が具体例になります。これは、クーパンが公開するデータを回避するのではなく、そのデータと共に働くアプローチです。

内製か外注か：連携は一度きりのプロジェクトではない

内製する場合は、単発のスプリントではなく継続的なメンテナンスを見込んで予算を組んでください。APIの仕様はクーパンのスケジュールで動きます。

フィールド、スキーマ、エンドポイントは時間とともに変わります。属性ルールはカテゴリごとに段階的に厳格化されてきました。新しいRocket Growth向けの商品スキーマも、一斉にではなく徐々に展開されてきました。今日動いている連携も、あるカテゴリのルールが変わったり、スキーマのバージョンが置き換えられたりすると、壊れたり、あるいは気づかないうちに異なるデータを返し始めたりします。これは一度きりの構築ではなく、継続的なエンジニアリングです。

最も長持ちする設計原則は、このプライバシーの境界線から直接導かれます。データフローを設計する際は、顧客識別フィールドではなく、安定した運用上の識別子を軸にしてください。 注文ID、出荷ID、安心番号は、APIから確実に取得できるものです。購入者のメールアドレスや生の電話番号は、取得できないものです。社内のレコード、ロジック、結合（ジョイン）を運用上の識別子の上に築いていれば、あなたの連携はスキーマの変動とプライバシー規制の動向の両方に対応し続けられます。逆に、顧客のPIIに依存していた場合、その設計は最初から脆弱なままです。

これは、フローのうち実際の顧客に間接的に触れる部分の扱い方にも影響します。クーパンがRocket Growthの下で顧客対応の返品を処理する一方で返品された商品が自社在庫へ戻ってくる場面や、入庫検品デスクがラベルや認証エビデンスを確認する場面では、あなたが扱っているのは運用オブジェクトと取引ステージ、つまりまさにAPIが渡すよう設計された識別子であって、ショッパーの連絡先情報ではありません。

よくある質問

クーパンのOpen APIから購入者のメールアドレスを取得できますか？ いいえ。クーパンが公表しているプライバシーポリシーに基づき、購入者のメールアドレスのフィールドは、注文一覧、単一注文、顧客問い合わせのいずれのレスポンスでも空の文字列として返ります。使えるメールアドレスへ至るAPIの経路はありません。

安心番号（안심번호）とは何ですか？ 顧客の実際の携帯番号を明かすことなく、通話やメッセージを顧客へ転送するプロキシ中継番号です。根底にある個人情報はクーパンが保持したまま、返品・交換の物流を完結できます。キャッシュするのではなく、フローの後のステージで再取得が必要になる場合があります。

マスキングは時間とともに緩む可能性がありますか？ いいえ。これは韓国の個人情報保護法（PIPA）に由来しており、同法の下ではマーケットプレイスが主たるデータ管理者です。方向性はマスキングの縮小ではなく拡大なので、それを前提に計画してください。

では、クーパン連携では実際に何を自動化すべきですか？ 出品の作成、注文のフルフィルメント、在庫同期、返品・交換の調整、そして精算の照合です。D2Cマーケティングは、エクスポートした連絡先リストではなく、クーパン自身のプラットフォーム内の広告・プロモーションツールを通じて行う必要があります。

フィールドの挙動を自分で確認するにはどこを見ればよいですか？ フィールドレベルの正確な挙動はクーパンの公式開発者向けドキュメントで確認し、規制上の根拠については政府ポータルlaw.go.krでPIPAの条文を読んでください。