Только что завершился второй день Летнего Аналитического Фестиваля conf.uml2.ru, который проходил в Центре Отдыха "Малинки" недалеко от Иваново.
День состоял из нескольких круглых столов, которые проходили в уютной беседке, на природе, под шашлыки и пиво.
Тема первого круглого стола "Кто такой аналитик". Обсуждение велось о том, кто такое аналитик, какие аналитики бывают, какими профессиональными и личностными качествами должен обладать аналитик. Также обсуждалась связь аналитиков и тестировщиков.
Следующий стол обсуждал вопрос "Где должны готовить аналитиков". Эта тема вызвала очень жаркие споры, особенно благодаря тому, что на обсуждении присутствовал представитель Ивановского Государственного Химико-технологического Университета. Высказывались претензии у ВУЗам о том, что они не достаточно хорошо готовят специалистов системного анализа. В свою очередь представитель ВУЗа говорил, что ВУЗ дает основу, базу. А дальше - обязанность компаний.
Затем был проведен мастер-класс по разработке спецификации требований для вымышленного проекта. Мастер-класс, на мой взгляд, был несколько спорый. Я, честно говоря, ожидал от него несколько большего.
Фоток опять же нет, но думаю что скоро будут. Тогда и опубликую.
P.S. Несколько раз пытались поднять тему о работе аналитика в продуктовых компаниях, где нет заказчиков, но к сожалению тему замяли.
P.S.S. Запомнилось несколько интересных фраз:
- На собеседовании: Почему ты решил стать аналитиком? Потому что я плохой программист.
- У аналитика хорошо развиты комуникативые навыки. Так почему-бы ему не поработать сэйлом?
- Аналитики не нужны. Они только мешают программистам работать. А тестеры потом еще и баги пишут, что программисты не так накодили, как аналитики наанализировали.
- Анализируй визуально. Визуализируя анализируй.
- All you need is ЛАФ
воскресенье, 11 июля 2010 г. - www.msmirnov.ru
суббота, 10 июля 2010 г. - www.msmirnov.ru
Летний Аналитический Фестиваль-2010
Сегодня прошел первый день Летнего Аналитического Фестиваля 2010 в г. Иваново (ЛАФ 2010) conf.uml2.ru, организованного сообществом системных аналитиков www.uml2.ru, на котором ваш покорный слуга имел место быть.
Проходил ЛАФ в центре Иваново в довольно уютном бизнес-центре.
Всего на фестивале присутствовало около 90 человек из разных городов.
Первый день состоял из двух серий докладов, посвященных различным аспектам управления требованиями, системного анализа и проектировании систем.
Из всех докладов, которые мне удалось посетить, наиболее интересными мне показались следующие:
Фотографировать, к сожалению, возможности не было, так как фотоаппарат сейчас в Шарье у Кати с Лидой. Надеюсь завтра скину у кого-нибудь из участников фотки. Если получиться, то опубликую.
Завтра будет второй день - неформальное общение. Шашлыки, круглые столы и все такое.
Место проведения - поселок Малинки под Иваново.
Надеюсь будет не менее интересно чем сегодня.
А теперь спать, а то завтра опять дорога 200 км.
P.S. Город Иваново понравился - красивый, чистый, дороги хорошие, девушки симпатичные. Очень понравился.
P.P.S. Пообедали весьма отменно.
Проходил ЛАФ в центре Иваново в довольно уютном бизнес-центре.
Всего на фестивале присутствовало около 90 человек из разных городов.
Первый день состоял из двух серий докладов, посвященных различным аспектам управления требованиями, системного анализа и проектировании систем.
Из всех докладов, которые мне удалось посетить, наиболее интересными мне показались следующие:
- Тестирование требований: Зачем - понятно, а вот Как?
http://conf.uml2.ru/class/testirovanie-trebovanii-zachem---ponyatno-a-vot-kak.html
Докладчик Нечаева Юлия (jnechaeva.blogspot.com) рассказала о своем опыте внедрения процесса тестирования требований в своей компании.
Видео-запись доклада доступна здесь:
Лично мы в компании формально требования не тестируем. Надо будет поговорить об этом с тестировщиками.
- Написание тестов, как вид тестирования требований
http://conf.uml2.ru/class/napisanie-testov-kak-vid-testirovaniya-trebovanii.html
Весьма харизматичный (в хорошем смысле слова) докладчик Мартыненко Сергей blog.shumoos.com рассказал о своем видении определения требований через изначальное определение тестов к требованиям (этакий TDD для требований).
Особенно запомнились три его тезиса:
- Первый вопрос, с которого надо начать общение с потенциальным заказчиком: "Как вы поймете, что проект успешен?"
- Второй вопрос: "Кто кому и как будет сдавать проект?"
Видео пока на сайте нет, но я думаю что будет.
Как появится - добавлю ссылку.
- Практика работы с требованиями в иностранной компании, или In Wiegers We Trust
http://conf.uml2.ru/class/praktika-raboty-s-trebovaniyami-v-inostrannoi-kompanii-ili-in-wiegers-we-trust.html
Докладчик Белин Александр рассказал о своем опыте формализации процесса управления требованиями в крупной международной компании.
Работа, которая была проделана автором в плане организации процесса управления требованями поистине титаническая. Автору удалось из полного хаоса выстроить весьма сложную систему управления, в которую вовлечены множество людей. При чем процесс управления требованиями был внедрен в весьма тяжелом формальном варианте, что впрочем, было обусловлено спецификой производства (фармацевтика, медицина).
Видео пока тоже, к сожалению, не выложено - еще просто не успели. А доклад был очень интересным. Как появится - помещу сюда ссылки.
Фотографировать, к сожалению, возможности не было, так как фотоаппарат сейчас в Шарье у Кати с Лидой. Надеюсь завтра скину у кого-нибудь из участников фотки. Если получиться, то опубликую.
Завтра будет второй день - неформальное общение. Шашлыки, круглые столы и все такое.
Место проведения - поселок Малинки под Иваново.
Надеюсь будет не менее интересно чем сегодня.
А теперь спать, а то завтра опять дорога 200 км.
P.S. Город Иваново понравился - красивый, чистый, дороги хорошие, девушки симпатичные. Очень понравился.
P.P.S. Пообедали весьма отменно.
вторник, 6 июля 2010 г. - www.msmirnov.ru
Опыт организовации ротации Destination URLs для PPC-объектов
В этом посте я помещаю свою заметку"Опыт организовации ротации Destination URLs для PPC-объектов", опубликованную некоторое время назад на Хабре (http://michael-e-smirnov.habrahabr.ru/blog/97853/)
Как известно, объекты PPC-поисковых систем (как правило, это keywords и ads) имеют
такой параметр, как Destination URL (целевой URL), который содержит в себе ссылку
на страницу, рекламируемую посредством платной рекламы.
Было необходимо организовать ротацию Destination URL таким образом, чтобы они последовательно
менялись друг за другом для большого количества PPC-объектов (миллионы ключевых
слов) на различных поисковых системах (Google, Yahoo, MSN, Baidu, ASK и др.).
На первый взгляд эту задачу можно было решить посредством создания нескольких Ad'ов
с необходимыми целевыми ссылками, но на самом деле такой подход обладал следующими
проблемами:
Можно было просто обновлять целевые URL'ы по определенному графику, использую API
поисковых систем, но это также не могло решить проблему по нескольким причинам:
Поэтому, для организации подобного взаимодействия было решено организовать собственный
сервер, через который будет происходить редирект посетителей на целевые URL'ы.
Вот как выглядит путь посетителя от поисковой системы до целевой страницы:
Т.е. посетитель попадает на промежуточный сервер, а затем перенаправляется на целевой
URL. Для посетителя это происходит практически незаметно.
Целевые URL’ы были объединены в группы, в пределах которых осуществлялась ротация.
В свою очередь идентификатор группы был указан в целевом URL’е для PPC-объектов.
Т.е. URL’ы ключевых слов и Ad'ов на поисковой системе имели примерно следующий вид:
my_redirect_server.ru/?rotation_group_id=123456
При попадании посетителя на промежуточный сервер происходила ротация целевых URL’ов
и посетитель перенаправлялся на выбранный URL. Ротация происходила с учетом временных
настроек целевых URL’, а также других настроек (частота отображения и т.п.).
Благодаря такому решению задача была решена.
Очень важно было обеспечить бесперебойную работу промежуточного сервера, потому
что в случае его падения могла возникнуть такая ситуация, при которой посетители
приходили бы с поисковой системы (т.е. тратили бы деньги на оплату кликов), но не
попадали бы на целевой URL. Т.е. деньги тратились бы впустую.
Кроме того, необходимо было обеспечить балансировку нагрузки на случай резкого роста
трафика от крупного рекламодателя.
Поэтому, вместо одного промежуточного сервера было использовано несколько физических
серверов, которые балансировали нагрузку между собой.
Однако, кроме балансировки нагрузки эти сервера должны были бы еще обмениваться
информацией между собой, для того, чтобы обеспечить равномерность ротации. Кроме
того, при изменении настроек групп пришлось бы уведомлять каждый из серверов, что
было бы не удобно.
Поэтому для обеспечения механизма ротации был выделен отдельный сервис на отдельном
сервере.
Этот сервис был ответственен за принятие решения о том, какой целевой URL должен
быть отображен в каждом конкретном случае. В случае падения Rotation service сервера
редиректа продолжали работать на закешированных результатах до момента его поднятия.
В общем случае, вообще нельзя было допустить такой ситуации, когда система не сможет
отправить посетителя на какой-либо URL.
Поскольку ротацию требовалось выполнять максимально быстро, Rotation service работал
исключительно на закешированных данных групп и текущего состояния ротации. При изменении
настроек Rotation service уведомлялся о необходимости обновить кеш.
Благодаря такому подходу обеспечивалась высокая скорость выбора целевого URL’а.
Еще одна проблема при обеспечении высокой скорости работы – это сохранение отчетных
данных, которое нельзя было выполнять в синхронном режиме.
Поэтому был реализован механизм, при котором сервера накапливали отчетные данные
в памяти и с периодичностью в несколько минут сбрасывали их в фоновом режиме на
сервер сбора статистики.
Еще одной проблемой стало обеспечение высокой скорости работы при географической
удаленности посетителей и серверов редиректа.
При работе с Baidu основная часть посетителей находилась в Китае и они испытывали
трудности при редиректе через сервера, которые располагались в Европе. Эта проблема
была решена установкой дополнительного сервера в Китае.
Описанное выше решение было запущено в эксплуатацию несколько лет назад и с тех
пор обеспечивает обработку до 100 миллионов запросов ежемесячно, хотя потенциал
решения значительно выше.
Введение.
Как известно, объекты PPC-поисковых систем (как правило, это keywords и ads) имеют
такой параметр, как Destination URL (целевой URL), который содержит в себе ссылку
на страницу, рекламируемую посредством платной рекламы.
Было необходимо организовать ротацию Destination URL таким образом, чтобы они последовательно
менялись друг за другом для большого количества PPC-объектов (миллионы ключевых
слов) на различных поисковых системах (Google, Yahoo, MSN, Baidu, ASK и др.).
На первый взгляд эту задачу можно было решить посредством создания нескольких Ad'ов
с необходимыми целевыми ссылками, но на самом деле такой подход обладал следующими
проблемами:
- Невозможно было управлять временем работы URL'а – т.е. нельзя было сделать так,
чтобы какой-то URL работал только по выходным, или только два часа в день по утрам
и т.п. - Невозможно было управлять частотой отображения того или иного целевого URL'а.
- Было сложно собрать воедино статистику по использованию целевых URL'ов с нескольких
разнородных поисковых систем.
Можно было просто обновлять целевые URL'ы по определенному графику, использую API
поисковых систем, но это также не могло решить проблему по нескольким причинам:
- Многие поисковые системы (например Baidu или Yahoo) после изменения URL'ов ставят
изменения в состояние ожидания (Pending) и тратят значительное время (до нескольких
суток) на их проверку. - На Google это приводило бы к дополнительным расходам на Google Developer Token.
- Baidu не позволяет применять URL'ы, если их домены не находятся в списке заранее
разрешенных доменов. Поэтому смена урлов URL'ов затруднена. - Google обнуляет статистику по Ad’ам, если у них изменить URL, потому что внутренне
для Google это означает создание нового Ad’а. - Даже при отсутствии этих проблем все равно остается проблема быстрого обновления
большого количества объектов – т.е. если мы имеем миллионы ключевых слов, мы не
сможем мгновенно отправить изменения на любую поисковую систему. - Кроме того, связь через интернет не всегда является надежной – бывают обрывы связи
между провайдерами, сами API поисковым систем периодически глючат и т.п
Поэтому, для организации подобного взаимодействия было решено организовать собственный
сервер, через который будет происходить редирект посетителей на целевые URL'ы.
Решение.
Вот как выглядит путь посетителя от поисковой системы до целевой страницы:
Т.е. посетитель попадает на промежуточный сервер, а затем перенаправляется на целевой
URL. Для посетителя это происходит практически незаметно.
Целевые URL’ы были объединены в группы, в пределах которых осуществлялась ротация.
В свою очередь идентификатор группы был указан в целевом URL’е для PPC-объектов.
Т.е. URL’ы ключевых слов и Ad'ов на поисковой системе имели примерно следующий вид:
my_redirect_server.ru/?rotation_group_id=123456
При попадании посетителя на промежуточный сервер происходила ротация целевых URL’ов
и посетитель перенаправлялся на выбранный URL. Ротация происходила с учетом временных
настроек целевых URL’, а также других настроек (частота отображения и т.п.).
Благодаря такому решению задача была решена.
Подводные камни.
Очень важно было обеспечить бесперебойную работу промежуточного сервера, потому
что в случае его падения могла возникнуть такая ситуация, при которой посетители
приходили бы с поисковой системы (т.е. тратили бы деньги на оплату кликов), но не
попадали бы на целевой URL. Т.е. деньги тратились бы впустую.
Кроме того, необходимо было обеспечить балансировку нагрузки на случай резкого роста
трафика от крупного рекламодателя.
Поэтому, вместо одного промежуточного сервера было использовано несколько физических
серверов, которые балансировали нагрузку между собой.
Однако, кроме балансировки нагрузки эти сервера должны были бы еще обмениваться
информацией между собой, для того, чтобы обеспечить равномерность ротации. Кроме
того, при изменении настроек групп пришлось бы уведомлять каждый из серверов, что
было бы не удобно.
Поэтому для обеспечения механизма ротации был выделен отдельный сервис на отдельном
сервере.
Этот сервис был ответственен за принятие решения о том, какой целевой URL должен
быть отображен в каждом конкретном случае. В случае падения Rotation service сервера
редиректа продолжали работать на закешированных результатах до момента его поднятия.
В общем случае, вообще нельзя было допустить такой ситуации, когда система не сможет
отправить посетителя на какой-либо URL.
Поскольку ротацию требовалось выполнять максимально быстро, Rotation service работал
исключительно на закешированных данных групп и текущего состояния ротации. При изменении
настроек Rotation service уведомлялся о необходимости обновить кеш.
Благодаря такому подходу обеспечивалась высокая скорость выбора целевого URL’а.
Еще одна проблема при обеспечении высокой скорости работы – это сохранение отчетных
данных, которое нельзя было выполнять в синхронном режиме.
Поэтому был реализован механизм, при котором сервера накапливали отчетные данные
в памяти и с периодичностью в несколько минут сбрасывали их в фоновом режиме на
сервер сбора статистики.
Еще одной проблемой стало обеспечение высокой скорости работы при географической
удаленности посетителей и серверов редиректа.
При работе с Baidu основная часть посетителей находилась в Китае и они испытывали
трудности при редиректе через сервера, которые располагались в Европе. Эта проблема
была решена установкой дополнительного сервера в Китае.
Заключение.
Описанное выше решение было запущено в эксплуатацию несколько лет назад и с тех
пор обеспечивает обработку до 100 миллионов запросов ежемесячно, хотя потенциал
решения значительно выше.
пятница, 25 июня 2010 г. - www.msmirnov.ru
Какой weighting бывает.
Некоторое время назад в одной из своих статей я описывал что такое weighting, применительно к трекингу сайтов (http://www.seonews.ru/masterclasses/detail/29891.php#6).
Напомню, weighting - это способ анализа источников активности посетителей на сайте.
Проще всего говорить в применении weighting'а к определению источников продаж.
При использовании алгоритмов weighting'а привязка продажи к источникам трафика происходит не через анализ пользовательских сессий, а через анализ активности посетителя за длительный период без какого-либо учета сессий.
В итоге, если посетитель зашел сначала по одному источнику, затем по другому, потом по третьему и в конце концов совершил покупку, то сумма прибыли равномерно распределится между этими тремя источниками.
Это так называется "стандартный режим" weighting'а, при котором сумма прибыли равномерно распределятся между всеми источниками.
Здесь важно для себя решить, какое количество источников, предшествующих продаже, принимать во внимание.
Если оно будет слишком маленьким, то это будет приводить к потере информации.
Если слишков большим - к замусориванию отчетов.
Я рекомендую число 5.
Обычно, среди источников выбирается один основной, к которому собственно приписывается продажа. Остальные источники являются вспомогательными (Assists).
В последствии будет полезно посчитать, какое количество продаж принес каждый источник в качестве основного (Sales Count) и вспомогательного (Assists Count)
Существуют и другие способы weighting'а - например, вся сумма может приписываться к первому (first source of last five) или к последнему (last source of last five) из 5-ти источников.
Это требуется в тех случаях, когда остальные источники используются только в качестве вспомогательной информации, но не принимаются во внимание при анализе доходности.
В этом случае сама продажа так же приписывается к основному источнику, а все остальные помечаются как вспомогательные.
Еще один способ - анализ только первого источника за все время существования посетителя (а не из последних пяти). Это требуется в довольно редких случаях. При этом вся сумма приписывается к одному главному источнику, а вспомогательные источники отсутствуют.
Существует также алгоритм, при котором выполняется неравномерное распределение суммы продажи между источниками. Этот способ позволяет более точно организовать анализ эффективности каждого из источников. При этом требуется решить, какой процент от суммы продажи мы хотим относить на основной источник. Оставшаяся сумма сумма при этом равномерно распределяется между оставшимися источниками. Например, если мы хотим приписывать 50% суммы на основной источник, а всего источников было 3, то вспомогательные источники получат по 25% суммы продажи.
Напомню, weighting - это способ анализа источников активности посетителей на сайте.
Проще всего говорить в применении weighting'а к определению источников продаж.
При использовании алгоритмов weighting'а привязка продажи к источникам трафика происходит не через анализ пользовательских сессий, а через анализ активности посетителя за длительный период без какого-либо учета сессий.
В итоге, если посетитель зашел сначала по одному источнику, затем по другому, потом по третьему и в конце концов совершил покупку, то сумма прибыли равномерно распределится между этими тремя источниками.
Это так называется "стандартный режим" weighting'а, при котором сумма прибыли равномерно распределятся между всеми источниками.
Здесь важно для себя решить, какое количество источников, предшествующих продаже, принимать во внимание.
Если оно будет слишком маленьким, то это будет приводить к потере информации.
Если слишков большим - к замусориванию отчетов.
Я рекомендую число 5.
Обычно, среди источников выбирается один основной, к которому собственно приписывается продажа. Остальные источники являются вспомогательными (Assists).
В последствии будет полезно посчитать, какое количество продаж принес каждый источник в качестве основного (Sales Count) и вспомогательного (Assists Count)
Существуют и другие способы weighting'а - например, вся сумма может приписываться к первому (first source of last five) или к последнему (last source of last five) из 5-ти источников.
Это требуется в тех случаях, когда остальные источники используются только в качестве вспомогательной информации, но не принимаются во внимание при анализе доходности.
В этом случае сама продажа так же приписывается к основному источнику, а все остальные помечаются как вспомогательные.
Еще один способ - анализ только первого источника за все время существования посетителя (а не из последних пяти). Это требуется в довольно редких случаях. При этом вся сумма приписывается к одному главному источнику, а вспомогательные источники отсутствуют.
Существует также алгоритм, при котором выполняется неравномерное распределение суммы продажи между источниками. Этот способ позволяет более точно организовать анализ эффективности каждого из источников. При этом требуется решить, какой процент от суммы продажи мы хотим относить на основной источник. Оставшаяся сумма сумма при этом равномерно распределяется между оставшимися источниками. Например, если мы хотим приписывать 50% суммы на основной источник, а всего источников было 3, то вспомогательные источники получат по 25% суммы продажи.
понедельник, 21 июня 2010 г. - www.msmirnov.ru
Baidu увеличила максимальную длину URL для ключевых слов
Baidu увеличила максимальную длину URL для ключевых слов до 1024, что не может не радовать.
Раньше длина была очень маленькой и для того, чтобы определить по какому ключевому полю пришел посетитель приходилось в URL слова писать его ID из локальной базы, что совсем не хорошо. Такой способ довольно сильно увеличивает нагрузку на систему трекинга, так как каждый раз необходимо обращаться в базу и запрашивать слово, особенно при большом трафике.
Сейчас эта проблема решена - в URL слова можно писать его текст, ID кампании, ID AdGroup и вообще все, что необходимо для идентификации слова.
Вообще, приятно видеть, как динамично развивается Baidu, в течении года сменишвая систему Baidu Classic (довольно старомодная система, использующая positioning для ключевых слов подобно старой Overture) на Baidu Pro, которая по своей структуре близка к Google, Yahoo и MSN.
Осталось им только отменить ограничение, которое не позволяет использовать в URL домены, кроме как из разрешенного списка. Довольно неудобная вещь, видимо сделанная для обеспечения цензуры, не позволяет оперативно организовать redirect трафика с Baidu.
Надеюсь они это исправят.
Раньше длина была очень маленькой и для того, чтобы определить по какому ключевому полю пришел посетитель приходилось в URL слова писать его ID из локальной базы, что совсем не хорошо. Такой способ довольно сильно увеличивает нагрузку на систему трекинга, так как каждый раз необходимо обращаться в базу и запрашивать слово, особенно при большом трафике.
Сейчас эта проблема решена - в URL слова можно писать его текст, ID кампании, ID AdGroup и вообще все, что необходимо для идентификации слова.
Вообще, приятно видеть, как динамично развивается Baidu, в течении года сменишвая систему Baidu Classic (довольно старомодная система, использующая positioning для ключевых слов подобно старой Overture) на Baidu Pro, которая по своей структуре близка к Google, Yahoo и MSN.
Осталось им только отменить ограничение, которое не позволяет использовать в URL домены, кроме как из разрешенного списка. Довольно неудобная вещь, видимо сделанная для обеспечения цензуры, не позволяет оперативно организовать redirect трафика с Baidu.
Надеюсь они это исправят.
среда, 16 июня 2010 г. - www.msmirnov.ru
Phone calls tracking
Навеяно статьей "Как отследить эффективность рекламы в Интернет-магазине" (http://habrahabr.ru/blogs/eCommerce/96558/).
Автор статьи рассматривает проблему, как связать продажи с источниками трафика, если регистрация продаж происходит через интернет.
На мой взгляд, предложенный метод имеет ряд существенных недостатков:
1. Он не позволяет точно подсчитать количество продаж.
2. Продажи подсчитываются "обезличенно" - т.е. нельзя конкретно сказать источник каждой конкретной продажи.
3. Невозможно точно подсчитать суммы продаж по каждому из источников.
4. Нельзя проследить предыдущие заходы покупателя - например, если вчера он зашел с Google, сделал закладку, а сегодня зашел по ней и совершил покупку.
Некоторое время назад я сталкивался с решением подобной задачи и вот как это было сделано:
1. Для того, чтобы однозначно связать продажу с хитом на странице магазина, посетителям показывались не разные телефонные номера, а различные промо-коды, которые они называли при покупке.
2. Промо-код был укороченной версией уникального идентификатора (GUID) данного хита, состоял из 6-ти знаков, содержал буквы и цифры. При чем, чтобы исключить возможность кэширования, GUID создавался непосредственно на стороне клиента в javascript-коде.
3. Информация обо всех хитах посетителей сохранялась в базу трекинга.
4. Телефонные операторы составляли Excel-файл, в котором записывали данные о продажах (Сумма заказа, дата, данные по покупателе, данные о товарах и конечно промокод).
Затем операторы загружали этот файлы в базу трекинга через определенный интерфейс.
5. При загрузке продажа ассоциировалась с хитом посредством промо-кода. Дополнительно к промо-коду использовалась также и дата заказа для того, чтобы снизить вероятность дублирования промо-кодов.
6. После этого мы получали однозначную привязку продаж к хитам и затем, используюя идентификаторы сессий и посетителя, мы могли определить источник данной конкретной сессии и источники входа данного посетителя безотносительно сессий (так называемый weighting - что это такое - см. мою статью "Как связать продажи и источники трафика. Weighting." http://www.seonews.ru/masterclasses/detail/29891.php )
В завершение хочу сказать, что данный алгорим обрабатывал и обрабатывает порядка 100 миллионов хитов в месяц.
Автор статьи рассматривает проблему, как связать продажи с источниками трафика, если регистрация продаж происходит через интернет.
На мой взгляд, предложенный метод имеет ряд существенных недостатков:
1. Он не позволяет точно подсчитать количество продаж.
2. Продажи подсчитываются "обезличенно" - т.е. нельзя конкретно сказать источник каждой конкретной продажи.
3. Невозможно точно подсчитать суммы продаж по каждому из источников.
4. Нельзя проследить предыдущие заходы покупателя - например, если вчера он зашел с Google, сделал закладку, а сегодня зашел по ней и совершил покупку.
Некоторое время назад я сталкивался с решением подобной задачи и вот как это было сделано:
1. Для того, чтобы однозначно связать продажу с хитом на странице магазина, посетителям показывались не разные телефонные номера, а различные промо-коды, которые они называли при покупке.
2. Промо-код был укороченной версией уникального идентификатора (GUID) данного хита, состоял из 6-ти знаков, содержал буквы и цифры. При чем, чтобы исключить возможность кэширования, GUID создавался непосредственно на стороне клиента в javascript-коде.
3. Информация обо всех хитах посетителей сохранялась в базу трекинга.
4. Телефонные операторы составляли Excel-файл, в котором записывали данные о продажах (Сумма заказа, дата, данные по покупателе, данные о товарах и конечно промокод).
Затем операторы загружали этот файлы в базу трекинга через определенный интерфейс.
5. При загрузке продажа ассоциировалась с хитом посредством промо-кода. Дополнительно к промо-коду использовалась также и дата заказа для того, чтобы снизить вероятность дублирования промо-кодов.
6. После этого мы получали однозначную привязку продаж к хитам и затем, используюя идентификаторы сессий и посетителя, мы могли определить источник данной конкретной сессии и источники входа данного посетителя безотносительно сессий (так называемый weighting - что это такое - см. мою статью "Как связать продажи и источники трафика. Weighting." http://www.seonews.ru/masterclasses/detail/29891.php )
В завершение хочу сказать, что данный алгорим обрабатывал и обрабатывает порядка 100 миллионов хитов в месяц.
вторник, 4 мая 2010 г. - www.msmirnov.ru
Схема и шаблон производственного процесса
Некоторое время назад я создал презентацию, которая должна помочь сотрудникам моей проектной группы (особенно новичкам) лучше понять структуру протекающего производственного процесса.
Эта презентация представляла собой краткую "дорожную карту", которая описывала что и в каком порядке мы делаем, какие документы готовим и т.п.
Сам процесс был постороен на базе RUP с некоторыми, как это обычно бывает, изменениями.
http://www.msmirnov.ru/public/my_process_roadmap.ppt
Презентацию прилагаю к этому посту - так как имею желанию поделится результатами трудов по установлению производственного процесса, а кроме того послушать интересные отзывы коллег по цеху.
Шаблоны документов, упомянутых в презентации, я поместил в посте "Шаблоны некоторых документов для разработки проектов".
Там находятся шаблоны следующих документов:
Эта презентация представляла собой краткую "дорожную карту", которая описывала что и в каком порядке мы делаем, какие документы готовим и т.п.
Сам процесс был постороен на базе RUP с некоторыми, как это обычно бывает, изменениями.
http://www.msmirnov.ru/public/my_process_roadmap.ppt
Презентацию прилагаю к этому посту - так как имею желанию поделится результатами трудов по установлению производственного процесса, а кроме того послушать интересные отзывы коллег по цеху.
Шаблоны документов, упомянутых в презентации, я поместил в посте "Шаблоны некоторых документов для разработки проектов".
Там находятся шаблоны следующих документов:
- Документ проекта
- План осуществимости
- Концепция
- Общее описание архитектуры
- Общий план тестирования
- Список основных рисков
- План проекта
- Документ описания архитектуры
- План итерации
Подписаться на:
Сообщения (Atom)