Google Analytics kennt vier Traffic Quellen: Suchmaschine, Direkt, Verweisende Seite (Referral Site) und Kampagne … aber welche Benutzer fallen wo rein?

Kampagnen Tracking

Alle Links bzw. Benutzer die explizit mit Tracking Variablen ausgezeichnet wurden fallen unter Kampagnen, dazu zählt aber nicht Google AdWords, dieser Traffic wird zwar als Kampagne getrackt, hat aber eine Ausnahmestellung und wird im Analytics als “Bezahlter Suchmaschinen Traffic” angezeigt.

Suchmaschinen Traffic

Jetzt wirds interessant … was ist eigentlich eine Suchmaschine? Wer hat das definiert? Kann man das ändern?

Tja, definiert hat das Google und die Liste kann man auf Google Code einsehen. Auf dieser Liste stehen 40 Seiten, darunter alte Bekannten wie AOL, Yahoo und natürlich alle Google Suchseiten, aber auch sehr spezielle Suchmaschinen von denen man noch nie was gehört hat. Nach welchen Regeln diese Liste erstellt wurde konnte ich nicht herausfinden.

Die gute Nachricht ist das man diese Einteilung selber ändern kann. Mit den pageTracker Methoden _addOrganic() und _addIgnoreRef() kann man explizit Suchmaschinen hinzufügen oder ignorieren. Mit _clearOrganic() kann man sogar die ganze Suchmaschinen-Liste entfernen.

Verweisende Websites

Alles was keine Kampagne ist und keine Suchmaschine aber einen Referrer-Header hat, ist eine verweisende Website. Da findet man oft auch Google drin, das sind Benutzer die aus Gmail oder anderen Google Diensten (ausser der Suche) auf die Seite kommen. Zum Beispiel wenn man Newsletter versendet oder ein Google Doc mit Link veröffentlich hat.

Direkter Traffic

Tja, alles was jetzt noch übrig bleibt, also alles ohne Referrer-Header fällt unter Direkt Traffic … ganz einfach :)

Mehr über Traffic Sources, Kampagnen-Tracking und Url-Builder Tool auf Google Code.

Weitere Artikel zu Analytics findet ihr unter: http://bohuco.net/blog/tag/inside-analytics-tracking/

Google Analytics ist ein wahres Monster wenns um die Anzahl der Cookies geht, aber wozu sind alle diese Cookies nötig und was kann man eigentlich selber für Einstellungen vornehmen …

Unique User Tracking

Das __utma Cookie identifiziert einen Client bzw. Benutzer, dieses Cookie läuft erst nach zwei Jahren ab und diese Zeit kann auch nicht geändert werden.

Session Tracking

Mit __utmb, __utmc kann Google einzelne User-Sessions messen, also Visits von ein und demselben Benutzer. Die Cookies laufen nach 30 Minuten ab oder wenn der Browser geschlossen wird. Wenn eine Session länger oder kürzer dauern soll kann man das mit der pageTracker Methode _setSessionCookieTimeout ändern.

pageTracker._setSessionCookieTimeout(1800000); // Millisekunden

Traffic Source Tracking

Im Cookie __utmz steht drin woher der Benutzer gekommen ist, also die Traffic Source bzw. Referral Site. Dieses Cookie gilt 6 Monate, wem das zu lange ist weil die Conversions viel schneller passieren kann das mit der Methode _setCampaignCookieTimeout() ändern.

pageTracker._setCampaignCookieTimeout(15768000000); //Millisekunden

User Var Tracking

Wenn dem pageTracker Daten mit _setVar() übergiben werden dann findet diese Daten im Cookie __utmv.

Weitere Infos über die Analytics Cookies, das pageTracker API und Campaign Tracking mit Analytics.

Nächstes Mal in Inside Analytics Tracking: Quellen Who is Who – Suchmaschine vs. Verweisende Seite. Weitere Artikel zu Analytics findet ihr unter: http://bohuco.net/blog/tag/inside-analytics-tracking/

Google hat jetzt das angekündigte Multiple Sign-In aktiviert. Endlich kann man mit unterschiedlichen Benutzern auf verschiedenen Google Diensten angemeldet sein ohne das man mehrere Browser geöffnet haben muß. Multi Sign-In funktioniert derzeit nur mit Gmail, Google Docs, Google Reader, Google Sites, Google Calendar und Google Code, weitere Dienste können folgen.

Das neue Feature muss auf der Account-Seite aktiviert werden und ist noch nicht überall aktiv.

Multi Sign-in available

WebSockets are the new cool boys in town, but the specs are in a very early state and so it’s hard to keep up to date with the different browser implementations …

Current stable browser-versions, like Chrome 5, only supports the old specification (aka -75), Firefox 3.6 don’t know the WebSockets object at all. The new Beta-/Dev-versions of Firefox and Chrome now supports the new spec-version -76. There is one major change in the new draft, the handshake is much more complicated now …

The Browsers now sends some security strings and the WebSocket server have to implement a handling for this new headers (Sec-WebSocket-Key1 and Sec-WebSocket-Key2), and must return a security-hash:

To prove that the handshake was received, the server has to take three pieces of information and combine them to form a response. The first two pieces of information come from the |Sec-WebSocket-Key1| and |Sec-WebSocket-Key2| fields in the client handshake … The third piece of information is given after the fields, in the last eight bytes of the handshake, expressed here as they would be seen if interpreted as ASCII

Here is the PHP Method for handling the new security hashes:

    private function getHandshakeSecurityKey($key1, $key2, $code) {
        return md5(
            pack('N', $this->handleSecurityKey($key1)).
            pack('N', $this->handleSecurityKey($key2)).
            $code,
            true
        );
    }
 
    private function handleSecurityKey($key) {
    	preg_match_all('/[0-9]/', $key, $number);
    	preg_match_all('/ /', $key, $space);
    	if ($number && $space) {
    		return implode('', $number[0]) / count($space[0]);
    	}
    	return '';
    }

For the full source code of a PHP5 WebSockets server view the source of my WebSocketServer.php Class. If you want to see it in action, try my WebSockets example with Firefox 4 Beta or Chrome/Safari 5.

The original code comes from Web Reflection Blog by Andrea Giammarchi.

HTML5 WebSockets makes it possible to open a persistent connection to a server within a web-browser via javascript.

UPDATE: Mastering the new Spec-76 WebSockets handshake with PHP.

Websockets works already in the latest Webkit-browsers like Safari 5 and Chrome 5. Firefox 4 Beta 1 knows the Websocket-Object but it can’t open the connection :(

My Websocket test script sends the current mouse position via socket connection to the server and then receives all positions of all current open sockets and prints them to the browser-window. In other words, you can see the mouse cursors of the other users on the page.

var socket;
 
function init() {
	var host = "ws://84.38.67.247:8080/dev/websocket/server.php";
	try {
		socket = new WebSocket(host);
		socket.onopen = function(msg){ };
		socket.onmessage = function(msg){
			eval('var data = ' + msg.data + ';');
			for (userId in data) {
				if (data[userId].position) {
					var pos = data[userId].position.split(',');
					var color = data[userId].color;
					render(userId, pos[0], pos[1], color);
				}
			}
			dump(data);
		};
		socket.onclose = function(msg){ };
	} catch(ex){ console.log(ex); }
 
	$('body').bind('mousemove', function(evt){
		send(evt.clientX, evt.clientY);
	});
}
 
function render(u, x, y, c) {
	if ($('#'+u).length == 0) {
		$('
 
 
').appendTo('body');
	}
	$('#'+u).css('left', x+'px');
	$('#'+u).css('top', y+'px');
	$('#'+u).css('background', c);
}
 
function send(x,y) {
	var msg = x + ',' + y;
	socket.send(msg);
}

On the server side i use a PHP5 script. I have written my own server-class but it’s based on the work of the phpwebsocket project. The server.php instantiate the WebSocketServer object and contains the callback function.

http://bohuco.net/dev/websocket/

Source Codes:
WebSocketServer.php
server.php

Ein Typ namens David Galbraith hat im CERN nach dem Geburtsort des Webs gesucht und ihn gefunden (zumindest fast). Ein unscheinbarer Gang in einem unscheinbaren Gebäude mit einer kleinen Tafel an der Wand, dort soll Berners Lee das WWW erfunden haben.

Auf Oobject hat Galbraith einige Fotos gepostet, ausserdem hat er sich via E-Mail den genauen Geburtsort nochmal von Tim Berners Lee bestätigen lassen. Das Mail-Interview kann man im Blog von David nachlesen. Anscheinend hängt die Tafel im falschen Gebäude, denn Berners Lee will den Prototypen im Gebäude 31 und nicht im Gebäude 2 entwickelt haben :) … aber auch von dort gibt es einige Bilder im Web.

via Gizmodo

Der SproutCore Erfinder Charles Jolley verlässt Apple und gründet ein Unternehmen das sich mit der Entwicklung neuer Rich-Web Applikationen auf HTML5-basis beschäftigen wird.

Jolley war unter anderem für die MobileMe Plattform zuständig und hat für Apple Javascript Frameworks entwickelt. Die neue Firma wird Strobe Digital Publishing heißen und Jolley beschreib sie so:

Strobe Digital Publishing is a better way to put content onto the iPad and other mobile touch devices. Based on a blend of HTML5 and native technology, Strobe content applications offer a great native-style reading experience with the ability to deep link and share content to drive traffic.

SproutCore ist ein HTML/Javascript Framework das diverse Komponenten für Rich-Web Applikationen zur Verfügung stellt – Demo.

via cnet, maclife.de

Die erste Beta-Version von Firefox 4.0 bringt einige neue geile Technologien für Web-Entwickler.  Via WebM und HTML5 können jetzt HD-Videos ohne zusätzliches Plugin im Browser angezeigt werden. Der neue HTML5 Parser wurde schneller gemacht und kann jetzt Inline-SVG und MathML.

Mit Websockets lassen sich persistente Verbindungen zum Browser öffnen, das geschieht mit einem einfachen Javascript API. Im Chrome sind die Websockets auch schon implementiert, nur leider ist der Standard noch nicht ganz fertig darum wirds wohl auch noch etwas dauern bis die Funktion endgültig freigeschaltet wird.

Mit IndexedDB kann via Javascript eine lokale SQL Browser-Datenbank verwendet werden. Mit typischen SQL Statements können dann beim User lokal Daten abgelegt und gelesen werden.

Die Beta ist am 6. Juli erschienen und kann auf mozilla.com heruntergeladen werden.

Mozilla Blog

Screen readers are really cool pieces of software, but as a web-developer you should help the screen reader to handle your webpages better for the blind users. Besides you add more text content to your pages, and search engines loves text content.

Here some really simple tricks:

<map title=”My favorite links”>
The <map> tag is not only for imagemaps, you should use it to group link-lists. In the title-attribute you have to write a description for the elements within the map. Screen readers can now readout the description, so blind people can decide if they want hear the list.

WCAG Techniques – Link Blocks

<abbr title=”What the fuck”>WTF</abbr>
With the <abbr> tag you can markup abbreviations for screen readers, maybe search engines can use this additional data too.

WCAG Techniques – Abbreviations

<hr />
Use the oldschool horizontal ruler for your document structure, you can style it with css or hide it from non-blind users. Screen readers use it to tell users if there is a new content block.

Skip Links
With a “Skip to content”-Link, blind users can fast jump to the main content section. If you don’t provide such links screen readers must read always the main/sub-menu of your pages. You can hide the skip-links with css.

accesskey=”9″
Provide access key attribute, so blind users can faster navigate through your pages. You should add an access key to every main-menu point.

That’s the solution that worked for me …

# remove multiple slashes
RewriteCond %{REQUEST_URI} ^(.*)//(.*)$ [NC]
RewriteRule . %1/%2 [R=301,L]

# … within URL-path
RewriteRule ^(([^/]+/)*)/+(.*)$ http://%{HTTP_HOST}/$1$3 [R=301,L]

# … before URL-path
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ //+([^\ ]*)
RewriteRule .* http://%{HTTP_HOST}/%1 [R=301,L]