Die Kunst der doppelten Verneinung – Verwendung von Trigger-Ausnahmen im Google Tag Manager

Neben den Grundlagen des Hinzufügens von Analyse- und Marketing-Tags zu Ihrer Website ermöglicht der Google Tag Manager durch den strategischen Einsatz von Triggern auch fortgeschrittenes Website-Tagging und -Management. Wenn Sie die Grundlagen der Trigger-Bedingungen, mehrerer Trigger und Trigger-Ausnahmen verstehen, können Sie Ihren Container kleiner, agiler und effektiver gestalten.

Lassen Sie uns einige Grundlagen durchgehen und dann wirklich in Trigger-Ausnahmen eintauchen.

Trigger und „Ereignisse“

Wenn Sie mit dem Anlegen eines Triggers beginnen, leistet der Assistent gute Arbeit, indem er Sie zwingt, mit einem bestimmten Ereignis zu beginnen. Dies ist ein anderes Konzept als in Google Analytics (GA) und entspricht bestimmten „Aktionen“, die auf der Seite stattfinden. Beliebte Ereignisse sind, wenn das Laden einer Seite beginnt, auf einen PDF-Link geklickt wird oder ein Formular eingereicht wird.

Wenn Sie eine bestimmte Art von Ereignis auswählen, übernimmt der Google Tag Manager (GTM) den schwierigen Teil und „hört“ sich diese Ereignisse an. Wenn die Ereignisse auftreten, sucht GTM nach allen Triggern, die mit diesem Ereignis verknüpft sind, und prüft dann den nächsten Teil, den wir besprechen werden – die Triggerbedingungen.

Trigger-Bedingungen

Es gibt nur wenige Fälle, in denen wir bei jedem Laden einer Seite oder bei jedem Klick auf einen Link einen Tag auslösen wollen. Vielmehr brauchen wir eine Möglichkeit, uns auf bestimmte Seiten oder bestimmte Aktionen zu konzentrieren. Sobald wir zum Beispiel festgestellt haben, dass jemand auf einen Link geklickt hat, können wir damit beginnen, durch das Hinzufügen von Bedingungen spezifischer zu werden. Dies ist der Teil, in dem wir uns auf PDF-Links oder nur auf Blog-Seiten beschränken.

Darüber hinaus haben wir die Möglichkeit, mehrere Bedingungen aufzunehmen. Angenommen, ich wollte nur PDF-Links verfolgen, die auch das Wort „analytics“ im Link enthalten, dann könnte ich dies mit mehreren Bedingungen tun.

Die Triggerbedingungen müssen ALLE WAHR sein, damit der Trigger ausgelöst wird.

Was passiert, wenn ich einen Trigger für PDF-Dateien möchte, die entweder „Analytics“ oder „Google-Anzeigen“ enthalten?

Nun, wie bei den meisten Dingen bei Google gibt es mehrere Möglichkeiten, die gleiche Aufgabe zu erledigen. Es könnte verlockend sein, beide als separate Bedingungen aufzunehmen, aber das würde nicht funktionieren, da ALLE Bedingungen WAHR sein müssen, damit der Auslöser ausgelöst werden kann. Das hier ist eine UND-Verknüpfung für alle Bedingungen.

In diesem Fall könnte ich den Trigger, den wir gerade erstellt haben, modifizieren und einen regulären Ausdruck verwenden, der entweder „analytics“ oder „google ads“ entspricht.

Dann möchte ich diesen Trigger umbenennen, um anzuzeigen, dass er nun sowohl auf Analytics als auch auf Google Ads PDF-Downloads feuert.

Mehrere Trigger

Manchmal wäre es eine bessere Lösung, mehrere Trigger zu verwenden. Eine hilfreiche Frage, die Sie sich stellen sollten, wäre: „Würde ich diesen Trigger jemals für ein anderes Tag verwenden? Sie können die Anzahl der allgemeinen Trigger reduzieren, indem Sie allgemeinere Trigger erstellen, die auf viele Tags anwendbar sind, und dann bei Bedarf mehrere Trigger hinzufügen.

Auf dieser Ebene sind die Trigger mit einem ODER verknüpft. Es reicht, wenn einer der Trigger als WAHR ausgewertet wird.

Abhängig von Ihren Bedürfnissen kann es hilfreicher sein, zwei Trigger für „Analytics PDF Downloads“ und „Google Ads PDF Downloads“ zu haben als einen einzigen Trigger mit der Aufschrift „Analytics oder Google Ads PDF Downloads“. Dann können wir diese für Remarketing-Tags, Google Analytics-Tags, alles, was wir wollen, verwenden!

Nehmen wir diesen Trigger und teilen wir ihn in zwei separate Trigger auf und fügen sie demselben Tag hinzu.

Hier ist noch ein weiterer wichtiger Hinweis einzufügen. Was wäre, wenn es das Schicksal so will und wir zufällig eine PDF-Datei hätten, die sowohl die Wörter „analytics“ als auch „google ads“ enthielte? Ich werde oft gefragt: Wenn es zwei Auslöser gibt, bedeutet das dann nicht, dass der Tag zweimal ausgelöst wird?

Die Antwort ist normalerweise „Nein“. Denken Sie daran, dass jeder Trigger mit einer Art von Ereignis verbunden ist, wie das Laden der Seite oder ein Klick auf einen Link.

Ein Tag wird nur EINMAL pro Ereignis ausgelöst.

Wenn also auf einen Link geklickt wird und es sich dabei um eine PDF-Datei über Google Analytics und Google Ads handelt, stimmen beide Auslöser überein, aber da beide an dasselbe Link-Klick-Ereignis gebunden sind, wird das Tag nur einmal ausgelöst.

Trigger-Ausnahmen

Manchmal tappen wir in die Falle, die Trigger-Bedingungen zu benutzen, um sowohl zu sagen, wann wir etwas abfeuern wollen, als auch gleichzeitig, wann wir etwas NICHT abfeuern wollen. Abhängig von Ihren Szenarien mag dies durchaus sinnvoll sein, aber oft kann dies zu einer langen Liste von Triggern führen, die eine beträchtliche Menge in sich wiederholen. Häufig können die Gründe, warum wir nicht wollen, dass ein Tag ausgelöst wird, immer und immer wieder verwendet werden, wie z.B. das Blockieren der Auslösung bestimmter Tags auf mobilen Geräten oder die Trennung von Tags, die auf unserer Dev- und Live-Version der Website ausgelöst werden sollen.

In unserem Beispiel haben wir derzeit zwei Trigger, die ausgelöst werden, einen für PDFs mit dem Wort „analytics“ und einen für PDFs mit dem Wort „google ads“. Nehmen wir an, ich würde gerne sicherstellen, dass diese Tags nur auf unserer Live-Site ausgelöst werden. Wenn der Link in diesem Beispiel auf unserer Live-Site ist, die den Hostnamen „www.tobiasbatke.com“ hat, dann ist es in Ordnung zu feuern. Wenn er sich auf unserer Dev-Site befindet, die wir als „dev.tobiasbatke.com“ ausgeben werden, dann möchte ich nicht, dass er ausgelöst wird.

Sie könnten denken, dass wir einfach weiterhin weitere Bedingungen zu unseren Triggern hinzufügen können, wie unten beschrieben. Diese Methode funktioniert, aber es wäre nicht meine Empfehlung.

Diese Methode ist etwas umständlicher und etwas schwieriger zu handhaben. Wenn wir sie zuerst auf unserer Dev-Site testen wollen, müssten wir jede Bedingung in jedem Trigger durchgehen und ändern und sie dann wieder auf Live zurücksetzen, wenn wir bereit sind.

Willkommen bei den Trigger-Ausnahmen! Dabei handelt es sich um spezielle Trigger, mit denen wir in bestimmten Fällen das Abfeuern von Tags blockieren können. Dazu müssen wir möglicherweise unsere Logik ein wenig verdrehen. Wenn wir möchten, dass diese Tags nur auf unserer Live-Website abgefeuert werden, können wir eine Trigger-Ausnahme oder einen blockierenden Trigger erstellen, der besagt: „Nicht feuern, wenn Sie NICHT auf der Live-Website sind“.

Schauen wir uns das etwas genauer an und untersuchen die doppelte Verneinung. Wenn wir dies als Trigger-Ausnahme verwenden, dann sagt es Folgendes aus:

„Blockieren Sie dieses Tag vom Auslösen, wenn der Benutzer nicht auf www.tobiasbatke.com ist“.

die umformuliert werden kann als:

„Diesen Tag nur feuern, wenn der Benutzer auf www.tobiasbatke.com ist“.

Der Vorteil hier ist, dass dies ein Auslöser ist, den wir immer und immer wieder nutzen werden. Wenn wir zum Beispiel sicherstellen, dass unsere Marketing-Tags richtig abgefeuert werden, wollen wir verhindern, dass diese auch auf unserer Entwicklungsseite abgefeuert werden.

Trigger-Ausnahmen werden genau wie normale Trigger erstellt, mit ein paar kleinen Unterschieden. Ich beginne alle meine blockierenden Trigger gerne mit „Blocker – „, was mir einfach hilft, meine Liste von Triggern zu organisieren.

Erinnern Sie sich, dass alle Trigger an ein Ereignis gebunden sein müssen? In diesem Fall werden wir eine Ausnahme machen und sagen, dass wir, anstatt einen blockierenden Trigger an ein bestimmtes Ereignis zu binden, jedes Ereignis blockieren, wenn die Bedingungen übereinstimmen. Wir können dies mit ein wenig regulärem Ausdruck tun, indem wir sagen, dass das Ereignis gleich .* ist, was einfach bedeutet, dass es ein beliebiges Ereignis sein kann.

Sobald wir den Trigger erstellt haben, können wir ihn zu einem Tag hinzufügen, indem wir auf den Link „Ausnahmen hinzufügen“ am unteren Rand des Tags klicken.

Dann wählen wir einfach den Trigger, den wir erstellt haben, und er wird in einem speziellen Abschnitt angezeigt. Genau wie bei regulären Triggern können wir mehrere Trigger-Ausnahmen zum gleichen Tag hinzufügen.

Wenn JEDE Trigger-Ausnahme als wahr ausgewertet wird, wird der Tag für dieses Ereignis am Abfeuern gehindert.

Es ist auch hilfreich, das GTM-Debug-Panel zu verwenden, um herauszufinden, warum ein bestimmtes Tag ausgelöst oder nicht ausgelöst wurde, insbesondere um Ihnen die spezifischen Trigger anzuzeigen, die als wahr ausgewertet wurden oder nicht (das grüne Kontrollkästchen).

Warum Trigger-Ausnahmen verwenden?

Was ist so toll daran? Warum sollten wir Trigger Ausnahmen verwenden? Ich werde Ihnen ein paar Gründe nennen.

Weniger Unordnung, weniger Verwirrung

Ich habe es bereits erwähnt, aber es lohnt sich, es zu wiederholen: Wenn wir Wege finden, Trigger in wiederverwendbare Komponenten zu zerlegen, dann können wir die Anzahl der Trigger, die wir insgesamt beibehalten müssen, effektiv reduzieren.

Funktion von allem anderen trennen

Löst Feuer aus, wenn etwas passiert. Wenn möglich, versuchen Sie, die Aufgabe eines Triggers so zu gestalten, dass wirklich nur das macht, was Sie versuchen zu erfassen. Wir können Trigger-Ausnahmen verwenden, um andere Dinge zu steuern, z.B. Informationen über den Benutzer (Handy oder Desktop), Informationen über die Umgebung (Live oder Dev) oder wie häufig ein Tag auslösen darf.

Wartung und Instandhaltung

Trigger-Ausnahmen machen es auch einfacher zu verwalten, wo und wann ein Tag ausgelöst wird. Wenn wir einen gemeinsam genutzten GTM-Container verwenden, können wir das Tag und den Trigger, an dem wir arbeiten, einrichten und blockierende Trigger verwenden, um zu steuern, ob diese produktionsbereit sind oder nicht.

Eine sehr große Liste von Blockierungsauslösern

Und nachdem unsere (nicht ganz so) kurze Einführung abgeschlossen ist, finden Sie hier eine lange Liste von blockierenden Triggern, die Sie erstellen können, und deren Anwendungsfälle. Eine Anmerkung – die Benennung ist wichtig, damit Sie genau verstehen, was diese Trigger tun. Ich werde Ihnen Vorschläge machen, aber zögern Sie nicht, die Namen so umzubenennen, dass sie für Sie Sinn ergeben!

1. Blocker – Regelmäßige Website-Besucher

Variablen: Debug-Modus (eingebaute Variable)

Anwendungsfall: Diese Trigger-Ausnahme verwendet die eingebaute Variable Debug-Modus, um festzustellen, ob jemand die Website im Debug-Modus in der Vorschau anzeigt. Nur ein eingeloggter GTM-Benutzer kann einen Container in der Vorschau anzeigen, d.h. nur ein eingeloggter GTM-Benutzer kann sich im Debug-Modus befinden.

Dies ist ein ausgezeichneter blockierender Trigger, da wir damit an einem Tag arbeiten und ihn in Aktion sehen können, während wir einen Container in der Vorschau anzeigen, aber er ist für niemanden sichtbar, der unsere Website besucht, selbst wenn der Container versehentlich veröffentlicht wird. Wenn ich ein neues Tag erstelle, füge ich sofort diese Ausnahme hinzu, um es für alle Website-Besucher zu blockieren, bis ich bereit bin, dass es auf der Website live geschaltet wird. Wenn Sie mehrere Personen oder Agenturen haben, die mit GTM arbeiten, ist dieser Auslöser ein Muss!

Erinnern Sie sich an die doppelte Verneinung – Blockieren Sie das Abfeuern von Tags, wenn der Debug-Modus gleich false ist, oder wenn wir das umdrehen, feuern Sie nur Tags ab, wenn sich der Benutzer gerade im Debug-Modus befindet.

2. Blocker – GTM-Debug-Modus

Variablen: Debug-Modus (eingebaute Variable)

Anwendungsfall: Diese Trigger-Ausnahme dreht den Operator einfach um und besagt, dass wir das Auslösen von Tags blockieren, wenn wir uns im Debug-Modus befinden. Dies ist praktisch für Tags, die bereits ordnungsgemäß funktionieren, die wir aber nicht auslösen wollen, während wir unsere Site debuggen.

Wenn wir beispielsweise Testtransaktionen einführen, können wir diese Trigger-Ausnahme zu allen unseren Conversion-Tags hinzufügen, damit sie keine gefälschten Transaktionsdetails an Facebook, Google-Anzeigen, Analytics usw. senden.

3. Blocker – Live-Site

Variablen: Hostname der Seite (eingebaute Variable)

Anwendungsfall: Wenn Sie eine Website haben, die mehrere Umgebungen hat, wie z.B. verschiedene Staging- oder Entwicklungsserver, ist diese Trigger Exception so hilfreich, um zu kontrollieren, welche Tags sich noch im Dev-Modus befinden und welche zur Hauptsendezeit bereit sind. Auch hier gilt: Werfen Sie diese Ausnahme auf alles, was noch nicht bereit ist, live zu gehen.

4. Blocker – Dev Site

Variablen: Hostname der Seite (eingebaute Variable)

Anwendungsfall: Jetzt drehen wir das um und machen die umgedrehte Blockierung der Tags für das Feuern auf unserer Dev-Site. Dies ist besonders wichtig für alles, was Conversions messen würde. Obwohl wir oft die Umgebung genau gleich halten wollen, um sicherzustellen, dass alles schön zusammenpasst, kann es hilfreich sein, ausgewählte Tags vor dem Abfeuern zu verbergen. E-Mail-Marketing, Remarketing-Tags, Umfragen oder Popups, Google Trusted Store-Abzeichen, Live Chat – was auch immer! Wenn es richtig funktioniert, entfernen Sie es von Ihrer Dev-Site.

5. Blocker – Andere Website

Variablen: Hostname der Seite (eingebaute Variable)

Anwendungsfall: Es gibt einige wenige Fälle, in denen es sinnvoll ist, den gleichen GTM-Container auf völlig unterschiedlichen Domänen zu haben. Vielleicht haben sie ein ähnliches Template, oder Sie möchten einfach Ihr Tagging rationalisieren. Diese blockierenden Auslöser können verwendet werden, um zu diktieren, welche Tags auf welchen Sites ausgelöst werden sollen. Erinnern Sie sich an die doppelte Verneinung: Wenn ich will, dass es auf www.tobiasbatke.com feuert, werde ich eine Blockierungsregel für alles erstellen, was nicht gleich www.tobiasbatke.com ist.

6. Blocker – nicht erste Seite

Variablen: Referrer (eingebaute Variable)

Anwendungsfall: Der HTTP-Referrer ist eine hilfreiche Information, die Ihnen sagt, was die vorherige Seite war, die den Nutzer auf die aktuelle Seite „verwiesen“ hat. Dies ist die Grundlage für die Zuordnung des Google Analytics-Traffics, und mit einigen bemerkenswerten Ausnahmen, wie z. B. dem Wechsel von HTTPS zu HTTP, können wir dies auf verschiedene Weise verwenden.

In diesem Beispiel sagen wir, dass wir das Auslösen eines Tags blockieren möchten, wenn ein Nutzer eine Seite auf unserer Website besucht und wenn die vorherige Seite auch unsere Website war. Mit anderen Worten, wir wollen, dass dieses Tag nur auf der ersten Seite der Sitzung eines Benutzers ausgelöst wird. Dies kann sich hervorragend für Pop-ups, Werbeaktionen oder Mitteilungen eignen, die einem Benutzer ständig angezeigt werden und die unter Umständen störend sind.

Denken Sie darüber nach, wie Sie dies auch verwenden könnten, um verschiedene Tags zu feuern, wenn jemand von einer bestimmten verweisenden Website kommt!

7. Blocker – 80 Prozent

Variablen: Zufallszahl (eingebaute Variable)

Anwendungsfall: Diese Methode geht auf einen Blog-Eintrag von Dan Russell zurück, mit einigen bemerkenswerten Änderungen. Anstatt einen Auslöser für eine Zufallsstichprobe zu erstellen, verwenden wir eine Trigger-Ausnahme. Auch hier besteht der Vorteil darin, dass wir die Auslöser verwenden können, um mit den Bedingungen umzugehen, die erforderlich sind, damit das Tag ausgelöst wird, und wir verwenden die Trigger-Exception nur, um die Häufigkeit des Auslösens des Tags zu steuern.

Die Variable Zufallszahl gibt uns genau das, eine Zufallszahl. Wir können einen einfachen regulären Ausdruck verwenden, um eine Übereinstimmung zu erzielen, wenn die letzte Ziffer in dieser Zufallszahl zwischen 1 und 8 liegt. Das geschieht in 80 Prozent der Fälle, wobei die beiden anderen Optionen eine 9 oder eine 0 sind.

Lassen Sie uns noch einmal die Perspektive ändern: Wenn wir verhindern, dass dieser Tag in 80 Prozent der Fälle abgefeuert wird, dann sagen wir eigentlich: „Feuern Sie diesen Tag in 20 Prozent der Fälle“. Es ist hier wichtig zu beachten, dass jedes Mal, wenn eine Seite geladen wird, dieser Trigger überprüft wird. Dies ist also nicht unbedingt eine Möglichkeit, einen Tag nur 20 Prozent der Besucher Ihrer Website anzuzeigen.

8. Blocker – nicht Analytics bezogen

Variablen: Seiten-URL (eingebaute Variable)

Anwendungsfall: Wenn ich einen bestimmten Tag nur für Besucher feuern möchte, die sich auf einer Seite befinden, die sich mit Google Analytics beschäftigt, kann ich den gesamten Traffic auf Seiten blockieren, die nichts mit Google Analytics zu tun haben. Passen Sie dies natürlich an Ihre spezifische Site-Struktur oder an Ihre spezifischen Unterverzeichnisse an.

9. Blocker – Mobile

Variablen: Ist mobile (benutzerdefinierte JavaScript-Variable)

Anwendungsfall: Kommen wir nun zu einigen der lustigen Sachen, die wir mit benutzerdefinierten JavaScript-Variablen machen können! Wir haben zwar eingebaute Variablen verwendet, aber wir können unsere Möglichkeiten durch die Verwendung von benutzerdefiniertem JavaScript erheblich erweitern. Für diesen Fall werden wir eine Variable erstellen, die den User Agent überprüft, um festzustellen, ob sich der Besucher auf einem mobilen Gerät befindet. Simo Ahava hat eine gute mobile Variable, die von http://detectmobilebrowsers.com angepasst wurde, also werden wir einfach diese Variable verwenden! (Danke!) Die Variable gibt ein einfaches wahr oder falsch an, was die Frage beantwortet: „Ist der Besucher auf einem mobilen Gerät?“

Dies ist eine große Ausnahme, die für jeden Tag zu verwenden ist, der eine Nachricht auftauchen lässt oder einem Benutzer auf einem mobilen Gerät eine negative Erfahrung vermitteln würde.

function () {
  var a = navigator.userAgent || navigator.vendor || window.opera;
  if (/(android|bb\d+|meego).+mobile|avantgo|bada\/|blackberry|blazer|compal|elaine|fennec|hiptop|iemobile|ip(hone|od)|iris|kindle|lge |maemo|midp|mmp|mobile.+firefox|netfront|opera m(ob|in)i|palm( os)?|phone|p(ixi|re)\/|plucker|pocket|psp|series(4|6)0|symbian|treo|up\.(browser|link)|vodafone|wap|windows (ce|phone)|xda|xiino/i.test(a) || /1207|6310|6590|3gso|4thp|50[1-6]i|770s|802s|a wa|abac|ac(er|oo|s\-)|ai(ko|rn)|al(av|ca|co)|amoi|an(ex|ny|yw)|aptu|ar(ch|go)|as(te|us)|attw|au(di|\-m|r |s )|avan|be(ck|ll|nq)|bi(lb|rd)|bl(ac|az)|br(e|v)w|bumb|bw\-(n|u)|c55\/|capi|ccwa|cdm\-|cell|chtm|cldc|cmd\-|co(mp|nd)|craw|da(it|ll|ng)|dbte|dc\-s|devi|dica|dmob|do(c|p)o|ds(12|\-d)|el(49|ai)|em(l2|ul)|er(ic|k0)|esl8|ez([4-7]0|os|wa|ze)|fetc|fly(\-|_)|g1 u|g560|gene|gf\-5|g\-mo|go(\.w|od)|gr(ad|un)|haie|hcit|hd\-(m|p|t)|hei\-|hi(pt|ta)|hp( i|ip)|hs\-c|ht(c(\-| |_|a|g|p|s|t)|tp)|hu(aw|tc)|i\-(20|go|ma)|i230|iac( |\-|\/)|ibro|idea|ig01|ikom|im1k|inno|ipaq|iris|ja(t|v)a|jbro|jemu|jigs|kddi|keji|kgt( |\/)|klon|kpt |kwc\-|kyo(c|k)|le(no|xi)|lg( g|\/(k|l|u)|50|54|\-[a-w])|libw|lynx|m1\-w|m3ga|m50\/|ma(te|ui|xo)|mc(01|21|ca)|m\-cr|me(rc|ri)|mi(o8|oa|ts)|mmef|mo(01|02|bi|de|do|t(\-| |o|v)|zz)|mt(50|p1|v )|mwbp|mywa|n10[0-2]|n20[2-3]|n30(0|2)|n50(0|2|5)|n7(0(0|1)|10)|ne((c|m)\-|on|tf|wf|wg|wt)|nok(6|i)|nzph|o2im|op(ti|wv)|oran|owg1|p800|pan(a|d|t)|pdxg|pg(13|\-([1-8]|c))|phil|pire|pl(ay|uc)|pn\-2|po(ck|rt|se)|prox|psio|pt\-g|qa\-a|qc(07|12|21|32|60|\-[2-7]|i\-)|qtek|r380|r600|raks|rim9|ro(ve|zo)|s55\/|sa(ge|ma|mm|ms|ny|va)|sc(01|h\-|oo|p\-)|sdk\/|se(c(\-|0|1)|47|mc|nd|ri)|sgh\-|shar|sie(\-|m)|sk\-0|sl(45|id)|sm(al|ar|b3|it|t5)|so(ft|ny)|sp(01|h\-|v\-|v )|sy(01|mb)|t2(18|50)|t6(00|10|18)|ta(gt|lk)|tcl\-|tdg\-|tel(i|m)|tim\-|t\-mo|to(pl|sh)|ts(70|m\-|m3|m5)|tx\-9|up(\.b|g1|si)|utst|v400|v750|veri|vi(rg|te)|vk(40|5[0-3]|\-v)|vm40|voda|vulc|vx(52|53|60|61|70|80|81|83|85|98)|w3c(\-| )|webc|whit|wi(g |nc|nw)|wmlb|wonu|x700|yas\-|your|zeto|zte\-/i.test(a.substr(0, 4))) { return true; }
  return false;
}

10. Blocker – Desktop

Variablen: Ist mobil (benutzerdefinierte JavaScript-Variable)

Anwendungsfall: Schalten wir den Operator hier um und suchen einfach nach der Umkehrung – wenn jemand nicht auf einem mobilen Gerät ist, dann nehmen wir an, er befindet sich auf einem Desktop. Dies ist unsere Art, spezifische Tags nur für mobile Besucher abzufeuern, wie Geolokalisierung usw.

11. Blocker – Interne IP

Variablen: IP-Adresse (Datenschicht-Variable)

Anwendungsfall: Ich habe darüber in einem Beitrag über die Verwendung von Blocker-Regeln anstelle von Ausschlussfiltern geschrieben. Sie können auf diesen vorherigen Beitrag schauen, um weitere Informationen über die Server-Einrichtung zu erhalten, aber für eine kurze Zusammenfassung: Wenn wir die IP-Adresse des Benutzers im DataLayer erhalten können, dann können wir diese verwenden, um eine Vielzahl von Trigger-Erweiterungen zu erstellen.

Ich habe vorhin ein paar Tags aufgelistet, die sich gut für die Sperrung von internen Benutzern oder Mitarbeitern eignen würden. In diesem Fall können wir die IP-Adresse einbringen und prüfen, ob sie mit unserem regulären Ausdruck übereinstimmt.

12. Blocker – Interner Cookie

Variablen: Ist Angestellter (First Party Cookie)

Anwendungsfall: Ebenfalls aus einem früheren Blog-Beitrag über das Herausfiltern von Mitarbeiter-Traffic: Wenn Sie Mitarbeiter dazu bringen können, die Hand zu heben und sich als Mitarbeiter zu identifizieren, können Sie ein Cookie setzen und dieses später verwenden, um das Abfeuern bestimmter Tags zu verhindern. Diese Implementierung ist hilfreich für Unternehmen, in denen Mitarbeiter häufig auf Reisen sind oder die keine statische Büro-IP-Adresse haben.

13. Blocker – Wochenendtage

Variablen: Wochentag (Benutzerdefiniertes JavaScript)

Anwendungsfall: Denken Sie daran, dass wir mit Custom JavaScript wirklich jede Berechnung durchführen können, die wir benötigen. In diesem Fall erhalten wir den Wochentag. Ich lokalisiere dies auf Deutschland, da wir uns dort befinden. Sie müssen sich überlegen, wie Ihr Datum erscheinen soll: In der Zeitzone des Besuchers, die sich ändern wird, oder in der Zeitzone Ihres Unternehmens.

Theoretisch könnten Sie diese Auslöser verwenden, um wochentagspezifische Anzeigen anzuzeigen oder Tags auf der Grundlage bestimmter Tage zu ändern. Stellen Sie sich vor, Sie ziehen auch die Tageszeit ein und können während der Geschäftszeiten und wenn Ihr Büro geschlossen ist, verschiedene Tags auslösen. Livechat zum Beispiel?

function() {
	//Fill in your offset from GMT!
	//https://en.wikipedia.org/wiki/List_of_UTC_time_offsets
	// *********
	var offset = +1;
	// *********
	var current = new Date( new Date().getTime() + offset * 3600 * 1000);
	var daysOfWeek = new Array(7);
	daysOfWeek[0]=  "Sonntag";
	daysOfWeek[1] = "Montag";
	daysOfWeek[2] = "Dienstag";
	daysOfWeek[3] = "Mittwoch";
	daysOfWeek[4] = "Donnerstag";
	daysOfWeek[5] = "Freitag";
	daysOfWeek[6] = "Samstag";
	return(daysOfWeek[current.getDay()]);
}

Diese Liste soll einige kreative Ideen dafür entfachen, wie Sie Trigger-Ausnahmen verwenden können! Fühlen Sie sich frei, diese Variablen oder andere benutzerdefinierte JavaScript-Variablen auf kreative Weise zu verwenden. Haben Sie andere kreative Ideen, die für andere Leser auch interessant sein könnten? Schreiben Sie es mir in die Kommentare.

Schreibe einen Kommentar

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.