ow Much of a Programmatic Trader’s Workflow Can Excel Handle?

How Much of a Programmatic Trader’s Workflow Can We Rebuild in Excel?

I didn’t set out to answer this as a thought experiment.

I built it. Then I used it.

Order forms came in. Naming conventions were already defined for how campaigns, ad sets, line items, and ads needed to be structured. Excel took the order details, applied those rules, generated the campaign structure, and transformed those inputs into what I needed to actually build the campaigns.

Sometimes that meant populating a platform-specific bulk-upload template.

Sometimes it meant producing a structured trafficking sheet that told me exactly what needed to be entered manually.

Either way, the interpretation work had already been done.

Then I could QA hundreds of campaign components at once instead of reviewing every build from scratch.

So the more accurate question isn’t really how much could Excel handle?

It’s:

How much of the operational layer around programmatic trading can be turned into a system?

Quite a lot.

The Operational Layer Nobody Hires a Trader For

A surprising amount of a programmatic trader’s day can disappear into production work.

Reading an order.

Interpreting requirements.

Naming campaigns correctly.

Building line items that follow the same structure with small, campaign-specific differences.

Entering targeting, budgets, dates, creatives, IDs, and settings.

Formatting a bulk-upload template when one is available.

Checking pacing.

Finding campaigns that are behind, ahead, or approaching budget exhaustion.

Reconciling what several platforms call the same metric.

Preparing reporting that someone else needs to understand.

None of those tasks is meaningless. They are necessary.

But much of that work is also repetitive, rule-based, and structurally predictable.

And that matters.

Industry research has repeatedly pointed to the operational burden surrounding programmatic trading: traders often work across several platforms while spending substantial time on manual reporting, campaign adjustments, and other repeatable tasks.

That isn’t simply a productivity complaint.

It is time that could otherwise be spent analyzing performance, testing strategy, understanding audiences, and making better decisions.

I decided to stop performing as much of that work manually as I reasonably could.

So I built a system around it.

Stage One: The Order Form Becomes the Input Layer

Automation does not begin with the DSP.

It begins with the order.

If the information required to build a campaign is scattered across emails, documents, notes, and conversations, the person trafficking the campaign has to interpret that information before anything can be automated.

So I treated the order form as structured data.

Budget.

Flight dates.

Objective.

Targeting.

Geography.

Creative requirements.

Platform.

Tactic.

Audience information.

And, importantly, every variable required by the naming convention.

Once those inputs exist as structured fields, the naming convention stops being something a person manually constructs for every campaign.

It becomes a rule.

The system takes the order details, applies the naming logic, and produces the campaign, line-item, ad-set, and ad names that downstream processes expect.

That naming convention is not cosmetic.

It becomes an identifier that lets trafficking, QA, reporting, and analysis refer to the same campaign in the same way.

I don’t build the names for 500 campaigns.

I build the rule once. The system builds the names.

And that leads to another important lesson:

The quality of the automation depends on the quality of the order form.

If geography matters to setup, geography needs to exist as structured input.

If an audience requires a particular segment ID, that needs to be captured upstream.

If the platform requires a frequency cap, the order cannot leave that decision ambiguous.

If a creative assignment matters, the relationship needs to be defined before trafficking begins.

You cannot reliably automate information that was never properly collected.

Stage Two: Trafficking Is a Translation Problem

Every platform expects campaigns to be built differently.

Different fields.

Different naming structures.

Different targeting inputs.

Different budget logic.

Different representations of dates, IDs, creatives, audiences, and settings.

Sometimes the platform provides a bulk-upload template.

Sometimes it does not.

Sometimes a bulk tool exists, but manual trafficking is still the more practical execution method.

That distinction matters less than it might seem.

Because the real problem is not whether someone eventually clicks Upload or enters the values through a platform interface.

The real problem is translating the order correctly.

Once the campaign plan exists as structured data, Excel can translate that plan into the exact build specification required by the destination platform.

For a platform that supports bulk trafficking, the output might be:

a completed upload template.

For a manually trafficked campaign, the output might instead be a structured build sheet containing:

Campaign Name

Line Item / Ad Set Name

Budget

Flight Dates

Geo

Audience

Device

Bid Strategy

Frequency Cap

Creative Assignment

Landing URL

Tracking

Platform-specific settings

The execution method changes.

The source of truth does not.

That is the key.

The trader no longer has to repeatedly reinterpret the original order while moving from one campaign to the next.

The system has already converted the order into build-ready instructions.

Stage Three: QA Moves Upstream

This may be the most important part of the whole system.

If campaign creation is driven by structured input and defined rules, QA no longer has to begin after everything has been manually entered.

It can happen before activation.

The workbook can ask:

Does every campaign have a start date?

Does every campaign have an end date?

Do line-item budgets reconcile to the total campaign budget?

Does the naming convention match the expected structure?

Is required audience information present?

Does the tactic have an appropriate creative type?

Are required IDs missing?

Do campaign dates fall inside the order dates?

Is required tracking present?

Are platform-specific fields complete?

Now QA works whether the final campaign will be bulk uploaded or manually trafficked.

That is important.

Because the system is not merely checking the format of an upload file.

It is validating the campaign build itself.

Instead of visually reviewing hundreds of independently constructed rows and hoping to spot an anomaly, you can validate whether the same rules were applied correctly across all of them.

The objective becomes less:

Find the mistake after someone makes it.

And more:

Design the process so fewer mistakes can be created in the first place.

Stage Four: Activation Becomes the Execution Layer

At this point, the campaign is ready to build.

For some platforms:

Generate template → Upload → Review → Activate

For others:

Generate build specification → Enter → Verify → Activate

The human is still involved where the platform requires human interaction.

But the human is no longer responsible for remembering every rule.

That is a major difference.

Manual entry does not automatically mean manual decision-making.

If the workbook has already determined the correct name, budget, dates, targeting, creative assignment, and required settings, the trader is executing a prepared specification rather than reconstructing the campaign from the source order.

That makes manual trafficking faster.

More importantly, it makes it more consistent.

Stage Five: You Can’t Monitor What You Haven’t Standardized

Once campaigns go live, the problem reverses.

Now the platforms start sending data back.

And they do not all send it back the same way.

One platform says:

Spend

Another:

Amount Spent

Another:

Media Cost

Campaign hierarchies differ.

Headers differ.

Dimensions differ.

Naming differs.

So the same architecture I described in The Death of a Workbook becomes useful again:

SOURCE

↓

MIRROR

↓

VALIDATE

↓

NORMALIZE

↓

COMBINE

Raw platform exports remain raw.

Then the fields required for analysis are mapped into a common structure.

Once that happens, the downstream workbook does not need completely different logic for every platform.

It can understand:

Date

Platform

Campaign

Tactic

Impressions

Clicks

Spend

Conversions

regardless of what the original platform called them.

Everything that follows—pacing, campaign health, optimization, reporting—depends on this layer being trustworthy.

That is why normalization happens before the dashboard.

Stage Six: Pacing Should Tell You Where to Look

Pacing is inherently repetitive.

Budget.

Spend to date.

Flight dates.

Days elapsed.

Days remaining.

Expected delivery.

Actual delivery.

Required daily spend.

Projected final spend.

Those are calculations.

Once the campaign data underneath them is standardized, there is little reason for a trader to manually inspect every campaign just to determine which ones require attention.

The workbook can calculate that.

Instead of opening forty campaigns and asking forty times:

How is this pacing?

the system can surface:

6 campaigns require attention.

Maybe one is underpacing.

Another is projected to exhaust its budget early.

Another has barely delivered despite being halfway through its flight.

Another is technically pacing correctly but its primary KPI has deteriorated.

Now the trader has somewhere useful to point their attention.

The workbook does not replace the trader’s judgment. It prioritizes where that judgment is needed.

That is the role automation should play.

Stage Seven: The Dashboard Is the Last Layer, Not the First

Eventually, someone needs to understand what happened.

A trader.

An account manager.

A client.

Leadership.

That is where the dashboard comes in.

But I deliberately think of the dashboard as the last layer.

Not because visualization matters least.

Because it depends on everything underneath it being right.

A beautiful pacing chart built on inconsistent campaign names is still wrong.

A perfect KPI card built on duplicated Spend is still wrong.

A dashboard combining three platforms without normalizing their definitions is just presenting inconsistent data more attractively.

The visualization exists because someone needs to understand something.

It only works because the architecture underneath it was designed first.

Build the dashboard last.

What Excel Did Not Replace

This distinction is important.

Excel did not replace the DSP.

It did not decide which impression to bid on in milliseconds.

It did not replace auction mechanics, inventory access, platform optimization algorithms, identity infrastructure, verification, or bidding engines.

I did not rebuild ad tech.

I rebuilt a meaningful portion of the operational layer surrounding it.

The order intake.

The naming.

The campaign construction.

The build specifications.

The bulk templates where applicable.

The manual trafficking instructions where necessary.

The QA.

The data normalization.

The pacing.

The reporting.

Those are very different claims.

And the second one is much more interesting to me because those are precisely the processes where a large amount of human time can quietly disappear.

Why Excel?

Excel is already there.

That matters.

I did not need to wait for engineering to build an internal application.

I did not need to purchase a new workflow platform before testing whether the process could work.

I did not need to migrate an entire operation just to model the business rules.

I could define the logic in a tool I already had, test it against real campaigns, identify where it broke, and improve it as the workflow changed.

That does not make Excel the correct solution for every problem.

It makes it an unusually powerful environment for prototyping and operationalizing structured business logic.

And sometimes the workbook that begins as a prototype becomes capable enough to do the job itself.

Build Once. Trade More.

This is where I’m taking the next stretch of work on this site.

I want to take the systems I built for my own workflows and turn them into a connected suite for programmatic traders.

Programmatic Campaign Builder

Order → Validate → Build → QA → Activate

Turn structured campaign orders into validated, platform-ready build specifications for either bulk upload or manual trafficking.

Programmatic Data Hub

Ingest → Mirror → Normalize → Validate → Combine

Turn inconsistent platform exports into one trusted campaign dataset.

Trader Control Center

Monitor → Prioritize → Diagnose → Optimize

Surface pacing issues, campaign-health signals, forecasts, and optimization opportunities.

Interactive Performance Dashboard

Analyze → Filter → Compare → Explain

Turn the normalized dataset into interactive campaign analysis and reporting.

Four applications.

One architecture underneath them.

And one principle connecting all of it:

Enter the information once. Define the rule once. Let everything downstream inherit it.