UML – быстрый старт

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

1.     Введение.

UML – это Unified Modeling Language, как следует из названия – унифицированный язык моделирования. UML представляет собой набор соглашений, которые предназначены для облегчения процесса моделирования и обмена информацией в проектной группе. Наличие стандартизированной нотации позволяет сократить время на усвоение информации, упрощает общение и взаимодействие, облегчает документирование.

В этом документе описаны самые основные разделы языка UML, которые потребуются в повседневной работе.

2.     Основы.

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

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

3.     Описание типов диаграмм.

3.1.          Диаграмма вариантов использования (Use-case diagram).

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

Основными понятиями при работе с диаграммой вариантов использования являются Актор (Actor) и Вариант использования (Use case).

Актор – это роль, которую выполняет пользователь или другая система, при взаимодействии с проектируемой системой.

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

Каждый Актор обладает уникальным именем.

Друг с другом акторы могут быть связаны различного рода отношениями.

Например, акторы могут наследоваться друг от друга.

Это означает, что акторы-наследники наследуют характеристики базовых акторов.

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

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

Вариант использования обозначается значком:

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

Например:

означает, что актор User инициирует вариант использования Login.

Один и тот же вариант использования может использоваться несколькими акторами, например:

вариант использования Login используется двумя акторами.

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

1.       «Включение» одного варианта использования в другой. Означает, что один вариант использования инициируется в процессе другого. Например:

2.       «Расширение».  Означает, что один вариант использования является дополнением или уточнением другого варианта использования в случае наступления некоторых условий. Например:

3.       «Реализация». Означает, что один вариант использования является реализацией другого варианта использования. Например, если один из них описан в терминах бизнес-процессов, а другой – в терминах проектируемой системы.
Например:

Кроме того, варианты использования могут быть связаны отношением «Реализация» с требованиями к системе и с классами. При наличии таких связей есть возможность проследить в каких классах реализованы требования и какие классы могут быть затронуты при изменении требований или вариантов использования.
Например:

Кроме Акторов и Вариантов использования на диаграмме также могут находиться следующие элементы:

“Collaboration” – элемент, предназначенный для визуальной группировки объектов – акторов и вариантов использования – по принципу их совместной работы.
Обозначается значком

Например,

«Boundary» - элемент, предназначенный для визуальной группировки объектов – акторов и вариантов использования – по принципу их распределения на подсистемы или компоненты.

Обозначается значком

Например:

Среди акторов могут быть не только пользователи, но и внешние системы и внутренние подсистемы.

Пример внутренней подсистемы:

3.2.                     Диаграмма последовательностей (Sequence diagram)

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

Иными словами, если вариант использования отвечает на вопрос «Что делает актор?», то последовательность отвечает на вопрос «Как работает система при выполнении данного варианта использования?».

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

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

Проще всего продемонстрировать суть диаграммы последовательностей на примере:

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

На самой диаграмме показаны линии жизни каждого из объектов и процесс их взаимодействия.

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

Кроме сообщений, которые вызываются другими объектами, существуют собственные сообщения, которые объект вызывает сам у себя (Self-message).

Например:

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

Например:

На этой диаграмме метод возвращает результаты своей работы.

Собственные сообщения также могут быть обратными.

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

Сообщения могут объединяться в комбинированные фрагменты (Combined fragment), который предназначен для отображения циклов, ветвлений, критических секций и пр.

Пример ветвления:

Пример цикла:

Некоторые сообщения могут заканчиваться Конечными точками (End point), которые означают выход из алгоритма.

Пример:

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

Например:

3.3.                     Диаграмма классов

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

Так же как и предыдущие диаграммы она может быть представлена как в терминах конкретных классов, так и в терминах бизнес-объектов.

Диаграммы классов обычно заполняются параллельно с диаграммами последовательностей в процессе моделирования работы вариантов использования.

Основным элементом диаграммы классов является класс.

Обозначается значком:

Класс состоит из двух частей – заголовка с именем класса и тела с описанием его полей (Атрибуты – в терминах UML) и методов (Операции - в терминах UML).

Абстрактные классы отличаются наклонным написанием заголовка:

Под атрибутами класса в терминологии UML понимают его поля.

Атрибуты записываются с указанием доступности, имени и типа.

Например:

Знак «-» означает, что атрибут является приватным (private).

Знак «+» означает, что атрибут является публичным (public).

Знак «#» означает, что атрибут является защищенным(protected).

После имени следует указание типа атрибута.

Под операциями в терминологии UML понимаются методы, свойства, индексаторы и пр.

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

Например:

Статические атрибуты и операции записываются с подчеркиванием, например:

Абстрактные методы записываются наклонным шрифтом, например:

Кроме классов, важным элементом диаграмм классов являются интерфейсы.

Интерфейс обозначается так:

Кроме классов и интерфейсов на диаграмме классов также могут помещаться перечисления.

Перечисление обозначается так:

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

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

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

Генерализация или наследование (Generalize) обозначается так:

На примере показано, что два класса являются наследниками абстрактного класса.

Реализация (Realize) – означает, что данный класс реализует данный интерфейс:

Ассоциация (Associate). Наиболее широко используемая связь между классами. Она имеет достаточно широкое значение и может означать, например, следующее:

1.       Один класс осуществляет взаимодействие с другим каким-либо образом.
Например:

2.       Один класс включает в себя экземпляр другого класса.
Например:

Видим, что перечисление Status включено в класс User, при этом имя поля Status, с областью видимости public.

3.       Один класс включает в себя несколько экземпляров другого класса.
Например:

Видим, что коллекция UsersCollection может включать от нуля до бесконечности объектов User.
Возможные значения количества объектов:

·         «*» или «0..*» - любое количество объектов

·         «0..n» - любое количество объектов, но не больше n, например «0..5»

·         «n» - точное количество объектов, например «1», «5»

·         «n..*» - любое количество объектов, но не меньше n, например«1..*» - хотя бы один.

Если Ассоциация не может быть реализована без дополнительных классов (например, отношение «многие-ко-многим»), то она реализуется при помощи дополнительных классов ассоциации, которые предназначены решить эту задачу.
Обозначается это следующим образом:

В данном примере вы видите, что для того, чтобы установить связь «многие-ко-многим» между переводчиками (класс Translator) и языками (класс Language) используется вспомогательный класс TranslatorToLanguage.

Композиция (Compose)  - означает, что объекты одного класса могут быть включены в объекты другого класса и при этом этот вложенный объект может находиться только в одном объекте-контейнере. Если объект контейнер удаляется, то вложенный объект тоже удаляется.

Например:

Агрегация (Aggregate) - означает, что объекты одного класса могут быть включены в объекты другого класса и при этом этот вложенный объект может находиться в нескольких объектах-контейнерах. Если объект контейнер удаляется, то вложенный объект не удаляется.

Например:

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

1.       Класс-сущность (Entity) – обычно применяется для обозначения классов, которые хранят некую информацию о бизнес-объектах.
Обозначается:

2.       Класс-контроллер (Controller) – обычно используется для классов, которые используются для выполнения некоторых операций над объектами.
Обозначается:

3.       Класс-Разграничитель (Boundary) – обычно используется для классов, отделяющих внутреннюю структуру системы от внешней среды. Это могут быть WebServices, пользовательский интерфейс и пр.
Обозначается:

3.4.          Диаграмма коммуникаций

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

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

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

Проще всего привести описание диаграммы коммуникаций на примере:

На примере видим, что актор User взаимодействует с экземпляром страницы LoginPage, который в свою очередь работает с классом SecutiryManager, который оперирует объектами типа User.

Элементы диаграммы коммуникаций могут быть связаны отношением «Ассоциация». Как я уже указывал выше Ассоциация имеем достаточно широкое значение и может трактоваться по разному (см. Диаграммы классов).

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

Например:

3.5.          Диаграммы состояний. (State diagram или State Machine)

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

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

Диаграммы состояний состоят из элементов двух основных типов: Состояний и Переходов.

Элемент Состояние (State) отображает состояние объекта или процесса в какой-либо момент времени.

Обозначается значком:

Название Состояния является его описанием, т.е., например, состояние

означает, что пользователь находится в «незалогиненном» состоянии.

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

Например:

Для обозначения начала и конца всего процесса переходов используются псевдо-состояния: Инициирующее (Initial)

и Финализирующее (Final)

Применятся они могут, например, так:

Если Состояние сопряжено с некоторой деятельностью, то это тоже отображается на диаграмме.

Например:

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

Например:

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

Другой вариант того же самого примера:

Этот пример отличается от предыдущего тем, что после ввода неверных данных пользователю больше не предлагается ввести свои данные.

Переход также может осуществляться между одним и тем же состоянием.

Например:

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

При этом контекст Суперсостояния является актуальным для всех элементов, находящихся внутри этого Суперсостояния.

Например:

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

Например:

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

Например (из книги Фаулера):

Если несколько параллельных потоков переходов должны быть синхронизироваться в какой-то момент, то для это используется псевдо-состояние Synch

Существует также дополнительный элемент Fork/Join – используется для разбивки или объединения нескольких потоков состояний.

Например:

3.6.          Диаграммы деятельности. (Activity diagram)

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

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

Основным объектом диаграмм активностей является Активность (Activity), которая обозначается следующим значком:

Диаграммы активностей имеют те же элементы, что и диаграммы состояний, а именно: псевдо-активности начала и конца потоков, переходы, Fork/Join, Суперактивности.

Пример:

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

Кроме того, на этой диаграмме присутствует новый элемент Решение (Decision) –

Этот элемент знаком нам по блок-схемам и обозначает момент ветвления или соединения потоков.  Отличие от Fork/Join состоит в том, что процесс продолжается только по одной ветке, в то время как после Fork/Join – по всем веткам параллельно.

Существенным дополнением диаграммы деятельности является элемент Partition, который сам по себе логического значения не имеет и предназначен для визуальной группировки работ по какому-либо признаку.

Обозначается значком:

Например:

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

Кроме обычных активностей, есть несколько дополнительных:

1.       Отправка (Send) – используется для отображения запросов к каким-либо внешним источникам.
Обозначается:

2.       Получение (Receive) – используется для получения информации от каких-либо внешних источников.
Обозначается:


Например:

4.     Пакеты (Packages)

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

Обычно пакеты представляют собой:

·         подсистемы, если речь идет о системе

·         компоненты или слои, если речь идет о классах

·         наборы бизнес-логики, если речь идет о вариантах использования и т.п. 

Конкретный способ группировки элементов в пакеты остается на усмотрение проектировщика.

Пакет обозначается следующим образом:

Например, может существовать пакет Акторов -

в котором находятся диаграммы с перечнем Акторов.

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

Например:

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

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

08Здесь я привожу копию моей статьи "Как связать продажи и источники трафика. Weighting", опубликованной на сайте SeoNews (http://www.seonews.ru/masterclasses/detail/29891.php)

1. Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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). Поэтому для того чтобы верно сопоставить продажи с затратами, вам потребуется предварительно перевести время ваших продаж во время поисковой системы. Обратная операция (т.е. перевод времени затрат в ваше время) невозможна, так как поисковые системы не предоставляют отчеты в почасовой разбивке.

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

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

Для определения системы и поискового запроса необходимо знать, какими 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, так как по ним не производится никаких затрат. Поэтому единственные показатели, которые можно посчитать – это объем и количество продаж.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6. Weighting

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

Пример 1.

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

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

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

Пример 2.

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

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

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

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

Пример 3.

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

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

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

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

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

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

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

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

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

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

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

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

	Привязка
	По сесcиям	Weighting
Первая продажа	Первое ключевое слово	Первое ключевое слово
Вторая продажа	Второе ключевое слово	Первое и второе ключевые слова
Третья продажа	-	Первое и второе ключевые слова

		Объем продаж		ROI
	Затраты	По сесcиям	Weighting	По сесcиям	Weighting
Первое ключевое слово	$50	$100	$100+$200/2+$300/2=$350	100%	600%
Второе ключевое слово	$70	$200	$100+$300/2=$250	186%	257%
Итого	$120	$300	$350+$250=$600	150%	400%

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

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

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

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

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

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

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

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

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

7. Заключение

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

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