Properties sind das Fundament deines HubSpot CRMs — und gleichzeitig die Stelle, an der die meisten Setups aus dem Ruder laufen. In diesem Artikel zeigen wir dir, wie du Eigenschaften sauber anlegst, sinnvoll gruppierst und welche Feldtypen wann passen. Aus über 60 HubSpot-Projekten wissen wir: Wer Properties von Anfang an strukturiert, spart sich später monatelanges Aufräumen.
Was sind Properties in HubSpot eigentlich?
Eine Property — im Deutschen oft "Eigenschaft" genannt — ist ein einzelnes Datenfeld an einem HubSpot-Objekt. Jeder Kontakt, jedes Unternehmen, jeder Deal und jedes Ticket besteht aus dutzenden, manchmal hunderten solcher Felder. Vorname, E-Mail, Lifecycle Phase, Deal-Betrag, Ticket-Priorität: das alles sind Properties. Sie definieren, welche Informationen du über deine Kontakte und Unternehmen überhaupt speichern kannst.
HubSpot unterscheidet vier Standard-Objekttypen, die jeweils ihren eigenen Property-Satz haben: Contact, Company, Deal und Ticket. Eine Property, die du am Kontakt anlegst, existiert nicht automatisch am Unternehmen. Das ist wichtig zu verstehen, weil viele Teams dieselbe Information versehentlich an mehreren Objekten doppeln. Erst wenn du das Datenmodell verstanden hast, wird klar, an welches Objekt eine Information gehört.
Kernidee: Properties sind keine technische Spielerei, sondern dein CRM-Datenmodell. Jede schlecht benannte oder falsch platzierte Property kostet dich später Reports, Filter und Sales-Effizienz.
Was ist der Unterschied zwischen Default und Custom Properties?
HubSpot liefert pro Objekt mehrere hundert Standard-Properties mit — sogenannte Default Properties. Dazu gehören Klassiker wie First Name, Last Name, Email, Phone Number, Lifecycle Stage, Lead Status, Original Source und viele mehr. Diese Felder sind tief im System verankert: HubSpot füllt sie teilweise automatisch (etwa Original Source bei Formular-Submits) und nutzt sie für Standard-Reports, Workflows und die Integration mit anderen Tools.
Custom Properties sind alle Felder, die du oder dein Team selbst erstellt habt. Beispiele aus echten Projekten: "Branche", "Mitarbeiterzahl-Range", "Wunschtermin Erstgespräch", "DSGVO-Einwilligung Newsletter". Custom Properties sind extrem mächtig — aber genau hier passieren auch die meisten Fehler. In jedem zweiten HubSpot Audit, das wir machen, finden wir Custom Properties, die niemand mehr nutzt, doppelte Felder mit minimal anderem Namen oder Properties, die als Text angelegt wurden, obwohl ein Dropdown sinnvoller gewesen wäre.
Wie organisiere ich Properties mit Property Groups?
Wer mit 200+ Properties pro Objekt arbeitet, braucht eine Struktur. HubSpot bietet dafür Property Groups: thematische Container, in denen du verwandte Felder bündelst. Standard-Gruppen sind etwa "Contact Information", "Email Information" oder "Conversion Information". Du kannst aber jederzeit eigene Gruppen anlegen — und genau das solltest du tun.
In unseren Implementierungen erstellen wir typischerweise Custom-Gruppen wie "Vertriebsdaten", "Marketing-Consent", "Onboarding-Status" oder "Kundenservice-Felder". Der Effekt: Wenn ein Sales-Mitarbeiter einen Kontakt öffnet, findet er die Felder, die er wirklich braucht, sofort gebündelt. Und im Property-Editor sehen Admins auf einen Blick, welche Felder zu welchem Bereich gehören. Property Groups sind außerdem die Basis für saubere Formular-Strukturen und Imports.
Wie erstelle ich eine Property Schritt für Schritt?
Der Weg zu einer neuen Property ist immer derselbe: Einstellungen (Zahnrad oben rechts) → Properties → Create Property. Im ersten Schritt wählst du den Object Type — also ob die Property an Contact, Company, Deal oder Ticket hängen soll. Diese Entscheidung ist endgültig: Eine Contact-Property kannst du später nicht in eine Company-Property umwandeln. Überleg also vorher, an welches Objekt die Information logisch gehört.
Im zweiten Schritt wählst du die Property Group, vergibst ein eindeutiges Label (das, was später im UI angezeigt wird) und schreibst eine kurze Beschreibung, die erklärt, was in das Feld gehört. HubSpot generiert automatisch einen internen Namen aus dem Label — den solltest du im Auge behalten, weil er später in API-Calls und Workflow-Bedingungen auftaucht. Im dritten Schritt wählst du den Feldtyp und speicherst.
Klingt simpel — und ist es auch. Der Knackpunkt liegt nicht in der Klick-Strecke, sondern in den Entscheidungen davor: richtiger Object Type, richtige Group, richtiges Label, richtiger Feldtyp. Genau deshalb ist Property-Planung Teil jedes HubSpot Setup-Projekts. Wer Daten aus bestehenden Tools übernimmt, sollte sich vorab unsere HubSpot Importvorlagen ansehen — sie zeigen, welche Property-Struktur für einen sauberen Import nötig ist.
Welche Feldtypen gibt es und wann nutze ich welchen?
HubSpot bietet eine ganze Palette an Feldtypen. Die Wahl ist mehr als Kosmetik: Sie entscheidet, ob du das Feld später für Filter, Listen und Reports sauber nutzen kannst. Ein "Land" als freier Text ist eine Katastrophe für Reports — als Dropdown ist es ein verlässlicher Filter.
| Typ | Use Case | Beispiel |
|---|---|---|
| Single-Line Text | Kurze, freie Texteingabe ohne Auswahl | Spitzname, externe Referenz-ID |
| Multi-Line Text | Längere Notizen, Beschreibungen | Interne Notiz zum Kunden |
| Number | Numerische Werte für Berechnungen & Filter | Mitarbeiterzahl, Umsatz |
| Date Picker | Stichtage, Termine, Fristen | Vertragsende, Wunschtermin |
| Single Checkbox | Ja/Nein-Entscheidung | Newsletter-Opt-in, AGB akzeptiert |
| Dropdown Select | Eine Auswahl aus festen Optionen | Branche, Land, Lead-Quelle |
| Multiple Checkboxes | Mehrere Werte aus festen Optionen | Produktinteressen, Sprachen |
| Score | Berechneter Punktwert nach Regeln | Lead Score, Engagement Score |
Wie verbinde ich eine Property mit einem Formular?
Properties entfalten ihren Wert erst, wenn sie mit Daten gefüllt werden — und der häufigste Weg dafür sind Formulare. In jedem HubSpot Formular-Editor kannst du Felder per Drag-and-Drop hinzufügen. HubSpot zeigt dir alle existierenden Properties zur Auswahl. Wenn du ein Feld brauchst, das es noch nicht gibt, kannst du direkt aus dem Formular heraus eine neue Property anlegen — HubSpot fragt dich dann: "Existierende Property verbinden oder neue erstellen?"
Unser klarer Rat: Erstelle Properties nicht aus dem Formular heraus, sondern vorher über Einstellungen → Properties. Warum? Weil Properties, die im Formular-Flow entstehen, gerne in der falschen Group landen, generische Namen bekommen ("Frage 1") und niemand später weiß, wofür sie gut sind. Erst Property planen, dann Formular bauen — diese Reihenfolge spart dir Wochen Aufräumarbeit. Dieselbe Logik gilt übrigens für HubSpot Listen: Saubere Properties sind die Grundlage für präzise Segmentierung.
HubSpot Datenmodell aufsetzen lassen?
Wir planen dein Property-Modell, bauen Groups und implementieren das saubere Setup — bevor das Chaos beginnt.
Jetzt beraten lassen
Welche typischen Fehler vermeide ich bei Properties?
Drei Fehler sehen wir in fast jedem Audit. Erstens: Zu viele Properties. Teams legen jedes Mal eine neue Property an, wenn sie eine Information brauchen — ohne zu prüfen, ob es sie schon gibt. Nach zwei Jahren hat das CRM 400 Custom Properties, von denen 60 % leer sind. Die Sales-Übersicht wird unbenutzbar, weil niemand mehr findet, was wichtig ist.
Zweitens: Keine Property Groups. Wer Properties ohne Gruppierung anlegt, schiebt sie unbewusst in die Default-Gruppe "Other Information" — und genau dort verschwinden sie. Drittens: Falsche Feldtypen. Der Klassiker: "Branche" als Single-Line Text. Jeder Sales-Kollege schreibt etwas anderes ("IT", "It", "I.T.", "Software", "SaaS"), und am Ende kann niemand nach Branche filtern. Ein simples Dropdown mit 15 festen Optionen hätte das Problem von Anfang an verhindert.
Faustregel: Bevor du eine neue Property anlegst, suche 30 Sekunden, ob sie schon existiert. Bevor du einen Text-Feldtyp wählst, frag dich, ob 5 feste Optionen reichen würden. Bevor du speicherst, prüf die Property Group. Drei Checks, die 90 % der Property-Sünden verhindern.
Wie funktioniert Property Governance in größeren Teams?
In Teams ab fünf Personen reicht "alle dürfen Properties anlegen" nicht mehr. Du brauchst Governance: klare Regeln, wer Properties erstellen darf, wie sie benannt werden und welche Reviews es gibt. In unseren Enterprise-Projekten setzen wir typischerweise auf ein Property-Owner-Modell: Eine oder zwei Personen im Team haben Admin-Rechte und sind die einzigen, die neue Properties erstellen dürfen. Alle anderen reichen Anfragen über ein internes Ticket-System ein.
Dazu kommt eine Naming Convention: Alle Custom Properties bekommen ein Präfix nach Bereich, etwa "sales_", "marketing_", "service_". So sieht jeder im Property-Editor sofort, woher ein Feld kommt. Ergänzt wird das Ganze durch ein quartalsweises Property-Review: Welche Felder sind in den letzten drei Monaten gefüllt worden? Welche stehen leer? Was kann archiviert werden? Diese Disziplin trennt funktionierende CRMs von zugemüllten. Wer intern keine Kapazität für Property-Pflege hat, übergibt diesen Part oft an einen externen HubSpot Admin als Teil eines Retainers. Für die Umsetzung von Workflows, die auf Properties reagieren, lohnt sich ein Blick in unseren Artikel zu HubSpot Workflows.
Fazit: So baust du ein sauberes Property-Modell
Properties entscheiden, wie viel du aus HubSpot rausholst. Plane dein Datenmodell, bevor du Felder erstellst. Nutze Property Groups konsequent. Wähle Feldtypen so, dass du später filtern und reporten kannst. Vermeide Wildwuchs durch klare Naming-Regeln und einen Property-Owner. Und wenn dein bestehendes CRM schon im Property-Chaos steckt, hilft ein HubSpot Audit beim Aufräumen — oder ein komplettes HubSpot Setup, in dem wir das Datenmodell von Grund auf sauber aufbauen. Wenn du tiefer einsteigen willst, wirf einen Blick in unseren HubSpot Reports Workshop — dort zeigen wir, wie saubere Properties die Basis für verlässliches Reporting bilden.
Häufige Fragen zu HubSpot Eigenschaften
Wie viele Properties kann ich in HubSpot anlegen?
HubSpot erlaubt je nach Lizenz mehrere tausend Custom Properties pro Objekt. Im Starter-Tier sind es 100, in Professional 1.000 und in Enterprise bis zu 6.000 pro Objekt. Die Frage ist aber selten "wie viele kann ich" — sondern "wie viele brauche ich wirklich".
Kann ich eine Property nachträglich von Text auf Dropdown ändern?
Nein, der Feldtyp einer Property lässt sich nach dem Anlegen nicht mehr ändern. Du musst eine neue Property mit dem korrekten Typ erstellen, die Daten per Workflow oder Import migrieren und die alte Property anschließend archivieren.
Was passiert mit Daten, wenn ich eine Property lösche?
Beim Löschen einer Property gehen alle darin gespeicherten Werte unwiderruflich verloren. HubSpot empfiehlt deshalb, ungenutzte Properties zu archivieren statt zu löschen. Archivierte Properties verschwinden aus der UI, lassen sich aber bei Bedarf wiederherstellen.
Sind Custom Properties über die API verfügbar?
Ja. Jede Custom Property ist sofort über die HubSpot CRM API verfügbar — sowohl zum Lesen als auch zum Schreiben. Der interne Property-Name (nicht das Label) wird dabei als Feldbezeichner verwendet.
Was ist eine Calculation Property?
Calculation Properties sind berechnete Felder, deren Wert HubSpot automatisch aus anderen Properties ermittelt — etwa eine Differenz zweier Datumswerte oder die Summe mehrerer Zahlen. Sie sind in Professional- und Enterprise-Lizenzen verfügbar.
Wie verhindere ich, dass mein Team beliebig Properties anlegt?
Über die Berechtigungen: Nur User mit Super-Admin- oder bestimmten benutzerdefinierten Rechten können Properties erstellen. In größeren Teams empfehlen wir ein Property-Owner-Modell mit ein bis zwei Verantwortlichen plus Anfrage-Prozess für alle anderen.
