Integrace CRM a e-shopu: data, synchronizace a GDPR
CRM bez dat z e-shopu je jen adresář. Ukazujeme, která data mají téct oběma směry, jak nezdvojit zákazníky, jak přenášet souhlasy s obchodními sděleními a na jaké limity API narazíte u HubSpotu, Pipedrivu a Raynetu.
E-shop ví, co zákazník koupil. CRM ví, s kým obchodník mluvil, jakou nabídku poslal a co zákazník reklamoval. Dokud o sobě tyhle dva systémy nevědí, obchodník volá zákazníkovi, který včera objednal za 80 000 Kč, a nabízí mu slevu pro nové zákazníky. Marketing posílá kampaň lidem, kteří odběr zrušili.
Integrace CRM a e-shopu to řeší. Zní to jako jednoduché „přeposílání kontaktů“, ale v praxi rozhoduje o úspěchu pět věcí: která data posílat, kterým směrem, jak zacházet se souhlasy, jak nezdvojit zákazníky a jak nenarazit na limity API. Projdeme je jednu po druhé.
Jaká data mezi CRM a e-shopem tečou
Neposílejte všechno. Každé pole navíc je místo, kde se může něco rozbít, a u osobních údajů i otázka, jestli je v CRM vůbec potřebujete.
| Data | Směr | K čemu je CRM potřebuje |
|---|---|---|
| Kontakt (jméno, e-mail, telefon) | e-shop → CRM | základ záznamu zákazníka |
| Firma, IČO, DIČ (B2B) | oba směry | párování firem, fakturační údaje |
| Objednávka: číslo, datum, částka, stav | e-shop → CRM | historie nákupů, obchodní příležitosti |
| Souhrny: celková útrata, počet objednávek, poslední nákup | e-shop → CRM | segmentace, prioritizace obchodníků |
| Souhlasy s obchodními sděleními | oba směry | kdo smí dostávat kampaně |
| Individuální ceník, sleva, splatnost (B2B) | CRM → e-shop | obchodník domluví podmínky, e-shop je uplatní |
| Stav reklamace nebo tiketu | podle toho, kde vzniká | kompletní obraz zákazníka |
Položky objednávek (konkrétní produkty) posíláme do CRM jen tehdy, když s nimi někdo pracuje, třeba pro kampaně na doplnění spotřebního zboží. Jinak stačí součty.
Jednosměrně, nebo obousměrně
Jednosměrná synchronizace (e-shop → CRM) je jednodušší a u B2C často stačí. E-shop je jediný zdroj pravdy, CRM data jen čte a obohacuje o vlastní poznámky a aktivity.
Obousměrná synchronizace je potřeba, když obě strany data mění. Typicky B2B: obchodník v CRM upraví kontaktní osobu, splatnost nebo cenovou skupinu a e-shop to musí převzít. Tady vznikají nejčastější chyby:
- Konflikt změn. Zákazník si v e-shopu změní telefon a obchodník ho ve stejnou chvíli upraví v CRM. Který platí? Pravidlo musí být dané předem, nejlépe po jednotlivých polích: kontaktní údaje vlastní e-shop, obchodní podmínky CRM.
- Smyčka. E-shop pošle změnu do CRM, CRM ji jako „novou změnu“ pošle zpět, e-shop znovu do CRM. Řešením je značit, odkud změna přišla, a změny vyvolané integrací nepřeposílat.
- Časová razítka. Porovnávejte čas poslední změny, ne jen hodnoty. Pomůže to i při dohánění výpadku.
Změny posílejte ideálně webhooky, tedy v okamžiku, kdy nastanou. Tam, kde systém webhooky nemá, pomůže pravidelné stahování změn přes REST API podle data poslední úpravy.
GDPR a souhlasy: co musí integrace přenést
Integrace kopíruje osobní údaje do dalšího systému. To má tři praktické důsledky.
Souhlasy musí cestovat s kontaktem. Obchodní sdělení e-mailem smíte posílat buď s předchozím souhlasem adresáta, nebo vlastním zákazníkům v režimu § 7 odst. 3 zákona č. 480/2004 Sb. Ten dovoluje oslovit zákazníka ohledně vlastních obdobných produktů, pokud má při získání kontaktu i v každé zprávě možnost zasílání snadno a zdarma odmítnout. Výklad a časté otázky k zákonu zveřejňuje Úřad pro ochranu osobních údajů na uoou.gov.cz. Pro integraci z toho plyne:
- přenášejte stav souhlasu a také jeho původ (souhlas, nebo zákaznická výjimka), datum a zdroj,
- odhlášení z odběru musí platit všude, ať se stalo v e-shopu, v CRM, nebo v e-mailingovém nástroji,
- nikdy nepřepisujte odhlášení starší hodnotou „souhlasí“ při synchronizaci.
Doložitelnost. Podle čl. 7 GDPR musí správce umět doložit, že souhlas byl udělen. Historie změn souhlasu v CRM nebo v middleware je tu praktický doklad.
Výmaz. Když zákazník uplatní právo na výmaz podle čl. 17 GDPR, musíte ho vyřídit ve všech systémech, kam jste údaje zkopírovali. Integrace by proto měla umět žádost o výmaz propagovat, nebo aspoň mít seznam míst, kde údaje leží. Širší souvislosti rozebíráme v článku GDPR pro e-shopy: praktický checklist 2026.
Deduplikace zákazníků
Duplicitní kontakty jsou nejčastější problém CRM napojeného na e-shop. Zákazník nakoupí bez registrace, pak se zaregistruje s jiným velkým písmenem v e-mailu, pak objedná na firmu. Ve výsledku má tři záznamy.
Jak tomu předejít:
- Zvolte jeden identifikátor. Obvykle e-mail, u registrovaných zákazníků i ID z e-shopu. U B2B firem IČO.
- Normalizujte. E-mail převeďte na malá písmena a ořízněte mezery, telefon na mezinárodní formát, IČO bez mezer.
- Používejte upsert. Operace „aktualizuj, pokud existuje, jinak vytvoř“ místo slepého zakládání. Například HubSpot má pro kontakty dávkový upsert, kde jako identifikátor zvolíte e-mail nebo vlastní unikátní vlastnost. HubSpot zároveň nedovolí dvěma kontaktům stejnou e-mailovou adresu.
- Vyčistěte historii před spuštěním. Import stávajících zákazníků je nejlepší chvíle duplicity sloučit, později je to dražší.
- Rozlište osobu a firmu. Jedna firma může mít víc nakupujících. Kontakty páruje e-mail, firmy IČO.
Příklady CRM a jejich API
Tři CRM, se kterými se u českých e-shopů potkáváme často. Limity jsou k září 2026 a mohou se měnit, aktuální stav ověřte v dokumentaci poskytovatele.
- [HubSpot](/kb/crm/hubspot). REST API s objekty kontaktů, firem a obchodů. Pro soukromé aplikace uvádí HubSpot ve svém changelogu u účtů s předplatným Professional limit 190 požadavků za 10 sekund a 650 000 požadavků denně, u Enterprise 190 požadavků za 10 sekund a 1 000 000 denně. Denní limit se sdílí mezi všemi aplikacemi v účtu. HubSpot také oznámil, že od konce září 2026 už v rozhraní účtu nepůjde zakládat nové legacy private apps a jako náhradu uvádí service keys.
- [Pipedrive](/kb/crm/pipedrive). Používá limity založené na tokenech. Každý účet má denní rozpočet vypočtený jako 30 000 základních tokenů × násobitel tarifu × počet uživatelů, každý endpoint stojí podle náročnosti jiný počet tokenů. Po vyčerpání rozpočtu API vrací chybu 429 až do resetu následující den. Navíc platí krátkodobé limity na uživatele v klouzavém dvousekundovém okně.
- [Raynet](/kb/crm/raynet). Český CRM s REST API. Výchozí limit je podle dokumentace 24 000 požadavků denně, stav limitu vrací API v hlavičkách X-Ratelimit a po překročení odpovídá chybou 429. Navýšení nabízí Raynet za 1 000 Kč měsíčně za každých 10 000 požadavků denně (ceník k září 2026, aktuální ceník ověřte u poskytovatele).
Salesforce a Bitrix24 mají také veřejná API a hotové konektory, konkrétní limity závisí na edici a licenci. Pro návrh integrace z toho plyne jedno: dávkujte (posílejte víc záznamů v jednom požadavku, kde to API umí), neposílejte změny, které nic nemění, a čtěte hlavičky s limity.
Jak na to prakticky
- Sepište, která data CRM opravdu potřebuje a kdo s nimi pracuje.
- U každého pole určete zdroj pravdy a směr synchronizace.
- Zvolte identifikátor zákazníka a firmy a pravidla normalizace.
- Vyčistěte duplicity před prvním importem.
- Přenášejte souhlasy včetně původu, data a odhlášení.
- Připravte postup pro výmaz údajů ve všech systémech.
- Ověřte limity API zvoleného CRM a navrhněte dávkování.
- Nastavte monitoring chyb a denní kontrolu počtů kontaktů a objednávek.
Napojení CRM děláme v rámci služby CRM a PIM systémy. Pokud CRM tvoří jen jeden z více propojených systémů, vyplatí se ho zapojit přes společnou mezivrstvu, viz Integrace a middleware. Proč CRM e-shop vůbec potřebuje, rozebíráme v článku CRM pro ecommerce, konkrétní nastavení Pipedrivu v článku Pipedrive pro e-shopy.
Potřebujete s tím pomoct?