Nadiske.ru / MakeCD.ru

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

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

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

За eManual двинулись и другие сайты с хорошим контентом и не менее хорошим посещением: Opennet.ru, Accords.Ru, Shema.Ru, Good-Cook.Ru, eSpot.ru, Void.Ru, 3DNews.Ru, Algolist.Manual.Ru и другие. С их владельцами мы находили совершенно разные взаимовыгодные варианты по раскрутке продаж. Деньги, к слову, не везде были определяющим фактором.

Где-то в середине этого пути наши пути с партнером разошлись - за ним осталась доля в проекте, но все технические и организационные решения я принимал уже единолично. По правде говоря, можно долго спорить, хорошее это было решение или нет, но проект к тому времени нам обоим уже немного поднадоел - ничего кардинально нового мы в него привнести не смогли. Домен MakeCD.Ru было решено отпустить, я зарегистрировал домен nadiske.ru. Концепция нового магазина включала идею - каждому партнеру по сайту третьего уровня. Так появились Emanual.nadiske.ru, opennet.nadiske.ru и т.д.

Схема, по которой мы работали, была следующей. Как я уже сказал, каждому из наших партнеров мы высылали уникальную ссылку, состоящую из идентификатора партнера в качестве домена третьего уровня над nadiske.ru. По этой ссылке открывалась версия списка <товаров>, в которой товар партнера был выделен большой галочкой и оставалось нажать только кнопку <Заказать>. Разумеется, никто не запрещал пользователю выделить еще и другие товары, и это было частью концепции.

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

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

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

К закрытию проекта в нем насчитывалось 54 <лота> и все они были уникальными продуктами, не продающимися нигде больше в Интернете и постоянно и статично рекламируемыми на более чем 15 сайтах-партнерах.

Еще одной концепцией было минимизация и упрощение процесса заказа. В магазине не было разделов и категорий, поиска и остального, к чему мы привыкли. Все 54 лота размещались на одной странице, этакой простыне, килобайт 150 весом. Они были сгруппированы по названию товара, так что принципиально отличных товаров насчитывалось около 20. Около каждого товара стоял чекбокс-переросток, выполненный на javascript. Внизу в нижнем фрейме постоянно жила кнопка <Заказать>, отправлявшая пользователя на страницу ввода собственных данных. Сайт мог работать как с фреймами, так и с их имитацией, так что с совместимостью проблем тоже не было. Единственной серьезной проблемой было то, что javascript порой слишком рано обращался к соседнему фрейму за данными и приходилось долго ловить эту ошибку - она возникала при определенной скорости загрузки страниц.

Интересной находкой была система подтверждения заказа. Я ее как-то писал в Артстайле, реализуя очередную собственную идею Mail-to-web. Для нее придумалось даже маркетинговое название ActiveMail, но, похоже, сейчас его никто не двигает.

Принцип у нее следующий - при приходе письма на определенный е-майл, система перехватывает письмо, анализирует его и выделяет из него основные составляющие - е-майл отправителя, тему, собственно текст письма, приложенные файлы и др. Далее система производила обращение к скрипту уже на другом сервере, передавая ему в качестве CGI-переменных указанные элементы письма. Скрипт мог делать все что угодно - например, класть тему письма в БД заголовком новости, а содержимое письма - телом новости. Дополнительной возможностью было выделение из текста письма а-ля XML-конструкций и преобразования их в вид <переменная=значение> для передачи вместе с прочими заголовками письма скрипту в качестве переменных CGI.

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

То есть последовательность была следующая:

1. Пользователь производил заказ в магазине, оставляя свой е-майл
2. Магазин направлял на этот е-майл письмо-подтверждение со сгенерированным 16-значным идентификационным кодом покупателя. Обратным адресом указывался адрес автоматической обработки почты.
3. Покупатель мог перейти по ссылке в письме - так сделано у всех, а мог просто ответить на письмо - так сделано только у нас.
4. Если он отвечал на письмо, оно шло на другой сервер - на котором стоял ActiveMail.
5. ActiveMail получал письмо, по адресу получателя определял аккаунт, заглядывал в связанные с этим аккаунтом настройки, в частности, какой URL вызывать и каким методом ему передавать данные (GET/POST) и выполнял этот запрос. В нашем случае он вызывал скрипт, изменяющий статус товара у пользователя с указанным идентификатором. Заказ сразу становился <новым> из <временного>.

Сбоев быть не могло - если в систему пользователь ответил пустым письмом или письмом без 16-значного кода, ему в ответ система высылала соответствующее диагностическое сообщение.

Итак, заказы получены и помещены в локальную базу. Одним из отчетов в Microsoft Access был отчет <новые заказы>. В нем были адреса наших заказчиков, подтвердивших свои заказы. Сначала мы делали все сами и я помню, я сначала искал по Москве где купить картон, которым следовало прокладывать с обоих сторон диски, чтобы они в дороге не ломались, а затем мы с женой резали его ножницами на аккуратные (и не очень аккуратные) кусочки. К каждому заказу вручную оформлялись несколько сопровождающих документов, без которых почта не может отправить диски наложенным платежом. Бланки под такие документы брались на почте пачками, причем, если с описями проблем не было, то с бланками наложенного платежа были накладки - на почти они всегда быстро заканчивались. В таком <сыром> состоянии мы развозили пакеты, состоящие из дисков, картонных обкладок и комплекта документов по нескольким почтовым отделениям, где нам их упаковывали и отсылали адресатам. Почте за такую работу, разумеется, доплачивали побандерольно.

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

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

Наши продукты тиражировались на CD-R. За время существования сервиса несмотря на тысячи записываемых дисков в промышленном режиме использовалось два привода CD-R, но они оба были и остаются в хорошем состоянии. Один из них и по сей день служит мне верой и правдой. Запись производилась нашей сотрудницей где-то два раза в неделю, чем поддерживались необходимые <складские запасы> - где-то по 10-15 дисков одного наименования в зависимости от спроса. Ни одного брака записи за это время не было, хотя, повторюсь, записаны тысячи болванок и запись шла в полупромышленном режиме. Было с десяток случаев за всю практику, когда по недосмотру отсылались незаписанные диски или совсем не то, что заказывал покупатель и, разумеется, такие ситуации решались повторной отсылкой с извинениями.

Проект закрылся и тому есть причины. Был налажен сбыт, но всякий товар, даже уникальный и актуальный, устаревает и требует постоянного обновления. Проект прожил почти два года в основном на тех продуктах, которые были созданы к его открытию. Все остальные продукты, появляющиеся за этот срок, поддерживали его на плаву, но не развивали. Чтобы сделать вторую революцию и повторить успех, надо было целиком обновить ассортимент. Например, провести повторно скачивание всей информации с сайтов партнеров, их обработку и создание полноценной, оттестированной оффлайн-версии. В начале проекта эти затраты никто не считал - для нас это было интересным, да и время было - сидели вечерами и ночами. А ведь в пересчете на стоимость потраченного времени это было весьма существенным вкладом. Вторично на такие подвиги никто из нас готов не был, а заказывать такие работы на стороне могло стоить проекту крахом. Последними шагами были попытки продавать то, что не требовало от нас каких-либо существенных усилий по созданию продукта, но добавляло в магазин разнообразие и ассортимент. Так появились дистрибутивы Linux, FreeBSD, архив CPAN, программное обеспечение для Unix, Windows CE. В результате проект стал постепенно сворачиваться и к 2004 году он прекратил свое существование.