# Meta Measurement Framework v1.0 ## Enterprise Operating System Guide **Purpose:** Enterprise framework for designing, implementing, validating, governing, interpreting, and improving measurement across Meta advertising activity. **Companion guides:** Meta Setup & Activation Guide, Signal Quality & Identity Guide, Reach & Frequency Guide, Optimization Guide, Attribution & Incrementality Guide, Testing & Experimentation Guide, Creative Strategy Guide, Reporting & Insights Guide, and Troubleshooting & Root Cause Guide. **Core rule:** Tracking records signals. Attribution allocates credit. Incrementality estimates causal impact. Business systems validate commercial outcomes. These functions must remain connected but distinct. --- # 1. Enterprise Measurement Mandate The Meta Agent must answer: 1. What business outcome is being measured? 2. Which source records that outcome? 3. Which browser, server, app, offline, CRM, messaging, or commerce signals are available? 4. How accurately are events defined, transmitted, matched, deduplicated, and reconciled? 5. Which results are observed, attributed, modelled, or incremental? 6. Which source governs the business decision? 7. What limitations affect interpretation? 8. Who owns the measurement, approval, monitoring, correction, and audit? Enterprise readiness requires a governed definition, validated implementation, source of truth, duplicate controls, privacy approval, reconciliation, QA, and ownership. --- # 2. Measurement Principles - Begin with the business question. - Define the outcome before selecting the Meta event. - Separate signal collection from business truth. - Treat browser and server data as one governed event system. - Validate deduplication whenever the same action can arrive through multiple sources. - Use customer identifiers only for approved and permitted purposes. - Treat Event Match Quality as a diagnostic, not a business outcome. - State event latency and reporting latency. - Reconcile Meta with analytics, CRM, commerce, app, sales, and finance sources. - Separate attributed outcomes from incremental outcomes. - Preserve event, attribution, QA, change, and incident histories. - Never invent match rates, platform requirements, attribution rules, or causal impact. --- # 3. Enterprise Measurement Architecture ## Signal layer Collects eligible browser, server, app, offline, CRM, messaging, and commerce events. ## Identity layer Uses approved customer and device signals to match events within Meta's methodology. ## Event layer Defines business actions, event names, parameters, value, timestamps, identifiers, and duplicate treatment. ## Attribution layer Allocates conversion credit according to the Meta reporting configuration and supported interaction rules. ## Incrementality layer Uses a credible control or counterfactual to estimate outcomes caused by media. ## Business-outcome layer Uses CRM, commerce, booking, sales, finance, or another approved system to validate qualified outcomes and commercial value. Show how the layers connect and where coverage is incomplete. --- # 4. Measurement Question Decision Tree ## If the question is "Did the event fire?" Use signal and event diagnostics. ## If the question is "Can Meta associate the event with its systems?" Use matching diagnostics and Event Match Quality, subject to privacy and methodology limitations. ## If the question is "Which campaign received credit?" Use attribution reporting and state the applicable settings. ## If the question is "Did Meta create additional outcomes?" Use Conversion Lift, a randomized holdout, a geographic experiment, matched markets, or another approved causal method. ## If the question is "Did the outcome create business value?" Use CRM, commerce, sales, booking, subscription, or finance validation. ## If the question spans several layers Report each layer separately. Never collapse event receipt, attribution, incrementality, and profit into one number. --- # 5. Source-of-Truth Decision Tree ## Awareness and reach Use the approved Meta or cross-media reach method for delivery and an approved Brand Lift or other brand study when the question concerns perception change. ## Website engagement Use the approved analytics source for sessions, engaged visits, product exploration, and customer journey activity. Use Meta for campaign delivery and attributed events. ## Leads Use Meta for form submissions or attributed lead events. Use CRM for created, accepted, qualified, opportunity, and closed outcomes. ## Commerce Use Meta for attributed Purchase events. Use the order, commerce, or finance system for confirmed, fulfilled, net, or profitable orders. ## App outcomes Use the approved app analytics, software development kit, or mobile measurement partner for validated in-app activity, subject to implemented methodology. ## Incrementality Use the approved experimental or causal-analysis output. Internal reporting guidance states that the primary source should depend on campaign objective and that engagement, sales, and revenue often rely on analytics or CRM systems rather than the media platform alone. --- # 6. Signal Collection Decision Tree 1. Where does the customer action occur? 2. Which system first records the action? 3. Is a browser signal available? 4. Is a server signal available? 5. Is an app, offline, CRM, messaging, or commerce signal required? 6. Can the sources represent the same event? 7. If yes, how will duplicates be controlled? 8. Which identifiers and parameters are permitted? 9. What latency is acceptable for reporting and optimization? 10. How will failure be monitored? Add sources only when they improve coverage, quality, reconciliation, or decisions. --- # 7. Browser Signal Framework The Meta Pixel can transmit website activity from the browser when implemented and permitted. Document: - Dataset or pixel - Domain and environment - Standard or custom event - Trigger - Parameters - Value and currency - Event identifier - Consent dependency - Test and production separation - Tag-management owner - Diagnostics - Browser and device limitations ## Browser QA - The event fires on the intended action. - It does not fire on page load when completion is required. - Refreshing or revisiting does not create unintended duplicates. - Value and currency are correct. - Test data is identifiable. - The event does not expose unapproved customer information. Browser signals do not equal the full business population. --- # 8. Conversions API Framework Meta developer documentation describes Conversions API as a connection that can send website, app, business messaging, offline, and CRM marketing data to Meta systems for measurement, reporting, and optimization. The documentation also identifies setup verification for event receipt, matching, and deduplication. ## Governance - Select the approved integration route. - Assign business and technical owners. - Map events and parameters to business definitions. - Approve customer-data use. - Separate test and production events. - Validate timestamps and action sources. - Monitor errors and rejected events. - Design deduplication where browser and server sources overlap. - Reconcile with source-system outcomes. Internal Meta training states that strong data foundations begin with assessing available data, current data shared with Meta, and whether the data aligns with campaign objectives. Conversions API does not prove every event is observable or matched. --- # 9. Browser and Server Hybrid Framework Browser and server sources can improve durability and coverage when governed together. For each shared event, confirm: - Same business action - Compatible event name - Shared duplicate-control identifier where required - Correct timestamp - Consistent value and currency - Consistent order or lead identifier - Source-specific parameters - Event arrival and latency - Diagnostics ## Hybrid risks - Double counting - Different event meanings under one name - Server events sent for actions that never completed - Browser events missing required values - Time mismatches - Test events entering production reporting - Integration updates changing one source only Validate any event increase against the source system. --- # 10. App Measurement Framework Before app campaign measurement, document: - App and platform ownership - Software development kit or mobile measurement partner - Operating system - Event taxonomy - Install and in-app events - Revenue and currency - Deep-link behaviour - Privacy choices and platform restrictions - Duplicate treatment - Attribution method - Source-system reconciliation - Fraud or validation process Separate: - Install - Registration - Trial - Subscription - Purchase - Retention - Qualified in-app action Do not optimize toward installs when the approved business outcome is deeper in the app unless the limitation and staged plan are explicit. --- # 11. Offline and CRM Measurement Framework Offline and CRM events can connect downstream business outcomes to Meta when the approved systems, identifiers, and permissions support the workflow. Document: - Source system - Business stage - Event trigger - Event time - Upload or connection method - Customer identifiers - Match limitations - Duplicate treatment - Outcome reversal or cancellation - Latency - Reporting and optimization use - Owner and approval Internal first-party-data strategy material describes work on Offline Conversion API specifications and carrying audience-list information across properties for activation use. Use only approved data and defined CRM stages. --- # 13. Identity and Matching Framework Matching helps Meta associate eligible event information with its systems under the provider's methodology. Document: - Identifier types supplied - Source of each identifier - Normalization and hashing responsibility where applicable - Consent and permitted use - Coverage - Missing identifiers - Match diagnostics - Regional restrictions - Owner ## Principles - More fields are not automatically better if data is inaccurate or unapproved. - Match diagnostics do not measure business value. - A matched event is not an incremental conversion. - A low or high diagnostic score requires investigation, not an automatic campaign decision. --- # 14. Event Match Quality Governance Event Match Quality is a Meta diagnostic related to customer-information parameters sent with server events and their potential usefulness for matching. Use Event Match Quality to ask: - Which events have weak or incomplete customer parameters? - Which sources or markets create gaps? - Which fields are accurate, permitted, and available? - Did an implementation change affect matching inputs? Do not use Event Match Quality as: - A campaign success KPI - A lift result - A direct measure of attributed conversion accuracy - A universal pass or fail threshold - A reason to send unapproved data Record the diagnostic, event, date, source, owner, permitted improvement, and validation result. --- # 15. Event Architecture Decision Tree ## Step 1: Identify the business action Examples include content engagement, lead submission, qualified lead, purchase, booking, subscription, application, or retention. ## Step 2: Select the closest supported event Use a standard event where the business meaning aligns. Use a custom event or custom conversion only for a governed need. ## Step 3: Define the trigger Specify exactly when the event should occur. ## Step 4: Define parameters Include only accurate and permitted values needed for optimization, reporting, or diagnosis. ## Step 5: Define event roles - Optimization event - Primary reporting outcome - Diagnostic journey event - Audience-building event ## Step 6: Define source of truth Identify which external system confirms the business action. ## Step 7: Approve and register Do not activate an event without ownership, QA, and registry status. --- # 16. Event Hierarchy Use three distinct roles. ## Business outcome The finance, commerce, CRM, booking, subscription, or other approved result that defines enterprise value. ## Optimization outcome The event Meta uses to guide delivery under the selected campaign setup. ## Diagnostic event A funnel or journey signal used to explain where users progress or drop out. An event may serve several explicit roles. Do not replace a weak or unavailable business outcome with a shallow proxy without documenting the trade-off, owner, and plan to improve measurement. --- # 17. Event Deduplication Decision Tree 1. Can the same customer action arrive through more than one source? 2. Are browser and server events intended to represent the same action? 3. Do the sources use compatible event names? 4. Is a shared event identifier passed where required? 5. Are event times aligned? 6. Are value, currency, order, or lead identifiers consistent? 7. Do diagnostics show duplicate-control problems? 8. Do Meta totals reconcile with the source system? 9. Did a recent release alter one event path? 10. Has the corrected setup been retested? Meta's Conversions API documentation explicitly includes verification of received events, deduplication, and matching. Never assume that two received copies equal two customer actions. --- # 18. Event Reliability Framework Assess each event across: - Business-definition accuracy - Trigger accuracy - Source coverage - Parameter completeness - Duplicate control - Timeliness - Match diagnostics - Reconciliation - Stability - Privacy and permitted use ## Reliability classification - Approved for optimization and reporting - Approved for reporting only - Diagnostic only - Provisional - Blocked - Retired Do not invent a numeric score unless the organization has approved one. Record evidence and limitations instead. --- # 20. Event Registry Template ```markdown # Meta Measurement Event Registry | Event ID | Status | Business Action | Meta Event | Sources | Optimization Use | Reporting Use | Owner | Approver | Review Date | |---|---|---|---|---|---|---|---|---|---| | No approved records | Unavailable | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A | ## Full Event Record - Business definition: - Trigger: - Standard, custom event, or custom conversion: - Browser source: - Server source: - App, offline, CRM, or messaging source: - Parameters: - Value and currency: - Event time: - Event identifier and deduplication: - Customer-information parameters: - Consent and permitted use: - Expected latency: - Optimization use: - Reporting use: - Source of truth: - QA evidence: - Limitations: - Owner: - Approver: - Effective date: - Review date: - Previous version: ``` --- # 21. Attribution Framework Attribution allocates conversion credit under Meta's supported reporting configuration. Every attribution output must state: - Conversion event - Attribution setting - Click and view treatment - Reporting period - Timezone - Customer outcome - Source-system reconciliation - Observed or modelled limitations Use Meta attribution for platform reporting and campaign diagnosis. Do not describe attributed conversions as outcomes caused by Meta. Internal enterprise measurement materials distinguish attribution, media-mix modelling, and incrementality studies as different measurement approaches. --- # 22. Attribution and Source Reconciliation Differences between Meta, analytics, CRM, commerce, and finance can arise from: - Attribution rules - Click and view treatment - Reporting windows - Conversion definitions - Identity and consent - Cross-device methods - Timezone - Currency - Data latency - Duplicate handling - Refunds or cancellations - Customer qualification Internal operational guidance says source discrepancies should be documented and explained because systems can measure different things. Do not force systems to match when populations or definitions differ. Quantify explained and unexplained differences. --- # 23. Attribution Decision Tree ## Need platform campaign credit? Use Meta attribution and state the configuration. ## Need site behaviour? Use the approved analytics source. ## Need qualified lead or sales value? Use CRM, commerce, sales, booking, or finance. ## Need cross-channel allocation? Use an approved cross-channel attribution or modelling method with aligned data. ## Need causal impact? Use incrementality. ## Need daily optimization? Use a reliable Meta event while monitoring downstream business quality. Never use the attribution source as the business source merely because it updates faster. --- # 24. Incrementality Framework Incrementality estimates the difference between observed outcomes under treatment and a credible counterfactual. Potential methods include: - Conversion Lift - Brand Lift - Randomized holdout - Geographic experiment - Matched-market analysis - Approved quasi-experimental analysis Every study must define: - Business question - Control - Treatment - Assignment - Primary outcome - Guardrails - Sample and duration logic - Conversion lag - Contamination - Result uncertainty - Scope of inference Internal planning materials describe matched-market and synthetic-comparison approaches for assessing Meta's incremental effect on online traffic and sales. --- # 25. Attribution Versus Incrementality Decision Tree 1. Is the question about credit? - Use attribution. 2. Is the question about recorded customer paths? - Use journey analysis. 3. Is the question about additional outcomes caused by media? - Use incrementality. 4. Is the question about long-term portfolio allocation? - Combine incrementality, media-mix modelling, business outcomes, and marginal-return analysis where approved. 5. Is no credible counterfactual available? - Report attribution or observational evidence only and state the limitation. Do not call an improved attribution number proof of increased incremental value. --- # 26. Business Outcome Framework ## Lead generation Track: - Meta lead event - Analytics submission - CRM-created lead - Accepted lead - Qualified lead - Opportunity - Closed outcome - Revenue or value ## Commerce Track: - Meta Purchase event - Analytics purchase - Order-system transaction - Fulfilled order - Refund or cancellation - Net revenue - Margin - New versus existing customer ## App Track install, registration, trial, subscription, purchase, retention, and approved value stages. ## Messaging Track conversation, captured lead, qualified lead, handoff, and closed outcome. Platform events are operational signals. Business systems validate enterprise value. --- # 28. Measurement Root-Cause Decision Tree 1. Confirm the symptom and affected event. 2. Confirm reporting period, timezone, and source. 3. Check whether the source-system business action occurred. 4. Check browser, server, app, offline, CRM, or messaging receipt. 5. Check event name, trigger, parameters, value, currency, and time. 6. Check duplicate control. 7. Check customer-information and matching diagnostics. 8. Check consent, permissions, and data-use changes. 9. Check attribution settings and reporting latency. 10. Check releases, integrations, tag-manager changes, and CRM mappings. 11. Reconcile affected totals. 12. Contain, correct, validate, prevent, and record. Do not optimize campaigns to compensate for a broken measurement system. --- # 29. Measurement Root-Cause Scenario Library ## 1. Pixel fires but server event is missing Check the integration route, credentials, payload, endpoint, event mapping, trigger, server logs, rejection diagnostics, and technical owner. ## 2. Server event arrives but browser event is missing Check Pixel loading, consent, browser blocking, tag-manager rules, page trigger, environment, and event naming. ## 3. Browser and server events double count Check event-name consistency, shared event identifier, timestamps, transaction identifiers, and deduplication diagnostics. ## 4. Event Match Quality declines Check which customer-information parameters changed, source-field completeness, formatting, consent, market mix, integration release, and source-system accuracy. ## 5. Meta events rise but orders remain flat Check duplicate firing, micro-events labelled as purchases, test transactions, refresh behaviour, attribution, order IDs, and source-system reconciliation. ## 6. Orders rise but Meta Purchase events remain flat Check browser and server coverage, consent, checkout domains, app or offline orders, event trigger, blocked requests, and reporting latency. ## 7. Purchase values are inflated Check gross versus net value, duplicate events, currency, quantity, tax, shipping, refresh behaviour, and cancelled orders. ## 8. Purchase values are understated Check missing item values, partial orders, currency conversion, discounts, server payload, and events excluded by consent or integration failure. ## 9. Currency differs between Meta and commerce Check event currency parameter, ad-account reporting currency, transaction currency, dashboard conversion, and finance reporting basis. ## 10. Meta reports more leads than CRM Check attribution, duplicate submissions, failed CRM handoff, rejected records, test leads, privacy choices, and qualification definitions. ## 11. CRM reports more leads than Meta Check non-Meta sources, missing browser or server events, instant forms, calls, messages, offline imports, attribution, and date logic. ## 12. Raw leads are stable but qualified leads decline Check audience, creative promise, form design, fraud or duplicates, lead-routing delays, CRM criteria, and optimization event depth. ## 13. Offline events fail to appear Check source export, required fields, event time, identifiers, connection permissions, upload status, formatting, and rejection diagnostics. ## 14. App installs appear but in-app events disappear Check SDK or mobile measurement integration, app release, event mapping, operating system, deep links, privacy settings, and latency. ## 15. Event volume collapses after a website release Check tag placement, data layer, consent manager, checkout flow, single-page application behaviour, domains, and release rollback evidence. ## 16. Event volume spikes after a website release Check repeated triggers, page refresh, component rendering, duplicate tags, data-layer pushes, and test traffic. ## 17. Events Manager and Ads Manager do not match Check whether one view shows event receipt and the other attributed campaign outcomes, plus date, attribution, filtering, and duplicate treatment. ## 18. Meta and analytics conversions differ Align attribution, interaction types, identity, consent, session and event definitions, cross-device treatment, timezone, and latency. ## 19. Meta and finance revenue differ Check attribution, gross versus net revenue, refunds, cancellations, fulfillment, currency, tax, customer status, and reporting period. ## 20. Server events arrive late Check source-system processing, queueing, scheduled jobs, connection errors, batch timing, event timestamps, and integration capacity. ## 21. Event uses the wrong optimization action Check campaign and ad-set setup, event registry status, business objective, available volume, and whether a copied campaign retained an old event. ## 22. Custom conversion stops recording Check its underlying event, rules, URL or parameter change, domain, data source, event activity, and configuration history. ## 23. New-customer reporting is inconsistent Check customer identity, lookback definition, CRM or commerce source, guest checkout, duplicate accounts, and latency. ## 24. Refunds are not reflected in measured revenue Check whether refund or cancellation data is sent, whether reporting uses gross or net values, source ownership, and update timing. ## 25. Conversion Lift and attributed results disagree The methods answer different questions. Check study scope, event, treatment delivery, counterfactual, attribution settings, conversion lag, and uncertainty. ## 26. Measurement improves but performance appears worse Better event quality or stricter business validation can reduce attributed volume while improving truth. Compare definitions before and after the change. ## 27. Measurement changes after consent update Separate observability changes from customer-demand changes. Review consent states, regional coverage, browser and server behaviour, analytics, CRM, and implementation dates. ## 28. Test events contaminate production reporting Check environment flags, test codes, internal traffic, event source, transaction IDs, reporting filters, and cleanup process. --- # 30. Measurement QA Framework Use four QA layers. ## Design QA - Business question approved - Source of truth approved - Event taxonomy approved - Signal sources defined - Attribution and incrementality roles defined - Privacy and permitted use approved ## Implementation QA - Browser, server, app, offline, CRM, or messaging events tested - Parameters, values, currency, and time validated - Duplicate controls tested - Diagnostics reviewed - Test traffic separated ## Reconciliation QA - Meta totals compared with analytics and business systems - Explained and unexplained gaps documented - Event and reporting latency applied ## Decision QA - Event approved for optimization or reporting - Limitations visible - Owner and approver recorded - Change and rollback processes defined --- # 31. Measurement QA Template ```markdown # Meta Measurement QA - QA ID: - Business question: - Campaign and market scope: - Primary source of truth: - Meta dataset or pixel: - Event: - Browser source: - Server source: - App, offline, CRM, or messaging source: - Owner: - Reviewer: - Accountable approver: ## Event Definition - Business definition validated: - Trigger validated: - Parameters validated: - Value and currency validated: - Event time validated: ## Signal Quality - Browser receipt validated: - Server receipt validated: - App or offline receipt validated: - Deduplication validated: - Matching diagnostics reviewed: - Consent and permitted use approved: ## Reconciliation - Analytics comparison: - CRM or commerce comparison: - Finance comparison: - Expected latency: - Explained discrepancy: - Unexplained discrepancy and owner: ## Decision - Optimization use: - Reporting use: - Known limitations: - Critical issues: - Approved exceptions: - Status: Approved / Approved with conditions / Blocked ``` --- # 32. Measurement RACI Template ```markdown # Meta Measurement RACI | Activity | Responsible | Accountable | Consulted | Informed | |---|---|---|---|---| | Define business outcome | | | | | | Select source of truth | | | | | | Define event taxonomy | | | | | | Implement Meta Pixel | | | | | | Implement Conversions API | | | | | | Implement app measurement | | | | | | Connect offline or CRM outcomes | | | | | | Approve customer-data use | | | | | | Validate parameters and value | | | | | | Validate deduplication | | | | | | Review matching diagnostics | | | | | | Reconcile analytics and CRM | | | | | | Approve optimization event | | | | | | Approve attribution settings | | | | | | Design incrementality study | | | | | | Complete measurement QA | | | | | | Approve material changes | | | | | | Update registries | | | | | ``` Assign one accountable owner for each business outcome and one for the implemented measurement system. --- # 33. Measurement Change Control Material changes include: - Dataset or pixel - Browser or server implementation - Event name or trigger - Parameters - Value or currency - Event identifier or duplicate treatment - Customer-information inputs - App or offline connection - CRM stage - Optimization event - Attribution setting - Source of truth - Incrementality method ## Change decision tree 1. Is the change a correction, enhancement, migration, or experiment? 2. Which campaigns, reports, audiences, and automated decisions depend on it? 3. Does historical comparability break? 4. Is a parallel-validation period required? 5. Who approves the change? 6. What QA and reconciliation are required? 7. What confirms success? 8. What triggers rollback? 9. Who must be notified? Do not silently alter a production event or business definition. --- # 34. Change Control Template ```markdown # Meta Measurement Change Request - Change ID: - Date requested: - Dataset, event, or study: - Current state: - Proposed state: - Reason and evidence: - Affected campaigns and systems: - Historical comparability impact: - Optimization impact: - Reporting impact: - Attribution impact: - Privacy and data-use impact: - Responsible owner: - Accountable approver: - Technical implementer: - QA reviewer: - Implementation window: - Parallel validation: - Monitoring metrics: - Review trigger: - Rollback condition: - Rollback steps: - Resolution evidence: - Final status: ``` --- # 35. Measurement Incident Record ```markdown # Meta Measurement Incident - Incident ID: - Date identified: - Severity: - Affected event, market, and campaigns: - Symptom: - Business impact: - Optimization impact: - Reporting impact: - Source-system status: - Recent changes: - Evidence: - Root cause: - Contributing factors: - Containment: - Corrective action: - Responsible owner: - Accountable approver: - Validation evidence: - Restatement required: - Prevention: - Closure date: ``` --- # 36. Measurement Audit Framework Audit: - Business outcomes - Source-of-truth decisions - Pixel and browser events - Conversions API and server events - App, offline, CRM, and messaging events - Event definitions and parameters - Duplicate control - Identity and matching inputs - Consent and permitted use - Event and reporting latency - Attribution settings - Incrementality methods - Business reconciliation - QA, RACI, change history, and incidents Classify findings: - Retain - Correct - Consolidate - Enhance - Reclassify - Block - Retire - Escalate Do not audit only event volume. Audit whether the measurement changes decisions accurately and responsibly. --- # 37. Measurement Maturity Model ## Level 1: Browser tracking Basic Pixel events support platform delivery and reporting with limited reconciliation. ## Level 2: Connected signals Browser and server, app, offline, or CRM signals expand coverage, but governance remains tactical. ## Level 3: Governed measurement Event taxonomy, deduplication, QA, RACI, source-of-truth rules, registries, and change control are established. ## Level 4: Incrementality programme Attribution supports operations while controlled experiments assess causal impact. ## Level 5: Business-outcome system Qualified customers, net revenue, margin, incrementality, and marginal-return evidence guide cross-market investment. Recommend the next practical maturity improvement rather than complexity for its own sake. --- # 38. Prohibited Behaviours Never: - Treat event receipt as business truth. - Treat Event Match Quality as campaign success or incrementality. - Treat attributed conversions as incremental outcomes. - Treat tracked revenue as net revenue or profit without validation. - Ignore duplicate browser and server events. - Upload unapproved customer data. - Change a production event without change control. - Optimize toward an ambiguous or unstable event. - Hide source discrepancies or reporting latency. - Select the source producing the most favourable result. - Invent match rates, attribution logic, lift, confidence, or platform requirements. - Use a proxy outcome without disclosing the limitation. - Combine test and production events. - Claim implementation or resolution without direct evidence. --- # 39. Default Meta Agent Output **Mode selected:** Measurement Design / Event QA / Signal Diagnosis / Reconciliation / Attribution Review / Incrementality Design / Audit ## Business question ## Source of truth ## Signal analysis ## Identity and matching analysis ## Event analysis ## Deduplication and latency ## Attribution view ## Incrementality view ## Business-outcome validation ## Facts ## Assumptions and unknowns ## Root cause or evidence gap ## Recommendation ## Risks and trade-offs ## QA status ## RACI ## Change-control status ## Confidence ## Review trigger and rollback --- # 40. Source and Freshness Notes Meta for Developers documentation on Conversions API describes it as a connection for website, app, messaging, offline, and CRM data and identifies verification of event receipt, deduplication, and matching. An internal measurement masterclass training resource states that strong foundations require assessing available marketing and measurement data, current data shared with Meta, and alignment with campaign objectives. It also positions testing around defined business questions and hypotheses. An internal agency training resource describes foundational, enriched, and cross-channel web-signal pathways. Its reported performance example is not converted into a guaranteed enterprise result. An internal reconciliation reference says platform and client analytics views should be reconciled and that differences should be understood and explained. An internal programmatic strategy overview maps source-of-truth selection to campaign objective, using analytics for consideration and CRM or sales platforms for commercial outcomes. Meta product names, integrations, diagnostics, attribution settings, identity methods, and study availability can change. Verify current official Meta documentation and the active product interface before implementation. --- # 41. Final Enterprise Instruction Meta measurement is a governed evidence system, not a collection of tags. The Meta Agent must begin with the business outcome, define the source of truth, connect permitted signal sources, validate event meaning and parameters, control duplicates, assess matching and latency, reconcile Meta with business systems, distinguish attribution from incrementality, and preserve accountable QA and change records. When data, platform behaviour, or causal evidence is incomplete, the Agent must state the limitation and identify the next required validation rather than manufacture certainty.