Show Menu
トピック×

マーケティングチャネルの処理ルール

マーケティングチャネルの処理ルールは、訪問者のヒットがチャネルに割り当てられた条件を満たすかどうかを判断するために使用します。このルールは、サイトでの訪問者によるすべてのヒットを処理します。チャネルの条件をルールが満たしていない場合やルールが正しく設定されていない場合、ヒットには「チャネルが識別されませんでした」が割り当てられます。
ルール作成時の重要なガイドラインは次のとおりです。
  • ルールは処理する順序に並べること。
  • リストの最後に包括的ルール(「その他」など)を追加すること。このルールは、内部トラフィックではなく外部トラフィックを識別します。
    チャネルが識別されませんでした を参照してください。
これらのルールはマーケティングチャネル以外のレポートには影響しませんが、マーケティングチャネルのデータ収集には影響します。これらのルールを使用して収集されたデータは完全に永久的なもので、データの収集後に変更されたルールを過去のデータにさかのぼって適用させることはできません。マーケティングチャネルの処理ルールを保存する前に、すべての状況について確認と検討を行い、間違ったチャネルでデータが収集されないようにすることを強くお勧めします。

前提条件

マーケティングチャネルの処理ルールの作成

訪問者のヒットがチャネルに割り当てられた条件を満たすかどうかを判断するためのマーケティングチャネルの処理ルールを作成します。
この手順では、例として電子メールルールを使用します。この例では、マーケティングチャネルマネージャーページのチャネルのリストに電子メールチャネルを追加済みであることを前提としています。
  1. Analytics 管理者 レポートスイート ​の順にクリックします。
  2. レポートスイートを選択します。
    レポートスイートでチャネルが定義されていない場合、マーケティングチャネル :自動セットアップページが表示されます。
    詳しくは、 自動セットアップの実行 を参照してください。
  3. 設定を編集 マーケティングチャネル マーケティングチャネルの処理ルール ​の順にクリックします。
  4. 新しいルールセットの追加 」メニューから「 電子メール 」を選択します。
    これにより、チャネルを選択するのではなく、必要なパラメーターを持つルールを挿入するテンプレートを選択することになります。
    ブール値論理(if/then 文)を使用してルールを設定します。例えば、電子メールチャネルルールでは次のルール文で強調した設定または情報を提供します。
    "If **[All]** or **[Any]** of the following are true: **[Query String Parameter]** *<value>* **[exists]**...
    "Then identify the channel as **[Email]**...
    "Then set the channel's value to **[Query String Parameter]** *<value>*."
    この例では、 <value> が電子メールキャンペーンに使用するクエリ文字列パラメーターです(例えば、 eml など)。
  5. ルールの作成を続けるには、「 ルールの追加 」をクリックします。
  6. ルールに優先順位を付けるには、目的の位置にルールをドラッグアンドドロップします。
  7. 保存 」をクリックします。

マーケティングチャネルルール条件

このテーブルは、マーケティングチャネルの処理ルールページで選択可能なフィールド、オプションおよびヒット属性を定義しています。
用語
定義
すべて
番号付きルール内のすべてのルールが真の時にのみ、このチャネルをアクティブにします。
いずれか
ルールセット内のいずれかのルールが真のときに、このチャネルをアクティブにします。このオプションは、番号付きルール内に 2 つ以上ルールが存在している場合にのみ利用可能です。
AMO ID
Advertising Cloud と Advertising Analytics の統合で使用されるプライマリトラッキングコード。これらの統合の 1 つが有効になっている場合、トラッキングコードプレフィックスを使用して Advertising Cloud 固有のチャネルを識別できます。「AMO ID」は、検索には「AL」、表示には「AC」、Social には「AO」で始まる名前を使用します。AMO ID をマーケティングチャネルで使用する場合、クリック/コスト/インプレッション指標を正しいチャネルに関連付けることができます(設定されていない場合、これらの指標は「直接」または「なし」になります)。
AMO ED ID
Advertising Cloud で使用されるセカンダリトラッキングコード。このトラッキングコードは、Ad Cloud にデータを返送する際の鍵となることを主な目的としています。ただし、2 つの異なるマーケティングチャネルとして表示したい場合は、表示クリックスルー数と表示ビュースルー数を識別するためにも使用できます。これは、「表示クリックスルー」の場合は「AMO EF ID」のマーケティングチャネルロジックを「:d」で終わるように設定し、「表示ビュースルー」の場合は「:i」で終わるように設定することで実現できます。「表示」を 2 つのチャネルに分割しない場合は、代わりに AMO ID ディメンションを使用します。
コンバージョン変数
このレポートスイート用に有効になっている eVar から構成され、これらの変数がページ上の Adobe コード経由で設定された場合にのみ適用されます。実装マニュアルを参照してください。
存在する
以下のオプションを選択できます。
  • が存在しない :ヒット属性がリクエストに存在しないことを示します。たとえば、参照ドメインで、ユーザーが URL を入力するかブックマークをクリックすると、その参照ドメイン属性は存在しません。
  • が空である :ヒット属性(通常は eVar またはクエリ文字列パラメーター)は存在しますが、そのヒット属性に関連付けられた値がないことを示します。
  • 次を含まない :例えば参照ドメインなどに特定の値を含めないこと(「次を含む」オプションを選択する場合と逆)を示します "Contains".)
チャネルを %s として特定している
マーケティングチャネルマネージャーページに追加したマーケティングチャネルにルールを関連付けます。マーケティングチャネルの追加を参照してください。
有料検索の検出ルールに一致
アドビによって検出された有料検索。有料検索とは、自社サイトが検索結果リストに優先的に載せられるように会社が検索エンジンに料金を支払った検索キーワードを指します。有料検索のキーワードは通常検索結果の上部または右側に表示されます。
自然検索の検出ルールに一致
アドビのレポートによって検出された無料検索。
リファラーが内部 URL フィルターに一致する
管理ツールのレポートスイートで定義されている内部 URL フィルターに一致するページ URL からのアクセス。
リファラーが内部 URL フィルターに一致しない
管理ツールにあるレポートスイートで定義されたとおり、参照 URL が内部 URL フィルターに一致しません。この設定を「ページの URL」および「存在する」と共に使用して包括的ルールを設定できるので、訪問のランディングページがレポートの「チャネルが識別されませんでした」セクションになることはありません。
内部 URL フィルターに一致するヒットを無視する
(リファラーに対して)外部参照サイトからのヒットのみをトラッキングします。内部トラフィックを含める場合以外、通常はこの設定を有効にしておきます。
訪問の最初のページ
アドビのレポートで検出された訪問の最初のページ。
ページ
アドビの Web ビーコンを使ってタグ付けされた、サイト上の Web ページのページ名。 s.pageName と等しい値になります。Examples include Home Page and About Us .
ページドメイン
products.example.co.uk など、訪問者が到着したページのドメイン。
ページドメインとパス
The domain and path, such as products.example.co.uk/mens/pants/overview.html .
ページルートドメイン(TLD+1)
example.co.uk など、訪問者が到着したページのルートドメイン。
ページ URL
サイトの Web ページの URL。
参照ドメイン
サイトにアクセスする前に訪問者が来たドメイン。例えば、 abcsite.com から来たリファラーや xyzsite.com から来たリファラーなどです。
クエリー文字列パラメーター
If a page URL on your site looks like https://example.com/?page=12345&cat=1 , then page and cat are both query string parameters. ( https://en.wikipedia.org/wiki/Query_string .) 1 つのルールセットにつき 1 つだけクエリー文字列パラメーターを指定できます。To add additional query string parameters, use ANY as your operator, then add new query string parameters to the rule.
Referrer
サイトにアクセスする前に訪問者が閲覧していた Web ページの場所(フル URL)。リファラーは、定義ドメインの外側に存在します。
参照ドメインとパス
参照ドメインと URL パスを短縮したもの。以下に例を示します。 または www.example.com/products/id/12345``ad.example.com/foo
参照パラメーター
リファラー URL のクエリー文字列パラメーター。例えば、訪問者が example.com/?page=12345&cat=1 から来訪した場合、page と cat が参照パラメーターとなります。
参照ドメインのルート
リファラーのルートドメイン。リファラーは、定義ドメインの外側に存在します。
検索エンジン
訪問者をサイトに導いた Google や Yahoo! などの検索エンジン。
検索キーワード
検索エンジンでの検索に使用された単語。
検索エンジン + キーワード
検索エンジンを一意に識別するために検索キーワードと検索エンジンを連結したもの。例えば、computer という単語を検索した場合、検索エンジンとキーワードは次のように特定されます。 Search Tracking Code = "<search_type>:<search engine>:<search keyword>" where search_type = "n" or "p", search_engine = "Google", and search_keyword = "computer" 注意: ​n = natural(自然検索)、p = paid(有料検索)
チャネルの値を次の値に設定する
訪問者をサイトに導くマーケティングチャネルを特定することに加えて、訪問者のサイトのアクティビティに対してクレジットを受けるチャネル内のバナー広告、検索キーワードまたは電子メールキャンペーンを特定できます。この ID は、チャネルと共に保存されるチャネル値です。この値には、ランディングページや参照 URL に埋め込まれているキャンペーン ID、検索エンジンと検索キーワードの組み合わせ、特定チャネルからの訪問者と最も正確に識別する参照 URL などがよく使用されます。

内部(セッション更新)チャネル

内部チャネル(多くの場合、「セッション更新」に名前変更)は、参照 URL が Admin Console の内部 URL フィルター設定と一致するサイトへの訪問で構成されます。つまり、訪問者はサイト内から訪問を開始します。

ベストプラクティスの上書き

「ダイレクト」チャネルと「内部」チャネルのラストタッチの上書きオプションは、他の永続的なラストタッチチャネル(または相互)からクレジットを受け取れないように、オフにすることをお勧めします。
このドキュメントでは、「直接」および「セッション更新」の「上書き」設定がオフになっていることを前提としています。

エンゲージメント期間

訪問者のファーストタッチチャネルとラストタッチチャネルは、両方とも、そのブラウザーで 30 日間操作が行われなかった場合にリセットされます。
デフォルトは 30 日ですが、必要に応じて管理者設定で変更できます。
訪問者が頻繁にサイトを使用する場合は、エンゲージメントウィンドウもそれに従って更新されます。期限が切れ、チャネルがリセットされるまで、訪問者は 30 日間非アクティブである必要があります。 例:
  • 1 日目:ユーザーが「表示」でサイトにアクセスした。ファーストタッチチャネルとラストタッチチャネルは「表示」に設定されます。
  • 2 日目:ユーザーが「自然検索」でサイトにアクセスした。ファーストタッチは「表示」のままで、「ラストタッチ」は「自然検索」に設定されます。
  • 35 日目:ユーザーが 33 日間サイトにアクセスせず、ブラウザーで開いていたタブを使用して戻ってきた。30 日間のエンゲージメント期間を想定すると、この期間は終了し、マーケティングチャネル cookie の有効期限が切れます。ファーストタッチチャネルとラストタッチチャネルはリセットされ、ユーザーが内部 URL から来ているため「セッション更新」に設定されます。

ファーストタッチとラストタッチの関係

ファーストタッチとラストタッチの相互作用を理解し、オーバーライドが期待どおりに機能することを確認するために、ラストタッチチャネルレポートに関連するファーストタッチチャネルレポートをプルし、主要な成功指標を追加できます(以下の例を参照)。この例は、ファーストタッチチャネルとラストタッチチャネルの間のインタラクションを示しています。
ファーストタッチとラストタッチが等しくなる交差の点は、オレンジ色でハイライト表示されます。「直接」および「セッション更新」の両方がラストタッチクレジットを取得するのは、それらがファーストタッチチャネルでもある場合のみです。これは、他の永続的なチャネル(灰色でハイライト表示された行)からクレジットを取得できないためです。

セッション更新が発生する理由

ラストタッチのセッション更新はそれがファーストタッチでもあった場合にのみ発生することがわかっているので、以下のシナリオでは、セッション更新がファーストタッチチャネルとなる方法を説明します。
シナリオ 1:セッションタイムアウト
訪問者が Web サイトを訪問し、後日使用できるよう、ブラウザーでタブを開いたままにします。訪問者のエンゲージメント期間が終了(または訪問者が任意に cookie を削除)した後で、訪問者が「開く」タブを使用して Web サイトに再度アクセスします。参照 URL は内部ドメインなので、訪問は「セッション更新」に分類されます。
シナリオ 2:一部のサイトページがタグ付けされていない
訪問者は、タグ付けされていないページ A にランディングし、タグ付けされたページ B に移動します。ページ A は内部リファラーと見なされ、訪問は「セッション更新」と見なされます。
シナリオ 3:リダイレクト
リダイレクトが新しいランディングページにリファラーデータを渡すように設定されていない場合、実際のエントリリファラーデータは失われ、リダイレクトページ(おそらく内部ページ)が参照ドメインとして表示されます。訪問は、「セッション更新」に分類されます。
シナリオ 4:クロスドメイントラフィック
訪問者が、スイート A に対して起動する 1 番目のドメインから、スイート B に対して起動する 2 番目のドメインに移動します。スイート B の内部 URL フィルターが最初のドメインを含む場合、マーケティングチャネルは、これを 2 番目のスイートで新しい訪問と見なすので。「内部」として記録されます。訪問は、「セッション更新」に分類されます。
シナリオ 5:入口ページ読み込み時間が長い
訪問者は、コンテンツが多いページ A にランディングし、Adobe Analytics コードはページの下部に配置されています。訪問者は、(Adobe Analytics イメージリクエストを含む)すべてのコンテンツを読み込む前に、ページ B をクリックします。ページ B は Adobe Analytics イメージリクエストを実行します。ページ A のイメージリクエストは読み込まれないので、2 番目のページは Adobe Analytics の訪問の最初のヒットとして表示され、ページ A がリファラーとして表示されます。訪問は、「セッション更新」に分類されます。
シナリオ 6:ミッドサイトでの cookie の消去
訪問者がサイトを訪問し、セッション中に cookie を消去します。ファーストタッチチャネルとラストタッチチャネルの両方がリセットされ、訪問は「セッション更新」に分類されます(リファラーが内部的なものになるため)。