Insights

The Marketing Input Map

Map the evidence, facts, constraints, and priorities each marketing decision requires, then show where every input originates, how it changes, and what happens when it fails to arrive.

A campaign brief arrives late because the customer evidence is missing. The launch message changes because a product condition surfaced after review. A page keeps an old claim because nobody knew which system held the current fact.

Those failures look unrelated when the company organizes the problem by tool or team. They become one operating problem when the work is mapped by input.

The marketing input map shows what a decision needs, where each input begins, what changes before it arrives, and who can repair the path when it fails.

Start With a Decision, Not the Software Stack

A map of CRM, call-recording, support, analytics, and project-management tools may be technically accurate and still tell marketing almost nothing.

Begin with one work object or decision: approve a homepage claim, write a campaign brief, choose an audience, revise a proof section, or prepare a launch message. State what must be known before that decision can be made well.

This reverses the usual mapping exercise. The map includes a system only when it supplies a required input. A large platform may contribute one field. A short customer passage may change the entire decision.

Separate Inputs That Do Different Jobs

Do not put every piece of context into one evidence category.

Customer evidence shows what buyers or customers said, did, requested, or rejected. Company facts define what the product, service, policy, or offer can truthfully claim. Constraints limit the work through budget, timing, permission, capacity, or channel rules.

Priorities state what the company has chosen to pursue. Performance evidence shows what happened after earlier work reached the market.

These inputs can disagree without any source being wrong. A customer may want a capability the product does not have. A campaign may perform well against a company priority that has since changed. The map should preserve those distinctions until a decision is made.

Map the Origin, Not the Forwarded Copy

An input often reaches marketing as a pasted message, meeting note, or slide. That is the delivery artifact, not necessarily the source.

Trace the input back to the event and authoritative record. A lost-deal summary may originate in a call passage. A product fact may originate in release documentation. A leadership priority may originate in a dated decision record rather than the latest retelling.

Google Cloud describes data lineage as a record of where data comes from, where it moves, and which transformations occur along the way. The same discipline applies here even when the input is qualitative. See the official data lineage documentation.

The input map should let a reviewer move from marketing work back to the original evidence without treating the latest summary as the record.

Record Every Material Transformation

Marketing rarely receives an untouched source. A transcript becomes a tagged objection. Several tickets become a support theme. Product documentation becomes an approved claim. Analytics events become a conversion measure.

Name the transformation and the rule behind it. Record whether it was generated, reviewed, or revised by a person or system. Preserve the version used by the current work.

W3C PROV-O provides a useful model for this separation through entities, activities, and agents. It also supports derivation, attribution, and revision relationships. See the official PROV-O specification.

The goal is not to reproduce a technical provenance system inside a marketing document. The goal is to stop a classified or summarized input from silently replacing what it came from.

Give Every Input a Small Operating Record

Each mapped input needs enough detail to be usable and repairable.

Record the source event, authoritative record, transformation, owner, freshness threshold, arrival mode, destination, permission state, and fallback. Keep the current status separate from the definition of the input.

The owner is responsible for the path, not necessarily for creating the source evidence. A marketing operations owner may maintain the route from call transcripts while sales still owns the conversation.

Define Freshness According to the Decision

Freshness is not one company-wide number.

A legal policy may remain current until it changes. A launch dependency needs confirmation before the launch window. An emerging objection may matter only if it reaches the campaign team before the next revision.

Set a maximum useful age for the input inside the named decision. Then show last confirmed time, expected refresh pattern, and the condition that makes the record stale.

Google Cloud's data-quality guidance treats freshness as whether information was updated recently enough to be useful. It also separates completeness, consistency, validity, and accuracy. Those distinctions prevent a current record from being mistaken for a complete or correct one. See the official data-quality dimensions.

Name the Arrival Mode and Destination

An input can arrive as a direct record, an alert, a scheduled brief, or a review queue. Choose the mode according to urgency and ambiguity.

A verified product correction may update an approved fact record directly. A possible language pattern may belong in a review queue. A monthly source-coverage change may belong in the voice-of-customer brief.

Name the destination precisely. "Marketing" is not a destination. The campaign brief, page record, proof backlog, audience decision, or dashboard review is.

Write the Failure Behavior Before Automating

Every important input path eventually fails. A source can be unavailable, a transformation can break, permission can change, or the owner can miss a review.

Decide what the work should do when the input is missing or stale. It may block publication, preserve the last confirmed value with age visible, open a review task, or continue while marking the limitation.

Do not let an empty field silently become approval. The failure behavior should match the consequence of being wrong.

Expose Shared Inputs and Single-Point Failures

One input may support several marketing decisions. That makes the path valuable and fragile.

A current product fact may feed the website, sales asset, campaign brief, and launch page. If every destination depends on one person forwarding an update, the map has found a single-point failure.

Shared inputs deserve stronger ownership, observable age, and a reusable destination record. Repeated manual requests are evidence that the company has identified a real input but has not built its route.

Use the Map to Choose What to Automate

Do not automate every line on the map. Prioritize paths with a clear source, repeated demand, high decision value, and a manual transport step.

The article on what should reach marketing automatically provides the delivery gate. The capturing and routing distinction shows why finding an input does not determine where it belongs.

Some paths should remain reviewed. A leadership tradeoff, uncertain customer pattern, or claim with restricted evidence needs judgment even when the source arrives automatically.

Turn the Current Map Into a Build Sequence

Mark missing inputs, manual transfers, stale paths, unclear owners, and destinations that consume conflicting versions. Rank them by the decision they delay or weaken.

GOV.UK's guidance on mapping a user's whole problem recommends showing touchpoints, backend processes, involved people, and required evidence so teams can find dead ends and broken joins. The same logic applies to the internal path that supports marketing work. See the official service mapping guidance.

Choose one high-value path and rebuild it end to end. Confirm that the source, transformation, destination, and fallback work before adding another.

Keep the Map Attached to the Operating System

A static workshop diagram will age as soon as tools, owners, and decisions change.

Northstar's Listening Engine uses the map to define sources, transformations, delivery rules, and review conditions. The Glass Dashboard shows whether required inputs are present, current, attributable, and owned when the work is reviewed.

The useful map is not the one with the most systems. It is the one that shows exactly why a marketing decision can proceed, where it will fail, and who can repair the path.

Frequently asked questions

What is a marketing input map?

A marketing input map shows which evidence, facts, constraints, and priorities a marketing decision or work object requires. It records each input's origin, transformation, owner, freshness requirement, destination, and failure behavior.

How is an input map different from a software architecture diagram?

A software diagram starts with systems and integrations. An input map starts with a marketing decision, then includes only the systems and handoffs that supply something the decision needs.

Which marketing work should be mapped first?

Start with a current decision that is delayed, frequently revised, or made from stale information. Examples include a campaign brief, homepage claim, launch message, proof asset, or audience decision.

What input fields belong on the map?

Record the input definition, source event, authoritative record, transformation, owner, freshness threshold, arrival mode, destination, permission state, and fallback when the input is missing.

How should freshness be defined?

Define freshness according to the decision. A product fact may stay useful for months, while a campaign response or emerging objection may lose value within days.

How does an input map reveal automation priorities?

It exposes inputs that are valuable, repeatedly requested, available in a source system, and currently moved by a manual handoff. Those paths are strong automation candidates.

How does Northstar Stack use the input map?

Northstar uses the map to define Listening Engine sources, transformations, and delivery rules. The Glass Dashboard shows whether required inputs are current, attributable, owned, and present when the work is reviewed.