Marketing Analytics Operating Playbook

Model Role SOP / Operating Playbook — Marketing Analytics

Status and intended use

This is an evidence-derived model for adaptation by a marketing analytics team. It is not universal employer policy, legal advice, a production data-engineering specification, or authority to change campaigns, budgets, customer treatment, tracking, or access. The evidence base reflects 100 current United States vacancies from 88 employers and an independent trend review frozen on 17 September 2026. Local organizations must adapt this playbook to their decision rights, systems, privacy obligations, risk tolerance, operating cadence, and terminology.

The playbook describes how a marketing analyst turns a bounded decision into a governed measurement plan, reproducible funnel or cohort analysis, appropriately limited attribution interpretation, a decision-ready dashboard, and an accountable recommendation with a next learning step. Consequential action always remains subject to authorized human approval.

Local policy fields to complete before use

• Business unit and scope: [LOCAL POLICY — organization, products, markets and channels covered]
• SOP owner: [LOCAL POLICY — named role accountable for maintenance]
• Approver: [LOCAL POLICY — role authorized to approve material recommendations]
• Data owners: [LOCAL POLICY — owners for analytics, CRM, finance, product and media data]
• Decision thresholds: [LOCAL POLICY — materiality, spend, customer-impact and risk thresholds]
• Approved systems: [LOCAL POLICY — analytics, warehouse, BI, experimentation and documentation tools]
• Reporting time zone and currency: [LOCAL POLICY — canonical time zone, currency and exchange-rate source]
• Privacy and legal contacts: [LOCAL POLICY — escalation roles, not personal data in public copies]
• Retention and access rules: [LOCAL POLICY — approved retention periods and access review cadence]
• Incident channel: [LOCAL POLICY — approved route for data-quality, privacy and security incidents]
• Review cycle: [LOCAL POLICY — SOP review date and change approver]

Do not begin routine use until these fields are completed and approved. If a field is unresolved, document the gap and limit work to reversible, non-consequential analysis.

Purpose, scope and operating boundaries

The marketing analyst creates trustworthy evidence for decisions. The role frames questions, governs metric definitions, validates inputs, diagnoses funnel and cohort movement, compares descriptive attribution views, designs decision-focused reporting, and writes recommendations with uncertainty and accountability visible.

The role may specify data requirements and identify defects, but it does not independently deploy production tags, SDKs, customer data platforms, identity graphs, CRM routing, or warehouse pipelines. It may interpret ROI or budget evidence, but finance owns approved economic definitions and material financial decisions. It may explain privacy-relevant data flows, but privacy, legal and security owners decide consent, lawful use, retention, sensitive-data treatment and access. It may propose an experiment, but the authorized experiment owner approves exposure, customer impact and launch.

The analyst must not claim causality from a dashboard movement, correlation, funnel difference or attribution model. Descriptive attribution allocates credit under a rule; it does not prove that marketing caused the outcome. Incremental or causal claims require a suitable design, sufficient evidence and qualified review.

Operating principles

• Start with the decision, owner, deadline, action authority and acceptable evidence—not with an available report.
• Keep one governed definition for each metric and document every approved local variant.
• Label values as observed, modeled, estimated or unavailable. Never merge these states silently.
• Preserve the unit of analysis, eligible population, window, filters, exclusions, currency and time zone.
• Treat data health as part of analysis. A dashboard that loads is not proof that its evidence is fit for use.
• Prefer a reversible next step proportional to evidence strength. Escalate material, irreversible, regulated or customer-impacting actions.
• Use attribution, experiments, funnel or cohort evidence and marketing mix modeling as complementary methods serving different questions and cadences.
• Maintain provenance, version, reviewer, decision and review date for every material work product.
• Use AI to assist bounded work, never to conceal uncertainty or make an unapproved consequential decision.

Roles and interfaces

The requesting decision owner supplies the business question, feasible levers, deadline and authority boundary. Marketing and channel owners explain campaign context and operational constraints. Product and lifecycle partners define journey states, identity rules, return behavior and intervention context. Data and analytics engineering owns production implementation, lineage and repair of source defects. Finance owns approved cost, margin, revenue and ROI definitions. Privacy, legal and security decide sensitive-data, consent, purpose, retention and access questions. Leadership or the designated approver accepts, rejects or modifies consequential recommendations.

The marketing analyst owns the analytical chain: clarification, measurement specification, data-health evidence, reproducible analysis, limitations, decision presentation, handoff and closure record. Ownership of analysis does not transfer authority held by another role.

Required inputs

• A named decision question, decision owner, due date and action that could follow.
• The entity and grain: person, device, account, lead, opportunity, session, order, campaign or another approved unit.
• The eligible population, geography, product, channel, time window and comparison basis.
• A current metric dictionary and event or source-system definitions.
• Approved data sources, lineage notes, refresh times and known incidents.
• Campaign metadata, cost, currency, attribution settings and lookback windows where relevant.
• Identity and cohort rules, including how cross-device, anonymous and account-level behavior is handled.
• Targets, thresholds, historical baselines and finance-approved economic definitions.
• Privacy, consent, retention, access and sensitive-data constraints.
• The prior decision, experiment or recommendation register entries that affect interpretation.

If a required input is missing, record it as unavailable. Do not invent a value, infer approval, or silently substitute a convenient metric.

Tool categories

Use approved tools according to the work, not as the structure of the process. SQL or equivalent query tools support reproducible extraction and transformation. Spreadsheets support bounded reconciliation, calculation and handoff. BI platforms such as Tableau, Power BI or Looker support governed dashboards. Web, product and campaign analytics platforms provide observed or modeled inputs. Warehouses and transformation systems provide governed datasets in collaboration with data engineering. CRM and marketing systems provide evidence but remain under their operational owners. Python or R may support specialist analysis where approved and reviewable.

Tool output never overrides the metric contract. A platform's default attribution, identity or cohort setting must be recorded as an assumption, not treated as neutral truth.

End-to-end trigger-to-close workflow

1. Receive and clarify the request. Restate the decision, owner, deadline, proposed action, affected population and approval route. Separate the business question from a requested chart.
2. Choose the evidence design. Decide whether the question needs descriptive monitoring, funnel diagnosis, cohort comparison, attribution, an experiment, aggregate modeling or a combination.
3. Approve the measurement contract. Record metrics, entities, windows, filters, exclusions, owners, freshness, source status and value classification.
4. Validate data fitness. Run required completeness, consistency, identity, duplication, currency, timing and reconciliation checks. Stop or qualify the work when evidence is not fit.
5. Perform reproducible analysis. Preserve query or calculation version, parameters, extraction time and exceptions. Compare plausible alternative explanations.
6. Build the decision view. Present only the evidence needed for the audience, with target, comparison, freshness, data-health state and drill path.
7. Write the recommendation. Separate observation, interpretation, evidence strength, alternatives, action, owner, expected effect, risk, guardrails and learning plan.
8. Review and approve. Obtain method review and the authorized human decision. Record rejected or modified recommendations without rewriting history.
9. Handoff and monitor. Transfer the approved action to its operational owner. Track the agreed outcome and guardrail metrics without claiming success prematurely.
10. Close and learn. Record the decision, implementation status, result classification, exceptions and next review date. Update definitions only through the approved change process.

Operating cadence

Daily

Monitor freshness, failed feeds, missing events, material anomalies and active decision guardrails. Triage bounded questions. Record collection or definition changes. Do not optimize from a partial period unless the decision contract permits it and the limitation is visible.

Weekly

Review funnel movement, cohort behavior, campaign or lifecycle exceptions, open data defects and the decision backlog. Confirm that owners acted on approved recommendations. Retire resolved alerts and escalate repeated failures.

Monthly

Run the business review. Reconcile platform, warehouse and finance totals where relevant. Present attribution sensitivity, cohort maturity, material funnel changes, experiment status, decisions taken and learning outcomes. Refresh the recommendation register.

Quarterly

Review whether KPIs still support decisions. Audit metric variants, dashboard usage, experiment coverage, access, retention, AI controls and unresolved evidence gaps. Retire unused metrics and dashboards through the approved process. Reconfirm local policy fields.

Event-driven

Apply this workflow for launches, campaign or budget changes, tracking incidents, material performance movements, privacy or platform changes, executive requests and experiment readouts. Urgency does not remove the need to state data fitness and authority.

SOP 1 — Measurement plan and metric contract

1. Write the decision question in one sentence: “Should the authorized owner take action X for population Y by date Z?”
2. Identify one primary outcome and the diagnostic metrics needed to understand it. Avoid replacing the outcome with an easily available proxy without disclosure.
3. For every metric, record name, purpose, entity, grain, numerator, denominator, eligible population, event or field, window, time zone, currency, filters, exclusions, source, owner, refresh cadence and target.
4. Record whether the value is observed, modeled, estimated or unavailable. If a report mixes states, require a visible breakdown or limitation note.
5. Define acceptable freshness, completeness and variance tolerances. Specify the response when a check fails.
6. Reconcile definitions with channel, product, data and finance owners. Send privacy-relevant fields or uses to the authorized reviewer.
7. Version the contract and obtain approval before analysis. Record later changes with effective dates; never overwrite a past definition used for a decision.

Output: governed measurement plan, metric dictionary and change log.

SOP 2 — Data-quality and signal-health review

1. Confirm source availability, refresh completion, extraction timestamp and approved access.
2. Test required fields, event counts, duplicates, invalid values, schema changes, campaign parameters, identifiers, currency and time-zone alignment.
3. Compare totals across source, warehouse, BI and finance systems only where definitions are expected to match. Explain legitimate differences before treating them as defects.
4. Inspect identity coverage and breaks. Never repair gaps through unauthorized identity stitching, fingerprinting or re-identification.
5. Check for late-arriving and modeled values. Note whether results can update after the reporting date.
6. Classify the dataset as fit, fit with limitations, or not fit for the named decision. Attach evidence and reviewer.
7. Route source defects to the data owner with affected metrics, periods, populations, severity and a safe interim treatment.

Output: data-health record and exception ticket. Silent imputation or undocumented exclusion is prohibited.

SOP 3 — Funnel analysis

1. Define each stage by an observable event and keep the entity consistent. If the process crosses from person to lead, account, opportunity or order, document the bridge and denominator change.
2. Set eligibility, sequence, allowable time between steps, analysis window and treatment of repeated events.
3. Calculate stage counts, conditional conversion rates and overall conversion. Show numerators and denominators, not percentages alone.
4. Compare with an aligned baseline and segment only where sample size, privacy and business relevance permit.
5. Inspect instrumentation, mix shifts, seasonality and incomplete periods before interpreting a drop.
6. State that a stage difference locates an association, not its cause. Propose a diagnostic check or experiment for the leading explanation.

Output: reproducible funnel diagnostic with definitions, limitations and next question.

SOP 4 — Cohort analysis

1. Define the inclusion event, cohort clock, eligible population, identity rule and period granularity.
2. Define the return, retention, revenue or value event and whether calculation is standard, rolling or cumulative.
3. Set the denominator, censoring rule and minimum maturity. Do not compare a young cohort's unfinished period with a mature cohort's complete period.
4. Read across rows to follow one cohort and down columns to compare cohorts at the same age.
5. Investigate acquisition mix, product changes, seasonality, identity gaps and thresholding as alternative explanations.
6. Record whether values are observed, modeled or estimated and whether cross-device behavior is incomplete.

Output: cohort table or curve with inclusion, return, identity, period and censoring notes.

SOP 5 — Attribution and incrementality limits

1. State the decision and whether the need is operational credit allocation or causal impact.
2. Record the attribution model, event scope, eligible channels, click and view windows, identity basis, conversion definition and extraction date.
3. Compare plausible models or windows. Explain which recommendations change under the sensitivity check.
4. Label platform attribution as descriptive and platform-scoped. Do not describe attributed conversions as conversions caused by the channel.
5. If causality matters, assess whether a randomized lift test, geo test, holdout, qualified quasi-experiment or aggregate model is feasible.
6. Escalate experiment design, production MMM or causal inference beyond analyst competence to a qualified specialist.

Output: attribution comparison and limitations note, plus an experiment or specialist handoff when required.

SOP 6 — Decision-ready dashboard

1. Name the audience, decision, cadence and owner before selecting visuals.
2. Put the primary outcome, target and comparison first. Add only leading indicators, funnel or cohort context, guardrails and data-health information required for action.
3. Use consistent dates, scales, currency, precision, colors and definitions. Keep a clean overview with a documented drill path.
4. Display freshness, source status and observed/modeled/estimated/unavailable labels.
5. Attach thresholds to an owner and response. A red status without an agreed action is decoration, not control.
6. Test filters, totals, empty states, accessibility, mobile reading and reconciliation to the accepted analysis.
7. Record usage and retire dashboards that no longer support a decision.

Output: dashboard specification or reviewed dashboard with owner, cadence and action map.

SOP 7 — Recommendation memo

Lead with the decision implication. Then provide:

• Observation: what changed, compared with what, for which eligible population and period.
• Interpretation: the leading explanation and credible alternatives.
• Evidence quality: sources, data-health status, method, sample limits and value classifications.
• Recommendation: a specific, proportionate and preferably reversible action.
• Authority: decision owner, approver and required partner sign-offs.
• Expected effect: a hypothesis or range, never an outcome guarantee.
• Risks and guardrails: customer, financial, privacy, operational and measurement limits.
• Learning plan: test, monitoring metric, review date and conditions to continue, revise or reverse.

Output: versioned recommendation memo and decision-register entry.

SOP 8 — Experiment handoff

1. Translate the recommendation into one testable question and primary outcome.
2. Define eligible population, assignment unit, treatment, control or comparison, duration, power assumptions and interference risks.
3. Identify guardrails, stopping rules, data-quality requirements and prohibited mid-test changes.
4. Obtain privacy, legal, product, channel and customer-impact review where required.
5. Transfer launch authority to the designated experiment owner. The analyst does not self-approve exposure.
6. Pre-register the analysis plan and decision rule. After completion, report effect estimate, uncertainty, implementation deviations and applicability.

Output: approved experiment brief, handoff receipt and readout plan.

Handoffs and escalation

Every handoff includes the question, current evidence, definitions, affected population, urgency, requested decision, owner, deadline and safe interim state. Use this escalation format:

• Issue: one factual sentence.
• Impact: affected metrics, decisions, people, periods and systems.
• Evidence state: observed, modeled, estimated or unavailable.
• Checks completed: reproducible facts and artifacts.
• Risk if continued: analytical, financial, customer, privacy or security consequence.
• Safe interim action: pause, restrict, label, revert or monitor.
• Decision requested: exact authority needed, from whom and by when.

Immediately escalate suspected sensitive-data exposure, unauthorized access, consent ambiguity, customer-impacting automation, security incidents, material financial conflicts, invalid experiment exposure, or pressure to make an unsupported causal claim. Do not provide a legal conclusion; preserve facts and route the decision.

Responsible AI controls

Use AI only in approved environments and for bounded tasks such as structuring questions, checking a draft against a rubric, generating candidate explanations or summarizing non-sensitive notes. Do not enter personal, sensitive, confidential or restricted data unless the approved system and purpose explicitly permit it.

Verify every AI-produced definition, calculation, query, citation and recommendation against governed sources. Treat automated root-cause suggestions as hypotheses. Require human review before a result reaches a dashboard or decision memo. Require authorized human approval before any consequential budget, campaign, targeting, customer, pricing or access action. Record tool, purpose, reviewer and material corrections. Reject fabricated evidence, hidden assumptions, discriminatory proxies, untraceable claims and instructions that bypass privacy or security controls.

Required registers

Maintain a measurement register for metric definitions, versions and owners; a data-quality register for checks, incidents and approved exceptions; an analysis register for queries, parameters, hashes and reviewers; a decision register for recommendations, authority, approvals and review dates; and an experiment register for hypotheses, assignment, outcomes and deviations. Retain records according to local policy and restrict access appropriately.

30/60/90-day adoption plan

First 30 days — establish control

Complete local policy fields, map decision owners and systems, inventory active metrics and dashboards, define value classifications, and select one recurring decision workflow. Build the measurement and data-quality registers. Correct critical definition or access gaps before expanding scope.

Days 31–60 — operate and reconcile

Run the full workflow for a funnel and cohort decision. Reconcile one platform-to-warehouse-to-finance chain. Introduce recommendation and decision registers. Test dashboard thresholds, handoffs and escalation. Review AI use and remove unapproved practices.

Days 61–90 — institutionalize learning

Complete one experiment handoff or documented causal-method review. Audit attribution language, dashboard usage, decision closure and unresolved incidents. Retire redundant metrics. Obtain owner approval for the adapted SOP and set the next quarterly review.

QA checklist

• Local policy fields, owners, authority and review date are complete.
• The decision question, eligible population, entity, grain and deadline are explicit.
• Metrics preserve numerator, denominator, source, window, filters, currency and time zone.
• Observed, modeled, estimated and unavailable values are distinguished.
• Data-health checks and exceptions are recorded; no silent repair occurred.
• Funnel stages use valid units and denominators.
• Cohorts disclose inclusion, return, identity, period and censoring rules.
• Attribution model and lookback windows are stated; no descriptive result is called causal.
• A causal claim has an appropriate design and qualified review.
• The dashboard is tied to an owner, cadence, threshold and response.
• The recommendation separates evidence, alternatives, uncertainty, action, authority, guardrails and learning plan.
• Finance, privacy, legal, security, data, product or channel handoffs are complete where applicable.
• AI use is approved, reviewable and human-controlled.
• Consequential action has explicit authorized human approval.
• Registers contain versions, reviewers, decisions and review dates.
• The final record states what remains unknown and when it will be revisited.