Identity mapping indexes for efficient data analysis

Abstract

A system and method for efficient identity data matching using compressed mapping indexes generates an identity mapping index that consolidates identity mapping relationships from multiple sources into a compact, binary-encoded structure where source identifiers are mapped to integer values representing the presence or absence of mappings across multiple partners. Data is processed through identity resolution to generate both derived identifiers (generated directly from input data) and maintained identifiers (linked to a persistent identity graph). The system performs matching operations against identity mapping indexes using derived-only identifiers and derived-plus-maintained identifiers separately, then compares results to quantify the performance improvement from identity graph-based resolution. The compressed index structure significantly reduces storage requirements and enables rapid join operations. The system includes data ingestion modules supporting multiple transfer protocols, identity resolution pipelines, matching engines, statistics generation modules, and security controls for data deletion after processing.

Description

IDENTITY MAPPING INDEXES FOR EFFICIENT DATA ANALYSISCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of US Provisional Patent Application No. 63 / 711,628, filed on October 24, 2024. Such application is incorporated by reference herein.FIELD OF THE INVENTION

[0002] The present invention relates generally to systems and methods for identity resolution and data analytics. More particularly, the invention relates to systems and methods for efficiently matching customer data against large-scale identity mapping datasets, generating insights about data coverage and overlap.BACKGROUND OF THE INVENTION

[0003] In the modern data analytics ecosystem, organizations increasingly rely on identity resolution services to connect disparate data sources and enable cross-device, cross-platform targeting and measurement. Identity resolution providers maintain large-scale identity graphs that map various identifiers (such as email addresses, mobile advertising IDs (MAIDs) , cookie IDs, and other pseudonymous identifiers) to persistent person-level or household-level identifiers.

[0004] A significant challenge faced by identity resolution service providers is demonstrating their value proposition. Prospective customers typically want to understand how their existing data assets would benefit from an identity resolution service before committing to a purchase. Specifically, they want to know what percentage of customer records can be resolved to persistent identifiers; how much overlap exists between an audience and various destinations or publisher inventories; what incremental reach gain may be realized by using identity resolution versus relying solely on deterministic identifiers like hashed email addresses (HEMs) .

[0005] Answering these questions presents substantial technical challenges. Identity resolution providers maintain massive datasets, often containing terabytes or even petabytes of mapping files that associate source identifiers with target identifiers across thousands of partners, publishers, and platforms. To provide meaningful insights to a prospective customer, the provider would need to resolve the customer's data through their identity graph and then match the resolved identifiers against these extensive mapping datasets.

[0006] Performing such operations at scale is computationally expensive and time-consuming. Traditional approaches would require joining customer data tables against numerous large mapping tables, which can take hours or even days to complete. This is impractical in a context where responsiveness is critical. Moreover, repeatedly performing such operations for multiple prospective customers places significant strain on computational resources.

[0007] Another challenge relates to data privacy and security. During evaluations, prospective customers may be hesitant to share sensitive customer data, and identity resolution providers must implement strict controls to ensure customer data is handled securely, used only for the stated evaluation purpose, and properly deleted afterward.

[0008] Additionally, there is a need to demonstrate the incremental value of proprietary identity resolution over simpler alternatives. Many organizations use hashed email addresses (HEMs) as common identifiers for data matching. However, HEM-based matching has significant limitations because it only works when email addresses are available in both datasets, it doesn't account for multiple devices or identifiers associated with the same person, and it doesn't leverage probabilistic matching or household-level connections. Identity resolution providers need an effective way to quantify and demonstrate the "lift" or improvement their services provide compared to HEM-only matching.

[0009] Existing visualization approaches suffer from various deficiencies. Some systems simply provide estimates based on historical averages rather than analyzing the specific customer's actual data. Others require extensive manual work by solutions engineers to set up custom analyses for each prospective customer. Still others lack the ability to show comparative metrics that isolate the value contribution of the identity resolution service itself versus deterministic matching alone.

[0010] Furthermore, conventional data structures for storing and querying large-scale mapping data are inefficient. Maintaining separate mapping tables for each partner or destination requires substantial storage capacity and makes queries slow. There is no effective way to compress these mapping relationships while still enabling fast lookups and overlap calculations.

[0011] What is needed, therefore, are improved systems and methods that enable identity resolution providers to efficiently demonstrate value. Such systems should be able to rapidly ingest and resolve customer data, match resolved identifiers against large-scale partner and destination universes, generate meaningful statistics about coverage and overlap, and quantify the incremental value provided by the identity resolution service. The systems should employ efficient data structures and algorithms that enable these operations to be performed quickly and cost-effectively, while maintaining appropriate data security and privacy controls.

[0012] References mentioned in this background section are not admitted to be prior art with respect to the invention as defined by the claims set forth herein.SUMMARY OF THE INVENTION

[0013] The present invention provides systems and methods for efficiently matching customer data against large-scale identity mapping datasets and generating statistical insights about data coverage, overlap, and identity resolution performance. The invention addresses the technical challenges of processing and analyzing massive datasets (often terabytes or petabytes in size) in a time-efficient and computationally feasible manner.

[0014] In one aspect, the invention introduces a novel compressed data structure called an “identity mapping index" that efficiently represents identity mapping relationships across multiple data sources. Rather than maintaining separate mapping tables for each partner or destination (which would require storing millions or billions of individual identifier pairs) , the identity mapping index consolidates mapping relationships for an entire "universe" of related mapping files into a compact, binary-encoded format.

[0015] The identity mapping index structure comprises a table with rows corresponding to source identifiers and columns corresponding to partner groups. Each cell contains an integer value that represents, in binary form, whether the source identifier has mappings to various partners within that group. By encoding the presence or absence of mapping relationships as bits within integers, the system achieves significant data compression while maintaining the ability to perform rapid join operations and statistical calculations.

[0016] In another aspect, the invention provides a comprehensive workflow for data analysis. The system receives customer data through various ingestion methods (including SFTP connections, cloud storage transfers, and browser-based file uploads) , processes the data through an identity resolution pipeline to generate resolved identifiers, and then matches the resolved identifiers against one or more identity mapping indexes representing different universes (such as technology partners, publisher inventories, or other destinations) . The system generates detailed statistics including overall match counts, per-partner match counts, overlap metrics, and coverage percentages.

[0017] An innovation of the invention in certain embodiments is its method for quantifying the incremental value of identity resolution services through comparative analysis. The system performs identity resolution to generate two types of identifiers: (1) derived identifiers, which are generated directly from the input data without reference to an external identity graph, and (2) maintained identifiers, which represent established entities within a persistent identity graph. The system then performs matching operations twice-once using only derived identifiers and once using both derived and maintained identifiers-and compares the results to calculate the "lift" or improvement provided by the identity graph-based resolution.

[0018] This comparative analysis technique effectively demonstrates the difference between deterministic matching (represented by derived-only matching) and enhanced identity resolution (represented by derived plus maintained matching) , allowing for quantification of the performance improvement. The system can express this improvement in various metrics such as percentage point increases, multipliers, or projected value calculations.

[0019] In certain embodiments, the invention further includes methods for expanding identity mapping indexes to account for identifier relationships. Specifically, when an identity graph indicates that multiple derived identifiers are associated with a single maintained identifier (or vice versa) , the system generates additional rows in the identity mapping index to represent these relationships. This expansion ensures that customer data containing any associated identifier can be matched against the appropriate mapping relationships.

[0020] The system architecture according to certain embodiments of the invention incorporates several technical components including: a data ingestion layer supporting multiple transfer protocols; an identity resolution engine utilizing stored procedures and data pipelines; a staging area for intermediate data storage; a matching engine that performs joins between customer data and identity mapping indexes; a statistics generation module that calculates various metrics; and a presentation layer that delivers results to users through dashboards or application programming interfaces (APIs) .

[0021] A feature of certain embodiments of the invention is its data security and privacy framework. The system includes mechanisms for deleting customer data and credentials after analysis is complete, ensuring that sensitive information is not retained unnecessarily. Access controls limit which personnel can view customer data, and the system maintains audit logs of data processing activities.

[0022] The invention in certain embodiments provides numerous technical advantages over prior approaches. By using compressed identity mapping indexes instead of separate mapping tables, the system dramatically reduces storage requirements and improves query performance. The ability to perform rapid matching operations enables near-real-time analysis rather than requiring hours or days for results. The comparative analysis methodology provides objective, quantitative metrics rather than subjective estimates. The flexible ingestion framework accommodates various customer preferences and technical capabilities. Overall, the invention enables efficient processing and analysis of massive identity datasets while maintaining appropriate security and privacy controls.

[0023] In one aspect, the invention is directed to a system for efficient identity data matching and statistical analysis, comprising a data ingestion module configured to receive customer data containing a plurality of customer identifiers, an identity resolution engine configured to process the customer data and generate resolved identifier data, wherein the resolved identifier data includes a first set of derived identifiers generated directly from the customer identifiers, and a second set of maintained identifiers representing entities within a persistent identity graph, a data storage system storing at least one compressed identity mapping index, wherein the compressed identity mapping index comprises a plurality of rows, each row corresponding to a source identifier, a plurality of columns corresponding to partner groups, and integer values in cells of the index, wherein each integer value encodes, in binary form, the presence or absence of mapping relationships between the source identifier and multiple partners within the corresponding partner group, a matching engine configured to perform a first matching operation by joining the first set of derived identifiers against the compressed identity mapping index to generate first match statistics, and perform a second matching operation by joining both the first set of derived identifiers and the second set of maintained identifiers against the compressed identity mapping index to generate second match statistics, and a statistics generation module configured to calculate comparative metrics by comparing the first match statistics with the second match statistics, wherein the comparative metrics quantify performance differences between the first matching operation and the second matching operation.

[0024] In another aspect, the invention is directed to a method for efficient identity data matching and statistical analysis, comprising receiving customer data containing a plurality of customer identifiers, performing identity resolution on the customer data to generate a first identifier column containing only derived identifiers generated directly from the customer identifiers, and a second identifier column containing both derived identifiers and maintained identifiers representing entities within a persistent identity graph, accessing a compressed identity mapping index stored in a database, wherein the compressed identity mapping index encodes mapping relationships between source identifiers and multiple partners using binary-encoded integer values, performing a first join operation between the first identifier column and the compressed identity mapping index to generate first match results, performing a second join operation between the second identifier column and the compressed identity mapping index to generate second match results, calculating comparative statistics by comparing the first match results with the second match results, and generating a report presenting the comparative statistics, wherein the comparative statistics quantify performance improvement attributable to the maintained identifiers.

[0025] In another aspect, the invention is directed to a compressed identity mapping index data structure stored in non-transitory computer-readable memory, comprising a table with a plurality of rows and a plurality of columns, wherein each row corresponds to a unique source identifier, each column corresponds to a partner group containing multiple partners, each cell contains an integer value representing, in binary form, a plurality of binary flags indicating whether the source identifier has mapping relationships with each partner in the corresponding partner group, and the data structure consolidates mapping relationships from multiple separate mapping files into a single unified structure that enables efficient join operations for determining data overlap statistics.

[0026] In summary, the present invention in various embodiments provides a technically sophisticated solution to the challenges of large-scale identity data matching and analysis, employing novel data structures, efficient algorithms, and innovative analytical methodologies to achieve superior performance and practical utility.

[0027] These and other features, objects and advantages of the present invention will become better understood from a consideration of the following detailed description of the preferred embodiments and appended claims in conjunction with the drawings as described following:BRIEF DESCRIPTION OF DRAWINGS

[0028] Fig. 1 is an overall data flow diagram according to an embodiment of the present invention.

[0029] Fig. 2 is an overall architectural layout according to an embodiment of the present invention.

[0030] Fig. 3 is a data flow diagram for an example in which a customer maintains its offline PII data within its own customer environment according to an embodiment of the present invention.

[0031] Fig. 4 is a data flow diagram for an example in which a customer maintains its own SFTP server according to an embodiment of the present invention.

[0032] Fig. 5 is a data flow diagram for an example in which a customer uploads a data file directly through its browser window according to an embodiment of the present invention.

[0033] Fig. 6 is a comprehensive system architecture for a system for generating and utilizing identity mapping indexes in the context of customer value visualization according to an embodiment of the present invention.

[0034] Fig. 7 is a data flow diagram illustrating a process for expanding identity mapping indexes to demonstrate incremental value provided relative to deterministic matching alone according to an embodiment of the present invention.

[0035] Fig. 8 is a diagram of a computing hardware component of an overall distributed architecture for implementation of an embodiment of the present invention.DETAILED DESCRIPTION OF THE INVENTION

[0036] Before the present invention is described in further detail, it should be understood that the invention is not limited to the particular embodiments described, and that the terms used in describing the particular embodiments are for the purpose of describing those particular embodiments only, and are not intended to be limiting, since the scope of the present invention will be limited only by the claims.

[0037] The present invention provides systems and methods for efficiently matching customer data against large-scale identity mapping datasets and generating statistical insights about data coverage, overlap, and identity resolution performance. The invention employs a novel compressed data structure called an “identity mapping index” that consolidates identity mapping relationships from multiple sources into a compact, binary-encoded format, enabling rapid join operations and statistical calculations on datasets that would otherwise require terabytes of storage and hours of processing time.

[0038] Referring to Fig. 1, the high-level workflow of the system is illustrated. The process begins when a customer 100 initiates interaction with the system during a cycle 140. The customer 100 visits a user interface (UI) 104, which may be a web-based customer value visualization (CVV) interface accessible through a browser.

[0039] Upon accessing the UI 104, the customer 100 completes an onboarding flow 106, during which the customer provides necessary credentials and configuration information for accessing their data. The onboarding flow 106 collects information such as data source locations, field mappings, and authentication credentials.

[0040] Once onboarding is complete, the system proceeds with a series of automated processing steps. The data ingestion module 110 receives and ingests the customer's data from the configured source. This customer data typically contains personally identifiable information (PII) or pseudonymous identifiers that the customer wishes to analyze.

[0041] The ingested data is then processed by the identity resolution module 112, which resolves the customer's identifiers to persistent identity graph identifiers. The identity resolution module 112 applies deterministic and probabilistic matching algorithms to link the customer's identifiers to entities within a maintained identity graph. The output of this resolution process includes both derived identifiers (generated directly from the input data) and maintained identifiers (linked to existing graph entities) .

[0042] Following identity resolution, the base insights derivation module 114 calculates preliminary statistics about the resolved data, such as total record counts, resolution rates, and identifier distributions. These base insights provide foundational metrics for subsequent analysis.

[0043] The resolved identifier data is then processed by the matching module 116, which performs join operations between the customer's resolved identifiers and one or more identity mapping indexes representing different "universes" of partners, destinations, or data sources. The matching module 116 efficiently matches millions of customer identifiers against compressed representations of billions of partner mappings.

[0044] The results from the matching operations are collected by the insights collation module 118, which aggregates statistics from multiple matching operations and organizes them for presentation. The insights collation module 118 may combine results from multiple universes (such as technology partners, publisher inventories, and application inventories) and calculate overlap metrics, coverage percentages, and comparative statistics.

[0045] The compiled insights are then delivered to the various teams 102 through the insights delivery module 120. The delivery may occur through dashboards, reports, APIs, or other presentation mechanisms. The various teams 102 uses this data during the cycle 140 to demonstrate value to the customer 100 and inform commercial discussions.

[0046] A feature of the system is its data privacy and security controls. After the insights have been delivered, the customer credentials deletion module 130 automatically deletes any stored authentication credentials provided by the customer during onboarding. Similarly, the customer data deletion module 132 removes all copies of the customer's data from the system, ensuring that sensitive information is not retained beyond its necessary use.

[0047] Based on feedback from the cycle and customer interactions, the provider team may iterate on the process through feedback iteration process 142, refining insights, adjusting inputs, modifying onboarding procedures, or enhancing outputs to better serve customer needs.

[0048] Fig. 2 illustrates the high-level system architecture showing the major components and their interactions. The system provides three primary user-facing interfaces accessible through web browsers.

[0049] The landing page interface 200 serves as the entry point where users initiate the customer value visualization process. The mappings interface 202 allows users to configure field mappings, specifying how fields in their data files correspond to expected identifier types. The report interface 204 presents the final statistical insights and visualizations to users. Additionally, the visualization dashboard 206 provides a user interface (referred to as M1 or Milestone 1) for monitoring system operations and viewing detailed metrics.

[0050] The system supports multiple data ingestion mechanisms to accommodate different customer preferences and technical capabilities. The file upload module 210 enables users to upload data files directly through their web browser. The SFTP reader module 212 can retrieve data from SFTP servers, whether customer-owned or provided by the service. The S3 / GCP connector module 214 supports direct connections to cloud storage buckets in Amazon S3 or Google Cloud Platform. The file transfer API 216 provides programmatic access for automated data transfers.

[0051] Once data is received through any of these ingestion mechanisms, it is initially stored in the customer home bucket 230, which serves as a secure landing zone for raw customer data. From there, data flows through several processing stages.

[0052] The field headers processor 218 examines the structure of incoming data files to identify column headers and data formats. The field mappings processor 220 applies the user-configured mappings to interpret which fields contain which types of identifiers.

[0053] Data from the customer home bucket 230 is transferred to a primary staging area 232, which is a cloud storage location where data awaits processing by the identity resolution pipeline. The S2 pipeline 250 is a data transformation pipeline that prepares data for identity resolution, performing tasks such as normalization, validation, and formatting.

[0054] The ID resolution stored procedure 252 is a database stored procedure that performs the core identity resolution logic. This procedure takes the customer's input identifiers and resolves them against a persistent identity graph, generating both derived identifiers and maintained identifiers. The derived ID generation module 254 specifically handles the creation of derived identifiers based solely on the input data.

[0055] The results of identity resolution are written to two database tables. The derived ID table 240 contains records with derived provider IDs, record IDs, filenames, and timestamps. The maintained provider ID table 242 contains records with maintained provider IDs (which represent links to established entities in the identity graph) , along with record IDs, filenames, and timestamps.

[0056] After identity resolution, the resolved data is transferred to a secondary staging area 234, where it awaits matching operations. The match stored procedure 256 performs the actual matching of customer identifiers against identity mapping indexes. This stored procedure executes efficient join operations between the customer's resolved identifier tables and the compressed index structures.

[0057] The system maintains multiple identity mapping Indexes for different universes of partners and destinations. The ATS identity mapping index 260 contains mappings related to AdTech system partners. The PAIR identity mapping index 262 contains mappings for PAIR (Platform for Addressable Identity Resolution) partners. The AIM identity mapping index 264 contains mappings for Audience Identity Manager destinations.

[0058] The matching process is controlled and monitored through several API components. The match API trigger 270 initiates matching operations after identity resolution is complete. The match stats API 272 retrieves statistical results from completed matching operations.

[0059] An opt outs database 236 maintains records of identifiers that have opted out of data processing, ensuring compliance with privacy regulations and user preferences. Before performing matches, the system checks resolved identifiers against this opt-out list.

[0060] The final match statistics are stored in a statistics database 238, from which they can be retrieved for presentation through the various user interfaces.

[0061] Figs. 3-5 illustrate three different data flow scenarios based on different data ingestion methods. These scenarios share many common components but differ in how customer data initially enters the system.

[0062] In the scenario illustrated in Fig. 3, the customer 304 maintains its offline PII data 302 within its own customer environment 300. The customer provides credentials to a solutions engineer 306, who configures the system to access a service provider SFTP server.

[0063] The customer SFTP server 320 resides within the provider environment 310, specifically within the MTTN (Multi-Tenant Kubernetes) infrastructure 312. The customer 304 uploads its offline PII data 322 to this SFTP server 320.

[0064] From the SFTP server 320, data is transferred to the customer home bucket 324, where a copy of the customer offline PII 326 is stored in cloud storage. This transfer may be facilitated by automated processes within the MTTN infrastructure 312.

[0065] The customer 304 interacts with the system through a browser window 372 accessible over the public internet 370. Through this browser interface, the customer enters data credentials, specifies field mappings, and initiates the processing by clicking a "Go" or similar action button.

[0066] The data then flows into the data transformation project 340, where the SingleStore ingestion pipeline + resolution component 342 processes the data. This component performs both data ingestion and identity resolution operations. A trigger pipeline control 346 coordinates the timing and sequencing of pipeline operations.

[0067] After resolution, data moves into the PAIR project 350, where the match module 352 performs matching operations. The match API 356 provides an interface for initiating and monitoring these matches. A staging area 354 within the PAIR project temporarily holds data during the matching process. A trigger match job control 358 coordinates the execution of matching operations.

[0068] Finally, results are delivered to the UI dashboard 360, where they can be viewed and analyzed.

[0069] Fig. 4 illustrates a scenario where the customer maintains its own SFTP server rather than using a provider one. In this configuration, the customer-provided SFTP server 400 resides within the customer environment 300, along with the customer offline PII database 302 and a copy of customer offline PII 402 stored on the SFTP server 400.

[0070] The key architectural difference from Fig. 3 is that the provider system connects outbound to the customer's SFTP server 400 rather than the customer connecting inbound to a provider SFTP server. This provides additional security and control for customers who prefer to maintain their data within their own infrastructure. The same SFTP connector technology is used, but configured to read from the customer's location rather than a provider-hosted location.

[0071] Once data is retrieved from the customer-provided SFTP 400, the remaining data flow through the customer home bucket 324, data transformation project 340, PAIR project 350, and UI 360 is identical to Fig. 3.

[0072] Fig. 5 illustrates the simplest data ingestion scenario, where the customer 304 uploads a data file directly through its browser window 372. In this scenario, there is no SFTP server involved.

[0073] When the customer initiates a file upload through the browser interface, the system generates a short-lived signed URL for direct upload to the customer home bucket 324. The upload path 410 bypasses any intermediate storage and delivers the customer offline PII 326 directly to the customer home bucket 324 in cloud storage.

[0074] This direct upload approach provides the fastest and simplest user experience, though it may be less suitable for very large files or for customers who require automated, scheduled data transfers. Once the data reaches the customer home bucket 324, the subsequent processing through the data transformation project 340, PAIR project 350, and UI 360 is identical to the SFTP scenarios.

[0075] The system utilizes several database tables to store intermediate results and final statistics. Two key tables are match_stats_overall and match_stats_details.

[0076] The match_stats_overall table stores aggregate statistics for each matching operation. This table includes the following fields:

[0077] id (integer, primary key) : A unique identifier for each statistics record

[0078] request_id (integer) : An identifier linking the statistics to a specific customer request

[0079] customer_id (string) : An identifier for the customer whose data was analyzed

[0080] data_source_name (string) : The name of the customer's data source that was processed

[0081] stats_type (enumeration) : Indicates whether the statistics represent "DERIVED" (derived-only matching) or "OVERALL" (derived plus maintained matching)

[0082] universe (enumeration) : Identifies which universe was matched against, such as "DESTINATIONS, " "PAIR, " or "ATS"

[0083] overall_match_count (bigint) : The total number of customer identifiers that matched at least one partner in the universe

[0084] The match_stats_details table stores per-partner match statistics and is linked to the match_stats_overall table through a foreign key relationship. This table includes:

[0085] mso_id (integer, foreign key) : References the id field in match_stats_overall

[0086] target (string) : The identifier or name of a specific partner within the universe

[0087] match_count (bigint) : The number of customer identifiers that matched this specific partner

[0088] By maintaining separate overall and detailed statistics tables, the system can efficiently store both aggregate metrics (for quick overview displays) and granular per-partner metrics (for detailed analysis) without redundancy.

[0089] After identity resolution, customer data is stored in a resolution output structure with the following fields:

[0090] record_id (bigint) : A unique identifier for each input record from the customer's data

[0091] provider_id (string) : Either a derived provider ID (dID) or maintained provider ID (mID) resulting from resolution

[0092] derived_id (string) : Specifically contains the dID when applicable; this field is only populated for records that resolved to derived identifiers

[0093] It is important to note that the relationship between record_id and provider_id is one-to-many. A single input record may resolve to multiple provider IDs, particularly when household-level or multi-device matching occurs. This one-to-many relationship is preserved through the matching process.

[0094] The identity mapping index structure is a compressed representation of identity mappings. Rather than storing individual mapping records (which would require billions of rows) , the identity mapping index consolidates mappings using a compact binary-encoded format. The structure includes:

[0095] source_id (bigint) : The identifier being mapped (e.g., a dID or mID)

[0096] partner_group_1 (bigint) : An integer encoding the presence / absence of mappings to partners in the first partner group

[0097] partner_group_2 (bigint) : An integer encoding the presence / absence of mappings to partners in the second partner group

[0098] partner_group_3 (bigint) : An integer encoding the presence / absence of mappings to partners in the third partner group

[0099] Additional partner_group columns may be included as needed. Each integer value represents multiple binary flags encoded in base-10 format, where each bit position corresponds to a specific partner.

[0100] The identity mapping index compression methodology can be understood through a concrete example. Consider three separate partner mapping files (for a partner 1, partner 2, and partner 3, respectively) : Table 1 Table 2 Table 3

[0101] These three mapping files represent typical partner mapping data, where each partner maintains a separate file mapping source identifiers (in this case, dIDs) to their internal partner identifiers (PAIRIDs) . Storing and querying these files separately would require joining against three different tables.

[0102] The first step in creating an identity mapping index is to consolidate these mappings into a unified structure that indicates, for each source identifier, which partners have any mapping for that identifier. This can be represented in binary flag format: Table 4

[0103] In this representation, a "1" indicates that the source identifier has at least one mapping to the corresponding partner, while a "0" indicates no mapping exists. This binary flag table consolidates information from all three partner files into a single queryable structure.

[0104] However, this representation can be further compressed by recognizing that each row's set of binary flags can be encoded as an integer. For example, the row for SourceID "A" has flags [1, 1, 0] , which in binary represents 110, which equals 6 in decimal. Similarly:

[0105] SourceID B: [1, 0, 0] = 100 (binary) = 4 (decimal)

[0106] SourceID C: [1, 1, 1] = 111 (binary) = 7 (decimal)

[0107] SourceID D: [0, 1, 1] = 011 (binary) = 3 (decimal)

[0108] SourceID E: [0, 1, 0] = 010 (binary) = 2 (decimal)

[0109] SourceID F: [0, 0, 1] = 001 (binary) = 1 (decimal)

[0110] SourceID G: [0, 0, 1] = 001 (binary) = 1 (decimal)

[0111] This yields the compressed integer representation: Table 5

[0112] This compressed format significantly reduces storage requirements while maintaining all mapping relationship information. The integer value in the "Partners" column encodes which partners have mappings for that source identifier.

[0113] When a customer's data needs to be matched against these partner mappings, a simple join operation can be performed. For example, if a customer file contains the following identifiers: Table 6

[0114] Joining this customer file against the compressed identity mapping index yields: Table 7

[0115] From this result, match statistics can be calculated. For instance, customer identifier C has mappings to all three partners (binary 111 = 7) , so it contributes to the match count for Partners 1, 2, and 3. Customer identifier D has mappings to Partners 2 and 3 (binary 011 = 3) . Customer identifiers F and G each have mappings only to Partner 3 (binary 001 = 1) . Customer identifiers H and I do not appear in the result, indicating they have no mappings to any of these partners.

[0116] Overall statistics can be derived. For example, total customer identifiers is equal to 6 (C, D, F, G, H, I) . Matched identifiers is 4 (C, D, F, G) . And thus the overall match rate is 4 / 6 = 67%.

[0117] Per-partner statistics may also be derived. Partner 1 matches are 1 (only C) = 1 / 6 = 17%of customer base. Partner 2 matches are 2 (C and D) = 2 / 6 = 33%of customer base. Partner 3 matches are 4 (C, D, F, G) = 4 / 6 = 67%of customer base.

[0118] Conversely, the system can calculate what percentage of each partner's audience overlaps with the customer. Partner 1's overlap with customer is 1 / 3 = 33% (C matches, out of A, B, C in Partner 1's data) . Partner 2's overlap with customer is 2 / 4 = 50% (C, D match, out of A, C, D, E in Partner 2's data) . Partner 3's overlap with customer is 4 / 4 = 100% (C, D, F, G all match, and these are exactly Partner 3's identifiers) .

[0119] In practice, identity mapping indexes may contain millions or billions of source identifiers and may encode hundreds or thousands of partners. To accommodate this scale while maintaining efficient join performance, the integer encoding is distributed across multiple "partner group" columns. For example, partner_group_1 might encode partners 1-64 (using a 64-bit integer) , partner_group_2 might encode partners 65-128, and so on. The system maintains metadata mapping each partner to its corresponding partner group column and bit position within that column's integer value.

[0120] Fig. 6 illustrates the comprehensive system architecture for generating and utilizing identity mapping indexes in the context of customer value visualization. At the top of the diagram, the customer 500 interacts with the CVV UI 506, which provides identity insights and ingestion capabilities. A sample UI mockup display 508 shows example statistics such as impression counts, media CPM values, conversion rates, and customer lifetime value calculations that might be presented to customers. Sales team 502 and product / engineering / design team 504 collaborate throughout the cycle interaction 620, with feedback loop process 622 enabling continuous improvement, and with communication to customer 304 from sales team 502 throughout cycle interaction 620.

[0121] The system comprises several major subsystems that work together to collect data, generate indexes, and produce insights. The ATS Logger System 510 captures data from browser-based pixel serving 512. When users visit websites or applications that have implemented tracking pixels, these pixel events flow through the pixel to ATS DB pipeline 514. Topic queues 516 provide a distributed streaming platform for handling high-volume event data, and metadata is collected at ATS logger system metadata API 526.

[0122] Events are ingested into the ATS SingleStore database 518, where they are stored in log format 520. Periodically, the ATS snapshot stored procedure 522 executes to create point-in-time snapshots of the accumulated log data. These snapshots are exported as ATS snapshot parquet files 524 to cloud storage, where they can be efficiently processed by downstream systems. Opt-outs are processed at ATS logger opt-outs 528.

[0123] The PAIR Logger System 530 operates similarly to the ATS system but captures different types of identity events. Browser-based pixel serving 532 generates events that flow through the pixel to PAIR to PAIR DB pipeline 534. Topic queues 536 buffer and distribute these events.

[0124] Events are stored in the PAIR SingleStore database 538 in log format 540 and snapshots 548. The PAIR snapshot stored procedure 542 periodically creates snapshots for export. The PAIR system also includes a PAIR opt out stored procedure 544 for processing opt-out requests, ensuring compliance with privacy regulations. The PAIR metadata API 546 provides access to metadata about PAIR identifiers and mappings.

[0125] The identity mapping system 550 is the core component that generates and utilizes the compressed identity mapping indexes. The SingleStore database 552 serves as the central data store for this system. The system receives snapshot parquet files 556 from cloud storage, which may originate from the ATS Logger System, PAIR Logger System, or other sources. These snapshots contain the raw mapping data that will be compressed into identity mapping indexes.

[0126] Pipeline components 566 process input parquet files 568 and feed them to the build stored procedure 562. This stored procedure implements the compression algorithm described earlier, consolidating separate partner mapping files into the compact binary-encoded identity mapping index format. The resulting identity mapping index 558 is stored in the database for subsequent matching operations.

[0127] When customer data needs to be matched, input parquet files 570 containing resolved customer identifiers are processed by pipeline components 566 and passed to the identity mapping index match stored procedure 564. This stored procedure performs the join operations between customer identifiers and the identity mapping index 558, generating match results 572 that include both overall and per-partner statistics.

[0128] The opt out stored procedure 560 checks identifiers against opt-out lists before performing matches. The metadata API 574 provides access to metadata about the index structure, including which partners are encoded in which bit positions.

[0129] Several API components coordinate the matching process. The API build controller 580 manages the building of new identity mapping indexes. The match pipeline setup API 576 configures matching pipelines for specific customer requests. The match API 578 initiates matching operations. The report builder integration 582 generates reports and optionally delivers them through various channels. A pipeline configuration component 584 stores configuration settings for various pipelines.

[0130] The activation reach and destinations system 590 feeds data into the ecosystem from multiple sources. Multiple source systems 592 send data to the online identity (OI) system 594, which processes and normalizes identity data. The AIM mapping generation process 596 creates AIM mapping files 598 that associate source identifiers with target identifiers for various destinations.

[0131] The PAIR backend system 600 maintains the online identity graph 602, which is the persistent entity resolution graph used for maintained identifier generation. AIM mappings storage 604 holds the generated mapping files, and the AIM service 606 provides access to these mappings for downstream systems.

[0132] The online identity ARL<>PEL generation process 610 creates a specialized mapping table 612 that associates Authenticated Resolved Links (ARLs) with Pseudonymous Entity Links (PELs) . This ARL<>PEL table 612 is crucial for the identity expansion process described with reference to Fig. 7.

[0133] Fig. 7 illustrates the process for expanding identity mapping indexes to demonstrate the incremental value provided by identity graph-based resolution compared to deterministic matching alone (such as HEM-based matching) . The process begins with the Online Identity graph 800 and offline graph 808, which contains the persistent entity resolution graph including both online (authenticated) and offline identity data. The anonymize derived and maintained process 802 takes cluster identifiers from the graph and anonymizes them for privacy protection, generating new pseudonymous identifiers that preserve graph relationships without exposing underlying PII. This anonymization produces multiple instances of AIM Audience (ANA) files 804, which contain anonymized identity mappings. The process also generates an ARL<>PEL mapping file 806 that associates Authenticated Resolved Links (which represent maintained identifiers tied to the identity graph) with Pseudonymous Entity Links (which represent derived identifiers) .

[0134] The AIM audience files 804 are delivered to two destinations. They are provided to local encoder delivery 810 for use in encoding processes, and to pixel serving delivery 812 for integration with real-time pixel serving systems.

[0135] The existing process for generating identity mapping indexes proceeds as previously described. The generate identity mapping index process 814 creates an activation destination and device identity mapping index 816 using standard compression techniques. However, to demonstrate the full value of identity resolution, the system performs an expansion step. The expand identity mapping index for Derived IDs process 818 takes the ARL<>PEL mapping file 806 and uses it to augment the identity mapping index.

[0136] This expansion process works as follows. The original identity mapping index contains rows for maintained identifiers (represented as ARLs in this context) . Using the ARL<>PEL mapping file 806, the system identifies which derived identifiers (PELs) are associated with each maintained identifier (ARL) . For each such association, the system duplicates the row for the maintained identifier and creates a new row for the derived identifier, preserving the same partner mapping information. Table 8 Table 9

[0137] This mapping table shows that some ARLs (maintained identifiers) have multiple associated PELs (derived identifiers) . For example, ARL "A" is associated with both PEL "x1" and PEL "x6" .

[0138] After a join between Table 8 and Table 9, the result is as follows: Table 10

[0139] Note that some PELs appear multiple times (e.g., x1 appears twice, x3 appears twice) because they are associated with different ARLs that have different partner mappings. The final deduplicated table then is as shown below in Table 11: Table 11

[0140] In the final deduplicated version, each unique SourceID appears only once. For SourceIDs that appeared multiple times (like x1 and x3) , the partner flags are combined using a logical OR operation, so that the final row indicates all partners for which any associated ARL had a mapping.

[0141] This final identity mapping index now contains rows for both maintained identifiers (ARLs) and derived identifiers (PELs) , enabling comparative matching operations.

[0142] To demonstrate the value of identity resolution, the system performs two separate matching operations using customer data. The resolution process receives customer PII data and performs identity resolution to generate a resolved table. The resolved table contains multiple columns:

[0143] derived_only: contains only derived identifiers (dIDs) that were generated directly from the input data without matching to the persistent identity graph

[0144] derived_and_maintained: contains both derived identifiers and maintained identifiers (mIDs) that represent links to established entities in the identity graph

[0145] record_id: links each identifier back to the original input record

[0146] The match on derived only process performs a join between the derived_only column and the expanded identity mapping index, simulating the performance that would be achieved using only deterministic matching (such as HEM-based matching) . This generates "derived-only" match statistics.

[0147] The match on maintained and derived process performs a separate join between the derived_and_maintained column and the same expanded identity mapping Index, demonstrating the performance achieved when leveraging the full identity graph. This generates "derived plus maintained" match statistics.

[0148] The combine and calculate lift process compares these two sets of statistics to quantify the performance improvement attributable to identity graph-based resolution. For example, suppose the derived-only matching yields a 30%match rate (30%of customer records matched at least one partner) , while the derived-plus-maintained matching yields a 60%match rate. This represents a 30 percentage point increase, or a 100%lift (doubling of performance) , or a 2x multiplier.

[0149] If each percentage point of match rate correlates with a specific monetary value (for example, $20,000 in potential revenue) , the system can calculate the total value provided by identity resolution. In this example, derived-only performance is 30%× $20,000 / percentage point = $600,000. Derived-plus-maintained performance is 60%× $20,000 / percentage point = $1,200,000. And incremental value from identity resolution is $1, 200,000 -$600,000 = $600,000. These metrics provide concrete, quantifiable evidence of the value provided by identity graph-based resolution compared to simpler deterministic matching approaches.

[0150] It should be understood that "derived" identifiers in this context serve as a proxy for HEM-based or other deterministic matching approaches. Derived identifiers are customer-encoded identifiers generated directly from the input data without reference to the broader identity graph, making them functionally similar to HEMs in terms of matching capabilities, but with enhanced privacy properties since they are encoded specifically for each customer rather than being universal identifiers like HEMs.

[0151] While the detailed description above describes specific embodiments and implementations, various modifications and alternative approaches are possible without departing from the scope of the invention.

[0152] The identity mapping index structure may be implemented using different integer sizes and partitioning schemes. For example, while the description uses bigint (64-bit) integers for partner group columns, alternative implementations might use 32-bit integers, 128-bit integers, or variable-length integer encodings depending on the number of partners to be encoded and the capabilities of the underlying database system.

[0153] The identity resolution process may employ various matching algorithms and graph structures. While the description references a persistent identity graph with maintained identifiers, alternative implementations might use different graph architectures, real-time resolution approaches, or hybrid deterministic-probabilistic matching strategies.

[0154] The data ingestion mechanisms may be extended to support additional protocols and sources beyond SFTP, cloud storage, and browser uploads. For example, the system could support direct database connections, API-based data feeds, streaming data sources, or integration with data warehouses and data lakes.

[0155] The identity mapping index generation process may incorporate additional optimization techniques such as compression algorithms, columnar storage formats, or distributed computing frameworks to handle even larger datasets more efficiently.

[0156] The comparative analysis methodology may be extended to compare more than two scenarios. For example, the system could compare performance across derived-only, maintained-only, and derived-plus-maintained scenarios, or could compare performance with and without household-level clustering, or could demonstrate the incremental value of different graph enhancement techniques.

[0157] The statistical outputs may include additional metrics beyond those described, such as unique reach estimates, frequency distributions, audience composition analyses, or predictive modeling of campaign performance.

[0158] The system architecture may be deployed across different cloud platforms (AWS, Google Cloud, Azure, etc. ) or in hybrid cloud / on-premises configurations, with appropriate modifications to the specific storage, database, and pipeline components used.

[0159] The present invention provides numerous technical advantages over prior approaches to identity data matching and customer value analysis. First, the compressed identity mapping index structure dramatically reduces storage requirements compared to maintaining separate mapping tables for each partner. By encoding mapping relationships as binary flags within integers, the system achieves compression ratios of 10: 1 or better, enabling billions of mapping relationships to be stored in datasets measuring in gigabytes rather than terabytes.

[0160] Second, the identity mapping index structure enables extremely fast join operations. Because the index is stored in a single table with indexed source_id values, database engines can perform joins orders of magnitude faster than would be required to join against dozens or hundreds of separate partner mapping tables.

[0161] Third, the comparative analysis methodology provides objective, quantifiable metrics demonstrating identity resolution value. Rather than relying on estimates or industry averages, the system processes the customer's actual data and generates specific statistics showing performance with and without identity graph enhancement.

[0162] Fourth, the flexible ingestion framework accommodates diverse customer preferences and technical capabilities, reducing barriers to adoption. Customers can choose the ingestion method that best fits their existing infrastructure and security requirements.

[0163] Fifth, the automated data deletion mechanisms ensure compliance with privacy regulations and build customer trust by demonstrating that sensitive data is not retained beyond its necessary use.

[0164] Sixth, the system architecture supports high scalability and throughput, processing millions of records and generating comprehensive insights in minutes rather than hours or days.

[0165] Seventh, the expansion methodology for identity mapping indexes enables the system to demonstrate identity graph value even when source mapping files contain only maintained identifiers, by back-porting these mappings to associated derived identifiers.

[0166] Fig. 8 is a block diagram illustrating an example computer hardware system, according to various embodiments, that can be used as part of a multi-component system to implement the invention as has been described in a cloud-computing environment. Computer system 140 may implement a hardware portion of a cloud computing system as forming parts of the various implementations of the present invention.

[0167] Computer system 1140 may be any of various types of hardware devices, including, but not limited to, a commodity server, personal computer system, desktop computer, laptop or notebook computer, mainframe computer system, handheld computer, workstation, network computer, a consumer device, application server, physical storage device, telephone, mobile telephone, or in general any type of computing node, compute node, compute device, and / or hardware computing device.

[0168] Computer system 1140 includes one or more hardware processors 1140a, 1141b…1141n (any of which may include multiple processing cores, which may be single or multi-threaded) coupled to a physical system memory 1142 via an input / output (I / O) interface 1144. Computer system 1140 further may include a network interface 1146 coupled to I / O interface 1144.

[0169] In various embodiments, computer system 1140 may be a single processor system including one hardware processor 1141a, or a multiprocessor system including multiple hardware processors 1141a, 1141b…1141n. Processors 1141a, etc. may be any suitable processors capable of executing computing instructions. For example, in various embodiments, processors 1141a, etc. may be general-purpose or embedded processors implementing any of a variety of instruction set architectures.

[0170] In multiprocessor systems, each of processors 1141a, etc. may commonly, but not necessarily, implement the same instruction set. The computer system 1140 also includes one or more hardware network communication devices (e.g., network interface 1146) for communicating with other systems and / or components over a communications network, such as a local area network, wide area network, or the Internet. For example, a client application executing on system 1140 may use network interface 1146 to communicate with a server application executing on a single hardware server or on a cluster of hardware servers that implement one or more of the components of the systems described herein in a cloud computing environment as implemented in various sub-systems. In another example, an instance of a server application executing on computer system 140 may use network interface 1146 to communicate with other instances of an application that may be implemented on other computer systems.

[0171] In the illustrated embodiment, computer system 1140 also includes one or more physical persistent storage devices 1148 and / or one or more I / O devices 1150. In various embodiments, persistent storage devices 1148 may correspond to disk drives, tape drives, solid-state memory or drives, other mass storage devices, or any other persistent storage devices. Computer system 1140 (or a distributed application or operating system operating thereon) may store instructions and / or data in persistent storage devices 1148, as desired, and may retrieve the stored instructions and / or data as needed. For example, in some embodiments, computer system 1140 may implement one or more nodes of a control plane or control system, and persistent storage 1148 may include the solid-state drives (SSDs) attached to that server node. Multiple computer systems 1140 may share the same persistent storage devices 1148 or may share a pool of persistent storage devices, with the devices in the pool representing the same or different storage technologies, including such technologies as described above.

[0172] Computer system 1140 includes one or more physical system memories 1142 that may store code / instructions 1143 and data 1145 accessible by processor (s) 1141a, etc. The system memories 1142 may include multiple levels of memory and memory caches in a system designed to swap information in memories based on access speed, for example.

[0173] The interleaving and swapping may extend to persistent storage devices 1148 in a virtual memory implementation, where memory space is mapped onto the persistent storage devices 1148. The technologies used to implement the system memories 1142 may include, by way of example, static random-access memory (RAM) , dynamic RAM, read-only memory (ROM) , non-volatile memory, solid-state memory, or flash-type memory.

[0174] As with persistent storage devices 1148, multiple computer systems 1140 may share the same system memory systems 1142 or may share a pool of system memories 1142. System memory or memory systems 1142 may contain program instructions 1143 that are executable by processor (s) 1141a, etc. to implement the routines described herein.

[0175] In various embodiments, program instructions 1143 may be encoded in binary, Assembly language, any interpreted language such as Java, compiled languages such as C / C++, or in any combination thereof; the particular languages given here are only examples. In some embodiments, program instructions 1143 may implement multiple separate clients, server nodes, and / or other components.

[0176] In some implementations, program instructions 1143 may include instructions executable to implement an operating system (not shown) , which may be any of various operating systems, such as UNIX, LINUX, SolarisTM, MacOSTM, or Microsoft WindowsTM. Any or all of program instructions 1143 may be provided as a computer program product, or software, that may include a non-transitory computer-readable storage medium having stored thereon instructions, which may be used to program a computer system (or other electronic devices) to perform a process according to various implementations.

[0177] A non-transitory computer-readable storage medium may include any mechanism for storing information in a form (e.g., software or processing application) readable by a machine (e.g., a physical computer) . Generally speaking, a non-transitory computer-accessible medium may include computer-readable storage media or memory media such as magnetic or optical media, e.g., disk or DVD / CD-ROM, coupled to or in communication with computer system 1140 via I / O interface 1144.

[0178] A non-transitory computer-readable storage medium may also include any volatile or non-volatile media such as RAM or ROM that may be included in some embodiments of computer system 1140 as system memory 1142 or another type of memory. In other implementations, program instructions may be communicated using optical, acoustical or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc. ) conveyed via a communication medium such as a network and / or a wired or wireless link, such as may be implemented via network interface 1146. Network interface 1146 may be used to interface with other devices 1142, which may include other computer systems or any type of external electronic device.

[0179] In some embodiments, system memory 1142 may include data store 1145, as described herein. In general, system memory 1142 and persistent storage 1148 may be accessible on other devices 1142 through a network and may store data blocks, replicas of data blocks, metadata associated with data blocks, and / or their state, database configuration information, and / or any other information usable in implementing the routines described herein.

[0180] In one embodiment, I / O interface 1144 may coordinate I / O traffic between processors 1141a, etc., system memory 1142, and any peripheral devices in the system, including through network interface 1146 or other peripheral interfaces. In some embodiments, I / O interface 1144 may perform any necessary protocol, timing or other data transformations to convert data signals from one component (e.g., system memory 1142) into a format suitable for use by another component (e.g., processors 1141a, etc. ) .

[0181] In some embodiments, I / O interface 1144 may include support for devices attached through various types of peripheral buses, such as a variant of the Peripheral Component Interconnect (PCI) bus standard or the Universal Serial Bus (USB) standard, as examples. Also, in some embodiments, some or all of the functionality of I / O interface 1144, such as an interface to system memory 1142, may be incorporated directly into processor (s) 1141a, etc.

[0182] Network interface 1146 may allow data to be exchanged between computer system 1140 and other devices attached to a network, such as other computer systems (which may implement one or more storage system server nodes, primary nodes, read-only node nodes, and / or clients of the database systems described herein) , for example. In addition, I / O interface 1144 may allow communication between computer system 140 and various I / O devices 1150 and / or remote storage 1148.

[0183] Input / output devices 1150 may, in some embodiments, include one or more display terminals, keyboards, keypads, touchpads, scanning devices, voice or optical recognition devices, or any other devices suitable for entering or retrieving data by one or more computer systems 1140. These may connect directly to a particular computer system 1140 or generally connect to multiple computer systems 1140 in a cloud computing environment, grid computing environment, or other system involving multiple computer systems 1140.

[0184] Multiple input / output devices 1150 may be present in communication with computer system 1140 or may be distributed on various nodes of a distributed system that includes computer system 1140. In some embodiments, similar input / output devices may be separate from computer system 1140 and may interact with one or more nodes of a distributed system that includes computer system 1140 through a wired or wireless connection, such as over network interface 1146.

[0185] Network interface 1146 may commonly support one or more wireless networking protocols (e.g., Wi-Fi / IEEE 802.11, or another wireless networking standard) . Network interface 1146 may support communication via any suitable wired or wireless general data networks, such as other types of Ethernet networks, for example. Additionally, network interface 1146 may support communication via telecommunications / telephony networks such as analog voice networks or digital fiber communications networks, via storage area networks such as Fibre Channel SANs, or via any other suitable type of network and / or protocol. In various embodiments, computer system 1140 may include more, fewer, or different components (e.g., displays, video cards, audio cards, peripheral devices, or an Ethernet interface) .

[0186] Any of the distributed system embodiments described herein, or any of their components, may be implemented as one or more network-based services in the cloud computing environment. For example, a read-write node and / or read-only nodes within the database tier of a hardware database system may present database services and / or other types of physical data storage services that employ the distributed storage systems described herein to clients as network-based services.

[0187] In some embodiments, a network-based service may be implemented by a software and / or hardware system designed to support interoperable machine-to-machine interaction over a network. A web service may have an interface described in a machine-processable format. Other systems may interact with the network-based service in a manner prescribed by the description of the network-based service’s interface. For example, the network-based service may define various operations that other systems may invoke, and may define a particular application programming interface (API) to which other systems may be expected to conform when requesting the various operations.

[0188] In various embodiments, a network-based service may be requested or invoked through the use of a message that includes parameters and / or data associated with the network-based services request. Such a message may be formatted according to a particular markup language such as Extensible Markup Language (XML) , and / or may be encapsulated using a protocol. To perform a network-based services request, a network-based services client may assemble a message including the request and convey the message to an addressable endpoint (e.g., a Uniform Resource Locator (URL) ) corresponding to the web service, using an Internet-based application layer transfer protocol such as Hypertext Transfer Protocol (HTTP) .

[0189] Unless otherwise stated, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs.

[0190] Although any methods and materials similar or equivalent to those described herein can also be used in the practice or testing of the present invention, a limited number of the 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 concepts herein.

[0191] All terms used herein should be interpreted in the broadest possible manner consistent with the context.

[0192] When a grouping is used herein, all individual members of the group and all combinations and sub-combinations possible of the group are intended to be individually included.

[0193] When a range is stated herein, the range is intended to include all sub-ranges within the range, as well as all individual points within the range.

[0194] When “about, ” “approximately, ” or like terms are used herein, they are intended to include amounts, measurements, or the like that do not depart significantly from the expressly stated amount, measurement, or the like, such that the stated purpose of the apparatus or process is not lost.

[0195] All references cited herein are hereby incorporated by reference to the extent that there is no inconsistency with the disclosure of this specification.

[0196] The present invention has been described with reference to certain preferred and alternative embodiments that are intended to be exemplary only and not limiting to the full scope of the present invention, as set forth in the appended claims.

Claims

1.A system for efficient identity data matching and statistical analysis, comprising:a data ingestion module configured to receive customer data containing a plurality of customer identifiers;an identity resolution engine configured to process the customer data and generate resolved identifier data, wherein the resolved identifier data includes:a first set of derived identifiers generated directly from the customer identifiers, and a second set of maintained identifiers representing entities within a persistent identity graph;a data storage system storing at least one compressed identity mapping index, wherein the compressed identity mapping index comprises:a plurality of rows, each row corresponding to a source identifier,a plurality of columns corresponding to partner groups, andinteger values in cells of the index, wherein each integer value encodes, in binary form, the presence or absence of mapping relationships between the source identifier and multiple partners within the corresponding partner group;a matching engine configured to:perform a first matching operation by joining the first set of derived identifiers against the compressed identity mapping index to generate first match statistics, andperform a second matching operation by joining both the first set of derived identifiers and the second set of maintained identifiers against the compressed identity mapping index to generate second match statistics; anda statistics generation module configured to calculate comparative metrics by comparing the first match statistics with the second match statistics, wherein the comparative metrics quantify performance differences between the first matching operation and the second matching operation.2.The system of claim 1, wherein the data ingestion module supports multiple data transfer protocols including SFTP connections, cloud storage transfers, and browser-based file uploads.3.The system of claim 1, wherein the identity resolution engine comprises a database stored procedure configured to process customer identifiers through resolution logic that references the persistent identity graph.4.The system of claim 1, wherein each integer value in the compressed identity mapping index represents multiple binary flags, each binary flag indicating whether a mapping relationship exists between the source identifier and a specific partner.5.The system of claim 1, further comprising an index expansion module configured to:receive an identifier relationship table indicating associations between derived identifiers and maintained identifiers; andgenerate an expanded compressed identity mapping index by duplicating rows corresponding to maintained identifiers and associating the duplicated rows with corresponding derived identifiers.6.The system of claim 5, wherein the identifier relationship table comprises mappings between authenticated resolved links (ARLs) and pseudonymous entity links (PELs) .7.The system of claim 1, wherein the comparative metrics include at least one of: a percentage point increase in match rate, a multiplier indicating relative performance improvement, and a lift value.8.The system of claim 1, further comprising a data deletion module configured to automatically delete the customer data and any associated credentials after the comparative metrics have been generated.9.The system of claim 1, wherein the compressed identity mapping index is partitioned into multiple partner group columns to optimize join performance in a distributed database system.10.The system of claim 1, wherein the system generates separate compressed identity mapping indexes for different universes, each universe representing a cohesive group of mapping files based on a common source identifier type.11.A method for efficient identity data matching and statistical analysis, comprising:receiving customer data containing a plurality of customer identifiers;performing identity resolution on the customer data to generate:a first identifier column containing only derived identifiers generated directly from the customer identifiers, anda second identifier column containing both derived identifiers and maintained identifiers representing entities within a persistent identity graph;accessing a compressed identity mapping index stored in a database, wherein the compressed identity mapping index encodes mapping relationships between source identifiers and multiple partners using binary-encoded integer values;performing a first join operation between the first identifier column and the compressed identity mapping index to generate first match results;performing a second join operation between the second identifier column and the compressed identity mapping index to generate second match results;calculating comparative statistics by comparing the first match results with the second match results; andgenerating a report presenting the comparative statistics, wherein the comparative statistics quantify performance improvement attributable to the maintained identifiers.12.The method of claim 11, wherein the compressed identity mapping index is generated by:receiving a plurality of mapping files, each mapping file associating source identifiers with target identifiers for a specific partner;identifying all unique source identifiers across the plurality of mapping files;for each unique source identifier, determining which partners have mapping relationships with that source identifier;encoding the presence or absence of mapping relationships as binary values; andconverting the binary values to integer values for storage in the compressed identity mapping index.13.The method of claim 11, further comprising the step of, prior to performing the first join operation and the second join operation, expanding the compressed identity mapping index by:receiving an identifier relationship table indicating associations between derived identifiers and maintained identifiers;identifying rows in the compressed identity mapping index corresponding to maintained identifiers; andduplicating those rows and associating the duplicated rows with corresponding derived identifiers.14.The method of claim 11, wherein the first match results represent performance achievable using deterministic identifier matching, and the second match results represent performance achievable using identity graph-based resolution.15.The method of claim 11, further comprising the steps of:calculating an overall match count indicating how many customer identifiers matched at least one partner;calculating per-partner match counts indicating how many customer identifiers matched each specific partner; andcalculating overlap metrics indicating how many customer identifiers matched multiple partners.16.The method of claim 11, further comprising automatically deleting the customer data from all system components after generating the report.17.The method of claim 11, wherein receiving customer data comprises:receiving authentication credentials for a customer-controlled data source;establishing a secure connection to the customer-controlled data source using the authentication credentials;retrieving data files from the customer-controlled data source; andstoring the retrieved data files in a staging area for processing.18.The method of claim 11, wherein the compressed identity mapping index includes multiple partner group columns, and each integer value in a partner group column encodes mapping relationships for multiple partners within that partner group.19.A compressed identity mapping index data structure stored in non-transitory computer-readable memory, comprising a table with a plurality of rows and a plurality of columns, wherein:each row corresponds to a unique source identifier;each column corresponds to a partner group containing multiple partners;each cell contains an integer value representing, in binary form, a plurality of binary flags indicating whether the source identifier has mapping relationships with each partner in the corresponding partner group; andthe data structure consolidates mapping relationships from multiple separate mapping files into a single unified structure that enables efficient join operations for determining data overlap statistics.20.The compressed identity mapping index data structure of claim 19, wherein the data structure further includes metadata mapping each partner to a specific partner group column and a specific bit position within integer values in that column, thereby enabling decoding of the binary-encoded integer values to determine which partners have mapping relationships with any given source identifier.

Images