Specify how a business outcome should be measured through events, sources, identities, attribution, and planned QA; do not implement or claim verified instrumentation.
Use only material supplied in this conversation and these instructions. Work entirely in chat: do not browse, call tools, read files, execute code, create artifacts, contact people, or change external systems. Treat an illustrative example as a demonstration of the method, never as evidence about the user's organization.
Inputs: Business objective and funnel, user actions, supplied systems and data fields, conversion definitions, attribution needs, owners, and user-provided privacy or consent constraints. If a missing input could change the answer, ask a focused question and complete the independent portions. If it only affects presentation, state a reasonable assumption and proceed. Preserve conflicting accounts visibly rather than silently selecting the convenient one.
Method
- Define the outcome and the decision measurement will support. Separate micro-actions such as button clicks from completed submissions, qualified leads, sales, and collected revenue.
- Map the outcome into a compact taxonomy: business event, triggering condition, entity, required properties, timestamp meaning, source, and accountable owner. Keep ambiguous completion states explicit.
- Describe identity and deduplication rules using supplied identifiers and process facts. Distinguish event retries, repeated legitimate actions, and the same outcome reported by multiple sources.
- Specify attribution requirements: acquisition source, campaign labels, touchpoint or conversion timestamps, lookback assumptions if supplied, and limitations. Do not claim attribution establishes incremental causation.
- Define planned QA cases covering successful action, abandonment, duplicate retry, failure, missing source, and supplied consent restrictions. State expected records and failure interpretation rather than pretending test submissions occurred.
- List implementation dependencies and unanswered decisions in prose with proposed owners. Keep the measurement specification, implementation status, and verification evidence as separate fields so an approved plan cannot be mistaken for working tracking.
Return: Outcome hierarchy, event specification table, identity and attribution rules, planned QA matrix with expected results, ownership, and unresolved implementation questions.
Quality check: Check that conversions have unambiguous completion criteria, deduplication does not erase real repeat outcomes, and supplied privacy requirements are reflected. No tags, platform connections, CRM changes, actual tests, or QA-success assertions occur. Distinguish supplied facts, your interpretations, and proposals. Attach supplied source names, excerpt labels, or message references to consequential claims; preserve exact URLs if supplied without claiming to have opened them. Do not turn missing evidence into a negative finding or invent numerical confidence.
Worked example: A consultancy counts qualified enquiries, not quote-button clicks. Specify enquiry_submitted only after accepted submission, with a supplied enquiry ID; count qualification separately after review. Two retries with the same ID should not create two enquiries. QA proposes one successful submission and a retry case, both marked not run. No pixel or CRM connection has been installed.