С другой стороны владельцу интернет магазина велено судьбой сделать собственный инструмент анализа! Желательно чтобы было видно какие виды товаров благодаря какой рекламе продаются. И какие рекламные источники лучше всего продают товары. Статья полезная.
Похоже это больше не работает. Статья за 2007-й год. Сейчас в упор не вижу Custom фильтров в аналитике, в кастом репортах все по другому.
В FAQ — ответ за середину 2008-го года с тем же решением.
Ну а вариант с переписыванием гугловского JS — это конечно жесть :-)
Я только неделю назад настраивал фильтры. Всё работает!
Смотрите внимательнее — настройки профиля пользовательские фильтры. Настройки — это там где ещё цели, совместный доступ, там где выдается сам код счетчика.
Но повторюсь. Магазин, на мой взгляд, должен иметь свою систему. Всех рефереров не хранить, но для каждой покупки в корзине надо дать ответ — откуда пользователь пришел!
Может я туплю, но кого в таком случае ставить как PK или unique? Если поставим дату, то при её дублировании потрётся ref_url. Если ref_url, то новым обращением для конкретного URI потрётся дата.
А по-моему, не будет. Функция NOW() возвратит время с секундами, и «ON DUPLICATE» не сработает — будут добавляться новые строки, вместо того, чтобы инкрементить ref_count у старых.
Делал свою систему статистики, вот какое наблюдение.
Хранить её в sql у хостера — не очень хорошая идея, потому что разрастается она быстро, места занимает много, статистика, как правило, интересует разная и за относительно большие промежутки, а к тому времени либо база распухнет недопустимо, либо будет медленно ворочаться. Или запрос не оптимально напишешь, или структуру данных не модифицируешь… А если шелла нет, то совсем плохо. В общем, не удобно.
Поэтому статистику стал складывать в xml-файл, вытаскивать его время от времени его по фтп и с помощью sax раскладывать, как надо, в базу на своей машине.
Если аппетиты в плане получения статистики не вырастут, то да.
В моём случае выросли очень быстро :)
Руководство иногда просит всевозможные выборки за несколько месяцев, а то и за год, такого характера: сколько народу за последние полгода пришло с Гугла из США, а сколько из Западной Европы, сколько с Яндекса из СНГ ну и такого характера. Требования время от времени меняются, запросы к базе замысловатые, так что приходится всё хранить у себя.
Возможно, при развитой бюрократии это нужно для планирования бюджетов рекламных кампаний PPC, на основе какой-никакой аналитики за предыдущие периоды.
в итоге родилась следующая структура
необработанный лог ведется каждый месяц table_counter_.date('mY')
по крону из сырого лога выдергивается:
1. Хиты, хосты, посетители и складываются в отдельную таблицу table_total
2. Переходы с поисковых систем, парсятся запросы и тоже складываются в свою таблицу table_searches
3. Фиксируются переходы со сторонних сайтов, пишутся в свою таблицу table_refer
сырой лог можно хранить столько долго, насколько это позволяют ресурсы, а вот обработанные данные занимают не так много.
писал подобную вещь (только для получения всей статистики — точки входа, ip, рефереры, поисковые боты и т.д. ).
на ряду с гугл серчем можно добавить и другие популярные поисковики (ну хотя бы яндекс еще)
ну и для гугл ссылок всеже лучше iconv в нормальную кодировку делать (если сайт не в utf, конечно)
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
Единственный минус, что отсчитывается именно от сегодняшнего числа.
А вы не видите?
$_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.
Не поленился — погрепал на серваке. Оказывается Zend/Controller/Request/Http.php имеет в своих внутренностях следующую строчку:
«if (isset($_GET) && is_array($_GET)) {».
Надеюсь вы не скажете, что Зенд лохи писали? ) Есть ещё кое-где. Преимущественно используется такая конструкция, насколько я понимаю, в крупных проектах, которые должны работать на самых разных системах. Для CMS и движков форумов разумно матерится при установке, если они не могут найти массив $_GET. Ну и т.п.
в этом примере достаточно is_array( $_GET )
потому что массив не может быть !isset()
Я надеюсь Вы это понимаете.
Zend не последняя инстанция и, к сожалению, там тоже есть огрехи, но сам фреймворк замечательный.
Вы шутите? Я вам выше привёл выдержки из мануала из которых ясно, что для админа-извращенца отключить создание суперглобального массива $_GET — дело одной минуты. То, что мне такие случаи на практике не встречались не значит, что такого не бывает в принципе.
Пишем Referrer tracker: мал да удал, с хранимыми процедурами MySQL