Mitul conectorului CDP

La o demonstrație recentă CDP la care am participat, un client nervos l-a întrebat pe furnizor dacă are un conector la Salesforce Sales Cloud. Vânzătorul a răspuns afirmativ, iar clientul a răsuflat uşurat. Dar adevărul este că majoritatea furnizorilor de platforme de date pentru clienți (CDP) au conectori dezamăgitori. Citiți mai departe pentru ce este și ce puteți face în acest sens.

Un pic de istorie: cursa „portlet-urilor” întreprinderii

Această întâlnire mi-a amintit de era „portalului întreprinderilor”. Vă rog să mă răsfăț în timp ce privesc înapoi la sfârșitul anilor 2000 și începutul anilor 2010 – o perioadă pe care majoritatea clienților și vânzătorilor ar dori să uite, dar care încă oferă lecții și astăzi.

Portalurile de întreprindere trebuiau să ofere o interfață unică și convenabilă într-o gamă potențială largă de aplicații de întreprindere, afișate ca blocuri separate pe un ecran într-un motiv de tablou de bord. Tehnologia care stă la baza acelor blocuri individuale a primit multe nume, dar, deocamdată, să le numim „portleturi”.

A devenit rapid clar că programele portal erau proiecte de integrare extrem de complexe, așa că întreprinderile au căutat în mod natural să folosească codul de conector prefabricat. Vânzătorii au răspuns cu cataloage portlet și a urmat o cursă a înarmărilor. „Avem 250 de portleturi”, s-ar lăuda un vânzător.

Aceste portleturi ar varia dramatic în ceea ce privește proveniența, suportul, gradul de utilizare, performanța, securitatea și (esențial) bazele tehnice. Un „portlet” era de obicei o instanță de referință a unui cod Java sau C# scris de cineva pentru o implementare unică client. De cele mai multe ori, codul trebuia revizuit, uneori de la zero.

Furnizorii au replicat – nu pe nedrept – că problemele au apărut adesea din modul în care au fost configurate sistemele de la distanță, mai degrabă decât din platforma portalului în sine. Poate că da, dar întreprinderile s-au obosit în cele din urmă de portlet-uri. Pe fondul altor schimbări tehnologice și de afaceri din lumea digitală, tehnologia platformei portal a demodat treptat.

Noua cursă de conectori CDP

Avanză rapid până astăzi, iar lumea ajunge să înțeleagă CDP-urile ca medii de integrare (printre altele). Fiecare echipă de selecție CDP cu care lucrăm se străduiește să găsească furnizori cu conectori prefabricați care să se potrivească cu platformele lor existente. Cu toate acestea, aproape fiecare implementare CDP găsește dezvoltatori scumpi care modifică sau rescriu în mod semnificativ acei conectori.

Furnizorii CDP se pare că cedează presiunilor pe care le-au suportat frații lor de portal. Dacă clienții apreciază un catalog divers de conectori, atunci, în calitate de furnizor CDP, trebuie să afișați mulți dintre ei, gata sau nu. În demo-urile CDP, conectorii apar pe ecran ca blocuri ordonate (cu logo-ul platformei conectate apărând vizibil) pe care le puteți trage – aproape ca portleturi!

Ei bine, nu atât de repede. La fel ca portleturile, conectorii furnizorilor CDP pot rezulta pur și simplu din rezultatul unei singure implementări. Mai important, în unele cazuri, un singur conector nu poate aborda complexitatea platformei martech de la celălalt capăt.

Luați în considerare Salesforce Sales Cloud, menționat mai sus. Platforma suferă de un model de obiect problematic pe care majoritatea licențiaților îl contorsionează sau îl extind puternic. Poate fi ca și cum te-ai conecta la o caracatiță foarte furioasă. Și Salesforce nu este în niciun caz singur aici. În astfel de situații, conectorul unui furnizor CDP poate oferi doar schelele de bază și lăsa restul la latitudinea unui dezvoltator.

Inamicul suntem noi?

Portalurile s-au stins din alt motiv. Dacă ochii sunt ferestre către suflet, portalurile erau ferestre către intestinele întreprinderii. Un portal a fost la fel de util ca și aplicațiile subiacente. Adesea, acele aplicații erau dezordonate, nu aveau conținut comun și modele de metadate, foloseau diverse regimuri de control al accesului, prezentau diferite modele UX și, uneori, expuneau date de calitate scăzută.

La compania mea, vedem un fenomen similar cu CDP-urile. În funcție de modul în care abordezi un efort CDP (și aici apar diferite modele), CDP poate expune imaturitatea regimului mai larg de gestionare a datelor clienților - cu atât mai mult motiv pentru a potrivi orice CDP potențial cu arhitectura ta de date mai largă.

Sapă mai profund: cum să identificați și să organizați datele cu un nou CDP

Atenție la furnizorii de CDP care pretind că au cataloage de conectori diverse

Ca întotdeauna, prevenit este antebrat. În primul rând, reconsiderați supraponderarea unui furnizor care pretinde că are cataloage de conectori care se potrivesc bine cu stiva dvs. Printre alte motive, simpla mutare a fișierelor CSV poate rezolva multe cazuri de utilizare (care nu sunt în timp real). Când aveți nevoie de conectori ambalate, experiența de integrare specifică devine utilă, dar nu vă protejează în mod inerent împotriva dezvoltării substanțiale în viitor. Cheia este să afli cât dezvoltare.

Să sperăm că urmați un proces agil de selecție CDP care se încheie cu o finalizare competitivă și o dovadă de concept mai tehnică (PoC) cu unul sau doi finaliști. Un PoC este un mediu grozav pentru a testa câțiva conectori esențiali. Veți ajunge apoi să înțelegeți nivelul de efort pentru revizuire acolo unde este necesar - și asta ar putea fi adesea.

La fel ca predecesorii lor de furnizori de portal, furnizorii CDP vor promite pachete de „pornire rapidă” pentru a accelera o implementare inițială. Nu crede. Încă o dată, unele întârzieri pot apărea din momentul în care va trebui să vă puneți în ordine propria casă de date, dar, de asemenea, vă pot garanta că cineva va face dezvoltarea conectorilor, iar acest lucru este măsurat în sferturi, nu în luni. Bugetează-ți resursele în consecință.