Мужики, а что же тогда "ваш бизнес" если не отслеживание кликов и не отслеживание "скликов" (любой природы)? Или вы не технологическая компания? Вместо того, чтобы публично расписываться в нежелании писать ДЛЯ СЕБЯ инструментарий первой необходимости потратили бы лучше время на:
- улучшение алгоритма распознавания тематики страниц/сайтов и выдачи наиболее подходящих объявлений;
- создание удобного интерфейса по работе со своим счетом/кампаниями/площадками;
- создание своего инструмента по сбору нужной ВАМ статистики по происхождению трафика.
Я уж не говорю о том, что у вас и так есть техническая возможность отслеживать происхождение трафика на рекламных площадках. Вы со своих серверов отдаете свои скрипты, поэтому нет никаких проблем фиксировать дополнительно рефереры.
В общем, это все личное дело компании Бегун, лечить которую никто не собирается. Просто совершенно не радует движение не в сторону клиента, а в сторону от него и перекладывание своих проблем на чужие головы. Рынок вылечит, надеюсь.
Требование предоставлять статистику посещений наружу кому-бы то ни было в корне неправильно. Статистика посещений - это коммерческая информация. Для проектов, для которых бегун является одним из побочных заработков и не более того это может быть критичной для бизнеса информацией. Насколько я понимаю, Бегун не берет на себя никакой ответственности за возможную утечку данных, в том числе например к конкурирующим ресурсам. Поэтому либо Бегун должен предоставлять такие гарантии - раз это нужно по бизнесу ЕМУ а не ПЛОЩАДКЕ, либо пользоваться своими способами оценки качества трафика. В частности, насколько я понимаю, намного проще обязать устанавливать счетчик РЕКЛАМОДАТЕЛЯ, чтобы оценивать конверсию, глубину просмотра сайта после клика по бегуновскому баннеру и так далее. Вообще мало понятно что можно извлечь из статистики рекламной площадки.
Подход - "не нравится - не ешь" - это "совок". Народ уйдет в другие системы. Нужно думать о клиентах, а свои проблемы решать самостоятельно, а не за их счет.
Еще настораживает отсутствие каких-либо четких критериев "качества" трафика. Насколько я вижу по жалобам, периодически появляющимся в этом разделе, при достижении какой-либо суммы Бегун может просто сказать - "а у тебя, мол, трафик некачественный. вот и статистика опять же у тебя плохая". Внятного объяснения какие параметры при рассмотрении той же статистики будут учитываться - пока не видно.
Немного конструктивной критики, надеюсь будет полезно.
Поправьте орфографию, чтобы глаз не запинался. "Благодаря этой библиотеки", "Заменяемо слово" и другие ошибки и опечатки.
Касательно статей. Формулы это конечно хорошо, но пока это только иллюстрация вашего собственного пути. Причем неоконченного. Было бы интересно все же начать не с процесса, а с результата, а процесс расписать чуть позже. В частности, было бы IMHO верно показать хотя бы теоретический результат ваших выкладок. То есть, если говорить о синонимайзере, тот текст, который вы даете на вход и на выход вашей модели.
Это что касается пожеланий. Что касается самой тематики работы есть вот какое соображение (сразу говорю - я не дорвейщик и даже не учусь, но тема синонимизирования и генерации текстов чисто абстрактно мне интересна): в статье "Оценка вероятности правильности использования синонима" вы делаете несколько предположений, которые непонятно откуда следуют. В частности мне кажется, что попытки высчитывать вероятности появления слов друг за другом без учета смысла приведут к тому же бреду, что генерируют с помощью обычных цепей Маркова. "Завтра погода будет плохая", "завтра поезд мой уйдет", "завтра случится что-то нехорошее", "завтра конец света" - после слова "завтра" будут стоять разные слова, как вы будете их синонимизировать?
Также, на мой непрофессиональный взгляд вы достаточно вольно оперируете вероятностями, и с точки зрения моего знания тервера ваши формулы мне не нравятся. Я могу ошибаться, но было бы неплохо залезть в справочники и проверить, если вы занимаетесь сей тематикой и зарабатываете на этом деньги.
Статьи смотрел по диагонали, сразу говорю, может чего не понял в вашей идее, тогда извините.
Чем вы генерируете конечно значения не имеет. Но на PHP часто заголовки, отдаваемые сервером формируются "руками", а на ASP и нете этим почти никогда не занимаются (исторически так сложилось). Поэтому в первую очередь проверьте нет ли разницы в том, какой набор заголовков отдается сервером на PHP версии проекта (надеюсь вы сохранили свой старый сайт в бэкапе?) и какой на ASP.
А вот какой у вас сервер - это имеет значение. Если вы не меняли Unix (Apache) на NT (IIS), то дальше можете не читать. Если меняли - следует проверить насколько корректно ваш сервер отдает контент при запросах keep-alive. У IIS есть проблемы при работе с яндексовским краулером, по крайней мере некоторое время назад. Приходилось рыться на системном уровне - смотреть TCP пакеты, поскольку потерянные HTTP запросы даже в логи сервера не попадали, как будто их не было. Привлекайте вменяемого сисадмина и commview+WGet вам в помощь.
Кое-что я фиксировал тут, пока разбирался - http://selectcms.ru/news/?nid=1252d9c9e706150be5a82a7404caa572, может и пригодится к сведению принять.
Ну, вообще-то сами регекспы в пределах приведенных примеров одинаковый синтаксис имеют, что на перле, что на PHP.
Это че-то не то. Оно конечно большое и "внушает", но там же просто тупо повторяется кусок один, столько раз сколько по RFC максимальная глубина поддоменов бывает.
У о'рейли в книге где то был поприкольнее примерчик.
Как это "штатными средствами не передать"? Берете wget (чем не штатное средство) и передаете заголовок Referer какой хотите.
Формат заголовка и прочее, если впервой, нужно смотреть в RFC 2616: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html, раздел 14.36
Если нужно это делать исключительно в браузере - можно извратиться javascriptом - сначала пойти куда-нужно чтобы заполнить referer, а потом - куда нужно за данными. Можно и еще извращеннее - поставить прокси и установить там настройки чтобы поле Referer записывалось какое нужно. Еще можно свою программу написать на bat/vbs/js/perl/php/c++/delphi (кому на чем проще и быстрее).
Масса вариантов, в общем. Все зависит от конкретной цели.
Что касается фреймов и новых окон - все зависит от браузера. В IE6.0 Referer сохранится в любом случае, позавчера как раз тестировали.
ТС, есть подозрение что ваш regexp малость кривоват. Почему вдруг имя почтового ящика у вас ограничено 20 символами? Есть масса длинных имен и фамилий, которые в корпоративных ящиках будут употреблены через точку, типа konstantin.mikhnerovich@bla.bla.com
А вообще, парсинг email адресов на регекспах соответственно RFC задача непростая. На perl есть классический пример, где эта задача решается регулярным выражением длиной в страницу или даже больше.
Вот поиск по сети дал оптимизированный результат: http://examples.oreilly.com/regex/email-opt.pl
Проверка через MX в большинстве случаев намного более сложно реализуется чем какой-нибудь тупой яваскрипт валидатор, и при этом избыточна для задачи. Учитывая кривизну настроек у огромного количества почтовиков для реальной жизни IMHO такая проверка кроме усложнения жизни пользователям сервиса мало что даст.
Задача продажи книг в коммерческих объемах упирается не в движок, а в проблему отсутствия единого каталога и классификатора книг. Идентификаторы типа ISBN в России не работают, все поставщики книг будут поставлять ассортимент в разном формате, будет проблема поиска дубликатов книг и так далее.
Поэтому для книг всегда пишется специализированное решение с уклоном в логистику и учет.
"Бросьте это дело, Холмс" (С).
Да, только надо проверить конечно будет ли замена быстрее поиска (если идеализировать решение). Плюс убивать исходную строку может быть не очень хорошо, а вдруг пригодится :).
PERL дает нам что? Правильно! TMTOWTDI (There's More Than One Way To Do It)!
Варианта три (как минимум):
1. Писать специализированное решение на серверном языке типа Perl, PHP, java, ASP, итд. Долго и если не понимаете тонкостей почтовых протоколов - бессмысленно.
2. Пользоваться готовым почтовым сервером типа MDaemon или Outlook Exchange. Создаются списки рассылки, а рассылкой занимается почтовик.
3. Функция рассылки переносится на клиентскую машину. Ищете софт для рассылки, импортируете список рассылки из серверного источника (например из базы CMS) и проводите рассылку со своей машине не грузя сервер.
