Cloud-native activation and segmentation
By processing data activation and segmentation within cloud-based data warehouses using anonymized identifiers and local compute resources, the method addresses computational and privacy issues in large datasets, achieving reduced data movement and lower costs.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- LIVERAMP
- Filing Date
- 2024-02-09
- Publication Date
- 2026-04-14
AI Technical Summary
Data activation and segmentation processes for large datasets are computationally expensive and pose privacy risks due to the need to send entire datasets across networks, especially when they contain personally identifiable information (PII).
Implementing data activation and segmentation within a cloud-based data warehouse environment, minimizing data movement by processing only anonymized customer identifiers, and leveraging built-in cloud functionalities and API callbacks to perform computations locally.
Reduces data movement by up to 85%, lowers computational costs, enhances privacy, and enables real-time activation and segmentation without exposing sensitive data, thus reducing infrastructure costs for service providers.
Smart Images

Figure 2026511512000001_ABST
Abstract
Description
Technical Field
[0001] Data owners often want their data to be "activated" to enable more accurate messaging to their customers, i.e., extended with additional data such as more complete contact data, other demographic data, or audience-related data.
Background Art
[0002] Data can also undergo "segmentation", which means adding data that helps the data owner more accurately target messages to its customers by dividing customers into similar segments, where similarity can be defined in various ways. For example, segments can be defined by consumer geography or activity. Generally, activation / segmentation requires the data owner to send the entire dataset to a service provider, who then sends the data back after it has been extended. In the case of extremely large datasets that span terabytes, the computational costs and time involved in sending this data back and forth become prohibitively expensive in some applications. Further, sending such large datasets across a network poses a privacy risk because there is always some risk that such data could be intercepted by a bad actor, and these datasets generally contain personally identifiable information (PII).
[0003] The references described in this background art section are not admitted to be prior art with respect to the present invention.
Summary of the Invention
[0004] The present invention provides a solution to data activation and segmentation problems that, in various embodiments, leverage the fact that today the vast majority of datasets are stored in cloud-based data warehouse environments. Instead of sending the entire dataset, only a single column of data, such as an anonymized customer identifier or household identifier, needs to be sent. The reduction in data requirements is a result of the computation being pushed down to the data owner's cloud-based data warehouse environment. This novel architectural approach dramatically reduces the amount of data being moved and protects privacy because only anonymized data is being sent over insecure networks. All actual processing for activation and / or segmentation takes place in the customer's environment, using compute resources available within the customer's cloud computing environment, rather than at the provider. In some embodiments of the present invention, the implementation of this process leverages built-in functionality in the cloud environment, as well as external API callbacks to the provider's application programming interface (API) set up for this purpose. If the necessary functionality already exists in the data owner's environment, the provider functionality does not need to be developed and deployed on the data owner's side to enable this reduction in data flow over the network.
[0005] In some embodiments, an architecture for implementing the present invention comprises an integration component and an activation component. The integration component may perform tasks such as mapping consumer audiences to database resources, setting up data change capture functionality to track changes in consumer audiences for desired messages, and setting up user-defined external functionality to fan out data to activation. The activation component is involved in setting up tasks to dynamically calculate segments and fan out data.
[0006] The present invention enables customer data in a cloud-based data warehouse to be natively activated at the destination by minimizing data movement in various embodiments. The invention minimizes data movement between customers and downstream applications by providing a way for data owners to create segments for the data they maintain in their data warehouse, dynamically calculating segments that should be pushed down to the destination via advanced embedded provider-specific features. Since modern cloud-based data warehouse providers include these key features as existing functionalities, various embodiments of the invention can be specifically adapted to one or more desired cloud environments.
[0007] In some embodiments of the present invention, all compute and storage are on the cloud, and therefore the present invention provides a native data application on a modern data warehouse for reverse extract transform load (ETL) segmentation. In a traditional ETL data pipeline, data is first extracted from various sources, and then the extracted data is transformed. This transformation may involve cleaning, aggregating, de-duplicating, or reformatting the data to ensure that the data is consistent and ready for analysis. Finally, the transformed data is loaded into a data warehouse, where it can be accessed for analysis and reporting purposes. Reverse ETL reverses this traditional process. In a modern data stack, companies often aggregate their data into a centralized cloud-based data warehouse, but this data must be operationalized to use the insights gained from it in day-to-day business operations. Reverse ETL processing begins with extracting data from a centralized data warehouse and then performing a transformation. However, this transformation is performed to suit the needs of various operational tools. Instead of loading the data into the data warehouse, the data is then loaded into operational systems such as CRM (Customer Relationship Management) systems, marketing platforms, customer service tools, and other business applications. This enables coordinated messaging campaigns, enhanced customer service through real-time access to customer data, and optimization of sales strategies and decisions. In some embodiments, the present invention enables activation and segmentation as part of this reverse ETL process.
[0008] These and other features, purposes, and advantages of the present invention will be better understood in consideration of the following detailed description of preferred embodiments and the appended claims, together with the drawings, as described below. [Brief explanation of the drawing]
[0009] [Figure 1] This is a diagram illustrating the system architecture overview according to one embodiment of the present invention. [Figure 2] This figure shows a workflow for a process implemented on the architecture of Figure 1, according to one embodiment of the present invention. [Figure 3] This is a diagram of a computing environment according to one embodiment of the present invention. [Modes for carrying out the invention]
[0010] Before the present invention is described in further detail, it should be understood that the scope of the present invention is limited only by the claims, and that the invention is not limited to the specific embodiments described, nor is it limited to the specific embodiments, and that the terms used in describing those specific embodiments are merely for the purpose of describing those specific embodiments and not to limit them.
[0011] A system providing one embodiment of the present invention leverages the native features of a cloud-based data warehouse environment. One example describes a data warehouse using the Snowflake® platform from Snowflake Inc. The Snowflake® environment is used in the following example for clarity, but the present invention is not limited thereto. Other cloud providers have similar features, and the present invention may be implemented on other cloud provider infrastructures in alternative embodiments, only a few of which are specifically enumerated herein. Key features utilized by systems in various embodiments include support for change data capture, task scheduling, and the ability to make calls to external application programming interfaces (APIs).
[0012] Change data capture (CDC) refers to the process of identifying and capturing changes made to data in a database and then distributing those changes in real time to downstream processes or systems. CDC is primarily used to maintain the state of a data warehouse, but it can also be used for other purposes, such as those described herein by the systems. In a Snowflake® environment, the STREAMS feature is used to provide CDC functionality, although change history can be used in, for example, a BigQuery® data warehouse environment provided by Google. The STREAMS feature creates a change table that shows what has been changed at the row level between two transaction points on a dataset.
[0013] Task scheduling can be performed in a Snowflake® environment using the environment's serverless task features. Similarly, scheduled queries can be used for task scheduling in a BigQuery® environment. In addition to these main features, there are implementation details specific to each data warehouse environment, such as the languages used to execute Data Definition Language (DDL) and Data Manipulation Language (DML) commands for defining data structures and manipulating data.
[0014] An overall architecture for a particular implementation of the present invention can be described with reference to Figure 1. Two computing environments, a provider environment 10 and a customer environment 14, communicate via a network. This network could be, for example, the internet. A workflow API 12 within the provider environment 10 is used to initiate a call to utilize computing resources in the customer environment 14. Cloud compute 16 provides computing resources located at the customer's location within the customer environment 14. Storage is provided for cloud compute 16 by a customer table 18, which is also located within the cloud-based customer environment 14.
[0015] Cloud compute 16 can also communicate with provider buckets 20 within provider environment 10. This enables computing resources in customer environment 14 to manipulate data to be returned to provider environment 10. A second API is provided in the form of a distribution API 22, which can utilize data in provider buckets 20 to complete output tasks. These output tasks can be sent to destination 24.
[0016] The workflow according to an implementation of the present invention can be described as follows, starting with the integration part and referring to Figure 2: The first step is to link the customer data warehouse to an internal customer identifier (ID) in identifier linking step 30. The customer begins by creating a service account linked to the customer's organization, calling a stored procedure referred to herein as “nativeapp.auth_setup”. The stored procedure securely stores the service account and allows other stored procedures for mounting audiences and creating segments to use the service account to access the customer account.
[0017] The second step is audience mounting from the database table in audience mounting step 32. Once permission is granted, the customer links its Snowflake® table in customer table 18 to the provider's internal system in provider environment 10 by calling another stored procedure, referred to herein as “nativeapp.mount_audience(TABLE_REFERENCE, AUDIENCE_ID_COLUMN)”. The stored procedure discovers the table schema and, using a service account, creates the relevant asset in the provider's internal metadata database stored in provider bucket 20. Once the audience is linked, non-technical users, such as marketers, can access the asset within the user interface used to create segments.
[0018] Historically, provider systems required audience data to be moved to the provider's internal database for the internal user interface to operate on the audience to activate segments. This architecture virtually links the dataset to assets within the customer silo and does not move the data outside the customer environment 14. The provider system stores only the metadata of the assets in the customer environment 14 and synchronizes that metadata as it changes over time as described below.
[0019] The third step is to create segments from the audience in step 34, which involves creating segments. While audiences are mapped by technical people such as data analysts, segment creation is often directed by non-technical people such as marketers. The provider environment 10 provides a user interface for non-technical users to manipulate audience data and create segments based on criteria desired by the non-technical users.
[0020] Operating within the customer environment 14 and using customer cloud compute 16, the provider's segment builder generates a Structured Query Language (SQL) query such as SELECT[user_identifier]FROM[audience_data]WHERE[segment_criteria]. This is done in step 36, which generates the select query. In one example, [user_identifier] could be RampID®, a LiveRamp, Inc. technology for identity information resolution. Each identifier in the RampID® system is uniquely associated with a specific entity within a set of entities, such as a consumer or household. Customers often use the provider's native application to resolve customer PII data to RampID® identifiers before generating segments. [audience_data] is the asset linked by the customer in the second step. [segment_criteria] is programmatically generated based on user input in the user interface.
[0021] The provider system generates a view for segment queries to track segment data and links that view to the provider's internal metadata database in customer table 18. The customer later delivers the segments through their activation channel, which triggers the provider's ETL system to move the [user_identifier] data from the customer environment 14 to the provider's internal database during the initial setup.
[0022] The fourth consideration is keeping segments up-to-date with source data. Often, customers have their own ETL systems and may update their data in their data warehouses, which results in changes to the [audience_data] table. As internal data changes over time, generated segment views also change dynamically. A provider system may support segments with billions of user identifiers, but only a small portion of the data changes over time. To minimize data movement and make the system more near real-time, the provider system tracks changes using a feature called CHANGE_TRACKING and creates a STREAM on the segment view to enable the CDC (Change Data Capture) mechanism described above.
[0023] The provider system sets up a TASK in Snowflake®, which is triggered in a scheduled manner to pull data from the STREAM to find new and deleted rows representing users who entered and left the segment, respectively. This is done in TASK creation step 38. User identifiers are stored in a Google Cloud Storage (GCS) bucket, and an internal API, the delivery API 22, which activates the segment, is called from a stored procedure to send the data to destination 24.
[0024] In one embodiment of the present invention, the amount of data movement required using traditional methods was examined against that used according to the implementation form of the present invention. Using an exemplary consumer dataset considered to represent a general case, an embodiment of the present invention achieved an 85% reduction in data movement across the network between the provider and the data owner. That movement reduction is due to only a portion of the dataset uploaded to the provider system, rather than the entire audience dataset, being the anonymized portion (such as anonymized customer identifiers or household identifiers). In other words, instead of sending the entire dataset (often extremely large), only a single column of the table dataset is required.
[0025] It will be appreciated that, in addition to reducing data movement and thus computational cost, embodiments of the present invention provide other advantages. For example, it is privacy-conscious since the provider does not host the complete consumer dataset. Further, the system operates in a more nearly real-time mode, and thus activation and segmentation can be used with additional applications that do not conform to the batch-mode operation of existing systems. Another advantage is that since the system utilizes client-side rather than provider-side computing resources, the infrastructure cost for the provider to build and maintain the system is significantly reduced.
[0026] In one embodiment of the present invention, a cloud-native data activation method includes the steps of: mapping a consumer audience, which includes a plurality of consumer data stored in a cloud-based customer environment, to a source database in a provider environment using a subset of the plurality of consumer data in the consumer audience sent from the customer environment to a cloud-based provider environment; operating a data change capture function in the customer environment, wherein the data change capture function tracks changes to the plurality of consumer data in the consumer audience; configuring a user-defined external function in the customer environment for activating the plurality of consumer data; and dynamically calculating a set of segments for the consumer data in the customer environment, wherein the step of calculating the set of segments includes adding additional data to the plurality of consumer data, which is sent from the provider environment to the customer environment, and calculating the additional data, which divides the plurality of customer data into similar segments, thereby enabling the customer to more accurately target messages to the consumer audience.
[0027] In another example of an embodiment of the present invention, a machine includes one or more computer processors and a memory space storing instructions that, when executed by the one or more computer processors, cause the one or more computer processors to link a set of audience data in a customer data warehouse to a set of internal customer identifiers in a cloud-based client environment, mount a set of audience data from a set of database tables stored within the cloud-based client environment, link the audience data to a cloud-based provider environment remotely located from the cloud-based client environment and connected to the cloud-based provider environment by a network, create a plurality of segments from the audience data by receiving criteria entered through a user interface to manipulate the audience data and create segments, and track changes to the plurality of segments in the audience data using change data capture features within the cloud-based client environment.
[0028] In another embodiment of one aspect of the present invention, a method for cloud-based data activation includes the steps of: linking a set of audience data in a customer data warehouse to a set of internal customer identifiers in a cloud-based client environment; mounting audience data from a set of database tables stored within the cloud-based client environment; linking the audience data from the cloud-based client environment to a remote cloud-based provider environment, wherein the cloud-based client environment and the cloud-based provider environment are communicating over a network; creating segments from the audience data by receiving criteria entered from a user interface in order to manipulate the audience data and create segments; and tracking changes to segments in the audience data using change data capture features native to the cloud-based client environment.
[0029] In another embodiment of one aspect of the present invention, a computerized system for cloud-native activation comprises a provider environment comprising a Workflow Application Programming Interface (API), a Delivery API, and a provider bucket communicating with the Delivery API, and a customer environment communicating with the provider environment across a network, wherein the customer environment comprises a cloud compute cluster communicating with the Workflow API and a number of customer tables communicating with the cloud compute cluster, the cloud compute cluster being configured to perform actions on the customer tables in response to requests from the Workflow API, the Workflow API being configured to initiate calls to utilize cloud compute in the customer environment, and the cloud compute cluster being The cloud compute cluster is configured to link multiple customer tables to an internal set of customer identifiers, and to link the multiple customer tables to a set of provider data in a provider bucket in order to create provider metadata related to the multiple customer tables in a provider bucket without moving all the data in the multiple customer tables outside the customer environment and into the provider environment, and to create segments within the multiple customer tables using data from the provider bucket in the provider environment, and to perform change data capture to track changes to the multiple customer tables over time and to communicate metadata about changes outside the customer environment to the provider bucket in the provider environment.
[0030] The methods described herein can be implemented in various embodiments by any combination of hardware and software. For example, in one embodiment, the method may be implemented by a computer system (for example, a computer system as in Figure 3) or a set of computer systems, each of which includes one or more hardware processors that execute program instructions stored in a computer-readable physical storage medium coupled to hardware processors, within the provider environment 10 and the customer environment 14. The program instructions may implement the functionality described herein (for example, the functionality of various hardware servers and other components that implement the network-based cloud and non-cloud computing resources described herein). The various methods shown in the figures and described herein represent exemplary implementations. The order of any method may be changed, and various elements may be added, modified, or omitted.
[0031] Figure 3 is a block diagram showing exemplary computer hardware systems in various embodiments, as previously mentioned. Computer system 140 may implement the hardware portion of a cloud computing system as forming part of various implementations of the present invention. Computer system 140 may be any of various types of hardware devices, including, but not limited to, commodity servers, personal computer systems, desktop computers, laptop or notebook computers, mainframe computer systems, handheld computers, workstations, network computers, consumer devices, application servers, physical storage devices, telephones, mobile phones, or generally any type of computing node, compute node, compute device, and / or hardware computing device.
[0032] The computer system 140 includes one or more hardware processors 140a, 141b...141n (any of which may include multiple processing cores, some of which may be single-threaded or multi-threaded) coupled to physical system memory 142 via an input / output (I / O) interface 144. The computer system 140 may further include a network interface 146 coupled to the I / O interface 144. In various embodiments, the computer system 140 may be a single-processor system including one hardware processor 140a, or a multi-processor system including multiple hardware processors 140a, 141b...141n, as shown in Figure 3. Processor 140a, etc., may be any suitable processor capable of executing computing instructions. For example, in various embodiments, processor 140a, etc., may be a general-purpose processor or embedded processor implementing one of various instruction set architectures. In a multi-processor system, each of the processors 140a, etc., may, though not necessarily, implement the same instruction set. Computer system 140 also includes one or more hardware network communication devices (e.g., network interface 146) for communicating with other systems and / or components across communication networks, such as a local area network, a wide area network, or the Internet. For example, a client application running on system 140 may use network interface 146 to communicate with a server application running on a single hardware server or a cluster of hardware servers that implement one or more of the components of the system described herein in a cloud computing environment, which are implemented in various subsystems. In another example, an instance of a server application running on computer system 140 may use network interface 146 to communicate with other instances of the application that may be implemented on other computer systems.
[0033] In the illustrated embodiment, the computer system 140 also includes one or more physical persistent storage devices 148 and / or one or more I / O devices 150. In various embodiments, the persistent storage device 148 may correspond to a disk drive, tape drive, solid memory or drive, other mass storage device, or any other persistent storage device. The computer system 140 (or a distributed application or operating system running on it) may, as needed, store instructions and / or data in the persistent storage device 148 and retrieve the stored instructions and / or data as needed. For example, in some embodiments, the computer system 140 may implement one or more nodes of a control plane or control system, and the persistent storage 148 may include a solid-state drive (SSD) mounted on the server node. Multiple computer systems 140 may share the same persistent storage device 148, or they may share a pool of persistent storage devices, where the devices in the pool represent the same or different storage technologies, including the technologies described above.
[0034] The computer system 140 includes one or more physical system memories 142 that can store code / instructions 143 and data 145 accessible by (one or more) processors 140a, etc. The system memory 142 may include multiple levels of memory and memory cache in a system designed to swap information in memory based on access speed, for example. Interleaving and swapping may extend to the persistent storage device 148 in a virtual memory implementation where the memory space is mapped onto the persistent storage device 148. Techniques used to implement the system memory 142 may include, as an example, static random-access memory (RAM), dynamic RAM, read-only memory (ROM), non-volatile memory, solid-state memory, or flash-type memory. As with the persistent storage device 148, multiple computer systems 140 may share the same system memory system 142 or share a pool of system memory 142. One or more system memories 142 may contain program instructions 143 that are executable by (one or more) processors 140a, etc., in order to implement the routines described herein.
[0035] In various embodiments, program instructions 143 may be encoded in binary, assembly language, any interpreted language such as Java®, a compiled language such as C / C++, or any combination thereof, and the specific languages given herein are merely examples. In some embodiments, program instructions 143 may implement multiple separate clients, server nodes, and / or other components.
[0036] In some implementations, program instructions 143 may include instructions executable to implement an operating system (not shown), which may be any of the various operating systems, such as UNIX®, LINUX, Solaris®, MacOS®, or Microsoft Windows®. Any or all of program instructions 143 may be provided as a computer program product or software, which may include a non-temporary computer-readable storage medium storing the instructions, and which may be used to program a computer system (or other electronic device) to perform a process according to various implementations. The non-temporary computer-readable storage medium may include any mechanism for storing information in a form readable by a machine (e.g., a physical computer) (e.g., software or processing application). Generally, the non-temporary computer-accessible medium may include computer-readable storage media or memory media, such as magnetic or optical media, for example, a disk or DVD / CD-ROM coupled to or communicating with the computer system 140 via the I / O interface 144. Non-temporary computer-readable storage media may also include any volatile or non-volatile media, such as RAM or ROM, which may be included as system memory 142 or another type of memory in some embodiments of the computer system 140. In other implementations, program instructions may be communicated using optical, acoustic, or other forms (e.g., carrier waves, infrared signals, digital signals, etc.) of propagated signals transmitted over a communication medium, such as a network and / or wired or wireless link, such as a network interface 146. The network interface 146 may be used to interface with other devices 152, which may include other computer systems or any type of external electronic device.
[0037] In some embodiments, system memory 142 may include a data store 145 as described herein. Generally, system memory 142 and persistent storage 148 may be accessible on other devices 152 over a network and may store data blocks, replicas of data blocks, metadata associated with data blocks and / or their states, database configuration information, and / or any other information that can be used when implementing routines described herein.
[0038] In one embodiment, the I / O interface 144 may coordinate I / O traffic between a processor 140a and other components in the system, and between the system memory 142 and any peripheral devices, including through a network interface 146 or other peripheral interfaces. In some embodiments, the I / O interface 144 may perform any necessary protocols, timing, or other data conversions to convert data signals from one component (e.g., system memory 142) into a format suitable for use by another component (e.g., a processor 140a). In some embodiments, the I / O interface 144 may include support for devices attached via various types of peripheral buses, such as variations of 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 144, such as an interface to the system memory 142, may be directly integrated into one or more processors 140a.
[0039] The network interface 146 may, for example, allow data to be exchanged between the computer system 140 and other devices attached to the network, such as other computer systems (which may implement one or more storage system server nodes, primary nodes, read-only node nodes, and / or database system clients as described herein). Furthermore, the I / O interface 144 may allow communication between the computer system 140 and various I / O devices 150 and / or remote storage 148. In some embodiments, the input / output devices 150 may include one or more display terminals, keyboards, keypads, touchpads, scanning devices, voice or optical recognition devices, or any other devices suitable for inputting or retrieving data by one or more computer systems 140. These may connect directly to a specific computer system 140 or, generally speaking, to multiple computer systems 140 in a cloud computing environment, a grid computing environment, or other systems involving multiple computer systems 140. Multiple input / output devices 150 may exist communicating with the computer system 140, or they may be distributed across various nodes of a distributed system including the computer system 140. In some embodiments, similar input / output devices may be separate from the computer system 140 and may interact with one or more nodes of the distributed system including the computer system 140 via wired or wireless connections, such as over a network interface 146. The network interface 146 may typically support one or more wireless networking protocols (e.g., Wi-Fi / IEEE 802.11, or another wireless networking standard). The network interface 146 may support communication over any suitable wired or wireless general data network, such as other types of Ethernet® networks.Furthermore, the network interface 146 may support communication over telecommunications / telephony networks such as analog voice networks or digital fiber optic networks, communication over storage area networks such as Fibre Channel SANs, or communication over any other suitable type of network and / or protocol. In various embodiments, the computer system 140 may include more components than those shown in Figure 3, fewer components than those shown in Figure 3, or components different from those shown in Figure 3 (e.g., displays, video cards, audio cards, peripheral devices, or Ethernet® interfaces).
[0040] 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 the database tier of a hardware database system may present database services and / or other types of physical data storage services employing the distributed storage systems described herein to clients as network-based services. In some embodiments, network-based services may be implemented by software and / or hardware systems designed to support interoperable machine-to-machine interaction over a network. Web services may have interfaces written in a machine-readable format. Other systems may interact with network-based services in a manner defined by the description of the network-based service's interface. For example, a network-based service may define various actions that other systems may invoke and define specific application programming interfaces (APIs) that other systems are expected to follow when requesting these actions.
[0041] In various embodiments, network-based services may be requested or invoked through the use of a message containing parameters and / or data associated with the network-based service request. Such messages may be formatted according to a specific markup language, such as XML, and / or encapsulated using a protocol. To fulfill a network-based service request, a network-based service client may assemble a message containing the request and transmit that message to an addressable endpoint corresponding to the web service (e.g., a Uniform Resource Locator (URL)) using an Internet-based application layer transport protocol, such as the Hypertext Transfer Protocol (HTTP).
[0042] Unless otherwise specified, all technical and scientific terms used herein have the same meaning as those generally understood by those skilled in the art to the extent of this invention. Similar or equivalent methods and materials as those described herein may also be used in the implementation or testing of this invention, but only a limited number of exemplary methods and materials are described herein. It will be apparent to those skilled in the art that many more modifications are possible without departing from the inventive concept herein.
[0043] All terms used herein should be interpreted in the broadest possible form that is appropriate to the context. When grouping is used herein, all individual members of the group, as well as all possible combinations and subcombinations of the group, are included individually. When a scope is specified herein, the scope includes all subscopes within the scope, as well as all individual points within the scope. When terms such as “about” and “approximately” are used herein, the terms include quantities, measurements, etc. that do not deviate significantly from the explicitly stated quantities, measurements, etc., so as not to impair the stated purpose of the apparatus or process. All references cited herein are incorporated herein by reference to the extent that they do not conflict with this disclosure.
[0044] The present invention has been described in relation to several preferred and alternative embodiments, which are intended to be illustrative and not to be limited to the full scope of the invention as described in the appended claims.
Claims
1. A cloud-native data activation method, The steps include: mapping a consumer audience, which includes multiple consumer data stored in a cloud-based customer environment, to a source database in the provider environment using a subset of the multiple consumer data in the consumer audience sent from the customer environment to the cloud-based provider environment; A step of operating a data change capture function in the customer environment, wherein the data change capture function tracks changes to the plurality of consumer data in the consumer audience. The steps include configuring a user-defined external function for activating the multiple consumer data within the customer environment, A step of dynamically calculating a set of segments for the consumer data within the customer environment, wherein the step of calculating the set of segments includes adding additional data to the plurality of consumer data, the additional data being sent from the provider environment to the customer environment, and the plurality of customer data being divided into similar segments, thereby enabling the customer to more accurately target the consumer audience with messages. Cloud-native data activation methods, including [specific methods].
2. The cloud-native data activation method according to claim 1, wherein the plurality of consumer data is organized into a plurality of rows and a plurality of columns, and the subset of the data in the plurality of consumer data includes a single column of the plurality of consumer data.
3. The cloud-native data activation method according to claim 2, wherein the single column of the plurality of consumer data includes an identifier for each of the plurality of rows of the consumer data.
4. The cloud-native data activation method according to claim 3, wherein the identifier is created by the provider and uniquely associates each of the plurality of rows in the consumer data with a particular consumer.
5. The cloud-native data activation method according to claim 1, wherein the data change capture function includes an embedded function of the cloud-based consumer environment.
6. One or more computer processors, The memory space that stores the instructions and A machine comprising, when the instruction is executed by the one or more computer processors, the one or more computer processors, In a cloud-based client environment, linking a set of audience data in a customer data warehouse to a set of internal customer identifiers, Mounting the set of audience data from the set of database tables stored within the aforementioned cloud-based client environment, Linking the aforementioned audience data from the cloud-based client environment to a cloud-based provider environment that is remote and connected to the cloud-based provider environment via a network, To manipulate the aforementioned audience data and create segments, the system creates multiple segments from the aforementioned audience data by receiving criteria entered through a user interface. Tracking changes to the multiple segments in the audience data using change data capture features within the cloud-based client environment. A machine that performs a task.
7. The machine according to claim 6, wherein when the instruction is executed by the one or more computer processors, the machine further causes the one or more computer processors to apply a linking procedure configured to discover a schema of the audience data in order to create a set of related assets in a metadata database in the cloud-based provider environment.
8. The machine according to claim 7, wherein when the instruction is executed by the one or more computer processors, the machine causes the one or more computer processors to further generate a query including an instruction for selecting a set of user identifiers, to identify locations in the audience data, and to identify segment criteria.
9. The machine according to claim 8, wherein when the instruction is executed by the one or more computer processors, the machine causes the one or more computer processors to further utilize a provider native application to resolve the audience data to the set of user identifiers.
10. The machine according to claim 9, wherein when the instruction is executed by the one or more computer processors, the machine causes the one or more computer processors to further link metadata in the cloud-based provider environment to the segmented data in order to track the segmented data over time.
11. The machine according to claim 10, wherein when the instruction is executed by the one or more computer processors, the machine further causes the one or more computer processors to perform a task of pulling data from the cloud-based client environment within the cloud-based provider environment to identify any new or deleted rows in the segmented data.
12. A method for cloud-based data activation, In a cloud-based client environment, the steps include linking a set of audience data in a customer data warehouse to a set of internal customer identifiers, The steps include mounting the audience data from a set of database tables stored within the aforementioned cloud-based client environment, A step of linking the aforementioned audience data from the cloud-based client environment to a remote cloud-based provider environment, wherein the cloud-based client environment and the cloud-based provider environment communicate via a network; The steps include: creating a segment from the audience data by manipulating the audience data and receiving criteria entered from the user interface in order to create the segment; The steps include: tracking changes to the segment in the audience data using native change data capture features in the cloud-based client environment; Methods that include...
13. The method according to claim 12, wherein the step of creating a segment includes the step of applying a linking procedure to discover a schema of the audience data in order to create a set of related assets in a metadata database in the cloud-based provider environment.
14. The method according to claim 13, wherein the step of creating a segment includes the steps of generating a query that includes instructions for selecting a set of user identifiers, identifying a location in the audience data, and identifying segment criteria.
15. The method according to claim 14, wherein the query is a Structured Query Language (SQL) query.
16. The method according to claim 15, further comprising the step of using a provider native app to resolve the audience data to the set of user identifiers.
17. The method according to claim 16, wherein the step of linking the audience data to the cloud-based provider environment includes the step of linking metadata within the cloud-based provider environment to the segmented data in order to track the segmented data over time.
18. The method according to claim 17, further comprising the step of performing a task within the cloud-based provider environment to pull data from the cloud-based client environment to identify any new or deleted rows in the audience data.
19. A computerized system for cloud-native activation, wherein the system is A provider environment comprising a Workflow Application Programming Interface (API), a Distribution API, and a provider bucket that communicates with the Distribution API, A customer environment that communicates with the provider environment over a network, wherein the customer environment comprises a cloud compute cluster that communicates with the workflow API, and a plurality of customer tables that communicate with the cloud compute cluster. Equipped with, The cloud compute cluster is configured to perform actions on the customer table in response to requests from the workflow API. The workflow API is configured to initiate a call to utilize the cloud compute cluster within the customer environment. The cloud compute cluster is configured to link the multiple customer tables to an internal customer identifier set. The cloud compute cluster is further configured to link the customer tables to a set of provider data in the provider bucket in order to create provider metadata related to the customer tables in the provider bucket, without moving all the data in the customer tables outside the customer environment and into the provider environment. The cloud compute cluster is further configured to create segments within the multiple customer tables using data from the provider bucket in the provider environment. A computerized system in which the cloud compute cluster is further configured to perform change data capture functionality to track changes to the multiple customer tables over time, and to communicate metadata about the changes outside the customer environment to the provider bucket in the provider environment.
20. The computerized system according to claim 19, wherein the cloud compute cluster is further configured to discover the schemas of the plurality of customer tables.
21. The computerized system according to claim 20, wherein the distribution API is configured to perform a scheduled task to find any new or deleted rows in the plurality of customer tables in the client environment and to store any identifier from the internal customer identifier set associated with the new or deleted row in the provider bucket.