War­um ein gu­tes Track­ing-Set­up Teil der Web­site-Pla­nung ist

Es pas­siert fast je­des Mal. Ein mit­tel­stän­di­sches Un­ter­neh­men in­ves­tiert sechs­stel­lig in ei­nen Web­site-Re­launch. Neu­es De­sign, fri­scher Con­tent, viel­leicht so­gar ein Head­less-CMS-Set­up. Der Launch läuft gut. Die Ge­schäfts­füh­rung ist zu­frie­den. Und dann, drei Mo­na­te spä­ter, kommt die Fra­ge: „Was bringt uns die neue Web­site ei­gent­lich?“

Stil­le.

Nie­mand kann es be­ant­wor­ten. Nicht, weil die Web­site schlecht wäre. Son­dern weil nie­mand vor dem Launch de­fi­niert hat, was über­haupt ge­mes­sen wer­den soll. Kein Track­ing-Kon­zept. Kei­ne KPIs. Kein Me­a­su­re­ment Plan. Das Ana­ly­tics-Tool wur­de ir­gend­wann in der letz­ten Wo­che vor Go-Live noch schnell ein­ge­baut — ein Goog­le-Ana­ly­tics-Snip­pet im Hea­der, fer­tig. Und jetzt ste­hen alle da und schau­en auf Sei­ten­auf­ru­fe und Boun­ce Ra­tes, als wür­den die­se Zah­len ir­gend­et­was Sinn­vol­les über den Ge­schäfts­er­folg aus­sa­gen.

Das ist kein Ein­zel­fall. Das ist der Nor­mal­zu­stand im deut­schen Mit­tel­stand.

Wenn wir bei hap­py­co­ding ein Web­site-Pro­jekt pla­nen, dann ge­hört das Track­ing-Kon­zept in die­sel­be Pha­se wie In­for­ma­ti­ons­ar­chi­tek­tur, Wire­frames und Con­tent-Stra­te­gie. Nicht da­nach. Nicht „wenn wir mal Zeit ha­ben“. Nicht als Nach­ge­dan­ke.

War­um? Weil Track­ing-Ent­schei­dun­gen die tech­ni­sche Ar­chi­tek­tur be­ein­flus­sen. Ob du ser­ver­sei­ti­ges Track­ing brauchst oder cli­ent­sei­ti­ges reicht, ob du ei­nen Con­sent-Lay­er in­te­grie­ren musst, wel­che Da­ten du an wel­che Sys­te­me wei­ter­lei­test — das al­les hat Aus­wir­kun­gen auf die Im­ple­men­tie­rung. Wenn du die­se Fra­gen erst nach dem Launch stellst, baust du im bes­ten Fall um. Im schlech­tes­ten Fall lebst du mit ei­nem Set­up, das dir kei­ne brauch­ba­ren Da­ten lie­fert.

Track­ing nach­träg­lich ein­zu­bau­en ist wie eine Hei­zung nach­träg­lich in ein fer­ti­ges Haus ein­zu­bau­en. Es geht. Aber es ist teu­rer, häss­li­cher und funk­tio­niert nie so gut, wie wenn man es von An­fang an ein­ge­plant hät­te.

Der häu­figs­te Feh­ler, den ich sehe: Teams in­stal­lie­ren ein Ana­ly­tics-Tool und schau­en dann, wel­che Da­ten es ih­nen gibt. Das ist rück­wärts ge­dacht. Die rich­ti­ge Rei­hen­fol­ge ist: Zu­erst de­fi­nierst du, wel­che Ge­schäfts­fra­gen du be­ant­wor­ten willst. Dann lei­test du dar­aus KPIs ab. Und dann baust du das Track­ing so, dass es ge­nau die­se KPIs er­fasst.

Für ein B2B-Un­ter­neh­men mit er­klä­rungs­be­dürf­ti­gen Pro­duk­ten könn­ten re­le­van­te Fra­gen sein: Wie vie­le qua­li­fi­zier­te Leads ge­ne­riert die Web­site pro Mo­nat? Wel­che Con­tent-For­ma­te füh­ren zu Kon­takt­an­fra­gen? Über wel­che Ka­nä­le kom­men Be­su­cher, die tat­säch­lich kon­ver­tie­ren? Wie lan­ge dau­ert die Cus­to­mer Jour­ney von Erst­be­such bis Kon­takt­auf­nah­me?

Aus die­sen Fra­gen er­ge­ben sich kon­kre­te KPIs: Con­ver­si­on Rate nach Ka­nal, durch­schnitt­li­che Touch­points bis zur Con­ver­si­on, Con­tent-En­ga­ge­ment-Scores, Lead-Qua­li­tät nach Quel­le. Und aus die­sen KPIs er­gibt sich, wel­che Events du tra­cken musst, wel­che Di­men­sio­nen du brauchst und wie dein Da­ten­mo­dell aus­se­hen soll­te.

Die­sen Pro­zess nennt man ei­nen Me­a­su­re­ment Plan. Er ist kein Nice-to-have. Er ist die Grund­la­ge da­für, dass dein Track­ing über­haupt sinn­vol­le Da­ten lie­fert.

Sei­ten­auf­ru­fe sind die Wäh­rung der Neun­zi­ger. In ei­ner mo­der­nen Web-Ap­pli­ka­ti­on — be­son­ders mit ei­nem Frame­work wie Next.js, das cli­ent­sei­ti­ges Rou­ting nutzt — sind klas­si­sche Pa­ge­views oh­ne­hin nur be­grenzt aus­sa­ge­kräf­tig. Was du brauchst, ist eine durch­dach­te Event-Track­ing-Ar­chi­tek­tur.

Das be­deu­tet: Du de­fi­nierst vor dem Launch, wel­che Nut­zer­inter­ak­tio­nen ge­schäfts­re­le­vant sind und wie du sie als Events ab­bil­dest. Für eine B2B-Web­site sind das ty­pi­scher­wei­se: For­mu­lar-Sub­mis­si­ons, CTA-Klicks, PDF-Down­loads, Vi­deo-Plays, Scroll-Tie­fe auf wich­ti­gen Landing Pa­ges, In­ter­ak­tio­nen mit Pri­cing-Ele­men­ten, Chat-In­iti­ie­run­gen. Je­des die­ser Events braucht ei­nen kla­ren Na­men, de­fi­nier­te Pa­ra­me­ter und eine do­ku­men­tier­te Be­deu­tung.

Goog­le Ana­ly­tics 4 ar­bei­tet kom­plett event­ba­siert. Das ist ein Pa­ra­dig­men­wech­sel ge­gen­über Uni­ver­sal Ana­ly­tics, den vie­le Un­ter­neh­men noch nicht voll­stän­dig ver­stan­den ha­ben. In GA4 ist je­der Da­ten­punkt ein Event — auch ein Sei­ten­auf­ruf. Du kannst bis zu 25 be­nut­zer­de­fi­nier­te Pa­ra­me­ter pro Event mit­ge­ben und bis zu 50 be­nut­zer­de­fi­nier­te Di­men­sio­nen und Me­tri­ken an­le­gen. Das gibt dir enor­me Fle­xi­bi­li­tät, aber nur, wenn du die­se Ar­chi­tek­tur vor dem Launch planst.

Ein Punkt, der ger­ne un­ter­schätzt wird: die Na­mens­kon­ven­ti­on für Events. Wenn du dei­ne Events nicht kon­sis­tent be­nennst, hast du in sechs Mo­na­ten ein Cha­os aus „but­ton_click“, „click_but­ton“, „cta_click“ und „CTA_Click“, das nie­mand mehr aus­wer­ten kann. De­fi­nie­re ein Sche­ma: Verb-Ob­jekt-For­mat, Klein­buch­sta­ben, Un­ter­stri­che als Trenn­zei­chen. Zum Bei­spiel: „form_sub­mit“, „pdf_down­load“, „vi­deo_play“, „cta_click“. Do­ku­men­tie­re es. Hal­te dich dran. Klingt tri­vi­al, spart aber Stun­den an Be­rei­ni­gungs­ar­beit.

Die Wahl des Ana­ly­tics-Tools ist kei­ne tech­ni­sche Klei­nig­keit, die man an die Ent­wick­ler de­le­giert. Es ist eine stra­te­gi­sche Ent­schei­dung mit Aus­wir­kun­gen auf Da­ten­schutz, Da­ten­ho­heit, Kos­ten und Aus­wer­tungs­mög­lich­kei­ten.

Goog­le Ana­ly­tics 4 ist der De-fac­to-Stan­dard. Es ist kos­ten­los (in der Ba­sis­ver­si­on), hat eine rie­si­ge Com­mu­ni­ty, in­te­griert sich naht­los mit Goog­le Ads und bie­tet mit Big­Que­ry-Ex­port mäch­ti­ge Ana­ly­se­mög­lich­kei­ten. Aber: Dei­ne Da­ten lie­gen bei Goog­le. In den USA. Und die DSGVO-Kon­for­mi­tät von GA4 ist — sa­gen wir mal — ein fort­lau­fen­des Dis­kus­si­ons­the­ma. Die ös­ter­rei­chi­sche Da­ten­schutz­be­hör­de hat Goog­le Ana­ly­tics be­reits für nicht DSGVO-kon­form er­klärt. Ähn­li­che Ent­schei­dun­gen an­de­rer eu­ro­päi­scher Be­hör­den folg­ten.

Ma­to­mo ist die Al­ter­na­ti­ve für Un­ter­neh­men, die Da­ten­ho­heit ernst neh­men. Self-hos­ted auf dei­ner ei­ge­nen In­fra­struk­tur — bei uns ty­pi­scher­wei­se auf Hetz­ner mit Coo­li­fy und Do­cker — hast du vol­le Kon­trol­le über die Da­ten. Kei­ne Dritt­an­bie­ter, kei­ne trans­at­lan­ti­schen Da­ten­trans­fers, kei­ne Ab­hän­gig­keit von Googles Ge­schäfts­mo­dell. Ma­to­mo kann in der self-hos­ted Va­ri­an­te so­gar ohne Con­sent-Ban­ner be­trie­ben wer­den, wenn du es rich­tig kon­fi­gu­rierst: IP-An­ony­mi­sie­rung, kei­ne Coo­kies, kei­ne Dritt­an­bie­ter-Re­quests. Das ist ein ech­ter Vor­teil, weil Con­sent-Ban­ner nach­weis­lich 20-40% der Nut­zer vom Track­ing aus­schlie­ßen.

Die Ent­schei­dung zwi­schen GA4 und Ma­to­mo hat di­rek­te Aus­wir­kun­gen auf die tech­ni­sche Im­ple­men­tie­rung. Un­ter­schied­li­che APIs, un­ter­schied­li­che Event-Mo­del­le, un­ter­schied­li­che In­te­gra­ti­ons­mög­lich­kei­ten. Wenn du die­se Ent­schei­dung nach dem Launch triffst, musst du un­ter Um­stän­den er­heb­li­che Tei­le des Track­ing-Codes um­schrei­ben.

Bei hap­py­co­ding emp­feh­len wir für die meis­ten B2B-Pro­jek­te Ma­to­mo self-hos­ted als pri­mä­res Ana­ly­tics-Tool. Die Grün­de: vol­le DSGVO-Kon­for­mi­tät ohne ju­ris­ti­sche Grau­zo­ne, kein Ven­dor Lock-in, Da­ten auf eu­ro­päi­schen Ser­vern, kei­ne lau­fen­den Li­zenz­kos­ten (in der Com­mu­ni­ty Edi­ti­on). Wenn ein Kun­de zu­sätz­lich Goog­le Ads schal­tet und die GA4-In­te­gra­ti­on für Kam­pa­gnen-Op­ti­mie­rung braucht, set­zen wir GA4 par­al­lel dazu ein — aber eben als Er­gän­zung, nicht als ein­zi­ge Da­ten­quel­le.

Der Goog­le Tag Ma­na­ger ist ein mäch­ti­ges Werk­zeug. Er er­laubt Mar­ke­ting-Teams, Track­ing-Pi­xel und Events zu ver­wal­ten, ohne dass Ent­wick­ler je­des Mal Code de­ploy­en müs­sen. Aber er hat eine fun­da­men­ta­le Schwä­che: Er läuft im Brow­ser des Nut­zers. Und das be­deu­tet: Ad-Blo­cker kön­nen ihn blo­ckie­ren. Con­sent-Ab­leh­nung kann ihn de­ak­ti­vie­ren. Brow­ser-Pri­va­cy-Fea­tures kön­nen ihn ein­schrän­ken.

Ser­ver-Side Track­ing löst vie­le die­ser Pro­ble­me. Statt im Brow­ser des Nut­zers zu lau­fen, wer­den Track­ing-Da­ten vom Ser­ver ge­sen­det. Das ist ro­bus­ter, schnel­ler (weil kei­ne zu­sätz­li­chen Ja­va­Script-Da­tei­en im Brow­ser ge­la­den wer­den) und gibt dir mehr Kon­trol­le über die Da­ten, be­vor sie an Ana­ly­tics-Diens­te wei­ter­ge­lei­tet wer­den.

In ei­ner Next.js-Ar­chi­tek­tur ist Ser­ver-Side Track­ing be­son­ders ele­gant um­zu­set­zen. Du kannst API Rou­tes oder Ser­ver Ac­tions nut­zen, um Events ser­ver­sei­tig zu er­fas­sen und an Ma­to­mo oder GA4 wei­ter­zu­lei­ten. Der Vor­teil: Die Track­ing-Lo­gik ist Teil dei­ner Ap­pli­ka­ti­on, nicht ein ex­ter­nes Script, das im Brow­ser her­um­hängt. Du hast vol­le Kon­trol­le über Da­ten­qua­li­tät und Da­ten­hy­gie­ne.

Aber auch hier gilt: Die­se Ar­chi­tek­tur­ent­schei­dung musst du vor dem Launch tref­fen. Ein nach­träg­li­cher Wech­sel von cli­ent­sei­ti­gem zu ser­ver­sei­ti­gem Track­ing ist ein si­gni­fi­kan­ter Um­bau.

Coo­kie-Ban­ner sind für die meis­ten Nut­zer ein Är­ger­nis. Für Web­site-Be­trei­ber sind sie ein Da­ten­loch. Je nach Bran­che und Ziel­grup­pe leh­nen 30-60% der Nut­zer nicht-es­sen­zi­el­le Coo­kies ab. Das be­deu­tet: Mit ei­nem klas­si­schen GA4-Set­up, das ei­nen Con­sent-Ban­ner er­for­dert, ver­lierst du bis zur Hälf­te dei­ner Da­ten. Du siehst nur das Ver­hal­ten der Nut­zer, die ak­tiv auf „Alle ak­zep­tie­ren“ ge­klickt ha­ben — und die­se Grup­pe ist nicht re­prä­sen­ta­tiv.

Es gibt Stra­te­gien, da­mit um­zu­ge­hen. Goog­le bie­tet mit dem Con­sent Mode v2 eine Mög­lich­keit, auch bei ab­ge­lehn­tem Con­sent an­ony­mi­sier­te Da­ten zu er­fas­sen und die­se über Ma­chi­ne Lear­ning zu mo­del­lie­ren. Das funk­tio­niert, hat aber of­fen­sicht­li­che Li­mi­ta­tio­nen — mo­del­lier­te Da­ten sind eben kei­ne ech­ten Da­ten.

Die sau­be­re Al­ter­na­ti­ve: Ein Ana­ly­tics-Tool, das kei­nen Con­sent-Ban­ner braucht. Ma­to­mo self-hos­ted, kor­rekt kon­fi­gu­riert, kann ge­nau das. Kei­ne Coo­kies, voll­stän­di­ge IP-An­ony­mi­sie­rung, alle Da­ten auf dei­nem ei­ge­nen Ser­ver. Da­mit er­fasst du 100% dei­ner Be­su­cher, nicht nur die, die dei­nem Ban­ner zu­ge­stimmt ha­ben. Für B2B-Web­sites, wo je­der ein­zel­ne Be­su­cher po­ten­zi­ell ein hoch­prei­si­ger Lead ist, macht das ei­nen rie­si­gen Un­ter­schied.

Die Con­sent-Ma­nage­ment-Stra­te­gie be­ein­flusst dei­ne Track­ing-Ar­chi­tek­tur grund­le­gend. Wel­ches Con­sent-Tool du ein­setzt (Coo­kie­bot, User­cen­trics, eine Cus­tom-Lö­sung), wie du es in dein Tag-Ma­nage­ment in­te­grierst, wel­che Track­ing-Tech­no­lo­gien du an wel­chen Con­sent-Sta­tus kop­pelst — all das muss vor dem Launch ste­hen. Ein nach­träg­li­cher Ein­bau führt fast im­mer zu Da­ten­in­kon­sis­ten­zen und Com­pli­ance-Ri­si­ken.

Ich will das noch­mal deut­lich ma­chen, weil es der Kern des Pro­blems ist. Track­ing nach­träg­lich ein­zu­bau­en ist nicht ein­fach „spät, aber okay“. Es hat kon­kre­te, mess­ba­re Nach­tei­le.

Ers­tens: Du ver­lierst Da­ten. Je­der Tag ohne Track­ing ist ein Tag, an dem du kei­ne Da­ten sam­melst. Du kannst sie nicht nach­träg­lich ge­ne­rie­ren. Wenn du drei Mo­na­te nach dem Launch dein Track­ing ein­rich­test, feh­len dir drei Mo­na­te Base­line-Da­ten. Du kannst kei­ne Vor­her-Nach­her-Ver­glei­che ma­chen. Du kannst kei­ne Trends iden­ti­fi­zie­ren. Du fliegst blind.

Zwei­tens: Die tech­ni­sche Im­ple­men­tie­rung wird teu­rer. Track­ing-Code in eine be­stehen­de Ap­pli­ka­ti­on ein­zu­bau­en be­deu­tet, exis­tie­ren­den Code an­zu­fas­sen. Das er­for­dert Ver­ständ­nis der be­stehen­den Ar­chi­tek­tur, Test­ing, po­ten­zi­el­le Re­gres­si­on. In ei­ner Next.js-App mit Ser­ver Com­pon­ents, Cli­ent Com­pon­ents und ver­schie­de­nen Ren­de­ring-Stra­te­gien ist das kein Tri­vi­al­fall.

Drit­tens: Du op­ti­mierst dei­ne Web­site im Blind­flug. Ohne Track­ing-Da­ten triffst du De­sign- und Con­tent-Ent­schei­dun­gen auf Ba­sis von Bauch­ge­fühl statt auf Ba­sis von Nut­zer­da­ten. Wel­che Landing Pa­ges funk­tio­nie­ren? Wo sprin­gen Nut­zer ab? Wel­che CTAs kon­ver­tie­ren? Ohne Track­ing weißt du es nicht. Du rätst. Und Ra­ten ist kei­ne Stra­te­gie.

Vier­tens: Die Da­ten­qua­li­tät lei­det. Nach­träg­li­ches Track­ing wird oft has­tig im­ple­men­tiert. Events wer­den in­kon­sis­tent be­nannt, Pa­ra­me­ter feh­len, die Do­ku­men­ta­ti­on ist lü­cken­haft. Sechs Mo­na­te spä­ter ver­steht nie­mand mehr, was „event_ac­tion_3“ be­deu­ten soll­te. Und dann fängt man von vor­ne an.

Ein Me­a­su­re­ment Plan ist ein Do­ku­ment, das die Brü­cke zwi­schen Ge­schäfts­zie­len und tech­ni­scher Track­ing-Im­ple­men­tie­rung schlägt. Er be­ant­wor­tet drei Fra­gen: Was wol­len wir wis­sen? Wie mes­sen wir es? Und wie set­zen wir die Mes­sung tech­nisch um?

Ein gu­ter Me­a­su­re­ment Plan hat ty­pi­scher­wei­se fünf Ebe­nen. Ganz oben ste­hen die Ge­schäfts­zie­le: Lead-Ge­ne­rie­rung stei­gern, Mar­ken­be­kannt­heit er­hö­hen, Self-Ser­vice-Quo­te ver­bes­sern. Dar­un­ter die KPIs, die die­se Zie­le mess­bar ma­chen: An­zahl qua­li­fi­zier­ter Leads, News­let­ter-Abon­nen­ten, Sup­port-Ti­cket-Re­duk­ti­on. Dann die kon­kre­ten Me­tri­ken: Con­ver­si­on Rate, durch­schnitt­li­che Ses­si­on-Dau­er auf Pro­dukt­sei­ten, Down­load-Zah­len. Dar­un­ter die Events und Di­men­sio­nen, die du tra­cken musst, um die­se Me­tri­ken zu be­rech­nen. Und ganz un­ten die tech­ni­sche Im­ple­men­tie­rung: Wel­cher Code feu­ert wel­ches Event, mit wel­chen Pa­ra­me­tern, an wel­chem Punkt in der User Jour­ney?

Die­ses Do­ku­ment ent­steht in Zu­sam­men­ar­beit zwi­schen Busi­ness-Stake­hol­dern, Mar­ke­ting und Ent­wick­lung. Es ist kein rei­nes IT-The­ma und kein rei­nes Mar­ke­ting-The­ma. Es ist ein Ge­schäfts­the­ma. Und es muss ste­hen, be­vor die ers­te Zei­le Track­ing-Code ge­schrie­ben wird.

Für B2B-Un­ter­neh­men ist die Web­site nur ein Touch­point in ei­ner lan­gen Cus­to­mer Jour­ney. Der ei­gent­li­che Wert ent­steht, wenn du Web­site-Da­ten mit dei­nem CRM ver­knüp­fen kannst. Wenn du siehst, dass Lead X, der ge­ra­de ei­nen 50.000-Euro-Deal ab­ge­schlos­sen hat, vor sechs Mo­na­ten über ei­nen be­stimm­ten Blog-Ar­ti­kel auf dei­ne Web­site ge­kom­men ist, drei White­pa­per her­un­ter­ge­la­den hat und dann über die Pri­cing-Sei­te ein Kon­takt­for­mu­lar aus­ge­füllt hat — dann ver­stehst du, wel­cher Con­tent wirk­lich Um­satz treibt.

Die­se Ver­knüp­fung ist tech­nisch an­spruchs­voll, aber mach­bar. Du brauchst eine User-Iden­ti­fi­ka­ti­on, die über die Web­site hin­aus funk­tio­niert — ty­pi­scher­wei­se über eine E-Mail-Adres­se, die bei der For­mu­lar-Sub­mis­si­on er­fasst wird. Die­se ID ver­bin­det den an­ony­men Web­site-Be­su­cher mit dem Lead in dei­nem CRM. Tools wie Su­pa­ba­se kön­nen als Zwi­schen­schicht fun­gie­ren, um Web­site-Events mit CRM-Da­ten zu kor­re­lie­ren, be­vor sie an ein Re­port­ing-Tool wei­ter­ge­lei­tet wer­den.

Aber auch hier: Die­se In­te­gra­ti­on muss von An­fang an mit­ge­dacht wer­den. Wel­che Da­ten flie­ßen vom Web­site-Track­ing ins CRM? Wel­che Fel­der im CRM wer­den be­füllt? Wie sieht der Da­ten­fluss tech­nisch aus? API-Calls, Web­hooks, Batch-Im­ports? Die­se Fra­gen in der Pla­nungs­pha­se zu klä­ren, spart Wo­chen an nach­träg­li­cher In­te­gra­ti­ons­ar­beit.

Track­ing-Da­ten sind nur dann wert­voll, wenn sie tat­säch­lich an­ge­schaut wer­den. Und hier liegt ein wei­te­res Pro­blem vie­ler Un­ter­neh­men: Sie ha­ben Da­ten, aber nie­mand schaut re­gel­mä­ßig rein. Das Goog­le-Ana­ly­tics-Da­sh­board wird ein­mal im Quar­tal ge­öff­net, wenn der Vor­stand nach Zah­len fragt. Den Rest der Zeit ver­staubt es.

Die Lö­sung: Au­to­ma­ti­sier­tes Re­port­ing. Statt dar­auf zu war­ten, dass je­mand sich in ein Ana­ly­tics-Tool ein­loggt, schickst du die re­le­van­ten Zah­len pro­ak­tiv an die rich­ti­gen Leu­te. Und ge­nau hier kommt n8n ins Spiel.

n8n ist ein self-hos­ted Work­flow-Au­to­ma­ti­on-Tool, das wir bei hap­py­co­ding für ge­nau sol­che Auf­ga­ben ein­set­zen. Du kannst Work­flows bau­en, die mor­gens au­to­ma­tisch die wich­tigs­ten KPIs aus Ma­to­mo oder GA4 zie­hen, sie auf­be­rei­ten und als Slack-Nach­richt, E-Mail oder Da­sh­board-Up­date an das Team sen­den. Kein ma­nu­el­les Ein­log­gen, kein Ex­port, kei­ne Pow­er­Point-Slides. Die Da­ten kom­men zu dir, nicht du zu den Da­ten.

Ein ty­pi­scher n8n-Work­flow für ein B2B-Re­port­ing sieht so aus: Je­den Mon­tag um 8 Uhr zieht n8n die Vor­wo­chen­da­ten aus Ma­to­mo. Be­su­cher, Con­ver­si­ons, Top-Landing-Pa­ges, Con­ver­si­on Rate nach Ka­nal. Er ver­gleicht die Zah­len mit der Vor­wo­che, be­rech­net pro­zen­tua­le Ver­än­de­run­gen und for­ma­tiert al­les in ei­ner Slack-Nach­richt mit grü­nen und ro­ten Pfei­len. Das Mar­ke­ting-Team hat sei­ne Zah­len, be­vor der ers­te Kaf­fee fer­tig ist.

Der Vor­teil von n8n ge­gen­über Cloud-Lö­sun­gen wie Za­pier: Es läuft auf dei­ner ei­ge­nen In­fra­struk­tur. Kei­ne Da­ten, die an Dritt­an­bie­ter flie­ßen. Kei­ne mo­nat­li­chen SaaS-Kos­ten, die mit dem Da­ten­vo­lu­men ska­lie­ren. Self-hos­ted auf Hetz­ner mit Coo­li­fy, ge­nau wie der Rest des Stacks. Kein Ven­dor Lock-in.

Noch wert­vol­ler als re­gel­mä­ßi­ge Re­ports sind Echt­zeit-Aler­ts. n8n kann nicht nur pe­ri­odi­sche Re­ports ge­ne­rie­ren, son­dern auch auf An­oma­lien re­agie­ren. Con­ver­si­on Rate bricht plötz­lich ein? So­for­ti­ge Be­nach­rich­ti­gung. Ein be­stimm­ter Blog-Ar­ti­kel geht vi­ral? Du er­fährst es, be­vor es in der Kaf­fee­pau­se The­ma wird. For­mu­lar-Sub­mis­si­ons stop­pen kom­plett? Alarm, be­vor du drei Tage lang Leads ver­lierst, weil ein Ja­va­Script-Feh­ler das Kon­takt­for­mu­lar lahm­legt.

Die­se Art von pro­ak­ti­vem Mo­ni­to­ring ist nur mög­lich, wenn das Track­ing-Set­up von An­fang an sau­ber auf­ge­setzt ist. Wenn dei­ne Events kon­sis­tent be­nannt sind, wenn dei­ne KPIs klar de­fi­niert sind und wenn die tech­ni­sche In­fra­struk­tur steht, die Da­ten in Echt­zeit ver­ar­bei­ten kann.

Wenn Track­ing so wich­tig ist, war­um ma­chen es dann so we­ni­ge? Ich sehe drei Haupt­grün­de.

Der ers­te: Track­ing ist un­se­xy. In ei­nem Web­site-Pro­jekt kämp­fen De­sign, Con­tent und Fea­tures um Bud­get und Auf­merk­sam­keit. Track­ing kommt als letz­ter Punkt auf die Lis­te, wenn das Bud­get schon ver­braucht und die Dead­line über­schrit­ten ist. Es gibt kein Stake­hol­der-Mee­ting, in dem je­mand sagt: „Wow, die­ser Me­a­su­re­ment Plan ist fan­tas­tisch.“ Track­ing-Ar­beit ist un­sicht­bar — bis sie fehlt.

Der zwei­te: Feh­len­des Know-how auf Agen­tur­sei­te. Vie­le klas­si­sche Web­agen­tu­ren kön­nen De­sign und Ent­wick­lung, aber ha­ben kei­ne Track­ing-Ex­per­ti­se. Sie in­stal­lie­ren GA4, set­zen ei­nen Coo­kie-Ban­ner und ha­ken „Ana­ly­tics“ auf ih­rer Check­lis­te ab. Ein ech­tes Track­ing-Kon­zept mit Me­a­su­re­ment Plan, Event-Ar­chi­tek­tur und CRM-In­te­gra­ti­on über­steigt ihre Kom­pe­tenz. Und was man nicht kann, bie­tet man nicht an.

Der drit­te: Die Kon­se­quen­zen kom­men ver­zö­gert. Ein feh­len­des Track­ing-Set­up tut am Launch-Day nicht weh. Die Web­site sieht gut aus, sie lädt schnell, die In­hal­te stim­men. Erst Mo­na­te spä­ter, wenn die ers­te ROI-Dis­kus­si­on kommt, fällt auf, dass man nichts mes­sen kann. Und dann ist es zu spät für ei­nen sau­be­ren Start — du hast be­reits Mo­na­te an Da­ten ver­lo­ren.

Wenn du den ei­nen Punkt aus die­sem Ar­ti­kel mit­nimmst, dann die­sen: Track­ing ist kein Mar­ke­ting-Fea­ture. Es ist Teil der tech­ni­schen Ar­chi­tek­tur dei­ner Web­site. So wie du Au­then­ti­fi­zie­rung, API-De­sign oder Da­ten­bank-Sche­ma in der Pla­nungs­pha­se de­fi­nierst, ge­hört auch das Track­ing-Set­up in die­se Pha­se.

Bei hap­py­co­ding ha­ben wir ei­nen Track­ing-Work­shop als fes­ten Be­stand­teil un­se­rer Pro­jekt-Kick­offs eta­bliert. In die­sem Work­shop de­fi­nie­ren wir ge­mein­sam mit dem Kun­den Ge­schäfts­zie­le, lei­ten KPIs ab, ent­schei­den über die Tool-Land­schaft (Ma­to­mo, GA4, oder bei­des), pla­nen die Event-Ar­chi­tek­tur und do­ku­men­tie­ren al­les in ei­nem Me­a­su­re­ment Plan. Das dau­ert ei­nen hal­ben Tag. Es kos­tet ei­nen Bruch­teil des Ge­samt-Bud­gets. Und es spart Wo­chen an nach­träg­li­cher Ar­beit und Mo­na­te an ver­lo­re­nen Da­ten.

Die Fra­ge ist nicht, ob du dir ein Track­ing-Set­up leis­ten kannst. Die Fra­ge ist, ob du es dir leis­ten kannst, ohne ei­nes zu laun­chen. Und die Ant­wort ist ziem­lich ein­deu­tig: Nein.

Wenn du ein Web­site-Pro­jekt planst und si­cher­stel­len willst, dass das Track­ing von Tag eins an funk­tio­niert — nicht als Nach­ge­dan­ke, son­dern als in­te­gra­ler Be­stand­teil der Ar­chi­tek­tur — dann sprich uns an. Wir bau­en kei­ne Web­sites, die gut aus­se­hen und sich dann nicht mes­sen las­sen. Wir bau­en Web­sites, die funk­tio­nie­ren. Und funk­tio­nie­ren heißt: mess­bar Er­geb­nis­se lie­fern.