Разработка интернет – магазина по продаже программного обеспечения

Оплата наложенным платежом

Оплачиваемая покупка при получении на почтовом отделении называется оплатой наложенным платежом. При оплате наложенным платежом, почта взимает 8% от стоимости заказа. Порядок оплаты такой:

1. на указанный адрес присылается заказ, либо заполняется определенная форма оплаты предложенная интернет - магазином.

2. указываются свои Ф.И.O., полный адрес с индексом, контактный телефон и e-mail.

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

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

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

1.4 Безопасность платежей в Интернете

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

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

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

Всюду далее под протоколом в интернет - торговле понимается алгоритм, определяющий порядок взаимодействия участников интернет - торговли (владельца карты, торгового предприятия, обслуживающего банка, банка - эмитента и центра сертификации[_]) и форматы сообщений, которыми участники интернет - торговли обмениваются друг с другом с целью обеспечения процессов авторизации и расчетов.

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

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

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

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

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

Действительно, использование PIN - кода должно производиться таким образом, чтобы этот секретный параметр на всех этапах обработки транзакции оставался зашифрованным (PIN - код должен быть известен только владельцу карты и ее эмитенту). В реальном мире это требование реализуется за счет использования в устройствах ввода транзакции специальных физических устройств, называемых PIN - PAD и содержащих Hardware Security Module - аппаратно-программные устройства, позволяющие хранить и преобразовывать некоторую информацию весьма надежным способом. Эти устройства хранят специальным способом защищенный секретный коммуникационный ключ, сгенерированный обслуживающим банком данного торгового предприятия. Когда владелец карты вводит значение PIN - кода, оно немедленно закрывается (шифруется) коммуникационным ключом и отправляется внутри авторизационного запроса на хост обслуживающего банка.

Точнее говоря, шифруется не сам PIN - код, а некоторый электронный "конверт", в который код помещается. На хосте обслуживающего банка зашифрованный идентификационный код перекодируется внутри Hardware Security Module хоста (хост обслуживающего банка также имеет свое устройство шифрования) в блок, зашифрованный на коммуникационном ключе платежной системы, и передается в сеть для дальнейшего предъявления эмитенту. По дороге к эмитенту PIN - код будет преобразовываться еще несколько раз, но для наших рассуждений это не важно. Важно другое - для того чтобы следовать классической схеме обработки PIN-кода, каждый владелец карты должен хранить криптограммы коммуникационных ключей всех обслуживающих банков, что на практике невозможно.

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

Существует другое, неклассическое решение по использованию PIN - кода. Например, можно на компьютере владельца карты шифровать PIN - код плюс некоторые динамически меняющиеся от транзакции к транзакции данные на ключе, известном только эмитенту и владельцу карты. Такой подход потребует решения задачи распределения секретных ключей. Эта задача является весьма непростой (очевидно, что у каждого владельца карты должен быть свой индивидуальный ключ), и если уж она решается, то использовать ее решение имеет смысл для других, более эффективных по сравнению с проверкой PIN - кода методов аутентификации владельца карты.

В то же время идея проверки PIN - кода была реализована для повышения безопасности транзакций в интернет -торговле по картам, БД которых хранится на хосте процессора STB CARD. В общих чертах STB CARD реализует следующую схему. Владельцы карт, эмитенты которых держат свою БД карточек на хосте STB CARD, могут получить дополнительный PIN - код, называемый ПИН2. Этот код представляет собой последовательность из 16 шестнадцатеричных цифр, которая распечатывается в PIN - конверте, передаваемом владельцу карты (специальный бумажный конверт, используемый банком - эмитентом для хранения в нем секретной информации, относящейся к эмитированной карте), и вычисляется эмитентом с помощью симметричного алгоритма шифрования, примененного к номеру карты и использующего секретный ключ, известный только эмитенту карты.

Далее во время проведения транзакции в интернет -торговле на одном из ТП, обслуживаемом банком STB CARD, у владельца карты в процессе получения данных о клиенте запрашивается информация по ПИН2. Клиент вводит значение кода ПИН2 в заполняемую форму и возвращает ее торговому предприятию.

Здесь нужно сделать важное замечание относительно сказанного ранее. Владелец карты в действительности ведет диалог в защищенной SSL - сессии не с торговым предприятием, а с виртуальным POS - сервером, через который работает торговое предприятие (система STB CARD в настоящее время использует сервер Assist).

Возвращаясь к схеме STB CARD, отметим, что, конечно же, в заполненной клиентом форме ПИН2 не содержится, а в действительности все выглядит следующим образом: ТП (точнее, сервер Assist), определив, что имеет дело с картой банка STB CARD, передает владельцу карты форму, содержащую подписанный Java - апплет, реализующий некоторый симметричный алгоритм шифрования. При этом ПИН2 играет роль секретного ключа этого алгоритма шифрования, а шифруемые данные получаются в результате применения хэш - функции к номеру карты, сумме и дате транзакции, а также случайному числу x, генерируемому торговому предприятию. Таким образом, в заполненной владельцем карты форме присутствует только результат шифрования перечисленных выше данных о транзакции на ключе ПИН2.

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

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

Таким образом, технология проверки PIN - кода, принятая в системе STB CARD, в действительности обеспечивает не только динамическую аутентификацию клиента, но еще и гарантирует "сквозную" целостность некоторых данных о транзакции (сумма транзакции, номер карты). Под "сквозной" целостностью здесь понимается защита от модификации данных на всем протяжении их передачи от клиента до банка - эмитента.

Минусы данного подхода состоят в следующем:

1. Для реализации схемы проверки значения PIN - кода необходимо, чтобы торговое предприятие "умело" формировать соответствующую форму с Java - апплет, что сразу сужает область применения схемы в относительно небольшом множестве торговых предприятий.

2. Использование длинного (шестнадцать шестнадцатеричных цифр) ключа делает его применение на практике крайне неудобным для владельца карты.

3. Защита от подставки (форма, запрашивающая ПИН2, предоставляется владельцу карты не торгового предприятия, а мошенником, желающим узнать значение ПИН2) основана на надежности аутентификации клиентом сервера торгового предприятия, а также на подписывании апплета секретным ключом сервера торгового предприятия. Поскольку нарушение обеих защит приводит только к появлению на экране монитора владельца карты соответствующего предупреждения, сопровождаемого вопросом - продолжить сессию или нет, то особенно доверять этим формам защиты не стоит.

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

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

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

2. Реквизиты платежной карты (номер карты, срок ее действия, CVC2/CVV2, и т. п.), используемой при проведении транзакции интернет - торговли, должны быть конфиденциальными для торгового предприятия.

3. Невозможность отказа от транзакции для всех участников транзакции интернет - торговли, то есть наличие у всех участников неоспоримого доказательства факта совершения покупки (заказа или оплаты).

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

Правовая база регулирования отношений интернет торговли в России достаточно невелика, отсюда и многочисленные факты мошенничества в Интернете и как следствие, недоверие людей к системам оплаты. В настоящее время законодательную базу составляют два таких основных закона как Федеральный закон «Об электронно-цифровой подписи» [-3] и Федеральный закон «Об электронной торговле»[-4]. Целью Федерального закон «Об электронно-цифровой подписи» является обеспечение правовых условий для использования электронной цифровой подписи в процессах обмена электронными данными, при соблюдении которых электронная цифровая подпись признается юридически равнозначной подписи физического лица, в том числе полномочного представителя юридического лица. Целью же Федерального закон «Об электронной торговле» является обеспечение правовых условий для электронной торговли: закрепление прав и обязанностей лиц, осуществляющих электронную торговлю, определение правил совершения сделок с использованием электронных документов, подписанных аналогами собственноручной подписи, а также признание электронных документов в качестве судебных доказательств.

1.5 Выводы

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

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

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

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

2 Разработка структуры построения электронного магазина

2.1 Архитектура электронного магазина

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

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

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

2.1.1 Разработка архитектуры интернет-магазина

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

Рисунок 2.1 - Архитектура интернет - магазина

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

В операционной части рассматривается среда разработки интернет магазина.

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

Разработка операционной части.

Предположительно интернет магазин разрабатывается в среде php. Для ответа обоснования выбора было произведено сравнение РНР с другими языками программирования Web-приложений. Это его основные конкуренты -- Perl, ASP.NET, ColdFusion и Java.

1. РНР и Perl

Язык Perl был создан программистом Ларри Уоллом (Larry Wall) и расшифровывается как Practical Extraction and Report Language. Перевести это можно как "язык для практического извлечения данных и составления отчетов". Perl является интерпретатором и появился намного раньше, чем Web. С появлением интернета язык Perl оказался удобным инструментом для создания динамических Web-страниц. Большое распространение Perl получил потому, что был доступен на каждом Web-сервере, поскольку практически все они работали под управлением UNIX, и альтернативой ему являлся лишь более сложный язык С.

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

2. РНР и Java

Вообще говоря, различают язык Java и технологию Java. Язык Java представляет собой С-подобный язык, который разрабатывался как "улучшенный C++". Технология Java включает в себя клиентскую и серверную часть, а также доступ к базам данных, поэтому наиболее корректно проводить сравнение технологии Java со связкой Apache/PHP/MySQL. Технология Java разрабатывалась как межплатформенная технология, позволяющая создавать Web-приложения корпоративного масштаба. Основными достоинствами этой технологии являются межплатформенная переносимость и объектно-ориентированный язык, что позволяет создавать сложные и объемные приложения. К числу недостатков можно отнести медленное выполнение, потребление большого количества памяти (плата за межплатформенную переносимость) и сложность разработки Web-приложений по сравнению с РНР. Между тем РНР почти не уступает Java в гибкости и масштабируемости созданных приложений. Кроме того, использование Java для разработки достаточно простых приложений вряд ли оправдано, а при работе над серьезными задачами Java обходится дороже.

3. РНР и ASP.NET

ASP (Active Server Pages) -- язык сценариев от Microsoft. Если язык ASP значительно уступал РНР по многим параметрам, в первую очередь, по времени выполнения сценариев, то с появлением технологии ASP.NET ситуация изменилась.

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

ASP.NET тесно интегрирован в новую технологию NET компании Microsoft. Главной особенностью разработки Web-приложений при помощи ASP.NET является возможность использовать любой язык программирования среды исполнения NET. Это может быть как модифицированный вариант Visual Basic -- Visual Basic.NET, так и новый язык С# или клон Java -- J#. Более того, в рамках одного Web-приложения могут быть использованы несколько языков программирования. Все это позволяет объединять в рамках одного проекта программистов, владеющих разными языками программирования. Код Web-приложения на ASP.NET компилируется в промежуточный язык MSIL (Microsoft Intermediate Language), иногда просто называемый IL. Аппаратно-независимый код на языке IL помещается в кэш Web-сервера для повышения производительности, по аналоги с байт-кодом Java. Но в отличие от технологии Java, обеспечивающей платформенную независимость, NET обеспечивает независимость от языка разработки. Выполнение Web-приложений ASP.NET на серверах, работающих не под Windows, практически невозможно. Более того, если Web-приложение интенсивно использует компоненты NET, просмотр динамической страницы будет возможен только под Windows и только с помощью браузера Internet Explorer. Поэтому в смысле переносимости РНР, безусловно, отличается от ASP.NET в лучшую сторону. Другой крайне немаловажный довод в пользу РНР заключается в быстром исправлении обнаруженных ошибок. Теоретически исправить их можно самостоятельно, если обладаете достаточной квалификацией. Также можно написать письмо разработчикам, и с большой долей вероятности, в следующей версии ошибка будет исправлена. А версии РНР выходят очень часто. С другой стороны, попробуйте написать об ошибке в Microsoft и попросить ее исправить. Если вы не глава Пентагона, вам это вряд ли удастся. Еще одним плюсом РНР, особенно важным для начинающих, является то, что его легче использовать для построения Web-приложений.

Таким образом, при выборе между ASP.NET и РНР следует исходить из стоящей задачи. Если в сети Интранет крупной корпорации большинство серверов и клиентских машин работают под управлением Windows, применение ASP.NET более чем оправдано. В то же время для разработки Web-сайта, размещаемого в Интернете, целесообразнее использовать РНР.

4. РНР и ColdFusion

Пакет ColdFusion разработан фирмой Allaire и предназначен для быстрой разработки как интерактивных, так и динамических Web-документов путем обработки информации, полученной из базы данных. Минусом ColdFusion является достаточно низкая переносимость. РНР работает практически на всех платформах, a ColdFusion -- только на четырех: Win32, Solaris, HP/UX и Linux. Кроме того, ColdFusion, так же как и ASP, является коммерческой разработкой. ColdFusion достаточно мало распространен. По сравнению с РНР он более требователен к ресурсам. Плюсом ColdFusion является хорошая интегрированная среда разработки и, как следствие, более простые, чем в РНР языковые конструкции и более быстрое написание кода. Правда, из-за такой высокоуровневости языка некоторые задачи на нем решаются сложнее.

5. Для создания интернет магазина была использована платформа PHP 4.0, а в дальнейшем планируется перейти на PHP 5.0, так как основные отличия заключаются в реализации объектно-ориентированной модели. РНР 4.0 работал на движке Zend Engine 1.0. К выходу РНР 5.0 фирма Zend полностью переписала движок и выпустила в свет Zend Engine 2.0, который, по словам создателей, реализует "новую объектную модель". По сравнению с РНР 4.0, в пятой версии языка появились следующие особенности:

1. Введены закрытые (private) и открытые (protected) члены и методы класса, а также абстрактные классы и методы.

2. Введены интерфейсы, при этом класс может реализовывать произвольный список интерфейсов.

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

4. Введены постоянные члены и методы класса.

5. Одним из важнейших нововведений является наличие деструкторов.

6. Хорошей новостью является введение в РНР 5.0 статических членов класса. В РНР 4.0, если возникала необходимость в использовании ста-тических членов, приходилось пользоваться искусственным приемом, за-ключающемся в комбинации глобальных переменных со статическими методами. При этом получались члены, которые действовали так же, как статические. Прием этот, мягко говоря, не очень хороший, поскольку привносил с собой все проблемы, связанные с использованием глобаль-ных переменных. Теперь в РНР 5.0 статические методы можно объявлять явно при помощи ключевого слова static.

7. В РНР 5.0 введен механизм обработки исключений, отсутствующий в РНР 4.0.

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

Разработка серверной части.

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

Слово "хостинг" произошло от англ. "hosting". (host - главная машина, хозяин)

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

Любой человек может без особых затруднений использовать как платные, так и бесплатные услуги. Как известно, бесплатный сыр бывает только мышеловке и в любом случае придётся платить. В первом (платном) варианте нужно расплачиваться деньгами, а во втором - качеством связи, ограничениями на размер файлов и рекламой, которая будет вывешена в магазине.

Как правило, на платном хостинге - домен будет выглядеть так: hostname.com/yourname, а на бесплатном - предоставляется субдомен и адрес будет выглядеть следующим образом: yourname.hostname.com

В последствии постараемся разместить магазин на платном хостинге в Российском интернете. Цены на именные домены «первого уровня» начинаются от 1-3 доллара в месяц, многое, конечно, зависит от провайдера предоставляющего хостинг.

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

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

Особенно большое распространение в Российском интернете партнерские/дилерские программы получили в сфере веб-хостинга, где и конкуренция в настоящее время значительно больше, чем, например, в электронной коммерции. Но и в других веб-услугах партнерские программы тоже постепенно получают все большее распространение. За рубежом, например, партнерские программы также получили очень широкое распространение и у туристических сайтов (особенно в сфере бронирования гостиниц; именно по партнерским программам различной сложности работают, например, такие крупные системы бронирования в Европе как SashaHotels.com или SunScale.com).

Одним из типичных примеров партнерских программ является программа крупнейшего российского интернет-магазина «Озон». Любой человек может разместить на своем сайте рекламу книг или кассет на «Озоне» со ссылкой на определенные страницы интернет-магазина с информацией по этим товарам. Если перешедший на «Озон» по такой ссылке посетитель приобретет данный товар, то партнер получит 12% от стоимости приобретенной данной книги или кассеты (а также 5% от стоимости остальных покупок, сделанных пользователем в течение этого визита на «Озон»). Заработанные таким образом средства можно затем использовать для покупок на самом «Озоне», либо (если процентные отчисления превышают 500 руб.) перевести на свой счет в банке. Партнеры могут разместить на своем сайте также форму поиска на «Озоне» либо его баннер (в этом случае процентные отчисления составляют 5% от суммы покупки).

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

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

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

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

Некоторое неудобство использования партнерских ссылок в том, что посетители могут заметить, что переходят не по прямой ссылке на сервер провайдера, а по партнерской. Для партнера же во многих случаях наиболее оптимальным было бы остаться «в тени», чтобы заказчик хостинга вообще не знал, что кто-то получил за его привлечение определенные проценты. Хотя стоимость заказа, что по партнерской программе, что напрямую, для клиентов обычно не отличается, тем не менее психологически российские пользователи не всегда положительно относятся к партнерам и часто встречаются отдельные индивидуумы, которые специально удаляют кукисы на компьютере перед заказом хостинга. Поэтому в последнее время получают распространение партнерские программы без специальных партнерских ссылок, когда сервер провайдера определяет партнера не по наличию его идентификатора в адресе, а просто по адресу сайта, с которого пришел посетитель. Такая схема реализуется технически несколько сложнее, зато она обеспечивает абсолютную анонимность партнера (если, конечно, потенциальный заказчик услуг хостинга перед заказом специально не просмотрит на своем компьютере кукисы). Так, без партнерских ссылок в настоящее время работает, например, партнерская программа хостинг-провайдера WebRider.ru, специальную ссылку можно не использовать также и в партнерской программе ATLEX'а (www.atlex.ru). Но у такого подхода есть и свой минус - если партнерские ссылки можно обычно проставлять где угодно, то без них - только на тех сайтах, которые зарегистрированы в партнерской программе у самого провайдера (чтобы потом можно было идентифицировать переход посетителя с определенного сайта как от партнера).

Самый существенный момент - это те проценты, которые получают партнеры за привлечение клиентов. Единой «таксы» в Российском интернете нет. В зависимости от провайдера партнер может получать от 5 до 50% от суммы заказа, средняя величина поощрения в Российском интернете в настоящее время составляет около 20%. Чаще всего партнеры получают именно проценты с продаж, но отдельные хостинг-провайдеры практикуют и фиксированную величину дохода в 5-20 долларов США в зависимости от величины заказа (по такой схеме функционируют, например, партнерские программы хостеров 350mb.ru, Majordomo.ru или Mastak.ru, а партнеры «Агавы» (www.agava.ru) могут выбрать как работу за проценты, так и за фиксированную плату за привлечение каждого клиента).

Некоторые провайдеры применяют более сложные схемы исчисления доходов по партнерским программам - за счет введения партнерства разного уровня. Процентные ставки для партнеров, привлекших разное количество клиентов, могут отличаться - в таком случае наиболее активные партнеры (привлекшие несколько десятков клиентов) работают по более выгодным условиям, чем их менее удачные коллеги. Например, у той же «Агавы» существует три уровня исчисления доходов в партнерской программе хостинга - 20% (до 5 клиентов), 25% (5-15 клиентов) и 30% (более привлеченных 15 клиентов). Другие провайдеры могут поощрять привлечение других партнеров и способствовать появлению реферальных сетей, в которых партнер «первого уровня» может получать некоторые проценты от прибыли, привлеченных им партнеров (т.е. партнеров «второго уровня») - такую схему практикуют, например, XP-Hosting.com и SpaceWeb (www.sweb.ru). Первый выплачивает до 20%, а второй - 10% суммарного ежемесячного заработка привлеченных партнеров.

Еще один существенный момент - то, как партнер может получить заработанные в рамках партнерской программы средства. Обычно хостинг-провайдеры предлагают два способа оплаты работы партнеров. Во-первых, как правило, существует возможность оплатить собственный хостинг у этого провайдера из заработанных средств (в этом случае партнера уже нужно рассматривать скорее как реселлера). Во-вторых, возможность вывода средств - например, на банковский счет или почтовым переводом, но чаще всего вывести средства, заработанные по партнерской программе можно только через системы интернет-платежей Webmoney (www.webmoney.ru), e-Gold (www.e-gold.com) или Яндекс.Деньги (money.yandex.ru). Именно так рассчитываются с партнерами, например, ValueHost и «Агава». Правда, т.к. провайдеры все-таки не заинтересованы в выводе средств партнерами, то они могут обставлять выплаты множеством различных условий. Например, у того же ValueHost'а перевод средств на WebMoney обставлен таким образом, что партнер неизбежно первые несколько раз оформит заявку на перевод средств неправильно, да и рассматриваются такие заявки в течение довольно долгого времени - так решение о переводе средств может приниматься в течение двух недель, а сам перевод может занимать вообще до 35 банковских (именно банковских, т.е. без учета выходных) дней. При этом оплата счетов хостинга на самом ValueHost'е со средств, заработанных по партнерской программе, осуществляется буквально за пару секунд.

Отдельные провайдеры могут вообще работать по старинке - т.е. к ним можно просто привести клиента за руку в офис. Такой вариант теоретически вполне возможен, например, в партнерских программах провайдера Highway.Ru. Соответственно и заработанные средства по партнерской программе у Highway.Ru тоже можно получать прямо в его офисе. Правда, Highway.Ru скорее ориентирован на работу по планам реселинга, чем партнерским программам.

Так же необходимо рассмотреть проблемы платного хостинга.

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

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

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

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

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

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

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

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

Отдельная история - поддержка CGI-скриптов. Под этим у разных провайдеров подразумеваются совершенно разные вещи. Если хостинг-провайдер заявляет о поддержке CGI-скриптов, то необходимо удостовериться, что в данный сервис входит не только возможность использования определенного стандартного набора уже установленных скриптов (обычно этот набор включает форум, гостевую книгу, чат, счетчики и т.д. - обычный набор сервисов и у серверов бесплатного хостинга), но и возможность использования собственных скриптов. Может быть существенным и то, поддерживается ли CGI в любой директории на сервере или только в специальной папке cgi-bin.

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

Выбор места для своего сайта всегда очень ответственное дело - от того, где и как будет располагаться сайт, зависит очень многое: и его посещаемость, и общий интерес пользователей, и, наконец, отдача (экономическая или просто психологическая в зависимости от тематической направленности ресурса и целей своего автора). С этой проблемой так или иначе сталкиваются любые создатели сайтов - как начинающие юзеры, так и «матерые» веб-мастера, программисты и IT-менеджеры. Конечно, для начинающего пользователя Интернета наиболее оптимальным местом для размещения своего персонального сайта являются различные сервера бесплатного хостинга. Но по мере развития такого интернет-проекта, его роста и перехода из любительской категории в профессиональную, сервера бесплатного хостинга перестают удовлетворять потребностям таких сайтов (точнее их владельцев). И дело не только в том, что на сайте вроде Narod.ru или Boom.ru постоянно что-то «глючит» или раздражают прикрепленные к сайту баннеры. Хотя и этого достаточно для того, чтобы перевести более или менее удачный интернет-проект на более качественный сервер хостинга. По большому счету к сервису бесплатного хостинга не может быть претензий, на то он и бесплатный хостинг, что ничего не гарантирует: ни отсутствие долгих промежутков времени, в течение которых сайт может быть просто недоступен, ни отсутствие рекламных баннеров, к которым владелец сайта не имеет никакого отношения. Сервера бесплатного хостера не гарантируют постоянного предоставления услуги и в любой момент могут изменить ее условия, очень часто это выражается либо введения обязательной рекламы на страницах сайтов пользователей, либо вообще к переходу со временем на коммерческую основу. Наибольший резонанс в Сети в отношении серверов бесплатного хостинга, как правило, вызывает постепенная коммерциализация предоставлемых услуг, которая происходит на протяжении последних 2-3-х лет как на Западе, так и в России. Если изначально большинство free-хостеров предоставляло абсолютно бесплатные услуги, то мере дальнейшего роста каждого проекта своего рода степень «халявности» предоставляемого сервиса обычно уменьшается.

Кроме того, большинство серверов бесплатного хостинга предоставляет довольно ограниченный набор сервисов, в которые, как правило, не входит поддержка различных скриптов (вроде CGI или PHP) и баз данных, необходимых для функционирования солидных интернет-проектов. Такие сервисы предоставляют преимущественно коммерческие хостинг-провайдеры. Хотя в последнее время появился и ряд бесплатных хостеров с поддержкой CGI/PHP/MySQL (например, Hut.ru, Hoha.ru, Webservis.ru), но в любом случае они не поддерживают собственный домен второго уровня. В конце концов, в определенный момент развития интернет-проекта становится понятно, что наличие в адресе сайта чего-то типа «chat.ru» или «narod.ru» просто несолидно.

Если для корпоративного пользователя, особенно крупного, кроме цена важна не только стоимость предоставляемых услуг и их набор, но и в первую очередь обеспечение бесперебойной работы сервера и вопросов безопасности (особенно в отношении физического хостинга), то для частного и массового пользователя на первом месте все-таки стоимость. Большинство потенциальных клиентов хостинг-компаний среди физических лиц - владельцы персональных сайтов на серверах бесплатного хостинга. Поэтому вряд ли владелец сайта, который недавно хостился бесплатно, готов платить в год существенно больше 100 долларов США.

Второй основной вопрос, который интересует пользователя при выборе хостера, это объем дискового пространства. Как показывает практический опыт, в 60-80% случаев для самого сайта «с лихвой» хватает 20-30 Мб, а для почты еще мегабайт десять. Но наиболее продвинутым пользователям (с использованием различных баз данных, большого количества графических материалов, для удаленного хранения файлов, создания индексируемой базы сайта для осуществления опции поиска и т.д.) может понадобиться и существенно больше места - вплоть до ста и более мега байт. Особенно в том случае, если хостинг нужен одновременно для нескольких сайтов. Поэтому объективно, размер дискового пространства, который устраивает массового пользователя, начинается примерно с 30-50 Мб. К тому же чисто психологически вчерашний пользователь бесплатного хостинга скорее ухватится за тот план, который по сравнению с другим, при равной стоимости предлагает большее дисковое пространство, а показатели надежности и безопасности, к которым в основном и аппелируют крупные хостинг-провайдеры, скорее всего при выборе провайдера окажутся отодвинутыми на второй план.

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

Фактически эти три критерия (цена/объем дискового пространства/поддержка скриптов) и есть тот базис, который предопределяет выбор пользователя в пользу той или иной компании, предоставляющей услуги хостинга. Остальные «навороты» уже играют более подчиненную роль. Хотя, например, неограниченный трафик тоже избавит пользователя от лишней головной боли. Ну и различные прочие «бонусы» (как например, скидки при заказе хостинга на год, бесплатный домен, партнерские программы и прочие маркетинговые акции) тоже нельзя не учитывать.

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