Description:FIELD OF INVENTION
[0001] The present disclosure relates to computer-implemented systems and methods for segmenting entities in campaign management platforms. More particularly the present disclosure relates to a distributed segmentation architecture that enables entity segmentation across multiple data domains while preventing transmission of customer data from a customer computing environment to a campaign management platform.
BACKGROUND
[0002] Campaign management platforms are commonly used to define segments of entities (e.g., users, customers, accounts, cardholders) for downstream actions such as targeted communication, analytics, or workflow triggering. Entity segmentation involves evaluating conditions across datasets to identify entities meeting specified criteria. These segments enable personalized customer engagement by targeting specific entity groups with relevant communications, offers, or experiences. A considerable number of technical challenges arise in the data architecture of such systems such as executing segmentation across distributed datasets requires access to data residing in multiple locations, including data stored within customer-controlled computing environments that customers designate as sensitive and wish to maintain within their own infrastructure. The computational problem involves reconciling the need for comprehensive segmentation logic with the requirement that certain data never be transmitted outside customer-controlled boundaries.
[0003] Current approaches to entity segmentation in campaign management platforms rely on centralized architectures in which customer data, including data designated as sensitive by the customer, is transmitted from customer computing environments to the campaign management platform. The campaign management platform ingests, stores, and processes this data to perform segmentation operations. Data protection measures such as encryption, access controls, and contractual safeguards are employed to protect the transmitted data. However, these approaches require the sensitive data to traverse network boundaries and reside within the campaign management platform's infrastructure, where the data is processed and, in many cases, persistently stored for ongoing segmentation operations.
[0004] The centralized data transmission model presents several technical limitations. First, the architecture expands the attack surface by replicating sensitive data across multiple computing environments, increasing the number of systems that must be secured against unauthorized access. Second, the data transmission and storage operations consume network bandwidth and storage resources on the campaign management platform. Third, the architecture creates data coupling between the campaign management platform and customer data sources, such that changing campaign management vendors requires re-transmitting sensitive data to a new platform. Fourth, the centralized model lacks flexibility in accommodating customer-defined data classification policies, as the platform must receive and process all data fields regardless of customer sensitivity designations. Fifth, for customers operating in regulated industries such as financial services or healthcare, transmitting certain data categories outside their controlled infrastructure may introduce regulatory compliance complexity or risk. Accordingly, improved systems and methods that address one or more of these technical limitations are desired.
SUMMARY
[0005] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.
[0006] According to an aspect of the present disclosure, a system for performing distributed segmentation of entities for targeted communication is provided. The system includes a campaign management platform configured to receive a segmentation definition comprising conditions for segmenting entities across multiple data domains. The campaign management platform is further configured to partition the segmentation definition into a platform-executed portion and a customer-executed portion based on data domain characteristics. The campaign management platform is configured to execute the platform-executed portion to generate a first set of entity identifiers and transmit the customer-executed portion to a customer-side processing component for execution. The campaign management platform is configured to merge the first set of entity identifiers with a second set of entity identifiers received from the customer-side processing component using common identifiers to determine a final segment. The system further includes the customer-side processing component deployed by the campaign management platform and executing, under control of the campaign management platform, within a customer computing environment comprising one or more customer databases. The customer-side processing component is configured to receive the customer-executed portion from the campaign management platform, evaluate the customer-executed portion against data in the one or more customer databases to generate the second set of entity identifiers, and transmit the second set of entity identifiers to the campaign management platform. The campaign management platform is configured to initiate one or more actions on the final segment via one or more external communication channels. Data from the second data domain remains within the customer computing environment.
[0007] According to other aspects of the present disclosure, the system may include one or more of the following features. The entities may comprise various entity types such as users, accounts, cardholders, vehicles, policies, or custom entities, and the common identifiers may comprise customer-designated identifiers including Customer User ID (CUID), canonical entity identifiers, account identifiers, or custom entity identifiers.
[0008] The campaign management platform may be further configured to configure a customer-specific schema through Bring-Your-Own-Schema (BYOS), wherein the customer-specific schema comprises entity types, field definitions, data type specifications, and inter-entity relationships including one-to-one relationships, one-to-many relationships, many-to-one relationships, and many-to-many relationships, and adapt partitioning logic of the segmentation definition based on the customer-specific schema.
[0009] The customer-side processing component may be configured to connect to the one or more customer databases through Bring-Your-Own-Warehouse (BYOW) integrations using programmatic interfaces, wherein the one or more customer databases comprise one or more data storage systems such as relational databases, analytical data warehouses, event stores, and application programming interfaces, and wherein the customer-executed portion is executed directly within the one or more customer databases by the customer-side processing component.
[0010] The customer computing environment may comprise one or more of on-premise infrastructure, private cloud infrastructure, and customer-controlled public cloud infrastructure, and the customer-side processing component may be configured with network access controls with whitelisted ingress and egress specifications.
[0011] The campaign management platform may transmit the customer-executed portion to the customer-side processing component asynchronously through an Application Program Interface (API) communication protocol, the customer-side processing component may execute the customer-executed portion independently and in parallel with execution of the platform-executed portion, the customer-side processing component may implement retry mechanisms for handling retriable errors during execution, and the campaign management platform may produce the final segment upon receiving completion signals from both execution portions.
[0012] The first data domain may comprise behavioral data including user interaction events, campaign engagement metrics, application activity logs, and digital touchpoint data, user profile data including non-sensitive user attributes, and data associated with platform entities that are not designated as remote entities, and the second data domain may comprise customer-designated sensitive data including one or more of transactional data, financial records, PII, health data, proprietary datasets, and confidential information.
[0013] The common identifiers may enable independent and parallel computation of segmentation conditions in the first data domain and the second data domain, and the campaign management platform may perform correlation by matching the common identifiers between the first set of entity identifiers and the second set of entity identifiers.
[0014] The one or more external communication channels may comprise one or more channels such as email channels, messaging channels, push notification channels, short message service channels, in-application notification channels, voice communication channels, and rich communication service channels, and the one or more actions may comprise delivering personalized communications to user devices associated with entities in the final segment.
[0015] The campaign management platform may be configured to maintain synchronization between the customer-specific schema and active segmentation definitions through a manual schema update process, schema updates including field additions, field modifications, data type changes, and relationship modifications may be reflected through configuration changes, and schema updates may be propagated to the customer-side processing component.
[0016] The campaign management platform may be configured to receive initial identifier data comprising the common identifiers from the customer computing environment through one or more of an initial data upload process and an API-based synchronization process, and the common identifiers stored in the campaign management platform may enable correlation with entity identifiers returned from the customer-side processing component.
[0017] The partitioning may be based on analysis of entity relationships defined in a customer-specific schema, the customer-specific schema may specify remote entities having one-to-one relationships with platform entities, the platform-executed portion may comprise conditions evaluable using data associated with the platform entities, and the customer-executed portion may comprise conditions evaluable using data associated with the remote entities.
[0018] According to another aspect of the present disclosure, a method for performing distributed segmentation of entities for targeted communication is provided. The method includes receiving, by a campaign management platform, a segmentation definition comprising conditions for segmenting entities across multiple data domains. The method includes partitioning, by the campaign management platform, the segmentation definition into a platform-executed portion and a customer-executed portion based on data domain characteristics. The method includes executing, by the campaign management platform, the platform-executed portion to generate a first set of entity identifiers. The method includes causing, by the campaign management platform, execution of the customer-executed portion by a customer-side processing component deployed by the campaign management platform and executing, under control of the campaign management platform, within a customer computing environment comprising one or more customer databases. The causing comprises transmitting the customer-executed portion to the customer-side processing component, evaluating the customer-executed portion against data in the one or more customer databases to generate a second set of entity identifiers, and transmitting the second set of entity identifiers to the campaign management platform. The method includes merging, by the campaign management platform, the first set of entity identifiers with the second set of entity identifiers using common identifiers to determine a final segment. The method includes initiating, by the campaign management platform, one or more actions on the final segment via one or more external communication channels. Data from the second data domain remains within the customer computing environment.
[0019] According to other aspects of the present disclosure, the method may include one or more of the following features. The entities may comprise various entity types such as users, accounts, cardholders, vehicles, policies, or custom entities. The customer-side processing component may be configured with network access controls with whitelisted ingress and egress specifications. The campaign management platform may transmit the customer-executed portion to the customer-side processing component asynchronously through an API communication protocol. The customer-side processing component may execute the customer-executed portion independently and in parallel with execution of the platform-executed portion. The customer-side processing component may implement retry mechanisms for handling retriable errors during execution. The first data domain may comprise behavioral data including user interaction events, campaign engagement metrics, application activity logs, and digital touchpoint data, user profile data including non-sensitive user attributes such as user preferences or account settings, and data associated with platform entities that are not designated as remote entities. The second data domain may comprise customer-designated sensitive data including one or more of transactional data, financial records, PII, health data, proprietary datasets, and confidential information.
[0020] The foregoing general description of the illustrative embodiments and the following detailed description thereof are merely exemplary aspects of the teachings of this disclosure and are not restrictive.
BRIEF DESCRIPTION OF FIGURES
[0021] Non-limiting and non-exhaustive examples are described with reference to the following figures.
[0022] FIG. 1 depicts a block diagram of a system for performing distributed segmentation of entities for targeted communication, according to aspects of the present disclosure.
[0023] FIG. 2 illustrates a flowchart of a method for performing distributed segmentation of entities for targeted communication, according to aspects of the present disclosure.
[0024] FIG. 3 illustrates a flowchart of a schema configuration process using Bring-Your-Own-Schema (BYOS), according to aspects of the present disclosure.
[0025] FIG. 4 illustrates a flowchart of a customer-side database connection process using Bring-Your-Own-Warehouse (BYOW), according to aspects of the present disclosure.
[0026] FIG. 5 illustrates a flowchart of an identifier synchronization process for establishing common identifiers, according to aspects of the present disclosure.
[0027] FIG. 6 illustrates a flowchart of initiating actions on the final segment via external communication channels, according to aspects of the present disclosure.

DETAILED DESCRIPTION
[0028] The following description sets forth exemplary aspects of the present disclosure. It should be recognized, however, that such description is not intended as a limitation on the scope of the present disclosure. Rather, the description also encompasses combinations and modifications to those exemplary aspects described herein.
[0029] A system for performing distributed segmentation of entities for targeted communication includes a campaign management platform configured to receive a segmentation definition. The segmentation definition comprises conditions for segmenting entities across multiple data domains. The campaign management platform is configured to partition the segmentation definition into a platform-executed portion and a customer-executed portion based on data domain characteristics. Further, the campaign management platform is configured to execute the platform-executed portion to generate a first set of entity identifiers and transmit the customer-executed portion to a customer-side processing component for execution. The campaign management platform is configured to merge the first set of entity identifiers with a second set of entity identifiers received from the customer-side processing component using common identifiers to determine a final segment. It must be noted that customer-side processing component is deployed by the campaign management platform and executes under control of the campaign management platform, within a customer computing environment. The customer computing environment comprises one or more customer databases. The customer-side processing component is configured to receive the customer-executed portion from the campaign management platform, evaluate the customer-executed portion against data in the one or more customer databases to generate the second set of entity identifiers, and transmit the second set of entity identifiers to the campaign management platform. The campaign management platform is configured to initiate one or more actions on the final segment via one or more external communication channels. Data from the second data domain remains within the customer computing environment.
[0030] The system addresses technical difficulties associated with centralized data processing in entity segmentation architectures. By maintaining data from the second data domain within the customer computing environment, the system reduces the attack surface that would otherwise result from centralized data storage at the campaign management platform. The system eliminates transmission of data from the second data domain across network boundaries between the customer computing environment and the campaign management platform, thereby reducing exposure to interception or unauthorized access during data transit. The system decouples segmentation logic execution from data handling, enabling the campaign management platform to orchestrate entity segmentation operations without requiring access to or storage of data from the second data domain.
[0031] The system architecture separates a control plane handling segmentation logic from a data plane handling data access. The campaign management platform operates as the control plane, managing segmentation definitions, partitioning logic, execution coordination, and result merging using common identifiers. The customer-side processing component operates as the data plane, performing data retrieval and condition evaluation operations within the customer computing environment. This distributed architecture enables identifier-based segmentation orchestration at the campaign management platform with localized data resolution at the customer-side processing component. The separation allows the campaign management platform to coordinate multi-domain segmentation operations while the customer-side processing component handles the resolution of conditions requiring data from the second data domain without exposing data values to the campaign management platform.
[0032] In some embodiments, the term "customer-designated sensitive data" refers to any data fields, attributes, or data patterns that are designated by an individual customer organization as sensitive according to that customer's internal policies, regulatory obligations, or risk models. Such sensitive data may include personally identifiable information (PII) fields such as names, email addresses, phone numbers, or other contact identifiers. The term "PII" or "Personally Identifiable Information" refers to data that can be used to identify, contact, or locate a specific individual. In addition, sensitive data may include non-PII data that is nevertheless treated as sensitive by the customer, such as transaction histories, financial records, behavioral patterns, health data, or other confidential business information derived from customer datasets.
[0033] In some embodiments, the designation of data fields as sensitive is customer-controlled and configurable, such that the system does not define which data fields constitute PII or sensitive data. Rather, each customer may specify, through configuration metadata, access policies, or field classification rules, which fields are to be treated as sensitive and therefore excluded from transmission to the campaign management platform. Accordingly, the system maintains a technical separation in which data values from the second data domain remain within the customer computing environment while segmentation execution logic operates using common identifiers.
[0034] Referring to FIG. 1, a system 100 for performing distributed segmentation of entities for targeted communication includes a campaign management platform 102 and a customer-side processing component 112. The campaign management platform 102 and the customer-side processing component 112 are communicatively coupled over a network 104. The system 100 interacts with a customer computing environment 110, customer data sources 114, and one or more external communication providers 116. The customer-side processing component 112 is deployed within the customer computing environment 110. The customer data sources 114 are located within the customer computing environment 110 and are accessible to the customer-side processing component 112, but the customer data sources 114 are not part of the system 100. The system 100 enables entity segmentation operations while maintaining separation between segmentation orchestration logic and data handling. As described previously, data from the second data domain remains within the customer computing environment 110 and is not transmitted to the campaign management platform 102.
[0035] The campaign management platform 102 includes a segmentation engine 106 and a behavioral data repository 108. The segmentation engine 106 manages segmentation definitions, partitions segmentation definitions into execution portions, coordinates execution across distributed components, and merges entity identifier sets to determine final segments. The behavioral data repository 108 stores data from a first data domain, wherein the first data domain comprises behavioral data including user interaction events, campaign engagement metrics, application activity logs, and digital touchpoint data, user profile data including non-sensitive user attributes such as user preferences or account settings, and data associated with platform entities that are not designated as remote entities residing in the second data domain. In some embodiments, the behavioral data repository 108 may comprise one or more database systems including relational databases, document databases, key-value stores, data warehouses, or other data stores that maintain data from the first data domain. The campaign management platform 102 executes segmentation logic using common identifiers, wherein the common identifiers are selected by a customer from a plurality of data fields associated with entities and represent a particular entity in the campaign management platform 102 and in one or more customer databases. The campaign management platform 102 may be deployed as a cloud-based platform executing on cloud infrastructure, as a hybrid platform combining cloud and customer-controlled resources, or as an on-premise platform within a customer's infrastructure.
[0036] The term "entity" as used herein refers to any grouping of data defined by a customer that may have one or more fields and subfields. For example, a user entity and event entities are primary entity types in campaign management systems. In some embodiments, entities may comprise various entity types such as users, accounts, cardholders, vehicles, policies, or custom entities defined by the customer. A "user" entity denotes a known or anonymous user of a system. Users can have system attributes (default attributes assigned by the system, like email, phone, city) and custom attributes (attributes created by the customer, like is_vip, loyalty_tier). An "event" represents actions performed by the user, stored as timestamped records, wherein events usually have a name and a set of attributes. For example, if a user searches for flight tickets to New York, the customer's system might publish an event such as: {"user_id": ..., "timestamp": ..., "event_name": "flight_search", "event_data": {"from": "Washington", "to": "New York"}}. Other entities can be created by the customer at their discretion, which become "custom entities." For example, an insurance company might create a Policy entity that it may or may not associate with one or more users. A banking institution might create an Account entity and a Transaction entity. Entities can have relationships, analogous to relationships between different tables in a relational database.
[0037] The common identifiers enable independent computation of segmentation conditions by the campaign management platform 102 and the customer-side processing component 112 operating in the customer computing environment 110. In some embodiments, the common identifiers comprise customer-designated identifiers including Customer User ID (CUID), canonical entity identifiers, account identifiers, or custom entity identifiers. The term "CUID" or "Customer User ID" refers to a user identifier assigned by the customer's system. The CUID can be any non-sensitive identifier format, including universally unique identifiers (UUIDs), alphanumeric codes, system-generated identifiers, or any other non-PII identifier chosen by the customer. The CUID represents the same user in both the campaign management platform 102 and the customer's system, which allows both systems to effectively communicate about a user without transmitting sensitive data values. In some embodiments, the common identifiers may comprise hashed identifiers generated by applying a cryptographic hash function to an underlying identifier value. In some embodiments, the common identifiers may comprise surrogate identifiers that serve as substitutes for underlying identifier values, wherein a mapping between the surrogate identifier and the underlying identifier value is maintained within the customer computing environment 110.
[0038] With continued reference to FIG. 1, the customer computing environment 110 comprises the customer-side processing component 112 and customer data sources 114. The customer computing environment 110 may comprise one or more of on-premise infrastructure, private cloud infrastructure, and customer-controlled public cloud infrastructure maintained by the customer. The term "on-premise infrastructure" refers to computing resources located at the customer's physical facilities and under the customer's direct operational control. The term "private cloud infrastructure" refers to cloud computing resources dedicated exclusively to a single customer organization, whether hosted by the customer or by a third-party provider under the customer's control. The term "customer-controlled public cloud infrastructure" refers to resources within a public cloud environment (such as Amazon Web Services, Microsoft Azure, or Google Cloud Platform) where the customer maintains control over the computing environment, including virtual private clouds, dedicated instances, or isolated compute resources. The customer-side processing component 112 operates within network boundaries of the customer computing environment 110, and data egress restrictions prevent transmission of data from the second data domain outside the customer computing environment 110.
[0039] The customer data sources 114 are external to the system 100 and are owned and operated by the customer within the customer computing environment 110. The customer data sources 114 include one or more databases, data warehouses, event stores, application programming interfaces (APIs), or programmatic interfaces storing data from a second data domain, wherein the second data domain comprises customer-designated sensitive data including one or more of transactional data, financial records, PII, health data, proprietary datasets, and confidential information. In some embodiments, the customer data sources 114 may comprise relational database management systems such as PostgreSQL, MySQL, or Oracle Database, analytical data warehouses such as Snowflake, Amazon Redshift, or Google BigQuery, document databases such as MongoDB, event streaming platforms such as Apache Kafka, or other data storage systems. The customer data sources 114 are accessible only within the customer computing environment 110. The customer-side processing component 112 accesses the customer data sources 114 through programmatic interfaces, database connections, or API calls within the customer computing environment 110 without transmitting data values outside the customer computing environment 110.
[0040] The customer-side processing component 112 is deployed by the campaign management platform 102 and executes, under control of the campaign management platform 102, within the customer computing environment 110. In other words, the campaign management platform 102 provides the software, configuration, or instructions that establish the customer-side processing component 112 within the customer computing environment 110. The campaign management platform 102 directs the operations of the customer-side processing component 112 by transmitting execution instructions, receiving execution results, and coordinating execution timing. In some embodiments, the customer-side processing component 112 may be implemented as a software agent, a containerized service, a library, or a sidecar process. When implemented as a software agent, the customer-side processing component 112 operates as a standalone process within the customer computing environment 110, receiving instructions from the campaign management platform 102 and executing segmentation operations. When implemented as a containerized service, the customer-side processing component 112 may be deployed using container orchestration platforms such as Kubernetes or Docker. When implemented as a library, the customer-side processing component 112 may integrate into customer applications as a software dependency. When implemented as a sidecar process, the customer-side processing component 112 may execute alongside other services within the customer computing environment 110.
[0041] The customer-side processing component 112 is configured with network access controls with whitelisted ingress and egress specifications. The term "ingress specifications" refers to network security rules that define approved sources for incoming network connections or communications to the customer-side processing component 112. In some embodiments, the ingress specifications may include whitelisted IP addresses or hostnames from which the customer-side processing component 112 accepts connections, such as the hostname or IP address of the campaign management platform 102. The term "egress specifications" refers to network security rules that limit outbound network connections from the customer-side processing component 112 to a predefined list of approved destinations. In some embodiments, the whitelisted egress specifications include the hostname or IP address of the campaign management platform 102 to enable transmission of entity identifiers, and may exclude all other destinations to prevent unauthorized data transmission. The egress specifications ensure that the customer-side processing component 112 transmits only entity identifiers (and not data values from the second data domain) to the campaign management platform 102, thereby maintaining data isolation.
[0042] With continued reference to FIG. 1, the system 100 further includes external communication service providers 116 that deliver communications to end users 118. The external communication service providers 116 comprise third-party communication services that provide delivery infrastructure for various communication channels. In some embodiments, the external communication service providers 116 may comprise email service providers (such as SendGrid, Amazon SES, or Mailgun), messaging service providers (such as Twilio for SMS or WhatsApp Business API), push notification services (such as Firebase Cloud Messaging or Apple Push Notification Service), in-app messaging services, voice communication services, social media platforms, or Rich Communication Services (RCS) providers. The campaign management platform 102 orchestrates communication delivery through the external communication service providers 116 using final segments determined through the distributed segmentation process. The end users 118 receive communications on user devices associated with entities in the final segment.
[0043] The system 100 enables enterprise communications without exposing data from the second data domain to the campaign management platform 102. For example, financial institutions may use the system 100 to segment accounts based on transaction activity and digital engagement while maintaining transaction details within the customer computing environment 110. Healthcare organizations may use the system 100 to segment patients based on health records and appointment history while maintaining patient information within the customer computing environment 110. Retail organizations may use the system 100 to segment customers based on purchase history and browsing behavior while maintaining customer contact information within the customer computing environment 110. Organizations operating in regulated industries may use the system 100 to execute segmentation operations while satisfying data residency, data protection, or industry-specific compliance requirements.
[0044] Referring to FIG. 2, a method 200 for performing distributed segmentation of entities for targeted communication includes a plurality of steps performed by the campaign management platform 102 and the customer-side processing component 112. The method 200 enables entity segmentation operations while maintaining separation between segmentation orchestration logic and data handling, wherein data from the second data domain remains within the customer computing environment 110 and is not transmitted to the campaign management platform 102. The method 200 provides the core distributed segmentation workflow.
[0045] The method 200 begins at step 202, where the campaign management platform 102 receives a segmentation definition comprising conditions for segmenting entities across multiple data domains. The segmentation definition is a specification of criteria that entities must satisfy to be included in a segment. The segmentation definition comprises one or more conditions that may reference data from the first data domain, the second data domain, or both. A "condition" is a logical expression that evaluates to true or false for a given entity, such as "user has opened an email in the past 7 days" (first data domain condition) or "account balance is greater than $10,000" (second data domain condition). The segmentation definition may include multiple conditions combined using logical operators such as AND, OR, and NOT. For example, a segmentation definition might specify: "users who have opened an email in the past 7 days AND have a transaction amount greater than Rs. 5,000 in the past month." In this example, the first condition references the first data domain (email engagement) and the second condition references the second data domain transaction amount). The campaign management platform 102 receives the segmentation definition from a user interface, an API call, an automated workflow, or another input mechanism.
[0046] At step 204, the campaign management platform 102 partitions the segmentation definition into a platform-executed portion and a customer-executed portion based on data domain characteristics. The partitioning is determined by the entity types referenced in the segmentation definition and the data domain where those entities reside. In some embodiments, the customer explicitly designates certain entity types as remote entities residing in the second data domain during schema configuration, as described with respect to FIG. 3. When a segmentation definition references remote entities, the conditions evaluating those remote entities are allocated to the customer-executed portion. When a segmentation definition references platform entities residing in the first data domain, the conditions evaluating those platform entities are allocated to the platform-executed portion. The partitioning may occur at segment creation time, where users create segments specifically on remote entities (allocated to customer-executed portion) or on platform entities (allocated to platform-executed portion). In some embodiments, separate segments created on different entity types may be combined at a campaign level through logical operations such as AND, OR, or other combinations.
[0047] For example, a user might create a first segment on a User entity in the first data domain with the condition "user has clicked a link in an email in the past 14 days." This segment is allocated to the platform-executed portion because it references a platform entity. The same user might create a second segment on a Transaction entity (a remote entity in the second data domain) with the condition "transaction amount greater than Rs. 5,000 in the past month." This segment is allocated to the customer-executed portion because it references a remote entity. At a campaign level, these two segments may be combined using logical operations (AND, OR, or other combinations) to determine the final target audience. The partitioning is thus based on which entity types are referenced in each segment, with remote entity segments automatically routed to the customer-executed portion and platform entity segments routed to the platform-executed portion.
[0048] At step 206, the campaign management platform 102 executes the platform-executed portion to generate a first set of entity identifiers. The campaign management platform 102 evaluates the conditions in the platform-executed portion against data in the first data domain stored in the behavioral data repository 108. The segmentation engine 106 applies each condition to the available data, filtering entities based on whether they satisfy the specified criteria. For each entity that satisfies the platform-executed portion conditions, the campaign management platform 102 extracts the common identifier associated with that entity. The "first set of entity identifiers" is a collection of common identifiers representing entities that satisfy the platform-executed portion conditions. For example, if the platform-executed portion includes the condition "user has clicked a link in an email in the past 14 days," the campaign management platform 102 queries the behavioral data repository 108 to identify all users who have performed email link clicks within the specified time period, and extracts the CUID or other common identifier for each matching user. The first set of entity identifiers is stored temporarily for subsequent merging operations.
[0049] At step 208, the campaign management platform 102 transmits the customer-executed portion to the customer-side processing component 112. The campaign management platform 102 sends the customer-executed portion via a network connecting the campaign management platform 102 and the customer computing environment 110. In some embodiments, the campaign management platform 102 transmits the customer-executed portion to the customer-side processing component 112 asynchronously through an API communication protocol. The transmission includes the conditions comprising the customer-executed portion, any necessary execution context or parameters, and references to the common identifier schema that will be used for result correlation.
[0050] At step 210, the customer-side processing component 112 evaluates the customer-executed portion against data in the one or more customer databases to generate a second set of entity identifiers. This step occurs within the customer computing environment 110 as further elaborated with respect to FIG. 4. The customer-side processing component 112 receives the customer-executed portion from the campaign management platform 102, connects to the customer data sources 114, and queries data from the second data domain. The customer-side processing component 112 applies each condition in the customer-executed portion to the retrieved data, filtering entities based on whether they satisfy the specified criteria. For example, if the customer-executed portion includes the condition "user has made a purchase in the past 30 days," the customer-side processing component 112 queries transaction records in the customer data sources 114 to identify all users who have completed purchases within the specified time period. For each entity that satisfies the customer-executed portion conditions, the customer-side processing component 112 extracts the common identifier associated with that entity. The second set of entity identifiers is a collection of common identifiers representing entities that satisfy the customer-executed portion conditions. Importantly, the second set contains only entity identifiers (such as CUIDs) and does not contain data values from the second data domain (such as transaction amounts or account balances).
[0051] In some embodiments, the customer-side processing component 112 executes the customer-executed portion independently and in parallel with execution of the platform-executed portion. This parallel execution improves the overall performance of the segmentation operation by reducing total execution time. In some embodiments, the customer-side processing component 112 implements retry mechanisms for handling retriable errors, such as a network timeout, a database connection failure, or a temporary resource unavailability. The retry mechanism automatically re-attempts the failed operation after a delay, using strategies such as exponential backoff (progressively increasing delays between retries) or fixed interval retries.
[0052] At step 212, the customer-side processing component 112 transmits the second set of entity identifiers to the campaign management platform 102. The customer-side processing component 112 sends only the common identifiers (such as CUIDs or other entity identifiers) and does not transmit data values from the second data domain. The transmission occurs via the network, using the API communication protocol, and passes through the egress specifications configured on the customer-side processing component 112. The egress specifications verify that the outbound transmission is directed to a whitelisted hostname (the campaign management platform 102) and contains only identifier data. In some embodiments, the customer-side processing component 112 includes a completion signal and execution metadata (such as the count of identifiers or execution status) along with the second set of entity identifiers. The campaign management platform 102 receives the second set of entity identifiers and prepares for the merging operation. In some embodiments, the campaign management platform 102 produces the final segment upon receiving completion signals from both execution portions, ensuring that both the platform-executed portion and the customer-executed portion have completed before proceeding to the merge operation.
[0053] At step 214, the campaign management platform 102 merges the first set of entity identifiers with the second set of entity identifiers using common identifiers to determine a final segment. The merging operation applies set operations determined by the logical structure of the original segmentation definition or by the logical operations specified in the campaign configuration that combines multiple segments. If the segmentation definition uses AND logic between conditions from different data domains, the merge operation performs an intersection of the two identifier sets, selecting only identifiers present in both the first set and the second set. If the segmentation definition uses OR logic, the merge operation performs a union of the two identifier sets, selecting identifiers present in either set. Other logical combinations may require different set operations. In some embodiments, the logical structure may involve complex combinations of AND, OR, and NOT operators across multiple segment pairs, requiring multiple set operations to determine the final segment. The campaign management platform 102 applies the appropriate combination of set operations based on the logical operators specified in the original segmentation definition or in the campaign configuration that combines multiple segments.
[0054] The campaign management platform 102 performs correlation by matching the common identifiers between the first set of entity identifiers and the second set of entity identifiers. For example, if an entity has CUID "user_12345," and this CUID appears in both the first set (satisfying platform-executed conditions) and the second set (satisfying customer-executed conditions), then the entity is included in the final segment. The final segment represents the complete list of entity identifiers corresponding to entities that satisfy all conditions in the original segmentation definition across both data domains.
[0055] For example, consider a segmentation definition: "users who have opened an email in the past 7 days AND have a transaction amount greater than Rs. 5,000 in the past month." The platform-executed portion evaluates the first condition, generating a first set of entity identifiers: {"user_001", "user_002", "user_005", "user_008"}. The customer-executed portion evaluates the second condition, generating a second set of entity identifiers: {"user_002", "user_005", "user_009"}. The campaign management platform 102 performs an intersection merge (because the definition uses AND logic), resulting in a final segment: {"user_002", "user_005"}. These are the only entities that satisfy both conditions across both data domains. Importantly, the campaign management platform 102 achieves this comprehensive segmentation without ever receiving transaction amount values from the customer computing environment 110. In another example where segments use OR logic: "users who have opened an email in the past 7 days OR have a transaction amount greater than Rs. 5,000 in the past month," the platform-executed portion generates a first set: {"user_001", "user_002", "user_005", "user_008"} and the customer-executed portion generates a second set: {"user_002", "user_005", "user_009"}. The campaign management platform 102 performs a union merge (because the definition uses OR logic), resulting in a final segment: {"user_001", "user_002", "user_005", "user_008", "user_009"}. These are all entities that satisfy either condition across either data domain. More complex logical combinations may require combinations of intersection, union, and difference operations to achieve the desired segmentation logic.
[0056] At step 216, the campaign management platform 102 initiates one or more actions on the final segment via one or more external communication channels. This step is further elaborated with respect to FIG. 6. The "one or more actions" may comprise delivering personalized communications to user devices associated with entities in the final segment, triggering automated workflows, updating analytics dashboards, exporting segment data to external systems, or other operations based on the segmented entity list. In some embodiments, the one or more external communication channels comprise one or more channels such as email channels, messaging channels, push notification channels, short message service (SMS) channels, in-application notification channels, voice communication channels, social media platforms, or RCS channels. The campaign management platform 102 coordinates with the external communication service providers 116 to deliver communications to the end users 118 identified in the final segment. The method 200 thus enables comprehensive segmentation across distributed data domains while maintaining data isolation, wherein data from the second data domain remains within the customer computing environment 110 throughout the process.
[0057] Referring to FIG. 3, a flowchart 300 illustrates a schema configuration process using Bring-Your-Own-Schema (BYOS), according to aspects of the present disclosure. The schema configuration process enables customers to define entity types, field definitions, data type specifications, and inter-entity relationships without transmitting actual data values to the campaign management platform 102. The BYOS configuration allows the segmentation engine 106 to adapt partitioning logic based on the customer-specific schema, determining which entities reside in the first data domain and which entities reside in the second data domain within the customer computing environment 110.
[0058] At step 302, the campaign management platform 102 configures a customer-specific schema through BYOS, wherein the customer-specific schema comprises entity types, field definitions, data type specifications, and inter-entity relationships including one-to-one relationships, one-to-many relationships, many-to-one relationships, and many-to-many relationships. The "BYOS" refers to a configuration mechanism that enables customers to define their own data schema metadata without requiring the campaign management platform 102 to access or ingest the actual data.
[0059] A "one-to-one relationship" indicates that each instance of a first entity type is associated with at most one instance of a second entity type, and vice versa. For example, a User entity may have a one-to-one relationship with a UserProfile entity. A "one-to-many relationship" indicates that each instance of a first entity type may be associated with multiple instances of a second entity type. For example, a User entity may have a one-to-many relationship with Transaction entities (one user has many transactions). A "many-to-one relationship" is the inverse of a one-to-many relationship, viewed from the other entity's perspective. For example, from the Transaction entity's perspective, many transactions belong to one user. A "many-to-many relationship" indicates that each instance of a first entity type may be associated with multiple instances of a second entity type, and each instance of the second entity type may be associated with multiple instances of the first entity type. For example, a User entity may have a many-to-many relationship with Product entities through a purchase history (users can purchase multiple products, and products can be purchased by multiple users).
[0060] The customer provides the schema metadata to the campaign management platform 102 through a configuration interface, an API, or a schema definition file. For example, a banking customer might define the following schema: (1) User entity with fields: {user_id (string), email (string), registration_date (date)}, (2) Account entity with fields: {account_id (string), user_id (string), balance (decimal), account_type (string)}, (3) Transaction entity with fields: {transaction_id (string), account_id (string), amount (decimal), transaction_date (timestamp), merchant (string)}. The banking customer might also define the following relationships: User has one-to-many relationship with Account, Account has one-to-many relationship with Transaction. The campaign management platform 102 stores this schema metadata but does not receive or store the actual data values (such as specific email addresses, account balances, or transaction amounts).
[0061] At step 304, the campaign management platform 102 adapts partitioning logic of the segmentation definition based on the customer-specific schema. The campaign management platform 102 uses the schema metadata to determine which entities and fields are available in the first data domain and which are available in the second data domain. In some embodiments, the customer designates certain entity types or fields as residing in the second data domain (customer computing environment 110) during the schema configuration. For example, the customer might designate the Account entity and Transaction entity as residing in the second data domain, while the User entity's behavioral attributes reside in the first data domain. When partitioning a segmentation definition at step 204 of FIG. 2, the segmentation engine 106 consults the schema metadata to determine which execution portion should handle each condition. If a condition references a field in an entity designated as residing in the second data domain, the condition is allocated to the customer-executed portion. If a condition references a field in an entity residing in the first data domain, the condition is allocated to the platform-executed portion.
[0062] In some embodiments, the customer-specific schema specifies which entity types are remote entities residing in the second data domain within the customer computing environment 110. When a user creates a segmentation definition referencing a remote entity type, the system automatically allocates that segment to the customer-executed portion. When a user creates a segmentation definition referencing a platform entity type residing in the first data domain, the system automatically allocates that segment to the platform-executed portion. This entity-based partitioning ensures that each segment operates only on data available in its respective data domain, enabling users to create segments on remote entities without the system needing to extract and parse individual conditions from a complex segmentation expression.
[0063] At step 306, the campaign management platform 102 maintains synchronization between the customer-specific schema and active segmentation definitions through a manual schema update process. The customer may update the schema when entity types are added, fields are added or modified, data types change, or relationships are modified. When a schema update occurs, the campaign management platform 102 evaluates existing segmentation definitions to determine if they are affected by the schema changes. For example, if a new field is added to an entity, segmentation definitions referencing that field may need to be re-evaluated. If an entity is redesignated from the first data domain to the second data domain, segmentation definitions referencing that entity may need to be re-partitioned.
[0064] At step 308, the campaign management platform 102 reflects schema updates including field additions, field modifications, data type changes, and relationship modifications through configuration changes. The campaign management platform 102 updates its internal schema repository with the new schema metadata and makes the updated schema available to the segmentation engine 106. The configuration changes may trigger validation checks to ensure that existing segmentation definitions remain compatible with the updated schema.
[0065] At step 310, the campaign management platform 102 propagates schema updates to the customer-side processing component 112. The campaign management platform 102 transmits the updated schema metadata to the customer-side processing component 112 via the API communication protocol. The customer-side processing component 112 updates its local schema cache with the new metadata, enabling it to correctly evaluate future customer-executed portions that reference the updated schema. In some embodiments, if the schema update affects the location or structure of data sources, the customer-side processing component 112 may update its Bring-Your-Own-Warehouse (BYOW) connection parameters to reflect the changes, as further described with respect to FIG. 4. The schema synchronization ensures that both the campaign management platform 102 and the customer-side processing component 112 operate with consistent schema information, enabling accurate partitioning and execution across distributed components.
[0066] Referring to FIG. 4, a flowchart 400 illustrates a customer-side database connection process using BYOW, according to aspects of the present disclosure. The BYOW process enables the customer-side processing component 112 to connect to customer-selected data sources and execute segmentation conditions directly within the customer computing environment 110 without transmitting data values to the campaign management platform 102.
[0067] At step 402, the customer-side processing component 112 connects to the one or more customer databases through BYOW integrations using programmatic interfaces, wherein the one or more customer databases comprise one or more data storage systems such as relational databases, analytical data warehouses, event stores, and application programming interfaces. The term "BYOW" refers to a configuration mechanism that enables customers to designate their own existing data sources for use in segmentation operations, rather than requiring data to be copied or migrated to the campaign management platform's infrastructure. The term "programmatic interfaces" refers to software interfaces that enable the customer-side processing component 112 to interact with data sources through code, including database connection protocols, API endpoints, or data access libraries.
[0068] In some embodiments, the one or more customer databases may comprise relational databases such as PostgreSQL, MySQL, Microsoft SQL Server, or Oracle Database, accessed using database connection protocols such as Java Database Connectivity (JDBC) or Open Database Connectivity (ODBC). The customer-side processing component 112 establishes a database connection using connection parameters such as hostname, port, database name, username, and password provided by the customer. In some embodiments, the one or more customer databases may comprise analytical data warehouses such as Snowflake, Amazon Redshift, Google BigQuery, or Azure Synapse Analytics, accessed using their respective connection protocols or software development kits (SDKs). In some embodiments, the one or more customer databases may comprise application programming interfaces exposed by internal customer systems, accessed using HTTP/HTTPS requests conforming to REST or GraphQL API conventions.
[0069] The customer provides BYOW configuration information to the customer-side processing component 112, specifying the data source type, connection parameters, authentication credentials, and mapping between schema entities and data source tables or endpoints. For example, a customer might configure: "Account entity maps to accounts table in PostgreSQL database at db.internal.company.com." The customer-side processing component 112 stores this configuration and uses it to establish connections when executing customer-executed portions. All connections occur within the customer computing environment 110, ensuring that data does not traverse network boundaries to external systems.
[0070] At step 404, the customer-side processing component 112 executes the customer-executed portion directly within the one or more customer databases. The phrase "executes directly within" indicates that the query or condition evaluation occurs at the data source location, leveraging the computational resources and query optimization capabilities of the customer database system. In some embodiments, the customer-side processing component 112 translates conditions in the customer-executed portion into database-native query languages such as Structured Query Language (SQL) for relational databases, or into API requests for API-based data sources. For example, if the customer-executed portion includes the condition "account balance greater than $10,000," the customer-side processing component 112 generates an SQL query such as "SELECT account_id FROM accounts WHERE balance > 10000." The database executes this query using its own query engine, returning only the matching account identifiers to the customer-side processing component 112. This approach minimizes data transfer and leverages the performance optimization capabilities of the customer database system.
[0071] At step 406, the customer-side processing component 112 queries data from the one or more customer databases to evaluate segmentation conditions. The customer-side processing component 112 executes the database queries or API calls generated from the customer-executed portion, retrieving only the data necessary to evaluate the specified conditions. In some embodiments, the customer-side processing component 112 may execute multiple queries if the customer-executed portion includes conditions referencing multiple entity types or requires joining data from multiple tables. For example, if a condition references both Account and Transaction entities, the customer-side processing component 112 may execute queries against both the accounts table and the transactions table, then perform local processing to combine the results. The customer-side processing component 112 handles query execution within the customer computing environment 110, ensuring that retrieved data values do not leave the environment.
[0072] At step 408, the customer-side processing component 112 generates entity identifiers from query results while maintaining data within the customer computing environment. After evaluating the segmentation conditions and identifying matching entities, the customer-side processing component 112 extracts only the common identifiers (such as CUIDs) from the query results. The customer-side processing component 112 discards or does not persistently retain the data values from the second data domain (such as account balances, transaction amounts, or other sensitive fields). In some embodiments, the customer-side processing component 112 may temporarily store data values from the second data domain in ephemeral storage for use in subsequent personalization operations, wherein the ephemeral storage is cleared after the personalization operation completes. The temporarily stored data values remain within the customer computing environment 110 and are not transmitted to the campaign management platform 102. For example, if a query returns results: [{account_id: "ACC_001", balance: 15000}, {account_id: "ACC_002", balance: 25000}], the customer-side processing component 112 extracts only the account identifiers ["ACC_001", "ACC_002"] and does not include the balance values in the result set transmitted to the campaign management platform 102. This extraction process ensures that only identifiers are prepared for transmission to the campaign management platform 102.
[0073] At step 410, the customer-side processing component 112 returns entity identifiers to itself for transmission to the campaign management platform 102. This step represents the preparation of the second set of entity identifiers for the transmission that occurs at step 212 of FIG. 2. The customer-side processing component 112 formats the entity identifiers according to the expected format for the API communication with the campaign management platform 102, applies any necessary transformations (such as mapping internal identifiers to CUIDs if different identifier formats are used internally), and prepares the transmission payload. The egress specifications configured on the customer-side processing component 112 ensure that this transmission contains only identifier data and is directed only to the whitelisted hostname of the campaign management platform 102. The BYOW process thus enables flexible integration with diverse customer data sources while maintaining strict data isolation boundaries.
[0074] Referring to FIG. 5, a flowchart 500 illustrates an identifier synchronization process for bootstrapping common identifiers in the campaign management platform, according to aspects of the present disclosure. The identifier synchronization process enables the campaign management platform 102 to receive and store common identifiers from the customer computing environment 110, allowing correlation between entities represented in the first data domain and entities represented in the second data domain. The customer databases in the second data domain already contain entity identifiers that will serve as common identifiers. These identifiers must be synchronized to the campaign management platform 102 to enable future correlation operations.
[0075] At step 502, the campaign management platform 102 receives initial identifier data comprising the common identifiers through an initial data upload process. The initial data upload process refers to a one-time or infrequent bulk transfer of identifier information from the customer's systems to the campaign management platform 102 to establish the baseline set of common identifiers. The customer databases already contain entity identifiers that will serve as common identifiers for correlation between the two data domains. For example, the customer database might contain user records with a user_id field: {user_id: "user_001", ...}, {user_id: "user_002", ...}. These user_id values serve as the CUIDs that will be used for correlation. The customer uploads these identifier values to the campaign management platform 102, which stores them in the behavioral data repository 108 to enable future correlation with identifiers returned by the customer-side processing component 112. The initial data upload typically occurs during initial system setup or onboarding, establishing the foundational set of identifiers that exist in both data domains.
[0076] Alternatively, at step 504, the campaign management platform 102 receives identifier data comprising the common identifiers through an API-based synchronization process. The API-based synchronization process refers to an ongoing or incremental mechanism for updating identifiers through API calls. In this approach, the customer's systems provide an API endpoint that the campaign management platform 102 can query to retrieve current identifier sets on demand or on a scheduled basis, or the customer's systems push new identifiers to the campaign management platform 102 via API calls when new entities are created. For example, when a new user is created in the customer's system with user_id "user_003," the customer's system may trigger an API call to the campaign management platform 102 providing this new identifier. The campaign management platform 102 stores this identifier in the behavioral data repository 108. The API-based approach enables dynamic synchronization, accommodating scenarios where new entities are frequently added or identifier values change over time.
[0077] At step 506, the campaign management platform 102 stores the common identifiers in the behavioral data repository 108 for enabling correlation between entities represented in the first data domain and entities represented in the second data domain. The campaign management platform 102 maintains these identifiers as part of its entity records in the first data domain. The stored identifiers use the same values as the identifiers in the customer databases in the second data domain, ensuring that when the customer-side processing component 112 returns entity identifiers from the second data domain, the campaign management platform 102 can correlate them with entities in the first data domain. For example, if a user with user_id "user_001" exists in both the customer database (second data domain) and the campaign management platform's repository (first data domain), the same identifier value "user_001" enables direct correlation without requiring identifier translation or mapping between different identifier schemes.
[0078] At step 508, the campaign management platform 102 updates stored identifiers when new entities are added or identifier values change. In some embodiments, the campaign management platform 102 receives update notifications from the customer's systems when new entities are created. For example, when a new user is registered in the customer's system, the customer's system may trigger an API call to the campaign management platform 102 providing the new user's identifier. The campaign management platform 102 adds this new identifier to its repository in the first data domain, creating a corresponding entity record. In some embodiments, if an entity's identifier value is updated in the customer's system, the customer's system notifies the campaign management platform 102 of the change, ensuring that subsequent segmentation operations use the correct identifier values for correlation.
[0079] At step 510, the campaign management platform 102 maintains consistency of common identifiers across both data domains. Consistency maintenance ensures that identifiers stored in the behavioral data repository 108 (first data domain) match the identifiers in the customer databases (second data domain). In some embodiments, the campaign management platform 102 validates identifier synchronization periodically by requesting identifier counts or checksums from the customer-side processing component 112, detecting any inconsistencies such as missing identifiers or count mismatches. If inconsistencies are detected, the campaign management platform 102 may trigger a resynchronization process to obtain updated identifier sets from the customer databases. The identifier synchronization process ensures reliable correlation during the merge operation at step 214 of FIG. 2, enabling accurate final segment determination even though the two data domains are physically separated and the customer-side processing component 112 returns only identifiers without associated data values.
[0080] Referring to FIG. 6, a flowchart 600 illustrates an action execution process using the final segment, according to aspects of the present disclosure. This process enables the campaign management platform 102 to utilize the final segment determined through the distributed segmentation process for downstream actions.
[0081] At step 602, the campaign management platform 102 receives the final segment comprising entity identifiers determined through the distributed segmentation process. The final segment comprises a collection of entity identifiers representing entities that satisfy all conditions in the segmentation definition across both the first data domain and the second data domain. The campaign management platform 102 receives the final segment from the segmentation engine 106 and prepares to execute actions based on the segmented entity list.
[0082] At step 604, the campaign management platform 102 determines one or more actions to be executed on the final segment. The one or more actions may comprise delivering personalized communications to user devices associated with entities in the final segment, exporting segment data to external systems, triggering automated workflows, updating analytics dashboards, or other operations based on the segmented entity list. The determination is based on campaign configuration settings that specify which operations should be performed using the final segment.
[0083] At step 606, the campaign management platform 102 initiates the one or more actions on the final segment via one or more external communication channels, wherein the one or more external communication channels comprise one or more channels such as email channels, messaging channels, push notification channels, MS channels, in-application notification channels, voice communication channels, or RCS channels. The campaign management platform 102 prepares communication delivery instructions for entities in the final segment and transmits communication delivery requests to external communication service providers 116. The communication delivery requests include entity identifiers from the final segment and communication specifications. In some embodiments, initiating actions may also include exporting the final segment to external systems for use in other platforms, triggering automated workflows that operate on the segmented entity list, or updating segment repositories for future campaign use.
[0084] At step 608, the campaign management platform 102 coordinates delivery of communications to user devices 118 associated with entities in the final segment through external communication service providers 116. The external communication service providers 116 process the delivery requests and send communications to the user devices 118. The entities in the final segment thus receive communications on their user devices 118, completing the communication delivery workflow initiated by the segmentation operation.
[0085] At step 610, the campaign management platform 102 updates campaign analytics with segment performance data and action execution status. The campaign analytics include metrics such as final segment size, communications delivered, and action execution results. The segment performance data provides insight into the effectiveness of the segmentation definition and the distributed segmentation process.
[0086] The system 100 and method 200, as elaborated across FIGS. 1-6, thus enable comprehensive distributed segmentation and action execution workflows while maintaining strict data isolation boundaries. Data from the second data domain remains within the customer computing environment 110 throughout all operations. The campaign management platform 102 orchestrates segmentation logic, coordinates distributed execution, merges results using common identifiers, and initiates actions on the final segment, all without requiring access to or storage of data values from the second data domain. The customer-side processing component 112 executes segmentation conditions locally within the customer computing environment 110 and transmits only entity identifiers to the campaign management platform 102. The distributed architecture achieves the technical objectives of enabling full-featured segmentation capabilities while satisfying customer requirements for data isolation, regulatory compliance, and minimized data exposure.
[0087] A number of implementations have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the disclosure. Accordingly, other implementations are within the scope of the following claims.
, Claims:WE CLAIM:

1. A system for performing distributed segmentation of entities for targeted communication, the system comprising:
a campaign management platform configured to:
receive a segmentation definition comprising conditions for segmenting entities across multiple data domains;
partition the segmentation definition into a platform-executed portion and a customer-executed portion based on data domain characteristics;
execute the platform-executed portion to generate a first set of entity identifiers;
transmit the customer-executed portion to a customer-side processing component for execution; and
merge the first set of entity identifiers with a second set of entity identifiers received from the customer-side processing component using common identifiers to determine a final segment; and
the customer-side processing component deployed by the campaign management platform and executing, under control of the campaign management platform, within a customer computing environment comprising one or more customer databases, the customer-side processing component being configured to:
receive the customer-executed portion from the campaign management platform;
evaluate the customer-executed portion against data in the one or more customer databases to generate the second set of entity identifiers; and
transmit the second set of entity identifiers to the campaign management platform,
wherein the campaign management platform is configured to initiate one or more actions on the final segment via one or more external communication channels, and
wherein data from the second data domain remains within the customer computing environment.

2. The system of claim 1, wherein the entities comprise entity types including users, accounts, cardholders, vehicles, policies, or custom entities, and wherein the common identifiers comprise customer-designated identifiers including CUID, canonical entity identifiers, account identifiers, or custom entity identifiers.

3. The system of claim 1, wherein the campaign management platform is further configured to:
configure a customer-specific schema through BYOS, wherein the customer-specific schema comprises entity types, field definitions, data type specifications, and inter-entity relationships including one-to-one relationships, one-to-many relationships, many-to-one relationships, and many-to-many relationships; and
adapt partitioning logic of the segmentation definition based on the customer-specific schema.

4. The system of claim 3, wherein the customer-side processing component is configured to connect to the one or more customer databases through BYOW integrations using programmatic interfaces, wherein the one or more customer databases comprise one or more data storage systems including relational databases, analytical data warehouses, event stores, and application programming interfaces, and wherein the customer-executed portion is executed directly within the one or more customer databases by the customer-side processing component.

5. The system of claim 1, wherein the customer computing environment comprises one or more of on-premise infrastructure, private cloud infrastructure, and customer-controlled public cloud infrastructure, and wherein the customer-side processing component is configured with network access controls with whitelisted ingress and egress specifications.

6. The system of claim 1, wherein the campaign management platform transmits the customer-executed portion to the customer-side processing component asynchronously through an API communication protocol, wherein the customer-side processing component executes the customer-executed portion independently and in parallel with execution of the platform-executed portion, wherein the customer-side processing component implements retry mechanisms for handling retriable errors during execution, and wherein the campaign management platform produces the final segment upon receiving completion signals from both execution portions.

7. The system of claim 1, wherein the first data domain comprises behavioral data including user interaction events, campaign engagement metrics, application activity logs, and digital touchpoint data, user profile data including non-sensitive user attributes, and data associated with platform entities, and wherein the second data domain comprises customer-designated sensitive data including one or more of transactional data, financial records, PII, health data, proprietary datasets, and confidential information.

8. The system of claim 1, wherein the common identifiers enable independent and parallel computation of segmentation conditions in the first data domain and the second data domain, and wherein the campaign management platform performs correlation by matching the common identifiers between the first set of entity identifiers and the second set of entity identifiers.

9. The system of claim 1, wherein the one or more external communication channels comprise one or more channels including email channels, messaging channels, push notification channels, short message service channels, in-application notification channels, voice communication channels, and rich communication service channels, and wherein the one or more actions comprise delivering personalized communications to user devices associated with entities in the final segment.

10. The system of claim 3, wherein the campaign management platform is configured to maintain synchronization between the customer-specific schema and active segmentation definitions through a manual schema update process, wherein schema updates including field additions, field modifications, data type changes, and relationship modifications are reflected through configuration changes, and wherein schema updates are propagated to the customer-side processing component.

11. The system of claim 1, wherein the campaign management platform is configured to receive initial identifier data comprising the common identifiers from the customer computing environment through one or more of an initial data upload process and an API-based synchronization process, and wherein the common identifiers stored in the campaign management platform enable correlation with entity identifiers returned from the customer-side processing component.

12. The system of claim 1, wherein the partitioning is based on analysis of entity relationships defined in a customer-specific schema, wherein the customer-specific schema specifies remote entities having one-to-one relationships with platform entities, wherein the platform-executed portion comprises conditions evaluable using data associated with the platform entities, and wherein the customer-executed portion comprises conditions evaluable using data associated with the remote entities.

13. The system of claim 1, wherein merging the first set of entity identifiers with the second set of entity identifiers comprises performing one or more set operations selected from intersection, union, and difference operations based on logical operators specified in the segmentation definition.

14. A method for performing distributed segmentation of entities for targeted communication, the method comprising:
receiving, by a campaign management platform, a segmentation definition comprising conditions for segmenting entities across multiple data domains;
partitioning, by the campaign management platform, the segmentation definition into a platform-executed portion and a customer-executed portion based on data domain characteristics;
executing, by the campaign management platform, the platform-executed portion to generate a first set of entity identifiers;
causing, by the campaign management platform, execution of the customer-executed portion by a customer-side processing component deployed by the campaign management platform and executing, under control of the campaign management platform, within a customer computing environment comprising one or more customer databases, the causing comprising:
transmitting the customer-executed portion to the customer-side processing component;
evaluating the customer-executed portion against data in the one or
more customer databases to generate a second set of entity identifiers; and
transmitting the second set of entity identifiers to the campaign management platform;
merging, by the campaign management platform, the first set of entity identifiers with the second set of entity identifiers using common identifiers to determine a final segment; and
initiating, by the campaign management platform, one or more actions on the final segment via one or more external communication channels, wherein data from the second data domain remains within the customer computing environment.

15. The method of claim 14, wherein the entities comprise entity types such as users, accounts, cardholders, vehicles, policies, or custom entities, and wherein the common identifiers comprise customer-designated identifiers including CUID, canonical entity identifiers, account identifiers, or custom entity identifiers.

16. The method of claim 14, wherein the customer computing environment comprises one or more of on-premise infrastructure, private cloud infrastructure, and customer-controlled public cloud infrastructure, and wherein the customer-side processing component is configured with network access controls with whitelisted ingress and egress specifications.

17. The method of claim 14, wherein the campaign management platform transmits the customer-executed portion to the customer-side processing component asynchronously through an API communication protocol, wherein the customer-side processing component executes the customer-executed portion independently and in parallel with execution of the platform-executed portion, wherein the customer-side processing component implements retry mechanisms for handling retriable errors during execution, and wherein the campaign management platform produces the final segment upon receiving completion signals from both execution portions.

18. The method of claim 14, wherein the first data domain comprises behavioral data including user interaction events, campaign engagement metrics, application activity logs, and digital touchpoint data, user profile data including non-sensitive user attributes, and data associated with platform entities, and wherein the second data domain comprises customer-designated sensitive data including one or more of transactional data, financial records, PII, health data, proprietary datasets, and confidential information.

19. The method of claim 14, wherein merging the first set of entity identifiers with the second set of entity identifiers comprises performing one or more set operations selected from intersection, union, and difference operations based on logical operators specified in the segmentation definition.

20. A computer program product comprising a non-transitory computer-readable medium having computer-readable program code stored thereon, the computer-readable program code comprising instructions that when executed by a processor cause a campaign management platform to:
receive a segmentation definition comprising conditions for segmenting entities across multiple data domains;
partition the segmentation definition into a platform-executed portion and a customer-executed portion based on data domain characteristics;
execute the platform-executed portion to generate a first set of entity identifiers;
cause execution of the customer-executed portion by a customer-side processing component deployed by the campaign management platform and executing, under control of the campaign management platform, within a customer computing environment comprising one or more customer databases, the causing comprising:
transmitting the customer-executed portion to the customer-side processing component;
evaluating the customer-executed portion against data in the one or
more customer databases to generate a second set of entity identifiers; and
transmitting the second set of entity identifiers to the campaign management platform;
merge the first set of entity identifiers with the second set of entity identifiers using common identifiers to determine a final segment; and
initiate one or more actions on the final segment via one or more external communication channels, wherein data from the second data domain remains within the customer computing environment.