マーケティングチャネル FAQ

最終更新日： 2024年7月18日
  • トピック：

作成対象：

  • ユーザー
  • 管理者
NOTE
アトリビューションと Customer Journey Analytics に対するマーケティングチャネルの効果を最大限に高めるために、改訂されたベストプラクティスを公開しました。
Analytics 管理者は、マーケティングチャネルの管理の説明に従って、組織のマーケティングチャネルを管理できます。

マーケティングチャネルに関するよくある質問（FAQ）です。

私のトラッキングコードはパターンに従っていません。また、アフィリエイトチャネル用に指定しなければならないコードが無数にあります。

  • 除外処理を使用します。メールチャネルとアフィリエイトチャネルに同一のクエリ文字列パラメーターを使用しているとき、メールのトラッキングコードが少数なら、メールを定義するルールセットでメールトラッキングコードを指定することができます。その後、残りすべてのトラッキングコードを affiliates. として分類します。
  • 電子メールシステムで、ランディングページのすべての URL に &ch=eml などのクエリ文字列パラメーターを追加します。ch クエリパラメーターが eml と等しいかどうかを検出するルールセットを作成します。eml が含まれない場合はアフィリエイトです。

参照ドメインに予想より多くのデータが含まれています。

参照ドメインが処理ルールリストで上位すぎる可能性があります。処理順序が重要なので、下位の方（または最下位）に配置してください。

クエリ文字列パラメーターに一致するルールを作成しましたが、うまく機能しません。

クエリ文字列パラメーターのフィールドでパラメーター名（通常は英数字の値）が指定されていることを確認してください。また、次の電子メールルールの例に示すように、演算子の後にパラメーター値が指定されていることを確認してください。

ラストタッチトラフィックの属性がすべて内部ドメインになっているのはどうしてですか。

内部トラフィックに一致するルールがあります。これらのルールは訪問の最初のページだけでなく、サイト上のすべてのページビューで処理されることを忘れないでください。Page URL exists などのルールが指定されていて、他の条件が指定されていない場合は、ページの URL が常に存在するので、サイト上の連続するヒットのそれぞれについてそのチャネルが照合されます。

レポートに「チャネルが識別されませんでした」と表示されているトラフィックは、どのようにデバッグしたらよいですか。

ルールは順番に処理されます。以下のような場合は、どの条件にも一致しないことがあります。

  1. リファラーなし（直接訪問）。

  2. 内部リファラー、訪問の最初のページ。

  3. ページの処理異常。

この 3 つの可能性用のチャネルを用意してください。例えば、次のようなルールを作成します。

  1. 「リファラー」と「存在しない」と「訪問の最初のページ」。（直接を参照）

  2. 「リファラーが内部 URL フィルターに一致する」と「訪問の最初のページ」（内部を参照）。

  3. 「リファラー」と「存在する」と「リファラーが内部 URL フィルターに一致しない」

最後に、チャネルが識別されませんでしたで説明されているように、残りのヒットを捕捉する「その他」のチャネルを作成します。

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

レガシーのファーストタッチとラストタッチディメンションの相互作用を理解し、オーバーライドが期待どおりに機能することを確認するために、ラストタッチチャネルレポートに関連するファーストタッチチャネルレポートをプルし、主要な成功指標を追加できます（以下の例を参照）。この例は、ファーストタッチチャネルとラストタッチチャネルの間のインタラクションを示しています。

交点ではファーストタッチチャネルとラストタッチが等しいく、これはテーブルの対角線です。「直接」および「セッション更新」の両方がラストタッチクレジットを取得するのは、それらがファーストタッチチャネルでもある場合のみです。これは、他の永続的なチャネル（ハイライト表示された行）からクレジットを取得できないためです。

チャネルが識別されない理由

ルールがデータを捕捉しない場合、あるいはルールが正しく設定されていない場合、レポートの「チャネルが識別されませんでした」列にデータが表示されます。例えば、内部トラフィックも識別する「その他」というルールセットを処理順序の最後に作成することができます。

この種類のルールは、チャネルトラフィックが常に外部トラフィックに一致し、通常は「チャネルが識別されませんでした」にならないようにする包括的ルールとして機能します。内部トラフィックも識別してしまうルールを作成しないように注意してください。「その他」のルールを作成するには、チャネルの値を​ 参照ドメイン ​または​ ページ URL にするのが最も一般的で有効な方法です。

NOTE
一部のチャネルトラフィックは引き続き「チャネルが識別されませんでした」カテゴリーに分類される場合があります。例えば、訪問者がサイトを訪問してページをブックマークし、その訪問中にブックマークを使用してそのページに戻った場合がこれに該当します。このページは訪問者が最初に訪問したページではなく、参照ドメインが存在しないので、直接アクセスチャネルにもその他チャネルにも分類されません。

内部の理由（セッションの更新）

ラストタッチ内部（セッションの更新）は、ファーストタッチの場合にのみ発生します。前述の「ファーストタッチとラストタッチの関係」を参照してください。次のシナリオでは、セッション更新がファーストタッチチャネルになる可能性を説明します。

  • セッションタイムアウト：訪問者が Web サイトを訪問し、後日使用できるよう、ブラウザーでタブを開いたままにします。訪問者のエンゲージメント期間が終了し（または訪問者が自発的に Cookie を削除し）、訪問者が開いているタブを使用して web サイトに再度アクセスします。参照 URL は内部ドメインなので、訪問は「セッション更新」に分類されます。

  • サイトページにはタグされていないものもあります：訪問者は、タグ付けされていないページ A にランディングし、タグ付けされたページ B に移動します。ページ A は内部リファラーと見なされ、訪問は「セッション更新」と見なされます。

  • リダイレクト：リダイレクトが新しいランディングページにリファラーデータを渡すように設定されていない場合、実際のエントリリファラーデータは失われ、リダイレクトページ（おそらく内部ページ）が参照ドメインとして表示されます。訪問は、「セッション更新」に分類されます。

  • クロスドメイントラフィック：訪問者が、スイート A に対して起動する 1 番目のドメインから、スイート B に対して起動する 2 番目のドメインに移動します。スイート B の内部 URL フィルターが最初のドメインを含む場合、マーケティングチャネルは、これを 2 番目のスイートで新しい訪問と見なすので。「内部」として記録されます。訪問は、「セッション更新」に分類されます。

  • エントリーページの読み込みが長くかかる：訪問者は、コンテンツが多いページ A にランディングし、Adobe Analytics コードはページの下部に配置されています。訪問者は、（Adobe Analytics イメージリクエストを含む）すべてのコンテンツを読み込む前に、ページ B をクリックします。ページ B は Adobe Analytics イメージリクエストを実行します。ページ A のイメージリクエストが読み込まれないので、Adobe Analytics では、ページ A をリファラーとして、2 番目のページが訪問の最初のヒットとして表示されます。訪問は、「セッション更新」に分類されます。

  • サイト内の cookie をクリアする：訪問者がサイトを訪問し、セッション中に cookie を消去します。ファーストタッチチャネルとラストタッチチャネルの両方がリセットされ、訪問は「セッション更新」に分類されます（リファラーが内部的なものになるため）。

以下に、ファーストタッチチャネルとラストタッチチャネルの両方として設定されている内部更新（セッション更新）の例を示します。

  • 1 日目：ユーザーが「表示」でサイトにアクセスした。ファーストタッチチャネルとラストタッチチャネルは「表示」に設定されます。
  • 2 日目：ユーザーが「自然検索」でサイトにアクセスした。ファーストタッチは「表示」のままで、「ラストタッチ」は「自然検索」に設定されます。
  • 35 日目：ユーザーが 33 日間サイトにアクセスせず、ブラウザーで開いていたタブを使用して戻ってきた。30 日間のエンゲージメント期間を想定すると、この期間は終了し、マーケティングチャネル cookie の有効期限が切れます。ファーストタッチチャネルとラストタッチチャネルはリセットされ、ユーザーが内部 URL から来ているため「セッション更新」に設定されます。