СИСТЕМА И СПОСОБ СОПОСТАВЛЕНИЯ И СБОРА ДАННЫХ ПОЛЬЗОВАТЕЛЯ И/ИЛИ ПОЛЬЗОВАТЕЛЬСКОГО УСТРОЙСТВА
SYSTEM AND METHOD FOR MATCHING AND COLLECTING USER AND/OR USER APPARATUS DATA

ОБЛАСТЬ ТЕХНИКИ
Настоящее изобретение относится к системам и способам сопоставления и сбора данных пользователя и/или пользовательского устройства в рамках текущей сессии доступа пользователя к сети Интернет, для использования системами оповещения пользователей, которые формируют, распространяют и обеспечивают демонстрацию информационных сообщений через сеть Интернет.
УРОВЕНЬ ТЕХНИКИ
Известны различные системы и способы оповещения пользователей через сеть Интернет посредством информационных сообщений, например, такие как системы оповещения пользователей о чрезвычайных ситуациях, системы демонстрации рекламы, системы информирования о штрафах и налогах и т.п. Для указанных систем оповещения пользователей важным условием является донести информационные сообщения до максимального количества пользователей с определёнными социально-демографическими, поведенческими и другими характеристиками (далее целевая аудитория или ЦА). Такой процесс определения характеристик потенциального получателя и выбора на основе его характеристик наиболее подходящих ему рекламно-информационных сообщений называется таргетингом.
Так, например, известны различные способы и модели демонстрации рекламы в Интернет, в т. ч. с использованием таргетинга, при этом сбор информации о пользователе, необходимой для формирования профиля пользователя и таргетирования рекламы, осуществляется путём анализа и сопоставления следующих данных о пользователе и его действиях:
• файлы cookies;
• ключевые слова пользователя и результаты поиска в поисковых машинах;
• профили пользователя в социальных сетях и его интересы;
• данные о посещённых Интернет-ресурсах и действиях пользователя по отношению к рекламно-информационным сообщениям (просмотр, клик, закрытие и др.);
• любая иная доступная информация о пользователях/абонентах, включая его действия по приобретению и/или оплате товаров и услуг через Интернет.
Из документа RU 132591 U1 известна таргетированная рекламная система, характеризующаяся тем, что она содержит сформированные на специальном сервере блок сбора и профилирования данных и связанный с ним шиной обмена данных блок управления рекламными материалами, к которому подключены интерфейс рекламодателя, интерфейс агентства, интерфейс рекламной площадки, административный интерфейс, интерфейс источника внешних данных о пользователях партнера и специальный интерфейс (API). Решение обеспечивает показ различных видов рекламных сообщений Интернет-пользователям с учетом информации о социально-демографических данных о пользователях, его краткосрочных и долгосрочных интересах, географического местоположении пользователя, контексте страницы с рекламным местом, типе пользовательского устройства и других данных, характеризующих как Интернет-пользователей, так и Интернет-сайты, на которых размещается реклама.
Известен также способ идентификации потенциального получателя рекламы (пользователя/абонента) и получения данных о нём путём сопоставления файлов cookies, имеющихся в распоряжении рекламной биржи (Ad Exchange) и Покупателя рекламы (DSP), описанный в частности в «Google's cookie matching protocol» (https://developers.google.com/ad-exchange/rtb/cookie-guide) и «Selling Off Privacy at Auction» (Lukasz Olejnik, Tran Minh-Dung, Claude Castelluccia. Selling Off Privacy at Auction. 2013. hal-00915249).
Известны также различные методы и способы сопоставления или синхронизации файлов cookies, полученных из различных источников, включая так называемые «cookies третьих сторон» (third-party cookies или tracking cookies), т.е. файлы cookies, сохраняемые на устройстве пользователя не непосредственно сайтом/доменом, который посещает пользователь, а другими сайтами/доменами, например, рекламными сетями/службами. Такие методы и способы описаны, в частности, в документах JP 6415458 B2, US 10134047 B2, US 10290017 B2 и др. Общий принцип «синхронизации cookies» состоит в сопоставлении идентификаторов cookies различных источников и определении общего соответствующего им пользователя и/или абонентского устройства.
Недостатком указанных выше методов является то, что для идентификации потенциального получателя (пользователя и/или пользовательского устройства) рекламно-информационных сообщений необходимо наличие файлов cookies и/или иных данных о пользователе и/или его поведении, включая, но не ограничиваясь: ключевые слова, использованные для поиска информации в Интернет, профили пользователя в социальных сетях, история посещённых веб-страниц и др.
Также недостатком вышеуказанных способов является невозможность их использования для таргетирования рекламы в случае если во время сессии пользователь отключает на пользовательском устройстве функции передачи дополнительных данных для идентификации пользователя и определения его предпочтений, включая, но не ограничиваясь: файлы cookies, параметры геолокации, авторизация в социальных сетях и др. Подобные ограничения на сбор и сохранение пользовательских данных также возникают, если пользователь не использует браузер для получения рекламно-информационных сообщений, как, например, происходит при использовании мобильных приложений со встроенным механизмом демонстрации рекламы. Существуют также дополнительные ограничения для сохранения и последующего анализа third-party cookies, в частности, следующие:
• third-party cookies часто блокируются и/или удаляются средствами безопасности или настройками браузеров абонентских устройств, в частности в результате применения мер политики одного источника (Same Origin Policy, SOP, также встречается термин Single Origin Policy);
• доступ со стороны рекламных служб, систем профилирования пользователей и аналогичных систем/сервисов к third-party cookies различных доменов ограничен технологически, т.к. «прочитать» (расшифровать) содержащиеся в cookies данные может только тот домен/сервис, который их сформировал и сохранил.
Таким образом, отсутствие данных, на основании которых можно в режиме реального времени проанализировать поведение и предпочтения пользователя и сопоставить все имеющиеся о пользователе данные, включая исторически накопленные, приводит к невозможности определить профиль данного пользователя (как в режиме реального времени, так и в принципе) и отнести его к определённой ЦА.
Известен ряд способов таргетирования рекламы на основании анализа истории и результатов действий пользователя в Интернете, включая как обычный просмотр веб-страниц, так и взаимодействие с поисковыми машинами, Интернет-магазинами, системами платежей и др. Например, в документе US 2013/0110627 A1 описан метод повышения эффективности таргетинга на основании обработки запросов пользователя к поисковым машинам. Метод заключается в выявлении намерений пользователя при помощи анализа поисковых запросов и сопоставлении их с запросами рекламодателей с целью выбора рекламы, наиболее соответствующей поисковому запросу.
Также из документа US 8548820 B2 известны системы и методы сопоставления данных о пользователе и истории его доступа к контенту, обеспечивающие таргетирование рекламы. Из документа US 2014/0032306 A1 известен способ выявления необходимых для таргетирования параметров пользователя на основании истории поиска. Метод заключается в сборе данных о поисковых запросах пользователя и направлении соответствующего запроса на основе указанных данных в систему демонстрации рекламы.
Известен также способ определения и передачи данных о пользователе за счет внедрения дополнительных параметров таргетинга непосредственно в запрос к сервису третьей стороны, описанный в частности в документе US 8775391 B2. Данный способ имеет значительные ограничения, т.к. главным требованием для реализации описанного способа является использование обычного протокола HTTP (без расширения протокола HTTPS, обеспечивающего шифрование данных). В последнее время объем запросов и сервисов, поддерживающих обычный протокол HTTP, существенно сократился из-за низкого уровня обеспечения безопасности данных, и все основные сервисы, оперирующие с пользовательскими данными, включая рекламные службы, перешли на использование протокола HTTPS, который не поддерживается указанным методом. Это в свою очередь сделало методы, описанные в указанном выше патенте US 8775391 B2, и аналогичные не применимыми на практике, т.к. запросы, проходящие по SSL (HTTPS), зашифрованы, и поэтому никакой сторонний сервис не может обработать данные запросы, т.к. они закодированы сертификатом, привязанным к определённому домену, а подмену сертификатов все существующие современные браузеры определяют и отклоняют ответы, содержащие признаки подмены сертификатов.
Из документов US 9262367 B2 и US 9621625 B2 известны способы идентификации пользовательского устройства с применением специальных средств (сервисов), в частности, Proxy-сервера или его аналога (согласно документу US 9262367 B2) и специального сервиса «Discovery Server» (согласно документу US 9621625 B2), запросы на которые переадресуются за счет DNS-spoofing специального набора доменов для обеспечения сопоставления данных о пользовательском устройстве из различных источников.
Существенным недостатком данных способов является необходимость установки в периметр сети оператора или провайдера специальных средств для перехвата и обработки трафика третьих сторон, что может замедлять передачу и обработку данных для таргетирования вплоть до невозможности обработки в режиме реального времени. Описанные в вышеуказанных патентах способы также предполагают перехват и первичную обработку HTTP-трафика, но использование расширенного протокола HTTPS не позволяет применять указанные возможности сервисов по перехвату и первичной обработке трафика на практике, т.к. запросы, проходящие по SSL (HTTPS), зашифрованы, и поэтому никакой сторонний сервис не может обработать данные запросы, т.к. они закодированы сертификатом, привязанным к определённому домену. Реализация указанных способов для протокола HTTPS возможна, только если третья сторона передаёт в такой сервис свой сертификат для расшифровки трафика, но в этом случае не обеспечивается требуемый уровень безопасности передачи данных (т.к. компрометируется сам сертификат), поэтому использование описанных в вышеуказанных патентах способов с протоколом HTTPS практически невозможно.
Учитывая всё возрастающий объём рекламно-информационных сообщений в сети Интернет и требования систем оповещения пользователей к повышению их эффективности, а также стремление пользователей сети Интернет ограничить доступ различного программного обеспечения к своим личным данным, включая, но не ограничиваясь: регистрационные данные, профили социальных сетей, файлы cookies, история поиска, просмотра страниц и других действий в сети Интернет, а также избежать демонстрации рекламы на веб-страницах и в приложениях, включая мобильные, в т.ч. с использованием различных средств блокировки рекламы, существует потребность в средствах, позволяющих в режиме реального времени:
• провести анализ и сопоставление данных пользователя (абонента)/пользовательского устройства с запросами систем оповещения пользователей,
• обеспечить максимально возможную для конкретного пользователя релевантность информационных сообщений, включая рекламные, в течение конкретной сессии в браузере и/или использования приложения даже в условиях, когда пользователь (абонент) старается всеми доступными ему средствами ограничить возможности компьютерных систем собирать и анализировать его личные данные,
• подтвердить принадлежность запроса на информационное сообщение, включая рекламное, реальному пользователю/абоненту, что позволяет выявлять «ботов» и другие средства обмана систем оповещения пользователей и таким образом противодействовать им.
РАСКРЫТИЕ СУЩНОСТИ ИЗОБРЕТЕНИЯ
Сущность предлагаемого технического решения заключается в создании системы сопоставления и сбора данных пользователя и/или пользовательского устройства в рамках текущей сессии доступа пользователя к сети Интернет, взаимодействующей с устройством оператора или провайдера, используемой для системы оповещения пользователей, формирующей информационные сообщения в режиме реального времени.
Предлагаемое техническое решение обеспечивает технический результат в виде обеспечения сбора и сопоставления данных пользователя и/или пользовательского устройства и идентификацию пользователя и/или пользовательского устройства в режиме реального времени, в том числе в условиях, когда возможность сбора и сопоставления данных и идентификации пользователя ограничена пользователем, владельцем Интернет-ресурса и другими. Таким образом обеспечивается донесение системами оповещения пользователей информационных сообщений, основанных на собранных/сопоставленных данных пользователя и/или пользовательского устройства согласно предлагаемой системе и способу, до максимального количества реальных идентифицированных пользователей.
Дополнительно за счет идентификации пользователя в режиме реального времени обеспечивается высокоэффективное противодействие «ботам» и другим средствам обмана систем оповещения пользователей при распространении рекламно-информационных сообщений.
Согласно первому аспекту настоящего изобретения предложена система сопоставления и сбора данных пользователя и/или пользовательского устройства в рамках текущей сессии доступа пользователя к сети Интернет, взаимодействующая с устройством оператора или провайдера, используемая для системы оповещения пользователей, формирующей информационные сообщения в режиме реального времени, которая содержит блок получения запроса, выполненный с возможностью получения от системы оповещения пользователей запроса данных пользователя, содержащего транслированные IP-адрес и порт оператора или провайдера; блок направления запроса, выполненный с возможностью направления запроса, содержащего транслированные IP-адрес и порт оператора или провайдера, в сервис устройства оператора или провайдера, осуществляющий преобразование сетевых адресов (NAT - Network Address Translation; https://ru.wikipedia.org/wiki/NAT); блок получения исходных данных, выполненный с возможностью получения от сервиса NAT исходных IP-адреса и порта пользовательского устройства, сопоставленных с транслированными IP-адресом и портом оператора или провайдера; блок сопоставления и сбора данных, выполненный с возможностью сопоставления с использованием полученных исходных IP-адреса и порта пользовательского устройства данных пользователя и/или пользовательского устройства из всех доступных источников, включая базы данных оператора или провайдера, но не ограничиваясь ими, и сбора сопоставленных данных пользователя и/или пользовательского устройства из указанных доступных источников; и блок направления собранных данных, выполненный с возможностью направления собранных сопоставленных данных пользователя и/или пользовательского устройства в систему оповещения пользователей.
Согласно одному варианту реализации предлагаемой системы, блок сопоставления и сбора данных выполнен с возможностью определения уникального идентификатора пользователя (UID) и определения данных, соответствующих UID, на основании исходных IP-адреса и порта пользовательского устройства.
Согласно еще одному варианту реализации предлагаемой системы, блок сопоставления и сбора данных выполнен с возможностью сопоставления сопоставленных с использованием исходных IP-адреса и порта пользовательского устройства данных, хранящихся в первой базе данных, с данными, хранящимися во второй базе данных.
Согласно некоторым вариантам реализации предлагаемой системы, доступными источниками данных являются различные средства и корпоративные информационные системы (КИС), включая, но не ограничиваясь: браузеры, менеджеры загрузок, мобильные и десктопные приложения, CRM, DMP, DPI.
Согласно второму аспекту настоящего изобретения, предложен способ сопоставления и сбора данных пользователя и/или пользовательского устройства в рамках текущей сессии доступа пользователя к сети Интернет, используемый с устройством оператора или провайдера, для системы оповещения пользователей, формирующей информационные сообщения в режиме реального времени, который включает получение исходных IP-адреса и порта пользовательского устройства и соответствующих им транслированных IP-адреса и порта оператора или провайдера от устройства оператора или провайдера, осуществляющего преобразование сетевых адресов (NAT), если это соответствует заранее заданным настройкам; получение запроса на получение данных о пользователе и/или пользовательском устройстве от системы оповещения пользователей, причем запрос содержит транслированный IP-адрес и порт оператора или провайдера. Если ранее от сервиса NAT не было получено исходных IP-адреса и порта пользовательского устройства согласно заранее заданным настройкам, направление запроса к сервису NAT и получение от сервиса NAT исходных IP-адреса и порта пользовательского устройства на основании транслированных IP-адреса и порта оператора или провайдера, сопоставленных с ними; сопоставление данных пользователя и/или пользовательского устройства из всех доступных источников, включая базы данных оператора или провайдера, но не ограничиваясь ими, с использованием полученных исходных IP-адреса и порта пользовательского устройства, сбор сопоставленных данных пользователя и/или пользовательского устройства из указанных доступных источников, и направление собранных сопоставленных данных пользователя и/или пользовательского устройства в систему оповещения пользователей.
Согласно одному варианту реализации предлагаемого способа, определяют уникальный идентификатор пользователя (UID) и данные, соответствующие UID, на основании полученных исходных IP-адреса и порта пользовательского устройства и выполняют сбор сопоставленных данных пользователя и/или пользовательского устройства с использованием уникального идентификатора пользователя (UID) и данных, соответствующих UID.
Согласно еще одному варианту реализации предлагаемого способа, источниками данных являются различные средства и корпоративные информационные системы (КИС), включая, но не ограничиваясь: браузеры, менеджеры загрузок, мобильные и десктопные приложения, CRM, DMP, DPI.
Таким образом, предлагаемые система и способ позволяют идентифицировать потенциального получателя таргетированной рекламы или информационных сообщений (пользователя и/или пользовательское устройство) в режиме реального времени за счет возможности выполнения предлагаемыми системой и способом запросов к сервису NAT на получение исходных IP-адреса и порта пользовательского устройства в режиме реального времени и получения их от сервиса NAT, а также за счет использования связки исходных и транслированных IP-адресов и портов в режиме реального времени. В частности, исходные данные, полученные из сервиса NAT, используются предлагаемыми системой и способом как основа для поиска, сопоставления (мэтчинга) любых других имеющихся в разных источниках данных о пользователе/пользовательском устройстве и сбора сопоставленных данных о пользователе/пользовательском устройстве в режиме реального времени, что позволяет предоставлять различным системам оповещения пользователей/информационным системам возможность получить данные, которые они не могут получить другими средствами и способами, например, при отсутствии файлов cookies и/или иных данных о пользователе и/или его поведении, включая, но не ограничиваясь: ключевые слова, использованные для поиска информации в Интернет, профили пользователя в социальных сетях, история посещённых веб-страниц и др.
Более того, предлагаемые система и способ способствует противодействию «ботам» и другим средствам обмана рекламодателей при распространении рекламно-информационных сообщений, а именно предлагаемые система и способ позволяют получить подтверждение принадлежности запроса, например, на рекламу реальному пользователю за счет возможности сопоставления транслированных и исходных IP-адресов и портов в режиме реального времени. Положительный эффект от противодействия «ботам» заключается в повышении эффективности рекламно-информационных сообщений, а именно, в повышении процента показов рекламно-информационных сообщений реальным пользователям от общего количества показов данных рекламно-информационных сообщений.
В дополнение к тому, что предлагаемые система и способ способствуют более эффективному таргетированию рекламы и информационных сообщений в режиме реального времени, они также имеют возможность эффективно функционировать при использовании любых протоколов стека TCP/IP, включая протокол HTTPS.
Кроме того, предлагаемые система и способ способны одинаково успешно обеспечить идентификацию потенциального получателя (пользователя и/или пользовательского устройства) таргетированной рекламы и информационных сообщений при использовании им как браузеров, так и мобильных приложений.
Таким образом, на основе предлагаемых системы и способа возможно как таргетирование рекламы, так и информирование пользователей о каких-либо чрезвычайных ситуациях или о необходимой для соответствующих пользователей информации, включая информацию о штрафах, налогах и т.п.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
Для более подробного описания предлагаемых технических решений в вариантах осуществления настоящего изобретения ниже кратко перечислены прилагаемые чертежи, необходимые для их описания. Необходимо отметить, что чертежи далее демонстрируют лишь некоторые варианты осуществления настоящего изобретения, которые могут быть изменены и скомбинированы без отступления от сущности изобретения.
Фиг. 1 - блок-схема предлагаемой системы сопоставления и сбора данных пользователя и/или пользовательского устройства согласно одному из вариантов реализации.
Фиг. 2 - блок-схема предлагаемого способа сопоставления и сбора данных пользователя и/или пользовательского устройства согласно одному из вариантов реализации.
Фиг. 3 - общая функциональная схема взаимодействия предлагаемой системы сопоставления и сбора данных пользователя и/или пользовательского устройства, устройства оператора или провайдера и системы демонстрации рекламы согласно одному из вариантов реализации.
Фиг. 4.1. - функциональная схема подключения системы сопоставления и сбора данных пользователя и/или пользовательского устройства к системе демонстрации рекламы согласно одному из вариантов реализации.
Фиг. 4.2. - функциональная схема подключения системы сопоставления и сбора данных пользователя и/или пользовательского устройства между Ad Exchange и DSP согласно одному из вариантов реализации.
Фиг. 4.3. - функциональная схема подключения системы сопоставления и сбора данных пользователя и/или пользовательского устройства к DSP согласно одному из вариантов реализации.
Фиг. 4.4. - функциональная схема подключения системы сопоставления и сбора данных пользователя и/или пользовательского устройства в качестве независимого сервиса синхронизации (сопоставления) cookies согласно одному из вариантов реализации.
ОСУЩЕСТВЛЕНИЕ ИЗОБРЕТЕНИЯ
Настоящее изобретение далее более подробно описано на примерах вариантов реализации системы и способа сопоставления и сбора данных для системы оповещения пользователей, которая выступает в качестве системы демонстрации рекламы. При этом объём заявляемого изобретения не ограничивается приведенным вариантом реализации и может быть применен для любой другой системы оповещения пользователей, известной специалисту в области техники, в том числе для системы оповещения о таких чрезвычайных ситуациях, как плохая погода, пожар в конкретных торговых центрах или жилых домах, терактах, а также о штрафах, налогах и другое.
Настоящее изобретение представляет собой программный или программно-аппаратный комплекс, в данном варианте реализации предназначенный для выявления, сопоставления, сбора и направления в режиме реального времени в систему или системы демонстрации рекламы сведений об абоненте/пользователе сети и его устройстве в объёме, достаточном для таргетирования в режиме реального времени направляемой ему рекламы.
В настоящем описании раскрыт вариант распространения рекламы в сети Интернет с использованием механизма real-time-bidding (RTB или programmatic buying), в котором в режиме реального времени при обращении пользователя (абонента) к Интернет-ресурсу (сайту) или мобильному приложению происходит запрос к так называемой «рекламной бирже» (экосистема из трех компонентов: платформа со стороны предложения (supply side platform, SSP), платформа со стороны спроса (demand side platform, DSP) и платформа управления данными (data management platform, DMP), которая осуществляет отбор таргетированной рекламы для показа данному пользователю на основании его определённых характеристик и его устройства. Правила взаимодействия участников системы RTB, включая технические параметры и условия передачи данных, как правило, регулируются протоколом OpenRTB или аналогичным, специфичным для конкретной экосистемы. Определение и выбор рекламно-информационного сообщения для демонстрации конкретному пользователю (таргетирование) происходит на основании так называемого «профиля пользователя», включающего, например, социально-демографические характеристики, время и место обращения к сети/ресурсу, историю поисковых запросов и/или предыдущих показов рекламы и другие показатели.
Используемые в настоящем описании термины «оператор связи», «провайдер», «владелец сети» означают поставщика услуг связи, реализующего доступ в сеть Интернет. Предлагаемый комплекс, согласно одному из аспектов настоящего изобретения, относится к программно-аппаратным средствам оператора услуг связи.
Термины «абонентское устройство», «устройство пользователя сети» означают устройство или пользовательское устройство, с помощью которого или которых пользователь осуществляет подключение к сети провайдера и доступ к сети Интернет.
Термины «рекламная площадка», «рекламная служба» означают систему методов и средств, включая программно-аппаратные, обеспечивающие распространение и демонстрацию рекламно-информационных сообщений в сети Интернет.
Термин «третья сторона» означает любых других участников обмена данными в ходе сессии доступа пользователя к сети Интернет, кроме самого пользователя/абонента и его устройства (первая сторона) и оператора или провайдера, обеспечивающего данному пользователю доступ к сети Интернет (вторая сторона). В частности, третьей стороной для предлагаемой системы в случае применения в системе RTB будут являться, например, SSP, DSP или Интернет-ресурс (веб-сайт и т.п.), к которому обращается пользователь.
Также под «настройкой» следует понимать адаптацию способа взаимодействия предлагаемой системы к конкретному типу оборудования, а также бизнес-процессам, правилам и требованиям оператора или провайдера. Задавать и менять настройки может компания, в которой установлена предлагаемая система, либо непосредственно оператор/провайдер. Настройки также могут менять и задавать участники системы таргетирования и демонстрации рекламы, но в этом случае настройки будут зависеть от соглашений с оператором/провайдером.
Необходимо отметить, что настоящее изобретение может быть использовано не только с сетью Интернет, но и в любых других сетях на основе набора протоколов TCP/IP (https://ru.wikipedia.org/wiki/TCP/IP).
Согласно блок-схемам, показанным на фиг. 1 и 2, система сопоставления и сбора данных пользователя и/или пользовательского устройства в рамках текущей сессии доступа пользователя к сети Интернет (Real Time Data Matching, далее - RTDM), взаимодействующая с устройством оператора или провайдера, используемая для системы оповещения пользователей, формирующей информационные сообщения в режиме реального времени, содержит блок 1 получения запроса, выполненный с возможностью получения от системы оповещения пользователей запроса данных пользователя, содержащего транслированные IP-адрес и порт оператора или провайдера; блок 2 направления запроса, выполненный с возможностью направления запроса, содержащего транслированные IP-адрес и порт оператора или провайдера, в сервис устройства оператора или провайдера, осуществляющий преобразование сетевых адресов (NAT); блок 3 получения исходных данных, выполненный с возможностью получения от сервиса NAT исходных IP-адреса и порта пользовательского устройства, сопоставленных с транслированными IP-адресом и портом оператора или провайдера; блок 4 сопоставления и сбора данных, выполненный с возможностью сопоставления с использованием полученных исходных IP-адреса и порта пользовательского устройства данных пользователя и/или пользовательского устройства из всех доступных источников, включая базы данных оператора или провайдера, но не ограничиваясь ими, и сбора сопоставленных данных пользователя и/или пользовательского устройства из указанных доступных источников; и блок 5 направления собранных данных, выполненный с возможностью направления собранных сопоставленных данных пользователя и/или пользовательского устройства в систему оповещения пользователей.
Согласно Фиг. 3, общая функциональная схема содержит систему сопоставления и сбора данных пользователя и/или пользовательского устройства в режиме реального времени (на Фиг. 3 обозначено как «RTDM»), а также пользовательское устройство (на Фиг. 3 обозначено как «Абонентское устройство»), устройство оператора или провайдера (на Фиг. 3 обозначено как «Устройство оператора»), содержащее сервис, осуществляющий преобразование сетевых адресов (NAT), систему демонстрации рекламы (на Фиг. 3 обозначено как «RTB»), доступные источники (на Фиг. 3 обозначено как «различные КИС», «Data Bases» и «любые программные и аппаратные средства, обеспечивающие сохранение данных»), хранящие данные о соответствующем профиле пользователя. Данные, хранящиеся в указанных доступных источниках, могут быть использованы при сопоставлении данных блоком сопоставления данных системы RTDM, а также могут быть собраны блоком сбора сопоставленных данных системы RTDM.
Сервис NAT выполнен с возможностью замены исходных IP-адреса и порта пользовательского устройства (Client IP-address и Source Port on Client) на транслированные IP-адрес и порт оператора или провайдера (NO IP-адрес и NO Port) и передачи исходных IP-адреса и порта пользовательского устройства и соответствующие им транслированные IP-адрес и порт оператора или провайдера в блок получения исходных данных системы RTDM, причем передача выполняется сразу после замены или по запросу блоком направления запроса от системы RTDM в зависимости от заранее заданных настроек. Стоит отметить, что система RTDM может содержать базу данных для хранения текущих NAT-трансляций, в частности для хранения и дальнейшего использования собранных данных о пользователе и/или пользовательском устройстве.
Устройство оператора или провайдера выполнено с возможностью направления запроса пользователя в сеть Интернет (на Фиг. 3 обозначено как «Интернет»), содержащего код запрашиваемого пользователем Интернет-ресурса. Указанный код содержит запрос рекламного контента, который в последующем направляется в систему демонстрации рекламы (на Фиг. 3 обозначено как «RTB»). Причем и запрос пользователя в сеть Интернет, и запрос рекламного контента содержат транслированные IP-адрес и порт оператора или провайдера.
Система демонстрации рекламы выполнена с возможностью получения запроса рекламного контента, содержащего транслированные IP-адрес и порт оператора или провайдера, и направления запроса данных пользователя, так же содержащего транслированные IP-адрес и порт оператора или провайдера в блок получения запроса системы RTDM. Также, система демонстрации рекламы выполнена с возможностью получения от блока направления собранных данных системы RTDM, собранных по соответствующему профилю пользователя. При этом система демонстрации рекламы выполнена с возможностью формирования таргетированного рекламного контента для соответствующего пользователя на основании полученных данных от системы RTDM.
Реализуемый согласно предложенному способу принцип заключается в следующем. Пользователь при подключении и/или авторизации в сети связи для получения доступа к Интернет-ресурсам регистрируется (передает провайдеру определённый набор данных) и/или авторизуется в сети одним из доступных у провайдера способов. В результате авторизации в сети устанавливается однозначная связь между IP-адресом, выданным провайдером абонентскому (пользовательскому) устройству (далее абонентское устройство или АУ), и идентификатором устройства или абонента (пользователя), позволяющая однозначно сопоставить запросы от выданного IP-адреса (Client IP-address) конкретному абоненту и устройству.
Далее, абонент запрашивает через определённое АУ доступ к определённому Интернет-ресурсу (путём ввода адреса в строку браузера или перехода по ссылке), либо запускает приложение сам или оно исполняется его АУ в фоновом режиме, которое запрашивает какие-либо данные через сеть Интернет или передает какие-либо данные через сеть Интернет (на Фиг. 3 обозначено 1). Любой запрос, отправляемый абонентским устройством абонента из внутренней сети оператора или провайдера в сеть Интернет, проходит через устройство оператора или провайдера сети (на Фиг. 3 обозначено «Устройство Оператора), осуществляющее преобразование сетевых адресов (Network Address Translation, NAT).
Таким образом, исходные IP-адрес и порт (Client IP-address и Source Port on Client соответственно - на Фиг. 3 обозначено 1а) заменяются на транслированные IP-адрес и порт оператора или провайдера (NO IP-address - Network Operator IP-address и NO Port - Network Operator Port соответственно) соответствующей подсети AS (Autonomous System), принадлежащей соответствующему оператору/провайдеру (на Фиг. 3 обозначено 1b). Указанные данные, вместе с информацией о назначении запроса передаются в систему RTDM в режиме реального времени или по запросу. Сервис NAT сохраняет исходные Client IP-address и Source Port on Client в NAT-таблице вместе с транслированным NO IP-address (Network Operator IP-address) и NO Port (Network Operator Port), а также, возможно, с адресом и портом назначения запрашиваемого абонентом Интернет-ресурса.
Если в сети установлен брандмауэр/файрвол (firewall) и/или используется технология проверки данных DPI (Deep Packet Inspection), или иное устройство оператора или провайдера, позволяющее регистрировать сетевую активность абонентов, действия абонентов в сети регистрируются и ассоциируются с IP-адресом АУ и передаются в систему RTDM в режиме реального времени автоматически либо по запросу (в зависимости от настроек сети и требований оператора или провайдера). В результате этого данные об АУ и абоненте (включая, но не ограничиваясь: МАС-адрес, IP-адрес, User-Agent, порт(ы) и домен(ы) назначения) могут быть получены системой RTDM и направлены/сохранены в различных информационных системах и/или базах данных в зависимости от конфигурации сети и правил, установленных оператором или провайдером (на Фиг. 3 обозначены «Различные КИС» и «Data Bases»). При наличии у оператора или провайдера дополнительных средств мониторинга и анализа трафика (включая, но не ограничиваясь: DPI, APM (Application Performance Management/Monitoring)), данные о запросе и абоненте также сохраняются в соответствующих базах данных указанных корпоративных информационных систем (КИС) (на Фиг. 3 обозначенных «Различные КИС» и «Data Bases»).
После преобразования сетевых адресов из сети оператора или провайдера в Интернет направляется запрос Интернет-ресурса, содержащий NO IP-адрес, NO Port, порт назначения (destination port), код запрашиваемого пользователем ресурса (веб-страницы и/или приложения), который в том числе может содержать запрос(ы) к рекламным службам/доменам/сервисам 3-х сторон (на Фиг. 3 обозначено 1с). При этом исходные IP-адрес и порт, а также данные об АУ и абоненте (включая, но не ограничиваясь: МАС-адрес, IP-адрес, User-Agent, порт(ы) и домен(ы) назначения) становятся доступными для системы RTDM.
Запрос к рекламным службам/доменам/сервисам 3-х сторон, содержащийся в коде запрашиваемого абонентом ресурса (веб-сайта) или приложения, поступает в соответствующую систему (на Фиг. 3 обозначено 2). В данном запросе в соответствии с сетевыми протоколами TCP/UDP обязательно содержится NO IP-address и NO Port, присвоенный ранее NAT-сервисом, а также IP-адрес(а) и порт(ы) назначения (destination IP-address и destination port). Также в запросе, если он происходит по протоколу HTTPS (или HTTP), могут присутствовать или отсутствовать другие идентификаторы АУ и абонента, на основании которых система может произвести таргетирование рекламы (User-Agent, файлы cookies и др.).
Система демонстрации рекламы (на Фиг. 3 обозначена RTB) направляет в систему RTDM запрос на получение данных для таргетинга, в котором содержится как минимум NO IP-адрес и NO Port (на Фиг. 3 обозначено 3). Возможность направления запроса на получение «внутреннего» IP-адреса конкретного абонентского устройства в течение сессии и обработки ответа от сервиса NAT заложена в функционале/коде системы RTDM.
Система RTDM на основании полученных запросов и содержащихся в них данных запрашивает и получает из NAT исходные IP-адрес и порт АУ, однозначно сопоставленные с IP-адресом и портом оператора или провайдера (NO IP-адрес и NO Port), если ранее сервисом NAT не было предоставлено данных (на Фиг. 3 обозначено 4) согласно заранее заданным настройкам. Стоит отметить, что схема взаимодействия системы RTDM и сервиса NAT может быть достаточно индивидуальной, в частности, она зависит от типа роутера или иного сервиса, реализующего NAT. В общем случае, система RTDM получает от роутера поток данных, содержащий NAT-трансляции в момент их установления, по протоколу netflow или ipfix, или иного оборудования/сервиса, обеспечивающего функционал NAT.
На основании полученных исходных IP-адреса и порта АУ и других данных, имеющихся в системе демонстрации рекламы, система RTDM путём обмена данными с устройствами/сервисами оператора или провайдера или с использованием ранее переданных и сохраненных данных определяет уникальный идентификатор абонента (UID) в рамках текущей сессии и соответствующие ему данные/профили, затем осуществляет сбор данных для таргетинга рекламы для соответствующего(их) профиля(ей) абонента из всех доступных источников (на Фиг. 3 обозначено 5а и 5b), включая, но не ограничиваясь: CRM, DMP и другие различные КИС, базы данных оператора или провайдера и др.
Система RTDM передаёт собранные по данному профилю абонента/устройства данные для таргетинга рекламы в систему демонстрации рекламы (RTB) (на Фиг. 3 обозначено 6). Причем, модуль RTDM может передавать как все собранные данные, так и только те данные, которые необходимы для системы демонстрации рекламы и соответствуют настройкам и требованиям оператора или провайдера. При этом настройки индивидуальны и зависят от способа реализации и/или установки системы RTDM и требований «потребителя» данных - участника системы демонстрации рекламы (DSP, SSP, рекламная биржа и т.п.).
В зависимости от конкретной схемы реализации решения дальнейшая обработка данных в системе демонстрации рекламы возможна различными способами:
а) если система RTDM подключена непосредственно к SSP-платформе, AdServer-у рекламодателя или любому другому сервису 3-й стороны, система RTDM получает запрос на получение данных для таргетинга и возвращает данные профиля абонента для таргетинга непосредственно в SSP-платформу, AdServer-у рекламодателя или любому другому сервису 3-й стороны;
б) в ином случае система демонстрации рекламы получает от системы RTDM и анализирует состав и качество полученных данных для таргетинга. На основании результатов анализа возможны следующие варианты действий системы демонстрации рекламы:
- если система RTDM не подключена к SSP-бирже, то запрос направляется к подключенным к ней DSP для получения ставок и проведения аукциона:
1) если одна из DSP подключена к системе RTDM, она может переслать в систему RTDM запрос на ставку (Bid Request) или иным образом получить дополнительную информацию по данному запросу в системе RTDM;
2) система RTDM за счет сопоставления временных меток и связанных с ними данных, ранее сохраненных или полученных от устройств/сервисов оператора или провайдера, с данными, полученными в Bid request-е или в рамках протокола взаимодействия с DSP, производит сопоставление запросов и определение идентификатора АУ. В случае нахождения однозначного соответствия запроса и АУ передает соответствующие данные об АУ/профиле абонента в DSP для таргетирования показа, далее система RTDM в процессе выбора и демонстрации таргетированного рекламного сообщения не участвует.
- если система RTDM подключена к рекламной/SSP-бирже (на Фиг. 3 обозначены как «AdExchange-1 - AdExchange-N+1») как DSP по протоколу OpenRTB или аналогичному, то сервис бирж(и) получает сформированный запрос на ставку (Bid request), который, по крайней мере, содержит IP-подсеть источника запроса и домен/сервис, на котором торгуется показ рекламы:
(1) система RTDM за счет сопоставления временных меток и связанных с ними данных, ранее сохраненных или полученных от сервисов оператора или провайдера, с данными, полученными в запросе ставки (Bid request), производит сопоставление запросов и определение идентификатора АУ. В случае нахождения однозначного соответствия запроса и АУ запрос обогащается соответствующими данными и передается в подключенные DSP для получения ставок по показу;
(2) из полученных ставок система RTDM выбирает максимальную ставку, полученную за допустимый промежуток времени, установленный в системе демонстрации рекламы и/или SSP, вычитает заданную маржинальность сервиса и передает данные о выбранной ставке в качестве ответа на исходный запрос рекламной/SSP-биржи, включая дополнительные параметры, полученные от DSP.
При этом вне зависимости от варианта реализации решения сбор и обработка вышеуказанных данных происходят в режиме реального времени (общее время от поступления запроса от системы демонстрации рекламы в систему RTDM до отправки дополнительных данных для таргетинга не превышает 100 мс). В результате соответствующий сервис обрабатывает полученные данные и выбирает таргетированное рекламное сообщение для демонстрации на АУ в режиме реального времени.
После того как система демонстрации рекламы сформировала таргетированный рекламный контент, она передаёт на АУ как минимум одно таргетированное рекламное сообщение для демонстрации (на Фиг. 3 обозначено 7).
По результатам демонстрации рекламного сообщения данные о демонстрации сохраняются в базе(ах) данных для дальнейшего использования системой RTDM и другими сервисами при таргетировании рекламы (на Фиг. 3 обозначено 8). Данные поступают в базы данных при помощи любых программных и аппаратных средств, обеспечивающих сохранение данных. В одном из вариантов реализации сохранение данных происходит непосредственно в системе RTDM, при этом сохранение данных непосредственно в системе RTDM не является обязательным и зависит от настройки системы в целом.
Стоит еще раз отметить, что система RTDM может одинаково эффективно выполнять свои функции при установке не только в периметре сети оператора или провайдера, но и вне периметра сети, в т. ч. в системе демонстрации рекламы, SSP/DSP и как независимый от оператора или провайдера сервис. Настоящее изобретение может быть реализовано в следующих вариантах:
• в виде отдельного программного обеспечения, устанавливаемого на сервере(ах) как оператора или провайдера, так и компаний, обеспечивающих демонстрацию онлайн-рекламы;
• в виде дополнения к специализированным программно-аппаратным комплексам, выполняющим различные функции мониторинга сетевой активности и анализа сетевого трафика, включая, но не ограничиваясь: брандмауэры (firewalls), средства DPI (Deep Packet Inspection) и др.;
• в виде специального программного обеспечения, устанавливаемого в сети оператора или провайдера и обрабатывающего данные от пограничного роутера, реализующего функционал NAT.
Таким образом, система RTDM может быть использована как оператором/провайдером, так и любыми участниками всей экосистемы демонстрации таргетированной рекламы. Стоит отметить, что указанные выше варианты реализации и/или установки системы RTDM подтверждают ее гибкость и совместимость с разными системами.
В частности, возможны следующие варианты реализации решения в зависимости от потребностей и политик систем демонстрации рекламы и/или оператора или провайдера. Различные варианты реализации классифицируются в зависимости от схемы подключения и доступных данных:
ο RTDM подключается к SSP, системе демонстрации рекламы (AdServer) и/или иному сервису и обеспечивает таким образом указанные сервисы специфическими данными (в т. ч. исходным/локальным IP-адресом и портом АУ), которые ни SSP, ни другие рекламные сервисы не могут получить иными способами в режиме реального времени. В данном варианте реализации RTDM обеспечивает в части демонстрации рекламы как таргетирование рекламы, так и подтверждение рекламодателю соответствия абонентов-получателей рекламы его требованиям по социально-демографическим, геолокационным и другим параметрам для таргетинга. Общая схема такого решения приведена на Фиг. 4.1.
• RTDM устанавливается между рекламной биржей и DSP. В этом случае RTDM может получить запрос на ставку (Bid request), дополнить его данными о пользователе/АУ, которые ни рекламная биржа, ни DSP не могут получить иными способами, и передать обогащенный запрос в DSP, аналогично тому, как это делает SSP, только с дополнительными данными. В этом случае RTDM позволяет в том числе обойти ограничения, установленные политиками и правилами владельца Интернет-ресурса, на передачу во внешние системы определённых данных об абоненте/АУ. Общая схема такого решения приведена на Фиг. 4.2.
• RTDM подключается непосредственно к DSP. В этом случае DSP обрабатывает Bid request, обогащая его данными, получаемыми при помощи RTDM, и, следовательно, обеспечивает более точное соответствие bid-request требованиям рекламодателя. Общая схема такого решения приведена на Фиг. 4.3.
• RTDM работает как независимый сервис с известным доменом или IP-адресом в сети Интернет и использует общепринятые механизмы синхронизации cookies для передачи данных об узнавании пользователя в сторонние системы, не используя при этом непосредственно сами cookies. Общая схема такого решения приведена на Фиг. 4.4.
В каждом из вариантов реализации/установки системы RTDM расширяются возможности того или иного участника системы демонстрации рекламы, в общем случае система RTDM имеет возможность предоставлять дополнительные данные для каждого участника системы демонстрации рекламы для осуществления более точного таргетирования.
Стоит отметить, что вне зависимости от настроек абонентского устройства и варианта реализации решение для выполнения функций таргетирования рекламы может выявлять, собирать, анализировать, сопоставлять и направлять в систему демонстрации рекламы различные данные, включая, но не ограничиваясь:
• физические идентификаторы устройства (MAC-адрес, идентификатор сетевого профиля, IMEI, IMSI, MSISDN и другие);
• сетевые параметры запроса (IP-адрес устройства и оператора или провайдера, а также порт(ы));
• адрес и/или домен ресурса, на котором будет демонстрироваться реклама;
• набор адресов и/или доменов ресурсов, которые абонент посещал непосредственно перед запросом на демонстрацию рекламы;
• сведения о местонахождении абонентского устройства (геолокация);
• социально-демографические данные из CRM и других систем учёта абонентов/пользователей сети (пол, возраст и др.);
• интересы и предпочтения абонента, выявленные по результатам анализа поведения абонента в сети, в частности, запрашиваемых и посещаемых Интернет-ресурсов и/или иных действий, включая просмотр рекламы.
Таким образом, решение обеспечивает сбор и формирование набора данных для таргетирования рекламы путём выявления и сопоставления различных идентификаторов абонентского устройства и/или абонента/пользователя и данных пользователя, имеющихся в различных программах и КИС, включая, но не ограничиваясь: браузеры, менеджеры загрузок, мобильные и десктопные приложения, CRM, DMP, DPI и др.
Например, сбор и формирование набора данных для таргетирования рекламы путем сопоставления любых доступных данных из разных источников могут быть выполнены следующим образом. Система RTDM на основе транслированного IP-адреса получает исходный IP-адрес, далее с использованием данной информации определяется МАС-адрес абонентского устройства, с которым сопоставляется любая привязанная к нему информация, хранящаяся в первой базе данных, например номер телефона и имя абонента (под «именем абонента» в данном случае можно понимать любой набор символов, например, логин, никнейм и т.п.), далее с использованием полученного имени абонента система RTDM сопоставляет информацию о возрасте и поле данного абонента из второй базы данных (причем, возможен вариант, когда используемому имени соответствует несколько абонентов с разными возрастами), далее из третьей базы данных определяются (сопоставляются) места, где абонент (все абоненты с теми же именами) часто бывает, из четвёртой базы данных - данные о местоположении абонента в данный момент, и т.п. Причем, в результате сопоставления данных определяется конкретный абонент (остальные абоненты с тем же именем при сопоставлении всех доступных данных отметаются как не подходящие под те или иные данные), которому впоследствии подбирается наиболее подходящая на данном этапе реклама. В другом примере, подсистемой (подсистемами) обработки данных и профилирования (DMP и др.) абоненту присваивается код определённой группы (сегмента пользователей, объединенных одним или несколькими общими признаками), например, женщины, 25-35 лет, модель используемого телефона, высокий уровень дохода, часто бывает в конкретных магазинах, регулярно пользуется Интернетом в метро на определенном его участке, и чем больше параметров/характеристик абонента определяется, тем точнее подбирается реклама. В общем случае, система RTDM получает данные из сервиса NAT и на основе полученных данных подбирает (сопоставляет) другие данные о конкретном абоненте, причем данные NAT могут формироваться по-разному, например, посредством роутера или сервера, которые могут выполнять преобразование сетевых адресов, или с использованием DPI, у которого система RTDM может в режиме реального времени запрашивать данные.
Отдельным активно развивающимся направлением онлайн-рекламы является реклама на предназначенных для приёма и/или просмотра видеоконтента системах/устройствах, подключённых к Интернет, но не использующих браузеры, включая, но не ограничиваясь: ресиверы цифрового телевидения (Set-Top Boxes, STB), игровые приставки, системы SmartTV и IPTV, системы «видео по запросу» (Video-on-Demand, VOD), системы на основе технологии OTT (Over-the-Top) и др. Наиболее существенная проблема в области таргетирования рекламы для пользователей данных устройств заключается в том, что данные устройства/системы не обладают возможностями формировать и передавать во внешние системы данные о пользователе и истории его действий так, как это делают обычные браузеры и/или мобильные приложения.
Система RTDM не требует для идентификации потенциального получателя таргетированной рекламы (пользователя и/или АУ) наличия файлов cookies и производных от них идентификаторов пользователя, АУ а также данных третьих сторон о пользователе и/или его поведении, включая, но не ограничиваясь: ключевые слова, использованные для поиска информации в Интернет, профили пользователя в социальных сетях, история посещённых веб-страниц и др. Таким образом, участники системы демонстрации рекламы (такие как рекламные биржи, DSP, SSP) могут получить от системы RTDM достаточно данных для анализа поведения пользователей, просматривающих контент, и, следовательно, даже в таких условиях с помощью системы RTDM возможно обеспечить эффективное таргетирование рекламы в режиме реального времени
Стоит также отметить, что согласно настоящему изобретению система RTDM использует данные NAT, получаемые от сетевого оборудования оператора или провайдера, что позволяет в режиме реального времени однозначно идентифицировать потенциального получателя таргетированной рекламы (пользователя/АУ) с целью сопоставления запроса на таргетированную рекламу и характеристик пользователя/АУ. Таким образом, технический результат, обеспечиваемый при использовании предлагаемого решения, заключается в установлении в режиме реального времени однозначного достоверного соответствия запроса на рекламу и характеристик абонента/пользователя и его АУ, что в свою очередь обеспечивает:
• выбор таргетированной рекламы для конкретного абонента/АУ в режиме реального времени в случае отсутствия или недостаточности данных о пользователе и его устройстве для использования стандартных средств таргетирования, предусмотренных системами демонстрации рекламы, в том числе работающими по протоколу OpenRTB,
• подтверждение принадлежности запроса на рекламу реальному абоненту, что таким образом позволяет использовать решение для противодействия «ботам» и другим средствам обмана рекламодателей в онлайн-рекламе («antifraud»).
Пример повышения эффективности рекламы от определения принадлежности запроса на рекламу реальному пользователю может быть следующим. При приобретении определенного количества показов рекламного ролика целевой аудитории, рекламодатель нацелен на максимальный «ответ» целевой аудитории. Однако, большая часть указанных показов может быть запрошена специальными программными средствами автоматического просмотра рекламы (так называемыми «ботами»), таким образом большая часть показов будет продемонстрирована не реальным пользователям, а искусственным средствам просмотра, и, следовательно, не принесёт ожидаемого рекламодателем результата. В случае с «ботами» рекламодатель может получить только небольшую часть просмотров реальными людьми (пользователями), тогда как при использовании системы RTDM у рекламодателя появляется возможность определять реальных пользователей и не тратить впустую показы рекламного ролика «ботам», таким образом, рекламное сообщение будет показано большему количеству реальных людей, соответственно, и эффективность приобретенного определенного количества показов данного рекламно-информационного сообщения будет выше. Данный пример также относится к случаю отправления информационных сообщений не рекламного характера, и благодаря использованию модуля RTDM такие информационные сообщения доходят до большего числа реальных людей.
Так, например, при возникновении чрезвычайной ситуации самым главным является своевременное оповещение людей, жизнь и здоровье которых окажутся под угрозой. В таких ситуациях вся ответственность ложится на имеющиеся системы оповещения. Применение систем оповещения пользователей, использующих систему RTDM, позволяет, например, своевременно предупредить большее количество людей об опасности и вовремя начать эвакуацию, что значительно снижает количество пострадавших в чрезвычайных ситуациях.
Стоит отметить также, что для достижения вышеуказанного результата от пользователя/абонента не требуется никаких действий (включая, но не ограничиваясь, изменение настроек абонентского устройства, установка дополнительного программного обеспечения и др.), а скорость доставки рекламно-информационного сообщения значимо не отличается от ситуации с использованием других средств таргетирования при прочих равных условиях.
Таким образом, в отличие от известных способов система RTDM для обеспечения идентификации потенциального получателя таргетированной рекламы (пользователя/АУ) в режиме реального времени:
1) не требует установки каких-либо дополнительных сервисов в периметр оператора или провайдера, следовательно, не оказывает влияния на пользовательский опыт и поток трафика и не приводит к необходимости изменений существующих бизнес-процессов оператора или провайдера, качества обслуживания (QoS) и других факторов взаимодействия абонента/пользователя и оператора или провайдера;
2) не требует перехвата и первичной обработки трафика третьей стороны какими-либо специальными средствами и/или сервисами (например, proxy, adroxy и т.п.), в частности, использующими подмену сертификатов или иные способы детектирования, а также не требует применения какого-либо другого сервиса, получающего запросы от пользователя непосредственно в сети оператора или провайдера;
3) имеет возможность эффективно функционировать при использовании любых протоколов стека TCP/IP, включая протокол HTTPS.
Таким образом, настоящее изобретение не использует какие-либо дополнительные средства или методы, влияющие на существующий процесс взаимодействия АУ с внешним сервисом, будь это SSP, DSP или любой другой сервис.
Необходимо отметить, что настоящее изобретение может быть использовано для формирования не только таргетированного рекламного контента для соответствующего пользователя, но и для формирования информационных сообщений не рекламного характера для соответствующего пользователя, соответственно, все указанные выше и охватываемые формулой изобретения примеры, варианты и модификации могут быть применены с изменениями, понятными для специалистов в данном уровне техники, если они необходимы, для формирования информационных сообщений не рекламного характера.