Das Putzlowitsch Test- und SEO-Blog

Bing Bilder-Liste 1.0 – Ein Bookmarklet für die Bing Bildersuche

Bookmarklets

Die Bookmarklets sind feine Sachen, denn man kann tolle Dinge damit machen. :-)

Ein Bookmarklet ist ein Browser-Lesezeichen, welches aber nicht die URL einer Webseite speichert, sondern Javascript-Code. Dieser kann dann auf eine gerade im Browserfenster angezeigte Webseite losgelassen werden.

Das Bookmarklet hat Zugriff auf den kompletten Seiteninhalt, kann diesen verändern oder Daten extrahieren und z.B. in einem neuen Fenster darstellen.

Vor einiger Zeit hatte ich bereits ein Bookmarklet für die Google-Bildersuche erstellt. Das habe ich nun für die Bing-Bildersuche adaptiert, denn auch bei Bing ist es recht mühselig, die relevanten Informationen aus der Ergebnisseite zu extrahieren.

Bing Bilder-Liste

Bookmarklet – Bing Bilder-Liste (1.0)

Bookmarklet – Bing Bilder-Liste (1.0)

So sieht die Trefferliste der Bing-Bildersuche für Geld nach Aufruf des Bookmarklets aus. Die Ausgabe ist gefiltert, Bing findet natürlich mehr Geld-Bilder als nur vier. :-)

Die Liste

Die Tabelle zeigt in der ersten Spalte das Thumbnail und die Bildgröße, in der zweiten die Position in der Bildersuche an. In der dritten Spalte findet man untereinander Bild-Id, Bild-URL und Seiten-URL (Referenz). Die Kästchen davor geben durch verschieden Farben Auskunft über den Status.

Für Bild-ID, Bild-URL und Seiten-URL bedeutet grün, daß es sich um ein eigenes Bild bzw. eine eigene Seite handelt. Ist das Kästchen vor der Seiten-URL gelb, kommt der Treffer von einer erlaubten Domain, die aber keine eigene ist.

Das rote Kästchen zeigt einen Hotlink bzw. eine Bildkopie an. Das Bild ist also ein eigenes Bild (ID oder Bild-URL), die Seite ist jedoch nicht in der Liste der eigenen oder erlaubten Domains zu finden.

Ein Klick auf eines der Kästchen zeigt folgendes an:

Bild-URL: das Bild
Seiten-URL: die Seite mit dem Bild

Die Optionen

Im oberen Berich kann man Ausgabe-Filter festlegen. Folgende Optionen sind für die Anzeige möglich:

(●) Alle Bilder
alle Bilder, die in der Bing-Trefferliste vorhanden sind
(●) Eigene Bilder
Bilder, die in der Liste der eigenen Domains oder bei den gespeicherten Bild-IDs zu finden sind
(●) Eigene Seiten
Seiten, die in der Liste der eigenen Domains zu finden sind
(●) Hotlinks/Kopien
Eigene Bilder, bei denen die Seite nicht in der Liste der eigenen oder erlaubten Domains zu finden ist
(●) Gefilterte Seiten
Seite, die in der Domain-Filter Liste zu finden sind

Die Option [x] Filter negieren dreht die Logik um. Das beutet z.B. für die Option Eigene Seiten, daß nun alle Seiten angezeigt werden, die nicht in der Liste der eigenen Domains zu finden sind.

Mit der Option [x] Nur ein Treffer pro Domain wird nur der jeweils erste Treffer einer Domain angezeigt.

Die Aktionen

Einzige Aktion ist im Moment der Download der Bilderliste als CSV-Datei mit CSV Download. Die Liste wird so ausgegeben, wie sie gerade angezeigt wird. Die Felder sind mit Semikoln getrennt. Damit können die Daten einfach z.B. in Excel weiterverarbeitet werde.

Bing Bilder-Liste Konfiguration

Bookmarklet – Bing Bilder-Liste Konfiguration

Bookmarklet – Bing Bilder-Liste Konfiguration

Mit dem Konfigurations-Bookmarklet können die Domainlisten und Optionen verwaltet werden.

Welche Liste wofür benutzt wird, geht aus Beschreibung oben zu den Filtern hervor.

Der Text im Eingabefeld wird mit [Hinzufügen] der Liste hinzugefügt. Dabei wird nicht geprüft, ob es sich syntaktisch um eine Domain handelt. Die Text ist ohne http:// und / am Ende einzugeben, also nur der Domainname. Es konnen auch mehrere Namen mit Leerzeichen, Komma oder Semikolon getrennt eingegeben/eingefügt werden.

Mit [Löschen] werden Einträge aus der Liste gelöscht. Eine Mehrfachauswahl ist möglich. Die aktuelle Liste kann mit Download als Textdatei heruntergeladen werden. Die Einträge sind mit Semikolon getrennt.

Mit Optionen kann die Voreinstellung für das Anzeigefilter festgelegt werden.

Zu guter Letzt und gaaanz wichtig, mit [Einstellungen speichern] werden die Einstellungen übernommen.

Die Listen der Domains und die Optionen werden im localStorage gespeichert, was bei sehr alten Browsern nicht funktioniert. Zudem müssen Cookies für die Bing-Domain erlaubt sein.

Die Bookmarklets

Aktuelle Version: 1.0

Bing Bilder Liste Bing Bilder Konfig

Die Bookmarklets sind zwar Links, es macht aber wenig Sinn, diese hier direkt anzuklicken. Vielmehr müßt Ihr sie als Lesezeichen im Browser speichern, also z.B. einfach in die Bookmarkleiste ziehen.

Hinweise zur Benutzung

Dann ruft Ihr die Bing-Bildersuche mit dem gewünschten Suchbegriff auf und startet das Bookmarklet durch Anklicken des Lesezeichens (Buttons in der Lesezeichenleiste).

Bookmarklet – Bing Bilder-Liste Anwendung

Bookmarklet – Bing Bilder-Liste Anwendung

Bing stellt in der Bildersuche direkt nach dem Aufruf zunächst die Liste der ersten 70 Treffer bereit. Falls Ihr mehr Ergebnisses in der Liste haben wollt, müßt Ihr mit dem Scrollbalken rechts ganz nach unten Scrollen. Dann werden ggf. in 70er Blöcken weitere Suchergbnisses nachgeladen. Und auch hier gilt, wollt Ihr die komplete Liste haben, müßt Ihr ganz nach unten scrollen.

Getestet habe ich die Bookmarklets bisher mit Firefox 63.0.1 und Google Chrome 49.0.2623.87, damit funktioniert es. Mit dem Internet Explorer 9.0 funktioniert es nicht, dem sind die URLs zu lang.

Viel Spaß beim finden Eurer Bilder! :-)

Keine Kommentare »

GSC-Liste – ein Bookmarklet für die Google-Search-Console

Bookmarklets

Bookmarklets sind feine Sachen, denn man kann tolle Dinge damit machen. :-)

Ein Bookmarklet ist ein Browser-Lesezeichen, welches aber nicht die URL einer Webseite speichert, sondern Javascript-Code. Dieser kann dann auf eine gerade im Browserfenster angezeigte Webseite losgelassen werden.

Das Bookmarklet hat Zugriff auf den kompletten Seiteninhalt, kann diesen verändern oder Daten extrahieren und z.B. in einem neuen Fenster darstellen.

Vor einiger Zeit hatte ich bereits mal ein Bookmarklet geschrieben, das die Ergebnisseite der Google-Bildersuche auswertet und eine neue, übersichtliche Listenansicht erstellt. Die Daten aus dieser Ansicht können auch als CSV-Datei gespeichert werden.

Die Google-Search-Console, ehemals Webmaster-Tools

GSC – Indexierungsstatus

GSC – Indexierungsstatus

Die Google-Search-Console (GSC) bietet dem Webmaster viele nützliche Werkzeuge und Statistiken. So kann man sich z.B. den Indexierungsstatus für eine Website ansehen.

Der Bericht „Indexierungsstatus“ bietet Daten zu den URLs, die Google im vergangenen Jahr in der aktuellen Property zu indexieren versuchte.

Dieser Wert gibt die Gesamtzahl der URLs an, die für die Anzeige in den Suchergebnissen verfügbar sind, zusammen mit weiteren URLs, die Google mit anderen Methoden finden könnte. Diese Zahl variiert im Laufe der Zeit, während Sie Seiten hinzufügen und entfernen. Die Anzahl der indexierten URLs ist fast immer deutlich kleiner als die Anzahl der gecrawlten URLs, weil unter Insgesamt indexiert nicht jene URLs aufgeführt werden, die als Duplikate oder nicht kanonisch betrachtet werden oder die ein noindex-Meta-Tag enthalten.

Mit dem Button [Diagrammdaten herunterladen] kann man die Daten als CSV-Datei oder in Google-Docs speichern. Teilweise kann man Daten auch per GSC-API abfragen, speichern und weiterverarbeiten.

Nur leider gibt es diese Möglichkeit nicht in allen Bereichen der Search-Console.

Speichern oder nicht speichern, das ist hier die Frage

Wegen eines Problems mit einem meiner Webhoster waren Anfang des Jahres zwei Statistiken für mich besonders interessant, die „Website-Fehler“ und die „Crawling-Statistiken“.

Und genau bei diesen Statistiken gibt es keine Speichermöglichkeit und meines Wissens auch keinen Zugriff per API. Man kann bestenfalls einen Screenshot machen, aber da sieht man keine konkreten Zahlen. Beim Überfahren des Diagramms mit der Maus werden zwar die Daten zum aktuelle Datenpunkt eingeblendet, aber eben nur für den einen.

GSC – Keine Antwort vom Server

GSC – Keine Antwort vom Server

Aber irgendwo auf der Webseite müssen die Daten ja zu finden sein, wenn sie als Tooltip-Fenster angezeigt werden können.

GSC-Liste Bookmarklet

Ja, die Daten sind auf der Webseite zu finden und genau hier kommt nun das Bookmarklet ins Spiel. Es extrahiert die Daten und stellt sie als CSV-Datei bereit. Es gibt keinerlei Einstellmöglichkeiten und es wird auch keine neue Browserseite geöffnet. Der Klick auf [GSC Liste] öffnet nur den „Datei speichern“-Dialog.

GSC-Liste als CSV-Datei speichern

GSC-Liste als CSV-Datei speichern

Der Dateiname wird aus dem letzten Teil des Pfades der URL in der GSC (‚crawl-stats‘, ‚crawl-errors‘), dem Domain-Namen und dem Datum von bis zusammengesetzt.

Hier findet Ihr das Bookmarklet Version 1.0:

GSC Liste

Die Bookmarklets sind zwar Links, es macht aber wenig Sinn, diese hier direkt anzuklicken. Vielmehr müßt Ihr sie als Lesezeichen im Browser speichern, also z.B. einfach in die Bookmarkleiste ziehen.

Das Bookmarklet funktioniert nur auf den Seiten „Crawling-Statistiken“ und „Crawling-Fehler“ in der Google-Search-Console.

Ich habe es mit den aktuelle Desktop-Versionen von Firefox (57.0.4) und Chrome (63.0.3239.132) getestet. Damit funktioniert es. Wie es mit anderen Browsern aussieht, kann ich nicht sagen. Das könnt Ihr gerne ausprobieren und hier dann in den Kommentaren berichten. :-)

2 Kommentare »

Google Bilder-Liste 1.5 – Update des Bookmarklets für die Google Bildersuche

Bookmarklet Google-Bilder-Listen 1.5

Bookmarklet Google-Bilder-Listen 1.5

Vor einigen Wochen hat Google die Meta-Daten aus der Universal-Search-Bilderbox entfernt. Auch in der URL zur Bildersuche sind nicht alle wichtigen Informationen enthalten. So fehlt zum Beispiel die Bild-URL und auch die Seiten-URL ist nicht mehr vorhanden.

Mein Google-Bildersuche Bookmarklet benötigt aber genau diese Informationen (und noch ein paar mehr), damit es funktioiert. Im Knowledge-Graph und in der Bildersuche selbst sind die Meta-Daten zu den Bildern noch vorhanden.

Aus den Daten der Bilderbox kann man glücklicherweise noch die Bild-Id ermitteln. Damit können dann die passenden Daten in der Bildersuche abgegriffen werden. Und genau so funktioniert auch die Erweiterung der neuen Version 1.5 des Bookmarklets.

Falls eine Bilderbox zu sehen ist, wird im Hintergrund die Bildersuche seitenweise in Blöcken zu 100 Suchergebnissen aufgerufen, bis die Daten zur entsprechenden Bild-Id gefunden wurden. Es kann aber auch passieren, daß das Bild nicht in der Bildersuche vorhanden ist. Dann wird wie beim zweiten Treffer oben im Screenshot als Bild-URL example.org angezeigt. Zudem gibt es keine Bildgröße und wegen dern fehlenden Doc-Id auch keine Suche nach ähnlichen Bildern, weiteren Größen usw.

Durch das Abrufen der Bildersuche kann es zu mehreren Sekunden Verzögerung kommen, bis die Liste angezeigt wird. Das hängt unter anderem auch davon, an welcher Position und ob überhaupt das Bild aus der Bilderbox in der normalen Bildersuche zu finden ist.

Für gefundene Bild wird in Klammern die Position in der Bildersuche ausgegeben, oder falls nicht vorhanden -1.

Update Version 1.6: Es hatten sich noch ein paar kleiner Fehler eingeschlichen, die mit Version 1.6 behoben wurden.
Außerdem gibt es durch einen Fehler die neue Erkenntnis, daß für die Suche nach ähnlichen Bildern, weiteren Größen usw. als Doc-ID auch die Bild-ID verwendet werden kann. Also funktionieren diese Abfragen auch dann, wenn das Bild selbst nicht in der Bildersuche gefunden wurde. :-)

Das aktuelle Google-Bildersuche Bookmarklet findet Ihr hier.

Keine Kommentare »

Das Siebtlingsgeburt-Ranking im Blog mit meinem Plugin einbinden

Gestern hatte ich ja bereits die maschinenlesbaren Daten von ranking-123.de vorgestellt. Ihr könnt diese Daten selbst nutzen und auswerten (wenn Ihr es könnt :-). Oder Ihr benutzt einfach mein WordPress-Plugin, das ich hier kurz vorstellen will.

Siebtlingsgeburt Top-100

Siebtlingsgeburt Top-100

123 Top-100 Plugin

Das Plugin besteht im wesentlichen aus zwei Funktionen.

Die erste Funktion agn_top100_read_data ist für das Abholen der Daten im JSON-Format zuständig. Hier habe ich etwas mehr Aufwand betrieben, um unnötige Requests und Datenübertragungen zu vermeiden. Die Daten werden lokal auf dem Server der WordPress-Installation im Verzeichnis wp-content/uploads gespeichert. Dieses muß daher von WordPress beschreibbar sein, damit das Caching funktioniert.

Die zweite Funktion agn_top100_shortcode implementiert einen WordPress-Shortcode, mit dem man sich die gewünschten Daten im Artikel oder auf der Seite ausgeben lassen kann.

Im einfachsten Fall sieht das dann so aus:
...
Hier findet ihr die aktuelle Siebtlingsgeburt Top-100:
<table class='chart-list'>[agn_top100 nam='siebtlingsgeburt']</table>
...

Per Voreinstellung wird die Liste als Tabelle ausgegeben, allerdings ohne Table-Tags. Die müßt Ihr selbst drumrum packen. Das hat den Vorteil, daß Ihr der Tabelle einfach eine CSS-Klasse oder sonstige Formatierungen mitgeben könnt.

In der Voreinstellung ergibt sich damit eine Tabelle wie auf dieser Beispielseite (ohne Grafik). Die Platzierung wird einfach durchnummeriert, vor der URL steht ggf. ein Symbol für den Ergebnistyp, hinter der URL folgt ein Link-Symbol mit einem (nofollow!) Link zur Seite. URLs, die Länger als 70 Zeichen sind, werden am Ende mit … verkürzt.

Über Shortcode-Parameter kann die Ausgabe angepaßt werden. Folgende Einstellungen sind möglich:

  • nam – Name der Daten
    Vorgabe: ‚xovilichter‚, hier also siebtlingsgeburt eintragen :-)
  • ret – Was soll der Shortcode zurückgeben?
    Vorgabe: ‚rnk‚, mögliche Werte

    • rnk – Ranking Tabelle/Liste (siehe lit)
    • upd – Datum und Zeit des letzten Updates (siehe dtf)
    • cnt – Anzahl der gefundenen Treffer insgesamt
  • max – Maximal Anzahl auszugebender Treffer
    Vorgabe: ‚100‚, eine Zahl zwischen 1 und 123
  • dtf – Ausgabeformat des letzten Updates (siehe ret:upd)
    Vorgabe: ‚‚d.m.Y H:i‘‚, Format entsprechend PHP-Date-Funktion
  • lit – Listentyp: Tabelle oder Liste?
    Vorgabe: ‚tab‚, mögliche Werte

    • tab – Tabelle (table)
    • lst – Liste (ol)
  • cut – Anzahl Zeichen, ab der eine URL verkürzt wird
    Vorgabe: ‚70‚, eine Zahl zwischen 0 (keine Verkürzung) und größer
  • sym – Typ-Symbol vor der URL anzeigen
    Vorgabe: ‚1‚, zum ausschalten ‚0‘ verwenden
  • lnk – Link am Ende der URL ausgeben
    Vorgabe: ‚1‚, zum ausschalten ‚0‘ verwenden

Hier ein paar Beispiele:
...
<ol>[agn_top100 nam='siebtlingsgeburt' max='33' lit='lst' sym='0']</ol>
...

Gibt maximal 33 Einträge als HTML-Liste (OL) ohne vorangestelltem Typ-Symbol aus.

...
Top-100 vom [agn_top100 nam='siebtlingsgeburt' ret='upd' dtf='l, d.m.Y H:i'] Uhr
...

Gibt den Zeitpunkt des letzten Updates formatiert aus.

Technische Voraussetzungen und Download

Technische Voraussetzungen:

  • WordPress 3.8 oder höher
  • PHP 5.2 oder höher mit curl-Funktion
  • Verzeichnis wp-content/uploads muß von WordPress beschreibbar sein

Download Version 0.18: 123 Top-100 Plugin

Falls es Unklarheiten oder Fragen gibt, einfach fragen. :-)

Ein Kommentar »

Besucher aus der Bildersuche tracken – in der Server-Logdatei und mit Google-Analytics

Früher war alles besser

Bildersuche Referrer

Bildersuche Referrer

Um zu erkennen, ob der Besucher einer Seite über die Bildersuche kommt, konnte man lange Zeit den Referrer auswerten. Dort fand man bestimmte Parameter (z.B. /imgres), die auf einen Treffer aus der Bildersuche schließen ließen.

Seit der Einführung der neuen Bildersuche bei google.de fehlen diese Parameter im Referrer und es steht bestenfalls noch „https://www.google.de/“ drin.

Bei vielen Websitebetreibern [1] [2] [3] führte das zu dem Schluß, daß nun von der Bildersuche praktisch gar keine Besucher mehr kommen. Es handelt sich aber um ein „Meßfehler“ in Google-Analytics, weil die alten Methoden zum tracken der Bildersuche nun nicht mehr funktionieren.

Die neue Bildersuche hat aber diesbezüglich einen positiven Aspekt, denn vor dem Besuch der Seite, wenn es denn dazu kommt, wird das Original-Bild vom Server abgerufen.

Tracking mit Keksen

Kekse – Cookies

Kekse – Cookies (Foto: ajt / 123RF)

Wie hilft uns das nun bei der Erkennung von Besuchern aus der Bildersuche?

Beim Abruf des Bildes kann ein Cookie gesetzt werden, das dann beim Aufruf der Seite ausgewertet wird. Gut, falls jemand Cookies deaktiviert hat, funktioniert das natürlich nicht, aber so viele Nutzer von Suchmaschinen werden das nicht sein.

Auch früher gabe es schon nutzerbedingte Meßfehler. Hat der Nutzer z.B. die Übertragung des Referrers ausgeschaltet, konnten die Zugriffe nicht zugeordnet werden. Hat der Nutzer gar JavaScript deaktiviert oder blockiert z.B. per DNS die Zugriffe auf www.google-analytics.com, wurden überhaupt keine Pageviews registriert.

Ich selbst bin ja eher ein Anhänger der Logfile-Analyse und verwende kein Google-Analytics oder andere Tools. Die Logfiles werden ohnehin erzeugt und da steht tatsächlich jeder Zugriff drin. Die richtige Interpretation der Daten ist dann allerdings auch schon eine Kunst für sich.

Zugriff!

Bildersuche-Tracking in der .htaccess

Bildersuche-Tracking in der .htaccess

Fast alle Aktionen, die wir für das Tracking per Cookie benötigen, können in der .htaccess-Datei erledigt werden. Für das Tracking mit Google-Analytics wird ein angepaßter JavaScript-Code erzeugt.

Die technische Basis meiner Lösung ist ein Apache-Webserver mit den aktiven Modulen mod_rewrite und für das Tracking in der Server-Logatei mod_headers.

Der für das Tracking verantwortliche Teil meiner .htaccess sieht so aus:

<IfModule mod_headers.c>
RequestHeader merge Referer "bisutrk=%{BISU_TRK}e" env=BISU_TRK
</IfModule>

<IfModule mod_rewrite.c>
RewriteEngine On

# Aufruf eines existierenden Bildes
RewriteCond %{REQUEST_URI} \.(jpg|png|gif)$
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule . - [E=REQ_IMG:1]

# Aufruf einer normalen Seite
RewriteCond %{REQUEST_URI} !\.[^\.]+?$
RewriteRule . - [E=REQ_PAGE:1]

# Host-Domain
RewriteCond %{HTTP_HOST} (([^\.]+?\.)?[^\.]+?)$
RewriteRule . - [E=OWN_DOM:%1]

# Referrer-Domain
RewriteCond %{HTTP_REFERER} ^https?://(([^\.]+?\.)?([^\.]+?\.)?[^\.]+?)/
RewriteRule . - [E=REF_DOM:%1]

# Referrer Second-Level-Domain (SLD) ist google oder bing
RewriteCond %{ENV:REF_DOM} (google|bing)(\.(com|co))?\.[^\.]+?$ [NC]
RewriteRule . - [E=REQ_SLD:%1]

# Bild -> Cookie setzen
RewriteCond %{ENV:REQ_IMG} 1
RewriteCond %{ENV:REQ_SLD} ^(.+?)$
RewriteRule . - [CO=BiSuTrk:%1:.%{ENV:OWN_DOM}]

# Normale Seite und Cookie gesetzt -> Variable setzen und Cookie löschen
RewriteCond %{ENV:REQ_PAGE} 1
RewriteCond %{ENV:REQ_SLD} ^(.+?)$
RewriteCond %{HTTP_COOKIE} BiSuTrk=([^;]+?)(;|$) [NC]
RewriteRule . - [E=BISU_TRK:%1,CO=BiSuTrk:INVALID:.%{ENV:OWN_DOM}:-1]
</IfModule>

Das sieht vielleicht erstmal etwas kompliziert aus, ist es aber nicht. Es sind auch noch Vereinfachungen möglich.

Die Anweisungen bewirken kein Rewrite und dienen nur zum Setzen und Auswerten von Umgebungsvariablen und zum Setzen bzw. Löschen von Cookies. Der Block sollte vor allen anderen Rewrite-Regeln stehen.

# Aufruf eines existierenden Bildes

RewriteCond %{REQUEST_URI} \.(jpg|png|gif)$
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule . - [E=REQ_IMG:1]

An Hand der Dateierweiterung wird geprüft, ob ein Bild angefordert wird. Außerdem wird getestet, ob es das Bild als Datei gibt. Falls nicht, soll der Zugriff auch nicht getrackt werden. Treffen beide Bedingungen zu, wird das in der Umgebungsvariablen REQ_IMG vermerkt. Diese wird dann später ausgewertet.

# Aufruf einer normalen Seite

RewriteCond %{REQUEST_URI} !\.[^\.]+?$
RewriteRule . - [E=REQ_PAGE:1]

Das eigentliche Tracking soll nur beim Aufruf einer normalen Seite erfolgen. Naheliegend wäre, daß man die Bedingung „Ist ein Bild“ einfach umkehrt, also negiert. Das trifft aber nicht immer zu, denn je nach Webbrowser wird nach dem Bild zum Beispiel noch das Favoriten-Icon favicon.ico abgerufen. Dieser Aufruf würde dann bereits das Tracking auslösen, was nicht gewollt ist.

Hier muß also eine Regel formuliert werden, die einen normalen Seitenaufruf beschreibt. In meinem Fall sind es die Permalinks von WordPress, die sich dadurch von normalen Dateiaufrufen unterscheiden, daß sie keine Dateiwerweiterung wie z.B. .jpg, .ico oder .css haben.

Wenn normale Seiten immer auf .html enden, könnte die Regel z.B. so aussehen:

RewriteCond %{REQUEST_URI} \.html$
RewriteRule . - [E=REQ_PAGE:1]

# Host-Domain

RewriteCond %{HTTP_HOST} (([^\.]+?\.)?[^\.]+?)$
RewriteRule . - [E=OWN_DOM:%1]

Hier wird aus dem HTTP_HOST der Domainname ohne Subdomain bzw. vorangestelltem www extrahiert. Die Variable wird als Cookie-Domain verwendet. Man kann die Domain aber auch direkt bei den beiden Cookie-Aktion eintragen. Ich wollte das Ganze nur so weit wie möglich universell gestalten.

# Referrer-Domain

RewriteCond %{HTTP_REFERER} ^https?://(([^\.]+?\.)?([^\.]+?\.)?[^\.]+?)/
RewriteRule . - [E=REF_DOM:%1]

Hier wird aus dem HTTP_REFERER der Domainname der aufrufenden URL extrahiert. Da ich den Referrer-Domainnamen noch bei anderen Rewrite-Regeln benötige, ziehe ich mir den an einer Stelle raus und packe ihn in eine Umgebungsvariabel. Das kann man auch anders machen bzw. mit der nächsten Regel zusammenfassen.

# Referrer Second-Level-Domain (SLD) ist google oder bing

RewriteCond %{ENV:REF_DOM} (google|bing)(\.(com|co))?\.[^\.]+?$ [NC]
RewriteRule . - [E=REQ_SLD:%1]

Nun wird mit der eben extrahierten Referrerdomain geprüft, ob es sich um Google oder z.B. Bing handelt und der Treffer ggf. in einer Umgebungsvariablen abgelegt. Berücksichtigt wird auch, daß es in manchen Ländern noch die Ebene .com und .co vor der eigentlichen Second-Level-Domain (SLD) gibt (z.B. google.co.uk oder google.com.au).

# Bild -> Cookie setzen

RewriteCond %{ENV:REQ_IMG} 1
RewriteCond %{ENV:REQ_SLD} ^(.+?)$
RewriteRule . - [CO=BiSuTrk:%1:.%{ENV:OWN_DOM}]

Nach der ganzen Vorarbeit kommen wir nun endlich zum Kernpunkt, dem Setzen eines Tracking-Cookies. Ich habe ihm den Namen BiSuTrk (Bilder-Suche-Tracking) verpaßt.

Die Bedingungen und Regeln sind einfach erklärt. Haben wir es mit einem existierenden Bild zu tun (REQ_IMG) und kommt der Aufruf von Google oder Bing (REQ_SLD), dann wird ein Cookie mit dem Namen BiSuTrk und dem Wert google/bing für die eigene Domain (OWN_DOM) gesetzt.

Hier findet Ihr die Beschreibung zur Cookie-Funktion im Apache-Rewrite-Modul. Ich verwende nur die ersten drei Parameter Name, Wert und Domain. Interessant ist aber auch noch der nächste Parameter „Lifetime“, der die Lebenszeit des Cookies in Minuten festlegt. Wird er nicht verwendet oder ist 0, dann wird ein Session-Cookie gesetzt. Das heißt, es überlebt nur, solange der Webbrowser nicht geschlossen wurde.

Falls ein Bild von Google oder Bing aufgerufen wurde, sind wir hier fertig. Das Cookie ist gesetzt und wartet im Hintergund auf den ersten Seitenaufruf.

# Normale Seite und Cookie gesetzt -> Variable setzen und Cookie löschen

RewriteCond %{ENV:REQ_PAGE} 1
RewriteCond %{ENV:REQ_SLD} ^(.+?)$
RewriteCond %{HTTP_COOKIE} BiSuTrk=([^;]+?)(;|$) [NC]
RewriteRule . - [E=BISU_TRK:%1,CO=BiSuTrk:INVALID:.%{ENV:OWN_DOM}:-1]

Der Nutzer hat unser schönes Bild in der Bildersuche gesehen, interessiert sich nun doch für unsere Seite und klickt beherzt auf das Bild oder [Seite besuchen]. Jetzt schlägt die letzte Tracking-Regel zu.

Es ist ein normaler Seitenaufruf (REQ_PAGE) und er kommt von google/bing (REQ_SLD) und das Tracking-Cookie ist gesetzt (HTTP_COOKIE). Yeahhh, dann ist es mit hoher Wahrscheinlichkeit ein Besucher aus der Bildersuche. Das merken wird uns in der Umgebungsvariable BISU_TRK und löschen das Cookie. Wobei man ein Cookie nicht löschen, sondern nur für ungültig erklären kann. Das passiert über eine Verfallszeitpunkt in der Vergangenheit, hier konkret mit -1 Minute.

Ab in die Log-Datei

Da der Referrer uns nicht mehr wie früher die Informationen zur Bildersuche liefert, setzen wird die Trackinginformation einfach in den Referrer ein.

<IfModule mod_headers.c>
RequestHeader merge Referer "bisutrk=%{BISU_TRK}e" env=BISU_TRK
</IfModule>

Mit dem Headers-Modul des Apache-Webservers kann man auch die Request-Header verändern, also das was eigentlich vom Browser des Nutzers gesendet wird. Abhängig davon, ob die Umgebungsvariable TRK_VALUE gesetzt ist, wird der Wert dem Referer hinzugefügt und landet so im Server-Logfile.

... "GET /tomaten/ HTTP/1.1" 200 8061 "http://www.google.de, bisutrk=google"

So sieht das dann im Logfile aus. Der Parameter wird mit Komma und Leerzeichen an den vorhandenen Referrer angehängt.

Wie man das nun auswertet, hängt von der verwendeten Logfile-Analyse-Software ab. Bei meinen selbst geschriebenen PHP-Skripten war das natürlich kein Problem.

Ab zu Google-Analytics

Da ich selbst kein Google-Analytics (GA) verwende, kann ich das nicht testen, theoretisch sollte es aber wie beschrieben funktionieren.

Man kann in GA benutzerdefinierte Parameter verwenden. Es gibt Dimensions und Metrics. Der normale Funktionsaufruf zum Tracking eines Seitenaufrufs sieht so aus.

ga( 'send', 'pageview' );

Mit einer benutzerdefinierten Dimension könnte das dann so aussehen:

ga( 'send', 'pageview', { 'dimension15': 'google' } );

Wie man das nun auf der Webseite ausgibt, hängt vom CMS ab. Als einfaches Beispiel habe ich das hier mal als PHP-Codeschnipsel implementiert:

$bisu_trk = trim( $_SERVER['BISU_TRK'] );
if( $bisu_trk )
	echo "ga( 'send', 'pageview', { 'dimension15': '$bisu_trk' } );";
else
	echo "ga( 'send', 'pageview' );";

Es wird die in der .htaccess-Datei gesetzte Variable (BISU_TRK) geprüft. Falls diese nicht leer ist, wir der ensprecheden Wert im der Dimension verwendet.

Fehler- und weitere Betrachtung

Ganz hundertprozentig sicher wird dieses Tracking der Bildersuche nicht funktionieren. Wie oben schon erwähnt, setzt es auf Cookies und falls der Nutzer keine Cookies erlaubt, guck man in die Röhre.

Außerdem ist nicht garantiert, daß der Nutzer tatsächlich mit dem Klick aus der Bildersuche kam. Vorstellbar ist, daß er zwar zunächst in der Bildersuche etwas gesucht hat, dann aber zur normalen Suche gewechselt ist und von dort Eure Seite besucht hat.

Selbst wenn der Nutzer Euer Bild in der Bildersuche gar nicht gesehen hat, wird möglicherweise trotzdem das Trackingcookie gesetzt. Das liegt daran, daß Google im Hintergrund bereits das vorhergehende und das nachfolgende Bild lädt.

Google-Bildersuche: Neues Layout (Preload)

Google-Bildersuche: Neues Layout (Preload)

Man könnte die Lebenszeit des Cookies verkürzen.

RewriteCond %{ENV:REQ_IMG} 1
RewriteCond %{ENV:REQ_SLD} ^(.+?)$
RewriteRule . - [CO=BiSuTrk:%1:.%{ENV:OWN_DOM}:5]

Falls der Nutzer nicht innerhalb von 5 Minuten, nachdem er das Bild gesehen hat, auf die Seite klickt, dann kommt er höchst wahrscheinlich doch nicht über die Bildersuche.

Für das Tracking in der Server-Logdatei benötigt man den ganzen Zauber mit Cookies eigentlich gar nicht, denn da steht ja sowohl der Aufruf des Bildes als auch der Seite drin. Die Frage ist nur, ob und wie man diese Einträge in der Logfileanalyse-Software zusammenbringen kann.

Ende im Gelände?

Auch in der neuen Bildersuche gibt es durchaus Möglichkeiten, die Nutzer der Bildersuche zu erkennen. Mit ein paar technischen „Tricks“ ist das Tracking im Logfile und in Google-Analytics möglich.

Falls jemand von Euch diese Trackingtechniken nutzt, würden mich Euere Erfahrungen damit, besonders bezüglich Google-Analytics, interessieren. Schreibt es in die Kommentare! :-)

Keine Kommentare »