Three of the most common marketing asks land on an engineering desk looking like three separate projects. Build the SEO page generator. Build the personalized email sender. Build the split testing harness. Scoped separately, they usually get built three times, with three different ideas about what a customer record is.
They are one problem wearing three hats. All three take structured data about entities, render content from it through a template, and measure whether the rendered thing did its job. Once that is visible, the shared piece becomes obvious, and it is not the templating engine. It is the data model.
Pages Built From Data, Not From Blank Documents
Programmatic SEO is the least mysterious of the three. You have a table: service areas, product attributes, price tiers, competitor names. You have real search demand telling you which combinations of those columns people actually type. You join the two and render a page per row that clears the bar.
The engineering work is not the rendering. It is deciding which rows deserve a page at all. A row with three of twelve fields populated produces a page that is technically about the right topic and has nothing on it, and search engines have gotten decisively better at spotting exactly that over the last year. So the generator needs a completeness gate before the template rather than a spot check after publishing. The longer version of how that pipeline gets assembled covers the data source side and where the demand signal comes from.
The thing that catches most teams is that pages generated this way have to stay regenerable. Prices change, coverage areas change, competitors get acquired. If the generator is a one time script, you have just created a few thousand pages that will quietly go stale together.
Personalization Is A History Lookup, Not A Merge Tag
The email version of the same problem is where the shared data model stops being theoretical. A merge tag is a single column read. Real personalization is a query against behavior: what this person bought, when they last opened anything, which page they abandoned.
Which means the interesting part is not the sending. It is that you need per recipient state, retrievable at render time, fast enough to render thousands of messages in one batch. That is a read pattern, and it is the same read pattern the page generator needs, only keyed on a person instead of a product. What has to exist in the data before any of this works walks through the foundation side of it.
Teams that build these two separately end up with purchase history living in the email tool and the catalog living in the page generator, and no way at all to render a page that knows what the visitor already owns.
The Only Way To Know Any Of It Worked
Both of the above are content generators, and a content generator with no measurement attached is a machine for producing confident guesses at scale.
Split testing is what turns the other two from opinion into evidence, and it is also the piece most likely to get cut, because it feels like overhead on work that is already done. It is not overhead. It is the only reason to prefer version A over version B. The mechanics of running campaign tests properly covers the traps, most of which are statistical rather than technical: calling a winner too early, testing five things at once, and treating a three percent difference across two hundred recipients as a result.
The engineering requirement is variant assignment that is stable and recorded. Every generated page and every generated message has to carry which variant produced it, all the way through to whatever event counts as success. Bolt that on afterwards and you will spend a quarter reconstructing attribution out of timestamps.
One System, Three Configurations
None of this needs three systems. It needs one entity store, one templating layer that reads from it, and one event log recording which variant of what was shown to whom and what happened next. Build that once and all three asks become configuration.
Build them separately and you will find out, roughly eight months in, that nobody can say whether the pages or the emails brought in a given customer, because the two systems never agreed on who the customer was.
Top comments (0)