Я ищу способ настроить среду песочницы Google Analytics, которая позволит мне протестировать собственный код js почти в реальном времени.
В моем приложении будут использоваться пользовательские переменные для расширенной сегментации, и я хотел бы быстро протестировать несколько сценариев, а не настраивать фиктивную учетную запись GA и ждать подтверждения теста целый день.
Спасибо
Отличный вопрос.
Для GA обновления сервера происходят каждые четыре часа, и после каждого шестого такого обновления весь набор пересчитывается, что означает 24-часовую задержку от изменения кода до надежной обратной связи. Эта задержка также относится к большинству настроек браузера GA (например, «пользовательские фильтры»).
Так что, если вы собираетесь использовать GA в качестве системы веб-метрик и рассчитываете действительно полагаться на эти данные, вам необходим тестовый стенд.
Для меня полезно сгруппировать тестовые системы для аналитики на стороне клиента, используя две рубрики: (i) полные, автономные (замкнутые) системы; или (ii) более простое автоматизированное извлечение данных из производственной системы (под «производственной системой» здесь я подразумеваю систему GA, а не Сайт, страницы которого отслеживаются кодом GA).
В последнем случае просто добавьте эту строку на каждую страницу вашего сайта, содержащую код отслеживания GA, чуть ниже «__trackPageview()»:
pageTracker._setLocalRemoteServerMode();
Эта строка приведет к тому, что копия каждой строки транзакции будет зарегистрирована в журнале активности вашего сервера, поэтому, по сути, вы получаете данные, собранные GA в режиме реального времени. Это все, что вам нужно сделать для сбора данных; для его анализа вы можете использовать, например, любой из превосходных анализаторов веб-журналов с открытым исходным кодом, например AWStats, или свернуть самостоятельно.
Это просто и надежно, но все, что он может сделать, это сказать вам (в режиме реального времени): «действительно ли работает код аналитики, который я только что реализовал на страницах, обслуживаемых моим производственным сервером?»
Обычно этого недостаточно — лучше знать, будет ли ваш код работать до того, как он появится на рабочем сервере. Для этого вам нужно смоделировать производственную среду и найти способ доступа в режиме реального времени к данным, которые собирает GA.
Этот тип испытательного стенда немного сложнее, но все же не сложный.
В общем, это требует следующих шагов:
локально размещать/обслуживать ga.js и пиксель отслеживания;
логировать запросы __utm.gif (в потоке данных GA каждый запрос соответствует одной зарегистрированной транзакции); а также
преобразовать заголовки в удобную для восприятия человеком форму.
Если вам нужна более подробная информация (т. е. пошаговая реализация), вот она:
И. Размещение/обслуживание скрипта GA (и автоматизация обновлений
Для этого вы можете создать небольшой сценарий оболочки, подобный этому, чтобы загрузить последнюю версию ga.js в локальный каталог (заменив существующую версию, которую он там находит).
#!/bin/sh
rm /My_Sites/sitename.com/analytics/ga.js
cd /My_Sites/sitename.com/analytics/
wget http://www.google-analytics.com/ga.js
chmod 644 /My_Sites/sitename.com/analytics/ga.js
cd ${OLDPWD}
exit 0;
(Благодарим AskApache.com, который предоставил первоначальная мотивация и детали конфигурации, чтобы сделать это в производственном контексте.)
II. Создайте файл __utm.gif
Это просто прозрачное gif-изображение размером 1x1 пиксель, которое вы поместите в каталог Сайта (неважно, где, оно просто должно соответствовать местоположению, указанному на ваших страницах)
III. Зарегистрируйте запросы __utm.gif
Для протокола тестирования, в котором вы являетесь источником активности на стороне клиента (например, вы хотите проверить кросс-браузерную точность некоторого кода отслеживания событий, который вы добавили на страницу на своем сайте, поэтому вы автоматизируете 5000 кликов на кнопке, которую вы только что подключили, обслуживая страницу с вашего сервера разработки, настроенного для этой цели), вероятно, проще всего просто записывать заголовки запроса, потому что именно в эти заголовки скрипт GA направляет клиента для сбора различных данных из DOM, из строки адреса (url) и из предыдущих заголовков http и добавления их к запросу ресурса на сервере GA (__utm.gif, который представляет собой просто прозрачный пиксель 1x1).
Другие виды тестовых протоколов требуют, чтобы вы работали с вашими журналами активности сервера; в этом случае просто добавьте эту строку на каждую страницу вашего сайта, чуть ниже __trackPageview():
pageTracker._setLocalRemoteServerMode();
IV. Проанализируйте эти зарегистрированные запросы, чтобы вы могли их прочитать.
Итак, теперь ваш журнал будет содержать отдельные строки транзакций, каждая из которых представляет собой строку, добавленную к HTTP-запросу для пикселя отслеживания GA. Эта строка представляет собой просто конкатенацию пар "ключ-значение", каждый ключ начинается с букв "utm" (вероятно, для "urchin tracker"). Каждый из этих параметров соответствует переменной, которую вы видите на панели управления GA (вот полный список и их описание). Это все, что вам нужно знать для создания парсера. Подробнее:
Во-первых, вот очищенный запрос __utm.gif (записи в вашем журнале LiveHTTPHeaders):
http://www.google-analytics.com/__utm.gif?utmwv=1&utmn=1669045322&utmcs=UTF-8&utmsr=1280x800&utmsc=24-bit&utmul=en-us&utmje=1&utmfl=10.0%20r45&utmcn=1&utmdt=Position%20Listings%20%7C%20Linden%20Lab&utmhn=lindenlab.hrmdirect.com&utmr=http://lindenlab.com/employment&utmp=/employment/openings.php?sort=da&&utmac=UA-XXXXXX-X&utmcc=__utma%3D87045125.1669045322.1274256051.1274256051.1274256051.1%3B%2B__utmb%3D87045125%3B%2B__utmc%3D87045125%3B%2B__utmz%3D87045125.1274256051.1.1.utmccn%3D(referral)%7Cutmcsr%3Dlindenlab.com%7Cutmcct%3D%2Femployment%7Cutmcmd%3Dreferral%3B%2B
Это мой парсер (на Python):
# regular expression module imported
import re
pattern = r'\&{1,2}'
pat_obj = re.compile(pattern)
# splitting the gif request on the '&' character
# (which GA originally used to concatenate each piece to build the request)
# (here, i've bound the __utm.gif to the variable by 'gfx')
gfx1 = pat_obj.split(gfx)
# create a look-up table to map a descriptive name to each gif request parameter
# (note, this isn't the entire list, which i've linked to above)
keys = "utmje utmsc utmsr utmac utmcc utmcn utmcr utmcs utmdt utme utmfl utmhn utmn utmp utmr utmul utmwv"
values = "java_enabled screen_color_depth screen_resolution account_string cookies campaign_session_new repeat_campaign_visit language_encoding page_title event_tracking_data flash_version host_name GIF_req_unique_id page_request referral_url browser_language gatc_version"
keys = keys.strip().split()
#create the look-up table
GIF_REQUEST_PARAMS = dict(zip(keys, values))
# parse each request parameter and map the parameter name to a descriptive name:
pattern = r'(utm\w{1,2})=(.*?)$'
pat_obj = re.compile(pattern)
for itm in gfx1 :
m = pat_obj.search(itm)
if m :
fmt = '{0:25} {1:10}'
print( fmt.format( GIF_REQUEST_PARAMS[m.group(1)], m.group(2) ) )
Результат выглядит следующим образом:
gatc_version 1
GIF_req_unique_id 1669045322
language_encoding UTF-8
screen_resolution 1280x800
screen_color_depth 24-bit
browser_language en-us
java_enabled 1
flash_version 10.0%20r45
campaign_session_new 1
page_title Position%20Listings%20%7C%20Linden%20Lab
host_name lindenlab.hrmdirect.com
referral_url http://lindenlab.com/employment
page_request /employment/openings.php?sort=da
account_string UA-XXXXXX-X
cookies
Чтобы не делать это еще длиннее, я не учел значения файлов cookie. Они, очевидно, требуют отдельного шага синтаксического анализа, хотя он практически идентичен шагу, который я только что показал. Опять же, каждый запрос представляет собой одну транзакцию, поэтому вы можете хранить их по мере необходимости.
