RU2651153C2 - Способ обработки данных, относящихся к соединению с платформой интернет-сайта - Google Patents

Abstract

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

Description

Область техники, к которой относится изобретение

Настоящее изобретение относится к области анализа данных пользователя в электронной коммерции.

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

Уровень техники

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

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

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

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

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

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

Раскрытие изобретения

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

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

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

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

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

- каждая стратегия связана с уровнем значимости, а порядок выполнения движков, связанных со стратегиями, зависит от уровней значимости указанных стратегий;

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

- каждая стратегия дополнительно связана со списком текстов и/или ссылок URL и/или изображений, а сообщения, формируемые движками указанной стратегии, построены из текстов и/или ссылок URL и/или изображений из указанного списка стратегии;

- по меньшей мере один стек сообщений представляет собой стек типа «последним вошел, первым вышел» (Last in, first out, LIFO) фиксированного размера, в котором самые старые сообщения заменяются самыми последними сообщениями;

- по меньшей мере один стек сообщений представляет собой стек типа «стек с маркером», при этом платформа передает маркер в стек при запросе сообщения, а сообщения, получившие маркер, заменяются самыми последними сообщениями;

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

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

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

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

Краткое описание чертежей

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

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

фиг. 2 представляет собой схематичное изображение шагов способа обработки данных соединения в соответствии с настоящим изобретением;

фиг. 3 представляет собой схему варианта осуществления системы обработки данных соединения в соответствии с настоящим изобретением;

фиг. 4 представляет модуль обработки системы обработки данных соединения в соответствии с настоящим изобретением;

фиг. 5 представляет собой схему модуля немедленной обработки варианта осуществления системы обработки данных соединения в соответствии с настоящим изобретением;

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

Осуществление изобретения

Ситуации

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

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

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

Ситуационный анализ, используя инструменты для анализа, прогнозирования и имитационного моделирования, открывает широкие перспективы во многих областях экономики. Системы ситуационного анализа (см., например, патентную заявку Франции FR 2962823) могут автономно принимать на входе один или более ситуационных потоков, извлекать ситуации из этих потоков, распознавать важные элементы и применять непрерывную обработку с целью обнаружения явлений и предоставления вариантов решения, преимущественно путем индукции.

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

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

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

Фиг. 1 представляет сетевую архитектуру, в которой настоящее изобретение осуществляется. Оборудование 3 (им может быть компьютерное оборудование любого типа, через которое пользователь может получить доступ в Интернет, от рабочей станции до мобильного терминала, например, смартфона или сенсорного планшета) подключено к платформе 2 интернет-сайта через сеть 4 интернет. Сервер 1, содержащий по меньшей мере одно устройство обработки данных и средства хранения данных, для осуществления данного способа находится в сетевом соединении с указанной платформой 2.

Важно понимать, что термином «платформа» обозначается один или более соединенных между собой серверов интернет-сайта, на которых размещена страница (страницы) интернет-сайта, на котором пользователь в данный момент ведет поиск. Сервером 1, выполняющим указанную обработку, может быть один из серверов, образующих платформу 2. Во всех случаях пользователь 3 оборудования непосредственно или опосредованно (через платформу 2) подключен через сеть интернет к серверу 1, осуществляющему данный способ. Следует отметить, что соединение между сервером 1 обработки и платформой 2 может быть локальным, но ничто не препятствует использованию варианта соединения, проходящего через сеть 4 интернет.

Первый механизм: идентификация ситуации

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

Чтобы это работало, механизм идентификации ситуации способа в соответствии с настоящим изобретением использует «триггеры». Триггеры представляют собой программные модули, которые могут активироваться и инициировать выполнение той или иной конкретной обработки в зависимости от заранее определенных событий.

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

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

Естественно, некоторые индексы, относящиеся к предпочтительным результатам (например, завершение или незавершение транзакции), более весомы, в частности, с точки зрения анализа ситуации.

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

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

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

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

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

Понятно, что обозначения 0, 1 и X являются лишь иллюстрацией, и специалист может выбрать способ представления данных по-своему. В частности, целесообразно использовать элементы информации, не имеющие определенного количества значений и допускающие хранение чисел, например, последовательности символов и т.д. Однако польза применения элементов информации, имеющих n состояний, будет рассмотрена позже. С использованием определенных выше обозначений 1X10 01ХХ является примером ситуационной сигнатуры с восемью элементами информации.

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

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

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

Например, 10А0 ААХ1 представляет собой маску с восемью элементами информации, объединяющую следующие сигнатуры: 1000 00X1, 1000 01X1, 1000 0ХХ1, 1000 10X1, 1000 11X1, 1000 1ХХ1, 1000 Х0Х1, 1000 Х1Х1, 1000 ХХХ1, 1010 00X1, 1010 01X1, 1000 0ХХ1, 1010 10X1, 1010 11X1, 1010 1ХХ1, 1010 Х0Х1, 1010 Х1Х1, 1010 ХХХ1, 10X0 00X1, 10X0 01X1, 10X0 0ХХ1, 10X0 10X1, 10X0 11X1, 10X0 1ХХ1, 10X0 X0X1, 10X0 X1X1, 10X0 ХХХ1.

Сравнение сигнатуры и маски легко осуществляется посредством логических вентилей (каждый элемент маски, отличный от значения «А», сравнивается с соответствующим элементом сигнатуры операцией «ИСКЛЮЧАЮЩЕЕ ИЛИ», затем к результатам этих сравнений применяется операция «И»). При соответствии маски ситуация указанного пользователя, подключенного к платформе 2, идентифицируется как типовая ситуация, связанная с указанной по меньшей мере одной маской, содержащей указанную ситуационную сигнатуру.

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

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

Второй механизм: обработка ситуации

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

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

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

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

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

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

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

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

Указанное действие может выполняться с использованием простого способа LIFO (Last In Last Out, «последним вошел, первым вышел»), но, предпочтительно, используется так называемый способ с маркером. В данном способе текущая страница содержит зоны демонстрации с возможностью приема сообщения в заданном формате, имеющего заданные параметры. Указанные зоны, при их доступности, передают маркер, содержащий различные параметры зоны. Ситуационный движок принимает маркер и «по требованию» формирует одно или более сообщений, зависящих от указанных параметров. Сообщения с маркером извлекаются из стека раньше остальных.

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

Оптимизация вычислительных мощностей

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

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

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

Три вышеназванных уровня задаются как функция типовых уровней активности на сайте в количестве действий в секунду.

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

Бета-уровень соответствует «среднему» уровню активности. Например, если на том же сайте 100000 подключений в день и видно, что пользователь интернета в среднем находится на сайте 1 минуту 30 секунд, то бета-уровень находится при 10,4 Гц.

Гамма-уровень соответствует «низкому» уровню активности. Например, если у сайта отношение между наименьшим и наибольшим количеством одновременных подключений за день равно 1:100 (или, самое меньшее, 10 одновременных подключений при 9 секундах на щелчок), то гамма-уровень находится при 1,11 Гц.

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

Полуконтролируемый и неконтролируемый режимы

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

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

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

Процессоры отклика

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

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

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

по меньшей мере два независимых модуля 21, 22 обработки данных соединения (модули типа «SALI2», в котором SALIX и SALIC являются двумя вариантами), причем модули 21, 22 обработки распределены в по меньшей мере две взаимодополняющие группы, модули 21, 22 группы выполнены с возможностью выполнения подмножества операций, необходимых для осуществления способа обработки данных соединения пользователя с указанной платформой 2, в том числе идентификации ситуации пользователя, и модули 21 обработки каждой группы принимают данные, поступающие из модулей обработки 22 другой группы, с целью завершения всех операций обработки данных соединения;

модуль 10 распределения («RENZO»), принимающий указанные данные соединения и передающий их в модули 21, 22 обработки;

модуль 30 согласования («RENALDO»), собирающий данные, поступающие из модулей 21, 22 обработки и передающий в указанную платформу 2 обработанные данные соединения.

Модули 10, 21, 22, 30 называются процессорами отклика, поскольку они рассчитаны на обработку входных данных без предварительного обучения.

Идея, соответственно, состоит в том, чтобы иметь две (или даже больше) группы из п модулей 21, 22, причем модули 21, 22 одной группы параллельно выполняют одну задачу, а задачи каждой группы при обработке данных соединения являются взаимодополняющими. Различные модули 21, 22 могут быть или физически независимыми процессорами (соединенными посредством шины), каждый из которых имеет собственные средства обработки и собственное пространство хранения, или, как вариант, программными модулями, работающими на данном оборудовании и совместно использующими одни и те же ресурсы процессора (возможно, многоядерного) и одно и то же пространство хранения. Следует отметить, что система 1 может быть распределена по нескольким серверам или даже установлена в системе распределенных («облачных») вычислений на виртуальных машинах. Модули 21, 22, предпочтительно, обмениваются данными в форме потока на языке абстракций, например, XML (eXtensible Markup Language, расширяемый язык разметки), JSON (JavaScript Object Notation, язык обозначения объектов в JavaScript), SOAP (Simple Object Access Protocol, простой протокол доступа к объектам), Silvia или даже протокола Mawerick.

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

Конкретно:

порт OBS (observer, наблюдатель) принимает данные, исходящие из платформы 2 в форме потока XML;

порт COL (collector, коллектор) принимает данные, поступающие из других модулей 21, 22 обработки SALI2 в форме потока XML;

порт ONT (ontology, онтология) принимает онтологию в форме файла XML;

порт LIB (library, библиотека) содержит библиотеки инспекторов, порогов и ситуационных движков (исполняемых);

порт EDI (editor, редактор) передает выходные данные в форме потока XML;

порт DIF (diffuser, распределитель) передает данные в модули 21, 22 обработки других групп в форме потока XML;

порт MON (monitoring, контроль) передает статистику.

Распределение задач между группами модулей 21, 22 позволяет получить более высокую эффективность обработки за счет специализации модулей 21, 22, а получение данных каждой группой обеспечивает «обратную связь», как видно из фиг. 3. Результаты одной части обработки улучшают другую часть обработки. Несколько вариантов возможного распределения модулей 21, 22 обработки между группами будут описаны позже. Следует отметить, что возможно комбинирование данных вариантов: система 1 может иметь две группы модулей 21, 22, распределенных в соответствии с первым правилом, а модули 21, 22 группы могут распределяться между двумя подгруппами в соответствии со вторым правилом.

Сортировка выполняется модулем 10 распределения, который анализирует каждый пакет информации и адресует его в соответствующие модули 21, 22 обработки.

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

В соответствии с первым вариантом модули 21 обработки группы представляют собой модули предварительной обработки, выполненные с возможностью идентификации ситуаций пользователей, подключенных к указанной платформе 2, а модули обработки 22 другой группы представляют собой модули заключительной обработки, выполненные с возможностью обработки идентифицированных ситуаций подключенных пользователей. В данной наиболее предпочтительной конфигурации используются, предпочтительно, модуль 21 предварительной обработки и N модулей 22 заключительной обработки (например, 4 или 8, но должно быть понятно, что указанное количество не является ограничивающим и может быть любым), поскольку обработка результирующих ситуаций и передача сообщений потребляет наибольшую часть ресурсов данного способа.

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

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

В системе, представленной на фиг. 3, «SALIX» - это модуль 22 отложенной обработки, a «SALIC» - это модули 21 немедленной обработки. В данной наиболее предпочтительной конфигурации используются, предпочтительно, модуль 22 отложенной обработки и N модулей 21 немедленной обработки (немедленная обработка имеет приоритет и требует больше ресурсов, поскольку некоторые операции не могут быть отложены). В конфигурации с четырьмя модулями 21 немедленной обработки всего имеется семь модулей 10, 21, 22, 30, и поэтому предпочтительным является восьмиядерный процессор (восьмое ядро управляет операциями остальной системы).

Фиг. 5 и 6 более подробно представляют, соответственно, модуль 21 немедленной обработки типа SALIC и модуль 22 отложенной обработки типа SALIX. На фиг. 5 и 6 показаны порты OBS, COLL, EDI и DIF (порты ONT, LIB и MON между указанными двумя типами модулей соединены аналогично).

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

Порт распределителя передает указанные векторы в модуль 22 отложенной обработки (SALIX). Порт коллектора принимает векторы информации, обрабатываемой как отложенная, и матрицы, поступающие из модуля 22 отложенной обработки (SALIX).

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

Модуль 22 отложенной обработки (SALIX) занимается операциями обработки, не требующими немедленного выполнения. Порт наблюдателя принимает только данные, относящиеся к услугам и пользователям с правами администратора. Порт коллектора принимает векторы, поступающие из модулей 21 немедленной обработки (SALIC). Ситуационные двигатели запускаются и управляются таймером, который принимает решение о том, в какой момент обработка откладывается.

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

В соответствии с третьим вариантом, каждая группа модулей 21, 22 соответствует «линии услуг». Это базовый элемент классификации товаров на интернет-сайте в системе, обозначаемый как «LSO» (Lines/Services/Options, линии/услуги/опции). Линия услуг объединяет несколько услуг. Например, категория «Салон», объединяющая услуги «Столы», «Мебель для телевизора», «Диваны» и т.д., является линией услуг в каталоге мебели. Аналогично, категории «Для мужчин» и «Размер XL» представляют собой линии услуг в каталоге одежды. На интернет-сайте, например, на сайте магазина, можно представлять одни и те же товары в нескольких режимах классификации, которыми являются различные линии услуг. Каждая услуга имеет опции. В предыдущем примере услуга «Брюки» из линии «Для мужчин» будет содержать список опций, которые являются моделями брюк. Каждая опция представляет товар с несколькими вариантами (размер, цвета и т.д); каждый товар, в отличие от опции, уникален (имеет ссылку в каталоге). Соответственно, один и тот же товар может быть представлен в нескольких контекстах LSO. В рассматриваемом примере те же брюки могут находиться в услуге «Мужские брюки» линии «XL».

Целесообразно разделять модули 21, 22 обработки по линиям услуг, особенно для сайтов с широким ассортиментом товаров, где ситуации пользователей могут сильно различаться. Следует отметить, что на больших сайтах уместно перенаправление пользователя на один из серверов платформы 2 в соответствии с линией услуг, по которой этот пользователь перемещается.

Также, и предпочтительно, некоторые из данных вариантов могут быть объединены. В частности, каждый из модулей 21 немедленной обработки (SALIC) второго варианта может быть специально предназначен для одной или нескольких линий услуг. В этом случае модуль 10 распределения (RENZO) распределяет входной поток путем его направления в модуль 22 отложенной обработки (SALIX), если это данные управления, или в модуль 21 немедленной обработки (SALIC), если это данные о переходах пользователя, в зависимости от линии услуг, в которой пользователь находится.

Claims (13)

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

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

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

(c) передачи в оборудование (3) указанного пользователя и/или платформы (2) подмножества сообщений указанного по меньшей мере одного стека сообщений.

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

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

4. Способ по п. 1, отличающийся тем, что каждая стратегия дополнительно связана со списком текстов, и/или ссылок URL, и/или изображений, а сообщения, формируемые движками указанной стратегии, построены из текстов, и/или ссылок URL, и/или изображений из указанного списка стратегии.

5. Способ по п. 1, отличающийся тем, что по меньшей мере один стек сообщений является стеком типа «последним вошел, первым вышел» (LIFO) фиксированного размера, в котором самые старые сообщения заменяются самыми последними сообщениями.

6. Способ по п. 1, отличающийся тем, что по меньшей мере один стек сообщений представляет собой стек типа «стек с маркером», при этом платформа (2) передает маркер в стек при запросе сообщения, а сообщения, получившие маркер, заменяются самыми последними сообщениями.

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

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

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

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

Images