Connecting web publisher inventory to programmatic exchanges without third-party cookies

Abstract

A system for serving targeted advertising while preserving privacy receives an item of personally identifiable information (PII) from a person using a browser. The item of PII may be, for example, a phone number or email address. The item of PII is hashed and then used to look up a node in an identity graph corresponding to the person. The node contains a link uniquely associated with the person, and the link is returned in encrypted form. An envelope containing the link is created and set as a first-party cookie on the person's browser. When the person uses the browser to visit another website, the envelope is decrypted, and the link is separately encrypted using a different method for each of multiple DSPs to which the link is sent. The DSPs are used to set up display ads on the user's browser, a process that occurs in real time.

Description

[Technical field]

[0001] The present invention relates to connecting web publisher inventory to programmatic exchanges without third-party cookies. [Background technology]

[0002] Third-party cookies are cookies that are set on a browser by a website other than the one the user is currently visiting at the time the cookie is set. They can be used by advertisers or ad servers to track the user's browsing activities across the Internet, to provide targeted advertising, to generate virtual user profiles, or for web analytics purposes. Using third-party cookies, a user may review an item for sale on a first website and then be served ads for that very item or similar items on a second or third website visited by the user at a later time. Third-party cookies allow the collection of data such as the website visited by the user from which the cookie was generated, the subpages visited on the same website, and the time spent on the website and its various subpages. To function properly, most of today's online or "programmatic" advertising ecosystem relies on the use of third-party cookies for user ad targeting. Third-party cookies make online advertising more relevant to users, but they have also been the subject of controversy.

[0003] The majority of web browsers give their users the option to block third-party cookies. Generally, however, the default setting allows third-party cookies, since many websites do not work properly if third-party cookies are blocked. Users must therefore take active action to block third-party cookies, either by changing their browser's default settings or by purchasing an ad-blocker service. Most users, however, do not take these actions. Apple's Safari browser, on the other hand, disables third-party cookies by default. Given the immense popularity of the Safari browser, and Apple products in general, third-party cookies are no longer useful to advertisers on the majority of user devices. It is expected that the number of browsers that block third-party cookies by default will increase, making third-party cookies even less useful to advertisers. Firefox, a browser offered by Mozilla, will follow Safari, and Google, maker of the popular Chrome browser, has already announced its plans to stop supporting third-party cookies. Because Safari, Firefox, and Chrome are used together for the vast majority of all web browsing, the use of third-party cookies for targeted advertising and other purposes quickly becomes infeasible. Device identifiers in the mobile (in-app) ecosystem are subject to the same scrutiny as third-party cookies, and standardized advertising identifiers have not yet emerged in environments such as connected TV. Thus, systems and methods for targeting online ads that do not utilize third-party cookies, while at the same time affording privacy protections to users who are targeted by these ads while browsing, would be highly desirable.

[0004] The references mentioned in this background section are not admitted to be prior art with respect to the present invention. Summary of the Invention [Means for solving the problem]

[0005] The present invention is directed to a standalone system and method for connecting web publisher inventory to advertising exchanges without the use of third-party cookies.

[0006] These and other features, objects and advantages of the present invention will be better understood from a consideration of the following detailed description of the preferred embodiment and the appended claims, taken in conjunction with the drawings, as set forth below. [Brief description of the drawings]

[0007] [Figure 1] 1 is a flow chart illustrating at a high level an implementation of the present invention. [Diagram 2] 2 is a more detailed flow chart illustrating the process of FIG. 1. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0008] Before describing the present invention in greater detail, it is to be understood that the present invention is not limited to the particular embodiments described, and the terminology used in describing the particular embodiments is solely for the purpose of describing those particular embodiments.

[0009] A system according to one embodiment of the present invention is shown in FIG. 1. The process begins in step 10 with a user visiting a publisher's digital property. A "publisher digital property" may be any individual digital asset containing content deemed desirable by a user, including but not limited to news, entertainment, and social media, and may include text, audio, photo, or video content. A branch is optionally selected during processing depending on whether the user is an EU resident or not. If the user is located in the EU, the user is presented with the appropriate consent and data usage terms required under the General Data Protection Regulation (GDPR) applicable to EU residents in step 12. Optionally, this step may be performed for users in any other region or for users in all regions. If the user declines in response to the terms presented in step 14, processing stops in step 16. If the user consents, or if the processing is from a non-EU user, the process proceeds to step 18, where the user sets up a login on a login page, signs up for a newsletter, etc. This step may include any activity by which the user provides user information to the Publisher Website. In the typical case, the user provides personally identifiable information (PII) at this point, such as an email address or phone number, which allows for deterministic identification of the individual later in the process.

[0010] The user's item or items of PII are then sent to the recognition block in step 20 where the system recognizes the authorized authentication event that resulted in the user providing the item of PII. Using the non-limiting example of email as the PII, the email is hashed and then in step 22 a call is made to an application programming interface (API) to access the identity graph. The purpose of this API is to provide a front end to a system that can use the hashed PII to unambiguously and anonymously identify the person to whom the email belongs and return an encrypted identity "envelope" to the recognition block. An identity graph is a data structure that contains nodes for large collections of subjects, such as consumers in a geographic or geopolitical region. By searching the identity graph for the hashed PII, a corresponding entity representing a person can be identified. A link is an identifier that is uniquely associated with a particular person among a large number of such people, such as all such people in a particular geographic or geopolitical region. A link can be of any form, including, for example, a numeric or alphanumeric identifier. One such service that provides these kinds of links is the IdentityLink service offered by LiveRamp, Inc. of San Francisco, California. An IdentityLink is an identifier that is uniquely and persistently associated with a particular user. In some implementations, the link may be hashed in a manner that is specific to each publisher. In this way, publishers cannot accumulate and share links to circumvent the privacy protections afforded to users within the system. The IdentityLink system uses partner encoding (i.e., a separate encryption algorithm for each partner) to provide this functionality. It can then be seen that the item of PII entered by the user in step 18 is converted in step 20 into an encrypted link contained in an envelope.An envelope is an encrypted container that contains one or more links along with associated metadata. The envelope is unique for every request, even when it represents the same underlying information, due to the nature of the encryption applied. Encryption of the data within the envelope helps protect the privacy of the user, whose web browser stores the envelope as a first-party cookie.

[0011] Once the envelope is returned, the recognition block then sets a first-party cookie or local storage object on the user's browser in step 24. This first-party cookie contains the identifying information envelope. Note that since this is a first-party link, it is, from the browser's perspective, provided by the publisher and not by a third party. The system can therefore operate even in environments or browsers where third-party links are blocked.

[0012] Some time after setting the first-party cookie, the envelope is read from the user's browser in step 26 and passed to a supply-side platform (SSP). The SSP is an ad exchange contracted by the publisher to be used to sell ads programmatically in an automated manner. It is used by the publisher to help the publisher sell various types of ads in an automated manner. The SSP implements a service provider "sidecar" in step 28. The sidecar is a subsystem for managing the secure decryption and decryption of anonymous identifiers used in real-time (programmatic) advertising. It generates encoded links to the platform (such as IdentityLink links) at a speed that allows the system to work in a real-time bidding programmatic advertising environment. The sidecar includes an authorization function with managed links, may periodically check for updates to the encoded information, and may periodically report telemetry information. The sidecar receives the securely encrypted payload and, in response, outputs a properly encoded identifier for a downstream platform, such as a demand-side platform (DSP), in step 30. DSPs are similar in function to SSPs, but are used on the marketing (i.e., "demand" side) to buy ad impressions from exchanges in an automated bidding fashion.

[0013] The output from the sidecar is an encoded IdentityLink identifier (or other type of link) that is decoded from the input envelope according to the permissions given to the sidecar and the metadata contained within the envelope. These DSP links are encoded separately for each Demand Side Platform (DSP) that is part of the system in step 32, another step to ensure the privacy of the users whose data is the subject of. In particular, the purpose of this function is to prevent DSPs from colluding with each other and unauthorizedly sharing links to thereby negate the inherent privacy protections afforded to users by the system. Once the DSP-encoded IdentityLink identifiers are distributed to the various DSPs, real-time bidding for programmatic ads and publisher inventory to advertisers or their agencies can then proceed in the usual manner, without the need for third-party cookies or other device identifiers.

[0014] The operation of the present invention may also be described with respect to the flow diagram of FIG. 2. A user accesses a publisher website using a web browser 40. In the course of using the website for informational, commercial, or other purposes, the user is presented with an opportunity to provide an item of PII at box 42. This may be, for example, to receive product updates, alerts about offers, etc. The item of PII shown in FIG. 2 is a phone number, although any such information may be submitted in various implementations. The user may be presented with a "Submit" button 44 in some implementations to transfer the item of PII to the publisher. When the user clicks the submit button, this initiates a series of requests made by a client-side process 46, which in some implementations may be implemented in the JavaScript programming language. The item of PII is hashed on the device to protect privacy and passed to an endpoint on the publisher site at step 50. A content delivery network (CDN) "worker" 54 receives the request and calls the identity graph API 52 to retrieve the envelope corresponding to the item of PII. A CDN, such as that provided by Cloudflare, Inc. of San Francisco, California, is a geographically distributed group of servers that work together to provide extremely fast delivery of Internet content, such as to load HTML (HyperText Markup Language) content, JavaScript files, images, and videos. A CDN does not host the content, but may cache the content, thus working with the hosting servers to increase the speed of execution. A CDN is thus used in this implementation of the invention to intercept requests and respond quickly, although other hardware configurations may be employed in other implementations of the invention. Regardless, the encrypted link returned by the CDN worker 54 or other hardware device is then written to the response via an HTTP cookie in step 56.Step 58 shows exemplary code for setting a first-party cookie on the user's browser.

[0015] Following the above steps, the first party cookie is read in step 60. This may occur as the user navigates between websites using his or her browser. Now, another CDN worker 54 is used to read the HTTP-only cookie and return the cookie as a JavaScript Object Notation (JSON) object. JSON is an interchange format based on JavaScript and commonly used for communication of data on the Internet. In alternative implementations, other formats may be used, such as, but not limited to, extensible Markup Language (XML).

[0016] The present invention provides several advantages over the various process implementations described herein. In some implementations, the process is based on a standalone JavaScript file and therefore has no external dependencies, although the present invention is not limited to the use of JavaScript and alternative techniques may be employed in alternative implementations. It provides the ability to accurately capture common PII entries, such as, but not limited to, phone numbers and email addresses. In some implementations, it may include the ability to apply downcase (i.e., make each character a lowercase string), hash the envelope with the link, and remove whitespace (such as spaces) from plain text emails before requesting. Optionally, in some configurations, the process may accommodate less common PII entry fields. Due to the speed at which the process operates and that it functions in real time, the process has no noticeable delay to the user and therefore does not impact the user experience at the publisher website. In various implementations, the present invention avoids the problems of third-party cookies by writing the envelope to persistent first-party storage associated with the user browser, such as in flash memory or a hard drive. In some configurations, the present invention may easily interface with other prebid.js adapters used in the programmatic advertising ecosystem, and may also easily interface with various third-party systems, such as the Privacy Manager JavaScript API for the consent management platform (CMP) from LiveRamp, Inc. of San Francisco, Calif. Additionally, in some embodiments, the present invention may present a customizable modal to request the user's email or other PII, which may be configured at runtime by passing a configuration object.

[0017] Although the invention has been described with respect to applications in which a cookie cache is used to store link envelopes, the invention is not so limited. In other implementations, the invention may be applied in channels where hardware device identifiers are available to publishers, as is currently the case for mobile devices, including smartphones. In other implementations, the invention may also be applied in channels where device identification information is absent or incomplete, such as an Internet Protocol (IP) address on an addressable television or television set-top box.

[0018] A more detailed description of the software components of an implementation of the invention may now be given. In one embodiment, the invention is implemented as a client-side solution for publishers that provides for detecting email entries in websites, including but not limited to login interactions, and sending updates to users via email. Publishers are required to use a JavaScript library provided as part of the solution and instantiate it with a configuration object so that the provider can recognize the instantiation. It may be included in the source HTML header as a self-hosted JavaScript file or served directly. If the library name is something like ats.js, the self-hosted script may be: <script src="」 / public / javascript / ats.js」">< / script> This can be included just before the closing tag to ensure that the page is fully rendered and ready for user interaction. For high latency pages, ats.js can be added to the . To start the library, a script tag as shown below can be used. <script>var atsScript = document.createElement(’script’);atsScript.onload = function() {window.ats.start({”placementID”:REPLACE_ME,”storageType”:”localStorage”,”detectionType”:”scrape”,”cssSelectors”:[”input[type=text]”,”input[type=email]”],”logging”:”error”});};atsScript.src = ’https: / / ats.rlcdn.com / ats.js’;document.body.appendChild(atsScript);< / script>

[0019] The library manages detection (unless the identity is passed directly), identity analysis, and persistence. The demand partner can then retrieve the link envelope from its storage location either via a direct JavaScript call or by the prebid.js User ID module. The publisher is given the JavaScript library and documentation information to implement the solution from the publisher side. In particular, the publisher team pulls down the ats.js library and the standard prebid.js core library along with a proprietary pre-bid adapter that supports identity envelopes. Once installed, the system receives an email address (or, in an alternative embodiment, other PII) as input from the user through the publisher site. Now assume that the user accesses the publisher website for the desired news or other publisher content. The user navigates to the appropriate web page using the Safari browser on his or her iPhone device, in this example. The user is presented with a request to allow data sharing and responds in the affirmative. The user is then presented with the desired content. After reading, a modal slides down on the screen and asks the user for his or her email address to receive content updates directly in his or her email inbox. If the user wants these updates, he or she agrees and returns to the publisher home page. The publisher user then employs an identity envelope in a popular programmatic advertising solution.

[0020] The solution provider gives the publisher free code to be placed in the header of the publisher’s website. When the site is given a user’s identity, the provider’s API converts the PII (such as email) into an identity token (an envelope containing a link) and stores it in the first-party cookie context on the user’s browser. On page load or subsequent page visits, the header bidder reads the link in the envelope from the first-party cookie and passes it to the SSP. Each SSP then passes the link envelope to the provider’s “sidecar” (as shown in Figure 1) for conversion of the encoded link to the DSP. The DSP-specific encoded link is passed to the DSP along with other information about the inventory in a programmatic ad bid request. The DSP can then make an optimally informed bid with the link combined with both first-party and third-party data.

[0021] As can be seen, the present system and method provides a JavaScript library that publishers can easily incorporate into their properties. The code should not execute until consent has been properly collected as required by applicable law, but should execute as soon as the page can be interacted with by the user. The library may reference a common set of cascading style sheets (CSS) selectors for the "common" location of identifiers. For example, input[type=text]. Publishers may incorporate additional CSS selectors, either in the library file itself or in an additional selectors only file. Using the configured CSS selectors, the system may monitor for interesting on "submit" events that contain valid email addresses as defined by a common email regular expression (regex), for example, / ^[a-zA-Z0-9.!#$%&'*+ / =?^_'{|}~-]+@[a-zA-Z0-9-]+(?:￥.[a-zA-Z0-9-]+)*$ / . Upon recognizing a valid email submission event, the email is hashed (e.g., using the SHA1 algorithm) and receives the hash, {”envelope”:”AhT2iHFFSriRpMW1oRuKYGcT0DJiLzpyAr3z4SnsCWa4-ae2DqE8ru2fdZjmtLC0Tb8-3g”} A network call is made to an API from the system provider that returns an envelope in a JSON payload, such as . The envelope is then written to first-party storage on the client side along with a timestamp of when the value was written or updated. The prebid.js adapter takes over at this point to read the envelope and make it available to ad exchanges in the programmatic advertising ecosystem.

[0022] Configuration options allow publishers to dictate how and when PII should be transformed into a secure encrypted link envelope. The placementID should be used in the configuration object to identify a specific instantiation of the solution to the provider and associate it with a specific publisher. ats.js has two basic modes of operation: Direct and Discovery. In Direct mode, the publisher provides an identifier directly to the ATS library. If the publisher already has the user login information, the publisher can ensure that the user login information is available upon request by including it directly in the publisher's configuration. If the publisher knows that the user provides an identifier on the property but is not able to provide it to the supplier (for example, if there is a newsletter signup provided by a Marketo or Mailchimp widget), the provider can use a document object model (DOM) or uniform resource locator (URL) driven discovery method. Using Direct, the publisher can pass a plain text email address (provider is LiveRamp here) as follows: { ”placementID”:9999, “email”:”imeyers@liveramp.com”} Otherwise, one or more email hashes are passed along: { ”placementID”:9999, ”emailHashes”:[ ”b364fe946d9982c6c547d5637645f9c3dd60ca2aa174e551718509d5dee66ab7”, ”b2c0928035d5f521a880381dc7ec85df7b7e06b3”, “4466aba660dd65e279fb8700f7ff1cb9” ] } In a preferred embodiment, the publisher passes either a plain text email address or multiple hash types to the ATS to ensure the best possible identity analysis (thus matching the user the advertiser wants to reach). Before the email hash is passed, the publisher should preferably ensure that the email is validated against regular expressions, remove whitespace, and downcase all characters in the address. If detection is used, the solution can be configured to accept one or more standard CSS selectors that instruct the solution where to watch for identifiers, such as: { “placementID”:9999, “cssSelectors:[ "Newsletter Signup" ] } Alternatively, the publisher can instruct the solution to watch for an identifier in a URL parameter. For example, if a user is clocked by an email notification and lands at https: / / / example.com / alerts?email_trigger=imeyers@liveramp.com, the publisher can configure the solution to check for the value in the email_trigger parameter. The URL value should be passed under the detectionType attribute. The URL detection could be as follows: { ”placementID”:9999, “detectionType”:”url”, “urlParameter”:”email_trigger” }

[0023] Additionally, there are some advanced configuration options that are expected to be less commonly used: By default, the envelope is written to a first-party cookie (along with a generation timestamp and version information); publishers can alternatively instruct the solution to write to a local storage object by changing the storageType attribute. { ”placementID”:9999, ”storageType”:”localStorage”, ”cssSelectors”:[ "input[type=email]" ] } If publishers wish to run ATS on specific browsers, they can identify them in the browser attribute as follows: { ”placementID”:9999, ”cssSelectors”:[ #newsletterSignup ”browsers”:[ "safari" ] } By default, the solution works with the first library loaded. Alternatively, a detection interval can be specified. This is useful, for example, if a publisher anticipates an asynchronous process for populating a DOM element with a user's email address. An example for detection every 10 seconds could be: { “placementID”:9999, "cssSelectors":[ ], "detectionInterval: 10000 } If it is desired to restrict the pages that the solution will attempt to run on, urlRegex can be used in the configuration. { ”placementID”:9999, ”cssSelectors”:[ ”input[type=email]” ], "urlRegex":"login" } By default, the solution does not log any library events, but it can be useful to view more detailed logs, especially during development. { ”placementID”:9999, ”cssSelectors”:[ #newsletterSignup "logging":"debug" } Other possible values ​​are ["info", "warn", "error"].

[0024] Typically, the only ats.js function that will be called is ats.start(config). This function is passed to the HTML <script>タグ中に配置され、ats.jsのための<script>タグのすぐ後にパブリッシャーの構成オブジェクトとともに呼び出されるべきである。他の可能な関数呼び出しはats. retrieveEnvelope(callback)であり得、それは、構成されたストレージからエンベロープをフェッチし、コールバック関数は随意である。関数がコールバックなしで呼び出された場合、プロミスが戻される。機能がコールバックありで呼び出された場合、エンベロープ値が戻される。別の可能な関数はats.triggerDetection();である。この関数は、パブリッシャーの構成において指定されたCSSセレクタを用いてDOM要素を走査する。

[0025] いくつかの実装形態では、ats.jsはprebid.jsに接続するように最適化されるので、先在するオープン·ソースprebid.jsはats.jsとともに使用される。適切に構成されたprebid.jsファイルがダウンロードされると、パブリッシャーは、必要とされる情報をリンク·ユーザIDモジュールに渡すためにpbjs.setConfigを更新するべきである。prebid.jsのための構成は以下に示されている。pbjs.setConfig({userSync:{userIds:[{name:’identityLink’,params:{pid:’9999’ / / Set your real identityLink placement ID here},storage:{type:’cookie’,name:’idl_env’,expires:1}}],syncDelay:5000}

[0026] 直接アクセスされるJavaScript(登録商標)ライブラリの基礎になるAPIの場合、API呼のためのクエリ·パラメータは、pid(パートナーID番号)と、it(電子メールの識別子タイプ、すなわち、ハッシュされた電子メール、ハッシュされた電話番号など)と、iv(未加工電子メールのハッシュ)と、ct(APIに渡される承諾のタイプ、たとえば、それがGDPRの下で求められるTCFv.1.1又はv2互換承諾文字列であるか否かを示す)と、cv(関連がある承諾文字列値)とを含む。ハッシング法は、例として、MD5、SHA1、及びSHA256を含み得る。好ましくは、すべてのスペース、タブ、及び他の空の文字は処理の前にプレーンテキスト電子メールから削除され、大文字はすべて小文字に変換される。「フェイク」電子メールは識別され、削除される。電話番号の場合、フォーマッティングは、好ましくは、処理の前に削除されるべきである。API呼からの応答は、成功した場合、{”envelope”:”Ao42jiiUNWfvloyXY887EBn801otRTWYnklvjCtw9REF_TMoMWLkeUvzVmQVZG1q”}など、識別情報エンベロープを含んでいる簡単なキー / 値をもつJSONオブジェクトである。ユーザがオプト·アウトされた場合、コンテンツをもたない異なる応答コードがある。

[0027] 上記で説明した実装形態において、本発明はサードパーティ·クッキーの使用を必要としないが、代替実装形態では、そのような機能が与えられ得る。たとえば、アドレス指定能力を高めるために、代替実装形態は標準の画像マッチ·ピクセルの削除をサポートし得る。この場合、パブリッシャーはサービス·プロバイダにピクセル識別子を要求する。ピクセル識別子が取得されると、これは、以下に与えられる例示的なコードを用いてats.js構成中に与えられ得る。{「placementID」: 9999,「cssSelectors」: [「input[type=text]」],「pixelID」: 12345}このコードは、終了< / body>タグのすぐ前のスクリプト·タグを削除し、サービス·プロバイダ·サードパーティ·クッキーを従来の様式で設定することを試みる。

[0028] いくつかの実装形態では、本発明はソーシャル·メディア·ログイン情報と一体化され得る。ソーシャル·ログインは、与えられた情報の有効性において最小の摩擦と高い信頼性をもつ、ユーザを登録するための強力なツールであり得る。たとえば、フェイスブック·プラットフォームとの一体化が望まれる場合について考える。パブリッシャーは、パブリッシャーが、ats.jsとともに使用するためにフェイスブックAPIからユーザ電子メールを取得することを可能にする、フェイスブックJavaScript SDK(software development kit)を使用する可能性がある。パブリッシャーは、以下の実例のようにhtmlコードを使用して「フェイスブックでログ·イン」ボタンを実装し得る。<a onclock-」onLogin()」>Login with Facebookその場合、onLogin関数のためのJavaScript(登録商標)コードは以下のようであり得る。function onLogin() {FB.login(function(response) {if (response.authResponse) {window.FB.api(‘ / me?fields=email’, function(response){callATS(response.email);});} else {console.log(‘not logged in…’);}}, {scope:‘email’})}別の実例として、ユーザを認証するためにGoogleサイン·インを使用するパブリッシャーについて考える。この場合、パブリッシャーは、以下の例示的なJavaScript(登録商標)コードに示されているように、ユーザの電子メール·アドレスを使用してプロバイダのシステムを呼び出すためにそれのonSignIn関数を修正することのみを必要とし得る。function onSignIn(googleUser) {var profile = googleUser.getBasicProfile();var email = profile.getmail());callATS(email);}

[0029] 様々な実装形態では、本発明はまた、Googleタグ·マネージャなど、ウェブサイト·タグ·マネージャと一体化され得る。現在実装されているGoogleタグ·マネージャを使用すると、パブリッシャーは、最初にurl、https: / / tagmanager.google.comに移動し、次いで「新しいタグ」をクリックする。「Untitled Tag」というタグ名は、次いで、「ATS JavaScript」など、作成されるタグを識別するためのものに変更される。ユーザは、次いで、タグ構成セクションをクリックし、「タグ·タイプを選定する」の下で「カスタムHTMLタグ」をクリックする。以下の例示的なHTMLコードが使用され得、パブリッシャーはそれ自体のplacementIDをREPLACE_ME値に置き換える。<script>var atsScript = document.createElement(‘script’);atsScript.onload = function() {window.ats.start({「placementID」: REPLACE_ME,「storageType」:"localStorage」,「detectionType」:"scrape」,「cssSelectors」:[「input[type=text]」,「input[type=email]」],「logging」:"error」});};atsScript.src = ‘https: / / ats.rlcdn.com / ats.js’;document.body.appendChild(atsScript);< / script> The publisher then clicks "Trigger" and selects the trigger to which the publisher wants to connect the ats.js execution. In one instance, the trigger may be configured to fire on all pages. The publisher then saves the changes, clicks "Submit" and then "Publisher", and optionally adds a version change note.

[0030] In some implementations, the present invention may support the use of custom identifiers (Custom IDs) instead of common identifiers such as hashed email addresses and phone numbers. To implement this functionality, a mapping file may be sent to the service provider. In one example, the file should contain the publisher company name, the type of upload, and the current date in ISO8601 format separated by underscores. One example would be "IansCompany_AKP_2020-03-01.tsv". The contents of the file are two tab-delimited columns, in this example entitled "CID" and "Email Address". The first column contains the user ID that the publisher enters into the ats.js system. The second column contains the SHA-256 hashed email address. The email address should be down-cased and whitespace should be removed prior to hashing to ensure accurate results. The file may be sent to the provider via SFTP (SSH File Transfer Protocol).

[0031] Once the provider confirms successful ingestion of the publisher's first mapping file, the publisher then configures ats.js for the newly created custom identifier. The provider gives the publisher the account ID to be included in the configuration. A regular expression for the identifier in customerIDRegex should also be included. The regular expression allows ats.js to validate that the identifier matches the expected pattern. Similar to using ats.js with raw identifiers, the publisher can either pass the identifier directly to the configuration parameters (as customerID) or run ats.js in detection mode. If detection is used, the publisher should ensure that "detectionSubject": "customerIdentifier" is passed along with any other required attributes, such as detectionType. A sample configuration custom ID detection looks like this: { "logging":"debug", "placementID": 9999, “detectionType”:“url”, “urlParameter”: “customerid” “detectionSubject”:“customerIdentifier”, “customerIDRegex”: “[0-9a-f]{32}￥Z”, "accountID":"123456", “customerID”: “0d755934-693e-42c7-b04a-761a9c82df60” } A sample configuration for direct operation of a custom ID would look like this: { "logging":"debug", "placementID": 9999, “customerIDRegex”: “[0-9a-f]{32}￥Z”, "accountID":"123456", “customerID”: “0d755934-693e-42c7-b04a-761a9c82df60” }

[0032] In some implementations, the present invention may have the ability to accept emails passed in URLs from email newsletter products. Generally, since emails may be forwarded to individuals other than the original recipient, it is preferable to leverage a direct login from the user as it gives the best transparency of what data is processed for the user and also ensures that the publisher has accurate identification information. That said, utilizing emails from email newsletter products may be useful for publishers who already have a large pool of identifier users in their email service provider (ESP). To allow ats.js to leverage these identifiers, publishers should modify their standard newsletter or transactional emails to pass the identifier when the user clicks through to visit the site. Publishers would add a new link (or modify existing links) to add the additional query parameters, and then append [email] to represent the dynamically populated representation of the user's email address. One example URL could be https: / / authenticated-traffic-solution.com?user_id=[email]. The publisher then configures ats.js to detect and analyze the email address via its campaign monitor. The following example JavaScript can be used and modified to use the publisher's actual placementID and the query parameters used when setting up the link: { "placementID":9999, “storageType”: “localStorage”, “detectionType”:“url”, “detectionSubject”:“email”, "logging":error", “urlParameter”: “user_id” }

[0033] In the specific instance where mailchimp is used for email campaigns, an additional query parameter would append *|EMAIL|* to the dynamically populated representation of the user's email address. An example url would be https: / / authenticated-traffic-solution.com?user_id=*|email|*. The publisher would then click "insert" to update the link. In the preview, the publisher would click <<Test Email Address> In production, this field will be populated with the recipient's email. The publisher can then configure ats.js to detect and analyze the email address passed through Mailchimp, the following example configuration can be used: { "placementID":9999, “storageType”:“localStorage”, “detectionType”:“url”, “detectionSubject”:“email”, "logging":error", “urlParameter”: “user_id” }

[0034] The systems and methods described herein may be implemented by any combination of hardware and software in various embodiments. For example, in one embodiment, the systems and methods may be implemented by a computer system or collection of computer systems, each of which includes one or more processors executing program instructions stored on a computer-readable storage medium coupled to the processor. The program instructions may implement the functions described herein. The various systems and displays shown in the figures and described herein represent example implementations. The order of any method may be changed and various elements may be added, modified, or omitted.

[0035] A computing system or computing device as described herein may implement the hardware portion of a cloud computing system or a non-cloud computing system forming part of various implementations of the present invention. The computing system may be any of a variety of types of devices including, but not limited to, a commodity server, a personal computer system, a desktop computer, a laptop or notebook computer, a mainframe computer system, a handheld computer, a workstation, a network computer, a consumer device, an application server, a storage device, a telephone, a mobile phone, or generally any type of computing node, compute node, compute device, and / or computing device. A computing system includes one or more processors (any of which may include multiple processing cores, which may be single-threaded or multi-threaded) coupled to a system memory via an input / output (I / O) interface. The computing system may further include a network interface coupled to the I / O interface.

[0036] In various embodiments, the computer system may be a single processor system including one processor or a multiprocessor system including multiple processors. The processors may be any suitable processor capable of executing computational instructions. For example, in various embodiments, they may be general purpose processors or embedded processors implementing any of a variety of instruction set architectures. In a multiprocessor system, each of the processors may generally, but not necessarily, implement the same instruction set. The computer system also includes one or more network communication devices (e.g., network interfaces) for communicating with other systems and / or components over a communications network, such as a local area network, a wide area network, or the Internet. For example, a client application running on the computing device may use the network interface to communicate with a server application running on a single server or a cluster of servers implementing one or more of the components of the system described herein in a cloud computing or non-cloud computing environment as implemented in the various subsystems. In another example, an instance of a server application running on the computer system may use the network interface to communicate with other instances of the application that may be implemented on other computer systems.

[0037] The computing device also includes one or more persistent storage devices and / or one or more I / O devices. In various embodiments, the persistent storage devices may correspond to disk drives, tape drives, solid-state memory, other mass storage devices, or any other persistent storage devices. A computer system (or a distributed application or an operating system running thereon) may store instructions and / or data in the persistent storage devices as required, and may retrieve the stored instructions and / or data as needed. For example, in some embodiments, a computer system may implement one or more nodes of a control plane or control system, and the persistent storage may include solid-state drives (SSDs) attached to the server nodes. Multiple computer systems may share the same persistent storage device, or may share a pool of persistent storage devices, where the devices in the pool of persistent storage devices represent the same or different storage technologies.

[0038] A computer system includes one or more system memories that may store code / instructions and data accessible by one or more processors. System memory may include multiple levels of memory and memory caches in a system designed to swap information in memory based on access speed, for example. Interleaving and swapping may be extended to persistent storage in virtual memory implementations. Technologies used to implement memory may include, by way of example, static random-access memory (RAM), dynamic RAM, read-only memory (ROM), non-volatile memory, or flash-type memory. As with persistent storage, multiple computer systems may share the same system memory or may share a pool of system memory. One or more system memories may include program instructions that are executable by one or more processors to implement the routines described herein. In various embodiments, the program instructions may be coded in binary, assembly language, any interpreted language such as Java, compiled languages ​​such as C / C++, or any combination thereof. The specific languages ​​given herein are merely examples. In some embodiments, the program instructions may implement multiple separate client, server nodes, and / or other components.

[0039] In some implementations, the program instructions may include instructions executable to implement an operating system (not shown), which may be any of a variety of operating systems, such as UNIX, LINUX, Solaris, MacOS, or Microsoft Windows. Any or all of the program instructions may be provided as a computer program product or software, which may include a non-transitory computer-readable storage medium having stored thereon instructions that may be used to program a computer system (or other electronic device) to execute a process according to various implementations. A non-transitory computer-readable storage medium may include any mechanism for storing information in a form (e.g., software, processing application) readable by a machine (e.g., a computer). In general, a non-transitory computer-accessible medium may include a computer-readable storage medium or memory medium, such as a magnetic or optical medium, e.g., a disk or DVD / CD-ROM coupled to a computer system via an I / O interface. A non-transitory computer-readable storage medium may also include any volatile or non-volatile medium, such as a RAM or ROM, which may be included as system memory or another type of memory in some embodiments of a computer system. In other implementations, the program instructions may be communicated using optical, acoustic or other forms of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.) conveyed over a communication medium such as a network and / or wired or wireless link, such as may be implemented via a network interface. The network interface may be used to interface with other devices, which may include other computer systems or any type of external electronic device.In general, system memory, persistent storage, and / or remote storage on other devices accessible through a network may store data blocks, replicas of data blocks, metadata associated with the data blocks and / or their states, database configuration information, and / or any other information usable in implementing the routines described herein.

[0040] In some implementations, the I / O interface may coordinate I / O traffic between the processor, system memory, and any peripheral devices in the system, including through a network interface or other peripheral interface. In some embodiments, the I / O interface may perform any necessary protocol, timing, or other data conversion to convert data signals from one component (e.g., system memory) into a format suitable for use by another component (e.g., processor). In some embodiments, the I / O interface may include support for devices attached via various types of peripheral buses, such as, for example, variations on the Peripheral Component Interconnect (PCI) bus standard or the Universal Serial Bus (USB) standard. Also, in some embodiments, some or all of the functionality of the I / O interface, such as the interface to the system memory, may be incorporated directly into the processor.

[0041] The network interface may enable data to be exchanged between the computer system and other devices attached to the network, such as, for example, other computer systems (which may implement one or more storage system server nodes, primary nodes, read-only nodes, and / or clients of the database system described herein). Additionally, the I / O interface may enable communication between the computer system and various I / O devices and / or remote storage. The input / output devices may, in some embodiments, include one or more display terminals, keyboards, keypads, touchpads, scanning devices, voice recognition devices or optical recognition devices, or any other device suitable for inputting or retrieving data by one or more computer systems. These may be directly connected to a particular computer system, or may generally be connected to multiple computer systems in a cloud computing environment, grid computing environment, or other system involving multiple computer systems. There may be multiple input / output devices in communication with the computer system, or may be distributed on various nodes of a distributed system including the computer system. The user interfaces described herein may be viewed by a user using various types of display screens, which may include CRT displays, LCD displays, LED displays, and other display technologies. In some implementations, input may be received by the display using touch screen technology, while in other implementations, input may be received through a keyboard, mouse, touchpad, or other input technology, or any combination of these technologies.

[0042] In some embodiments, similar input / output devices may be separate from the computer system and may interact with one or more nodes of a distributed system that includes the computer system via a wired or wireless connection, such as via a network interface. The network interface may generally support one or more wireless networking protocols (e.g., Wi-Fi / IEEE 802.11, or another wireless networking standard). The network interface may support communication over any suitable wired or wireless general data network, such as, for example, other types of Ethernet networks. Additionally, the network interface may support communication over a telecommunications / telephony network, such as an analog voice network or a digital fiber communications network, over a storage area network, such as a Fibre Channel storage area network, or over any other suitable type of network and / or protocol.

[0043] Any of the distributed system embodiments described herein, or any of their components, may be implemented as one or more network-based services in a cloud computing environment. For example, read-write nodes and / or read-only nodes in a database hierarchy of a database system may present database services and / or other types of data storage services that employ the distributed storage system described herein as a network-based service to clients. In some embodiments, the network-based services may be implemented by software and / or hardware systems designed to support interoperable machine-to-machine interaction over a network. A web service may have an interface described in a machine-processable format, such as Web Services Description Language (WSDL). Other systems may interact with the network-based service in a manner prescribed by the network-based service's interface description. For example, a network-based service may define various operations that other systems may invoke and may be expected to conform to when requesting various operations.

[0044] In various embodiments, a network-based service may be requested or invoked through the use of a message that includes parameters and / or data associated with a network-based service request. Such a message may be formatted according to a particular markup language, such as Extensible Markup Language (XML), and / or may be encapsulated using a protocol, such as Simple Object Access Protocol (SOAP). To perform a network-based service request, a network-based service client may assemble a message that includes the request and communicate the message to an addressable endpoint (e.g., a Uniform Resource Locator (URL)) that corresponds to the web service using an Internet-based application layer transport protocol, such as Hypertext Transfer Protocol (HTTP). In some embodiments, a network-based service may be implemented using Representational State Transfer (REST) ​​techniques rather than message-based techniques. For example, a network-based service implemented according to REST techniques may be invoked through parameters included in an HTTP method, such as PUT, GET, or DELETE.

[0045] Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. Although any methods and materials similar or equivalent to those described herein can also be used in the practice or testing of the present invention, a limited number of exemplary methods and materials have been described herein. It will be apparent to those skilled in the art that many more modifications are possible without departing from the inventive concepts herein.

[0046] All terms used herein should be interpreted in the broadest possible manner consistent with the context. In particular, the terms "comprise" and "comprising" should be interpreted in a non-exclusive manner to refer to elements, components, or steps, indicating that a referenced element, component, or step may be present or utilized or combined with other elements, components, or steps not specifically referenced. When Markush groups or other groupings are used herein, all individual members of the group and all possible combinations and sub-subcombinations of the group are intended to be individually included in the disclosure. When ranges are stated herein, the disclosure is intended to specifically include all points within that range and all subranges within that range. All references cited herein are incorporated by reference herein, unless inconsistent with the disclosure herein.

[0047] The present invention has been described with reference to certain preferred and alternative embodiments, which are illustrative only and not limiting of the full scope of the invention, which is limited only by the claims in any subsequent non-provisional patent application.

Claims

1. 1. A system for connecting publisher inventory to an exchange, comprising: an identity graph including a plurality of nodes each including data regarding a person and a link uniquely associated with such person, said identity graph being configured to receive an item of personally identifiable information (PII), search said plurality of nodes for a person matching said item of PII, and return said links corresponding to said person matching said item of PII; b. a recognition subsystem, said recognition subsystem comprising: i. receiving said item of PII from a publisher server; ii. sending said item of PII to said identity graph; iii. receiving, from the identity graph, the link for the person corresponding to the item of PII; iv. creating an envelope containing the link and a set of metadata including encryption permissions; v. creating a first party cookie that includes the envelope; vi. sending the envelope to the publisher; a recognition subsystem configured to: c. a sidecar subsystem configured to receive the envelope containing the link from the first party cookie and output an encrypted link, the encrypted link being encrypted by the sidecar subsystem according to the encryption permissions in the set of metadata in the envelope; Including, the system.

2. The system of claim 1 , wherein the recognition subsystem is further configured to hash the item of PII prior to sending the item of PII to the identity graph.

3. The system of claim 2 , wherein the recognition subsystem is further configured to set the first-party cookie on a user browser.

4. 4. The system of claim 3, wherein the sidecar is further configured to decrypt the link in the envelope.

5. 5. The system of claim 4, wherein the sidecar is further configured to output the encrypted link to one of a plurality of demand-side platforms (DSPs).

6. 6. The system of claim 5, wherein the sidecar is further configured to encode the encrypted link in a different manner for each of the multiple DSPs, such that DSPs cannot share a link to defeat privacy protection.

7. The system of claim 4 , wherein the sidecar operates in real time.

8. The system of claim 1 , wherein the recognition subsystem is further configured to encrypt the envelope.

9. 4. The system of claim 3, further comprising a publisher web server that includes a publisher digital property.

10. 10. The system of claim 9, further comprising a user computing device, the user computing device comprising a digital storage area configured to receive the publisher user data set.

11. 11. The system of claim 10, wherein the publisher user data set includes first-party cookies.

12. 1. A method for connecting publisher inventory to an exchange, comprising: a. receiving an item of PII relating to a person; b. searching the identity graph for a node in the identity graph that matches the item of PII; c. returning links from the matched nodes that are uniquely associated with the person; d. setting a publisher user data item on a device operated by the person, the publisher user data item being a first-party cookie that includes an envelope containing the link and a set of metadata including an encryption permission; e. reading the first party cookie some time after setting the publisher user data item on the device to retrieve the envelope and the set of metadata; f. generating an encrypted link, said encrypted link being encrypted by a sidecar subsystem according to said encryption permissions in said set of metadata in said envelope; g. sending the encrypted link to one of a plurality of demand side platforms (DSPs), where the encryption permissions in the set of metadata are tailored to a particular one of the plurality of DSPs; A method comprising:

13. 13. The method of claim 12, further comprising hashing the item of PII prior to searching the identity graph for the nodes in the identity graph that match the item of PII.

14. The method of claim 12 further comprising the step of encrypting the envelope.

15. 13. The method of claim 12, further comprising the step of encoding the link differently for each DSP of the plurality of DSPs to which the link is sent.

16. The method of claim 12 , wherein the step of reading the envelope to retrieve the links is performed in real time.

17. 17. The method of claim 16, further comprising presenting a first digital property to the person at the device in response to a first request from the device.

18. 20. The method of claim 17, further comprising receiving the item of PII from the person through the device at the first digital property.

19. 20. The method of claim 18, further comprising the step of requesting user consent prior to the step of receiving the item of PII from the person through the device at the first digital property.

20. 20. The method of claim 19, wherein the item of PII is either an email address or a phone number.

21. 20. The method of claim 19, wherein the item of PII is a custom identifier that includes individual identifying information.

22. 20. The method of claim 18, further comprising presenting a second digital property to the person at the device in response to a second request from the device, the second digital property being different from the first digital property.

23. 23. The method of claim 22, further comprising serving a digital advertisement to the device of the person while visiting the second digital property, the digital advertisement being selected from a plurality of possible digital advertisements based on an identification of the person.

24. 1. A method for connecting publisher inventory to an exchange, comprising: a. displaying, at a first publisher server, a user interface at a consumer device including an input area for an item of personally identifiable information (PII); b. receiving said item of PII from said user interface; c. encrypting said item of PII; d. setting a first party cookie on said consumer device, said first party cookie including said encrypted item of PII; e. following the step of setting the first-party cookie on the consumer device, reading the first-party cookie at a second publisher server; f. searching an identity graph comprising a plurality of nodes and identifying one of the plurality of nodes in the identity graph that matches the encrypted item of PII in the first party cookie; g. selecting a digital advertisement from a plurality of possible digital advertisements based on data at the one of the plurality of nodes in the identity graph that matches a link in the first party cookie; h. displaying said digital advertisement on said consumer device; A method comprising:

25. 25. The method of claim 24, further comprising sending the encrypted item of PII to each of a plurality of demand side platforms (DSPs) in a programmatic advertising ecosystem.

26. 25. The method of claim 24, wherein the step of setting a first-party cookie on the consumer device is performed in real time.

27. 25. The method of claim 24, wherein the item of PII is an email address.

Images