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

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

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

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

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

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

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

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

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

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

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

  • ルールは順番に処理されます。以下のような場合は、どの条件にも一致しないことがあります。
  1. リファラーなし(直接訪問)。

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

  3. ページの処理異常。

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

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

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

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

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

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

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

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

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

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

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

メモ

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

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

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

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

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

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

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

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

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

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

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

マーケティングチャネルの処理ルールを変更した後、一部のチャネルが変更されないのはなぜですか。

マーケティングチャネルの処理ルールが正しく設定されていない場合、処理ルールを変更する必要があります。変更を適用すると、一部の指標が引き続き誤ったチャネルに属性を持っていることがわかります。考慮すべき点がいくつかあります。

  • マーケティングチャネルデータはリアルタイムで収集されます:マーケティングチャネルのデータはデータ収集時に処理され、100%永続的です。処理ルールの変更は、データに遡って影響を与えません。

  • 処理ルールを変更しても、ファーストタッチデータにはすぐに影響しません:次に例を示します。

    1. 誤って設定されていたため、ユーザーが電子メールチャネルから入ってきて、サイトを離れます。
    2. 次の日、電子メール処理ルールを修正します。
    3. 数日後にユーザーが自然検索から戻ってきて、購入をおこないます。
    4. 電子メールチャネルにはファーストタッチクレジットが、自然検索にはラストタッチクレジットが付与されます。

    処理ルールを変更した数日後でも、誤ったファーストタッチチャネルでデータを収集できます。ファーストタッチデータは、すべてのユーザーの訪問者エンゲージメントが期限切れになるまで、誤ったチャネルで継続的に収集されます。

これらの不一致を修正する最善の方法は、次のいずれかまたは両方を行うことです。

  • すべての訪問者エンゲージメント期間を手動で期限切れにする:この設定は、すべての訪問者で、すべてのファーストタッチチャネルとラストタッチイベントを即時に期限切れにします。

    1. 管理ツール/レポートスイートの順に移動します。
    2. 画像編集設定/マーケティングチャネル/訪問者のエンゲージメント期間の上にカーソルを置きます。
    3. 「すべて期限切れ」をクリックします。
    4. 警告ポップアップウィンドウの「OK」をクリックします。これは、実行する処理を理解していることを確認するメッセージです。
  • ルールを修正した時点からのラストタッチ指標のみを表示します:ラストタッチ指標は常に、現在のルールセットに従います。処理ルールを正しく変更した後の時間の表示では、最新の処理ルールが反映されてています。

このページ