- 結論を3行で
- AR効果測定のKPIツリーは事業目的から逆算する
- 目的別に主KPIを1つ決める
- 分母を固定して指標を定義する
- ROIは売上ではなく増分粗利で見る
- 計測イベントとパラメータを公開前に設計する
- 最小イベント辞書を1枚にする
- UTMとQRで入口を分ける
- 推奨イベントとカスタムイベントを使い分ける
- WebAR・TikTok・周遊施策で計測範囲を分ける
- WebARは体験ファネルを自前で計測する
- TikTokは指標名の定義をそのまま読む
- 周遊施策は現地ログと事業成果をつなぐ
- 公開前QAとデータ保護で欠測を防ぐ
- 実機で正常・拒否・失敗を通す
- 二重発火と集計差を確認する
- カメラ画像・位置情報・識別子を棚卸しする
- 分析とレポートを次の意思決定につなげる
- 記述・アトリビューション・増分を分ける
- レポートの列を先に決める
- 離脱地点ごとに次の施策を変える
- よくある質問
- AR施策のKPIに共通の目標値はありますか?
- GA4だけで効果測定できますか?
- カメラ許可を取ると映像は保存されますか?
- 掲出場所ごとにQRコードを分けるべきですか?
- SNSのシェア数はどう測りますか?
- まとめ:次回改善までを設計する
結論を3行で
ARキャンペーンの効果測定は、公開後に数字を見る作業ではありません。目的、分母、イベント、比較基準、次の判断を公開前に固定する設計作業です。

- 事業目的から主KPIを1つ逆算する。再生数や起動数は、目的につながる場合だけ主指標にします。
- 開始・完了・CTA・成果の分母を固定する。同じ名前でもイベント数とユニークユーザー数を混ぜません。
- 計測QAとレポート列を公開前に決める。結果だけでなく、原因・次の施策・担当・期限まで残します。
計測の成否は、ダッシュボードの豪華さではなく、公開前に分母とイベント名を固定できたかで決まります。企画の目的から整理したい場合は、認知・UGC・来店・購買の4目的をまとめたARキャンペーン企画テンプレートを先に確認してください。
AR効果測定のKPIツリーは事業目的から逆算する
KPIは取れる数字の一覧ではありません。事業目的の下に主KPI、原因を診断する補助KPI、実装する計測点を並べます。

目的別に主KPIを1つ決める
主KPIを複数置くと、結果が割れたときに判断できません。意思決定に最も近い1つを主KPIにし、補助KPIは原因を説明できる2〜4個に絞ります。
| 目的 | 主KPI | 補助KPI | 主なデータ源 |
|---|---|---|---|
| 認知 | 対象者への到達 | 動画視聴、AR入口到達、想起 | 媒体分析、調査 |
| UGC | 実投稿数 | エフェクト利用、保存、投稿動画視聴 | プラットフォーム分析 |
| 来店・回遊 | 確認できた来店・到達 | 地点別取得、完走、滞在、クーポン | QR・地点ログ、POS、アンケート |
| 購買・商談 | 購入・有効リード | CTA、商品閲覧、カート、フォーム開始 | GA4、EC、CRM |
| ブランド態度 | 認知・好意・検討の差 | 体験完了、自由回答、満足度 | 接触群・非接触群の調査 |
ブランド態度はアクセスログだけでは直接測れません。JIAAのインターネット広告効果測定ハンドブックも、目的段階に応じてKPIと測定手法を分け、同名指標でも定義差を確認する必要性を整理しています。
分母を固定して指標を定義する
率には必ず分母があります。公開期間、タイムゾーン、ユニーク判定、社内テスト除外、再訪の扱いまでイベント定義書に書きます。以下はWebARで使える定義例です。
| 指標 | 計算式の例 | 判断できること |
|---|---|---|
| 体験開始率 | experience_startのUU ÷ landing_viewのUU | 入口説明・権限・起動導線の摩擦 |
| 体験完了率 | experience_completeのUU ÷ experience_startのUU | 難易度・時間・操作理解 |
| CTA到達率 | cta_clickのUU ÷ experience_completeのUU | 体験と次行動のつながり |
| 成果率 | 購入・来店・有効リードのUU ÷ experience_startのUU | AR入口から事業成果までの到達 |
| CPE | 施策総費用 ÷ experience_startのUU | 有効体験1人あたりの費用 |
イベント回数で割るなら「回数ベース」、UUで割るなら「人ベース」と明記します。再読み込みや連打で数字が増える施策では、この違いだけで結果が大きく変わります。
ROIは売上ではなく増分粗利で見る
ROIの実務式は「(ARが生んだ増分粗利 − 施策総費用)÷ 施策総費用 × 100」です。売上全額を利益とみなさず、制作、媒体、運用、計測、景品、現地対応まで費用に含めます。UTMやクーポンで数えたAR経由成果は、対照群で測る増分効果と分けて報告します。
経営・予算判断としてのROIはARマーケティングのROIとKPI、費用の分母はAR制作の費用相場と見積もり内訳をあわせて使うと整理しやすくなります。
計測イベントとパラメータを公開前に設計する
WebARのページビューだけでは、カメラ許可前に離れたのか、ARが準備できなかったのか、体験を完了したのか分かりません。ユーザーの行動と技術状態を分けてイベント化します。

最小イベント辞書を1枚にする
イベント名、発火条件、重複防止、主要パラメータ、確認画面を1枚にします。次は実装例であり、GA4の公式標準名ではありません。自社の命名規則へ合わせ、公開途中で意味を変えないことが重要です。
| イベント例 | 発火条件 | 主なパラメータ | 注意点 |
|---|---|---|---|
| landing_view | AR入口ページが利用可能になった | campaign_id、entry_point | 単なるHTML要求と分ける |
| camera_permission_result | 許可・拒否・エラーが確定 | result、error_code | 要求時と結果を混ぜない |
| ar_ready | 追跡・素材の準備が完了 | experience_id、load_bucket | ページ表示を体験開始にしない |
| experience_start | ユーザーが体験を開始 | variant_id、placement_id | 自動発火か操作起点か固定 |
| interaction | 意味のある操作を実行 | step_id、action_name | 高頻度イベントを絞る |
| experience_complete | 定義した完了条件を達成 | completion_type、duration_bucket | 画面を閉じただけで発火しない |
| cta_click | 次行動のリンクを選択 | cta_name、destination | 遷移先の成果と別にする |
| share_intent | 共有UIを起動 | channel、content_id | 投稿完了を確認できなければシェア数と呼ばない |
UTMとQRで入口を分ける
ポスター、商品パッケージ、会場サイン、SNS広告、メールで同じQRを使うと、どの入口が体験開始を生んだか分かりません。Google AnalyticsのカスタムキャンペーンURLに沿い、utm_source、utm_medium、utm_campaignを統一し、掲出場所やクリエイティブ差はutm_contentまたはplacement_idで分けます。値は大文字・小文字を区別するため、命名表から発行します。
推奨イベントとカスタムイベントを使い分ける
GA4にはshare、generate_lead、purchaseなどの推奨イベントがあります。実際の共有・リード・購入に該当するなら推奨名と規定パラメータを優先し、AR固有の準備完了・権限結果・追跡失敗はカスタムイベントにします。パラメータは行動の文脈を補うために使い、メールアドレスや氏名を入れません。
WebAR・TikTok・周遊施策で計測範囲を分ける
「Views」「Opens」「体験数」は製品ごとに意味が違います。WebAR、SNS、現地のログを同じ分母へ足さず、接続できる範囲だけを並べます。

| 形式 | 測りやすい範囲 | 接続先 | 主な注意 |
|---|---|---|---|
| WebAR | 入口、権限、準備、操作、完了、CTA | GA4、サーバーログ、EC・CRM | 同意拒否、広告ブロック、端末差 |
| TikTokエフェクト | 投稿動画の視聴、投稿、エフェクトトレイからのOpen、反応 | Effect House Analytics、広告・販売データ | 媒体指標をWebAR起動数へ読み替えない |
| 周遊・現地イベント | 地点到達、順序、完走、特典交換、アンケート | 地点ログ、POS、来場データ | 位置・識別子、営業時間、現場欠損 |
4億回と200万回は到達規模を示す成果値ですが、78mは制作仕様です。数字が大きいことと、KPIであることは同じではありません。事業目的とのつながり、分母、期間、データ源を説明できる数字だけを成果として扱います。
WebARは体験ファネルを自前で計測する
WebARは入口ページと体験コードを自社側で実装できるため、権限結果、AR準備完了、操作、完了、CTAまで細かく定義できます。一方、カメラ映像を端末内だけで処理するのか、サーバーへ送るのかは分析ツールだけでは分かりません。体験ログとデータフローを同じ設計書に載せます。

実画面は体験内容を伝えますが、開始・撮影・保存・投稿・次行動は別々の事実です。計測仕様は新規案件ごとに確認します。
TikTokは指標名の定義をそのまま読む
TikTok Effect HouseのEffect Analytics公式ガイドでは、Viewsはエフェクトを使ったTikTok動画の視聴、Postsはそのエフェクトを使った投稿数、Opensはエフェクトトレイでクリックされた回数、SharesはTikTok内で動画が共有された回数です。外部共有はSharesに含まれず、データは24時間ごとに更新されます。ViewsをAR起動数、Opensを全入口のクリック数として扱ってはいけません。
自社のはてな新曲施策では、公式アカウントへ投稿した3パターンの動画が合計約200万回再生されました。これは動画成果として報告し、エフェクトを開いた人数や投稿完了率とは分けます。はてな「参?」ARエフェクト事例では、3パターンの表現と公式投稿の関係を確認できます。
周遊施策は現地ログと事業成果をつなぐ
周遊型ARでは、参加開始数、地点別到達数、到達順序、完走数、特典交換、アンケートを並べます。アクセスログだけで来店や消費を断定せず、店舗別QR、クーポン、POS、スタッフ記録など検証可能なデータへ接続します。山口県のまち歩きAR業務仕様書でも、利用者数、地点別体験、滞在、初回地点、全地点達成、回遊ルート、アンケート、改善提案まで分析項目に含めています。
回遊率・完走率の定義、QR・GPS・地点ログの使い分けは周遊型イベントのKPI設計で詳しく解説しています。
公開前QAとデータ保護で欠測を防ぐ
公開後に未発火や二重発火が分かっても、失われた期間は戻せません。技術、実機、データ保護の3方向で公開判定します。

実機で正常・拒否・失敗を通す
少なくともiOS・Androidの代表端末で、初回訪問、再訪、カメラ許可、拒否、設定変更後の復帰、低速回線、非対応端末、縦横切替、戻る、再読み込み、連打を確認します。GoogleのGA4検証ガイドが案内するDebugView、Tag Assistant、ブラウザのNetworkを使い、イベント名とパラメータを操作直後に確認します。
| テスト | 期待するイベント | 失敗時の判定 |
|---|---|---|
| 許可して開始 | permission_result→ar_ready→experience_start | 順序・時刻・IDを確認 |
| カメラ拒否 | result=denied、開始なし | 拒否を技術エラーに混ぜない |
| 読込失敗 | error_code、ar_readyなし | 素材・回線・端末で分類 |
| 完了操作を連打 | experience_completeは1回 | 重複防止キーを確認 |
| 社内テスト | test_trafficとして除外可能 | 本番実績へ混入させない |
二重発火と集計差を確認する
GA4、サーバーログ、プラットフォーム分析で総数が完全一致するとは限りません。タイムゾーン、日次締め、同意状態、広告ブロック、ボット除外、重複排除、データ更新時刻をそろえ、差の理由を記録します。公開前テストでは1操作につき何回発火するかを確認し、公開後24時間は入口別・端末別の急落とエラー率を監視します。
カメラ画像・位置情報・識別子を棚卸しする
カメラ許可は映像の保存や二次利用への包括同意ではありません。W3CのMedia Capture and Streamsが示すように、カメラ利用には許可があり、拒否・取消・端末エラーも起こります。画像を端末内処理するのか、送信・保存するのか、顔特徴・位置・端末識別子を扱うのかをデータフローで説明します。
Google Analyticsは個人を特定できる情報の送信を禁止しており、URL、UTM、イベント、カスタムディメンションに氏名、メール、電話番号、精密な位置を入れない設計が必要です。保存期間、閲覧権限、削除方法、外部送信先も公開前に確認します。
分析とレポートを次の意思決定につなげる
効果測定の成果物はグラフではなく、継続・変更・停止の判断です。比較条件、結果、原因、次の施策を同じページに置きます。

記述・アトリビューション・増分を分ける
分析は3段階で考えます。第1段階は「何人が開始し、どこで離脱したか」という記述。第2段階はUTM、QR、クーポンで成果をARへひも付けるアトリビューション。第3段階はARがなければ起きなかった成果を、対照群との差で推定する増分です。
| 段階 | 方法 | 言えること | 言えないこと |
|---|---|---|---|
| 記述 | ファネル、端末別、入口別 | 起きた行動と離脱箇所 | ARが原因かどうか |
| アトリビューション | UTM、専用QR、クーポン、CRM連携 | AR経由と識別できた成果 | 施策がなければ起きなかった成果 |
| 増分 | ランダム化、地域・店舗・時間帯の対照 | 比較条件内での上乗せ効果 | 条件外への無制限な一般化 |
ランダム化が難しいイベントでは、同じ曜日・営業時間・天候帯、類似店舗、前回施策など比較条件をそろえます。完全な因果推論ができない場合は、制約を明記して意思決定に必要な確度を選びます。
レポートの列を先に決める
公開前に空のレポートを作り、次の列を用意します。
| 列 | 記載内容 |
|---|---|
| KPI | 指標名、イベント名、分子、分母、UUか回数か |
| 目標・比較基準 | 自社基準、前回、対照群、設定理由 |
| 実績・差分 | 期間、タイムゾーン、実績、目標差、前回差 |
| 分解 | 入口、端末、日、地点、クリエイティブ |
| 解釈 | 観測事実と原因仮説を分けて記載 |
| 次の施策 | 変更内容、期待する指標変化、担当、期限 |
| データ制約 | 欠測、同意、除外、更新時刻、推定範囲 |
離脱地点ごとに次の施策を変える
入口到達が少なければ告知・掲出場所、許可拒否が多ければ説明と信頼、ar_ready到達が低ければ素材容量・端末対応、開始後の完了が低ければ操作と体験時間、完了後のCTAが低ければオファーと画面順、CTA後の成果が低ければ遷移先と商品条件を見直します。全体平均だけで「クリエイティブを改善」と結論づけず、落ちた段に対応する担当へ戻します。
よくある質問
AR効果測定の目標値、GA4、カメラ、QR、SNSについて、実装前に出やすい質問を整理します。

AR施策のKPIに共通の目標値はありますか?
全施策に使える完了率やシェア率はありません。体験時間、入口、対象者、端末、特典、公開場所で分母が変わるためです。最初は自社の前回値、通常ページ、対照地域・店舗、同条件のクリエイティブを基準にし、目標値には設定理由と期間を書きます。
GA4だけで効果測定できますか?
WebAR内の行動には有効ですが、SNS内の投稿・視聴、現地来店、POS購入、ブランド態度まではGA4だけで完結しません。GA4、プラットフォーム分析、サーバーログ、POS・CRM、アンケートを役割分担し、同じユーザーへ無理に結合せず集計単位を明記します。
カメラ許可を取ると映像は保存されますか?
許可はブラウザやアプリがカメラへアクセスする条件であり、保存の有無は実装次第です。端末内処理だけか、画像・特徴量を送信するか、保存期間と利用目的は別に説明します。許可結果もgranted、denied、errorに分け、映像そのものを分析イベントへ載せません。
掲出場所ごとにQRコードを分けるべきですか?
改善判断が変わる単位で分けます。駅、店頭、会場入口、商品棚で告知や混雑条件が違うなら、utm_contentやplacement_idを変えます。個人ごとのQRが不要な施策では、場所・クリエイティブ単位に留め、URLパラメータへ個人情報を入れません。
SNSのシェア数はどう測りますか?
自社画面で共有UIを開いた回数はshare_intentであり、投稿完了数とは別です。TikTokではEffect HouseがTikTok内のSharesを提供しますが外部共有は含みません。実投稿、投稿動画視聴、共有意図を別行で報告し、取得できない投稿完了を推定値で埋めません。
まとめ:次回改善までを設計する
AR効果測定は、目的を決め、実装し、公開前に検証し、数字を改善へ戻す循環です。次回の施策を良くする資産としてイベント定義書とレポートを残します。

- 事業目的と主KPIを1つ決め、補助KPIを原因診断に使う。
- イベント名、分母、UU・回数、期間、除外条件を公開前に固定する。
- WebAR、SNS、現地データの定義を混ぜず、接続できる段だけつなぐ。
- 実機QA、同意、個人情報、二重発火、集計差を公開判定に含める。
- 結果、原因仮説、次の施策、担当、期限までレポートに書く。
TOBIDASEでは、AR企画、WebAR・エフェクト制作、イベント実装だけでなく、KPIツリー、イベント辞書、UTM・QR、公開前QA、レポート項目の設計まで支援しています。企画書や既存の計測表がある場合はそのまま共有いただけます。ARキャンペーンの効果測定・計測設計について相談する