Membangun Master Data Management (MDM) Otomatis dengan n8n + AI: Entity Resolution, Match‑Merge, dan Survivorship Rules

2026-04-23 · 9 menit baca

Membangun Master Data Management (MDM) Otomatis dengan n8n + AI: Entity Resolution, Match‑Merge, dan Survivorship Rules

Data pelanggan, produk, dan pemasok tersebar di banyak sistem—CRM, e-commerce, dukungan pelanggan, invoice, gudang, bahkan spreadsheet tim. Tanpa Master Data Management (MDM), Anda menghadapi duplikasi, data konflik, dan laporan yang tidak konsisten. Kabar baiknya, n8n + AI memungkinkan Anda membangun pipeline MDM otomatis yang mampu melakukan entity resolution, match‑merge, dan survivorship untuk menghasilkan golden record yang akurat—dengan audit, kontrol biaya, dan kepatuhan UU PDP.

Mengapa MDM Penting (dan Mengapa Sekarang)

Satu sumber kebenaran (single source of truth): konsolidasikan ID dan atribut lintas sistem agar analitik, personalisasi, dan operasional konsisten.
Skala dan otomatis: AI membantu mencocokkan entitas yang rumit (nama mirip, alamat tidak baku) sehingga tim tidak kewalahan review manual.
Kecepatan bisnis: golden record yang selalu terbarui mempercepat kampanye, penjualan, dan dukungan pelanggan.
Kepatuhan & keamanan: MDM memudahkan right to rectification, right to be forgotten, dan audit trail sesuai UU PDP.

Konsep Inti: Entity, Golden Record, Match‑Merge, Survivorship

Domain master: Customer, Product, Supplier, Karyawan, dll.
Golden record: representasi final, paling tepercaya dari satu entitas (mis. satu pelanggan) yang disusun dari banyak sumber.
Entity resolution: proses menemukan catatan yang sebenarnya merujuk ke entitas yang sama (deduplikasi dan penggabungan).
Match‑merge: aturan untuk memutuskan kapan dua catatan adalah match (threshold, model AI) dan bagaimana menggabungkan atributnya.
Survivorship rules: logika pemilihan nilai per-atribut (berdasarkan sumber, recency, kelengkapan, skor kualitas).

Arsitektur Referensi MDM Otomatis dengan n8n + AI

Gambaran komponen yang dapat Anda rakit dengan n8n:

Ingestor multi-sumber: Database (MySQL/Postgres), API CRM/e-commerce, Google Sheets, CSV/Excel.
Standarisasi & pembersihan: normalisasi nama, telepon Indonesia (+62), email, alamat (provinsi, kota, kode pos).
Kandidat & blokir (blocking): pembuatan blocking key agar pencarian kandidat efisien (nama+email domain+4 digit akhir telepon).
Similarity scoring: gabungan rule‑based (Jaro‑Winkler/Levenshtein), fingerprint, dan AI embeddings untuk teks.
Model klasifikasi match: rule + model ML/LLM untuk memprediksi probabilitas “same entity”.
Clustering: kelompokkan catatan yang saling terhubung (graf komponen terhubung) menjadi satu entitas.
Survivorship & golden record: pilih nilai terbaik per-atribut, buat ID master, dan persist ke tabel master.
Publikasi & sinkronisasi: tulis kembali ke sumber (opsional), API untuk layanan lain, dan cache.
Audit & observability: jejak keputusan, skor, versi aturan; human-in-the-loop untuk case rendah keyakinan.

Langkah Implementasi di n8n (End‑to‑End)

1) Ingest Data dari Banyak Sumber

Gunakan node Cron untuk penjadwalan, lalu HTTP Request (API CRM/e-commerce), Google Sheets / CSV, atau MySQL/Postgres untuk menarik data. Pastikan setiap record menyertakan source_id dan source_system.

2) Normalisasi & Pembersihan Data

Di Function node, lakukan standardization konsisten—terutama untuk konteks Indonesia:

Telepon: konversi 08… → +62…, buang spasi/tanda baca, validasi panjang.
Nama: trim, huruf kecil/kapital konsisten, hapus karakter ganda, bentuk fingerprint.
Alamat: pecah jadi jalan, kelurahan, kecamatan, kota/kab, provinsi, kode pos; normalisasi singkatan (Jl. → Jalan, Kb. → Kebon).
Email: lowercase, split local dan domain; domain membantu blocking.
Identifier lokal: jika tersedia NPWP/KTP, hash/salt untuk keamanan, simpan hanya fingerprint cocok untuk pencocokan.

// Function node (JavaScript) contoh normalisasi nomor HP Indonesia
function normalizePhone(idPhone) {
  if (!idPhone) return '';
  let s = String(idPhone).replace(/[^0-9+]/g, '');
  if (s.startsWith('+')) return s;
  if (s.startsWith('62')) return '+' + s;
  if (s.startsWith('0')) return '+62' + s.slice(1);
  return '+62' + s; // fallback
}

function fingerprintName(name) {
  if (!name) return '';
  return name
    .toLowerCase()
    .normalize('NFKD')
    .replace(/[\u0300-\u036f]/g, '') // hapus diakritik
    .replace(/[^a-z\s]/g, ' ')
    .replace(/\s+/g, ' ')
    .trim();
}

items.forEach(item => {
  const n = item.json;
  n.phone_norm = normalizePhone(n.phone);
  n.name_fp = fingerprintName(n.name);
  n.email_lc = (n.email || '').toLowerCase().trim();
  n.email_domain = n.email_lc.split('@')[1] || '';
  n.block_key = `${(n.name_fp||'').slice(0,4)}_${(n.email_domain||'').slice(0,6)}_${(n.phone_norm||'').slice(-4)}`;
});
return items;

3) Candidate Generation dengan Blocking + Embeddings

Blocking mempersempit pasangan kandidat sehingga komputasi efisien. Simpan indeks block_key dan cari kandidat dalam blok yang sama. Untuk teks panjang (alamat), gunakan embeddings (OpenAI/Hugging Face, atau model lokal) dan vector search pada kolom alamat.

Opsi vektor: Postgres + pgvector, Qdrant, Weaviate, atau Pinecone; n8n menghubungkan via HTTP Request atau Database.
Cache embeddings: simpan hash alamat → vektor untuk menghemat biaya dan latency.

4) Similarity Scoring (Rule + AI)

Hitung skor gabungan dari berbagai sinyal, misalnya:

Nama: Jaro‑Winkler/Levenshtein atas fingerprint nama.
Email: exact match domain + local part mirip.
Telepon: exact match setelah normalisasi.
Alamat: cosine similarity embeddings + token match kecamatan/kota/kode pos.
Identifier: fingerprint NPWP/KTP sama → skor tinggi.

Gabungkan dengan bobot yang bisa dikonfigurasi, lalu gunakan LLM/ML classifier pada kandidat meragukan (skor menengah) untuk memutuskan match atau non‑match. Simpan juga confidence dan reason dari model untuk audit, tanpa membocorkan data sensitif.

5) Clustering dan Graph Merge

Setelah pasangan match ditemukan, bentuk graf (node=catatan, edge=match) dan ambil connected components. Setiap komponen = satu entitas. Di n8n, ini dapat dilakukan di Function node dengan algoritma union‑find sederhana.

6) Survivorship Rules (Field‑Level)

Terapkan kebijakan pemilihan nilai terbaik per-atribut. Contoh:

Source priority: ERP > CRM > Form Web > Enrichment pihak ketiga.
Recency: pilih nilai dengan timestamp terbaru.
Completeness & validity: alamat dengan kode pos valid, telepon terverifikasi.
AI assist (opsional): menyatukan format alamat/gelar nama, mengisi tipe industri dari deskripsi, dsb.

// Contoh kebijakan survivorship sederhana (JSON) yang dibaca Function node
const policy = {
  fieldRules: {
    name: { priority: ['ERP','CRM','WEB'], fallback: 'longest' },
    phone: { priority: ['CRM','ERP'], validation: 'e164' },
    email: { priority: ['WEB','CRM'], unique: true },
    address: { recency: true, quality: ['has_postal_code','district_match'] },
    industry: { ai_enrich_if_missing: true }
  },
  sourceTrust: { ERP: 1.0, CRM: 0.9, WEB: 0.7, THIRD_PARTY: 0.6 }
};

Dengan kebijakan seperti ini, golden record dibentuk deterministik dan bisa diaudit ulang ketika kebijakan berubah.

7) Persist Golden Record & Publikasi

Buat tabel master_customer / master_product di Postgres/MySQL berisi master_id, atribut golden, serta map ke source_system + source_id. Publikasikan melalui node Webhook n8n atau Database, dan sinkronkan ke downstream (marketing, BI, support).

8) Human‑in‑the‑Loop, QA & Audit

Low confidence queue: kirim kandidat ambigu ke Slack / Notion / Airtable via n8n untuk review manual, lalu update keputusan kembali ke workflow.
Audit trail: simpan skor, alasan, dan aturan yang digunakan pada setiap keputusan match‑merge.
Rollback & reprocessing: jika kebijakan berubah, re-run hanya cluster terdampak (pakai blocking key dan timestamp).

Contoh Workflow n8n (Customer 360 Indonesia)

Cron: nightly run.
Ingest: ambil data pelanggan dari CRM (HTTP), order dari e-commerce (DB), tiket dari helpdesk (HTTP), sheet offline (Google Sheets).
Normalize (Function): telepon → E.164 +62, nama fingerprint, alamat pecah + normalisasi singkatan Indonesia.
Generate Embeddings (OpenAI/HF): bidang alamat; cache hash → vektor.
Candidate Search: query blok basis block_key + vektor alamat di pgvector/Qdrant.
Score (Function): hitung composite score (nama/email/telepon/alamat/ID).
LLM Classify (opsional): hanya untuk skor borderline; output match/non‑match + confidence.
Cluster (Function): union‑find → komponen terhubung = entitas.
Survivorship (Function): terapkan policy per‑field, bentuk golden record.
Upsert (Database): tulis ke master_customer + tabel master_link (map ke sumber).
Publish: Webhook / queue / DB view untuk sistem downstream.
HITL: kirim kasus low‑confidence ke Slack/Notion untuk triase manual.
Metrics: kirim metrik ke Grafana/Prometheus (jumlah match, precision sampel, waktu proses, biaya embedding).

Strategi Scoring yang Andal (dengan Contoh)

Misal komponen skor (0–1):

Nama: 0.35 (Jaro‑Winkler pada fingerprint)
Email: 0.25 (domain exact, local ≥ 0.8)
Telepon: 0.25 (exact setelah normalisasi)
Alamat: 0.15 (cosine sim embeddings + kecamatan/kode pos match)

Composite = Σ(w_i × score_i). Threshold: ≥0.85 = otomatis match, ≤0.6 = non‑match, di antara keduanya → LLM/ML + antrian review.

Performa, Biaya, dan Skalabilitas

Blocking agresif: kurangi pasangan kandidat. Pertimbangkan beberapa kunci (nama+domain, telepon+kode pos) untuk cakupan lebih luas.
Incremental updates: proses hanya perubahan (CDC) dan pasangan baru; simpan signature per record.
Cache embeddings & batching: kumpulkan 100–500 alamat untuk sekali panggilan model; gunakan model lokal bila perlu.
Parallelism n8n: pecah pipeline jadi sub‑workflow; gunakan queue untuk beban tinggi.
Idempotensi: beri dedupe_key per pasangan; hindari duplikasi edge pada retry.

Keamanan & Kepatuhan UU PDP

Minimisasi data: kirim ke model hanya token yang diperlukan (jangan kirim KTP/NPWP mentah).
Pseudonimisasi: hash/salt untuk identifier; enkripsi at‑rest & in‑transit.
Data residency: gunakan model lokal/on‑prem untuk bidang sensitif; audit akses model.
Hapus data: implement right to be forgotten dengan menandai dan membersihkan cluster terkait.
Audit trail: simpan alasan/aturan tiap keputusan match‑merge untuk pemeriksaan.

Evaluasi Kualitas: Jangan Hanya Andalkan “Rasa”

Pair‑level: precision/recall F1 untuk keputusan match.
Cluster‑level: over‑merge dan under‑merge rate.
Field accuracy: persentase survivorship benar per atribut.
Sampling berkala: 1–5% pasangan borderline direview manusia untuk kalibrasi threshold.
Drift monitoring: pantau distribusi skor; jika bergeser, tinjau ulang bobot dan blocking.

Contoh Skema Tabel Master & Link

-- master entitas
CREATE TABLE master_customer (
  master_id UUID PRIMARY KEY,
  name TEXT, email TEXT, phone TEXT,
  address TEXT, province TEXT, city TEXT, postal_code TEXT,
  industry TEXT,
  quality_score NUMERIC,
  updated_at TIMESTAMP DEFAULT now()
);

-- relasi ke sumber
CREATE TABLE master_link (
  master_id UUID REFERENCES master_customer(master_id),
  source_system TEXT,  -- CRM, ERP, WEB, etc.
  source_id TEXT,
  created_at TIMESTAMP DEFAULT now(),
  PRIMARY KEY (source_system, source_id)
);

Human‑in‑the‑Loop: Desain Review yang Nyaman

Ringkasan kontras: tampilkan perbedaan kunci (telepon, email, kecamatan, kode pos) agar reviewer cepat memutuskan.
Satu klik: tombol Approve/Reject dari Slack/Notion/Airtable, n8n menangkap webhook untuk menutup kasus.
Pembelajaran berkelanjutan: gunakan hasil review untuk re‑train model/bobot.

Template Aturan yang Siap Dipakai

Mulai dari aturan dasar, perkuat bertahap:

Fase 1 (rule‑first): exact email OR exact phone → match; nama Jaro‑Winkler ≥0.92 & alamat kecamatan sama → match.
Fase 2 (hybrid): tambah embeddings alamat; LLM untuk borderline.
Fase 3 (ml‑first): train classifier (XGBoost/LightGBM) atas fitur jarak; LLM hanya untuk alasan & HITL.

Praktik Terbaik agar MDM Anda Tahan Lama

Konfigurasi, bukan kode: simpan bobot, threshold, dan prioritas sumber sebagai konfigurasi (JSON/DB) sehingga mudah diubah tanpa redeploy.
Versi kebijakan: beri policy_version pada setiap golden record; ketika versi naik, reprocess terkontrol.
Observability: log waktu proses per tahap, biaya per 1.000 record, dan esktrapolasi kapasitas.
Data lineage: simpan asal nilai per‑field (dari sumber mana, kapan) untuk kejelasan dan audit.
Fail‑safe: jika model tidak tersedia, fallback ke rule‑based; jangan hentikan pipeline bisnis kritis.

Studi Kasus Singkat: Retail Omnichannel Indonesia

Retailer menggabungkan pelanggan dari POS toko fisik, e-commerce, dan pusat layanan. Dengan n8n + AI:

Duplikasi pelanggan turun 73% dalam 6 minggu.
Open rate email naik 18% berkat kontak unik dan alamat valid.
CSAT meningkat karena agen melihat riwayat menyatu pada layar tunggal.

Checklist Implementasi

Definisikan domain master dan atribut wajib.
Tentukan sumber, prioritas, dan SLA refresh.
Rancang blocking keys dan fitur similarity.
Siapkan vector store + cache embeddings.
Bangun scoring + threshold + LLM fallback.
Implement union‑find clustering.
Susun survivorship policy per‑field.
Implement HITL dan audit trail.
Uji kualitas (pair/cluster/field), kalibrasi, dan monitor drift.
Otomasi publikasi ke downstream dan dokumentasi data lineage.

Penutup

MDM modern tidak harus mahal dan rumit. Dengan n8n + AI, Anda bisa merakit pipeline entity resolution, match‑merge, dan survivorship yang tangguh, diawasi, dan hemat biaya—disesuaikan dengan kebutuhan Indonesia. Mulai dari aturan sederhana, tambahkan AI di titik bernilai tinggi, dan sertakan manusia pada kasus ambigu. Dalam hitungan minggu, Anda dapat memiliki golden record yang mendorong keputusan lebih cepat, pelanggan lebih puas, dan tim lebih produktif.

Membangun Master Data Management (MDM) Otomatis dengan n8n + AI: Entity Resolution, Match‑Merge, dan Survivorship Rules