GALAXY TECH
Chuyên gia Công nghệ
Thứ hai, 26/01/2015 | 00:00 GMT+7

Cách nhắm mục tiêu người dùng của bạn với Nginx Analytics và Thử nghiệm A / B

Nginx là một proxy và web server mạnh mẽ được một số trang web lớn nhất sử dụng để xử lý các kết nối client và cung cấp nội dung. Mặc dù hầu hết user đều quen thuộc với các tính năng cơ bản của Nginx, nhưng có những khả năng khác có thể không rõ ràng trong cách sử dụng thông thường.

Trong hướng dẫn này, ta sẽ khám phá một tập hợp các tính năng có thể hỗ trợ thử nghiệm nội dung mới và thu thập thống kê về user của bạn. Những điều này có thể cực kỳ hữu ích cho mục đích phát triển nội dung, để thực hiện thử nghiệm A / B đơn giản và để biết hành vi của các group user khác nhau thường xuyên trang web . Nginx có khả năng dễ dàng kết hợp các chức năng này vào chính web server .

Thử nghiệm A / B đơn giản với Mô-đun khách hàng phân tách

Ta sẽ bắt đầu bằng cách hướng dẫn bạn cách cấu hình một số thử nghiệm A / B cơ bản thông qua chính Nginx. Ta có thể làm điều này với một module HTTP tiêu chuẩn được gọi là http_split_clients . Trừ khi bị vô hiệu hóa rõ ràng trong quá trình biên dịch tùy chỉnh, điều này sẽ có sẵn trong cài đặt Nginx tiêu chuẩn nào.

Mô-đun cung cấp một chỉ thị duy nhất được gọi là split_clients chia các yêu cầu kết nối thành hai hoặc nhiều danh mục dựa trên các yêu cầu đã cấu hình . Lệnh này được xác định trong ngữ cảnh http , bên ngoài bất kỳ khối server nào. Nó chỉ định giá trị để kiểm tra trong mỗi kết nối và tạo một biến để lưu trữ kết quả.

Cú pháp cơ bản của chỉ thị trông giống như sau:

http {      . . .      split_clients "variable_to_evaluate" $new_variable {         percent_group%        value_to_store;         percent_group%        value_to_store;     }  }

Lệnh hoạt động bằng cách nội suy giá trị của biến đầu tiên được truyền vào và băm kết quả. Giá trị giống nhau sẽ luôn tạo ra cùng một hàm băm, cho phép tạo ra kết quả nhất quán. Biến đang được kiểm tra phải tạo ra một chuỗi khi được đánh giá.

Các dòng trong khối split_clients đại diện cho các “ group ” hoặc các lựa chọn thay thế khác nhau được xác định theo tỷ lệ phần trăm mà chúng nên sử dụng trong không gian băm có sẵn. Điều này tạo ra "phạm vi" băm phù hợp với một số lượng băm nhất định được xác định theo tỷ lệ phần trăm được cung cấp. Mỗi trong số này xác định một giá trị sẽ được đặt khi hàm băm nằm trong phạm vi của group đó. Biến thứ hai được đưa ra trong định nghĩa split_clients được đặt thành giá trị này.

Điều này dễ hiểu hơn nhiều khi xem xét một ví dụ. Hãy xem khối sau:

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

Trong ví dụ trên, ta đang đánh giá giá trị của kết nối cho $remote_addr , được đặt bởi Nginx thành địa chỉ IP của khách hàng. Giá trị của địa chỉ IP của khách hàng được băm bằng cách sử dụng thuật toán băm murmurhash2. Đến đây, Nginx sẽ kiểm tra phạm vi băm mà hàm băm được tính toán nằm trong phạm vi nào. Vì việc triển khai murmurhash2 mà Nginx sử dụng sử dụng 32 bit, các băm sẽ nằm trong repository ảng từ 0 đến 4294967295 (số 32 bit cao nhất).

Vì group đầu tiên được xác định chỉ định 10% tổng số băm, group này sẽ khớp từ 0 đến 429496729, là phần mười đầu tiên của phạm vi có sẵn. Các giá trị tạo ra một hàm băm trong phạm vi này sẽ đặt biến $designtest thành giá trị “.first”.

Địa chỉ IP có hàm băm từ khoảng 429496730 đến 858993459, phạm vi băm được biểu thị bằng 10% số băm có sẵn tiếp theo, sẽ trùng với dòng thứ hai. Trong những trường hợp này, biến $designtest sẽ được đặt thành “.second”.

Đối với tất cả các băm địa chỉ IP khác, (khoảng từ 858993460 đến 4294967295), biến $designtest sẽ được đặt thành một chuỗi trống.

Cách thực hiện điều này trên server

Về cơ bản, điều này cho phép ta ánh xạ ngẫu nhiên một tỷ lệ phần trăm kết nối nhất định đến các giá trị biến khác nhau. Khi điều này được thực hiện, ta có thể sử dụng biến đó để phục vụ các nội dung khác nhau.

Ví dụ: ta có thể thêm một server và khối vị trí phục vụ các nội dung khác nhau tùy thuộc vào giá trị của biến $designtest . Ví dụ dưới đây sử dụng biến này để quyết định file index nào sẽ phân phát:

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;         }     } }

Đối với các địa chỉ IP có hàm băm nằm trong group đầu tiên, Nginx sẽ cố gắng cung cấp file có tên là index.first.html . Tương tự như vậy, đối với các địa chỉ IP thuộc group thứ hai, Nginx sẽ tìm kiếm một file có tên là index.second.html . Nếu địa chỉ IP nằm trong group thứ ba, biến $designtest sẽ được đặt thành một chuỗi trống, do đó, index.html thông thường sẽ được phân phát.

Bây giờ, nếu ta tạo ba file index trong root tài liệu của bạn , chúng sẽ được phân phát cho những user khác nhau tùy thuộc vào kết quả băm của địa chỉ IP của họ:

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

Nếu bạn áp dụng các thay đổi trên đối với cấu hình Nginx của bạn và khởi động lại web server , bạn có thể kiểm tra . Ta có thể kiểm tra xem file cấu hình của ta không có lỗi cú pháp và sau đó khởi động lại dịch vụ bằng lệnh :

sudo nginx -t sudo service nginx restart

Nếu ta truy cập trang web trong trình duyệt của bạn , ta sẽ thấy một trong ba file ở trên. Có thể, đây sẽ là trang cuối cùng vì nó sẽ được phục vụ cho 80% khách truy cập trang web. Nếu bạn muốn xem nó sẽ hiển thị như thế nào đối với những user khác, bạn có thể truy cập trang web thông qua server proxy hoặc sử dụng một số công cụ web.

Ví dụ: trang GeoPeeker được dùng để xem trang web từ nhiều địa điểm khác nhau trên khắp thế giới. Nếu bạn nhập domain của bạn , bạn có thể thấy ít nhất một trong các trang web thay thế của bạn được hiển thị:

Chỉ mục trang web thay thế

Một trang web tương tự khác là LocaBrowser , cho phép bạn chọn từ nhiều quốc gia khác nhau. Lưu ý việc phân chia các trang đang được phân phát không dựa trên vị trí địa lý mà dựa trên hàm băm của địa chỉ IP, vì vậy điều đó không nghĩa là tất cả khách truy cập từ một quốc gia sẽ được phân phát cùng một file .

Trong khi ví dụ trên là một ví dụ đơn giản, khái niệm có thể được mở rộng khá nhiều. Bạn có thể sử dụng các biến do chỉ thị split_clients đặt để đặt cookie và ID user , chuyển tiêu đề cho proxy backend , v.v. Nếu bạn muốn kiểm tra A / B hoàn chỉnh hơn, bạn có thể cần sử dụng biến bạn đặt để xác định tài liệu root được phục vụ cho các bên khác nhau.

Điều quan trọng cần nhớ là kiểm tra ${remote_addr} chỉ là một ví dụ hữu ích. Bạn có thể băm dựa trên giá trị của bất kỳ biến nào của Nginx hoạt động trong chuỗi. Bạn có thể tìm thấy danh sách các biến có trong module Core tại đây , mặc dù các biến khác có sẵn thông qua các module khác. Kiểm tra tài liệu để biết thêm thông tin.

Đặt Pixel theo dõi bằng Chỉ thị blank_gif

Một cách mà administrator cố gắng giải thích cho những user truy cập trang web của họ là thông qua pixel theo dõi. Theo dõi pixel là một cách tốt để administrator thu thập dữ liệu về địa chỉ IP nào đang truy cập các trang nào vào thời điểm nào thông qua ghi log đơn giản.

Cách hoạt động của pixel theo dõi truyền thống là nhúng một hình ảnh trong suốt nhỏ vào trang. Khi user truy cập trang web, hình ảnh được yêu cầu như một phần của quá trình tải trang. Administrator có thể đưa những yêu cầu này vào một log riêng, cùng với địa chỉ IP nơi yêu cầu đến, khách hàng đang tải trang nào khi thực hiện yêu cầu, v.v. Loại thông tin này có thể là cơ sở để phân tích dữ liệu về hành động của khách truy cập trên trang web .

Mô-đun empty_gif cung cấp chức năng này trong Nginx. Mặc dù bất kỳ yêu cầu nào cũng được dùng để theo dõi, nhưng chỉ thị empty_gif cho phép bạn cung cấp .gif trong suốt nhỏ bé tồn tại trong bộ nhớ, tránh truy cập đĩa. Điều này sẽ tăng tốc các yêu cầu cho tài nguyên này. Chỉ thị có hiệu lực trong bất kỳ bối cảnh vị trí nào.

Thông thường, chỉ thị này được sử dụng cùng với một chỉ thị log riêng biệt để tách các yêu cầu phân tích sau này. Ví dụ: cấu hình của bạn có thể có một phần giống như sau:

. . .  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;         }     } }

Ở đây, ta cài đặt log_format trong ngữ cảnh http để ghi lại thông tin ta muốn theo dõi. Đây có thể là bạn muốn .

Sau đó, ta có thể cài đặt một khối vị trí để trùng với một yêu cầu .gif cụ thể. Ta đang sử dụng = modifier để mọi yêu cầu cho .gif sẽ được đối sánh nhanh chóng và hiệu quả mà không cần tìm kiếm các kết quả phù hợp hơn ở nơi khác. Bạn có thể chọn bất kỳ tên .gif nào bạn muốn.

Bên trong, ta sử dụng chỉ thị empty_gif để cung cấp .gif pixel 1x1 trong suốt từ bộ nhớ. Ta yêu cầu vị trí này đăng nhập vào một file riêng biệt bằng định dạng ta đã chỉ định trước đó. Cuối cùng, ta đặt thời gian hết hạn thành “kỷ nguyên”, điều này sẽ thông báo cho các trình duyệt không lưu vào bộ nhớ cache .gif , cho phép ta theo dõi mỗi khi khách truy cập vào trang.

Bây giờ, ta có thể thêm một hình ảnh yêu cầu hình ảnh ta đã chọn vào các trang của bạn . Ví dụ, một trang cực kỳ đơn giản có thể trông như thế này:

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

Khi khách truy cập vào trang này, hình ảnh /logme.gif sẽ được yêu cầu, khiến Nginx ghi vào file tracking.log của ta với các chi tiết về yêu cầu. Điều này có thể được xây dựng thành một hệ thống phức tạp hơn bằng cách điều chỉnh log_format của bạn và phân tích log của bạn bằng các công cụ xử lý văn bản.

Phân biệt nội dung dựa trên địa lý

Trước đó, ta đã hướng dẫn bạn cách cấu hình Nginx để tự động chia user thành các group nhằm mục đích thử nghiệm A / B với module split_clients . Nginx cũng có thể tự động chia user thành các group dựa trên vị trí địa chỉ IP của họ.

Địa chỉ IP được ánh xạ tới các vị trí gần đúng bằng cách sử dụng một tập hợp các bảng mà các nhà cung cấp nhất định biên dịch. Họ nhận được thông tin này chủ yếu từ nhiều cơ quan đăng ký chịu trách nhiệm phân bổ không gian IP ở các khu vực địa lý khác nhau. Thông tin có thể thu thập được từ địa chỉ IP của một ai đó chỉ là thông tin gần đúng và nên được sử dụng như một "dự đoán tốt nhất" thay vì một phương pháp xác định chính xác nguồn root của lưu lượng truy cập có độ chính xác cao.

Có được Database Vị trí

Nginx có thể sử dụng dữ liệu này để phân tách các client bằng cách sử dụng các lệnh khác nhau có trong module ngx_http_geoip_module . Tuy nhiên, database từ địa chỉ IP đến ánh xạ vị trí không được bao gồm, vì vậy bạn sẽ phải có được những database đó một cách riêng biệt.

Trên Ubuntu, bạn có thể nhận được ánh xạ cấp quốc gia bằng lệnh :

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

Một cách chung chung hơn để nhận bản đồ cấp quốc gia là tải các file xuống bằng wget . Ta có thể tạo một folder để lưu trữ database và sau đó download file bằng lệnh :

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

Ta cần extract file bằng lệnh :

sudo gunzip GeoIP.dat.gz

Để có database cấp city cụ thể hơn, bạn cũng có thể download bằng wget :

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

, ta cần extract các file :

sudo gunzip GeoLiteCity.dat.gz

Cấu hình Nginx để sử dụng dữ liệu vị trí

Sau khi có database vị trí, ta có thể cấu hình Nginx để tận dụng dữ liệu.

Ta có thể cho Nginx biết nơi tìm từng database trên đĩa bằng cách cài đặt các lệnh sau. Chúng phải được đặt trong ngữ cảnh http trong file cấu hình Nginx:

. . .  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;      . . . }

Khi vị trí đã được cài đặt , bạn có thể tận dụng các biến mà Nginx sử dụng cho từng database này. Database cấp quốc gia cung cấp cho ta quyền truy cập vào các biến sau:

  • $geoip_country_code : Mã quốc gia gồm hai chữ cái được sử dụng để đại diện cho một quốc gia. Ví dụ: “US” cho USA hoặc “RU” cho Nga. Chúng có thể được tìm thấy ở đây .
  • $geoip_country_code3 : Gần giống như ở trên, nhưng sử dụng biến thể ba chữ cái. Ví dụ: “USA” hoặc “RUS”.
  • $geoip_country_name : Tên được ánh xạ tới mã quốc gia như trong danh sách liên kết. Ví dụ: “New Zealand” cho “NZ”.

Database cấp city cung cấp cho ta một số lượng lớn hơn các biến. Với database đó, ta có quyền truy cập vào:

  • $geoip_area_code : Trường mã vùng kế thừa cho các số điện thoại của USA . Không nên dựa vào điều này để có dữ liệu chính xác.
  • $geoip_city_continent_code : Mã lục địa gồm hai chữ cái.
  • $geoip_city_country_code : Mã quốc gia gồm hai chữ cái giống nhau do database cấp quốc gia cung cấp.
  • $geoip_city_country_code3 : Mã quốc gia gồm ba chữ cái giống nhau do database cấp quốc gia cung cấp.
  • $geoip_city_country_name : Tên quốc gia giống như được cung cấp bởi database cấp quốc gia.
  • $geoip_dma_code : Vùng DMA hoặc mã city lớn cho các địa điểm ở USA . Điều này có thể được tìm thấy trong AdWords API của Google, được tìm thấy tại đây .
  • $geoip_latitude : Ước tính vĩ độ của IP root .
  • $geoip_longitude : Ước tính kinh độ của IP root .
  • $geoip_region : Mã vùng gồm hai ký tự được sử dụng để đại diện cho một khu vực chính trị, chẳng hạn như lãnh thổ, tiểu bang, tỉnh, v.v.
  • $geoip_region_name : Tên đầy đủ được liên kết với mã vùng ở trên.
  • $geoip_city : Tên city được liên kết với IP root .
  • $geoip_postal_code : Mã bưu điện của khu vực đặt IP.

, điều quan trọng cần nhấn mạnh là dữ liệu có sẵn thông qua các biến này dựa trên cơ sở phỏng đoán tốt nhất. Mặc dù vậy, điều này cung cấp cho ta một số cơ hội tuyệt vời để phục vụ các nội dung khác nhau cho các khu vực khác nhau.

Thường thì ta sẽ sử dụng một trong các biến ở trên với chỉ thị map để đặt giá trị của một biến khác có điều kiện. Điều này cho phép ta tạo một biến có giá trị được xác định bởi những gì database cho ta biết về vị trí của khách hàng.

Chỉ thị map cũng nên được sử dụng trong ngữ cảnh http . Ví dụ: ta có thể cấu hình trang web của bạn để hiển thị nội dung khác nếu khách truy cập đến từ Úc hoặc Singapore. Cách tốt nhất để kiểm tra điều này có lẽ là thông qua một trong hai hoặc ba mã quốc gia có trong database quốc gia hoặc city .

Ta sẽ sử dụng $geoip_country_code cho ví dụ này. Giá trị của biến đó sẽ xác định những gì ta lưu trữ trong biến $site_version mà ta đang tạo. Ta sẽ sử dụng điều này để xác định root tài liệu mà từ đó sẽ phân phát:

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";     }      . . . }

Điều này đặt giá trị của $site_version , một biến mà ta đang tạo riêng cho mục đích này. Nếu mã quốc gia của khách truy cập cho biết họ đến từ Úc ( AU ), ta sẽ đặt $site_version thành “/ australia”. Nếu khách truy cập đến từ Singapore (“SG”), ta sẽ đặt $site_version thành “/ singapore”. Nếu mã quốc gia của họ chỉ ra bất kỳ giá trị nào khác, ta sẽ đặt $site_version thành một chuỗi trống.

Điều này cho phép ta sửa đổi root tài liệu cho khách truy cập của ta từ các quốc gia cụ thể. Đây là một lựa chọn tùy ý để chứng minh một cách mà bạn có thể phân biệt nội dung dựa trên dữ liệu vị trí địa lý của khách hàng.

Để sửa đổi root tài liệu, ta chỉ cần đặt chỉ thị root trong khối server thành như sau:

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 {         . . .          root /usr/share/nginx/html${site_version};          . . .      } }

Nếu user đến từ Úc, root tài liệu để phục vụ yêu cầu sẽ được thay đổi thành /usr/share/nginx/html/australia . Tương tự như vậy, đối với khách truy cập từ Singapore, nội dung sẽ được phân phát từ /usr/share/nginx/html/singapore . Đối với những khách truy cập khác, biến $site_version được đặt thành một chuỗi trống, vì vậy họ sẽ tiếp tục nhận được nội dung từ /usr/share/nginx/html .

Ta có thể cài đặt root tài liệu mặc định /usr/share/nginx/html để kiểm tra điều này một cách dễ dàng. Bắt đầu bằng cách di chuyển đến vị trí đó:

cd /usr/share/nginx/html

Tiếp theo, ta có thể tạo các folder mà ta đã đề cập và chèn một số nội dung rất cơ bản vào index.html trong mỗi folder mới. Điều này sẽ cho phép ta xem liệu vị trí của ta có đang ảnh hưởng đến nội dung mà ta được cung cấp hay không:

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

Sau khi mọi thứ được cài đặt , ta có thể kiểm tra cấu hình của bạn và reload Nginx:

sudo nginx -t sudo service nginx restart

Như vậy, ta có thể tận dụng lợi thế của trang GeoPeeker để xem liệu ta có được phục vụ nội dung khác nhau từ các địa điểm khác nhau hay không. Cả Úc và Singapore đều là những lựa chọn mà trang web cho phép bạn kiểm tra.

Tại đây, bạn có thể thấy trang mặc định cho khách truy cập đến từ USA hoặc Ireland và văn bản thử nghiệm ta đã thêm cho những người đến từ Úc hoặc Singapore:

Sự khác biệt về vị trí địa lý

Điều này xác nhận Nginx đang chọn chính xác nội dung để phân phát bằng cách kiểm tra địa chỉ IP của khách hàng dựa trên database vị trí.

Kết luận

Bằng cách tận dụng các chiến lược và khả năng này, bạn có thể bắt đầu thu thập số liệu phân tích để giúp bạn đưa ra quyết định sáng suốt hơn về nội dung trang web của bạn . Mặc dù chắc chắn có nhiều công cụ bên ngoài có sẵn để thu thập loại dữ liệu này, nhưng có tùy chọn sử dụng các công cụ root của Nginx có thể là một lựa chọn tốt trước khi đầu tư thời gian vào các giải pháp khác.

Tags:

Các tin liên quan

Cách cài đặt WordPress với Nginx trên server FreeBSD 10.1
2015-01-14
Cách cài đặt Nginx, MySQL và PHP (FEMP) trên FreeBSD 10.1
2015-01-14
Hiểu và triển khai FastCGI Proxying trong Nginx
2014-12-08
Hiểu về Nginx HTTP Proxying, Cân bằng tải, Bộ đệm và Bộ nhớ đệm
2014-11-25
Hiểu cấu trúc tệp cấu hình và khung cấu hình Nginx
2014-11-19
Cách cài đặt MoinMoin với Nginx trên Ubuntu 14.04
2014-11-19
Hiểu server Nginx và các thuật toán lựa chọn khối vị trí
2014-11-17
Cách thiết lập server block Nginx trên CentOS 7
2014-11-05
Cách sử dụng tệp bản đồ Salt Cloud để triển khai server ứng dụng và reverse-proxy Nginx
2014-10-27
Cách triển khai ứng dụng Rails với Passenger và Nginx trên Ubuntu 14.04
2014-10-09