FOL9000

Referer-Spam in Google-Analytics loswerden

von

Manch einer wird in den Traffic-Quellen für seine Web-Site den einen oder anderen mysteriösen Eintrag gefunden haben. Zugriffe von domains wie semalt.com, darodar.com oder buttons-for-website.com oder aus Ländern, von denen man vermuten müsste, dass man dort schon wegen der Sprache kein größeres Interesse an der Web-Site haben dürfte. Diese Zugriffe können die Analytics-Daten erheblich verfälschen, denn sie stellen keinen ‚echten‘ User-Traffic dar, sondern meist Referer-Spam. Auch einige der Sites, die ich betreue sind von diesem Problem befallen, teilweise mit starken Auswirkungen auf die Qualität der Tracking-Daten. Aber es gibt Mittel und Wege, wie man dieser Pest Herr werden kann.

Update: Zwischenzeitlich hab ich einen Regulären Ausdruck anpassen müssen!

Referer-Spam

Zunächst einmal zum Problem selbst. Referer-Spammer rufen eine Web-Site auf, um in deren Logs (früher) oder (moderner) Tracking-Daten aufzutauchen. Dadurch erhoffen sich die Spammer, dass Google daraus schließt, dass von vielen Seiten auf sie verwiesen wird und deshalb ihre eigene Seite entsprechend höher wertet. Im Falle von Google-Analytics geht dies noch weiter. Die Spammer lesen den Analytics-Code einer Seite aus und rufen dann direkt, ohne den Umweg über die Seite den Analytics-Code selbst auf. Sie täuschen also nur vor, dass sie auf die Seite mit einem bestimmten Tracking-Code zugegriffen hätten — nur um gezählt zu werden und in der Referer-Statistik von Analytics aufzutauchen. Ich hoffe, dass diese Erklärung soweit korrekt ist, denn so ganz erschließt sich auch mir die Taktik der Spammer nicht immer. Aber wie auch immer: Der Dreck muss weg.

Die Beschreibung zeigt aber auch, dass diese Art von Spam zwar lästig ist, aber auf der eigentlichen Web-Site keinen Schaden anrichtet; nur die Zugriffs- und Traffic-Statistiken sind zugemüllt und nicht mehr korrekt auszuwerten.

Einige typische Domains solcher Spammer habe ich schon in der Einleitung aufgezählt. Aber es gibt natürlich noch viele weitere: econom, darodar, ilovevitaly, buttons-for-website, semalt, makemoneyonline, priceg, blackhatworth… Diese Liste ließe sich wahrscheinlich endlos fortsetzen, vollständig würde sie nie. Eine recht lange Liste verwendet dieses Projekt auf GitHub.

Aus gegebenem Anlass habe ich etwas zu diesem Problem recherchiert und stelle hier ein paar Infos zusammen. Natürlich kann das keine endgültige Lösung sein. Es stellt vielmehr meinen aktuellen Stand dar. Für Anregungen bin ich deshalb immer dankbar. Wer Probleme hat, denen sich mit den beschriebenen Ansätzen nicht beikommen lässt oder wer bessere Lösungen hat: schreibt einen Kommentar, damit alle was davon haben.

Eine mehrstufige Abwehr-Strategie

Um mit Referer-Spam umzugehen, bietet sich eine mehrstufige Strategie an. Hat man das Spam-Problem (noch) nicht, versucht man einfach, die Bots der bekannten Spammer auszusperren. Damit ist man zwar gegen neue Domains der Spammer machtlos, aber es ist ein erster Schritt. Ist man schon Opfer geworden, muss man versuchen, ihre Daten aus den Analytics-Auswertungen auszufiltern.

Vorbeugen, die erste: Bekannten Spammern den Zugang verweigern

Der erste Schritt könnte darin bestehen, bekannte Spammer einfach auszusperren. Dies geschieht am einfachsten über Einträge in der .htaccess-Datei. Mit den folgenden Zeilen würden Clients mit der Domain unerwuenscht im Referer abgewiesen und bekämen eine 403-Status-Code (Forbidden) zurück:

RewriteEngine on
RewriteCond %{HTTP_REFERER} ^(?:([^.]+)\.)?(?:([^.]+)\.)?(unerwuenscht)\.(com?|de|net|ru) [NC]
RewriteRule .* – [F]

Das geht auch mit mehreren Domains über mehrere Conditions. Wichtig ist hier das OR in allen Zeilen außer der letzten:

RewriteCond %{HTTP_REFERER} ^(?:([^.]+)\.)?(?:([^.]+)\.)?(unerwuenscht)\.(com?|de|net|ru|org) [NC,OR]
RewriteCond %{HTTP_REFERER} ^(?:([^.]+)\.)?(?:([^.]+)\.)?(bleibweg)\.(com?|de|net|ru|org) [NC]

Man kann das auch noch in einer Zeile zusammenfassen, obwohl mir das eigentlich zu unübersichtlich ist. In dieser Form kann man den Regulären Ausdruck aber auch in Analytics selbst nutzen, weswegen ich ihn hier doch aufführe:

RewriteCond %{HTTP_REFERER} ^(?:([^.]+)\.)?(?:([^.]+)\.)?(unerwuenscht|bleibweg)\.(com?|de|net|ru|org) [NC]

Update: In einer früheren Version des Ausdruck fehlte die Top-Level-Domain org. Natürlich könnte man den Ausdruck vereinfachen, indem man einfach alle TLDs abgreift. Mir ist es so aber lieber, weil ich dann vor dem Ändern und Erweitern erst noch sehe, was durchgekommen ist. Ist aber Geschmackssache.

Entscheidend ist der Reguläre Ausdruck in der Condition-Zeile. Er muss verschiedene Toplevel-Domains abdecken (z.B. .com, .co, .ru etc.), aber auch verschiedene Subdomains. Einfach nur www.unerwuenscht.com zu filtern reicht nicht. Dieser Ausdruck stammt nicht von mir selbst, ich habe ihn von revision6 und nur ganz minimal verändert.

Da die Spammer so nicht mehr auf die Seiten kommen, fallen auch keine Daten von ihnen an. Es gibt also auch keine Möglichkeit festzustellen, wer überhaupt oder wie oft abgewiesen wurde. (Oder vielleicht doch in den Server-Logs?)

Mit dieser Maßnahme kommen einige Übeltäter schon mal nicht mehr auf die Seiten.

Vorbeugen, die zweite: Analytics-Code verschleiern

Hat ein bis dahin unbekannter Spammer die erste Hürde dann doch genommen und hat er es auf den Analytics Tracking-Code angesehen, sollte man ihm den Code nicht im Klartext anbieten. Dazu setzt man den Tracking-Code einfach aus mehreren Teilen zusammen. Ein Bot wird so keinen Text finden, der dem Muster eines Tracking-Codes entspricht. Für Google hingegen wird der Code vor dem Registrieren zusammengesetzt.

Wo man bisher etwa wie folgt den Tracking-Code übergeben hat:

ga('create', 'UA-12345678-1', 'auto');

Schreibt man nun einfach:

ga('create', 'UA-1' + '234' + '567' + '8-1', 'auto');

Mit diesem simplen Trick wird es für Bots praktisch unmöglich sein, den Tracking-Code auszulesen. (Es sein denn, sie führen Javascript aus, dann nützt dieser Trick nichts.)

Spätestens jetzt sollte man aber kurz checken, ob man sich nicht verschrieben hat oder irgendeinen anderen Bug eingebaut hat. Am einfachsten wird es sein, über die Echtzeit-Analyse zu prüfen, ob die eigenen Bewegungen auf der Seite korrekt registriert werden.

Update: Es sieht so aus, als würden auch Analytics oder die Webmaster-Tools dann, wenn sie die Eigentümerschaft einer Seite checken, einen wie oben zusammengesetzten Tracking-Code nicht erkennen. Offenbar wird nach dem entsprechenden Code einfach gesucht und auf diese Weise soll er ja auch nicht zu finden sein. Bei mir half es in einem solchen Falle, den Tracking-Code wieder wie üblich als einzelnen String auf der Seite zu haben. Nach der Erkennung hab ich ihn dann wieder wie beschrieben zusammengesetzt und es lief weiterhin wie gewünscht. Dass es solche Probleme geben kann, sollte man also im Blick haben.

Vorbeugen, die dritte: Bekannte Spammer in Analytics selbst filtern

Auch Analytics bietet die Möglichkeit an, Daten bekannter Spammer auszufiltern. Dieses Filtern kann auf zwei Wegen geschehen: Zunächst mit dem von Google angebotenen Filter auf der Basis einer Google-eigenen Spammer-Liste und mit einem eigenen Filter.

Wichtig ist zu wissen, wie Analytics-Filter arbeiten. Ein Filter setzt schon beim Eingang der Daten an: Gefilterte Daten werden nicht gespeichert. Das muss man immer berücksichtigen, denn man kann einmal ausgefilterte Daten nicht wieder rekonstruieren. (Mit der oben beschriebenen .htaccess-Lösung geht das natürlich auch nicht.)

Google-bekannte Bots ausschließen

Den Google-eigenen Filter sollte man eigentlich immer aktiv haben. Ich wüsste keinen Grund, ihn nicht zu nutzen. Ich habe aber leider keine Ahnung, ob es irgendwo eine Liste dieser bekannten Bots gibt. Man weiß also nicht, was dort gefiltert wird und v.a. bleibt unklar, was nicht gefiltert wird. Aber es kann trotzdem kein Fehler sein, Google bei der Spam-Abwehr mitarbeiten zu lassen. Auch die Infos über die weggefilterten Zugriffe sind dann aber weg.

Dazu in Analytics unter ‚Verwalten‘ und dort unter ‚Datenansicht‘ die ‚Einstellungen der Datenansicht‘ anklicken. Ganz unten findet sich dort die Checkbox ‚Alle Treffer von bekannten Bots und Spidern ausschließen‘; sie sollte angewählt sein.

Einen eigenen Filter aktivieren

Wenn man wie oben beschrieben per .htaccess unerwünschte Spammer ausschließt, kann man sich einen selbst-definierten Filter in Analytics eigentlich sparen. Denn er würde auch nur filtern können, was man schon vorher abgewiesen hat — für diesen Filter bliebe also nichts mehr zu tun. Man setzt dafür ja auch den gleichen Regulären Ausdruck ein. Ich nutze einen eigenen Analytics-Filter für dieses Problem deshalb auch nicht. Wer einen solchen Filter trotzdem einsetzen möchte, finden eine Anleitung mit Screenshots bei revision6, von wo auch das Vorbild für den Regulären Ausdruck kommt. Auch hier gilt wie immer bei Filtern: Die ausgefilterten Daten sind nach Aktivierung des Filters weg.

Einschub: Wenn ich aber alles wissen will und die Spammer-Daten einsehen möchte?

Es mag Gründe geben sehen zu wollen, welche Spammer den nun wirklich in welchem Ausmaß abgewiesen werden. Dann sind alle bisher beschriebenen Maßnahmen nicht oder nur mit einem Zwischenschritt geeignet. Denn sowohl die .htaccess-Lösung als auch die Analytics-Filter filtern die Spammer-Daten unwiederbringlich aus.

Für mich ist das kein Problem. Wer es aber anders haben möchte, sollte erst einmal nicht die .htaccess-Lösung nutzen, sondern ganz auf Analytics-Filter setzen. Dann sollte man eine Datenansicht haben, in der keine Daten ausgefiltert werden. (Was man ja bei jedem Filter-Einsatz überlegen sollte.) Eine Datenansicht also mit allen ungefilterten Roh-Daten. In einer zweiten Datenansicht könnten dann die Spammer ausgefiltert werden. So hat man beides, immer 100%ig korrekte Roh-Daten und die gefilterten, auswertbaren Daten. Typisch würde man die ursprünglich angelegte Datenansicht (‚Alle Website-Daten‘) unangetastet lassen und sich eine neue zweite für den Filter anlegen.

Keine endgültige Lösung

Die bisher vorgestellten Maßnahmen sind Lösungen zur vorbeugenden Abwehr bekannter Spammer. Greifen neue, bis dato unbekannte Spammer auf die Web-Site zu, muss man die .htaccess-Einträge oder die Analytics-Filter um die neuen Domains erweitern. Es bleibt also dabei, dass man die Zugriffe laufend kontrollieren muss. Auch wenn man irgendwo von neuen Spam-Quellen liest, kann man gleich die Einträge erweitern.

Trotz aller Vorsichtsmaßnahmen wird es aber irgendwann sicher wieder ein Spammer schaffen an allen Barrieren vorbei zu kommen. Nachdem man die eigenen Filter erweitert hat, muss man sich dann Gedanken machen, wie man deren Daten in Analytics unschädlich macht.

Wenns zu spät ist: Segmente einsetzen

Man kann nicht alle Spam-Domains kennen und meist reagiert man auf dieses Problem erst, wenn ihre Zugriffe bereits die Analytics-Auswertungen stören. Man wird sich deshalb fast immer überlegen müssen, wie man die schädlichen Auswirkungen dieser bereits aufgelaufenen Spam-Daten in den Griff bekommt. Man kann den alten Datenmüll in Analytics nicht einfach löschen. Aber er lässt sich mit Analytics-Bordmitteln unschädlich machen.

Die Lösung ist ganz simpel: Man legt in Analytics ein neues Segment an.

Mit einem Segment kann man in Analytics die Datenauswertung auf einen Teil der Daten beschränken bzw. einen Teil der Daten ausblenden. Wichtig ist, dass die Daten — anders als bei einem Filter — erhalten bleiben. Typisch werden Segmente dazu eingesetzt, für eine Auswertung z.B. nur Daten von Mobil-Geräten oder eines bestimmten Betriebssystems zu berücksichtigen.

Um den schädlichen Einfluss der bereits aufgelaufenen Spammer-Daten in den Griff zu bekommen, kann man ein Segment anlegen, das eben diese Daten ausblendet.

Um ein neues Segment anzulegen klickt man im Segment-Bereich ganz oben über dem eigentlich Report auf ‚+ Segment hinzufügen‘. Es öffnet sich ein Bereich, in dem man mit dem roten Button ‚Neues Segment‘ das neue Segments definieren kann. Links unter ‚Erweitert‘ ‚Bedingungen‘ auswählen und den Filter für ‚Nutzer‘ und ‚Ausschließen‘ definieren. Die auszuschließenden Benutzer sollen identifiziert werden anhand von ‚Quelle/Medium‘. Dann ‚ist eine von‘ auswählen und in der folgenden Liste eine auszuschließende Domain auswählen. Analytics bietet hier eine Liste alle bekannten Quellen an, sodass die Auswahl einfach ist. Auf diese Weise definieren wir einen Filter für jede Domain, deren Daten ausgeblendet werden sollen. Die einzelnen Filter werden mit einer ‚Oder‘-Bedingung verknüpft. (‚Filter‘ ist hier natürlich nicht zu verwechseln mit einem Analytics-Filter; es ist der dem Segment zugrunde liegende Filter.) Durch Anklicken von ‚Oder‘ wird eine neue Zeile zum Eingeben eines weiteren Ausdrucks angezeigt. Auf diese Weise kann für jede Spam-Domain ein Filter im Segment angelegt werden.

Analytics-Segment

Analytics-Segment

Schon während der Eingabe der Segment-Daten wird rechts daneben angezeigt, wie groß der Einfluss des Segment-Filters ist. Hat man das Segment gespeichert und für den Report aktiviert, stellt Analytics die Daten des neues Segments zusätzlich zu den alten, kompletten Daten dar. Man kann das Segment, das alle Daten darstellt aber auch deaktivieren, dann werden nur noch die für die Auswertung interessanten Daten angezeigt. Zumindest am Anfang ist die gemeinsame Darstellung aber sicher interessant. Denn wenn alle Maßnahmen greifen, müssten sich die Graphen für das Segment mit den kompletten Daten und das Anti-Spam-Segment angleichen. Das ist dann das Zeichen dafür, dass kein Spam mehr durchkommt.

Dran bleiben

Für’s erste wird man nun Ruhe und saubere Daten haben. Aber ganz sicher wird irgendwann wieder ein seltsamer Eintrag in den Daten auftauchen. Dann heißt es Filter, Segmente etc. erweitern und hoffen, dass es bis zum nächsten wieder etwas dauern wird.

Kommentare sind geschlossen.