Show Menu
THEMEN×

Häufig gestellte Fragen zu Marketing-Kanälen

Unter Einrichten von Marketing-Kanal-Verarbeitungsregeln finden Sie eine Definition der angezeigten Felder auf der Seite der Verarbeitungsregeln des Marketing-Kanals.

Häufig gestellte Fragen

Die Implementierungen der Marketingkanal-Verarbeitungsregeln unterscheiden sich je nach verwendetem Trackingcode. Die Konfiguration der Regeln, die die gewünschten Ergebnisse erzielen, will gut durchdacht sein, um Probleme zu vermeiden.
Frage : Meine Trackingcodes sind alle verschieden, und für meinen Affiliates-Kanal muss ich Tausende dieser Codes angeben.
  • Sortieren Sie aus, was Sie nicht brauchen. Wenn Ihre E-Mail- und Affiliates-Kanäle denselben Abfragezeichenfolgenparameter verwenden, aber nur wenig E-Mail-Trackingcodes vorliegen, können Sie die E-Mail-Trackingcodes in einem Regelsatz zu „email“ angeben. Klassifizieren Sie dann alle weiteren Trackingcodes als affiliates.
  • Fügen Sie allen Landingpage-URLs in Ihrem E-Mail-System einen Abfragezeichenfolgenparameter hinzu, z. B. &ch=eml . Erstellen Sie einen Regelsatz, der erkennt, ob der „ch“-Abfrageparameter gleich eml . Wenn er eml nicht enthält, ist er ein Affiliate.
Frage : Verweisende Domänen enthalten mehr Daten als erwartet.
  • Verweisende Domänen stehen in der Liste der Verarbeitungsregeln eventuell zu weit oben. Da die Verarbeitungsreihenfolge wichtig ist, sollte dies einer der letzten bzw. der letzte Regelsatz sein.
Frage : Ich habe eine Regel erstellt, die mit einem Abfragezeichenfolgenparameter übereinstimmt aber nicht funktioniert.
  • Vergewissern Sie sich, dass der Parametername in den Feldern des Abfragenzeichenfolgenparameters angegeben ist (gewöhnlich ein alphanummerischer Wert). Vergewissern Sie sich zudem, dass der Parameterwert nach dem Operator steht, wie in folgendem Beispiel einer E-Mail-Regel dargestellt.
Frage : Warum wird der gesamte Last Touch-Traffic einer internen Domäne zugeschrieben?
  • Sie verwenden eine Regel, die internem Traffic entspricht. Denken Sie daran, dass diese Regeln für jeden Treffer auf Ihrer Site verarbeitet werden, nicht nur beim Erstbesuch. Wenn Sie eine Regel wie Page URL exists ohne weitere Kriterien verwenden, wird bei jedem nachfolgenden Treffer auf Ihrer Site eine Übereinstimmung mit dem betreffenden Kanal erfasst, da die Seiten-URL immer vorhanden ist.
Frage : Wie behebe ich Traffic-Fehler, die im Bericht als „Kein Kanal identifiziert“ auftreten?
  • Regeln werden der Reihe nach verarbeitet. Wenn keine Übereinstimmung mit den spezifischen Kriterien vorliegt, fallen die Treffer in eine von drei Kategorien:
  1. Kein Verweis (ein Direktbesuch).
  2. Interner Verweis, auf der ersten Seite des Besuchs.
  3. Ein Verarbeitungsfehler auf der Seite.
Stellen Sie sicher, dass Sie einen Kanal für diese drei Möglichkeiten haben. Erstellen Sie beispielsweise diese Regeln:
  1. Verweisende Stelle und Nicht vorhanden und Ist erste Seite des Besuchs . (Siehe Direct. )
  2. Referrer entspricht internen URL-Filtern und Ist erste Seite des Besuchs . (Siehe Internal .)
  3. Verweisende Domäne und Vorhanden und Verweis stimmt nicht mit internen URL-Filtern überein .
Erstellen Sie abschließend einen Kanal Other , der die verbleibenden Treffer erfasst, wie in Kein Kanal identifiziert beschrieben.

Beziehung zwischen Erstkontakt und Letztkontakt

Um die Interaktion zwischen alten First Touch- und Last Touch-Dimensionen zu verstehen und zu bestätigen, dass Außerkraftsetzungen erwartungsgemäß funktionieren, können Sie einen First Touch-Kanal-Bericht abrufen, der in Subrelationen zu einem Last Touch-Kanal-Bericht steht und in dem Ihre wichtigste Erfolgsmetrik hinzugefügt wurde (siehe Beispiel unten). Das Beispiel zeigt die Interaktion zwischen Erstkontakt- und Letztkontakt-Kanälen.
Der Schnittpunkt, bei dem "first gleich last touch"die Diagonale des Tisches ist. Sowohl Direct- als auch Sitzungsaktualisierung erhalten nur dann eine Last Touch-Gutschrift, wenn sie auch der First Touch-Kanal sind, da sie keine Gutschrift von anderen bestehenden Kanälen (markierten Zeilen) erhalten können.

Gründe für die Nichtidentifizierung des Kanals

Wenn Ihre Regeln keine Daten erfassen oder die Regeln nicht korrekt konfiguriert sind, zeigt der Bericht die Daten in der Zeile Kein Kanal identifiziert im Bericht an. Sie können beispielsweise am Ende der Verarbeitungsreihenfolge einen Regelsatz mit dem Namen Sonstige einrichten, der internen Traffic auch wie folgt identifiziert:
Diese Art von Regel dient als Auffangbehälter, um zu gewährleisten, dass Kanal-Traffic stets externem Traffic entspricht und in der Regel nicht Kein Kanal identifiziert zugeordnet wird . Achten Sie darauf, keine Regel zu erstellen, die auch internen Traffic erkennt. Zur Erstellung einer wirksamen Regel „Sonstige“ ist es häufig am sinnvollsten, den Kanalwert auf Verweisende Domäne oder Seiten-URL zu setzen.
Es kann dennoch vorkommen, dass Kanal-Traffic teilweise in die Kategorie „Kein Kanal identifiziert“ fällt. Beispiel: Ein Besucher öffnet die Site und versieht eine Seite mit einem Lesezeichen. Beim gleichen Besuch kehrt dieser Besucher über das Lesezeichen zur Seite zurück. Da es sich dabei nicht um die erste Seite des Besuchs handelt, wird es weder dem direkten Kanal noch einem anderen Kanal zugeordnet, da keine Referrer-Domäne vorliegt.

Gründe für die Aktualisierung der Sitzung

Last Touch Session Refresh kann nur auftreten, wenn es auch die erste Berührung war - siehe "Beziehung zwischen First & Last Touch" oben. Die folgenden Szenarien erläutern, wie Sitzungsaktualisierung ein First Touch-Kanal sein könnte.
Szenario 1: Sitzungstimeout
Ein Besucher ruft die Website auf und lässt die Registerkarte dann in seinem Browser geöffnet, um sie später erneut zu verwenden. Der Interaktionszeitraum des Besuchers läuft ab (oder er löscht seine Cookies freiwillig), und er verwendet die geöffnete Registerkarte, um die Website erneut zu besuchen. Da die verweisende URL eine interne Domäne ist, wird der Besuch als Sitzungsaktualisierung klassifiziert.
Szenario 2: Nicht alle Seiten der Site sind mit Tags versehen
Ein Besucher landet auf Seite A, die nicht mit Tags versehen ist, und wechselt dann zu Seite B, die mit Tags versehen ist. Seite A wird als interner Referrer angesehen, und der Besuch wird als Sitzungsaktualisierung klassifiziert.
Szenario 3: Umleitungen
Wenn eine Umleitung nicht so eingerichtet ist, dass Referrer-Daten an die neue Landingpage weitergegeben werden, gehen die Referrer-Daten verloren, und die Umleitungsseite (wahrscheinlich eine interne Seite) erscheint als Referrer-Domäne. Der Besuch wird als Sitzungsaktualisierung klassifiziert.
Szenario 4: Domänenübergreifender Traffic
Ein Besucher wechselt von einer Domäne, die zu Suite A führt, zu einer zweiten Domäne, die zu Suite B führt wird. Wenn in Suite B die internen URL-Filter die erste Domäne enthalten, wird der Besuch in Suite B als intern aufgezeichnet, da Marketingkanäle ihn als neuen Besuch in der zweiten Suite sehen. Der Besuch wird als Sitzungsaktualisierung klassifiziert.
Szenario 5: Lange Ladezeiten der Entrypage
Ein Besucher landet auf Seite A mit viel Inhalt, und der Adobe Analytics-Code befindet sich unten auf der Seite. Bevor der gesamte Inhalt (einschließlich Adobe Analytics-Bildanforderungen) geladen werden kann, klickt der Besucher auf Seite B. Seite B löst ihre Adobe Analytics-Bildanforderung aus. Da die Bildanforderung von Seite A nie geladen wurde, wird die zweite Seite als erster Treffer des Besuchs in Adobe Analytics angezeigt, wobei Seite A als Referrer dient. Der Besuch wird als Sitzungsaktualisierung klassifiziert.
Szenario 6: Löschen von Cookies mitten auf der Site
Ein Besucher besucht die Site und löscht seine Cookies während der Sitzung. Die Erstkontakt- und Letztkontakt-Kanäle werden zurückgesetzt, und der Besuch wird als Sitzungsaktualisierung klassifiziert (weil der Referrer intern ist).