Armakuni Contact us
← All case studies

Every client named its columns differently.
Every difference became a fix by hand.

A U.S. marketing intelligence agency measures TV, radio, digital and weather-driven demand for advertisers, and every client's data arrived with different column names, on a slow front end with charts clients couldn't question. We rebuilt the front end, used Claude 3.5 Sonnet to map each client's fields into one schema while the attribution stays in code, and let clients ask their charts questions.

Before

The data arrived in a different shape every time.

Clients couldn't interrogate the answer.

After
7,000 → 700,000records the platform can process
90%fewer data errors
  • A faster front end, where a client can ask a chart a question, get a summary of it or set it beside another.

As the agency reported.

The data arrived in a different shape every time

The agency helps advertisers see what their spending actually does across television, radio, digital channels and weather-sensitive demand, using attribution and demand forecasting. Its clients sent data with column names that varied widely, so every dataset needed manual corrections before anything downstream could run, and errors and delays crept in.

And clients couldn't interrogate the answer

The front end was slow, and its charts offered little to interact with. Clients could look at a chart, but couldn't ask it why, compare two views side by side or get a summary, so decisions and reports took longer than they should.

A model matches the column names and code does the maths

The design drew one line through the work. Spotting that two differently named columns mean the same thing is what a model does well, so the model maps the fields. The attribution calculations are business logic, and they stay in code, where they can be tested and trusted.

How we built it

3 decisions, in the order we made them. Each one says what we did and why, with what it did drawn beside it.

  1. Sonnet maps the fields; application logic calculates attribution
  2. A front end built to be questioned
  3. Measuring what TV and the weather actually did

Sonnet maps the fields; application logic calculates attribution

Built withBedrockClaude 3.5 Sonnet
Client columnsOther namesOther labels One schema then code, not the model, calculates
The engineering
  • A Bedrock microservice using Claude 3.5 Sonnet maps inconsistent column names for selected client datasets into the schema expected downstream.
  • That normalization step removes the repeated manual corrections before downstream processing.
  • Attribution calculations remain application logic, untouched by the model.
  • The implementation scope called for checks against business rules and against unsupported model output before wider coverage.

Why: when a model decides what a column means, someone can check it in seconds. Nobody can check a model's view of what a TV spot was worth.

A front end built to be questioned

Built withReactAmplifyFastAPILambdaAPI GatewayS3
Ask this chart a question AI summary of the chart compared side by side

“Armakuni goes above and beyond to deliver and copes with mistakes instead of hiding them.”

A reviewer, a marketing services company
The engineering
  • React and AWS Amplify support a rebuilt front end, with more responsive charting and interaction for the key modules, attribution and weather forecasting included.
  • Clients can ask questions of a chart, read its AI summary and compare results side by side.
  • Behind it, a centralized FastAPI backend replaced services that had been managed directly in AWS, as separate Lambda functions, API Gateway routes and S3 buckets with no central code repository, so the front end talks to one backend the team can version and test.

Measuring what TV and the weather actually did

What they actually didTV and radioweb visits afterWeatherleads predicted
The engineering
  • A new microservice-based module measures website activity after television and radio campaigns, with custom charts making the relationship visible.
  • A separate weather module uses weather and campaign-spend data to predict leads, as a proxy for demand, so clients can plan ahead. It has been built for some clients, with other clients' implementations in progress.

What we'd tell another CTO

1Use the model to match and code to calculate: field mapping is a model job, and attribution isn't. Check model output against business rules before anything downstream uses it, and bring each new client's data in only after validation, because one bad mapping spreads.
2Let clients question their charts, since a summary and a follow-up beat a static dashboard, and treat a proxy as a proxy. Predicted leads stand in for demand, and the copy should say so.

What else changed

As the agency reported.

  • A TV and radio impact module and a weather-driven lead prediction module, the latter live for some clients.

What comes next

The weather module for the remaining clients, and field mapping extended to more client datasets once each is validated.

How we'd do it today

This project came before our current offers. Here's how we'd approach the same work now.

Column mapping is a narrow, repetitive task, so AI Inference Engineering would give it a model the agency owns on Amazon SageMaker AI, at about a tenth of the price, with the hard cases still going to a frontier model through Amazon Bedrock. On AK AI Factory, every mapping someone already corrected by hand would become the golden set each change must pass, plus a sealed set nobody tunes to, and Axiom would keep one catalogue on Amazon DataZone, so every AI agent and every chart reads "lead", "spend" or "lift" the same way.

Have a problem like this one?

A free workshop: a few hours with the architects who'd do the work, on your own systems. No cost.

Book a free workshop