A Marketing Baseline Framework for Evidence-Led Decisions

A marketing baseline framework is a dated, reviewable model of the facts, interpretations, gaps, decisions, and constraints a team will use for a specific marketing horizon. It answers, "What do we currently have enough evidence to act on, what remains uncertain, and who owns the next review?" It is not a one-time health score, a complete marketing audit, or a frozen strategy.

Use the baseline after evidence collection but before many teams or tools create plans from conflicting context. The AI marketing audit guide owns end-to-end audit coverage. This framework owns the operating model that makes selected audit evidence reusable as of a known date.

What a baseline must make possible

A useful baseline lets a reviewer:

1. recover the source behind a material statement;
2. distinguish observation and calculation from interpretation;
3. see which evidence was unavailable or not measured;
4. understand the decision and time horizon that made the evidence relevant;
5. identify who approved the current state;
6. know what event or date requires review;
7. carry corrected context into the next brief without treating it as permanent truth.

The baseline is therefore both an evidence artifact and a decision-control system. Its value comes from how reliably it prevents silent assumptions from becoming shared facts.

Define the baseline charter

Begin with a short charter:

Decision horizon:
Decisions supported:
Business and market scope:
Products, audiences, and geographies included:
Evidence cutoff date:
Primary owner:
Required reviewers:
Excluded questions and sources:
Review cadence or trigger:

"Current marketing" is too vague. A baseline for choosing one quarter's priorities can use different scope from a baseline for entering a new region, reviewing a homepage, or planning a product launch.

Record exclusions before collection. If no private analytics, CRM, customer research, or financial data is available, state that boundary. Do not allow a public website baseline to imply that those questions were answered.

Use five connected layers

Layer 1: Canonical context

Canonical context contains the reviewed facts and scoped assertions needed across decisions:

• organization and product identity;
• released offers and conditions;
• priority audience and market for the horizon;
• approved positioning and claim boundaries;
• active competitor and substitute roles;
• goals, metric definitions, resources, and constraints.

"Canonical" means approved for current use, not universally true forever. Retain the source, owner, approval date, and review trigger for every high-impact field.

For objective public claims, FTC substantiation policy requires a reasonable basis before the claim is made. That makes claim evidence and approval part of canonical context, not a final copyediting check.

Layer 2: Evidence register

The register stores statements before they become recommendations.

Field	Purpose
Evidence ID	Stable reference used by decisions and documents
Statement	Neutral description of what the source supports
State	Observed, calculated, inferred, unavailable, or not measured
Source and scope	URL, system, property, segment, page, device, or account
Period and retrieval	When the evidence applies and when it was collected
Method	How a value or interpretation was produced
Confidence	Strength with a reason, not a mood
Limitation	What the evidence cannot establish
Owner	Person responsible for correction and review

The planned editorial-stock marketing evidence register template provides a copyable implementation. Its route is not live until it completes editorial review and publication.

For competitor context, SBA guidance supports combining public competitive analysis with direct market research. Store those source classes separately so a website observation does not become a customer-choice fact.

Layer 3: Evidence gaps

Treat gaps as first-class records:

Gap type	Example	Appropriate response
Unavailable	No qualifying CrUX field record for the scope	Preserve unavailable and choose another valid source if needed
Not measured	Customer switching reasons were not researched	Assign research or exclude the conclusion
Inaccessible	Analytics property access is not authorized	Obtain permission or narrow the decision
Conflicted	Product page and release contract disagree	Escalate to the responsible product owner
Stale	Competitor offer changed after retrieval	Refresh before a comparative decision
Insufficient	Three conversations cannot support a broad segment claim	Limit scope or collect more evidence

A gap can block a decision, reduce confidence, or become an explicit research action. It should never silently become zero.

Layer 4: Decision register

Connect evidence to an accountable choice:

Decision ID and title:
Question and horizon:
Evidence used:
Interpretation and confidence:
Alternatives considered:
Unknowns and gaps:
Chosen response:
Owner and contributors:
Expected outcome or learning:
Acceptance evidence:
Guardrail:
Review date or trigger:
Stop or revise condition:

This structure preserves disagreement. A team can accept the same observations and choose different actions because its constraints or risk tolerance differ.

Layer 5: Working outputs

Briefs, strategies, roadmaps, claims registers, content maps, and engineering tickets should reference the baseline rather than copy unsupported facts into new prose. Each output needs an as-of date and the evidence IDs behind material premises.

When a context field changes, affected outputs become review candidates. The model does not require automatic synchronization. A manual dependency field can still prevent a disproved claim from spreading.

Metric context also belongs in the baseline. Google explains that Search Console clicks and Analytics sessions represent different stages and are not expected to match exactly. Google Analytics attribution models distribute observed credit under defined rules; they do not automatically establish incrementality. Preserve those definitions and limitations before a report becomes a decision premise.

Separate state, confidence, and status

These dimensions answer different questions:

Dimension	Question	Examples
Evidence state	What kind of knowledge is this?	Observed, calculated, inferred, unavailable, not measured
Confidence	How strongly does the evidence support the scoped statement?	High with direct source; low with ambiguous sample
Review status	Has an authorized person accepted it for use?	Draft, under review, approved, disputed, retired
Decision status	What happened to the proposed response?	Proposed, chosen, blocked, deferred, rejected, completed

An observed page element can have high evidence confidence but remain unapproved company truth. An inferred audience can be approved as a working hypothesis while retaining an inferred state. A blocked decision should remain visible rather than being removed from the baseline.

NIST's AI Risk Management Framework supports documentation, accountability, and ongoing governance around AI-assisted decisions. Its Generative AI Profile adds relevant attention to provenance and evaluation. Adapt the controls to the consequence of the marketing decision rather than treating the framework as a product score.

Build the baseline in a disciplined sequence

1. Name the decision horizon

Choose the period and material choices. A baseline should not become an encyclopedia.

2. Approve critical identity and product facts

Resolve company name, product scope, current availability, audience hypothesis, and claim boundaries before generating strategy. The product positioning audit provides the full product-truth and message review.

3. Collect the minimum evidence set

Use public, provider, first-party, customer, market, and user-supplied sources only where they support the decision. Record scope and retrieval context.

4. Register gaps before synthesis

Ask which desired conclusions have no owning source. Narrow the decision or create research work rather than asking a model to fill the blank.

5. Form decision candidates

State alternatives, evidence, confidence, dependencies, and reversibility. Avoid a long recommendation list with no tradeoffs.

6. Approve a small portfolio

Choose work that fits resources and dependencies. Record what is deferred and what the team will stop doing.

7. Publish the as-of snapshot internally

Include the evidence cutoff, owners, excluded scope, and next review trigger in every working output.

Baseline quality tests

Test the system rather than its word count:

Traceability test

Can a reviewer move from a decision to each supporting statement, then to the source, scope, date, and method?

Contradiction test

Can the model store conflicting evidence without averaging it into a false consensus?

Missing-data test

Does an unavailable or unmeasured input remain visible through the decision and output?

Correction test

When a product owner corrects a fact, can the team identify affected claims, briefs, and decisions?

Handoff test

Can the recipient understand the decision, evidence, unknowns, owner, and acceptance condition without reopening the entire audit?

Expiration test

Does each time-sensitive item have a date or event that requires review?

The strategy review guide is a useful downstream control for checking whether generated outputs preserve these conditions.

Use review triggers, not a false promise of freshness

A baseline is an as-of record. Keep it useful through assigned triggers:

Trigger	Required review
Product or plan release	Capability, claim, offer, and documentation fields
Priority audience change	Positioning, competitors, content, and channel decisions
Repeated win-loss change	Competitor roles and proof needs
Migration or redesign	Website, search, measurement, and acceptance baselines
New material evidence	Affected interpretation and decisions
Source expiration	Refresh, retire, or preserve as historical evidence
Owner dispute	Mark disputed and prevent unqualified reuse

Do not call this continuous monitoring unless a released system actually performs it. Human review on an event or cadence is a valid operating model.

Illustrative application

A fictional software team is choosing a quarter's marketing priorities. Its public site names two audiences, its approved product scope supports only one current offer, CrUX field data is unavailable, sales notes mention a service substitute, and analytics has an event named "qualified" without a documented definition.

The baseline should not calculate one marketing score. It should:

1. preserve the two audience descriptions as observed public evidence;
2. record the priority audience as a decision requiring product and sales review;
3. mark field performance unavailable and retain lab diagnostics separately;
4. add the service as a substitute candidate with source and confidence;
5. block outcome reporting until the qualified-event definition is approved;
6. choose a small portfolio that resolves audience and measurement uncertainty first.

The operating value is not that the framework knows the answer. It makes the unknowns and sequence explicit.

Where Alesta fits

Alesta can establish the public-evidence layer of a baseline from a registered domain. Its current free workflow creates editable identity and Product Information, organizes bounded site, performance, and competitor evidence, and produces a Marketing Strategy working document from the same context.

Those outputs remain reviewable as-of material. They do not establish customer research, private commercial performance, resources, or recurring freshness. Use the lean-team quarterly planning use case to see how the public layer can seed a decision without replacing private discovery.

Operating rules

• Treat every baseline as of a stated date and scope.
• Preserve source states and gaps through every synthesis step.
• Require owner approval for product truth and public claims.
• Keep evidence confidence separate from decision preference.
• Record rejected and deferred options.
• Use scores only as transparent aids, never as truth.
• Review on meaningful events and retain history.

A marketing baseline earns trust when a team can see exactly what it knows, how it knows it, what it does not know, and why it chose the next action.