Zugegeben: Es gibt dabei Überschneidungen mit bereits bestehenden Empfehlungen, von denen weiter unten einige verlinkt sind. Der Grund liegt auf der Hand: Solche Alters waren und sind sinnvoll. Den Anfang macht daher ein Klassiker, der die meisten Listen anführt. Zudem werden hier begleitende Erklärungen zum Zweck und zur Anpassung an die persönlichen Bedürfnisse beigefügt, die einem Einsteiger den Start erleichtern sollen.

Totalausfall der Messung

Die Frage "Läuft der Laden überhaupt noch online?" beantwortet man sich idealerweise mit einem Dienst wie uptimerobot.com, pingdom.com o. Ä., denn hier bekommt man deutlich schneller mit, wenn die eigene Website ausgefallen ist. Trotzdem bleibt es sinnvoll, sich bei Komplettausfall von gemessenem Traffic per Alert informieren zu lassen. Es gibt mehrere Gründe, warum Analytics keine Daten mehr erhält, ohne dass die Website dazu wirklich "down" sein muss. Um dies mitzubekommen, dient die folgende Benachrichtigung, die wie alle anderen unter Verwaltung -> Benutzerdefinierte Benachrichtigungen -> +Neue Benachrichtigung in der Spalte der Datenansicht definiert wird:

Tipp: Wer sich den Luxus eines Kontrollprofils für internen Traffic gönnt, kann hiermit zeitnah mitbekommen, wenn etwas schief läuft und interne Besucher vermutlich unerwünschterweise in der Arbeitsdatenansicht landen.

Organischer Traffic bricht ein oder steigt stark an

Die Benachrichtigungen über "dramatische" Veränderungen bei Besuchen über Suchmaschinen ist für jede Site sinnvoll. Problem: Je nach der Breite normaler Schwankungen im Traffic müssen bei diesem Filter leider ggf. je nach Website unterschiedliche Schwellwerte verwendet werden, um wirklich rechtzeitig ausgelöst zu werden. In diesem Beispiel sind es satte 50%... wenn auch dies noch zu "Fehlalarm" führen sollte, wird der organische Anteil der Besuche vermutlich so gering sein, dass kein wirkliches Risiko in einem Rückgang stecken sollte. Ein Alert für Anstiege sollte dann sicher reichen.

So werden die beiden Filter für besondere Spitzen nach oben oder unten definiert:

... und mit abweichender Bedingung für Zuwachs in den Sitzungen:

Hinweis: Wenn Sie "natürliche" (z. B. saisonale) Spitzen bei Suchanfragen zu eigenen Markenbegriffen haben und diese solche Alerts nicht beeinflussen sollen, können hierbei wahlweise nur Besuche über "non-branded-Begriffe" berücksichtigt werden. Dazu kann man die eigenen Firmen- und Markensuchbegriffe in der Property unter "Tracking-Informationen -> Suchbegriff-Ausschlussliste" eintragen. Das sorgt dafür, dass Besuche über diese Begriffe nicht mehr als "organisch" eingestuft werden.

Wichtige Keywords fallen aus

Das wäre toll, oder? Geht aber eben leider nicht (mehr). Jedenfalls nicht hier. In der Google Search Console finden sich solche Ausfälle aber natürlich weiterhin. Da diese Daten aber weder für Segmente noch Benachrichtigungen genutzt werden können, selbst wenn man Analytics mit der Console verbindet, bleibt hier nur der Weg über die API oder Drittanbieter (siehe unten).

Verweistraffic ändert sich merklich

Diese Benachrichtigungen sind die sinnvollen Zwillinge der obigen Alerts zu organischem Traffic. Die Anteile sollte man auch hier so gestalten, dass auch möglichst kein Fehlalarm ausgelöst wird.

Hier das passende Pendant für Zuwachs:

Einzelne Domains überwachen

Man kann auch einzelne Domains separate überwachen. Dazu wird nicht mehr auf das Medium, sondern auf die Quelle geschaut. Wenn es nur eine Domain ist, ist der Vergleich relativ einfach und man gibt den Domainnamen direkt an. In diesem Beispiel sollen es mehrere Domains sein, die als Regulärer Ausdruck definiert werden. Das ist kein Hexenwerk: Geben Sie den Domainnamen an, "maskieren" Sie Punkte durch ein vorangestelltes "\" und trennen Sie mehrere Domains mit einem "|".

Das Beispiel zeigt einen Anstieg im Traffic, der über die drei Domains beispieldomain1.de, .com etc., beispieldomain2.com und beispieldomain3.de kommt. Auch für einen Rückgang (zur Not auch auf Wochen-
statt Tagesbasis) kann dies entsprechend eingerichtet werden. Das lohnt sich ggf. sogar für einzelne Domains, wenn üblicherweise hierüber nennenswert viele Besucher generiert werden. Fällt dort z. B. ein Link auf die eigene Domain weg, möchte man dies i. d. R. wissen 😉

Fehlerseiten

Die Methode zur Überwachung von Fehlerseiten hängt davon ab, wie genau der eigene Server mit Fehlern umgeht und ob ggf. schon eine besondere Behandlung in Analytics existiert. Voraussetzung ist es, dass die Fehlerseite einen Trackingcode enthält. Hat man darauf Zugriff, wird oft ein Event oder ein virtueller Seitenaufruf genutzt, an den dann auch die Benachrichtigung gebunden werden kann. Ein Beispiel hierzu findet sich hier im Blog unter 404 Fehlerseiten in Google Analytics messen. Im Fall des "Standardtrackings" ist eine Fehlerseite aber dennoch erkennbar; i. d. R. am Titel der Seite. In diesem Beispiel beginnen solche Seiten immer mit "Fehler 404:"; für die eigene Domain muss der Titel entsprechend angepasst werden.

Umsatz (bei eCommerce-Tracking) oder Ziele ausgefallen?

Auch wer keinen Shop hat und kein E-Commerce-Tracking nutzt, wird zumindest Ziele definiert haben. Sonst lohnt sich ehrlich gesagt auch der ganze Aufwand mit Analytics nicht 🙂 Und je nach Definition kann die Zielerreichung z. B. durch eine unwissende Umstrukturierung von Inhalten o. Ä. unmessbar werden. Oder schlimmer: technische Probleme hindern die Besucher daran, ein Ziel zu erreichen. Für alle oder ausgewählte Ziele sollte daher ebenfalls eine Benachrichtigung existieren. Wenn es ein belastbares Minimalniveau auf täglicher Basis gibt, kann und sollte der Alert auch für tägliche Kontrolle eingerichtet werden - sonst ist auch ein wöchentlicher Check besser als nichts. Umgekehrt kann ein Ziel auch so wichtig sein, dass es sich lohnt, dieses nicht nur für den gesamten Traffic, sondern getrennt nach Desktop, Tablet und Mobile, für verschiedene Browser oder Regionen zu überwachen. Hier der "einfache" Fall, in dem alle Besuche betrachtet werden:

Social dreht durch?

Zumindest ein Anstieg des Traffics aus sozialen Netzwerken sollte jeder Site einen Alert wert sein, denn das muss nicht immer etwas gutes bedeuten. Wer z. B. eher selten aus dieser Quelle besucht wird, sollte ggf. sogar auf den prozentualen Vergleich verzichten und ab einer absoluten Menge an Besuchern bereits einen Alarm auslösen, so dass zeitnah kontrolliert werden kann, ob ggf. gerade Diskussionen über das eigene Unternehmen stattfinden, an denen man lieber teilnehmen sollte. Das ist definitiv kein Social Media Monitoring, aber wie so oft: Besser als nichts.

"Social" heißt hier im Beispiel Facebook, Pinterest, Facebook und Google Plus. Das ist sicher nicht für jede Site die richtige Mischung. Zur Anpassung können weitere Domains nach dem gleichen Muster hinzugefügt werden wie bei der oben beschriebenen Überwachung einzelner Domains. Wer normalerweise mit Social Traffic gesegnet ist, wird sich vermutlich zudem nach dem gleichen Vorbild wie beim organischen Traffic oder den Verweisen einen Alert für einen spürbaren Rückgang anlegen.

Kampagnen fallen aus?

Auch dieser Block kann je nach Anzahl der nennenswerten Trafficquellen deutlich umfangreicher ausfallen. Hier sollen generell zwei Wege aufgezählt werden, die in den meisten Fällen ausreichen sollten.

Den Anfang macht die Überwachung sämtlicher Besuche aus bezahlten Quellen. Für alle, die mit Google AdWords und oder bei Bing Besucher "einkaufen", ist dieser Filter also geeignet.

Bestimmte Kampagnen überwachen

Alternativ - oder je nach Einsatz auch ergänzend - können einzelne Kampagnen überwacht werden. Dazu wird der Name der Kampagne beim Vergleich verwendet, so wie er entweder z. B. in AdWords definiert oder über die Kampagnenparameter bei der verweisenden URL angegeben wurde.

Wenn es sich bei der Kampagne nicht um eine laufend geführte Kampagne (z. B. bei AdWords) handelt, kann wie hier im Beispiel auch ein Teilvergleich des Namens genutzt werden. Voraussetzung ist hier allerdings, dass wechselnde Kampagnen durchgehend passend zum Filter benannt werden.

"Ungewöhnlicher" Traffic

Die folgende Benachrichtigung ist nur ein denkbares Beispiel von vielen, wenn es um die Erkennung von Anomalien anderer Art geht. Zu Spam finden sich unten bei den weiterführenden Links einige Hinweise und verlinkte Benachrichtigungen. Hier soll eine Benachrichtigung ausgelöst werden, wenn ungewöhnlich viele Besucher aus einem anderen Land als der Zielregion der Domain - hier Deutschland, Österreich und die Schweiz - auf die Site finden. Aber auch nach Sprachen oder anderen Dimensionen lassen sich natürlich ähnliche Alerts definieren.

Ein paar ärgerliche Einschränkungen

Die mangelnde Popularität der Funktion mag auch daran liegen, dass die Implementierung etwas "halbherzig" ist. So kann man diese zwar in mehreren Datenansichten - auch propertyübergreifend - verwenden... aber selbst hier ist eine nachträgliche Änderung bei jedem Alert einzeln nötig. Je mehr Benachrichtigungen genutzt werden, desto umständlicher wird so die Wiederverwendung. Weitere Beschränkungen bei der Nutzung:

• "Benutzerdefiniert" bedeutet tatsächlich, dass jeder Nutzer sie selbst definieren muss. Sie können nicht wie ihre "Nachbarn", die benutzerdefinierten Channelgruppierungen, als Asset geteilt werden.
• Die Verwendung von benutzerdefinierten Segmenten erfordert bei unterschiedlichen Properties oft auch mehrere Regeln - wenn z. B. die Segmente nicht überall sinnvoll verwendet, sondern pro Site zum gleichen Zweck unterschiedlich (mehrfach) definiert werden müssen.
• Komplexe oder mehrere verknüpfte Bedingungen sind nicht möglich. Bestenfalls über Umwege wie Filter und benutzerdefinierte Felder kommt man gelegentlich zum Ziel - das ist aber weder benutzerfreundlich, noch so vorgesehen.

Wer deshalb seine eigenen Vorstellungen von sinnvollen Benachrichtigungen nicht weiterkommt, muss zwangsweise auf die API ausweichen oder bestehende auf der API basierende Tools wie Metrics Watch

Brauchen wir Alerts?

Die Frage darf tatsächlich gestellt werden. Wer jetzt noch keine eingerichtet hat, mag z. B. auf Radarereignisse setzen. Während die Intelligenzberichte in Analytics das Ende der Betaphase nicht erreicht haben und "nur noch" die benutzerdefinierten Benachrichtigungen übrig sind, wurden schon 2016 deutlich sinnvollere Alternativen von Google in Aussicht gestellt, welche bald auch in den Produkten ankommen sollten. Die Andoid App zeigt bereits entsprechende Hinweise im "Radar", den wir sicher bald auch im Web nutzen können:

Ebenso lassen sich viele Dinge ohnehin nur bedingt durch die o. a. Einschränkungen mit einem Alarm versehen - oder es gibt geeignetere Tools wie zur Überwachung der Serverperformance, organischer Keywords & Co. Der Eigenbau eines Alarmsystems klingt daher verlockend. Und ist auch gar nicht so unrealistisch, wie es auf den ersten Blick erscheinen mag. Über das Google Analytics Spreadsheet Add-on lassen sich auch ohne große Kenntnisse von Programmiersprachen oder tiefe Einblicke in die API entsprechende Berichte erstellen und auch deren Versand automatisieren.

Noch nicht genug? Weitere Listen

Wer hingegen statt nach Alternativen nach Inspiration für weitere Alerts sucht, wird z. B. bei den folgenden Quellen fündig:

• 8 Google Analytics Alerts, die Dir den Arsch retten von Michael Janssen. Auch wenn es "nur" 8 sind, gibt es einige, die hier nicht berücksichtigt sind oder dort anders gelöst werden.
• Wer nicht mit Filtern gegen Spam vorgeht, kann sich zumindest ein paar hilfreiche Benachrichtigungen einrichten. Beispiele dazu finden sich unter 11 Useful Google Analytics Custom Alerts.
• Wer es "etwas granularer" mag, findet bei Lunametrics gleich 55+ Google Analytics Custom Alerts in englisch. Da der Beitrag schon älter ist, werden hier allerdings auch Keywordalerts empfohlen, die nicht mehr sinnvoll nutzbar sind.