Всегда приятно, когда результаты твоей работы приносят пользу. Вдвойне приятно, когда это замечают. И уж совсем хорошо когда об этом пишут.

Так произошло сейчас.

О проекте MakeMeTop (или Microchannel Technology, что одно и то же), которым я руковожу вот уже более 4-х лет, пишут сейчас на английском и китайском языках.
Дело в том, что недавно мы реализовали взаимодействие с поисковой системой Baidu, добавив ее к списку поддерживаемых поисковых систем. Это событие стало достаточно значительным, поскольку мы стали первыми, кому удалось этого добиться.

Вот первая публикация которая вышла в Китае: http://news.ccw.com.cn/internet/htm2008/20080317_390619.shtml
Примерный перевод можно посмотреть здесь:
http://translate.google.com/translate?u=http%3A%2F%2Fnews.ccw.com.cn%2Finternet%2Fhtm2008%2F20080317_390619.shtml&langpair=zh%7Cen&hl=ru&ie=UTF8

Процитирую: Ogilvy century bid management tool from Microchannel Technology's company to provide technical support to the global scope of the search engine dropped, and are applicable to all major mainstream search engines.

Поясню – Ogilvy – это наш клиент.

Затем в интернете появился еще раз публикаций:

• http://breakingnews.iol.ie/news/business/mhojmhgbqlcw/
  Microchannel Technologies has developed revolutionary internet software, including some of the world’s most advanced bid management and analytics software for internet search engines.
  
• http://www.independent.ie/business/world/irish-firm-strikes-huge-china-deal-1321248.html
  (Прошу обратить внимание – издание Independent)
  Microchannel Technologies has developed software for internet search engines.
  
  The specialised software is used by search engine marketing companies and advertising agencies to calculate a client's return on investment when running traditional and pay-per-click campaigns on the internet. The software will connect to Baidu, China's leading internet search facility, as well as all other major search engines worldwide. 
  
• http://breaking.tcm.ie/text/business/mhojmhgbqlcw/
  Microchannel Technologies has developed revolutionary internet software, including some of the world’s most advanced bid management and analytics software for internet search engines.
  
  The specialised software is used by search engine marketing companies and advertising agencies to calculate a client’s return on investment when running traditional and pay-per-click campaigns on the internet.
  
• http://www.investni.com/about-news.htm?newsid=10206
  Microchannel develops some of the world’s most advanced bid management and analytics software for internet search engines. Bid management software is an extremely specialised product. It is used by search engine marketing companies and advertising agencies to calculate the client’s return on investment when running traditional and pay-per-click campaigns on the internet.
  
  Microchannel become the first approved provider of Search Engine Marketing (SEM) software that can connect to Baidu, China’s leading internet search facility, as well as all other major search engines worldwide.
  
• http://www.ogilvy.com/press/showpress.php?ID=5683
  The Neo@Ogilvy and Microchannel Technologies effort facilitated the integration of China's leading search engine, Baidu.com    
  
• http://www.prweb.com/releases/2008/3/prweb782254.htm
  neo@Ogilvy first to launch new Implementation of MakeMeTop bid management and analytics software with Baidu API support in China.
  
  Belfast, Northern Ireland March 19, 2008 -- Microchannel Technologies Ltd., the software house that produces the advanced multi-lingual, multi-currency MakeMeTop series of bid management and analytics tools widely white-labelled by agencies worldwide, has successfully integrated the Baidu PPC API into their software, adding full support for the leading Chinese search engine to those already covered in the system -- including Google, Yahoo, MSN, Ask, Miva, Looksmart and Mirago.

Здесь я публикую текст своей статьи "Как связать продажи и источники трафика. Weighting.", опубликованной на сайте SeoNews.ru - http://www.seonews.ru/masterclass/101/ 

Как связать продажи и источники трафика. Weighting.

Введение

Для любого сайта, который предназначен для получения прибыли и в рекламу которого инвестируются определенные средства, важной задачей является анализ эффективности этих вложений, их возврата (ROI) и управление этим процессом. Последние несколько лет я руковожу проектом, который решает задачи подобного рода. В этом мастер-классе я собираюсь рассказать об одном из аспектов такого анализа, а именно – о связи продаж с источниками трафика.

Для того чтобы проанализировать эффективность инвестиций в интернет-рекламу, необходимо знать как минимум объем этих инвестиций и объем прибыли, полученной в результате рекламы. Однако для того чтобы инвестиции имели максимальный эффект, необходимо иметь возможность анализа источников прибыли.

Среди источников прибыли (или трафика на сайте) можно выделить следующие:

1. Платные поисковые системы

2. Бесплатные поисковые системы

3. Партнеры (обмен ссылками, баннерами и пр.).

4. Почтовые рассылки

Для каждого из таких источников можно подсчитать объем потраченных на рекламу средств (кроме бесплатных поисковых систем) и объем полученной прибыли.

Однако каждый из этих источников является довольно сложным по своей структуре:

1. Платные поисковые системы содержат множество ключевых слов, кампаний, аккаунтов и пр.

2. Бесплатные поисковые системы предоставляют трафик через различные поисковые запросы с использованием большого количества своих региональных подсистем.

3. Партнеры – имеют множество сайтов.

4. Рассылки – предназначены для рекламы различных товаров и услуг.

Соответственно возникает проблема – как понять, какое платное ключевое слово, какой поисковый запрос, какой партнер, какая рассылка и пр. приносят максимальную чистую прибыль? В этом мастер-классе описываются основные подходы к решению этой проблемы.

Описание механизма

Для того чтобы дальнейшие рассуждения были более наглядными, я привел здесь небольшой рисунок:

На нем вы можете видеть типичный путь пользователя по сайту – от попадания на сайт с одного из источников до оплаты заказа. Основными страницами здесь являются:

• Входная страница (Landing page) – страница, на которую пользователь попадает из «внешнего» интернета.

• Thank you page – страница благодарности за покупку. Эта страница отображается пользователю только после оплаты заказа. Отображение этой страницы является гарантией того, что пользователь совершил покупку.

Данная схема является приблизительной, т.е., например, внешняя платежная система может отсутствовать, если сайт сам имеет возможность принимать платежи.

Итак, основная задача - связать информацию о продаже ( ее сумме, товаре и пр.) с источником трафика и с расходами на этот источник.

Для каждого из источников способы его определения различаются, и поэтому я опишу их отдельно. Однако есть нечто общее, что их объединяет, а именно – счетчик трафика. Без него будет невозможно связать источник трафика и продажу. Счетчик трафика может быть частью сайта – т.е. просто анализировать логи вызовов его страниц, или может быть отдельной самостоятельной системой, которая имеет свой код на всех страницах.

В любом случае, счетчик трафика должен обладать следующим набором минимальных возможностей:

1. Должен уметь сохранять сессию посетителя от начальной страницы до последней.

2. Должен уметь сохранять идентификатор посетителя – он потребуется для решения проблемы weigthing'а (о weigthing'е ниже в этой статье).

3. Должен уметь сохранять все действия посетителя, по крайней мере, за несколько последних месяцев (опять же, для решения проблемы weigthing'а – см. ниже).

4. Иметь возможность регистрации факта продажи и как минимум ее объема.

5. Иметь возможность определения источника трафика , т.е. определения поисковых систем, поисковых запросов и пр. (как определить тот или иной источник – ниже в этой статье).

6. Иметь счетчики как минимум на входной странице и последней странице.

В том случае, когда вы имеете несколько сайтов, между которыми осуществляется переход посетителей, наличие счетчика трафика в виде отдельной системы является более предпочтительным, так как в этом случае вы имеете возможность сохранять идентификаторы посетителя и сессий не в Cookie сайта, а в Cookie счетчика, получив, таким образом, уникальные идентификаторы в пределах всех ваших сайтов. Однако для этого ваш счетчик должен обладать P3P-сертификатом.

Имея такой счетчик трафика, можно связать продажи и их объемы с источниками трафика и расходами.

Платные поисковые системы

Платные поисковые системы являются наиболее сложными и интересными с точки зрения анализа возврата инвестиций. Для того чтобы иметь возможность провести такой анализ для каждой продажи, вам необходимо знать, по какому ключевому слову был совершен переход на сайт. Ключевое слово идентифицируется различным набором параметров на разных поисковых системах, но, как правило, это

1. Само слово (его текст). Некоторые из поисковых систем обладают идентификаторами слов (Google, MSN), другие не обладают (MIVA).

2. Способ сопоставления ключевого слова и поискового запроса (полное совпадение, совпадение с учетом словоформ и пр.).

3. Группа слов на поисковой системе (одно и то же слово может встречаться в разных группах, поэтому необходимо знать эту группу).

4. Кампания. Понятие кампании существует не на всех поисковых системах, например, такие системы как MIVA, WebFinder, Mirago не имеют кампаний. Основные системы – Google, Yahoo, MSN, ASK, LookSmart и пр. обладают кампаниями.

5. Аккаунт на поисковой системе. Вы можете иметь несколько аккаунтов на одной системе с похожим набором слов.

6. Ad. Понятие Ad также есть не на всех поисковых системах, например, его нет на MIVA, WebFinder и пр. Для привязки продаж к ключевым словам знать Ad не обязательно, однако же, он может быть необходим для определения продаж по результатам рекламы в контекстных сетях (например, Google Аdsense).

Определить эти показатели через анализ реферреров на входной странице невозможно в силу ряда причин:

• Платные поисковые системы часто используются партнерами, которые размещают на своих сайтах результаты поиска или контекстную рекламу. В этом случае в качестве реферрера будет выступать неизвестный вам сайт, хотя, на самом деле, данный заход является для вас платным и вы обязаны за него заплатить.

• В случае Google Adsense в качестве реферрера будет GoogleSyndication, который также не предоставит никакой информации.

• Даже в случае, когда реферрер содержит поисковый запрос, все равно невозможно определить способ сопоставления, группу, кампанию и Ad.

Поэтому единственный способ определить все эти параметры – это заранее поместить их в URL ключевого слова или Ad'а.

Т.е. если URL вашего сайта выглядит так –

http://www.mysite.com/

То URL'ы ключевых слов будут выглядеть примерно так –

http://www.mysite.com/?ppc=google&keyword={keyword}&Ad={creative}&MatchType=Standard&AdGroup=12345&Campaign=67890

Здесь я привел общий вид URL’а – на разных поисковых системах он будет выглядеть по-разному, так как набор параметров будет различаться.

Как видим, в URL были добавлены дополнительные параметры, а именно:

• ppc – поисковая система или аккаунт на поисковой системе. В примере я привел значение google, но оно не обязательно должно содержать имя поисковой системы. Если вы имеете несколько аккаунтов, то оно может быть, например, google1 или google2, MyYahoo и т.п.

• Keyword – ключевое слово. Здесь в качестве значения я привел шаблон {keyword} который работает на Google, Yahoo и MSN. В момент нажатия на ссылку он будет заменен на текст слова, однако другие поисковые системы обладают другими шаблонами или не обладают ими совсем. В этом случае в URL придется помещать текст слова как он есть – т.е. keyword=my+keyword

• Ad – идентификатор Ad'а. Здесь в качестве примера я привел {creative}, который обслуживается Google, но на других системах он пишется по-другому – на MSN - {AdId}, на Yahoo - {YSMADID}.

• MatchType – способ сопоставления ключевого слова и поискового запроса. На разных поисковых системах существует разные способы сопоставлений. Здесь также могут применяться шаблоны – для Yahoo - {YSMMTC}, для MSN – {MathType}. Google не обладает таким шаблоном.

• AdGroup – идентификатор группы слов. Не на всех поисковых системах это понятие выглядит именно как AdGroup – где-то есть такие понятия как категория, листинг и пр., но суть у них одна – группировка слов.

• Campaign – идентификатор кампании. Опять же, не на всех системах есть кампании, но там, где они есть, их нужно определять.

С помещением таких параметров в URL ключевого слова также связаны некоторые проблемы:

1. Если у вас достаточно длинные ключевые слова, то максимальной длины строки URL, принятой в поисковой системе, может не хватить.

2. Набор параметров индивидуален для каждой поисковой системы (я уже отмечал, что кампании есть не везде и что набор способов сопоставления различается), поэтому придется помнить об этих различиях и формировать URL'ы соответствующим образом.

3. Проблема партнеров – партнеры поисковых систем могут кешировать результаты поиска на довольно длительное время. Это приводит к тому, что вы будете получать на сайте заходы по ключевым словам, которые приостановлены или даже удалены. С другой стороны, плюсом добавления параметров в URL является то, что при переходе от партнера, который не кеширует результаты запросов, вы получите его сайт в качестве реферрера, который мог бы попасть в источники трафика сам по себе, как разместивший ссылку на ваш сайт. Но в действительности этот сайт-партнер вас не интересует, так как на самом деле это платный переход и вам необходимо знать эффективность именно ваших ключевых слов, а не партнеров поисковых систем.

4. Проблема закладок – пользователь может попасть на входную страницу, которая содержит дополнительные параметры в URL и сохранить этот URL в Избранное. Если через некоторое время пользователь откроет ваш сайт из Избранного, то ваш счетчик зарегистрирует заход по платному ключевому слову, хотя на самом деле оно таковым не является.

5. Проблема ротации URL'ов (для Google): указав точный URL слова, вы теряете возможность создания нескольких Ad'ов с разными URL'ами – вместо них всегда будут использоваться URL'ы слов.

Все эти проблемы, конечно, вносят дополнительные неудобства, но они не искажают статистику настолько сильно, чтобы отказаться от данного подхода.

URL’ы Ad’ов тоже нуждаются в аналогичных дополнительных параметрах, так как они могут выступать самостоятельно в контекстных сетях и их эффективность также должна быть оценена.

Имея все эти параметры и сохраняя их в вашем счетчике, вы сможете затем связать их и с продажей при помощи идентификатора сессии посетителя. Вот почему наличие счетчика на входной странице обязательно – без него вы не сможете проанализировать заходы. Однако иногда бывают ситуации, при которых нет возможности поместить счетчик на входную страницу. Например, если она находится не на вашем сайте или если это связано с какими-то техническими или иными трудностями. Для того чтобы решить эту проблему, вы можете применить прием «Redirect». Суть приема в том, чтобы создать дополнительную страницу, которая не будет содержать никакой информации, а только лишь регистрировать факт захода с платной поисковой системы, а затем автоматически направлять посетителя на основной сайт. На следующей схеме я проиллюстрировал, как это работает.

В этом случае для ключевого слова вам вместо URL'а основного сайта потребуется указать URL этой дополнительной страницы. Целевой URL при этом (тот, куда пользователь должен быть перенаправлен) следует также указывать в качестве дополнительного параметра URL'а ключевого слова. Жестко кодировать URL'ы в коде дополнительной страницы не стоит, так как при этом вы лишитесь гибкости управления словами. Таким образом, URL’ы слов будут иметь следующий вид:

http://www.mysite.com/redirectpage.aspx?ppc=google&keyword={keyword}&Ad={creative}&MatchType=Standard&AdGroup=12345&Campaign=67890&DestinationURL= http://www.mysite.com/

Вы видите, что теперь посетители будут первоначально попадать на redirectpage, которая будет регистрировать факт захода с платной поисковой системы, а затем перенаправлять посетителей, используя параметр DestinationURL.

Понятно, что страница redirectpage должна работать очень устойчиво, так как в случае сбоев в ее работе будет происходить расход средств на поисковой системе, а посетители при этом не будут попадать на сайт.

Таким образом, используя дополнительные параметры в URL'ах, вы сможете накапливать статистику по продажам.

Для определения возврата инвестиций вам потребуется сравнить накопленные таким образом данные со статистикой расходов по ключевым словам и Ad'ам. Эту статистику можно получить с любой поисковой системы, а затем выполнить сравнение этих величин.

При этом главным показателем здесь является ROI = (Profit-Expenses)/ Expenses, который отображает эффективность вложений в то или иное слово.

Следует, однако, иметь в виду, что некоторые поисковые системы не обладают возможностью предоставлять отчетность с учетом вашего часового пояса (например, MIVA). Поэтому для того чтобы верно сопоставить продажи с затратами, вам потребуется предварительно перевести время ваших продаж во время поисковой системы. Обратная операция (т.е. перевод времени затрат в ваше время) невозможна, так как поисковые системы не предоставляют отчеты в почасовой разбивке.

Бесплатные поисковые системы

Бесплатные поисковые системы являются достаточно простыми с точки зрения анализа трафика. Для определения самой системы и поискового запроса, достаточно проанализировать реферрер на входной странице. Однако, в отличие от платных поисковых систем, бесплатные могут предоставлять посетителям доступ к любой проиндексированной странице сайта, поэтому любая страница сайт может стать для них входной. В этом случае вам потребуется наличие счетчика трафика на всех страницах вашего сайта.

Для определения системы и поискового запроса необходимо знать, какими URL'ами могут обладать эти системы (с учетом региональных подсистем) и какие параметры запросов они используют.
Например, если посмотреть на ссылки, которые формирует Google, можно увидеть, что получаются запросы подобного вида:

http://www.google.ru/search?complete=1&hl=ru&newwindow=1&q=my+search+query&lr=&aq=f

Видно, что текст поискового запроса (my search query) находится после параметра q=. Зная параметры поисковых систем, вы сможете получить тексты поисковых запросов, а затем связать с ними продажи, используя идентификатор сессии посетителя.

Для бесплатных поисковых систем нет смысла в подсчете ROI, так как по ним не производится никаких затрат. Поэтому единственные показатели, которые можно посчитать – это объем и количество продаж.

Однако эти показатели тоже могут быть весьма полезными. Зная, какие именно поисковые запросы приносят больше всего прибыли, вы можете использовать наиболее эффективные из них для пополнения списка ваших платных ключевых слов.

Партнеры и рассылки

Под партнерами здесь понимаются любые сайты (кроме поисковых систем), которые имеют ссылки на ваш сайт.

Среди них могут быть:

• баннеры, размещенные на сайтах ваших непосредственных партнеров;

• баннеры, размещенные в баннерных сетях;

• ссылки, размещенные на сайтах ваших непосредственных партнеров;

• ссылки, размещенные без вашего участия на каких-либо сайтах в интернете;

• ссылки, размещенные в почтовых рассылках;

Видно, что часть из перечисленного может быть для вас платной или бесплатной.

Для анализа доходности такого рода переходов обычно необходимо получить статистику продаж по следующим направлениям:

1. Сайтам, ссылающимся на ваш сайт.

2. Баннерам и ссылкам, размещенным у партнеров, в баннерных сетях, в почтовых рассылках и пр.

Статистику продаж по сайтам со ссылками получить довольно просто – имея счетчик на входных страницах, вы сможете определить реферрер и получить из него адрес сайта. Единственное, на что стоит обратить при этом внимание – это дополнительные параметры в текущем URL'е, которые вы, возможно, добавили для ваших ключевых слов на платных поисковых системах. Если такие параметры имеются, то реферрер, скорее всего, не должен восприниматься как партнер, так как он пользуется запросами к платным поисковым системам, а не размещает непосредственные ссылки на ваш сайт.

Статистику по баннерам и различным ссылкам (в том числе и в рассылках) можно получить, используя промо-код. Промо-код должен находится в URL'ах баннеров и ссылок и должен однозначно их идентифицировать.

Т.е. URL баннера для вашего сайта должен иметь следующий вид:

http://www.mysite.com/?promocode=banner1

Ваш счетчик, установленный на входной странице, сможет идентифицировать баннер или ссылку, используя промо-код и определить таким образом принадлежность продажи к данному баннеру или ссылке.

Затем, имея статистику затрат на размещение баннеров, вы сможете сравнить ее со статистикой продаж и подсчитать ROI баннеров и ссылок аналогично платным словам.

Weighting

Описанные выше подходы работают хорошо, но имеют один существенный недостаток, который проще будет продемонстрировать на примерах.

Пример 1.

Предположим, посетитель находит ваш сайт, доходит до просмотра товара и создает закладку.

На следующий день посетитель возвращается по своей закладке и производит покупку.

Как видите, в этом случае определение связи ключевого слова с фактом продажи с использованием сессии посетителя будет невозможно, так как в этом примере нет единой сессии от перехода до продажи – вместе этого мы видим две разные сессии.

Пример 2.

Предположим, посетитель находит ваш сайт и совершает покупку.

Через непродолжительное время посетитель возвращается на ваш сайт и совершает еще одну покупку, предварительно запомнив его адрес –

Как видим на этом примере, при анализе сессий посетителя вторая продажа не будет связана с платным ключевым словом, хотя это было бы логично – посетитель только что нашел сайт и совершил две покупки, просто выполнив их в двух последовательных сессиях.

В качестве решения этой проблемы можно было бы предложить сохранение платного ключевого слова (или другого источника трафика) например, в Cookie посетителя и все его последующие сессии считать относящимися к этому слову. Однако это тоже неверно, что видно на примере 3.

Пример 3.

Предположим, посетитель заходит на сайт по одному платному ключевому слову, а затем заходит еще раз, но уже по другому слову (или, например, уже с использованием бесплатной поисковой системы).

Здесь продемонстрированы два варианта событий.
Первый вариант: две сессии посетителя – первая по платному ключевому слову, вторая – по бесплатному.

Второй вариант: одна сессия посетителя, но с двумя переходами на сайт по разным платным ключевым словам.

Здесь видно, что при сохранении первого платного ключевого слова в Cookie возникает вопрос: как быть со вторым переходом? При таком подходе второе слово не будет учтено как источник продаж.

Можно было бы предположить, что правильным решением станет привязка продажи всегда к последнему, а не к первому переходу. Однако и этот подход не лишен недостатка: в этом случае первое слово остается без внимания, несмотря на то, что оно все-таки сыграло определенную роль в привлечении будущего покупателя. Кроме того, нам неизвестно, какой же из переходов больше повлиял на посетителя и привел его к окончательному решению о совершении покупки именно на этом сайте.

Для решения этой проблемы следует отказаться от анализа действия посетителя в контексте сессий. Вместо этого следует анализировать всю историю поведения посетителя на сайте и историю его переходов на сайт. Именно поэтому я писал выше о том, что счетчик должен обладать возможностью сохранять все действия посетителя хотя бы на несколько месяцев.

Кроме того, при таком подходе продажи должны быть ассоциированы не с одним, а с несколькими переходами. Сумма продажи при этом должна распределяться между несколькими источниками трафика. В этом и есть суть подхода, который называется weighting.

Пример работы weighting'а.

Рассмотрим этот более сложный пример, чтобы лучше понять, как работает weighting. Как видим, посетитель три раза заходил на сайт и совершил три покупки. При этом два раза он заходил по различным платным ключевым словам и один раз по закладке. При анализе на основе сессий первая продажа была бы привязана к первому ключевому слову, вторая – ко второму, а третья продажа была бы ни к чему не привязана. При использовании weighting'а первая продажа будет также привязана к первому слову (т.к. это единственный переход данного посетителя на сайт, совершенный до продажи), а вот вторая и третья продажи уже будут отнесены одновременно на первое и второе слово.

Возникает вопрос: каким образом распределить сумму продаж между ключевыми словами? Есть два пути – распределять ее равными частями или с использованием весовых коэффициентов – например, на последнее слово относить 70% суммы, а на первое – 30%. Какой именно способ выбрать, зависит от потребностей конкретного сайта и системы.

Приведем сводную таблицу сравнения способов анализа на основе сессий и weighting'а для данного примера. Здесь для простоты в случае weighting'а будем распределять суммы продаж между источниками равномерно.

В следующей таблице видна разница того, к каким словам относятся продажи при использовании обоих методов.

Теперь рассмотрим, как отличаются значения объемов продаж и ROI для метода анализа сессий и weighting'а. Предположим, что продажи посетителя были на сумму $100, $200 и $300 соответственно, а затраты были по ключевым словам были $50 и $70.

Как видим из таблиц, метод weighting’а дает более точное и полное представление о возврате инвестиций в интернет-рекламу и позволяет точнее ассоциировать продажи и источники трафика.

С использованием weighting'а связано несколько вопросов, а именно:

• Для какого количества ключевых слов или других источников трафика следует производить распределение суммы продаж?
Дело в том, что если посетитель пользуется большим количеством различных источников трафика – например, осуществляет сотни переходов по различным ключвым словам – то в этом случае не следует распределять суммы продаж между всеми из них, так как это снизит достоверность метода. Лучше ограничиться количеством из последних 3-5 источников, которые предшествуют продаже.

• Как долго ключевое слово или источник трафика можно считать применимым к вновь поступающим продажам?
В самом деле, если пользователь попал на сайт по платному ключевому слову год назад, затем целый год не заходил на сайт, а потом снова зашел, но уже по другому слову, то вряд ли имеет смысл относить 50% продажи на первое слово, так как это тоже снизит достоверность метода. Лучше ограничиться каким-то осязаемым сроком в 2-3 месяца, в течение которого слова и другие источники трафика будут считаться актуальными для той или иной продажи.

• Как распределять сам факт продажи?
При распределении суммы продаж между несколькими источниками трафика все более-менее ясно – сумма делится равными частями или с учетом весовых коэффициентов. Однако в случае когда кроме учета объемов вы ведете еще и учет количества продаж, для вас может оказаться неприемлемым наличие нецелого числа продаж по какому-либо ключевому слову. Например, при распределении одной продажи между пятью ключевыми словами вы увидите, что каждое из них принесло вам 0.2 продажи. Если такого рода значения не являются для вас источником проблем, то вы можете все оставить, как есть. Если же для вас это не подходит, то вам придется оставить факт продажи неделимым, привязав его, например, к последнему слову из пяти. При этом, однако, при просмотре отчетности вы увидите, что первые четыре слова принесли вам некоторую прибыль и при этом 0 продаж. Т.е. в этом случае вам придется держать в голове такую особенность учета.

• Производительность
Если сайт достаточно популярен (имеет сотни миллионов посетителей), то для него использование weighting'а может быть достаточно затратным, так как потребуется хранить и анализировать историю действий посетителей, которая будет довольно внушительной.

• Платежные системы
Если посмотреть на самый первый рисунок мастер-класса, то, с точки зрения weighting'а, все может выглядеть так:

Видим, что платежная система в таком случае может быть воспринята как источник трафика (сайт-партнер), так как переход с нее предшествует факту продажи, и в этом случае на нее будет отнесено 50% продажи. Для устранения этого эффекта вам необходимо знать адреса платежных систем (а возможно, и других сайтов), которые необходимо будет исключить из анализа путем weighting'а.

Заключение

Описанные в данном мастер-классе приемы позволят вам привязать продажи на вашем сайте к источникам трафика – платным или бесплатным ключевым словам, партнерам и пр., а также проанализировать эффективность инвестиций в интернет-рекламу и проанализировать возврат этих инвестиций.

Если у вас есть любые вопросы, комментарии или пожелания по поводу этого материала или данной тематики, пожалуйста, направляйте их мне через www.msmirnov.ru - я всегда буду рад их получить и обсудить.

Михаил Смирнов, руководитель проектов.

Заметил, что MSN ужасным образом ужимает фотографии, которые я закачиваю на сайт. Качество становится просто ужасным. Вообще теперь не хочется фотографии к ним закачивать. Интересно, можно это как-то исправить?

На днях была возможность покататься на новом Лансере - X. Впечатления самые наилучшие. Особенно внешний вид. Сколько бы ни ругали жесткий пластик, шумный вариатор и т.д. - мне машина эта очень нравится. Хотя цена, конечно, кусается - около 660 000р. за версию с двухлитровым двигателем и вариатором.

Здесь я привожу текст своей статьи "Практические рекомендации по организации службы поддержки в малых и средних проектах" опубликованной на сайте GotDotNet.ru - http://www.gotdotnet.ru/LearnDotNet/Misc/481321.aspx 

Практические рекомендации по организации службы поддержки в малых и средних проектах.

Введение

Всем известно, что для эффективной работы службы технической поддержки эта служба должны быть многоуровневой. В этой статье я привожу ряд уроков и практических рекомендаций, которые я извлек из работы службы поддержки проекта, которым я руковожу. Эти рекомендации призваны помочь тем руководителям, которые только собираются организовать подобную службу в своих проектах и не имеют необходимого опыта.

Работа службы

Итак, как я уже упомянул выше, для эффективной работы служба технической поддержки она должна быть многоуровневой. Управляя в данный момент проектом среднего объема (10-20 человек в команде проекта и несколько сотен клиентов по всему миру), я использовал разделение службы поддержки на три уровня. Вы можете видеть эти уровни на диаграмме.

	Условные обозначения
	- Клиенты
	- Региональные офисы поддержки
	- Центральный офис поддержки
	- Команда разработки

На первом уровне, самом близком к клиентам, находятся региональные офисы поддержки, обслуживающие своих локальных клиентов. На втором находится центральный офис поддержки и на третьем, самом последнем уровне, находится команда разработки. Причем, центральный офис поддержки находится в непосредственной близости от команды разработки, составляя с ней единое целое.

Рассмотрим вопросы, связанные с функционированием каждого из этих уровней.

Региональный уровень.

Первый (региональный) уровень необходим по нескольким причинам:

1. Сотрудники региональных офисов хорошо знакомы с местной спецификой работы, культурными и языковыми особенностями и т.п. Это является очень важным моментом, особенно когда региональные офисы находятся в разных странах или обеспечивают поддержку на разных языках. Плохое знание местных нюансов делового общения, которое могут демонстрировать сотрудники центрального офиса поддержки, может отрицательно сказаться на имидже продукта и компании.
   
2. Сотрудники регионального офиса работают в том же часовом поясе, что и клиенты. В этом случае вам не придется держать круглосуточный штат сотрудников в центральном офисе.
   
3. Сотрудники регионального офиса обладают возможностью выезда или длительных телефонных переговоров, что часто бывает невозможно для сотрудников центрального офиса.
   
4. Сотрудники регионального офиса способны быстро отреагировать на типичные затруднения клиентов, которые, в большинстве своем, связаны с вопросами по использованию продукта, а не с проблемами в его работе. Тем самым региональный офис позволяет существенно разгрузить работу центрального офиса, взяв на себя основной поток простых вопросов.
   
5. Клиентам удобней работать с местной службой поддержки, так как в этом случае они ощущают большую заботу о себе со стороны компании, особенно если они имеют личного регионального менеджера.

Таким образом, региональные офисы поддержки берут на себя основную нагрузку по работе с пользователями. Они отвечают на основные вопросы, разъясняют особенности использования продукта и т.д.

Однако, в работе региональных офисов существует ряд сложностей, на которые необходимо обратить внимание.

1. Квалификация сотрудников. Это проблема, пожалуй, основная. Не имея соответствующей подготовки, местные сотрудники могут сами быть недостаточно осведомлены о продукте, могут не знать всех его особенностей. Это может приводить к тому, что они будут давать неверные ответы клиентами или же просто служить передаточным звеном между клиентов и центральным офисов поддержки. И то и другое отрицательным образом сказывается на процессе поддержки. В первом случае клиенты получают неверную информацию, во втором случае излишне нагружается центральный офис, а региональный офис не выполняет свою основную функцию. Для решения этой проблемы я рекомендую предварительное обучение и стажировку сотрудников региональных офисов в центральном офисе, даже если они находятся в разных странах.
   
2. Оторванность от процесса разработки. Поскольку в любом продукте происходят изменения, а клиенты получают обновления этих продуктов, может создаться такая ситуация, при которой сотрудники региональной службы будут не в курсе последних обновлений в продукте. Для решения такой проблемы необходимо уведомление всех сотрудников всех офисов поддержки списком изменений при каждом новом выпуске продукта. При этом, чем более детальной будет информация об обновлении, тем лучше.
   
3. Неспособность решить сложные вопросы. Эта проблема перекликается с проблемой квалификации, но имеет свою особенность. Дело в том, что вопросы, которые подаются на рассмотрение, могут быть связаны со сбоями в работе продукта, которые региональный офис решить не в состоянии. В этом случае, вопрос поступает на рассмотрение в центральный офис поддержки, а затем, возможно, в команду разработчиков, что увеличивает время решения проблемы. Однако, если продукт достаточно стабилен, то проигрыш по времени в таких случаях обычно не значителен.

В случае успешного решения всех этих проблем, работа регионального офиса достаточно эффективна и приносит ощутимый эффект. Есть еще несколько вопросов, связанных с работой региональной службы поддержки, на которые я бы хотел обратить внимание.

1. Доступ к продукту. Очень часто клиенты не в состоянии четко объяснить проблему или ситуацию, которая у них происходит. Для того, чтобы понять, с чем именно столкнулся пользователь, для службы поддержки будет очень эффективно, если она будет иметь доступ к продукту и данным клиента. Конечно, здесь возникает вопрос конфиденциальности клиентских данных, но если это не является проблемой или если этот вопрос решен, например, юридически, то предоставление доступа для службы поддержки весьма оправдано. Например, если речь идет о предоставляемой интернет-системе, то служба поддержки должна иметь возможность получить в нее доступ и проанализировать какие действия пользователь совершал и в чем состоит его затруднение. Это также необходимо и для того, чтобы предоставить полные объем информации в центральный офис, если возникнет такая необходимость. Центральный офис и команда разработки могут ощущать такой же недостаток информации, описывающей проблему, поэтому, имея подобный доступ, региональные сотрудники смогут собрать такую информацию.
   
2. Протоколирование всех действий и изменений. Для работы службы поддержки будет очень полезно, если продукт будет обладать возможностью протоколирования всех действий и всех изменений, совершаемых пользователями, либо самими сотрудниками службы. Особенно это важно, когда продукт используется для управления какими-либо данными, содержащимися у клиента. Кроме того, если продукт предоставляет возможность автоматизированного управления такими данными, то все эти изменения, а также их причины, также должны быть запротоколированы. Наличие подобных протоколов позволяет решить сразу несколько проблем:

• Сотрудники службы поддержки могут точнее проанализировать какие именно действия совершал пользователь до того, как у него возникла некоторая ситуация. Если продукт предоставляет возможность автоматизированного управления пользовательскими данными, то такие протоколы смогут показать изменения сделанные в автоматическом режиме.
  
• Протоколы могут использоваться в качестве доказательства того, что какие-либо изменения были совершены самим пользователем, либо же продуктом. Периодически возникает ситуация, когда необходимо выяснить, кто именно внес те или иные изменения и почему. Такие протоколы позволяют решить эту проблему.
  
• Протоколы могут дать возможность восстановления ошибочно измененных данных, если такие изменения были внесены пользователями или продуктом.

1. Ведение базы запросов. Весьма полезно, если в региональной службе поддержки будет организована база задаваемых вопросов. Такая база позволит сохранить информацию о том, какие вопросы задавались различными клиентами и какие ответы были на них получены. Здесь также будет известно кто именно отвечал на вопрос и сколько времени это потребовало. В последствии эта информация может служить для анализа того, сколько и какие именно вопросы задает каждый клиент, какие вопросы обрабатывает каждый специалист службы, оценить общий объем и эффективность работы офиса и т.п. Также эта база может использоваться для списка часто задаваемых вопросов или для анализа удобства работы с продуктом и качества продукта. Идеально, если база вопросов будет общей для всех офисов поддержки всех уровней.

Центральный офис.

Центральный офис является промежуточным звеном между региональными офисами и командой проекта. Этот офис необходим для решения следующих задач:

1. Оградить команду проекта от потока вопросов региональных офисов. Не смотря на то, что вопросы, поступающие от региональных офисов, могут требовать непосредственного вмешательства команды разработки, практика оказывает, что большинство из них все-таки могут быть решены на уровне поддержки. Такие вопросы могут быть связаны, например, с особенностями внутренних алгоритмов работы продукта.
   
2. Упорядочить поток вопросов, которые все же требуют участия разработчиков. При наличии непосредственного доступа регионального уровня поддержки к команде разработки есть риск того, что команда разработки будет вынуждена постоянно отвлекаться на решение их вопросов, что отрицательно скажется на производственном процессе. Для решения такой проблемы предназначен центральный офис, который организует упорядоченный процесс обращения к команде проекта.
   
3. Работа с особыми клиентами. Некоторые клиенты, которые обладают особыми привилегиями, могут иметь доступ непосредственно к центральному офису поддержки, минуя региональный уровень. Это может быть связано, например, с выполнением ряда дополнительных задач непосредственно для данного клиента. Такой доступ позволит им быстрее получать ответы на свои специфические вопросы, так как центральный офис находится в непосредственной близости от команды разработчиков. Однако, в общем случае, такого подхода стоит избегать.
   
4. Подготовка и рассылка описаний обновлений. При каждом выпуске обновлений продукта, центральный офис поддержки должен подготавливать и рассылать во все региональные офисы подробное описание всех изменений, проведенных в продукте. Он также должен оказывать консультации сотрудникам региональных офисов и особо важных клиентов по сути проведенных изменений.

Так же, как и офис регионального уровня, центральный офис должен обладать централизованной базой вопросов и проводить ее анализ. Кроме того, центральный офис должен иметь доступ к документам производственного процесса команды разработки – к базе ошибок, планам проекта, планам выпусков и т.п. Это позволит им наладить эффективную работу с командой разработчиков.

Проблемы, которые могут возникать в данном офисе, в большинстве своем аналогичны проблемам регионального уровня – это квалификация, излишнее вовлечение команды разработки, оторванность от процесса разработки и т.п. Однако, в общем случае, эти проблемы меньше проявляются, так как, еще раз повторюсь, этот отдел находится в непосредственной близости от команды разработки.

Команда проекта.

Команда проекта, насколько это возможно, должна быть ограничена от общения с клиентами по поводу возникающих у них вопросов. В большинстве случаев клиентам нравится иметь непосредственный доступ к команде разработки, так как это дает им возможность влиять на разрабатываемую функциональность и быстро получать ответы по их конкретным ситуациям. Однако, несмотря на это, такой способ коммуникаций отвлекает разработчиков от их основных задач и крайне отрицательно сказывается на процессе разработки. Поэтому, команда разработки должна проявить некоторую твердость в этом вопросе и даже при поступлении вопросов от важных клиентов не принимать их к рассмотрению, а направлять в соответствующий офис поддержки.

Задачи, которые должна выполнять команда проекта для обеспечения процесса поддержки, следующие:

1. Предоставить центральному офису доступ к документам, позволяющим сформировать описание изменений, протекающих в проекте.
   
2. Обеспечить уведомление сотрудников центрального офиса поддержки о результатах решения вопросов, поступивших от них.
   
3. Обеспечить центральному офису помощь в решении тех вопросов, которые требуют вмешательства разработчиков.

Обобщение

На следующей диаграмме показано как уменьшается поток вопросов от клиентов до команды разработки.

Основная задача такой организации – минимизировать нагрузку на команду разработчиков и позволить клиентам получать поддержку как можно быстрее. Цветом на диаграмме обозначено, насколько желательными должны быть коммуникации по поддержке. Зеленым выделен региональный уровень – здесь коммуникации являются наиболее желательными. Желтым цветом – уровень центрального офиса поддержки – к нему должны поступать только сложные вопросы. Красным цветом – команда разработчиков – к ней проблемы поддержки должны поступать в исключительных случаях. Все это позволяет распределить нагрузку по поддержке клиентов оптимальным образом.

Я с радостью рассмотрю любые комментарии и вопросы по данной тематике.

Мои координаты доступны на сайте www.msmirnov.ru

Михаил Смирнов
Руководитель проектов.

Здесь я привожу текст статьи "Технологии Push и Pull при работе с linked servers в Microsoft SQL Server", опубликованной в 354 номере рассылки MS SQL Server - дело тонкое 22 апреля 2007г. http://www.sql.ru/subscribe/2007/354.shtml#20

Технологии Push и Pull при работе с linked servers в Microsoft SQL Server

Для обеспечения взаимодействия нескольких серверов Microsoft SQL Server наиболее часто используется технология linked-серверов. При этом, типичной является задача обмена данными между linked-серверами. В данной статье я проведу краткий сравнительный анализ технологий push и pull для решения задачи передачи новых данных.

Провести такой анализ проще всего на примере. Пусть у нас есть два сервера – сервер-источник (SourceServer) и целевой сервер (DestServer). В качестве примера рассмотрим задачу, когда нам необходимо передать таблицу Customers c сервера-источника на целевой сервер.

Технология Push

Технология Push характеризуется “заталкиванием” данных с исходного сервера на целевой сервер. Т.е. SQL-запрос для передачи таблицы Customers будет выполняться на исходном сервере и выглядеть так:

insert into DestServer.Northwind.dbo.Customers
select *
from Customers

Для того, чтобы понять, как такой запрос будет обработан SQL Server’ом, необходимо воспользоваться SQL Server Profiler.
На исходном сервере запрос выполняется в неизменном виде –

insert into DestServer.Northwind.dbo.Customers
select top *
from Customers
go

Однако, на целевом сервере все совсем не так. На нем выполняются следующие запросы -

set implicit_transactions on 
go

declare @P1 int
set @P1=1
declare @P2 bigint
set @P2=8400823175122854
exec sp_getschemalock @P1 output, @P2 output, 
N'"Northwind"."dbo"."Customers"'
select @P1, @P2
go

declare @P1 int
set @P1=180150000
declare @P2 int
set @P2=2
declare @P3 int
set @P3=4
declare @P4 int
set @P4=-1
exec sp_cursoropen @P1 output, 
N'select * from "Northwind"."dbo"."Customers"', 
@P2 output, @P3 output, @P4 output
select @P1, @P2, @P3, @P4
go

exec sp_cursor 180150000, 4, 0, 
N'Northwind.dbo.Customers', 
@CustomerID = N'ALFKI', 
@CompanyName = N'Alfreds Futterkiste', 
@ContactName = N'Maria Anders',
@ContactTitle = N'Sales Representative', 
@Address = N'Obere Str. 57', 
@City = N'Berlin', 
@Region = NULL, 
@PostalCode = N'12209', 
@Country = N'Germany', 
@Phone = N'030-0074321', 
@Fax = N'030-0076545'
go

exec sp_cursor 180150000, 4, 0, 
N'Northwind.dbo.Customers', 
@CustomerID = N'ANATR', 
@CompanyName = N'Ana Trujillo Emparedados y helados', 
@ContactName = N'Ana Trujillo', 
@ContactTitle = N'Owner', 
@Address = N'Avda. de la Constitucion 2222', 
@City = N'Mexico D.F.', 
@Region = NULL, 
@PostalCode = N'05021', 
@Country = N'Mexico', 
@Phone = N'(5) 555-4729', 
@Fax = N'(5) 555-3745'
go

exec sp_cursor 180150000, 4, 0, 
N'Northwind.dbo.Customers', 
@CustomerID = N'ANTON', 
@CompanyName = N'Antonio Moreno Taqueria', 
@ContactName = N'Antonio Moreno', 
@ContactTitle = N'Owner',
@Address = N'Mataderos  2312', 
@City = N'Mexico D.F.', 
@Region = NULL, 
@PostalCode = N'05023', 
@Country = N'Mexico', 
@Phone = N'(5) 555-3932', 
@Fax = NULL
go

exec sp_cursorclose 180150000
go

IF @@TRANCOUNT > 0 COMMIT TRAN
Go

set implicit_transactions off 
go

Видно, что при вставке на удаленный сервер, SQL Server выполняет следующие операции:

• Открывает распределенную транзакцию, включая режим неявных транзакций.

• Открывает курсор и вставляет записи последовательно одну за другой, а не все сразу, как в случае обычной вставки, без использования linked-серверов.

Последовательную вставку каждой записи также можно заметить, если на целевом сервере создать триггер на INSERT – триггер будет срабатывать столько раз, сколько записей существует во вставляемом наборе.
Для примера – следующий триггер на таблице Customers:

CREATE TRIGGER dbo.I_Customers
   ON  dbo.Customers
   AFTER INSERT
AS 
BEGIN
	declare @InsertedCount int, @TotalRows int
	select @InsertedCount = count (*) from inserted
	select @TotalRows = count (*) from Customers

	insert into CallsCount (InsertedCount, TotalRows)
	values (@InsertedCount, @TotalRows)
END

В этом триггере CallsCount - это вспомогательная таблица, которая поможет подсчитать сколько раз триггер был запущен. Она содержит два поля – InsertedCount – кол-во записей в таблице inserted и TotalRows – общее кол-во записей в таблице Customers на момент срабатывания триггера.
После выполнения предыдущего запроса на вставку выборка из таблицы CallsCount дает следующий результат:

Здесь видно, что триггер был вызван 3 раза. При этом каждый раз в таблице inserted была одна запись, а кол-во записей в таблице Customers увеличивалось постепенно. Это еще раз доказывает то, что записи вставляются последовательно, одна за одной.

Можно провести интересный эксперимент, изменив триггер следующим образом:

ALTER TRIGGER dbo.I_Customers 
   ON  dbo.Customers
   AFTER INSERT
AS 
BEGIN
	declare @InsertedCount int, @TotalRows int
	select @InsertedCount = count (*) from inserted
	select @TotalRows = count (*) from Customers

	insert into CallsCount (InsertedCount, TotalRows)
	values (@InsertedCount, @TotalRows)

	if @TotalRows = 3
		rollback tran
END

Т.е. таким образом можно как бы попытаться откатить вставку третьей строки. Однако, после запуска запроса на вставку, при наличии такого триггера, обе таблицы – Customers и CallsCount будут пустыми – в них не будет не только третьей записи, но и вообще ни одной.
Причина этого видна в перехваченной последовательности запросов - SQL Server объявляет распределенную транзакцию. Вызывая rollback tran в триггере мы откатываем не только данный триггер, но и всю транзакцию вставки. Это, вообще говоря, логично, так как при этом работа триггера выглядит так же как и при вставке не из удаленного сервера, с той лишь разницей, что вызывается он несколько раз. Именно для обработки таких ситуаций SQL Server и объявляет распределенную транзакцию. Побочным эффектом такой транзакции является длительная блокировка таблицы Customers на целевом сервере на все время вставки.
Все эти эффекты не имеют важного значения, если между серверами передаются небольшие объемы данных. Однако, последовательная вставка курсором большого кол-ва записей может занимать довольно длительное время, добавляя ко всему прочему блокировку таблиц на все это время. В качестве примера можно попробовать передать большой справочник, состоящий примерно из 130 000 строк.

insert into DestServer.Northwind.dbo.Dictionary
select *
from Dictionary

На тестовом сервере это привело к 130 000 запросам на вставку и заняло примерно 370 секунд. В дальнейшем это значение будет сопоставлено с результатами работы технологии Pull.

Технология Pull

При использовании технологии pull запрос на вставку данных выполняется на целевом сервере. При этом происходит «втягивание» данных от сервера-источника.
Такой запрос, выполняющийся на целевом сервере, выглядит так:

insert into Customers
select *
from SourceServer.Northwind.dbo.Customers

Если воспользоваться SQL Server Profiler, то на целевом сервере он будет выполняться в неизменном виде -

insert into Customers
select *
from SourceServer.Northwind.dbo.Customers
go

На сервере-источнике при этом будет выполнен следующий запрос -

set implicit_transactions on 
go

declare @P1 int
set @P1=1
declare @P2 bigint
set @P2=8381016049028902
exec sp_getschemalock @P1 output, @P2 output, 
N'"Northwind"."dbo"."Customers"'
select @P1, @P2
go

declare @P1 int
set @P1=2
exec sp_prepexec @P1 output, NULL, 
N'SELECT Col1028,Col1027,Col1026,Col1025,Col1024,
Col1023,Col1022,Col1021,Col1020,Col1019,Col1018 FROM 
(SELECT Tbl1001."CustomerID" Col1018,
        Tbl1001."CompanyName" Col1019,
        Tbl1001."ContactName" Col1020, 
        Tbl1001."ContactTitle" Col1021,
        Tbl1001."Address" Col1022, 
        Tbl1001."City" Col1023,
        Tbl1001."Region" Col1024,
        Tbl1001."PostalCode" Col1025,
        Tbl1001."Country" Col1026,
        Tbl1001."Phone" Col1027,
        Tbl1001."Fax" Col1028 
 FROM "Northwind"."dbo"."Customers" Tbl1001) Qry1029'
select @P1
go

exec sp_unprepare 2
go

exec sp_releaseschemalock 1
go

IF @@TRANCOUNT > 0 ROLLBACK TRAN
Go

set implicit_transactions off 
go

Здесь видно, что при такой технологии курсор не используется. Вместо этого применяется пакетная вставка записей – всех за один раз. Это же доказывает нам и использование триггера. После выполнения запроса таблица CallsCount содержит всего одну запись -

Из этого также видно, что в запрос выполнялся всего один раз, в таблице insterted было 3 записи и в саму таблицу Customers также было вставлено 3 записи.

insert into Dictionary
select *
from SourceServer.Northwind.dbo.Dictionary

Если попытаться замерить время, которое сервер тратит на вставку записей таким образом на примере большого справочника из 130 000 строк, то следующий запрос на том же сервере выполняется 30 секунд, что в 12 раз быстрее, чем при использовании технологии Push.

Сравнительные данные

В следующей таблице приведены сравнительные данные этих двух технологий

Заключение

Из всего вышесказанного следует, что технология pull обеспечивает более высокую производительность, чем технология push и является более предпочтительной.

Я с радостью рассмотрю любые комментарии и вопросы по данной тематике.

Мои координаты доступны на сайте www.msmirnov.ru

Михаил Смирнов
Руководитель проектов.