Google Analytics – eigene Conversions rausfiltern (dyn. IP)

Beitrag von **Schweiss-weg** » 30.03.2010, 16:19

Hallo! Jemand eine Idee, wie ich bei Google Analytics unsere eigenen Zugriffe und Conversions ausfiltern kann?
Wir haben eine unserer dynamischen IP und pflegen selbst (und das verursacht das Conversion-Problem) Test- und Telefonbestellungen ein.

Vielleicht über eine Art Firefox Cookie-Blocker oder was man sonst noch so blocken kann?

von **Anzeige von ABAKUS** »

Beitrag von **TBT** » 30.03.2010, 20:46

Einen lokalen Proxy einrichten, der der Zugriff auf Google Analytics Skripte verbietet?
klappt hier wunderbar mit einer deny Liste für Squid

Beitrag von **mgutt** » 30.03.2010, 21:59

Setz Dir ein Cookie und bau ein "If Cookie vorhanden" um den Google Code, damit er bei Euren Mitarbeitern nicht ausgeführt wird.

von **Anzeige von ABAKUS** »

SEO Consulting bei ABAKUS Internet Marketing
Erfahrung seit 2002

persönliche Betreuung
individuelle Beratung
kompetente Umsetzung

Jetzt anfragen: 0511 / 300325-0.

Beitrag von **mic_jan** » 30.03.2010, 22:02

Da muss man keinen eigenen Cookie kochen. Das geht auch so mit Analytics. Den Cookie kann man mit GA selber setzen. Indem man einfach eine eigene Gruppe für die eigenen Aufrufe beim GA-Code übergibt.

Dafür muss dann eine Seite aufgerufen werden, wo der entsprechende GA-Cookie gesetzt wird.

Und zum Schluss macht man dann noch ein Profil in GA wo alles getracked wird ausser diese eine Gruppe.

Afaik steht das auch in der GA Hilfe drin.

Gruß,

Michael

Beitrag von **Schweiss-weg** » 31.03.2010, 10:37

Das ist so gemeint, oder?
https://www.google.com/support/analytic ... swer=55481

Beitrag von **Schweiss-weg** » 31.03.2010, 12:20

… aber wie genau heisst der Cookie der gesetzt wird und wie lange ist er haltbar?
Und wie kann ich generell am besten überpüfen, ob er korrekt gesetzt ist?

Beitrag von **mgutt** » 01.04.2010, 08:51

Setz Dir einfach ein Cookie und an Hand dessen entscheidest Du serverseitig, ob Analytics ausgeliefert wird. Zusätzlich kannst Du irgendwo auf der Seite "Mitarbeiter-Modus" oder ähnliches ausgeben.

Beitrag von **Schweiss-weg** » 01.04.2010, 11:20

Wenn ich nach der von Google empfohlenen Methode vorgehe habe ich aber das Problem den Cookie in allen Browsern zu identifizieren!

Konkret und nach Browser ausgewertet bedeutet dies folgendes:
Opera: __utmv: 121607050.test_value
Netscape: __utmv: 121607050.test_value
Safari: kein passender Cookie auffindbar
Firefox: kein passender Cookie auffindbar

Ich verstehe das nicht ganz

Beitrag von **Schweiss-weg** » 09.04.2010, 15:20

Jetzt kommts noch besser. Verstehe nun gar nichts mehr

Ich habe mir mal die Freude gemacht, per "Erweiterte Segmente" alle eigenen Zugriffe herauszufiltern. Dabei habe ich folgende Kriterien einbezogen:

die über die für uns in Frage kommenden Städte mit Einwahlknoten

das von uns verwendete Betriebssystem (Mac OS-X)

den von uns benutzen Zugangsprovider

All diese Punkte zusammen genommen sollten eingentlich unsere eigenen Zugriffe relativ klar abgrenzen können, insbesondere, da wir Mac OS-X benutzen.

Betrachte ich aber einen Zeitraum der letzten 5 Jahre haben wir bis auf kurze (aber deutliche) "Zugriffsinseln" immerzu NULL-Zugriffe generiert, was aber im Grunde nicht sein kann. So fallen diese 0-Zugriffsphasen auch in Zeitbereiche im Jahr 2009, in denen wir noch gar nicht darüber nachgedacht haben unsere eigenen Zugriffe heraus zu filtern

Ich möchte Euch mal bitte ein vergleichbares Segment auszutesten, wenn Eure Zugangskonstellation nachvollziehbare Selektionskriterien zulässt (seltener Browser, seltenes OS, ungewöhnlich hohe Bildschirmauflösung, o.ä.)
und mich über das Ergebnis zu informieren.

Beitrag von **mgutt** » 10.04.2010, 09:08

Beim Einwahlknoten wirds schon hapern, weil die Geo-Datenbanken keineswegs verlässlich sind. Hast Du Telekom als Provider? Der ist halbwegs zuverlässig in den Geo-Datenbanken.

Beitrag von **Rem** » 11.04.2010, 21:55

Betrachte ich aber einen Zeitraum der letzten 5 Jahre haben wir bis auf kurze (aber deutliche) "Zugriffsinseln" immerzu NULL-Zugriffe generiert, was aber im Grunde nicht sein kann. So fallen diese 0-Zugriffsphasen auch in Zeitbereiche im Jahr 2009, in denen wir noch gar nicht darüber nachgedacht haben unsere eigenen Zugriffe heraus zu filtern

Wer garantiert Dir überhaupt, dass Google über fünf Jahre hinweg Daten speichert?

Siehe:
https://www.google.com/support/googlean ... swer=66084

Also bei meiner Seite sind teilweise nur noch für den letzten Monat vollständige Daten vorhanden...

Beitrag von **Schweiss-weg** » 12.04.2010, 09:49

Nein, wir sind bei einem anderen Provider.
Die Daten scheinen schon vorhanden, denn die von mir beschriebenen "Zugriffsinseln" liegen in der Mitte des Jahres 2009. Würde das Ganze schon mal gern verstehen oder nachvollziehen können

Beitrag von **Schweiss-weg** » 16.04.2010, 14:00

Noch jemand eine Idee, wie man die Filterung am besten (und vor allem eindeutigsten) überprüfen kann?

Beitrag von **marcoru** » 16.04.2010, 17:11

Schweiss-weg hat geschrieben:… aber wie genau heisst der Cookie der gesetzt wird und wie lange ist er haltbar?
Und wie kann ich generell am besten überpüfen, ob er korrekt gesetzt ist?

Ich habe den Cookie gesetzt anscheinend funktioniert es aber nicht da ich Zugriffe verzeichnen kann die eindeutig von mir stammen.

Dazu auch die Vermutung über die Haltbarkeit des cookies in der snow leopard anzeige wird er angezeigt als
_umtv gültigkeit 15.04.10 also gestern.... contens 58509737.test_value

Habe im Grunde genau google's anleitung befolgt
hier
https://www.google.com/support/analytic ... swer=55481

Beitrag von **mgutt** » 17.04.2010, 12:16

Mensch Kinners ^^

Ladet Euch diese Seite hoch:

Code: Alles auswählen

<html>
<head>
<title>Mitarbeiter-Cookie</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="robots" content="noindex, nofollow" />
<script type="text/javascript">
// set cookie &#40;name, value, days&#41;
function sc&#40;n, v, d&#41; &#123;
	// expires
	var e = '';
	if &#40;d&#41; &#123;
		var t = new Date&#40;&#41;;
		t.setTime&#40;t.getTime&#40;&#41;+&#40;d * 24 * 60 * 60 * 1000&#41;&#41;;
		e = '; expires=' + t.toGMTString&#40;&#41;;
	&#125;
	document.cookie = n + '=' + v + e + '; path=/';
&#125;;
// delete cookie &#40;name&#41;
function dc&#40;n&#41; &#123;
	sc&#40;n, '', -1&#41;;
&#125;;
</script>
</head>
<body>

<h3>Mitarbeiter-Cookie</h3>

<input type="button" onclick="sc&#40;'StffC', 1, 360 * 5&#41;;window.setTimeout&#40;'location.replace&#40;location.pathname&#41;;', 300&#41;;" value="Cookie setzen!" />
<input type="button" onclick="dc&#40;'StffC'&#41;;window.setTimeout&#40;'location.replace&#40;location.pathname&#41;;', 300&#41;;" value="Cookie entfernen!" />

<p>
	<script type="text/javascript">
	if &#40;document.cookie.indexOf&#40;'StffC'&#41; == -1&#41; &#123;
		document.write&#40;'Das Mitarbeiter-Cookie ist <u>nicht</u> vorhanden!'&#41;;
	&#125;
	else &#123;
		document.write&#40;'Das Mitarbeiter-Cookie ist gesetzt!'&#41;;
	&#125;
	</script>
</p>

</body>
</html>

Nun geht jeder Mitarbeiter hin und setzt sich das Cookie (hält 5 Jahre, sofern die Cookies nicht gelöscht werden).

Dann baut das in Euren Google-Analytics Code:

Code: Alles auswählen

	pageTracker._setCustomVar&#40;
		1,
		"Besuchergruppe",
		&#40;document.cookie.indexOf&#40;'StffC'&#41; == -1&#41; ? "Besucher" &#58; "Mitarbeiter",
		2
	&#41;;
	pageTracker._trackPageview&#40;&#41;;

Dadurch wird Euer Bericht um die entsprechende Besuchergruppe erweitert. Alternativ könnte man die Bedingung auch um den gesamten Tracking-Code bauen, falls man Mitarbeiter überhaupt nicht tracken möchte.

Wer Analytics als Async-Script nutzt, muss es entsprechend anpassen. Hier mehr Infos dazu:
https://stackoverflow.com/questions/225 ... -analytics (in den kleinen Kommentaren ist ein Link).