Учебник по созданию shareware программ

         

Рассылка регистрационных ключей



Рассылка регистрационных ключей

В конференциях, посвященных shareware, часто задают вопрос — как лучше всего рассылать регистрационные ключи: самостоятельно или поручить это регистраторам?

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

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

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

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

Если же автору shareware-продукта нужно, чтобы ключи высылались не из статического списка, а генерировались по имени пользователя, которое было указано при заказе, то, если регистратор поддерживает такую возможность, ее реализация тоже может устраивать не всех. Например, начинающему разработчику, программирующему на Visual Basic, не подойдет предложение предоставить кодогенератор в виде DLL-библиотеки (функция получает имя пользователя, возвращает код) или консольной программы под DOS (имя передается как параметр, код отправляется в текстовый файл или стандартный output) — так, в частности, организована поддержка кодогенераторов на RegSoft и Sharelt!. Скорее всего, рассылка регистратором ключей, генерируемых по имени пользователя, не устроит и тех shareware-разработчиков, которые для защиты своих программ используют специализированные пакеты третьих фирм, ведь алгоритм генерации регистрационных ключей в данном случае закрыт.

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

First Name: Great Last Name: Satan



Address 1: 666 hell drive

City: Hell

Country: USA

Phone: 666-6666-666

Email Address: hzds@hotmail.com

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

Некоторые регистраторы преподносят разработчикам еще один "сюрприз". Они не высылают покупателю регистрационный номер, а просто показывают его на странице. Если регистратор работает именно так — лучше посылать номер самостоятельно или выбрать другого регистратора. Многие покупатели этот номер просто не замечают, не записывают или записывают, но с ошибками. Это доставляет разработчику много хлопот и неприятностей - пользователи начинают сердиться, предъявлять автору претензии, обвинять в обмане, требовать вернуть деньги.

После описания всех этих недостатков в реализации рассылки регистрационных ключей различными компаниями-регистраторами может создаться впечатление, что найти регистратора, имеющего удовлетворительный сервис по рассылке ключей, невозможно. Конечно, это не так. Например, известнейшая компания RegNow (http://www.regnow.com), по отзывам, замечательно справляется с рассылкой ключей, в том числе и при довольно больших объемах продаж (несколько десятков регистрации в день), выполняя требования, указанные ранее (большие списки номеров, каждый покупатель получает уникальный ключ, отправка писем, текст которых определен разработчиком и т. д.). Проверка на фрауды при этом проводится довольно поверхностная, однако, если ее ужесточить, это вызывает недовольство клиентов. Но даже при такой простой проверке на фрауды число последних относительно невелико — 2—3% от общего числа регистрации. Если "прошивать" ключи, полученные по фраудам, внутри ЕХЕ-файла программы, чтобы эти ключи не могли разблокировать закрытые в незарегистрированной версии функции, и менять дистрибутив на сервере программы, то фрауды не приносят ощутимого ущерба продажам продукта.

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

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

Соответственно, недостатки ручной рассылки ключей состоят в следующем:

  • обработка уведомлений о заказах и подготовка писем с регистрационными ключами занимает дополнительное время, что может быть очень существенно при большом объеме продаж;
  • автор программы не может высылать ключи так же быстро, как регистратор;
  • если автор работает в одиночку, то у него могут возникать проблемы с рассылкой ключей — например, если он уехал в отпуск или случились какие-то неполадки у провайдера, обеспечивающего выход в Интернет. Пользователи, оплатившие программу, но не дождавшиеся ключа, могут предъявить автору претензии и потребовать вернуть деньги. Какой способ организации рассылки ключей все-таки предпочтителен? Однозначно ответить па этот вопрос нельзя. Каждый разработчик выбирает то, что его устраивает, исходя из особенностей распространяемых им продуктов, своих личных потребностей, объема продаж, собственного расписания дел и т. д.


Содержание раздела