Webhook přilepí lead na cizí kontakt podle křestního jména

import { Aside } from ‘@astrojs/starlight/components’;

Při deduplikaci kontaktů nikdy nematchuj na **neúplném identifikátoru** (jen křestní jméno). Z neúplných dat raději **založ nový záznam**, než ho přilepit na špatný. Příchozí lead se musí vytvořit **vždy** — i z holého telefonu nebo holého e-mailu.

Symptom

Klient hlásí: „nechodí nám všechny leady”. Část leadů z reklamní kampaně (Meta Lead Ads → Zapier → CRM) v systému chybí, ačkoli webhook je prokazatelně přijal (v logu je Přijatá data pro každý z nich) a nevyhodil žádnou chybu — tj. žádný 500, žádný retry, lead prostě „zmizel”.

Root cause

Webhook hledal existujícího klienta v pořadí e-mail → telefon → jméno. Fallback podle jména matchoval i tehdy, když přišlo jen křestní jméno (Meta Lead Ads často pošle jen „Lukáš”, „Martin”, „Katka” bez příjmení):

// ŠPATNĚ — match i při prázdném příjmení
if (!client && firstName) {
  client = await prisma.client.findFirst({
    where: { firstName: { equals: firstName, mode: "insensitive" } },
  });
}

Nový lead „Lukáš” se tak přilepil na náhodného existujícího klienta se stejným křestním jménem. Reálný e-mail a telefon nového leadu se přitom neuložily, protože „enrich” doplňuje jen prázdná pole existujícího klienta — a ten už e-mail/telefon měl (jiné). Kontakt se efektivně ztratil: lead visel pod cizím klientem a dohledat ho nešlo.

Fix

Match podle jména jen když máme jméno I příjmení; jinak založit nového klienta. A vytvoření leadu odolné vůči chybám doplňků (note nesmí shodit hlavní zápis):

// SPRÁVNĚ — jen plné jméno
if (!client && firstName && lastName) {
  client = await prisma.client.findFirst({
    where: {
      firstName: { equals: firstName, mode: "insensitive" },
      lastName:  { equals: lastName,  mode: "insensitive" },
    },
  });
}
// ...pokud klient není, založ nového z jakýchkoliv dat (i jen telefon / jen e-mail / bez jména)

Doplňkové operace (vytvoření poznámky, dohledání autora) zabaleny do try/catch s fallbackem, aby nikdy neshodily vytvoření samotného leadu.

Jak se tomu vyvarovat v jiných systémech

• Detection: projdi dedup logiku webhooků — na čem reálně matchuje? Grepuj findFirst / findUnique u import/webhook cest a ověř, že klíč je unikátní identifikátor (e-mail, telefon, IČO), ne jméno.
• Anti-pattern: match na poli, které není unikátní (křestní jméno, město), + „enrich plní jen prázdná pole” → tichá ztráta dat.
• Lepší přístup: (1) lead/záznam z webhooku vytvoř vždy, i z neúplných dat — radši duplicita než ztráta; (2) merge/dedup řeš odděleně a auditovatelně; (3) webhook, který přijímá data od třetí strany, musí počítat s tím, že pole budou chybět — „chodí to jak může”.

Sister bugs / související

• E-mail helper tiše zahodí přílohy — podobně tichá ztráta na happy-path-only kódu.
• git clean smaže neverzované uploady — jiný typ tiché ztráty dat.