So richten Sie sich mit Nginx Analytics und A / B-Tests an Ihre Benutzer

Einführung

Nginx ist ein leistungsstarker Proxy- und Webserver, der von einigen der größten Websites für die Verarbeitung von Clientverbindungen und die Bereitstellung von Inhalten verwendet wird. Während die meisten Benutzer mit den Grundfunktionen von Nginx vertraut sind, gibt es andere Funktionen, die bei typischer Verwendung möglicherweise nicht ohne weiteres erkennbar sind.

In diesem Handbuch werden einige Funktionen erläutert, mit denen Sie neue Inhalte testen und Statistiken über Ihre Benutzer erstellen können. Diese können für die Entwicklung von Inhalten, für einfache A / B-Tests und zum Erkennen des Verhaltens verschiedener Benutzergruppen, die Ihre Websites häufig besuchen, äußerst nützlich sein. Nginx kann diese Funktionen problemlos in den Webserver selbst integrieren.

Einfaches A / B-Testen mit dem Split-Clients-Modul

Zunächst zeigen wir Ihnen, wie Sie einige grundlegende A / B-Tests über Nginx selbst konfigurieren. Wir können dies mit einem Standard-HTTP-Modul namens "+ http_split_clients +" tun. Sofern dies während einer benutzerdefinierten Kompilierung nicht ausdrücklich deaktiviert wird, sollte dies in jeder Standard-Nginx-Installation verfügbar sein.

Das Modul bietet eine einzige Direktive mit dem Namen "+ split_clients ", die Verbindungsanforderungen auf der Grundlage der konfigurierten Anforderungen in zwei oder mehr Kategorien aufteilt. Diese Direktive wird im Kontext " http +" außerhalb von Serverblöcken definiert. Es gibt den Wert an, auf den in jeder Verbindung geprüft werden soll, und erstellt eine Variable, in der die Ergebnisse gespeichert werden.

Die grundlegende Syntax der Direktive sieht ungefähr so aus:

http {

   . . .

   split_clients "" $ {
       %        ;
       %        ;
   }

}

Die Direktive interpoliert den Wert der ersten übergebenen Variablen und hasht das Ergebnis. Der gleiche Wert erzeugt immer den gleichen Hash, wodurch konsistente Ergebnisse erzielt werden. Die zu überprüfende Variable muss bei der Auswertung einen String erzeugen.

Die Zeilen im Block "+ split_clients " stellen verschiedene "Buckets" oder Alternativen dar, die durch den Prozentsatz definiert sind, den sie vom verfügbaren Hash-Speicherplatz verbrauchen sollen. Dadurch werden Hash-Bereiche erstellt, die mit einer bestimmten Anzahl von Hashes übereinstimmen, die durch den angegebenen Prozentsatz bestimmt werden. Jede dieser Optionen definiert einen Wert, der festgelegt werden soll, wenn sich der Hash innerhalb des Bereichs dieses Buckets befindet. Die zweite Variable, die während der Definition von " split_clients +" angegeben wurde, wird auf diesen Wert gesetzt.

Dies ist bei Betrachtung eines Beispiels viel einfacher zu verstehen. Schauen Sie sich den folgenden Block an:

split_clients "${remote_addr}" $designtest {
   10%         ".first";
   10%         ".second";
   *           "";
}

Im obigen Beispiel wird der Wert der Verbindung für "+ $ remote_addr +" ausgewertet, der von Nginx auf die IP-Adresse des Clients festgelegt wird. Der Wert der IP-Adresse des Clients wird mithilfe des Hashing-Algorithmus murmurhash2 gehasht. Zu diesem Zeitpunkt prüft Nginx, in welchen Hashbereich der berechnete Hash fällt. Da die von Nginx verwendete murmurhash2-Implementierung 32-Bit verwendet, liegen die Hashes zwischen 0 und 4294967295 (die höchste 32-Bit-Zahl).

Da die erste definierte Gruppe 10% der gesamten Hashes angibt, entspricht dies 0 bis 429496729, dem ersten Zehntel des verfügbaren Bereichs. Werte, die einen Hash innerhalb dieses Bereichs erzeugen, setzen die Variable "+ $ designtest +" auf den Wert ".first".

IP-Adressen mit Hashes von ungefähr 429496730 bis 858993459, dem Hash-Bereich, der durch die nächsten 10% der verfügbaren Hashes dargestellt wird, stimmen mit der zweiten Zeile überein. In diesen Fällen wird die Variable "+ $ designtest +" auf ".second" gesetzt.

Für alle anderen IP-Adress-Hashes (ungefähr von 858993460 bis 4294967295) wird die Variable + $ designtest + auf eine leere Zeichenfolge gesetzt.

So implementieren Sie dies auf einem Server

Dies ermöglicht es uns grundsätzlich, einen bestimmten Prozentsatz der Verbindungen zufällig auf verschiedene Variablenwerte abzubilden. Sobald dies erledigt ist, können wir diese Variable verwenden, um verschiedene Inhalte bereitzustellen.

Zum Beispiel könnten wir einen Server und einen Standortblock hinzufügen, die je nach Wert der Variablen + $ designtest + unterschiedliche Inhalte liefern. Das folgende Beispiel verwendet diese Variable, um zu entscheiden, welche Indexdatei bereitgestellt werden soll:

http {

   . . .

   split_clients "${remote_addr}" $designtest {
       10%     ".first";
       10%     ".second";
       *       "";
   }

   server {
       listen 80;
       server_name localhost;
       root /usr/share/nginx/html;

       index index${designtest}.html;

       location / {
           try_files $uri $uri/ =404;
       }
   }
}

Bei IP-Adressen mit Hashes, die in die erste Gruppe fallen, versucht Nginx, eine Datei mit dem Namen "+ index.first.html " bereitzustellen. Ebenso sucht Nginx für IP-Adressen, die in die zweite Gruppe fallen, nach einer Datei mit dem Namen " index.second.html ". Wenn sich die IP-Adresse in der dritten Gruppe befindet, wird die Variable " $ designtest " auf eine leere Zeichenfolge gesetzt, sodass eine herkömmliche " index.html +" - Datei bereitgestellt wird.

Wenn wir nun die drei Indexdateien in unserem Dokumentenstamm erstellen, werden diese abhängig vom resultierenden Hash ihrer IP-Adresse an verschiedene Benutzer geliefert:

echo "<h1>First Site</h1>" | sudo tee /usr/share/nginx/html/index.first.html
echo "<h1>Second Site</h1>" | sudo tee /usr/share/nginx/html/index.second.html
echo "<h1>Default Site</h1>" | sudo tee /usr/share/nginx/html/index.html

Wenn Sie die obigen Änderungen an Ihrer Nginx-Konfiguration vornehmen und den Webserver neu starten, können Sie dies testen. Wir können überprüfen, ob unsere Konfigurationsdatei keine Syntaxfehler enthält, und dann den Dienst neu starten, indem wir Folgendes eingeben:

sudo nginx -t
sudo service nginx restart

Wenn wir die Site in unserem Browser besuchen, sehen wir eine der drei obigen Dateien. Wahrscheinlich wird es das letzte sein, da es 80% der Site-Besucher bedienen wird. Wenn Sie sehen möchten, wie es für andere Benutzer angezeigt wird, können Sie die Site über einen Proxyserver oder mithilfe einiger Webtools besuchen.

Zum Beispiel kann die Website GeoPeeker verwendet werden, um Ihre Website von verschiedenen Orten auf der ganzen Welt aus anzuzeigen. Wenn Sie Ihren Domain-Namen eingeben, wird möglicherweise mindestens eine Ihrer alternativen Websites angezeigt:

image: https://assets.digitalocean.com/articles/nginx_testing/ab_testing.png [Alternative Site-Indizes]

Eine weitere ähnliche Website ist LocaBrowser, auf der Sie aus verschiedenen Ländern auswählen können. Beachten Sie, dass die Aufteilung der Seiten, die geliefert werden, nicht auf der Geolokalisierung basiert, sondern auf dem Hash der IP-Adresse. Dies bedeutet also nicht, dass alle Besucher aus einem Land dieselbe Datei erhalten.

Das obige Beispiel ist zwar einfach, das Konzept kann jedoch erheblich erweitert werden. Sie können die mit der Direktive "+ split_clients +" festgelegten Variablen verwenden, um Cookies und Benutzer-IDs festzulegen, Header an Backend-Proxys zu übergeben usw. Wenn Sie A / B ausführlicher testen möchten, können Sie die von Ihnen festgelegte Variable verwenden, um den Dokumentenstamm zu bestimmen, der an verschiedene Parteien geliefert wird.

Es ist auch wichtig, sich daran zu erinnern, dass die Prüfung "+ $ {remote_addr} +" nur ein nützliches Beispiel ist. Sie können Hashes basierend auf dem Wert aller Nginx-Variablen erstellen, die in Strings funktionieren. Eine Liste der im Kernmodul enthaltenen Variablen finden Sie unter here, obwohl andere Variablen über andere Module verfügbar sind. Weitere Informationen finden Sie in der Dokumentation.

Tracking-Pixel mit der empty_gif-Direktive einstellen

Ein Weg, wie Administratoren versuchen, die Benutzer zu berücksichtigen, die ihre Site besuchen, besteht darin, Pixel zu verfolgen. Das Verfolgen von Pixeln ist eine günstige Möglichkeit für Administratoren, durch einfaches Protokollieren Daten darüber zu erfassen, welche IP-Adressen zu welcher Zeit welche Seiten besuchen.

Die Art und Weise, wie ein herkömmliches Tracking-Pixel funktioniert, besteht darin, ein winziges transparentes Bild auf der Seite einzubetten. Wenn ein Benutzer die Site besucht, wird das Bild als Teil des Prozesses zum Laden der Seite angefordert. Der Administrator kann diese Anforderungen zusammen mit der IP-Adresse, von der die Anforderung stammt, der Seite, die der Client beim Erstellen der Anforderung geladen hat, usw. in einem separaten Protokoll ablegen. Diese Art von Informationen kann die Grundlage für eine Datenanalyse in Bezug auf die Aktionen der Besucher auf Ihrer Website sein.

Das + empty_gif + Modul bietet diese Funktionalität in Nginx. Während jede Anforderung zum Verfolgen verwendet werden kann, können Sie mit der Direktive "+ empty_gif " eine winzige transparente " .gif +" - Datei bereitstellen, die im Speicher vorhanden ist, um den Zugriff auf die Festplatte zu vermeiden. Dies beschleunigt die Anforderungen für diese Ressource. Die Richtlinie ist in jedem Standortkontext gültig.

In den meisten Fällen wird diese Anweisung in Verbindung mit einer separaten Protokollanweisung verwendet, um die Anforderungen für eine spätere Analyse zu trennen. Zum Beispiel könnte Ihre Konfiguration einen Abschnitt haben, der so aussieht:

. . .

http {

   log_format tracking '[$time_local] : $remote_addr : $remote_user : '
                       '$args : $http_referer : $http_user_agent';

   server {

       . . .


       location = /logme.gif {
           empty_gif;
           access_log /var/log/nginx/tracking.log tracking;
           expires epoch;
       }
   }
}

Hier richten wir ein "+ log_format " im " http +" - Kontext ein, um die Informationen aufzuzeichnen, die wir verfolgen möchten. Dies kann alles sein, was Sie möchten.

Anschließend können wir einen Standortblock einrichten, der mit einer bestimmten "+ .gif " - Anforderung übereinstimmt. Wir verwenden den Modifikator " = ", damit alle Anforderungen für " .gif " schnell und effizient abgeglichen werden, ohne nach besseren Übereinstimmungen an anderer Stelle zu suchen. Sie können einen beliebigen " .gif +" - Namen auswählen.

Im Inneren verwenden wir die Direktive "+ empty_gif ", um das transparente 1x1-Pixel " .gif " aus dem Speicher bereitzustellen. Wir teilen den Anforderungen für diesen Speicherort mit, dass sie in einer separaten Datei in dem zuvor angegebenen Format protokolliert werden. Schließlich setzen wir das Ablaufdatum auf "Epoche", wodurch die Browser angewiesen werden sollen, das " .gif +" nicht zwischenzuspeichern, sodass wir jedes Mal verfolgen können, wenn der Besucher die Seite besucht.

Jetzt können wir ein Bild hinzufügen, das das ausgewählte Bild auf unseren Seiten anfordert. Eine extrem einfache Seite könnte beispielsweise so aussehen:

<html>
   <head>
       <title>Your Site</title>
   </head>
   <body>
       <h1>Normal Content</h1>
       <img src="/logme.gif">
   </body>
</html>

Wenn ein Besucher diese Seite aufruft, wird das Bild "+ / logme.gif " angefordert, wodurch Nginx in unsere Datei " tracking.log " schreibt, in der Details zu der Anforderung enthalten sind. Dies kann zu einem komplexeren System ausgebaut werden, indem Sie Ihr " log_format +" optimieren und Ihre Protokolle mit Textverarbeitungswerkzeugen analysieren.

Inhalte nach Geografie differenzieren

Zuvor haben wir Ihnen gezeigt, wie Sie Nginx so konfigurieren, dass Benutzer für A / B-Tests mit dem Modul + split_clients + automatisch in Gruppen unterteilt werden. Nginx kann Benutzer basierend auf dem Speicherort ihrer IP-Adresse auch automatisch in Gruppen unterteilen.

IP-Adressen werden mithilfe einer Reihe von Tabellen, die bestimmte Anbieter kompilieren, ungefähren Standorten zugeordnet. Sie erhalten diese Informationen hauptsächlich von zahlreichen Registern, die für die Zuweisung von IP-Speicherplatz in verschiedenen geografischen Gebieten verantwortlich sind. Die Informationen, die von der IP-Adresse einer Person abgerufen werden können, sind nur eine Annäherung und sollten als "beste Vermutung" im Gegensatz zu einer äußerst genauen Methode zur Ermittlung der Herkunft des Datenverkehrs verwendet werden.

Erfassen der Standortdatenbanken

Nginx kann diese Daten verwenden, um Clients mithilfe verschiedener Anweisungen zu trennen, die im Modul + ngx_http_geoip_module + enthalten sind. Die Datenbanken mit Zuordnungen von IP-Adressen zu Standorten sind jedoch nicht enthalten, sodass Sie diese separat erwerben müssen.

Unter Ubuntu können Sie die Zuordnungen auf Länderebene abrufen, indem Sie Folgendes eingeben:

sudo apt-get update
sudo apt-get install geoip-database

Eine allgemeinere Methode zum Abrufen der Zuordnungen auf Länderebene ist das Herunterladen der Dateien mit + wget +. Wir können ein Verzeichnis zum Speichern der Datenbank erstellen und dann die Datei herunterladen, indem wir Folgendes eingeben:

sudo mkdir -p /usr/local/share/GeoIP
cd /usr/local/share/GeoIP
sudo wget http://geolite.maxmind.com/download/geoip/database/GeoLiteCountry/GeoIP.dat.gz

Wir müssen die Datei entpacken, indem wir Folgendes eingeben:

sudo gunzip GeoIP.dat.gz

Für die spezifischere Datenbank auf Stadtebene können Sie auch mit + wget + herunterladen:

sudo mkdir -p /usr/local/share/GeoIP
cd /usr/local/share/GeoIP
sudo wget http://geolite.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz

Auch hier müssen wir die Dateien entpacken:

sudo gunzip GeoLiteCity.dat.gz

Konfigurieren von Nginx zur Verwendung von Standortdaten

Nachdem wir die Standortdatenbanken eingerichtet haben, können wir Nginx so konfigurieren, dass die Daten genutzt werden.

Mit den folgenden Anweisungen können wir Nginx mitteilen, wo sich die einzelnen Datenbanken auf der Festplatte befinden. Diese müssen im Kontext "+ http +" in der Nginx-Konfigurationsdatei festgelegt werden:

. . .

http {
   # If you downloaded the country-level data using `apt-get` uncomment and use:
   #geoip_country /usr/share/GeoIP/GeoIP.dat;
   # If you downloaded the country-level data using `wget`, use:
   geoip_country /usr/local/share/GeoIP/GeoIP.dat;
   geoip_city /usr/local/share/GeoIP/GeoLiteCity.dat;

   . . .
}

Sobald der Speicherort festgelegt wurde, können Sie die von Nginx für jede dieser Datenbanken verwendeten Variablen nutzen. Über die Datenbank auf Länderebene haben wir Zugriff auf die folgenden Variablen:

* + $ geoip_country_code + *: Der aus zwei Buchstaben bestehende Ländercode, der zur Darstellung eines Landes verwendet wird. Zum Beispiel "US" für die Vereinigten Staaten oder "RU" für Russland. Diese finden Sie unter here.
* + $ geoip_country_code3 + *: Fast das gleiche wie oben, aber mit der Drei-Buchstaben-Variante. Zum Beispiel "USA" oder "RUS".
* + $ geoip_country_name + *: Der dem Ländercode zugeordnete Name, wie in der verknüpften Liste angezeigt. Zum Beispiel "Neuseeland" für "NZ".

Die Datenbank auf Stadtebene bietet uns eine größere Anzahl von Variablen. Mit dieser Datenbank haben wir Zugriff auf:

* + $ geoip_area_code + *: Ein Vorwahlfeld für US-Telefonnummern. Für genaue Daten sollte man sich nicht darauf verlassen.
* + $ geoip_city_continent_code + *: Ein aus zwei Buchstaben bestehender Kontinentcode.
* + $ geoip_city_country_code + *: Derselbe aus zwei Buchstaben bestehende Ländercode, der von der Datenbank auf Länderebene bereitgestellt wird.
* + $ geoip_city_country_code3 + *: Derselbe dreibuchstabige Ländercode, der von der Datenbank auf Länderebene bereitgestellt wird.
* + $ geoip_city_country_name + *: Derselbe Ländername wie in der Datenbank auf Länderebene.
* + $ geoip_dma_code + *: Die DMA-Region oder der Metro-Code für US-Standorte. Dies finden Sie in der AdWords-API von Google unter here.
* + $ geoip_latitude + *: Eine Schätzung des Breitengrads der Ursprungs-IP.
* + $ geoip_longitude + *: Eine Schätzung der Länge der Ursprungs-IP.
* + $ geoip_region + *: Ein aus zwei Zeichen bestehender Regionscode, der eine politische Region darstellt, z. B. ein Gebiet, ein Bundesstaat, eine Provinz usw.
* + $ geoip_region_name + *: Der vollständige Name, der dem obigen Regionscode zugeordnet ist.
* + $ geoip_city + *: Der mit der Ursprungs-IP verknüpfte Städtename.
* + $ geoip_postal_code + *: Die Postleitzahl des Gebiets, in dem sich die IP befindet.

Auch hier ist es wichtig zu betonen, dass die über diese Variablen verfügbaren Daten bestmöglich geschätzt werden. Dies bietet uns jedoch einige großartige Möglichkeiten, unterschiedliche Inhalte für unterschiedliche Bereiche bereitzustellen.

Häufig verwenden wir eine der oben genannten Variablen mit der Direktive "+ map +", um den Wert einer anderen Variablen bedingt festzulegen. Auf diese Weise können wir eine Variable mit einem Wert erstellen, der davon abhängt, was die Datenbank über den Standort des Kunden aussagt.

Die Direktive + map + sollte auch im Kontext + http + verwendet werden. Beispielsweise können wir unsere Website so konfigurieren, dass sie andere Inhalte anzeigt, wenn der Besucher aus Australien oder Singapur stammt. Der beste Weg, dies zu überprüfen, ist wahrscheinlich einer der zwei- oder dreibuchstabigen Ländercodes, die entweder in der Länder- oder in der Stadtdatenbank enthalten sind.

In diesem Beispiel verwenden wir den "+ $ geoip_country_code ". Der Wert dieser Variablen bestimmt, was wir in der Variablen " $ site_version +" speichern, die wir erstellen. Wir werden dies verwenden, um den Dokumentenstamm zu bestimmen, von dem aus geliefert werden soll:

http {
   # If you downloaded the country-level data using `apt-get` uncomment and use:
   #geoip_country /usr/share/GeoIP/GeoIP.dat;
   # If you downloaded the country-level data using `wget`, use:
   geoip_country /usr/local/share/GeoIP/GeoIP.dat;
   geoip_city    /usr/local/share/GeoIP/GeoLiteCity.dat;

   map $geoip_country_code $site_version {
       default     "";
       AU          "/australia";
       SG          "/singapore";
   }

   . . .
}

Dies setzt den Wert von "+ $ site_version ", einer Variablen, die wir speziell für diesen Zweck erstellen. Wenn der Ländercode des Besuchers angibt, dass er aus Australien stammt (" AU "), setzen wir " $ site_version " auf "/ australia". Wenn der Besucher aus Singapur ("SG") stammt, setzen wir " $ site_version " auf "/ singapore". Wenn der Ländercode einen anderen Wert angibt, setzen wir " $ site_version +" auf eine leere Zeichenfolge.

Auf diese Weise können wir den Dokumentenstamm für unsere Besucher aus bestimmten Ländern ändern. Dies ist eine willkürliche Auswahl, um zu demonstrieren, wie Sie Inhalte basierend auf den Geostandortdaten des Kunden unterscheiden können.

Um das Dokument root zu ändern, müssten wir nur die Direktive + root + im Serverblock so einstellen, dass sie ungefähr so aussieht:

http {
   # If you downloaded the country-level data using `apt-get` uncomment and use:
   #geoip_country /usr/share/GeoIP/GeoIP.dat;
   # If you downloaded the country-level data using `wget`, use:
   geoip_country /usr/local/share/GeoIP/GeoIP.dat;
   geoip_city    /usr/local/share/GeoIP/GeoLiteCity.dat;

   map $geoip_country_code $site_version {
       default     "";
       AU          "/australia";
       SG          "/singapore";
   }

   . . .

   server {
       . . .



       . . .

   }
}

Wenn der Benutzer aus Australien stammt, wird der Dokumentenstamm für die Bearbeitung von Anfragen in "+ / usr / share / nginx / html / australia " geändert. Für Besucher aus Singapur wird der Inhalt ebenfalls aus " / usr / share / nginx / html / singapore " bereitgestellt. Für andere Besucher wurde die Variable " $ site_version " auf eine leere Zeichenfolge gesetzt, sodass sie weiterhin Inhalte aus " / usr / share / nginx / html +" erhalten.

Wir können das Standard-Dokumentstammverzeichnis "+ / usr / share / nginx / html" einrichten, um dies einfach zu testen. Beginnen Sie, indem Sie an diesen Ort ziehen:

cd /usr/share/nginx/html

Als nächstes können wir die genannten Verzeichnisse erstellen und einige grundlegende Inhalte in eine + index.html + - Datei in jedem der neuen Verzeichnisse einfügen. Auf diese Weise können wir feststellen, ob sich unser Standort auf den Inhalt auswirkt, der uns bereitgestellt wird:

sudo mkdir australia && echo "<h1>australia</h1>" | sudo tee australia/index.html
sudo mkdir singapore && echo "<h1>singapore</h1>" | sudo tee singapore/index.html

Nachdem dies alles eingerichtet ist, können wir unsere Konfiguration testen und Nginx neu laden:

sudo nginx -t
sudo service nginx restart

Jetzt können wir die Website GeoPeeker erneut nutzen, um festzustellen, ob wir an verschiedenen Standorten unterschiedliche Inhalte erhalten. Sowohl Australien als auch Singapur sind Optionen, die Sie auf der Website überprüfen können.

Hier sehen Sie die Standardseite für einen Besucher aus den USA oder Irland und den Testtext, den wir für Besucher aus Australien oder Singapur hinzugefügt haben:

image: https://assets.digitalocean.com/articles/nginx_testing/geo_differences.png [Geolocation-Unterschiede]

Dies bestätigt, dass Nginx den zu liefernden Inhalt korrekt auswählt, indem die IP-Adresse des Clients mit der Standortdatenbank verglichen wird.

Fazit

Wenn Sie diese Strategien und Funktionen nutzen, können Sie mit dem Sammeln von Analysen beginnen, um fundiertere Entscheidungen über den Inhalt Ihrer Website zu treffen. Es gibt sicherlich viele externe Tools, mit denen Sie diese Art von Daten erfassen können. Die Option, native Nginx-Tools zu verwenden, ist jedoch eine gute Wahl, bevor Sie Zeit in andere Lösungen investieren.

TOC