Show Menu
トピック×

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

マーケティングチャネルの処理ルールの作成 で、マーケティングチャネルの処理ルールページに表示されるフィールドの定義に関する項目を参照してください。

よくある質問

マーケティングチャネルの処理ルールの実装は、トラッキングコードによって異なります。求める結果をもたらすようなルールを設定するには、問題を解決するための工夫が求められる場合があります。
質問 :私のトラッキングコードはパターンに従っていません。また、アフィリエイトチャネル用に指定しなければならないコードが無数にあります。
  • 除外処理を使用します。電子メールチャネルとアフィリエイトチャネルに同一のクエリ文字列パラメーターを使用しているとき、電子メールのトラッキングコードが少数なら、電子メールを定義するルールセットで電子メールトラッキングコードを指定することができます。その後、残りすべてのトラッキングコードをアフィリエイトとして分類します。 affiliates.
  • 電子メールシステムで、ランディングページのすべての URL に &ch=eml などのクエリー文字列パラメーターを追加します。ch クエリパラメーターが eml と等しいかどうかを検出するルールセットを作成します。 eml が含まれない場合はアフィリエイトです。
質問 :参照ドメインに予想より多くのデータが含まれています。
  • 参照ドメインが処理ルールリストで上位すぎる可能性があります。処理順序が重要なので、下位の方(または最下位)に配置してください。
質問 :クエリー文字列パラメーターに一致するルールを作成しましたが、うまく機能しません。
  • クエリー文字列パラメーターのフィールドでパラメーター名(通常は英数字の値)が指定されていることを確認してください。また、次の電子メールルールの例に示すように、演算子の後にパラメーター値が指定されていることを確認してください。
質問 :ラストタッチトラフィックの属性がすべて内部ドメインになっているのはどうしてですか。
  • 内部トラフィックに一致するルールがあります。これらのルールは訪問の最初のページだけでなく、サイト上のすべてのページビューで処理されることを忘れないでください。「 Page URL exists 」などのルールが指定されていて、他の条件が指定されていない場合は、ページの URL が常に存在するので、サイト上の連続するヒットのそれぞれについてそのチャネルが照合されます。
質問 :レポートに「チャネルが識別されませんでした」と表示されているトラフィックは、どのようにデバッグしたらよいですか。
  • ルールは順番に処理されます。以下のような場合は、どの条件にも一致しないことがあります。
  1. リファラーなし(直接訪問)。
  2. 内部リファラー、訪問の最初のページ。
  3. ページの処理異常。
この 3 つの可能性用のチャネルを用意してください。例えば、次のようなルールを作成します。
  1. リファラー 」と「 存在しない 」と「 訪問の最初のページ 」。( 直接 を参照)
  2. リファラーが内部 URL フィルターに一致する 」と「 訪問の最初のページ 」( 内部 を参照)。
  3. リファラー 」と「 存在する 」と「 リファラーが内部 URL フィルターに一致しない
最後に、 チャネルが識別されませんでした で説明されているように、残りのヒットを捕捉する「 その他 」のチャネルを作成します。

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

従来のファーストタッチディメンションとラストタッチディメンションの間のやり取りを理解し、上書きが期待どおりに動作することを確認するには、(下の例を参照)に示す主要な成功指標を追加して、ラストタッチチャネルレポートを取り込みます。 この例は、ファーストタッチチャネルとラストタッチチャネルの間のインタラクションを示しています。
最初のタッチと最後のタッチが等しい交点は、テーブルの対角線です。 直接更新とセッション更新の両方で、ラストタッチクレジットが取得されるのは、それらがファーストタッチのチャネルでもある場合のみです。これは、他の永続的なチャネル(強調表示された行)からクレジットを受け取ることができないためです。

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

ルールがデータを捕捉しない場合、あるいはルールが正しく設定されていない場合、レポートの「チャネルが識別されませんでした」列にデータが表示されます。例えば、内部トラフィックも識別する「 その他 」というルールセットを処理順序の最後に作成することができます。
この種類のルールは、チャネルトラフィックが常に外部トラフィックに一致し、通常は「 チャネルが識別されませんでした 」にならないようにする包括的ルールとして機能します。内部トラフィックも識別してしまうルールを作成しないように注意してください。「その他」のルールを作成するには、チャネルの値を​ 参照ドメイン ​または​ ページ URL にするのが最も一般的で有効な方法です。
一部のチャネルトラフィックは引き続き「チャネルが識別されませんでした」カテゴリーに分類される場合があります。例えば、訪問者がサイトを訪問してページをブックマークし、その訪問中にブックマークを使用してそのページに戻った場合がこれに該当します。このページは訪問者が最初に訪問したページではなく、参照ドメインが存在しないので、直接アクセスチャネルにもその他チャネルにも分類されません。

内部の理由(セッションの更新)

ラストタッチセッションの更新は、ファーストタッチの場合にのみ発生します。前述の「ファーストタッチとラストタッチの関係」を参照してください。 次のシナリオでは、Session Refreshがファーストタッチチャネルになる可能性を説明します。
シナリオ 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 を消去します。ファーストタッチチャネルとラストタッチチャネルの両方がリセットされ、訪問は「セッション更新」に分類されます(リファラーが内部的なものになるため)。