CMS vs. DXP – Ver­ste­he den Un­ter­schied

Wenn du über die Fra­ge „CMS oder DXP“ re­flek­tierst, ist es ver­lo­ckend, sie als „bes­ser vs schlech­ter“ zu ver­ste­hen. Aber das wird der Kom­ple­xi­tät der Rea­li­tät nicht ge­recht. Viel­mehr ist „DXP“ eine evo­lu­tio­nä­re Er­wei­te­rung von „CMS“, be­glei­tet von phi­lo­so­phi­schen Fra­gen über Struk­tur, Mo­du­la­ri­tät, In­te­gra­ti­on und Er­leb­nis. In die­sem Text gehe ich Schritt für Schritt vor: erst eine kon­zep­tio­nel­le Ver­or­tung, dann ana­to­mi­sche Un­ter­schie­de, schließ­lich eine Ver­gleichs­ta­bel­le und greif­ba­re Bei­spie­le.

Be­vor wir ins De­tail ge­hen, lohnt es sich, die Be­grif­fe in ih­ren Kon­tex­ten zu ver­or­ten — ins­be­son­de­re his­to­risch und kon­zep­tio­nell.

Ein CMS war (und ist) pri­mär auf die Ver­wal­tung von In­hal­ten aus­ge­legt, ins­be­son­de­re Web­sei­ten­in­hal­te — also Tex­te, Bil­der, Do­ku­men­te, manch­mal struk­tu­rier­te Da­ten. In der klas­si­schen Form kop­pelt ein CMS Ba­ckend (Re­dak­ti­on, Spei­che­rung) und Front­end (Dar­stel­lung) re­la­tiv eng.

Mit der Zeit ent­stan­den Va­ri­an­ten: Head­less-CMS (Ba­ckend ohne vor­de­fi­nier­tes Front­end), de­cou­pled / hy­brid CMS (Ba­ckend und Front­end sind ge­trennt, aber oft mit ei­nem Prä­sen­ta­ti­ons­lay­er) etc.

Ein DXP möch­te nicht nur In­hal­te lie­fern, son­dern Er­leb­nis­se or­ches­trie­ren — ent­lang der Cus­to­mer Jour­ney, mit Kon­text, mit dy­na­mi­schem Ver­hal­ten. In vie­len Fäl­len ist ein mo­der­nes DXP mo­du­lar oder „com­po­sable“, also aus Bau­stei­nen zu­sam­men­ge­setzt.

Man kann sich das so vor­stel­len: Wenn ein CMS dein Pu­bli­ka­ti­ons­werk­zeug ist, ist eine DXP dein Er­leb­nis-Stu­dio + Kon­troll­zen­trum.

Ein gu­ter Ar­ti­kel, der die­se Ent­wick­lung be­leuch­tet: DXP vs. CMS: Choo­sing the right plat­form for your di­gi­tal stra­tegy von Con­tentful

Und auch: CMS vs. DXP: Key Dif­fe­ren­ces Ex­plai­ned bei dot­CMS

Ich un­ter­tei­le die Un­ter­schie­de in meh­re­re Di­men­sio­nen. In je­dem Teil zei­ge ich, wor­in sich CMS und DXP un­ter­schei­den, was ihre je­wei­li­gen Stär­ken und Schwä­chen sind, und gebe kon­kre­te Aspek­te zum Nach­den­ken.

Wenn du in ei­nem Pro­jekt nur Web­sei­ten, Blog­bei­trä­ge, Do­ku­men­ta­tio­nen ver­wal­ten willst, reicht oft ein gu­tes CMS. Wenn du je­doch Nut­zer je nach Ver­hal­ten, Ka­nal, Per­so­na­li­sie­rung steu­ern willst — z. B. ein Nut­zer sieht am Han­dy Wer­bung, klickt, lan­det in der App — dann brauchst du DXP-Fä­hig­kei­ten.

Ein DXP ist eher ein Öko­sys­tem als ein ein­zel­nes Pa­ket. Ein DXP will In­te­gra­tio­nen er­leich­tern, Da­ten aus ver­schie­de­nen Quel­len zu­sam­men­füh­ren und in Echt­zeit re­agie­ren.

Wenn du z. B. Nut­zer­ver­hal­ten, Kun­den­pro­fi­le, Seg­men­tie­rung, A/B-Tests usw. in­te­grie­ren willst, ist ein DXP deut­lich im Vor­teil.

Eine DXP er­laubt, dass der­sel­be In­halt für ver­schie­de­ne Nut­zer un­ter­schied­lich aus­ge­lie­fert wird — z. B. Ein­stei­ger vs Pow­er-User, Geo-Tar­ge­ting etc.

Wenn dein Pro­jekt nicht bei der Web­site en­det, son­dern über App, Ki­osk, Smartspea­k­er etc., dann brauchst du DXP-Fä­hig­kei­ten.

DXPs hel­fen da­bei, In­hal­te zu mes­sen, Ver­hal­ten zu ana­ly­sie­ren und dar­auf zu re­agie­ren.

Ein Nut­zer könn­te z. B. in der DXP se­hen, wie In­hal­te in ver­schie­de­nen Ka­nä­len syn­chro­ni­siert wer­den.

Vie­le An­bie­ter kom­bi­nie­ren heu­te CMS-Funk­tio­nen mit DXP-An­for­de­run­gen, z. B. hy­bri­des Sys­tem. Man­che be­gin­nen als CMS und wer­den mit Zeit zur DXP aus­ge­baut (Evo­lu­ti­on statt Re­vo­lu­ti­on). Oder man nutzt ein CMS in klei­nen Pro­jek­ten, und bei Wachs­tum por­tiert man Tei­le in die DXP-Schicht.

Pim­co­re spricht da­von, dass CMS-Funk­tio­nen häu­fig Kern­be­stand­tei­le ei­nes DXP sind, aber der DXP dar­über hin­aus die ge­sam­te Da­ten­ar­chi­tek­tur in­te­griert.

Ein paar kon­kre­te Bei­spie­le aus der Pra­xis:

Da­mit das Gan­ze „lebt“, hier ein er­zäh­le­ri­sches Bei­spiel, wie der Un­ter­schied sicht­bar wird:

Stell dir eine Fir­ma “Green­Tech GmbH” vor. An­fangs ha­ben sie le­dig­lich eine Web­site, Blog und Pro­dukt­be­schrei­bun­gen. Sie star­ten mit Word­Press als CMS. In­hal­te sind sta­tisch, die Sei­ten ein­fach, we­nig An­pas­sung für Nut­zer. Nach ei­nem Jahr wol­len sie per­so­na­li­sier­te Emp­feh­lun­gen — ba­sie­rend auf dem, was der Nut­zer zu­vor an­ge­se­hen hat. Sie möch­ten auch In­hal­te über eine mo­bi­le App aus­spie­len, Tests fah­ren und Nut­zer­pfa­de ana­ly­sie­ren. Sie ste­cken in ei­nem Di­lem­ma: Ihr CMS stößt an Gren­zen.

Also über­le­gen sie: Soll man ein DXP ein­set­zen? Sie mi­grie­ren in eine Platt­form, die nicht nur In­hal­te lie­fert, son­dern Da­ten sam­melt, Nut­zer­seg­men­te bil­det und Ka­nä­le or­ches­triert. Nun sieht ein wie­der­keh­ren­der Be­su­cher auf der Web­site Wer­bung für Ma­te­ria­li­en, in der Mo­bi­le-App wird ein pas­sen­der Ar­ti­kel an­ge­bo­ten, und in ei­nem Da­sh­board sieht das Mar­ke­ting­team un­mit­tel­bar, wie Nut­zer über Ka­nä­le wan­dern.

Der Un­ter­schied: Die In­hal­te sind nicht mehr mo­no­li­thisch und sta­tisch, sie wer­den le­ben­dig, kon­text­sen­si­tiv und teil ei­nes grö­ße­ren Er­leb­nis­ses.

Ein CMS or­ga­ni­siert In­hal­te – eine DXP or­ga­ni­siert Be­zie­hun­gen. Der Über­gang vom CMS zur DXP ist da­mit we­ni­ger ein tech­no­lo­gi­scher Sprung als ein Pa­ra­dig­men­wech­sel: vom Ver­öf­fent­li­chen zum Or­ches­trie­ren. Wo das CMS den Re­dak­teur stärkt, stärkt die DXP das ge­sam­te di­gi­ta­le Öko­sys­tem – sie spannt Da­ten, Ka­nä­le, Nut­zer und Er­leb­nis­se zu ei­nem kon­sis­ten­ten Ge­flecht.

Die­se Ver­schie­bung hat auch Kon­se­quen­zen für Stra­te­gie und Ar­chi­tek­tur. Un­ter­neh­men, die ihre di­gi­ta­len Be­rüh­rungs­punk­te ver­ste­hen wol­len, be­nö­ti­gen nicht zwin­gend eine DXP – wohl aber ein Be­wusst­sein da­für, wann ihr CMS an sei­ne Gren­zen stößt. Oft ge­nügt eine mo­du­la­re, API-ge­trie­be­ne CMS-Lö­sung, um in Rich­tung DXP zu wach­sen, ohne so­fort in En­ter­pri­se-Kom­ple­xi­tät zu ver­fal­len.

Die ent­schei­den­de Fra­ge lau­tet also nicht: „Brau­chen wir eine DXP?“ Son­dern: „Wol­len wir In­hal­te steu­ern – oder Er­fah­run­gen ge­stal­ten?“

Wer den Un­ter­schied ver­steht, kann be­wusst wäh­len, wie viel Struk­tur, Au­to­ma­ti­sie­rung und Kon­text sei­ne di­gi­ta­le Prä­senz wirk­lich braucht.