Adobe Analyticsでイベントを計測する方法を徹底解説

Adobe Tags、eVar/prop、イベント設計、検証
2025.11.02

はじめに：GA4の自動計測とAdobe Analyticsの違い

Google Analytics 4 (GA4) では、計測タグをサイトに導入するだけでページビュー、スクロール、クリックなど多くのイベントが自動的にトラッキングされます。例えばGA4では、初回訪問（first_visit）や外部リンククリック（click）、スクロール（scroll）、ページビュー（page_view）、セッション開始（session_start）、10秒以上の滞在（user_engagement）、フォーム送信（form_submit）、ファイルダウンロード（file_download）など30種類以上のイベントがデフォルトで収集されます。一方で Adobe Analytics は、GA4のように最初から多彩なイベントが自動取得されるわけではありません。よく言われる「基本的なイベントも自分で設定しないと何も取れない」という話は、概ね事実です。

Adobe Analyticsでは、トラッキングコード（AppMeasurementやLaunch経由のタグ）を各ページに設置すればページビューや訪問数など一部の基本指標は自動的に集計されます。実際、Adobeには標準でいくつかのアウトオブボックス指標（OOTB指標）が用意されており、ページビュー、訪問数(セッション数)、ユニーク訪問者数、平均訪問時間、直帰率、退出率などは追加のカスタム実装なしで計測可能です。またレポートスイートをeコマース用に設定すれば、カート追加数・注文数・売上高といった指標もあらかじめ含まれています。しかし重要なのは、これらの指標が勝手に増えていくわけではないという点です。ページビューや訪問数は各ページでトラッキングビーコン（ヒット）が送信されて初めてカウントされますし、カート追加や購入といった指標もサイト側で対応するイベント送信を実装しなければレポート上はずっと「0」のままです。

要するに、GA4ではタグを入れるだけでユーザーの様々な行動が自動で捉えられるのに対し、Adobe Analyticsでは何をイベントとして計測するかを自分で定義し、その計測処理を実装する必要があるのです。実装の手間という点では「GA4の方が容易で、Adobe Analyticsは初期設定により多くの作業と技術的リソースを要する」と指摘されていますinfotrust.com。この違いから、「Adobe Analyticsの案件は怖いから受けない」というウェブ解析担当者が少なくないのもうなずけます。しかし裏を返せば、Adobe Analyticsではサイトやビジネスに合わせて自由にイベントを設計できる柔軟性があるとも言えます。この記事では、GA4に精通しているもののAdobe Analyticsはこれからという方向けに、Adobeでどんなイベントを計測すべきか50の汎用イベントと30のECサイト向けイベントを厳選し、それらをGA4並みに扱うための設定方法を解説します。未知のものだったAdobe Analyticsのイベント追跡について、「これなら自分にも実装できそうだ」と感じていただけることが本記事のゴールです。

Adobe Analyticsのイベント計測に必要なツールと設定

まずは、Adobe Analyticsでイベントを計測するために知っておくべき製品や設定の概要を整理します。GA4で言うところの「プロパティ設定」「タグ管理」「レポート画面」に相当する要素が、Adobeではそれぞれ異なる名前・役割で存在します。対象読者はこれらの違いが分からないことを想定していますので、順を追って説明します。

  • Adobe Analytics本体（レポートスイート） – データ収集と分析を行うAdobeの分析基盤です。Google Analytics本体に相当し、サイトから送信されたヒット（ビーコン）データを蓄積・集計します。分析UIとして提供されているのが**Analysis Workspace（ワークスペース）**で、GA4の探索やレポート機能に相当します。Workspace上でディメンション×指標の自由分析やレポート作成を行います。
  • Adobe Experience Platform Launch（Adobe Launch） – Adobeが提供するタグ管理ツールです。Google Tag Manager(GTM)に相当し、サイトに埋め込んだLaunchのスクリプトを介してAnalyticsのトラッキングコードを含む各種タグを発火・管理します。イベントの検出条件（クリックやフォーム送信など）と、それに応じてAdobe Analyticsへデータを送信する処理を定義する役割を担います。Adobe Tag Managerという名前の製品はありませんが、一般に「Adobeのタグマネージャー」と言えばLaunch（正式名称: Adobe Experience Platform Tags）を指します。LaunchはAdobe Analyticsだけでなく他のマーケティングタグもまとめて管理できますが、本記事では主にAdobe Analyticsのタグ実装に焦点を当てます。
  • Adobe Analyticsの管理設定（レポートスイート設定） – Adobe Analyticsでカスタムイベントやカスタム変数を利用する場合、あらかじめ管理画面でそれらを定義しておく必要があります。GA4ではイベント名やパラメーターをその場で送信できますが、Adobeではレポートスイートごとにどのイベントスロットを使うか、どのeVar/prop（カスタムディメンション変数）を使うかを決めておく仕組みです。この設定はAdobe Analyticsの管理コンソールから行います。具体的には、**「管理者 > レポートスイート > 編集設定 > 転換 > サクセスイベント」の画面でイベントを追加・編集します。ここでイベントID（event1, event2, …）に対応するわかりやすい名前を付け、イベントの種別（カウンターか数値か通貨か）を設定します。例えば「event1」を「資料請求完了」という名前のカウンターイベントにすれば、以降Analytics上ではevent1が「資料請求完了数」という指標として扱われます。GA4の「カスタム定義（カスタム指標）」に名前を付けるようなイメージです。※Adobeではこのようなカスタムイベントをサクセスイベント（成功イベント）**とも呼びます。

以上をまとめると、Adobe Analyticsでイベントを計測するには:

  1. 計測したいイベントをAdobe Analytics管理画面で定義する。
    （例：event1を「フォーム送信数」として作成し有効化する。必要に応じて種別を「通貨」や「数値」に変更する。）
  2. Adobe Launchでイベント発生時にAdobe Analyticsへデータを送るルールを設定する。
    （例：「お問い合わせフォーム送信」というルールを作成し、トリガーを「対象フォームのsubmitイベント」、アクションでAdobe Analyticsのイベント送信を設定する。）
  3. Analysis Workspaceでデータが正しく計測されているかレポートを確認する。
    （例：Workspace上で「フォーム送信数」イベントの指標をページや参照元ディメンションと組み合わせ、意図通り計上されているか分析する。）

以下では、手順2のLaunchでの実装方法をもう少し詳しく説明し、その後具体的なイベントの例を挙げていきます。

Adobe Launchでのイベント実装手順

Adobe Launch（以下Launch）では、サイト上の特定のユーザー行動を検知してAdobe Analyticsのヒットを送信する設定を**ルール（Rules）**として作成します。LaunchのルールはGTMにおける「トリガー＋タグ」に相当し、イベント（Event）・条件（Conditions）・**アクション（Actions）**の組み合わせで構成されます。「もし○○したら（Event）、△△ならば（Conditions）、Analyticsのヒットを送る（Action）」というIF文のような構造です。基本的な実装フローは次の通りです。

  1. ルールの作成とイベント設定: Launch管理画面の「Rules」セクションで新規ルールを作成し、発火させたいユーザー行動をEventとして追加します。イベントの種類は非常に豊富で、ページ読み込み、クリック、フォーム送信、要素の表示、メディア再生など様々なトリガーが用意されています。例えば「特定のボタンのクリック」をトリガーにしたければ、Core拡張の「クリック」イベントを選び、そのボタンのCSSセレクタやIDを指定します。フォーム送信なら「Submit」イベントを選択し、対象フォーム要素を指定します。
  2. アクションでAdobe Analyticsの変数セット: 次にそのルールにActionを追加し、Extension（拡張機能）から「Adobe Analytics」を選びます。Action Typeにはまず「Set Variables」を選択しますexperienceleague.adobe.com。このステップでは実際に送信するAdobe Analyticsの変数を指定します。Launchの「Adobe Analytics – Set Variables」アクションにはEventsセクションがあり、ドロップダウンから送信したいイベントを選択できますexperienceleague.adobe.com。先ほど管理画面で定義したイベント（例：event1「フォーム送信数」）をここで指定します。必要に応じてイベントに値を渡すことも可能です（整数値や通貨額を入力すればその分イベントを加算できますexperienceleague.adobe.com）。また、イベントと一緒に送る追加のデータがあれば、このSet Variables内でeVarやpropにも値をセットします。例えばフォーム名やボタン名をeVarに設定すれば、「どのフォームが送信されたか」「どのボタンがクリックされたか」といった文脈も分析できるようになります。これはGA4におけるイベントパラメータに相当する考え方で、Adobeではイベント指標（カウント）と組み合わせて分析するための属性データはカスタム変数（eVarやprop）として送信します。
  3. アクションでビーコン送信: Set Variablesで必要な変数をセットしたら、続けてAdobe Analytics – Send Beacon（ビーコン送信）のアクションを追加しますexperienceleague.adobe.com。ここでTrackingの種類としてs.t() もしくは s.tl() を選択できます。s.t() はページビューとして扱われる通常のトラッキングヒット、s.tl() はリンクトラッキングヒット（ページビューにカウントしないイベント送信）に相当しますexperienceleague.adobe.com。一般に、ページ読み込みに伴うイベント（ページビューや仮想ページビュー）はs.t()、ユーザー操作に伴うイベント（クリック、フォーム送信、スクロールなどページ遷移を伴わないもの）はs.tl()で送信します。LaunchのSend Beaconアクションでは、トackingの種類として「ページビュー (s.t())」か「リンク (s.tl())」を選べるようになっているので、用途に応じて選択してくださいexperienceleague.adobe.com。なお、Adobe Analytics拡張ではSet VariablesとSend Beaconを分けず、一度に「Set Variablesして送信」まで行う簡易アクションも提供されていますが、より柔軟な制御のため本記事では分けて設定する手順を紹介しています。
  4. ルールの有効化と公開: ルールの設定が完了したら保存し、Launchのライブラリビルドと公開（Publish）を行います。これで実装は完了です。該当のユーザーイベントが発生すると、LaunchがAdobe Analyticsのビーコン（ヒット）を送信し、サクセスイベントとして計上されるようになります。Experience Cloud Debuggerなどのツールを使えば、実際にイベントが送られているか確認できますexperienceleague.adobe.com。

以上がAdobe Analyticsでイベントを計測する基本的な流れです。ポイントは、「何をもってイベントとするかを明確に設計し、それをAdobe側に登録してから、サイトのタグで検知・送信する」ことです。最初は手順が多く感じるかもしれませんが、GA4でGTMを使ってカスタムイベントを送る場合と考え方は似ています。GA4ではイベント名を自由に決めてGTMのタグで送りますが、AdobeではイベントIDを事前に決めてLaunchのルールで送る、という違いです。

それでは、具体的にどのようなイベントを計測すべきかを考えてみましょう。まずはあらゆるサイトで共通して重要となりうる汎用的なイベント50個を紹介し、それぞれAdobe Analyticsで計測するポイントを述べます。その後、特にECサイト向けに有用なイベント30個についても同様に解説します。

汎用的なイベント50選（サイト種別を問わず重要なイベント）

以下に、Webサイト全般で役立つ汎用的なイベントを50個挙げます。ページビューのような基本指標から、ユーザーのエンゲージメントを測るもの、フォーム送信やクリック、メディア再生、エラー検知まで幅広く含めています。GA4では自動取得されるがAdobeでは手動実装が必要なものについては注釈しています。それぞれのイベントについて、何を計測するものかとAdobe Analyticsで実装する際のポイントを簡潔にまとめます。

● ページビュー・訪問に関するイベント

  • (1) ページビュー (Page View) – ページが表示された回数をカウントする最も基本的なイベントです。GA4ではデフォルトで計測されるイベントですが、Adobeでは各ページにページビュー送信（s.t()）の実装が必要です。通常はLaunchで「全ページ共通のルール」を作成し、DOM ReadyやWindow LoadedトリガーでAdobe Analytics – Send Beacon (s.t()) を発火させますexperienceleague.adobe.com。これによりAdobeの「ページビュー」指標が増加します（Adobe管理画面で特に設定を変更しない限り、ページビューは自動集計されます）。
  • (2) セッション開始 (Visit Start) – 新しい訪問（セッション）の開始を示すイベントです。GA4ではsession_startイベントが自動取得されますが、Adobe Analyticsではセッション（訪問）は最初のページビューが発生した時に自動的にカウントされる仕組みです。特別なイベント実装は不要で、「訪問数 (Visits)」指標として標準提供されています。ただし「初回訪問かどうか」をイベントとして計測したい場合は、VisitorIDの有無で判定してカスタムイベントを発火する実装も可能です（高度な例）。基本的には訪問数は自動集計に任せればOKです。
  • (3) 滞在時間/エンゲージメント (Time on Page/Engagement) – ユーザーがページ上で一定時間アクティブに滞在したかを計測するイベントです。GA4では10秒以上の滞在をuser_engagementイベントとして自動記録します。Adobeでは自動取得されないため、例えば「ページ滞在30秒経過」や「スクロールやクリック等の操作が発生した」ことをもってエンゲージメントとみなし、カスタムイベントを発火させます。具体的には、ページ読み込み後30秒で_satellite.track()やカスタムイベントを発火し、Launchでそれを拾ってAdobe Analyticsのイベント（例: event5「30秒以上エンゲージメント」）を送信します。これにより「エンゲージした訪問」のような指標を計測できます。実装は手間ですが、直帰率や滞在時間では捉えきれない質の高い訪問を把握するのに有用です。
  • (4) スクロール深度 (Scroll Depth) – ユーザーがページをどこまでスクロールしたかを測るイベントです。GA4では初期設定で90%スクロール時にscrollイベントが送信されます。Adobeではスクロール位置を監視して閾値（例えばページ下部から100px手前、あるいはページ全長の◯%）に達したらLaunchのカスタムイベント（イベントタイプ「カスタムコード」など）を発火させ、Adobe Analyticsにイベントを送ります。例えばevent6を「90%スクロール達成」として定義し、ユーザーがページを最後まで読んだ指標として計上できます。実装にはwindow.scrollイベントリスナーで位置をチェックするスクリプトが必要になりますが、一度仕組みを作れば汎用的に使い回せます。長いコンテンツページの読み飛ばし率把握などに役立つでしょう。

● クリックやナビゲーションに関するイベント

  • (5) 外部リンククリック (Outbound Link Click) – 外部サイトへのリンクがクリックされた回数です。GA4では自動的に外部リンクのクリックがclickイベントとして記録されます（対象がドメイン外の場合）。Adobe Analyticsでも、トラッキングコード設定で外部リンクを自動追跡するオプション（s.trackExternalLinks 等）を有効化できます。しかし**「外部リンククリック数」という指標をレポートで見たい場合、Adobeではカスタムイベントを用意する必要があります。例えばevent10を「外部リンククリック数」として定義し、Launchのグローバルルールで外部リンククリック時にevent10を送信するよう設定します（Adobe Analytics拡張のLink Tracking設定でLink Track Eventsにevent10を指定すると、自動追跡時にそのイベントがカウントされます）。こうすることで、どの外部サイトへユーザーが遷移したかを把握できます。なお外部リンクのURL自体はpropやeVar**に格納して送信すれば、どのリンク経由で離脱したか分析可能です。
  • (6) ファイルダウンロード (File Download) – PDFや画像、ドキュメントなどファイルのダウンロード回数です。GA4では一定種類のファイルリンククリックをfile_downloadイベントとして自動で捕捉します。Adobeも、trackDownloadLinksをtrueにすれば指定した拡張子（デフォルトでPDFやxls等）へのクリックを自動で検知しヒットを送ります。ただし標準ではそれらは単なる「カスタムリンクヒット」として処理されるだけで、特定の指標にカウントされません。レポートでダウンロード数を明示するには、こちらもカスタムイベントを用意しましょう。例えばevent11を「ファイルダウンロード数」として定義し、LaunchのLink Tracking設定でLink Track Eventsにevent11を指定します。あるいはダウンロード用のルール（条件：クリックされたURLの拡張子がPDF等）を作成し、Set Variablesでevent11をセットしてSend Beacon (s.tl())を送ります。あわせてダウンロードされたファイル名やパスをeVarにセットすれば、どのコンテンツがどれだけダウンロードされたか詳細に分析できます。
  • (7) 内部リンククリック (Internal Navigation Click) – サイト内のメニューやナビゲーションのクリック回数です。ユーザーがグローバルナビや特定のバナーをどれだけクリックして別ページに進んだかを計測します。GA4ではサイト内リンクは特別扱いされずページビューとして現れるだけですが、Adobeでも通常はそのクリック先でページビューが発生するため、一見追加のイベントは不要に思えます。しかし「トップメニューの〇〇ボタンがどれだけ押されたか」「ホームのバナーから商品ページに遷移した数」などどの内部導線が効果的かを知るには、クリック自体をイベントで計測すると便利です。実装方法として、各重要な内部リンクに対しLaunchでクリックルールを作成し、event12「内部リンククリック数」を送信します。さらにeVarに「リンク名称」や「セクション名」を渡せば、ページ遷移先だけでなくクリックされた場所そのものの人気度を可視化できます。GA4でもイベントを作成して計測するケースですが、Adobeでも同様のアプローチで対応可能です。Activity Map（Adobe Analyticsのリンク解析機能）を使えばページ上のクリック解析もできますが、特定リンクのトレンドを指標化するにはカスタムイベントが有効です。
  • (8) 主要CTAボタンクリック (Primary CTA Click) – サイト内の主要な行動喚起(CTA)ボタンのクリック数です。例えば「資料請求」「お問い合わせ」「無料トライアル開始」といったビジネス上重要なボタンが何回クリックされたかを測定します。これもGA4では自動では取れないためカスタムイベントを設定する部分で、Adobeでも同様にカスタムイベント実装が必要です。まず各CTAごとにeventを割り当ててもいいですが、数が多い場合はevent13「CTAクリック数」という一つのイベントでまとめ、どのCTAかはeVar（例: eVar5=ボタンID）で区別する方法がおすすめです。Launchで対象ボタンのCSSセレクタを指定したクリックイベントを作成し、event13を送信、eVar5にボタン名をセット、といった設定を行います。これでAdobe Analytics上でCTAクリック数を全体・個別に把握できます。GA4経験者なら、タグ設定でボタンごとにイベント送信したのと同じ感覚で、Launchでルールを作っていけばOKです。
  • (9) 内部プロモーションクリック (Internal Promotion Click) – サイト内キャンペーンバナーなどのクリック数です。トップページや一覧ページにある広告バナー・キャンペーン枠がユーザーにクリックされた回数を計測します。GA4ではこれも自動計測されないため、カスタムイベントやカスタムディメンションで対応しますが、Adobeでも同じです。event14を「内部プロモクリック」として設定し、対象要素（バナー画像等）のクリックでevent14を送信します。あわせてプロモーションIDや名前をeVarに送信すれば、どのキャンペーンが何クリックされたか分析できます。AdobeではこのデータをClassification（分類）機能でキャンペーン種別や期間と紐付けることも可能です。なお表示インプレッション数については、後述の「要素表示」のイベントで触れます。
  • (10) ページ内要素表示 (Element View) – 特定のページ内コンテンツがビューに入った回数を測るイベントです。例えば「ホームページのおすすめ商品セクションが閲覧されたか」「記事ページで関連記事ウィジェットが表示までスクロールされたか」等、ユーザーが画面上で実際に見た要素を計測します。GA4には自動ではありませんが、拡張機能やIntersectionObserverを用いたカスタム実装で対応する領域です。AdobeでもLaunchでカスタムコードを使い、対象要素が画面に入るタイミングで_satellite.track('elementView')等のDirect Callを発火、event15「セクション表示」を送信するといった手順になります。スクロールの深度計測と組み合わせ、重要コンテンツの視認率を捉えるのに役立ちます。実装難易度は高めですが、GA4経験者であればGTMで同様のことをしようとした延長で考えれば理解できるはずです。

● フォーム・サイト内コンバージョンに関するイベント

  • (11) フォーム開始 (Form Start) – ユーザーがフォーム入力を開始した回数です。たとえば資料請求フォームの最初のフィールドをクリックした（フォーカスした）時にイベントを発火させ、「フォーム開始数」を計測します。GA4ではform_startイベント（フォームの最初の入力時）を自動収集する場合があります。Adobeでは自動機能はないため、Launchのフォームイベント「Focus」や「クリック」などで実装します。event20を「フォーム開始」に設定し、対象フォームの最初の入力フィールドにフォーカスが当たったタイミングでevent20を送信します。フォーム開始率（開始/表示）を追うことで、フォームがユーザーにどれだけトライされているか分かります。実際の実装では、フォーム要素に共通クラスを付与しLaunchで拾う、あるいは開発者にフォーム開始時に_satellite.track('formStart', {formId: 'X'})を埋め込んでもらい、それをルール（Direct Callルール）で処理する方法などがあります。フォーム離脱分析など高度な解析につなげる入口となるイベントです。
  • (12) フォーム送信完了 (Form Submission) – フォームが実際に送信（成功）された回数です。コンバージョン計測の代表例で、お問い合わせ送信や資料請求送信、会員登録送信などを指標化します。GA4ではform_submitイベントが自動検出されるケースがありますが、信頼性のために明示的に計測することも多いです。Adobeでは当然自動では取れないので、必ず実装しましょう。まずAdobe Analyticsの管理画面でevent1を「フォーム送信完了」として作成しておきます。Launchでは「Form > Submit」イベントタイプを使い、対象フォーム要素をセレクタ指定します。そのルールでevent1をセットし（eVarにもフォームIDや種類をセット）、**Send Beacon (s.tl())**でヒットを送信します。これによりAdobe上で「フォーム送信完了数」という指標が増加していきます。なお、シングルページアプリケーション等でフォーム送信後にページ遷移しない場合でも、この方法で確実にカウントできます。「自分で設定しないと何も取れない」典型例ですが、実装自体はGTMでフォーム送信イベントを拾ってGAに送るのと同程度の労力です。※フォームが正常送信されたかどうか判定するため、可能であれば開発側で送信成功時にデータレイヤーイベントをプッシュしてもらう方が確実です。
  • (13) フォームエラー (Form Error) – フォーム送信時にバリデーションエラー等が発生した件数です。ユーザーが必須項目を埋めずに送信してエラーになった、などコンバージョン障害の分析に用います。GA4では自動計測されないためカスタムイベント領域になります。AdobeでもLaunchで実装しますが、やや工夫が必要です。一般的には、フォーム送信ボタンがクリックされた後にフォーム要素にエラーメッセージが表示されたことを検知してイベントを送ります。例えば、送信ボタンのクリックイベント時に少しディレイを置いて、フォームにエラークラスが付いていないかチェックし、あればevent2「フォームエラー」を送信する、といったカスタムスクリプトをLaunchのカスタムコードアクションで実行します。あるいは開発者にエラー発生時のフックがあれば、そこから直接Launchの_directCall_ルールを呼んでもらう方法もあります。実装難易度は上がりますが、エラー発生率を追うことでフォーム改善に役立つでしょう。event2でエラー数、event1で送信成功数を取り、比率を見るような形です。
  • (14) サイト内検索実行 (Site Search) – サイト内検索が実行された回数です。ユーザーがサイトの検索バーにキーワードを入力して検索した行動を指します。GA4ではサイト内検索クエリをURLクエリパラメータから自動検出してview_search_resultsイベントを収集したりしますが（※要設定）、Adobeではサイト内検索専用の自動機能はありません。ただ、多くのサイトでは検索結果ページに検索キーワードが表示されるため、検索結果ページの表示をもって検索実行とみなす方法が一般的です。具体的には、検索結果ページのページロード時にevent3「サイト内検索」を送信し、同時にeVar1（例えば検索キーワード用eVar）に検索語をセットします。検索語はURLパラメータやページのスクリプトから取得できます。LaunchではページURLに「q=○○」が含まれる場合にルールを発火させる条件を設定し、Set Variablesでevent3とeVar1（値はデータ要素から取得した検索クエリ）を設定、Send Beaconします。これでAdobeレポート上で検索回数と検索ワードランキングが得られます。GA4では検索イベントもパラメータとしてキーワードが取れますが、Adobeでも同様にイベント＋eVarの組み合わせで実現します。
  • (15) サイト内検索結果ゼロ (Zero Search Results) – 検索結果が0件だった検索の回数です。ユーザーが何か検索したものの結果が見つからなかったケースを計測します。これはGA4でも自動では取れず、カスタム実装が必要です。Adobeでは、検索結果ページでヒット数が0だったことを条件に別途event4「ゼロ検索結果」を送信します。例えば検索結果件数がページHTMLに表示されているなら、その値を読み取って0の場合にLaunchのルールを発火させます。あるいはデータレイヤーに検索ヒット数を埋め込んでもらい、それを条件にする方法もあります。ゼロ結果率が高いキーワードはコンテンツの穴を示すため、SEOやサイト改善に活かせます。実装は検索実行イベントとセットで行うとよいでしょう。
  • (16) ログイン (Login) – ユーザーがサイトにログインした回数です。会員制サイトやECサイトなどで重要な指標です。GA4には自動イベントはないものの、loginという推奨イベントが用意されています。同様にAdobeでもログイン時にeventを送ります。例えばevent30を「ログイン完了」と定義し、ログイン成功ページの表示や、ログイン処理完了時のカスタムイベントでevent30を発火します。Launch実装では、ログイン後に遷移するマイページトップの読み込み時にevent30を送信する方法や、ログインボタン押下後にJavaScriptで_satellite.track('loginSuccess')を呼んでDirect Callルールで処理する方法などがあります。あわせてログインユーザーIDを（個人を特定しないIDで）eVarにセットしておけば、以降のヒットにユーザー識別子を紐付けることも可能です（ただし個人情報の扱いには注意）。ログイン率やアクティブユーザー分析に用います。
  • (17) ログアウト (Logout) – ユーザーがログアウトした回数です。重要度は高くないかもしれませんが、ログインとの対になるイベントです。実装する場合、ログアウトリンクのクリック時にevent31「ログアウト」を送信します。これにより平均セッション長や滞在行動との関連を見ることもできますが、必須ではないでしょう。GA4では特に用意されていないイベントですので、必要に応じて。
  • (18) 新規会員登録 (Sign-Up) – ユーザーが新規アカウント登録した数です。会員サイトやサービスサイトでの主要コンバージョンです。GA4ではsign_upイベント（推奨イベント）があり計測できますが、Adobeでもぜひ計測しましょう。フォーム送信完了イベントの一種ですが、特に新規登録はLTVに関わる重要な指標となるため専用のイベントを割り当てる価値があります。event32を「会員登録完了」と定義し、会員登録完了ページ表示や完了時のスクリプトでevent32を送信します。実装はフォーム送信と同様の手順です。登録経路分析やマーケティング効果測定（どの流入で登録が多いか）に役立ちます。
  • (19) メールマガジン登録 (Newsletter Subscription) – ニュースレターやメルマガ購読の申し込み数です。これもフォーム送信の一種ですが、マーケティングKPIとして重要なので別イベントで計測する例が多いです。GA4では明確な自動計測対象ではないため、Adobeでもカスタム実装します。event33を「メルマガ登録」とし、登録完了時に送信。ポップアップで取得する場合などは、登録完了ボタンのクリックで送る方法もあります。今後のメール開封・購読維持率などとの付き合わせなど高度な分析も可能です。
  • (20) アンケート回答送信 (Survey Submitted) – サイト上のアンケートやフィードバックフォームの送信数です。ユーザー満足度調査などサイト内で行った際に、その回答送信をカウントします。これも基本はフォーム送信なので、eventを用意し送信完了時に計測します。例えばevent34「アンケート送信」を作り、回答完了ボタンでevent34を送ります。回答内容自体はAdobe Analyticsではテキスト収集に向かないため、集計は外部システムになるでしょうが、「何件回答が集まったか」をリアルタイムに把握する目的で役立ちます。GA4でもカスタムイベント領域です。
  • (21) エラーページ閲覧 (Error Page View) – 404エラーなどページが表示できなかった場合の発生数です。GA4ではエラー検知専用の自動イベントはありません（カスタムでException送信は可能）が、Adobeでも手動実装が必要です。方法としては、404エラーページのトラッキングコードでevent40「エラーページビュー」を送ります。ページ名（例えば”404: URL”）を設定し、さらにeVarにリクエストURLを入れておけば、どのページへのアクセスで404になったか分析できます。サイトの死んだリンクを洗い出したり、ユーザーが辿り着けなかったコンテンツの把握に有用です。Launch実装では「Window Loaded時にdocument.titleやURLを見て’404’を含む場合にevent40を送信」といったルールを作ることもできます。
  • (22) JSエラー発生 (JavaScript Error) – フロントエンドのJavaScriptエラーが発生した回数です。ユーザー体験に影響する重大な情報ですが、GA4には標準では収集されません（Monitoringツール等別途）。Adobeでも通常は収集しませんが、必要に応じてイベントを送れます。window.onerrorでキャッチした内容をLaunchに渡し、event41「JSエラー発生」を送ります。エラーのメッセージやURLをカスタム変数で送っておけば開発フィードバックに使えます。ただし量が多くなる可能性もあるので慎重に実装してください。

● メディア再生・コンテンツ消費に関するイベント

  • (23) 動画再生開始 (Video Play) – 埋め込み動画の再生開始回数です。GA4ではYouTube動画埋め込みであれば自動トラッキング（要設定）できますが、それ以外はカスタム実装になります。Adobeでは動画計測専用のMedia Analytics機能もありますが、ここでは基本的なイベントとして扱います。動画の再生ボタンがクリックされたらevent50「動画再生」を送信し、eVar10に動画IDやタイトルをセットします。LaunchではHTML5の<video>要素に対する「Play」イベントタイプや、YouTube APIを利用したカスタムコードで実装します。再生回数はコンテンツの人気指標になります。AdobeのMedia Moduleを用いるとより詳細な視聴指標（再生時間や完了率）を収集できますが、まずはシンプルに再生開始イベントを押さえるだけでも効果的です。
  • (24) 動画視聴25%/50%/75% (Video Milestones) – 動画の再生進捗に応じた視聴完了度です。GA4でもYouTube動画は25%単位の進捗イベントを自動取得できますが、Adobeでも同様に区切りの再生地点でイベント送信すると良いでしょう。例えばevent51「動画50%視聴」を用意し、動画再生時間が全体の50%に到達した時にLaunchのMedia時間イベント（またはカスタムタイマー）でevent51を送ります。これにより動画の半分以上見たユーザー数などを測定できます。Media Analyticsを使う場合は自動でQuartile計測されますが、手動でも重要動画なら実装価値があります。完了率の高い動画とそうでない動画の比較などに使えます。
  • (25) 動画視聴完了 (Video Complete) – 動画を最後まで視聴した完了回数です。GA4でもYouTube動画完了は自動イベントになりますが、Adobeでもぜひ計測したい指標です。event52「動画完了」を設定し、動画終了時（endedイベント）に送信します。視聴完了率＝完了数/再生開始数でコンテンツ消費度合いが分かります。Launch実装では動画要素の「Ended」イベントタイプを使います（HTML5動画の場合）。YouTube埋め込みならYouTube Player APIのonStateChangeでEndedを検知し、Launchのカスタムイベントを発火させる方法になります。動画コンテンツ戦略の評価に欠かせないイベントです。
  • (26) 音声コンテンツ再生 (Audio Play) – ポッドキャストや音声の再生開始数です。サイトに音声コンテンツがある場合に計測します。動画と同様の考え方で、event53「音声再生」を送ります。HTML5 <audio>タグのplayイベントや、埋め込みプレーヤーのAPIからLaunch連携して実装します。以降の進捗や完了も動画と同様に計測できます。
  • (27) ファイル閲覧 (PDF View) – PDF等の埋め込みコンテンツが表示・閲覧開始された回数です。ダウンロードではなくページ上に埋め込まれたPDFやドキュメントビューアなどの閲覧を指します。例えばホワイトペーパーをPDF埋め込みで読めるようにしている場合、その閲覧開始をevent54「PDF閲覧開始」で計測します。実装はビューアのJavaScriptイベントや、ビューボタンのクリックから判断します。GA4には自動計測されないため、Adobeで独自実装する事例です。
  • (28) コンテンツ共有 (Content Share) – ユーザーがサイト上のコンテンツを共有（シェア）した回数です。ブログ記事の「Share to Twitter/Facebook」ボタンがクリックされた回数や、「メールで共有」アクションの実行数を計測します。GA4ではshareイベントがありますが自動では発火しませんので、Adobeでもカスタム対応が必要です。event60を「コンテンツ共有」として、共有ボタンのクリックで送信します。eVarに共有先（Twitter等）を記録すれば、どのチャネルに人気か分析できます。SNS流入の誘発状況を知る手がかりになります。
  • (29) コメント投稿 (Comment Submitted) – ユーザーが記事や商品にコメント/レビューを投稿した数です。UGC（ユーザー生成コンテンツ）の活発度合いを測ります。GA4では特に用意はないのでカスタムイベントになります。Adobeでもフォーム送信の一種として、コメント投稿完了時にevent61「コメント投稿」を送ります。コメント本文はAnalyticsに送らず、投稿完了の事実だけをカウントします（必要に応じてeVarに投稿種別など）。これによってユーザーエンゲージメントを定量化できます。
  • (30) 評価・投票 (Rating/Vote) – ユーザーが星評価や投票を行った回数です。例えば製品に星評価☆を付けた、記事を「役に立った/立たなかった」投票した、といったアクションです。GA4では自動ではないのでカスタムイベント領域、Adobeでも同様です。event62「評価実施」を設定し、評価ボタン押下時に送信します。評価内容（何点を付けたか）はeVarで送るか、あるいはイベントを数値イベントにして評価点をそのまま値として送る方法もあります。後者の場合、例えばevent62を数値タイプに変更し、5点満点評価なら5を送れば平均評価点のような指標も計算可能です。ただ実装と設計が少し高度になるため、まずはカウントだけでも良いでしょう。
  • (31) お気に入り追加 (Add to Favorites) – ユーザーがお気に入り登録・ブックマークした回数です。記事のお気に入り、商品のウィッシュリスト追加など、ユーザーの関心を示す行動です。GA4にはadd_to_wishlistというEC向けイベントがありますが一般サイトではカスタム対応になります。Adobeでもevent63「お気に入り追加」を送信し、対象のコンテンツIDをeVarにセットすることで計測します。お気に入り登録者数や頻度が把握でき、人気コンテンツの指標にもなります。
  • (32) アプリダウンロードクリック (App Download Click) – モバイルアプリのダウンロードリンクがクリックされた回数です。サイト上からApp StoreやGoogle Playへのバナーをクリックした数を指標化します。GA4では外部リンククリックとして取得されるか、カスタムイベントを送るケースです。Adobeでは外部リンククリックの一種なので、先述の外部リンクイベント(event10)でまとめても良いですが、重要KPIなら専用にevent64「アプリDLクリック」を設けるのもアリです。Launchで対象のストアリンククリックに対しevent64送信、と実装します。モバイル誘導の効果測定に繋がります。
  • (33) 印刷実行 (Print Page) – ユーザーがページ印刷を実行した回数です。ブログ記事やレシピサイトなど、印刷ボタンがある場合の利用状況を測ります。GA4では自動計測されないため、Adobeでもカスタムイベントで対応します。ブラウザの印刷ダイアログ表示イベント（window.onbeforeprintなど）は扱いづらいですが、サイト内に「印刷」ボタンがあるならそのクリックでevent65「印刷実行」を送ります。印刷ニーズの高いコンテンツの把握に役立つでしょう。
  • (34) 地図・店舗検索アクション (Map Interaction) – 埋め込み地図の操作や店舗検索の実行回数です。店舗検索ボタンを押した、地図を拡大/縮小した、ピンをクリックした等を指標化します。GA4では自動はなく、Adobeでもサイト固有の実装となります。たとえば店舗検索ボタン押下でevent66「店舗検索」を送信し、検索された店舗名や地域をeVarに入れる、地図のドラッグやズームは深追いしすぎると実装コストが高いので主要な操作だけイベント化する、といった方針になります。オフライン店舗への関心を測るKPIとして定義します。
  • (35) チャット開始 (Live Chat Initiated) – Web接客やサポート用のライブチャットが開始された回数です。サイトにチャット機能を設置している場合、ユーザーがチャットを開いた（オペレーターまたはボットとの対話を開始した）ことをイベントで捉えます。GA4では自動ではないのでカスタムイベントを設定します。Adobeでも、チャットウィジェットのAPIやJavaScriptイベントを利用してevent70「チャット開始」を送信します。例えばボタン式ならクリックで送信、画面下からチャットウィンドウが開いたタイミングでカスタムコードから_sendBeacon_を呼ぶなど。チャット利用率が高いページや、チャットからのコンバージョンを分析するのにデータが役立ちます。
  • (36) チャットメッセージ送信 (Chat Message Sent) – ユーザーがチャットでメッセージを送った回数です。単にチャットを開いただけでなく実際に問い合わせを入力したかを測ります。チャット開始数に対する実利用率を知るためのイベントです。実装はチャット提供プラットフォーム側のカスタムフックを使い、ユーザー送信時にAdobeイベントを発火させます。event71「チャットメッセージ送信」を設定して収集します。
  • (37) UI機能トグル (Feature Toggle) – ユーザーがサイトのUI設定を切り替えた回数です。例えばダークモードのON/OFF切替、言語切替、レイアウト切替などサイト内の表示設定をユーザーが変更できる場合、その操作を計測します。GA4ではカスタム、Adobeでもカスタム対応です。event72「UI設定変更」を送り、eVarに「ダークモードON」等どんな変更かを記録します。利用率を知りUX改善の材料とできます。
  • (38) フィードバック送信 (Feedback Submitted) – サイトフィードバックフォーム（簡易な満足度ボタン等）の送信数です。例えば各ページに「この情報は役に立ちましたか？」Yes/Noボタンがある場合の集計です。これもフォーム送信の一種なので、event73「フィードバック送信」としてYesクリックやNoクリック時に送信します。Yes/Noそれぞれ別イベントにするより、eVarに「Yes/No」を持たせる方が実装が少なく済みます。ユーザーの生の声をダイレクトに反映する指標として重宝します。
  • (39) ソーシャルフォロークリック (Social Follow Click) – TwitterやInstagramなどSNSのフォローボタンがクリックされた回数です。サイトから公式SNSへ誘導するリンクのクリックを測定します。外部リンクの一種ですが、SNSごとにイベントや変数で区別します。例えばevent74「ソーシャルフォロークリック」を定義し、クリック時に送信、eVarに”Twitter”や”Instagram”等サービス名をセットします。どのSNSが人気か、どれくらいフォロー誘導できているかを把握できます。
  • (40) コンテンツインプレッション (Content Impression) – ページ内の特定コンテンツがユーザーの視界に入ったインプレッション数です。#10で説明した「ページ内要素表示」と重なりますが、特に広告やプロモーション要素のインプレッションとして重要なものを別途計測する場合です。例えばトップのカルーセルバナーが何％のユーザーに表示されたか等。実装は#10と同様にIntersection Observer等で検知しイベント送信します。GA4では手動対応領域です。
  • (41) カルーセル操作 (Carousel Navigation) – トップページなどのスライダー（カルーセル）でユーザーが手動操作した回数です。複数枚のバナーを切り替えるUIで、ユーザーが「次へ」をクリックしたりスワイプした回数を測ります。これによりユーザーが自主的に複数枚目以降も見ているかが分かります。実装はカルーセルのJSイベント（例: 次へボタンクリック）でevent75「カルーセル操作」を送ります。バナーの自動切替に対する能動的操作の割合が分かり、コンテンツ配置の参考になります。
  • (42) 比較機能使用 (Compare Feature Used) – 商品比較機能など、複数アイテムを選択して比較表示する機能が使われた回数です。これは後述のECイベントにも関連しますが、一般サイトでも例えばプラン比較などで類似機能があれば計測対象です。GA4ではカスタム、Adobeでもevent76「比較利用」を送ります。ユーザーが何をどれだけ比較したかはeVarにIDsを入れるなど高度になりますが、まず利用したか否かのカウントだけでも有用です。
  • (43) コンテンツコピー (Text Copy) – ユーザーがページ内のテキストをコピーした回数です。選択して右クリックコピーやCtrl+Cを検知します。これはかなりニッチですが、例えばコードスニペットを共有する技術サイトやクーポンコードをコピーさせるページなどでは指標になりえます。実装はdocument.addEventListener('copy', ...)でclipboardイベントを捕まえ、event77「テキストコピー」を送ります。GA4では自動ではなく、Adobeでも凝った実装ですが、興味深いユーザー行動の一つです。
  • (44) ページ離脱意図 (Exit Intent) – ユーザーがページから離れようとした兆候の検知回数です。マウスがブラウザの閉じるボタン付近に急に移動した場合などにポップアップを出すUXがありますが、その離脱意図をイベント記録するものです。GA4には無関係、Adobeでも高度なカスタム実装ですが、マーケティング的には離脱ユーザーの傾向を掴む材料になります。実装例として、ページでmouseleaveイベントを監視し、画面上部から出た場合にevent78「Exit Intent」を送る、といった形です。ただし精度やノイズもあるため、実装優先度は低めでしょう。
  • (45) オンラインチャットリクエスト (Support Contact Requested) – ユーザーが「お問い合わせ」や「サポートチャット開始」を試みた回数です。先述のライブチャット開始と重複する場合もありますが、例えばチャットではなく「お問い合わせフォームへ遷移する」ボタンを押したケースなども含め、ユーザーがサポートを求めた行動全般を指します。event80「サポート問い合わせクリック」を送信し計測します。GA4ではカスタムイベント領域です。サイト運営側のリソース計画（問い合わせ増減など）にも役立ちます。
  • (46) デバイス回転 (Orientation Change) – モバイル端末で画面の向き（縦横）が変わった回数です。一見関係なさそうですが、動画プレイヤーで縦横切替をトリガーにフルスクリーンにするUIなどではヒントになります。実装はwindow.onorientationchangeでeventを送るだけですが、分析上使いどころは限定的です。特定のUX検証目的で導入する例が考えられます。
  • (47) ページフォーカス復帰 (Tab Focus) – ユーザーがタブを戻ってきた（ページを再びアクティブにした）回数です。長くタブを放置後に戻った場合や、別タブから戻った場合に発火します。Launchには「Tab Focus」というイベントタイプがあり、これを使ってevent81「タブ復帰」を送れます。これもデータ活用の難易度は高いですが、例えば離脱しかけたユーザーが戻ってきてコンバージョンしたケースを探るなど特殊な分析に使えます。
  • (48) ページ非アクティブ (Tab Blur) – ユーザーがタブを離れた（ページが非アクティブになった）回数です。上記Tab Focusの逆で、Launchの「Tab Blur」イベントを使います。ユーザーが別のタブに行ったりウィンドウを隠したタイミングです。直帰の予兆や動画視聴放棄の検出など応用できますが、これ自体をKPIとすることは稀でしょう。
  • (49) ファイルアップロード (File Upload) – ユーザーがサイト上でファイルをアップロードした回数です。例えばプロフィール画像のアップロード、資料提出フォームでのファイル添付などです。GA4では自動なし、Adobeでもカスタムです。Launchで<input type=”file”>のchangeイベントを拾ってevent82「ファイルアップロード」を送ります。アップロード成功時に限定したければサーバー側と連携が必要になるため、簡便にはファイル選択動作の発生として捉えることが多いです。
  • (50) コンバージョン完了 (Conversion Completed) – 上記に挙げたような重要なコンバージョン（フォーム送信や購入など）の完了をまとめて扱う概念的なイベントです。これは具体的な単一イベントではなく、サイトごとに「主要コンバージョン」が何かを定義し、その完了数を計測するという意味になります。GA4では「コンバージョンにマークしたイベント」を指標として管理画面上で見ることができます。同様にAdobeでも、主要コンバージョンとなるイベント（例えば資料請求送信、デモ申込送信など）それぞれを実装し、必要に応じて合計を計算することでKPI管理します。イベントの実装そのものは各該当イベント（フォーム送信など）ですが、最終的な事業ゴール指標としてこれらを位置付けましょう。

以上、汎用的な50イベントを網羅しました。ここに挙げたイベントは、サイトの種類問わず有用なものですが、すべてを実装する必要はありません。サイトの目的に応じて重要なユーザー行動を選び、優先順位高く実装していくと良いでしょう。「Adobeでは自動では取れない」と言われるイベントも、仕組みを理解すれば一つ一つ着実に計測できることがお分かりいただけたと思います。

ECサイト特有のイベント30選（eコマース向け計測ポイント）

次に、ECサイト（通販サイト）に特化したイベント30個を紹介します。商品閲覧から購入完了までの一連のユーザー行動や、ショッピング特有の指標を計測するものです。GA4ではあらかじめ推奨イベントが定義されている領域ですが、Adobe Analyticsでも適切に実装すれば同等の分析が可能です。AdobeにはEC向けの予約語イベント（prodViewやscAddなど）や製品変数（products変数）が用意されており、これらを活用することで売上や購買行動のトラッキングが行えます。以下、GA4のイベント名も参考にしつつ、ECサイトで重視すべきイベントとAdobeにおける設定方法を見ていきます。

● 商品閲覧・検索に関するイベント

  • (1) 商品詳細ページ閲覧 (Product Detail View) – ユーザーが商品の詳細ページを閲覧した回数です。GA4のview_itemイベントに相当し、ECサイトでは基本中の基本指標です。Adobeでは、商品詳細ページの表示時に**prodView** というイベントを送信するのが一般的です。prodViewはAdobeの予約語イベントで、送信されると自動的に「商品閲覧数 (Product Views)」指標が増加します。実装方法として、Launchのページロードルール（またはグローバルのページビュー送信）で、商品詳細ページの場合にはs.eventsにprodViewを含めて送信します。またこの際、s.products変数に商品IDやカテゴリ、価格などを設定します。例えばs.products="Category;ProductID"という形式で商品を指定すると、その商品に対する閲覧としてレポートされます。Adobe Analytics管理画面で特にカスタムイベントを作らなくても、prodViewを使えば自動的に「商品閲覧数」指標が利用できます。GA4における商品ページビューがAdobeでも適切にカウントされるよう、漏れなく実装しましょう。
  • (2) 商品リスト閲覧 (Product List View) – ユーザーが商品一覧ページ（カテゴリページや検索結果ページ）を閲覧した回数です。GA4ではview_item_listイベント（商品リストの閲覧）が推奨されています。AdobeにはprodViewに類する予約イベントはありませんが、商品一覧も分析上重要なためカスタムイベントで計測します。例えばevent85を「商品リスト閲覧」と定義し、カテゴリ一覧ページや検索結果ページ読み込み時にevent85を送信します。あわせてproducts変数に一覧に表示された商品群のIDやカテゴリー情報を入れておくことも可能ですが、通常は一覧閲覧自体の回数を指標化できれば十分な場合が多いです。商品一覧から詳細ページへの遷移率を調べたり、人気カテゴリページのPVを把握するのに使えます。実装はページ種別の判定がポイントになります（URLやテンプレートで条件分岐）。
  • (3) 商品クイックビュー (Quick View Usage) – 商品一覧上でのクイックビュー機能が使用された回数です。商品ページに遷移せず、その場でポップアップで商品詳細を見るUIを設けているサイトがありますが、その利用頻度を測ります。GA4では特に用意されていないのでカスタムイベントとなり、Adobeでもevent86「クイックビュー表示」を実装します。クイックビューボタンのクリックやポップアップ表示時にevent86を送信し、products変数に対象商品のIDを入れておけば、どの商品がクイックビューで見られたかも分析できます。このイベントにより、ユーザーがどの程度一覧上で情報を完結させているかが分かります。
  • (4) 商品検索実行 (Product Search) – サイト内で商品検索が行われた回数です。一般サイト向けに「サイト内検索」は汎用イベント(14)で挙げましたが、ECサイトでは特に商品検索の頻度やキーワードが重要です。Adobeでは前述の手法と同様に、検索結果ページ表示でevent3「サイト内検索」（または専用にevent87「商品検索」）を送り、検索クエリをeVarに保持します。さらにECでは、検索結果に商品が何件出たかやクリックされたかまで分析したいところです。検索結果件数は#15のゼロ結果イベントで言及したように、ヒット件数0のときevent4「0件検索」を送るなどの工夫をします。検索キーワードのランキングやコンバージョンとの関係は、Adobeでも収集データがあればGA4同様に分析可能です。

● カート・購入プロセスに関するイベント

  • (5) 商品をカートに追加 (Add to Cart) – ユーザーが商品をカートに追加した回数です。ECサイトの重要イベントで、GA4でもadd_to_cartとして推奨されています。Adobeでは**scAdd** (shopping cart add)という予約イベントを使うことで「カート追加数 (Cart Additions)」指標が自動計上されます。実装では、商品詳細ページや一覧から「カートに入れる」ボタンがクリックされた際に、Launchのルールでs.events="scAdd"をセットして送信します。必ずproducts変数にどの商品が追加されたかを指定します（例: s.products="Category;ProductID;1" 数量1を追加）。これによりAdobe Analytics上で何件のカート投入があったか、またどの商品が何回カートに入れられたか把握できます。なおscAddはカスタムイベント定義不要の標準イベントですが、使用前にレポートスイートで「Cart Additions」指標（これはデフォルトで有効になっています）を確認しておきましょう。
  • (6) 商品をカートから削除 (Remove from Cart) – ユーザーがカートから商品を削除した回数です。GA4ではremove_from_cartイベントが該当します。Adobeでは**scRemove**という予約イベントがあり、「カート削除数 (Cart Removals)」指標を増加させます。実装は、カートページで「削除」ボタンが押されたときにs.events="scRemove"を送ります。これもproducts変数に対象商品を指定することで、どの商品が削除されたかもデータ収集可能です。カート離脱の分析に役立ちます。scRemoveもAdobeのEC標準イベントの一つです。
  • (7) カート閲覧 (View Cart) – ユーザーがカートページを閲覧した回数です。商品を追加後にカートを見る行動や、ヘッダーの「カートを見る」クリックなどを含みます。GA4では特にイベントはありません（view_cartは推奨イベントとして存在します）のでカスタムに近いですが、Adobeには**scView**という予約イベントがあり、「カート閲覧数 (Cart Views)」指標を提供しています。カートページ（またはサイドカート表示）を表示した際にs.events="scView"を送ることで自動的にカウントされます。実装上は、カートページ読み込み時のLaunchルールか、Ajaxでカートが表示されたときにDirect Callで処理するかになります。scViewにより、どれだけのユーザーが実際にカートまで進んだか（＝関心を持ったか）を測定できます。
  • (8) チェックアウト開始 (Begin Checkout) – ユーザーが購入手続き（チェックアウト）を開始した回数です。GA4のbegin_checkoutイベントに相当し、カートから「レジに進む」ボタンをクリックした、またはチェックアウトフローの最初のページを表示したタイミングを指します。Adobeでは**scCheckout**という予約イベントがあり、これを送信すると「チェックアウト数 (Checkouts)」指標が増えます。実装としては、チェックアウトフローが複数ページに分かれている場合、最初のステップページ（お届け先情報入力ページなど）の表示時にs.events="scCheckout"を送り、products変数に現在のカート内商品の一覧をセットします。シングルページアプリケーションの1ステップチェックアウトなら、「購入手続き開始」ボタンのクリック時に送る形になります。scCheckoutにより、何件の購入意向があったか（購入開始したか）がわかります。なおAdobeではチェックアウトステップごとにさらに詳細を追跡する場合、独自にeventを追加定義して送信します（例: event88「配送情報入力完了」、event89「支払情報入力完了」など）。
  • (9) 配送情報入力 (Add Shipping Info) – ユーザーがチェックアウトで配送先情報を入力完了した回数です。GA4ではadd_shipping_infoイベントが推奨されています。Adobeには直接対応する予約イベントは無いので、カスタムイベントで計測します。例えばevent90「配送情報入力完了」を定義し、ユーザーが住所や配送方法を入力し次へ進んだタイミングでevent90を送信します。実装は、チェックアウトフローの「支払い情報入力ページ」が表示された時点で「前の配送情報入力が完了した」とみなすか、あるいは「次へ進む」ボタン押下時に直接送信します。どのくらいのユーザーが住所入力まで到達したかが分かり、購入プロセスのドロップオフ分析に用います。このイベントはAdobeでは任意実装ですが、GA4の計測項目にならって設定しておくと比較・移行時にも役立つでしょう。
  • (10) 支払い情報入力 (Add Payment Info) – ユーザーが支払い（決済）情報を入力完了した回数です。GA4ではadd_payment_infoイベントがあります。同様にAdobeでもevent91「支払い情報入力完了」を定義して計測します。多くの場合、支払い情報入力後は確認画面や完了画面に進むので、確認画面表示をもってこのイベントを送る設計も可能です。あるいは「支払い方法選択」のドロップダウン変更時にイベント送信するケースも考えられます。配送情報入力と組み合わせ、どの段階で離脱が起きやすいかを分析できます。実装方法自体は(9)と似ています。
  • (11) クーポン適用 (Apply Coupon Code) – ユーザーがクーポンコードを適用した回数です。GA4では明示的なイベントはありませんが、パラメータとして記録することが多いです。Adobeでは、クーポンコード入力→適用ボタン押下時にevent92「クーポン適用」を送信し、eVarにクーポンコードを保持すると良いでしょう。さらに購入完了イベントと組み合わせて、そのクーポンが使われた注文数や割引額を分析できます。なお割引額自体は、Adobeでは注文時にproducts変数内でイベントとして渡すことも可能です（例えばeventを通貨型に設定し割引額を送信）。まずは適用行動の有無を計測し、マーケティング施策の効果測定に繋げます。
  • (12) クーポン削除 (Remove Coupon Code) – ユーザーが適用していたクーポンを取り下げた回数です。適用取り消しは頻度は高くないかもしれませんが、UIによっては可能です。GA4では特に定義なし、Adobeでもカスタム対応です。event93「クーポン削除」を送るか、適用と対になる動作として実装します（実際には不要な場合も多いでしょう）。クーポン周りはサイトによりますので、状況に応じて設定してください。
  • (13) 購入完了 (Purchase) – ユーザーが注文を完了した回数（購入件数）です。これはECサイト最重要のコンバージョンイベントです。GA4でもpurchaseイベントで計測し、収益や購入商品をパラメータで送ります。Adobe Analyticsでもpurchaseという予約イベントがあり、これを送信すると自動的に「注文数 (Orders)」指標が+1されます。さらにpurchaseイベントが含まれるヒットでは、products変数に指定した商品の価格・数量をもとに「売上高 (Revenue)」「商品数量 (Units)」が集計されます。具体的な実装として、購入完了ページ（サンキューページ）の読み込み時にs.events="purchase"を設定し、併せてproducts変数に「カテゴリ;商品ID;数量;価格」という形式で購入商品すべてをセミコロン区切りで列挙します（複数商品はカンマ区切りで連結）。またs.purchaseID（トランザクションID）も設定します。これにより注文の重複カウントを防止できます。Adobe Analyticsのeコマース機能では、purchaseイベント送信時に限り売上・数量・注文数を自動計算する仕組みになっています。したがって、購入完了イベントは必ずpurchaseを使いましょう（カスタムのeventではなく）。GA4との大きな違いは、売上や商品明細がイベントのパラメータではなくproducts変数によって伝達される点です。正しく実装すれば、Adobe AnalyticsのWorkspace上で商品別売上や平均注文額など多彩な売上分析が可能です。
  • (14) 購入返品 (Refund) – 注文が返品・返金処理された回数です。GA4ではrefundイベントが推奨されています。Adobe Analyticsで返品を計測する方法はいくつかあります。（1）注文キャンセルや返品時にpurchaseイベントを再度送信し、productsの数量や売上をマイナス値で送ることで売上を取り消す方法、（2）専用のeventを通貨型で設定し返金額を記録する方法、（3）Data Sources機能で返品データを後から投入する方法等です。リアルタイムに近い形で計測したいなら（1）がシンプルです。例えば返品が発生したらs.events="purchase"に加えて各商品を「-1個、-○円」として送ります（マイナスのRevenueが計上される）。ただしAdobeの標準レポートでは売上はマイナスも加減算されて集計されますが、注文数(Order)指標は増えてしまうので注意が必要です（その場合は別のカスタムイベントで返品件数を記録し分析時に考慮します）。シンプルに件数だけ追うなら、event94「返品件数」として管理し、返品処理完了時に+1送信でも構いません。返品率や正味売上の把握のため、サイト規模によっては導入を検討してください。
  • (15) 内部プロモーション表示 (Promotion Impression) – サイト内の販促バナーが表示されたインプレッション数です。トップページやカテゴリページにあるキャンペーンバナーなどが閲覧された回数を指します。GA4ではview_promotionイベントがあり、Adobeでもこれに相当するデータを取るには工夫が必要です。方法としては#40で述べた「コンテンツインプレッション」の応用で、特定のプロモ枠が画面に表示されるたびにevent95「プロモ表示」を送信し、eVarにプロモIDを入れます。もしくはページロード時にその枠が存在すれば即インプレッションとみなして送るケースもあります。さらにプロモクリック（イベント9参照）と組み合わせてCTRを分析できます。AdobeではこれらをTracking Code（キャンペーンID）で実装することもありますが、簡便にはカスタムイベント＋eVarでの対応が多いです。
  • (16) 内部プロモーションクリック (Promotion Click) – サイト内プロモーションバナーがクリックされた回数です。汎用イベント(9)で内部プロモクリックを挙げましたが、ECサイトでは特に重要なため再掲します。Adobeではevent14「プロモクリック」で対応し、プロモIDをeVarで送る実装とします。表示(15)とクリック(16)を両方計測すれば、プロモ効果測定が可能です。GA4のselect_promotionイベントに近い概念です。
  • (17) 商品レビュー投稿 (Submit Product Review) – ユーザーが商品レビューを投稿した件数です。これは汎用イベント(29)のEC版と言えます。ECでは購入後のレビュー投稿はUGCとして重要なので、Adobeでも是非計測しましょう。event96「レビュー投稿」を定義し、投稿完了時に送信します。eVarに商品IDを持たせれば、どの商品にレビューが何件付いたかも分析できます。レビュー件数の推移や、レビュー投稿ユーザーのリピート率分析など高度な活用も可能です。
  • (18) 商品評価 (Product Rating) – ユーザーが商品に星評価を付けた回数です。これも汎用イベント(30)のEC版です。購入者が5段階評価を付けるようなサイトでは、評価投稿をカウントします。event97「商品評価」を送り、評価値を数値イベントまたはeVarで渡します（例えばeVarに「5星中4星」とか、イベントを数値型にして4を加算）。レビュー投稿とセットで、評価傾向の定量分析に役立てます。GA4ではrateのようなイベントはないので独自実装となります。
  • (19) 商品を共有 (Share Product) – ユーザーが商品のページを他者と共有した回数です。汎用イベント(28)のEC版です。event60「コンテンツ共有」と同じものを使ってもよいですが、特に商品共有だけ把握したければ別イベントにする手もあります。例えばevent98「商品共有」を送り、共有先種別（LINE, Twitter等）と商品IDをそれぞれ変数で送ります。口コミやSNS拡散を図る施策の効果を見る指標になります。
  • (20) ウィッシュリスト追加 (Add to Wishlist) – ユーザーが商品をお気に入り登録（欲しいものリストに追加）した回数です。GA4でもadd_to_wishlistイベントが推奨されています。Adobeではカスタムイベントで、例えばevent80「ウィッシュリスト追加」を定義し実装します。products変数に商品を指定して送れば、その商品が何件お気に入り登録されたか分析できます。購入には至っていないが関心が高い商品の洗い出しに有用です。
  • (21) ウィッシュリスト削除 (Remove from Wishlist) – ユーザーがお気に入りから商品を削除した回数です。こちらもGA4にはremove_from_wishlistがあります。同様にAdobeでevent81「ウィッシュリスト削除」を送ります。お気に入り機能を提供している場合は、追加と削除の双方を計測しておくとユーザーの嗜好変化が見えます。
  • (22) ウィッシュリスト閲覧 (View Wishlist) – ユーザーが自分のウィッシュリストページを閲覧した回数です。お気に入りリストを見る＝購入検討フェーズと考えられるので、event82「ウィッシュリスト閲覧」としてカウントします。実装はページロード時に送るだけです。お気に入りから実際に購入に至った割合などを分析する材料になります。
  • (23) 比較機能使用 (Product Compare Used) – ユーザーが商品比較機能を使用した回数です。汎用イベント(42)でも触れましたが、ECサイトでは複数商品の比較機能がある場合、それをどれだけ使われているか測るのも有益です。event76「比較利用」を送信し、比較対象となった商品IDを（可能なら）eVarで列挙します。比較された回数が多い組み合わせはユーザーの悩みどころを示唆しますし、比較ページからの転換率も分析できます。
  • (24) 店舗検索実行 (Store Locator Search) – ユーザーが実店舗の検索を行った回数です。ECサイトでも実店舗情報を提供している場合、店舗検索や在庫確認をするユーザー行動があります。event83「店舗検索」を送信し、検索された店舗エリア等をeVar保持します。汎用イベント(34)に相当します。オンラインとオフラインの融合分析を目指す際には欠かせません。
  • (25) 実店舗在庫チェック (Check Store Inventory) – ユーザーが店舗在庫を確認した回数です。上記店舗検索の発展で、特定店舗の在庫状況を見るクリック数などです。例えば「店頭在庫を見る」ボタンでevent84「店舗在庫チェック」を送ります。ROPO効果（Webで調べて店舗で買う）の指標となりえます。
  • (26) 注文状況確認 (Order Tracking View) – ユーザーが自分の注文履歴・配送状況ページを閲覧した回数です。購入後、発送状況を確認する行動で、カスタマーエンゲージメントの一環です。event99「注文追跡閲覧」を実装します。頻繁にチェックするユーザーはロイヤリティが高いかもしれませんし、逆に発送遅延で不安になっているかもしれません。このデータ単体よりも他指標と組み合わせた分析で価値を発揮します。
  • (27) 返品手続開始 (Initiate Return) – ユーザーが商品の返品手続きを開始した回数です。例えば注文履歴から「返品する」ボタンをクリックしたケースです。GA4ではrefundが管理側の処理を指すのに対し、こちらはユーザー起点の行動です。event100「返品開始」を送り、どの注文か識別できればeVarで注文IDを渡します。返品意向の傾向をつかむのに役立ちます。
  • (28) 返品手続完了 (Complete Return) – ユーザーが返品処理を完了した回数です。サイト上で返品ラベル発行までした場合など、ユーザー側での操作完了を指します。event101「返品完了」を計測し、実際に倉庫で処理されたrefundイベント（先述14）と突合することで、どれくらいの返品要求が完了したか分析できます。ただサイトによってオンライン完結しないケースも多いので、実装できるかはケースバイケースです。
  • (29) アカウント登録（購入フロー内） (Account Registration in Checkout) – ユーザーが購入フロー中にアカウントを登録した回数です。会員登録が任意のECサイトでは、購入時にゲストから会員になるケースがあります。それを計測するイベントです。汎用イベント(18)で会員登録全般を扱いましたが、特に購入時に同時登録したケースだけを抽出したい場合に、event32「会員登録完了」と組み合わせてフラグを立てるか、新たにevent102「購入時会員登録」を送信します。後者は、チェックアウト中に「アカウント作成」チェックボックスをオンにした時点で送るなどの方法があります。これにより、新規顧客獲得と売上の関連を直接測定できます。
  • (30) ログイン（購入フロー内） (Login in Checkout) – 既存会員が購入フローでログインした回数です。ゲスト購入から途中で会員ログインしたケースなどを指標化します。event103「購入時ログイン」を送ります。これも必須ではありませんが、会員と非会員の動向を詳しく知るには使えます。GA4では特に分けていませんが、Adobeでは自由度が高いので定義してみました。

以上、ECサイト向けの30イベントを紹介しました。Adobe Analyticsでは、eコマース機能の一環として用意された予約イベント（prodView, scAdd, purchase等）を活用することで比較的容易に主要指標を計測できます。その一方で、チェックアウト途中のステップやウィッシュリスト、返品など細かなイベントは自分でカスタム定義して実装する必要があります。GA4の推奨イベントに沿った形で設計すれば、大きく見落とすことはないでしょう。ポイントは、購入関連のイベントでは必ずproducts変数など必要な変数を併せて送信することです。そうしないとAdobe側のレポートで商品別の集計や売上計上が正しく行われません。

まとめ：Adobe Analyticsイベント実装のコツと学び

「Adobe Analyticsは基本的なイベントも自分で設定しないと何も取れない」は厳密には半分真実で半分誤解です。確かにGA4のように自動でユーザー行動を網羅的に捕捉してくれるわけではありません。しかし、本記事で挙げたように事前に計測したいイベントを設計し、適切にタグ実装すれば、GA4で得られるのと同じ（あるいはそれ以上に細かな）行動データを収集・分析できるのがAdobe Analyticsです。

GA4に慣れた方にとって、Adobe Analyticsの実装作業は最初こそ戸惑うかもしれません。ですが、見方を変えればAdobeでは「自動で取れない」分だけ自分の手で計測をコントロールできるということでもあります。何を重要指標とし、どのデータをどう取得・命名するか、自由度が高い分だけ戦略的な設計が求められます。例えばイベント一つ取っても、カスタムイベントとして記録するだけでなく、それに関連する属性情報（どのページで発生したか、どのユーザーセグメントか等）をeVarや分類で付加でき、後から多角的に解析できます。Adobe Analyticsは初期設定に手間がかかる分、実装がハマれば強力な分析基盤となるのです。

最後に、本記事で紹介したイベント実装のポイントを簡単に振り返ります。

  • イベント定義は計測前に管理画面で！ – Adobeではサクセスイベントの定義をレポートスイート設定で行ってから実装に移ります。イベント名や型を整理した上で、Launchのルール設定を始めましょう。組織のソリューション設計書にどのevent番号を何に使うか明記すると後々混乱しません。
  • Launchルールでの実装パターンを把握する – ページ読み込み時に発火するイベント（ページビューや仮想PV）は「DOM ReadyでSend Beacon (s.t())」experienceleague.adobe.com、ユーザーアクション系は「クリック/イベント検知でSet Variables→Send Beacon (s.tl())」experienceleague.adobe.comというパターンが基本です。あとはデータ要素やカスタムコードを組み合わせれば大抵のことは実現できます。GTMでタグ+トリガー+変数を設定していた知識がそのまま応用できるでしょう。
  • 予約イベントと変数を活用 – 特にECサイトではAdobeの予約イベント（prodView, scAdd, purchase等）とproducts変数を正しく使うことで、売上や商品軸の分析がスムーズになります。逆にこれらを使わずにすべてカスタムイベントで記録してしまうと、標準レポートを活かせず分析が大変になります。Adobe提供の仕組みは積極的に活用しましょう。
  • GA4の自動収集イベントを手本に – どのイベントを計測すべきか悩んだら、GA4でデフォルト収集・推奨されているイベントの一覧を参考にすると漏れがありません。今回挙げたリストもほぼそれらを網羅する形になっています。GA4で便利だったレポートは、同じデータをAdobeで取得するにはどうするか逆算すると思い描きやすいです。
  • Analysis Workspaceで活用 – 実装したイベントはAnalysis Workspace上でディメンションやセグメントと組み合わせて分析・可視化できます。GA4のレポート作成と近い感覚で、自由な切り口でデータを活かせます。特にカスタムイベントは標準レポートには出てこないので、Workspaceで分析プロジェクトを作成してチームと共有すると良いでしょう。イベント名も管理画面で分かりやすく付けておけば、Workspaceのメトリクス一覧にそのまま表示され、レポート構築がしやすくなります。

Adobe Analyticsのイベント実装は確かにGA4よりハードルが高い部分もありますが、一度習得してしまえばデジタル行動データを思いのままに扱える強力なスキルとなります。未知だったAdobe Analyticsも、GA4の知識と本記事のガイドを組み合わせれば決して怖くありません。ぜひ少しずつ実プロジェクトで試し、**「GA4並みにAdobe Analyticsを使いこなす」**第一歩を踏み出してみてください。あなたの分析の幅がさらに広がるはずです。

参考文献・出典：

  • GA4 自動収集イベント – GA4では30以上のイベントがデフォルトでトラッキングされる
  • GA4とAdobe Analyticsの導入難易度比較 – 「GA4は実装が容易で、Adobeは初期設定に高度なリソースが必要」infotrust.com
  • Adobe Analyticsの標準指標 (OOTB指標) – ページビューや訪問数などはコード実装だけで自動取得される
  • Adobe Analyticsのサクセスイベント設定 – 管理画面でイベント名や種別を定義し、有効化する
  • Adobe Launchでのイベント実装手順 – Set Variablesでイベントを選択し、Send Beaconでヒットを送信するexperienceleague.adobe.comexperienceleague.adobe.com
  • Adobeにおけるリンクトラッキング設定 – デフォルトではリンククリック時にイベントは送られないため、Link Track Eventsにイベントを指定して計測する
  • AdobeのEC予約イベント – purchase, prodView, scAdd等を使うことでOrdersやCart Additions指標が計測可能

情報源

コメント

タイトルとURLをコピーしました