Customer Data Enrichment

Customer data enrichment adds useful information to an existing customer record from an authorised source. Start with two supplied datasets, match stable customer identifiers, and review conflicting values before accepting a combined record.

This guide covers reconciliation of information you already have permission to use. It does not scrape contacts, purchase data or infer missing customer facts with a model.

By Ai Flowi · Published 10 October 2026

example configuration, not a recorded test
documented in the catalogue; not production-tested by Ai Flowi

1. Define what information may be added

Choose a base dataset and a reference dataset. The base establishes which customer records belong in the output; the reference supplies approved additional fields. Define the purpose of each addition, such as adding an agreed account category or a known onboarding status. More fields are not automatically more useful.

Write field-level rules before joining. For each field, identify its authoritative source, whether an empty reference value may replace a populated base value, and what should happen when sources disagree. Preserve both original values for contested fields. A merge operation is not a business decision about which value is correct.

2. Establish matching keys and source permissions

You need both authorised exports, a workspace and a documented customer identifier shared by the sources. No model account is required for the proposed deterministic reconciliation. If either dataset comes from Google Sheets, read the authorised range using a separately tested connection; third-party service usage is outside the subscription and the provider is billed separately where applicable.

Use a stable identifier rather than a customer name as the join key. Names can be shared or changed, and matching similar names can attach another customer’s information. Define case and whitespace behavior deliberately. Preserve leading zeros and reject blank keys rather than treating all missing identifiers as one customer.

Confirm that using the reference information for this enrichment purpose is authorised. Retain a source identifier and snapshot reference for both exports. If permission or source ownership is unclear, keep the affected rows out of the accepted merge and record the gap for review.

3. Validate each dataset before conversion

Configure separate Load CSV components with csv_file for the base export and the reference export. Inspect each JSON data_list before transformation. Keep the two populations distinct so errors in the reference dataset do not silently remove base records.

Use separate JSON Operations steps with data, operations set to "JQ Expression", and checked query values for the respective contracts. Validate key types, required headers and duplicate identifiers. Prepare exceptions for blank keys, invalid field types and contradictory duplicate rows.

For this design, require one accepted row per customer identifier in each input. A repeated key needs an explicit reconciliation decision before the join. Do not apply "Drop Duplicates" merely to hide the problem: repeated observations can carry different values, and the catalogue does not establish a field-authority policy for deciding between them.

Prepare distinct source-prefixed column names for fields that can conflict, while keeping the join key named consistently. This avoids relying on an assumed collision suffix from the runtime. The resulting table should make each value’s origin visible before you derive an accepted field.

4. Perform a bounded customer record join

Use the Data → DataFrame conversion reference for the two validated sources before inspecting their Table columns.

In a synthetic reconciliation, the base record for customer key 001A contains an agreed account category, while the reference contains an empty category and an onboarding status. A field policy can keep the populated base category and add the authorised status, retaining each source reference. A reference row keyed 1A must stay unmatched unless your identity contract explicitly establishes equivalence. Removing leading zeros to improve the apparent match rate would change identity rather than enrich the record, and could attach a different customer’s status.

Use Table Operations with operation set to "Merge". Set left_dataframe to the base Table, right_dataframe to the reference Table, merge_on_column to your validated customer key and merge_how to "left". Its required df should also be supplied with the base Table; confirm the selected operation’s behavior in your workspace.

A left-join policy is intended to preserve the accepted base population while adding reference columns when a key matches. Inspect unmatched base records and reference-only records separately. Duplicate keys can multiply joined rows, so reconcile input uniqueness and output cardinality before accepting the result.

5. Apply field precedence without hiding conflicts

For a reviewable first configuration, display the merged Table in Chat Output and let the responsible data steward apply the written field policy. Keep base and reference values visible. The decision can accept a reference value, retain the base value or leave the field unresolved, with a reason and source reference.

If you later automate precedence, convert the inspected Table through Type Convert.input_data with output_type set to "JSON". Inspect its data_output shape before configuring JSON Operations.query for the field policy. This is a proposed extension, not an assertion that conversion produces a specific record-list envelope.

Google Sheets data reconciliation should distinguish source freshness from authority. A newer timestamp is not always the correct precedence rule: one source may be a confirmed account record while another is an unreviewed submission. Use the policy you can justify for that field, and preserve the losing value when it matters to an audit.

6. Inspect enriched records and exceptions

The intended output includes the customer key, original source values, accepted enriched fields, match status, conflict status, source snapshots and review decisions. Missing reference information should stay missing. An unresolved field should not look like an accepted blank or a model-filled value.

Reconcile the accepted base customer count to the output membership, then inspect every unmatched and conflicted row. Test a blank key, leading-zero identifier, case difference, duplicate reference key, empty reference value and contradictory field. Acceptance requires no unexplained row multiplication and no cross-customer attachment.

The existing lead cleaning recipe reports passed all 32 cases in its supplied test scope. It normalises and validates fields within one request. Those results do not test a two-source join, authority policy or conflict resolution, so retain the original recipe’s setup on its linked page.

When should customer data enrichment stop?

This proposal has no scraping service, identity verification or external data purchase. It cannot establish that two similar names refer to one person or repair an unreliable customer key. Stop when the match policy cannot distinguish records safely, or when field ownership and permitted use are unresolved.

Do not write the merged output back to an authoritative system until the data steward approves the field policy and tests a separate write process. If both sources already live in one system with a reliable native join, that feature may cover the task. After reconciliation, segmentation can use approved attributes, while qualification still requires its own buying evidence.

Catalogue settings for this design

Usage for customer data enrichment

Plans: Go from USD8/month billed yearly (USD10 monthly), Plus from USD16 (USD20 monthly), Pro 100 from USD80 (USD100 monthly), Pro 200 from USD160 (USD200 monthly) and Pro 500 from USD400 (USD500 monthly), with 5,000 to 250,000 Flowi Tokens/month and top-ups; 1 token per node run; third-party API and model usage is not included.

Related reading for customer data enrichment

• Lead cleaning recipe
• Component catalogue
• Documented use cases
• AI Customer Segmentation
• AI Lead Qualification