10 gode grunde til ikke at bygge din egen CDP

At bygge sin egen CDP er en stor mundfuld, selv for rigtig store virksomheder. Det kræver enormt mange ressourcer indledningsvis, under projektet, og efter projektet er “færdigt”.
Der er mange overvejelser man skal gøre sig hvis man vælger at gå denne vej, og derfor vil vi gerne give vores besyn på, hvorfor vi anbefaler at man ikke bygger den selv.

1. DU BRUGER ALT FOR MANGE RESSOURCER

Det er altid sjovt og spændende at bygge et nyt produkt, som du virkelig mener kan tilføre din virksomhed værdi. Hele processen med at finde ud af, hvem der skal med på projektet, idefasen, drømmene og hele tanken om, hvor fedt det bliver at lancere dette nye produkt.

Du har produktet klar, alle de ansatte bruger det, og alt er helt perfekt, indtil det ikke er det længere. Du har lanceret produktet, og begynder nu at bruge mere tid på at fejlrette end at udvikle nye funktioner.

I de første måneder bruger du 20% af din tid på fejlrettelser og 80% på at udvikle nye funktioner. Men det er software, og jo større og mere kompleks det bliver, jo mere vedligeholdelse bliver der. Efter noget tid bruger du 80% på fejlrettelser og 20% på udvikling af nye features.

Du begynder at se, at nu er dine udviklingsressourcer låst på produktet. Med andre ord er vedligeholdelse dyrt og svært at budgettere for, fordi alle planer er optimistiske.

2. DU BRUGER TID PÅ AT GENOPFINDE HJULET..

Du kommer til at bruge en masse tid på at bygge noget, som ofte vil være halvt så godt, som det der allerede eksisterer i forvejen. Du vil ligeledes bruge en masse tid på at lave de fejl, som mange andre har lavet før dig, og du vil bruge en masse tid på at udbedre noget, som andre allerede har udbedret i deres egne systemer.

Når du går ud og investerer i at købe en ”færdig software”, køber du ikke kun selve softwaren, men du køber også al den læring, det gode og det dårlige, som der følger med i at bygge en software som denne. Du sparer noget af det mest værdifulde, nemlig din tid.

3. DATAMODELLEN(ERNE)

Hvert produkt har brug for en datamodel. Vi garanterer, at den første version af den datamodel du opretter, ikke vil være den sidste, og at du vil gennemgå utallige iterationer, ændre og ødelægge den. Og du vil aldrig nogensinde stoppe med at videreudvikle datamodellen.

4. KUNDEPROFILER OG IDENTITETSOPLØSNINGER

Det hele ser meget simpelt ud. Lad os blot bruge nogle fremmede nøgler i hændelsesdataene igennem nogle SQL-sammenkoblinger…. Det fungerer ikke, fordi kundeenheder kan udvikle sig, og der ikke er nogen sammenføjning i SQL med korrekt rekursion.

Du begynder istedet at skrive det i Python. Du rammer væggen med hukommelsesforbrug. Du optimerer det til CPU, nu kører det for længe på grund af I/O… Og listen forstætter derud af!

5. ALARMER OG OVERVÅGNINGER

Når du bygger din datamodel til CDP, integrerer du dataene og opbygger datapipelinjerne som cron-job. Fra tid til anden (læs: hver anden dag), vil en fra din organisation ringe til dig og fortælle dig, at der ikke findes nogen friske data i CDP’en.

Du har brug for overvågning om ydeevnen, og ikke kun om din infrastruktur og selve applikationen, men også om hele datakvaliteten i CDP’en.

6. INTEGRATIONSOPDATERINGER

Hvis du indlæser data fra f.eks. Salesforce Marketing Cloud, fungerer det hele rigtig godt, indtil dataen en dag stopper med at komme ind. Efter at have kigget systemet igennem i sømmene og kigget alle logfilerne igennem, finder du ud af, at API ‘en er ændret.

Efter at have læst logfiler finder du ud af, at den gamle version er forældet. Du finder ligeledes hurtigt ud af, at dette sker for alle dine datakilder, sporadisk, hele tiden… Igen bruger du en masse dyrebar tid på at fikse det.

7. SIKKERHED, EN TING DU BARE IKKE KAN GÅ PÅ KOMPROMIS MED

Du bygger din egen CDP med en masse brugere, flere forskellige tilladelsessystemer, og du gemmer alle dine kundedata heri. Er du sikker på, at du ikke har nogen SQL-injektion, CSRF, en mand i midten, XSS og cirka en anden sårbarhed i din kode? Er du klar til at satse din virksomhed på det?

Hvilket system har den allerbedste sikkerhed? Det system der er hjemmelavet? Eller det system der har været flere år under udvikling, er blevet testet af snesevis af kunder fra forskellige brancher, og som har gennemgået et utal af sikkerhedstests?

8. HVEM KOMMER TIL AT UDVIKLE DIN LØSNING?

Vi kender alle dygtige udviklere, og vi kender alle nogle, der har en solid baggrund indenfor diverse brancher, men her taler vi om produktudvikling. Her er der brug for et stort team af specialister, som kan hjælpe dig med at føre din løsning ud i livet.

Her er der brug for en dataarkitekt, dataingeniør, back-end udvikler, frontend udvikler, software arkitekt, folk til at teste, folk til at dokumentere, en product owner og en projektleder, der kan styre projektet fra ende til anden. Vi ved, hvor svært det er at finde disse folk. Det kan tage meget lang tid, koste mange penge og koste meget ressource tid.

9. DOKUMENTATION

Det der ofte sker, når man udvikler sin egen løsning til eget brug, er at dokumentationen ikke rigtig er noget, man gider bruge tid på, for det er jo til intern brug. Dine folk, som arbejder i systemet, begynder at blive trætte af, at der ikke er nogen dokumentation, og de begynder at smutte en efter en.

Herefter skal du ansætte nye folk. De nye folk synes, at systemet er noget værre rod, og at de skal omskrive det hele, før det giver mening. Det koster tid, og det koster endnu flere penge.

10. DATAVIDENSKAB – DATA OG VIDENSKAB

Jo mere data du har, jo bedre er det, og du vil ikke udvikle en stor algoritme, uden at du har god data at arbejde med. Firmaer som udvikler CDP’er har rigtig mange klienter og dermed også rigtig meget data at arbejde med. Denne data giver dem en masse erfaringer, som de kan bruge til at videreudvikle deres løsning både i backend og i frontend.

Man skal bruge en data scientist til at udarbejde disse algoritmer, og de kan være svære at stimulere og holde engageret, hvis de kun arbejder på ét system. Især i en tid hvor disse personer har en rigtig stor markedsværdi.

Det kan være svært at få et overblik over alle de ting man skal være opmærksom på, når man går med overvejelser om at investere i en CDP.

• Hvordan skal organisationen se ud?
• Hvorfor skal vi bruge en CDP?
• Hvordan bygger jeg en businesscase på en investering som denne?
• Hvilke ressourcer har jeg behov for?
• Har jeg de rette ressourcer allerede?
• Hvilke data giver mening at integrere?
• Hvordan får jeg et overblik over mine tech-platforme?
• Hvad gør jeg hvis jeg gerne vil have online og offline data?
• Hvad er et tokenization ID?
• Etc.

Der dukker mange spørgsmål op, som kan være svære at besvare hvis man ikke har arbejdet med dette før.

Vil du vide mere om Customer Data Platforms, eller har du brug for rådgivning til hvor du skal starte, eller blot en snak om hvad en CDP kan gøre for Jeres forretning? Så giv os endelig et kald, eller send os en mail, så ser vi om vi ikke kan få rådgivet dig til den bedste løsning.