Pull to refresh

Comments 52

У счетчиков LiveInternet есть такой функционал, только в настройках проекта нужно поставить галочку «не отбрасывать параметры скриптов».
Извините, туплю… LiveInternet — JS.
Угу, и уверен что по надежности они уступают Google-у (имею ввиду uptime).
Отличный аптайм у ливинтернет, за год вот только недавно пару часов лежал.
У Гугла есть два варианта получения полных рефереров — либо строка в коде счетчика, либо настройка фильтра. Может кому-то пригодится.

www.reubenyau.com/google-analytics-hack-obtaining-full-referring-url/

С другой стороны владельцу интернет магазина велено судьбой сделать собственный инструмент анализа! Желательно чтобы было видно какие виды товаров благодаря какой рекламе продаются. И какие рекламные источники лучше всего продают товары. Статья полезная.
Похоже это больше не работает. Статья за 2007-й год. Сейчас в упор не вижу Custom фильтров в аналитике, в кастом репортах все по другому.
В FAQ — ответ за середину 2008-го года с тем же решением.
Ну а вариант с переписыванием гугловского JS — это конечно жесть :-)
Я только неделю назад настраивал фильтры. Всё работает!
Смотрите внимательнее — настройки профиля пользовательские фильтры. Настройки — это там где ещё цели, совместный доступ, там где выдается сам код счетчика.

А еще можно прописать все российские поисковики…

<script type=«text/javascript»>
try {
var pageTracker = _gat._getTracker(«UA-9999999-1»);
pageTracker._addOrganic(«mail.ru», «q»);
pageTracker._addOrganic(«rambler.ru», «query»);
pageTracker._addOrganic(«nigma.ru», «s»);
pageTracker._addOrganic(«blogs.yandex.ru», «text»);
pageTracker._addOrganic(«webalta.ru», «q»);
pageTracker._addOrganic(«aport.ru», «r»);
pageTracker._addOrganic(«akavita.by», «z»);
pageTracker._addOrganic(«meta.ua», «q»);
pageTracker._addOrganic(«bigmir.net», «q»);
pageTracker._addOrganic(«tut.by», «query»);
pageTracker._addOrganic(«all.by», «query»);
pageTracker._addOrganic(«i.ua», «q»);
pageTracker._addOrganic(«online.ua», «q»);
pageTracker._addOrganic(«a.ua», «s»);
pageTracker._addOrganic(«ukr.net», «search_query»);
pageTracker._addOrganic(«search.com.ua», «q»);
pageTracker._addOrganic(«search.ua», «query»);
pageTracker._addOrganic(«poisk.ru», «text»);
pageTracker._addOrganic(«km.ru», «sq»);
pageTracker._addOrganic(«liveinternet.ru», «ask»);
pageTracker._addOrganic(«gogo.ru», «q»);
pageTracker._addOrganic(«gde.ru», «keywords»);
pageTracker._addOrganic(«quintura.ru», «request»);
pageTracker._addOrganic(«qip.ru», «query»);
pageTracker._initData();
pageTracker._trackPageview();
} catch(err) {}</script>

Но повторюсь. Магазин, на мой взгляд, должен иметь свою систему. Всех рефереров не хранить, но для каждой покупки в корзине надо дать ответ — откуда пользователь пришел!
А почему не
INSERT INTO ref SET ref_url='$ref', ref_date=NOW() ON DUPLICATE KEY UPDATE ref_count=ref_count+1?
… а что мне(как внешнему пользователю) мешает в ref вставить что угодно?)
Вставляйте, это везде сработает :-) Из-за того что вставить можно что угодно и написано что может быть SQL Injection :-)
Тут смысл не в фильтрации, а в реализации. Не совсем понятно зачем создавать процедуру.
Значит обрабатывайте ref до выполнения запроса Вашим же способом
INSERT INTO ref SET ref_url='".addslashes($ref)."', ref_date=NOW() ON DUPLICATE KEY UPDATE ref_count=ref_count+1

+1 за «не понял зачем все эти навороты в хранимыми процедурами»
«Ну за то хоть разобрался» :-)
addslashes — не кошерно :-)
Может я туплю, но кого в таком случае ставить как PK или unique? Если поставим дату, то при её дублировании потрётся ref_url. Если ref_url, то новым обращением для конкретного URI потрётся дата.
Ну тоесть не потрётся, но получится ошибка, т.к. мы можем плюсануть либо не тот URI, либо не за ту дату.
Поглядел на CREATE TABLE в начале статьй. Простите, и правда ступил под вечер. )
В обсуждении рождается истина :-) Ваш вариант и проще, и быстрее в 2-4 раза. :-)
только ref_count по дефаулту надо 1 сделать
По-моему неверна конструкция «ref_date=NOW()», надо «ref_date=CURDATE()».
Работать будет и так и так.
А по-моему, не будет. Функция NOW() возвратит время с секундами, и «ON DUPLICATE» не сработает — будут добавляться новые строки, вместо того, чтобы инкрементить ref_count у старых.
Точнее, работать то будет, но неправильно.
А… В структуре же тип «DATE», тогда да, заработает. Извиняюсь, не заметил.
Делал свою систему статистики, вот какое наблюдение.
Хранить её в sql у хостера — не очень хорошая идея, потому что разрастается она быстро, места занимает много, статистика, как правило, интересует разная и за относительно большие промежутки, а к тому времени либо база распухнет недопустимо, либо будет медленно ворочаться. Или запрос не оптимально напишешь, или структуру данных не модифицируешь… А если шелла нет, то совсем плохо. В общем, не удобно.
Поэтому статистику стал складывать в xml-файл, вытаскивать его время от времени его по фтп и с помощью sax раскладывать, как надо, в базу на своей машине.
Так в базе только уникальные рефы в день, не так много… Все что старше пары недель можно удалять :-)
Если аппетиты в плане получения статистики не вырастут, то да.
В моём случае выросли очень быстро :)
Руководство иногда просит всевозможные выборки за несколько месяцев, а то и за год, такого характера: сколько народу за последние полгода пришло с Гугла из США, а сколько из Западной Европы, сколько с Яндекса из СНГ ну и такого характера. Требования время от времени меняются, запросы к базе замысловатые, так что приходится всё хранить у себя.
Возможно, при развитой бюрократии это нужно для планирования бюджетов рекламных кампаний PPC, на основе какой-никакой аналитики за предыдущие периоды.
я тоже завидую своим аппетитам :)

в итоге родилась следующая структура
необработанный лог ведется каждый месяц table_counter_.date('mY')

по крону из сырого лога выдергивается:
1. Хиты, хосты, посетители и складываются в отдельную таблицу table_total
2. Переходы с поисковых систем, парсятся запросы и тоже складываются в свою таблицу table_searches
3. Фиксируются переходы со сторонних сайтов, пишутся в свою таблицу table_refer

сырой лог можно хранить столько долго, насколько это позволяют ресурсы, а вот обработанные данные занимают не так много.
проще и быстрее записывать в форме Apache log
implode("\t", $row), explode("\t", $row)
в общем, да, с разделителями-табуляциями быстрее и компактнее
просто там xml сам себя документирует и основные тормоза возникают при работе с базой
писал подобную вещь (только для получения всей статистики — точки входа, ip, рефереры, поисковые боты и т.д. ).
на ряду с гугл серчем можно добавить и другие популярные поисковики (ну хотя бы яндекс еще)
ну и для гугл ссылок всеже лучше iconv в нормальную кодировку делать (если сайт не в utf, конечно)
У меня в день по 100 хитов с гугла, а с яндекса — хорошо если 1 :-)
Values in VARCHAR columns are variable-length strings. The length can be specified as a value from 0 to 255 before MySQL 5.0.3, and 0 to 65,535 in 5.0.3 and later versions.

заметьте, на версиях ниже 5.0.3 придется юзать ref_url как text, для меня своего рода потрясение устоев, не знал, может еще кому пригодится ;)
$max_date = sqlcount(«select MIN(ref_date) from (select DISTINCT ref_date from ref ORDER by ref_date DESC LIMIT 7) as tmp»);
$result = sqlexec(«select * from ref WHERE ref_date>='$max_date' order by ref_date DESC,ref_count DESC»);

Можно преобразовать в
SELECT ref_url,ref_date,ref_count FROM ref WHERE ref_date>DATE_SUB(CURDATE(), INTERVAL '8' DAY) ORDER BY 2 DESC,3 DESC

Единственный минус, что отсчитывается именно от сегодняшнего числа.
Во-первых, не записывается, на какую страницу вашего сайта пришли, что тоже интересно.
Во-вторых рационально хранить не больше, скажем, 1000 рефереров.
В-третьих, вот мои наработки по раскладу GET-запроса на: «Поисковик: Поисковый_запрос» — koxa.us/suggest.txt Может и не идеальное решение (без регулярки), но — работает. Попробуйте на koxa.us/suggest.php введите www.google.ru/search?hl=ru&newwindow=1&rlz=1G1GGLQ_RURU310&q=DotStudio&btnG=%D0%9F%D0%BE%D0%B8%D1%81%D0%BA&lr=&aq=f&oq=
можно писать целый пост в КодоБред.
if(isset($_GET)) {

Убило.
А вы не видите?
$_GET это суперглобальная переменная. Она не может быть !isset();
Даже если Вы сделаете unset(); Вы не освободите память от неё.
То что вы написали равно
if(1){
Ну строго говоря вы ошибаетесь, хотя в 99,9% случаев это так и будет.

Мануал:
Note: Variable availability
By default, all of the superglobals are available but there are directives that affect this availability. For further information, refer to the documentation for variables_order.

variables_order string
Sets the order of the EGPCS (Environment, Get, Post, Cookie, and Server) variable parsing. For example, if variables_order is set to «SP» then PHP will create the superglobals $_SERVER and $_POST, but not create $_ENV, $_GET, and $_COOKIE. Setting to "" means no superglobals will be set.
Я ошибаюсь?
Выполните:
if( isset( $_GET ) )
echo 'GET';

и посмотрите что произойдёт.
и расскажите про 0,1% из этого случая когда это не будет.
Очень интересно послушать.
Не поленился — погрепал на серваке. Оказывается Zend/Controller/Request/Http.php имеет в своих внутренностях следующую строчку:
«if (isset($_GET) && is_array($_GET)) {».

Надеюсь вы не скажете, что Зенд лохи писали? ) Есть ещё кое-где. Преимущественно используется такая конструкция, насколько я понимаю, в крупных проектах, которые должны работать на самых разных системах. Для CMS и движков форумов разумно матерится при установке, если они не могут найти массив $_GET. Ну и т.п.
в этом примере достаточно is_array( $_GET )
потому что массив не может быть !isset()
Я надеюсь Вы это понимаете.
Zend не последняя инстанция и, к сожалению, там тоже есть огрехи, но сам фреймворк замечательный.
Вы шутите? Я вам выше привёл выдержки из мануала из которых ясно, что для админа-извращенца отключить создание суперглобального массива $_GET — дело одной минуты. То, что мне такие случаи на практике не встречались не значит, что такого не бывает в принципе.
unset($_GET);
print_r($_GET);
if(isset($_GET)) echo 'Isset GET'; else echo 'Not isset GET';

Угадайте что выведет.
Хотя в данном случае Вы правы, да. Надо проверять $_GET['suggest']
Мне угадывать не надо.
Внимательно читайте. unset() сработает, но из памяти не отчистит.
достаточно просто if( !empty( $_GET ) )
Sign up to leave a comment.

Articles