Term Matcher Overview Examples

🧠 Matching Algorithm Comparison

This section demonstrates how different approximate matching algorithms behave under various input conditions.

• Levenshtein handles typical typos and character edits.

• Positional is strict and best for fixed-format codes (e.g., IDs like "AB-1234").

• LCS (Longest Common Subsequence) tolerates gaps and partial overlaps.

Use this to choose the most appropriate algorithm for your use case.

🔐 Safe Aggregation

You can use this node to clean your data before aggregation.

🤗 Safe Joining

You can use this node to join uncleaned data safely.

🔍 Fault-Tolerant Search

One key use case of the Approximate Matcher node is enabling fault-tolerant search.
It allows users to retrieve relevant matches even when data contains typos, inconsistent casing, or partial strings—common issues in real-world datasets like customer names, cities, or product IDs.

This makes it ideal for:

• Dirty or user-entered text fields

• Matching records from different systems

• Building robust search features in data pipelines

Use this node to avoid missing matches due to small differences in spelling or formatting.

This use case demonstrates how the Approximate String Matcher node can be used to detect potential errors or rare entries by matching the least frequent values against the most frequent ones in the same dataset.

Using approximate string matching (e.g., Levenshtein distance), we can distinguish:

• Likely typos — low-frequency entries that closely resemble high-frequency ones

• Rare but valid values — dissimilar entries that are truly unique

• Correct entries — high-frequency values, often assumed correct

This makes it ideal for:

• Detecting entry errors in location, product, or customer data

• Auto-flagging suspicious or rare strings for review

• Improving data quality in human-entered datasets

🧠 Frequency-Aware Anomaly Detection

✅ Variation Lookup Using Approximate Matching

This example demonstrates how to use the Approximate String Matcher node to return all similar values to a given input string (e.g., "Munich"), allowing users to find spelling variations or typos in the dataset.

The node is configured in Row Filter Mode, where:

• The search phrase is passed from a Table Creator

• The dataset contains values with potential spelling errors

• A Levenshtein edit distance threshold controls how tolerant the match is

🔍 Performs approximate matching between the search phrase and city names in the dataset.

• Set to Row Filter Mode: outputs only matching rows

• Match method: Levenshtein

• Threshold: e.g., max 5 edit operations