Google Analytics Echtzeit-Sandbox-Umgebung

8

Ich suche nach einer Möglichkeit, eine Google Analytics Sandbox-Umgebung einzurichten, die es mir ermöglicht um meinen benutzerdefinierten JS-Code in Echtzeit zu testen.

Meine App wird benutzerdefinierte Variablen für die erweiterte Segmentierung verwenden, und ich möchte mehrere Szenarien schnell testen, anstatt einen Dummy-GA-Account einzurichten und einen ganzen Tag zu warten, um den Test zu bestätigen.

Danke

    
Salman Paracha 24.07.2010, 18:02
quelle

1 Antwort

17

Große Frage.

Bei GA erfolgen Serverupdates alle vier Stunden, und nach jedem sechsten Update wird der gesamte Satz neu berechnet, was eine 24-Stunden-Verzögerung von der Codeänderung zu einer zuverlässigen Rückmeldung bedeutet. Diese Verzögerung gilt auch für die meisten Anpassungen im GA-Browser (z. B. "benutzerdefinierte Filter").

Wenn Sie also GA als Ihr Web-Metriken-System verwenden und erwarten, dass Sie sich tatsächlich auf diese Daten verlassen, ist ein Test-Rig notwendig.

Für mich ist es nützlich, Testsysteme für die clientseitige Analytik mit zwei Rubriken zu gruppieren: (i) vollständige, in sich geschlossene (geschlossene) Systeme; oder (ii) einfachere automatische Datenübernahme aus dem Produktionssystem (mit "Produktionssystem" hier meine ich GA-System, nicht die Seite, deren Seiten der GA-Code verfolgt).

Fügen Sie für Letzteres diese Zeile zu jeder Seite Ihrer Website hinzu, die den GA-Tracking-Code enthält, direkt unter "__trackPageview ()":

%Vor%

Diese Zeile bewirkt, dass eine Kopie jeder Transaktionszeile im Aktivitätsprotokoll Ihres Servers protokolliert wird. Im Wesentlichen erhalten Sie die von GA erfassten Daten in Echtzeit. Dies ist alles, was Sie tun müssen, um die Daten zu erfassen. um es zu analysieren, können Sie zum Beispiel einen der exzellenten Open-Source-Web-Log-Analysatoren wie AWStats verwenden, oder rollen Sie Ihre eigenen.

Dies ist einfach und zuverlässig - aber es kann Ihnen nur sagen (in Echtzeit): "Funktioniert der Analytics-Code, den ich gerade auf den Seiten meines Produktionsservers implementiert habe, tatsächlich?"

Normalerweise ist das nicht gut genug - Sie würden lieber wissen, ob Ihr Code funktioniert bevor er auf Ihrem Produktionsserver ist. Dazu müssen Sie die Produktionsumgebung simulieren und eine Möglichkeit finden, in Echtzeit auf die von GA gesammelten Daten zuzugreifen.

Diese Art von Prüfstand ist etwas komplizierter, aber nicht schwierig.

In der Summe erfordert es diese Schritte:

  1. host / serviere die ga.js und die Tracking Pixel lokal;

  2. protokollieren Sie die __utm.gif-Anfragen (in der GA Datenfluss, jede Anfrage entspricht einem geloggten Transaktion); und

  3. parse die Header in einige bequeme lesbare Form.

Wenn Sie mehr Details als das wünschen (dh eine Schritt-für-Schritt-Implementierung), hier ist es:

Ich. Hosting / Serving des GA-Skripts (& Automatisierung von Updates

Um dies zu tun, können Sie ein kleines Shell-Skript wie dieses erstellen, um die neueste ga.js-Version in Ihr lokales Verzeichnis zu laden (ersetzt die vorhandene Version, die dort gefunden wird).

%Vor%

(Danke an AskApache.com , das das Original zur Verfügung gestellt hat Motivations- und Konfigurationsdetails, um dies in einem Produktionskontext zu tun.)

II. Erstellen Sie die Datei "__utm.gif"

Dies ist nur ein transparentes 1x1-Pixel-GIF-Bild, das Sie in das Site-Verzeichnis stellen (egal wo, es muss nur mit dem auf Ihren Seiten angegebenen Ort übereinstimmen)

III. Protokollieren Sie die __utm.gif-Anforderungen

Für ein Testprotokoll, in dem Sie die Quelle der clientseitigen Aktivität sind (z. B. möchten Sie die browserübergreifende Genauigkeit eines Ereignisverfolgungscodes überprüfen, den Sie einer Seite auf Ihrer Site hinzugefügt haben, also Sie Automatisieren Sie 5000 Klicks auf die Schaltfläche, die Sie gerade verdrahtet haben und bedienen Sie die Seite von Ihrem für diesen Zweck eingerichteten Dev-Server. Es ist wahrscheinlich am einfachsten, nur die Anforderungsheader zu protokollieren, da in diesen Kopfzeilen das GA-Skript enthalten ist weist den Client an, verschiedene Daten vom DOM, von der Adressleiste (URL) und von früheren http-Headern zu sammeln und sie an eine Anforderung für eine Ressource auf dem GA-Server (__utm.gif, die nur ein transparentes 1x1-Pixel ist) anzufügen ).

Für diesen Protokolltyp verwende ich das Firefox-Addon LiveHTTPHeaders . Sie installieren es wie jedes andere Firefox-Addon, ein paar Mausklicks sind alles. Als nächstes öffne es und klicke auf den "Generator" -Reiter. In diesem Fenster können Sie die tatsächlichen Anfragen in Echtzeit sehen. Am unteren Rand des Fensters befindet sich eine Schaltfläche zum Speichern, um das Protokoll zu speichern. Ich finde es einfacher, LiveHTTPHeaders so zu konfigurieren, dass nur die __utm.gif-Anfragen protokolliert werden. Um dies zu tun, klicken Sie einfach auf die Registerkarte "Bearbeiten" und erstellen Sie einen Siimple-Filter, um alles außer diesen bestimmten Gif-Bildern auszuschließen (mit den Kontrollkästchen rechts und dem großen Textfeld rechts).

Für andere Arten von Testprotokollen müssen Sie mit Ihren Serveraktivitätsprotokollen arbeiten. In diesem Fall fügen Sie einfach diese Zeile zu jeder Seite Ihrer Site direkt unter __trackPageview () hinzu:

%Vor%

IV. Analysiere diese protokollierten Anfragen, damit du sie lesen kannst

Nun enthält Ihr Protokoll also einzelne Übertragungslinien, von denen jede eine Zeichenfolge ist, die an eine HTTP-Anforderung für das GA-Verfolgungspixel angehängt wird. Diese Zeichenfolge ist nur eine Verkettung von Schlüssel-Wert-Paaren, jeder Schlüssel beginnt mit den Buchstaben "utm" (wahrscheinlich für "urchin tracker").Jeder dieser Parameter entspricht einer Variablen, die Sie im GA-Dashboard sehen (hier eine vollständige Liste) und Beschreibung von ihnen). Das ist alles, was Sie wissen müssen, um einen Parser zu erstellen. Ausführlicher:

Zunächst ist hier eine bereinigte __ utm.gif Anfrage (die Einträge in Ihrem LiveHTTPHeaders-Protokoll):

%Vor%

Dies ist mein Parser (in Python):

%Vor%

Das Ergebnis sieht folgendermaßen aus:

%Vor%

Um dies nicht länger zu machen, habe ich den Wert der Cookies weggelassen. Sie benötigen offensichtlich einen separaten Parsing-Schritt, obwohl es praktisch identisch mit dem Schritt ist, den ich gerade gezeigt habe. Auch hier stellt jede Anfrage eine einzelne Transaktion dar, sodass Sie sie nach Bedarf speichern können.

    
doug 24.07.2010, 20:43
quelle

Tags und Links