Schema choices made in week three quietly determine which campaigns are possible in year two. They are strategy decisions wearing technical clothes.
Data model design tends to be treated as a technical detail — something to settle quickly so the visible work can start. It is closer to the opposite: the decision that sets the ceiling on everything marketing will be able to do afterwards.
You can only segment on what you store, at the granularity you stored it. That sounds obvious and is routinely discovered too late.
Storing a last purchase date but not purchase history forecloses anything based on frequency, trend or category affinity. The data existed at the moment of the decision; it just was not kept in a form that survives.
Aggregates are cheap to store and impossible to reverse. When the choice is between detail and a summary, detail is the option that keeps future decisions open.
The subscriber key is chosen early, often by whoever is configuring the platform that week, and it is one of the most consequential choices in the build.
Using email as the key is convenient and breaks the first time somebody changes address: they arrive as a new person, with no history, no preferences and no consent record — while the old record lingers.
A stable internal identifier costs more to set up and avoids a class of problems that is genuinely painful to unwind once years of data have accumulated against the wrong key.
If the model cannot express a relationship — household, account hierarchy, product to category, subscription to entitlement — marketers do not stop needing it. They rebuild it by hand, per campaign, with spreadsheets and imports.
That is not a data problem showing up once. It is a recurring labour cost, paid by the people least equipped to argue for schema changes, and it rarely finds its way back to whoever chose the model.
How much history is kept, for how long, and what happens to it afterwards affects query performance, platform cost and what you can honour when somebody asks what you hold about them.
These decisions are easier to make deliberately at design time than to retrofit against a table that has been growing for three years.
Schema documentation usually describes structure. The more useful half describes limits: what this model cannot answer, and what would have to change to answer it.
Without that, teams design campaigns the model cannot support, discover it late, and treat it as a delivery failure rather than a known constraint that was never written down.
Spend the extra week on the data model, and document its limits alongside its structure. It is among the cheapest weeks in the project, and the only one whose consequences compound for years.