Архитектура и функционирование адресных баз данных

Вадим Черепанов, РИА «Арго Лайнс»

Сейчас много говорится о директ-маркетинге — его методах и особенностях применения, эффективности и т.д. Но значительно хуже освещаются технологии ДМ-акций: проблемы технического оснащения работ, логистики прохождения заказов, специализированного программного обеспечения. Может быть, это и не неинтересно клиенту, однако полезно самим ДМ-агентствам, ведь не секрет, что даже самые «крутые» бренды в интересных ДМ-акциях в техническом и организационном плане раскручиваются подчас «на коленке». Отчасти, это объясняется тем, что ДМ в России еще достаточно молод и состояние рынка таково, что использование импортного специализированного оборудования иногда делает ДМ-акцию просто нерентабельной.

Информация в базе данных

Если говорить о программном обеспечении, то ситуация здесь напоминает мне Германию до Бисмарка: сплошное лоскутное одеяло. Каждая фирма, в меру компетентности своих специалистов по информационному обеспечению, создает базы данных, являющиеся основой ДМ-работ, под конкретные задачи и акции. Зачастую в одном ДМ-агентстве скапливается несколько разноплановых баз, которые неумолимо ветшают.

Давайте, оставив разговоры об SQL, реляционных связях, лингвистическом анализе контента и других подобных вещах, поговорим об архитектуре адресной базы данных (АБД) для ДМ.

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

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

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

Ясно, что информация в базе данных должна быть всегда «живой». Актуальность информации описывается экспоненциальной зависимостью. Так, например, в процессе сбора, верстки и издания городского телефонного справочника теряется актуальность до 5% его содержания, на момент выхода из типографии. Примерно через год, можно говорить о 40—60% неактуальной информации в нем, а позже, остается 15—20% адресов «стабильных» фирм, хотя о точности номеров факсов или персоналий говорить уже не приходится.

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

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

Пользователи баз данных

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

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

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

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

Интернет — наиболее непонятная и загадочная область, а о пользователях сети и говорить нечего. Но попробуем их структурировать, хотя бы с точки зрения пользователей адресной базы данных для ДМ.

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

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

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

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

Архитектура адресной базы данных

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

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

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

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

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

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

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

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

По мере поступления почтового возврата сканируем обычным сканером штрих-кодов этот идентификатор и заносим данные в специальную таблицу. При большом объеме рассылок — очень удобно. Не надо сортировать возвраты, копаться с определением кода рассылки. Отсканировал — и забыл. Остальное делает сама база данных: этот адрес помечается флагом возврата и уже не участвует в последующих выборках. Все адреса рассылочного списка, на которые не пришли возвраты, считаем «живыми». Дату актуализации каждого такого адреса меняем на дату проведения рассылки по почтовому штемпелю. Для почтовых рассылок нет другой обратной связи для актуализации данных — только обработка возвратов. При проведении постоянных рассылок это нехитрое мероприятие позволяет поддерживать актуальность адресов на уровне 93—97%. Метод выставления флагов, а не удаления данных дает еще один плюс: при внесении информации из нового или малоизвестного источника, количество совпадений с «выбывшими» данными базы говорит о многом.

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

Принцип его работы, я подробно описывал в № 5 «Диалога» за 2001 год. Скажу только, что по размеру этот блок занимает половину объема базы, так как использует кучу словарей, ссылок и вспомогательных таблиц. В нем логикой работы заведует развитое программное обеспечение в теле базы данных и вспомогательные внешние программные продукты. Без этого модуля невозможно функционирование ДМ-базы данных большого объема.

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

Источник: www.marketingpro.ru/library/teach_dm/teach_dm_dilog/1483.html