AI Marketing Engineer

Structured vs unstructured data: the marketing version

Your CRM fields and your customer reviews need different AI approaches. Here's how to tell them apart.

The distinction that matters is not structured versus unstructured. It is data you can filter and data you have to read, and marketing threw away decades of the second kind because reading it was impossible at any real scale.

That is the thing that actually changed. Not the definitions. Reading became affordable, and most marketing teams are sitting on years of customer voice they have never once looked at.

The two kinds, quickly

Structured data has a defined shape. Fields, types, rows. Your CRM, your ad platform exports, your transaction table. You can filter it, count it, sort it and join it, and the answer you get is exact.

Unstructured data has no shape you can query. Reviews, support tickets, sales call notes, survey free-text, chat logs, social comments, recorded calls. To know what is in it, something has to read it.

Marketing is unusual in how lopsided this is. The structured side is thin and heavily governed, maybe forty fields somebody argues about in a quarterly meeting. The unstructured side is enormous, ungoverned and mostly unread.

The category nobody teaches

There is a third kind and it does most of the damage. Semi-structured data: the free-text notes field. “Other - please specify.” Job title, with four hundred spellings of Head of Marketing. Lead source with forty variants of Web. Campaign names with no naming convention, entered by eleven people over six years.

This is where marketing data actually lives, and it is the worst of both worlds. It looks structured, so people filter on it. The filter is wrong, and it is wrong quietly. Nobody gets an error message. They get a number that is 30% short and a chart that looks fine.

[illustrative] A mid-size insurer, around 2022, with roughly 60,000 free-text cancellation reasons collected over four years. The commercial assumption was price. Reading a sample showed a large share described a specific step in onboarding that nobody in marketing had ever been told about.

I have never seen a marketing data audit where the semi-structured fields were not the biggest problem, and I have never seen one where they were the headline finding either.

What each kind needs

This is where AI advice goes wrong most often, so it is worth being blunt about it.

For structured data, do not use a language model. Use a query. An LLM asked to count things is a calculator made of guesses, and it will give you a confident total that is quietly wrong. If the question is “how many customers in this segment”, that is SQL, and it was SQL before 2022.

For unstructured data, a model is genuinely the right tool, and this is the real win. Extraction, classification, summarising at volume, spotting themes across sixty thousand comments. The trick is what you do with the output: turn it into structured fields. Category, sentiment, product area, root cause. Then you can filter it, and you are back on solid ground.

For semi-structured, use a model once to normalise the mess into real structure. Map four hundred job titles to twelve. Then treat it as structured and never look back.

Notice the pattern. Almost always the valuable move is converting unstructured into structured, not answering questions directly from the unstructured pile.

A stat to stop repeating

You will see a claim that 80 or 90% of enterprise data is unstructured, usually with a research house attached. I have tried to trace it more than once and never got to a primary source I would stand behind.

Do not put it in a board deck. The point stands perfectly well without it: you know roughly how many free-text fields you have, and you know roughly how often anyone reads them. That is a better argument than a borrowed number.

Where this gets blurry

Two honest caveats.

The line between the two is softening. Text-to-SQL tools let a model query structured data properly, by generating the query rather than guessing the answer, and that is a real and sensible use. My “do not use an LLM on structured data” rule is about arithmetic, not about access.

And “turn it into fields” loses things. Some of what customers tell you resists categorisation, and forcing sixty thousand comments into twelve buckets throws away the specific sentence that would have changed your mind. Keep the raw text. Read some of it yourself, with your own eyes, forever.

What to do first

Find your largest free-text field and count the rows. Read a hundred of them by hand and build a category list from what you actually see, not from what you expected.

Then have a model classify the rest against your list. The hundred you read yourself is not a shortcut you can skip - it is the part that makes the other 59,900 trustworthy.


Editing notes

  • The 80-90% unstructured-data stat is called out as unverifiable on purpose. I think that section is one of the stronger parts of the piece, but it is also the most likely to get cut, so flagging it deliberately.
  • [illustrative] on the insurer cancellation-reasons example. This one would be much stronger real - if you have a version of it from your own work, it is the centre of the piece.
  • Verify: nothing else in here depends on a date or a vendor claim, which makes this the safest of the four to publish quickly.
  • Cross-reference opportunity: the semi-structured section connects directly to “nobody owned the join” in the omnichannel piece.

← All field notes