特典と引き換えに受け取ったメールアドレスを、あとから止められる形にしておく

配布物から個人情報を受け取る導線は、作るのは簡単で、やめるのが難しいという性質があります。

紙に印刷したQRコードは回収できません。入口を閉じても、あとから読み取る人は出てきます。受け取ったアドレスは、送るのをやめても手元に残ります。始める前に、やめ方を決めておく話です。

題材として、AR対応の販促カードが公開している仕様を使います(2026年9月9日時点)。

→ 認証付きのAR対応カードを検討するなら デジスタカード

どこで個人情報が入ってくるか

カードのプランは3つあり、そのうち認証付きのものが該当します。

シリアルコードやログイン認証で対象者だけに中身を公開でき、認証でのメール収集に対応すると記載されています。

流れとしてはこうなります。

カード（QR）→ AR体験 → 認証（シリアル or ログイン）→ 特典の公開
                                   └─ ここでメールアドレスを受け取る

設計上の要点は、認証と収集が同じ画面に同居していることです。利用者から見れば「特典を見るための手続き」であって、「メールアドレスを渡す手続き」という自覚は薄い。ここを混ぜたまま作ると、後から説明できなくなります。

目的ごとに分けて受け取る

最低限、認証のために必要な入力と、継続的な連絡のための同意を分けます。

{
  "serial": "XXXX-XXXX",
  "email": "…",
  "purposes": {
    "unlock":   { "granted": true,  "at": "2026-09-09T12:00:00+09:00" },
    "newsletter": { "granted": false, "at": null }
  },
  "source": { "campaign": "card-2026-autumn", "plan": "auth" }
}

• unlock は、特典を開くために必要な処理
• newsletter は、それとは独立した同意

既定値を false にしておくこと。そして at を必ず持つこと。「いつ同意を得たか」が残っていないと、後から確認できません。

source.campaign を入れておくのも効きます。どの配布物から入ってきたアドレスかが分かると、その配布物ぶんだけを止めるということができます。全部まとめて止めるか続けるか、の二択にしないためです。

「やめる」を3段階で用意する

撤退の粒度を分けておきます。実際に必要になる場面が違います。

段階	何を止めるか	いつ使うか
配信停止	そのアドレスへの送信	利用者からの申し出
導線停止	新規の受け付け	キャンペーン終了時
削除	保持しているデータ	保存期間の満了、利用者からの請求

多いのは、配信停止だけ実装して残り2つを忘れるパターンです。

とくに2番目が抜けやすい。キャンペーンが終わっても、カードは配られたまま世の中にあります。QRを読み取った人が入力欄にたどり着いて、どこにも届かないアドレスを入力する、ということが起こります。

入口を閉じるときは、閉じたことが分かる画面を出します。入力欄を残したまま送信だけ捨てるのは最悪の形です。

if (campaign.status === 'closed') {
  return renderClosed({
    message: 'このキャンペーンの受け付けは終了しました。',
    // 特典そのものは見られる形にできるなら残す
    contentStillAvailable: campaign.contentPublic,
  });
}

期限は印刷物の寿命より長く見積もる

カードは財布に入ります。数年後に出てくることがあります。

ですから、キャンペーンの終了日 = 導線の終了日にしないほうがいい。終了後も「終了しました」と表示するページは生かしておきます。QRの遷移先が404になるのは、体験としても、信頼の面でも悪い。

保持期間は逆に、必要な期間で切る。両者は別のタイマーです。同じ設定値で動かさないようにします。

認証方式で、集まるものが変わる

認証にはシリアルコードとログイン認証の2通りが挙げられていました。性質が違います。

• シリアルコード — カードに印刷された値。刷った時点で確定し、後から変えられない
• ログイン認証 — 利用者のアカウントに紐づく。カード側は入口だけを持つ

シリアルは、印刷物の性質をそのまま引き受けます。発行数は刷った枚数で固定され、流出しても差し替えられません。1枚1コードにするのか、全枚数で共通コードにするのかを、入稿前に決める必要があります。

共通コードは運用が楽ですが、1人に配ったつもりが共有されます。個別コードは管理が要りますが、誰が開いたかが分かるので、配信停止の対象を特定できます。

撤退可能性の観点では、個別コードのほうが扱いやすい。ただし、刷り直しはできないという前提は変わりません。

LINE連携を足す場合、止める対象が増える

オプションとして、AR体験を入口に LIFFブラウザ経由でLINEミニアプリを起動する構成や、公式アカウントの友だち追加へ誘導する導線を設計できる、という機能が用意されていました。その先にスタンプ配布やキャンペーンを重ねる使い方も挙がっています。

導入には企業側の準備が要ります。LINE公式アカウントの開設、LINE Developers での設定(プロバイダー / LIFFアプリ)、アカウントの管理・設定対応。LINEの仕様により、構成や運用方法に応じて設計の調整が必要になる場合がある、とも書かれていました。

ここで効いてくるのが、FAQ にあったこの記述です。

プロバイダーへの公式アカウントの紐付けは1回限りで、あとから差し替えられません。自社環境で構築して紐付けるのが最も安全なフローとして案内されています。

これは撤退可能性が最も低い項目です。アドレスは消せますが、紐付けは戻せません。着手の順序としては、ここを最初に決めます。

なお、利用者が新しくアプリを入れる必要はなく、LINEアプリの上でミニアプリとして起動する、ともありました。利用者側の負担は増えません。増えるのは運用する側が止められないものの数です。

期間

カード自体の製造は、仕様確定後通常1〜2週間程度。LINE連携の組み込みやスタンプの申請(LINE側の審査期間を含む)は、アカウントの準備状況で変動する、とされています。

実装側から見ると、製造期間のほうが読めるということになります。詰まるとしたらアカウント周りです。

チェックリスト

着手前に決めておく項目を並べます。

• [ ] 認証のための入力と、継続連絡の同意を別のフラグで持つ
• [ ] 同意の取得日時を保存する
• [ ] 配布物を識別する値(campaign)を、受け取るデータに含める
• [ ] 配信停止・導線停止・削除を別々の操作として実装する
• [ ] 終了後に表示するページを用意する。404にしない
• [ ] シリアルを個別にするか共通にするかを、入稿前に決める
• [ ] 保持期間のタイマーと、導線の公開期間のタイマーを分ける
• [ ] LINEのプロバイダー紐付けを、着手の最初に決める

仕様は更新されることがあります。設計に入る前に、そのときの記載を確認してください。

本ページはプロモーションが含まれています