Marketing Data Infrastructure

Without accurate data, you are running campaigns blindly. Every dollar spent on marketing that cannot be traced to pipeline and revenue is a dollar you cannot justify or optimize. This playbook covers how to build clean, reliable marketing data infrastructure from the ground up so that every lead has a digital footprint, every campaign has measurable ROI, and every decision is data-informed.

---

1. The Foundation: Why Data Infrastructure Comes First

Most marketers start with campaigns and try to figure out measurement later. This is backwards. The correct sequence is:

1. Build tracking infrastructure
2. Validate data accuracy
3. Launch campaigns
4. Measure and optimize

If you launch campaigns before your tracking is solid, you will spend months cleaning up data retroactively, and you will never trust the numbers.

The Cost of Bad Data

• Marketing teams with poor data infrastructure waste 15-25% of their budget on channels they cannot prove work.
• Sales teams distrust marketing-sourced leads when lead source data is unreliable.
• Executive reporting becomes a manual, time-consuming exercise instead of an automated dashboard.
• Attribution arguments replace strategic conversations.

---

2. Google Analytics Goal Configuration

The Critical Rule: Destination Pages, NOT Events

Configure goals as destination page views (e.g., /thank-you, /confirmation), not events. Here is why:

• Destination goals can be imported directly into Google Ads as conversion actions.
• They can be matched across GA, Google Ads, and LinkedIn Ads so that data from all sources matches.
• Event-based goals create discrepancies between platforms because each platform counts events differently.
• Destination goals are simpler to audit: either the user hit the page or they did not.

Goal Setup Checklist

1. Map every conversion action on your site to a unique thank-you or confirmation URL.
2. Create a goal in GA4 for each destination URL.
3. Match these goals to conversion actions in Google Ads.
4. Match these goals to conversion tracking in LinkedIn Campaign Manager.
5. Verify that conversion counts match across all three platforms within a 5-10% margin.

GA4 Migration and Enhanced Event Tracking

• GA4 uses an event-based model but still supports destination-based conversions via page_view events filtered by page_location.
• Set up enhanced measurement events: scroll depth, outbound clicks, site search, video engagement, file downloads.
• Create custom events for key interactions: pricing page views, demo request button clicks, feature page engagement.
• Use GA4's exploration reports to build custom funnels that match your actual buyer journey.
• Set up data streams for web and app if applicable. Ensure cross-platform user tracking with User-ID.

Common GA Mistakes

• Not filtering out internal traffic (your own team inflates metrics).
• Not setting up cross-domain tracking when your marketing site and app are on different domains.
• Using default channel groupings without customization (leads to "Direct" being a catch-all for untracked traffic).
• Not linking GA to Google Ads and Search Console.

---

3. CRM Data Flow Architecture

Dual-Platform Setup

Most B2B companies run two platforms: a marketing automation platform and a sales CRM. Common combinations:

Marketing Platform	Sales CRM	Integration
HubSpot	Salesforce	Native connector
HubSpot	NetSuite	Third-party (Bedrock, custom)
Pardot	Salesforce	Native (same ecosystem)
Marketo	Salesforce	Native connector
ActiveCampaign	Salesforce	Zapier or native

Data Flow Principles

1. Marketing platform is the system of record for lead generation data: lead source, first touch, campaign attribution, email engagement, form submissions, content downloads.
2. Sales CRM is the system of record for pipeline and revenue data: opportunity stage, deal value, close date, sales activities, account hierarchy.
3. Integration syncs bidirectionally: new leads flow from marketing to sales; opportunity and revenue data flows from sales back to marketing.
4. Lead source must persist across both systems: when a lead is created in marketing and synced to sales, the original lead source must carry over and never be overwritten.

Integration Health Checks

• Run weekly sync audits: compare lead counts in marketing platform vs. CRM. Discrepancies above 2% indicate sync failures.
• Monitor sync error logs daily. Common issues: field mapping mismatches, picklist value misalignment, duplicate detection conflicts.
• Set up alerts for sync failures so they are caught within hours, not weeks.

---

4. UTM Parameter Strategy

Standard UTM Framework

Every link in every campaign gets UTM parameters. No exceptions.

Parameter	Purpose	Example Values
utm_source	Where the traffic comes from	google, linkedin, email, facebook, partner-name
utm_medium	The marketing medium	cpc, social, email, referral, organic
utm_campaign	The specific campaign	q1-webinar-series, product-launch-2024, competitor-comparison
utm_content	Differentiates ad variations	banner-a, text-link, cta-button, sidebar
utm_term	Paid search keywords	marketing-automation, crm-software

Custom Fields for Lead Source

Beyond UTMs, create two custom fields in your CRM:

1. Lead Source (First Touch): The original channel that brought the lead in. Set once, never overwritten. Values: Organic Search, Paid Search, LinkedIn Ads, Email, Referral, Direct, Event, Partner, Free Tool, Webinar, Content Syndication.
2. Last Lead Source (Most Recent Touch): The most recent channel the lead engaged through before their latest conversion. Updated on every new conversion.

UTM Governance

• Create a master UTM spreadsheet or use a UTM builder tool that enforces naming conventions.
• Standardize capitalization (always lowercase).
• Standardize delimiters (hyphens, not underscores or spaces).
• Audit UTM usage monthly. Inconsistent UTMs are worse than no UTMs because they create phantom channels in your reporting.

---

5. Lead Source Tracking Architecture

Every lead that fills out a form on your site should have a complete digital footprint in your CRM.

What Gets Captured

Data Point	How It Is Captured
Lead source (first touch)	UTM parameters on first visit
Lead source (last touch)	UTM parameters on conversion visit
Referral URL	HTTP referrer header
Landing page	Page URL where form was submitted
Device type	User agent string
Geographic location	IP-based geolocation
Pages viewed before conversion	Session tracking via GA or marketing platform
Time on site before conversion	Session duration tracking
Content consumed	Page view tracking linked to lead record

Implementation Steps

1. Add hidden fields to every form that capture UTM parameters from the URL.
2. Use JavaScript to read UTM parameters from the URL and populate hidden form fields.
3. Store first-touch UTMs separately from last-touch UTMs. Use cookies or local storage to persist first-touch data across sessions.
4. Sync all captured data to CRM fields on form submission.
5. Build reports that show lead volume, pipeline, and revenue by lead source.

The Payoff

• You can answer "Which channel drives the most revenue?" with confidence.
• You can calculate true CAC (customer acquisition cost) by channel.
• You can make budget allocation decisions based on data, not gut feeling.
• You can identify which campaigns generate leads that actually close, not just leads that fill out forms.

---

6. First-Party Data Collection Strategy

Browser cookies are going away. Third-party cookies are already blocked in most browsers. If your marketing data infrastructure depends on third-party cookies, you are building on a disappearing foundation.

Why First-Party Data Matters Now

• Third-party cookie deprecation means retargeting audiences will shrink by 30-60%.
• Cross-site tracking becomes unreliable without first-party alternatives.
• Companies that invest in first-party data now will have a significant competitive advantage within 12-24 months.

First-Party Data Collection Methods

1. Server-side capture: Move tracking logic from the browser to your server. Server-side Google Tag Manager, server-side conversion APIs (Facebook CAPI, LinkedIn CAPI).
2. Database-level tracking: Log every meaningful interaction in your own database. Page views, form submissions, email opens, product usage. You own this data regardless of browser privacy changes.
3. Authenticated user tracking: Encourage users to log in or create accounts. Authenticated sessions provide reliable tracking without cookies.
4. Email engagement data: Email opens, clicks, and replies are first-party data you fully control.
5. CRM and product usage data: Every interaction within your product is first-party data.

Server-Side Tagging Benefits

• Bypasses ad blockers (30-40% of B2B traffic uses ad blockers).
• Provides more reliable conversion data to ad platforms.
• Reduces page load impact from client-side scripts (improving Core Web Vitals).
• Gives you control over what data is shared with third parties.
• Improves data accuracy by 15-30% compared to client-side-only tracking.

Implementation Priority

1. Set up server-side Google Tag Manager (requires a cloud server, typically Google Cloud Run).
2. Implement Facebook Conversions API and LinkedIn Conversions API for server-side event sending.
3. Build a first-party data layer on your website that captures user interactions in your own database.
4. Create a unified customer profile that merges data from all first-party sources.

---

7. Data Normalization Rules

When data flows from multiple platforms into a central location, naming inconsistencies will destroy your reporting.

Common Normalization Challenges

Raw Platform Data	Normalized Category
Pardot	Email Leads
HubSpot Email	Email Leads
Mailchimp	Email Leads
Google Ads	Paid Search
Bing Ads	Paid Search
LinkedIn Sponsored Content	LinkedIn Ads
LinkedIn InMail	LinkedIn Ads
Facebook Ads	Facebook Ads
Organic - Google	Organic Search
Organic - Bing	Organic Search
Snitcher	Web Visitor Intelligence
Webinar - Zoom	Webinar
Webinar - GoToWebinar	Webinar

Normalization Implementation

• Create a mapping table in your CRM or data warehouse that translates raw values to standardized categories.
• Apply normalization rules on data import, not on reporting. Standardize upstream so all downstream reports are clean.
• Document every normalization rule and review quarterly. New platforms and campaigns introduce new raw values that need mapping.
• Set up alerts for unmapped values so they are caught and categorized quickly.

---

8. SQL Databases for Marketing Pattern Discovery

Connect your marketing platforms at the database level to discover patterns that platform-native reporting cannot reveal.

Architecture

1. Export data from each marketing platform to a SQL database (BigQuery, Snowflake, PostgreSQL, or even a well-structured MySQL instance).
2. Create tables for: leads, campaigns, opportunities, email engagement, web sessions, ad spend.
3. Build joins across tables to answer cross-platform questions.

Queries That Drive Decisions

• Lead score to pipeline correlation: SELECT lead_score_range, COUNT(opportunity_id), AVG(deal_value) FROM leads JOIN opportunities ON leads.id = opportunities.lead_id GROUP BY lead_score_range
• Channel to close rate: Which lead sources produce leads that actually become customers, not just SQLs?
• Time to close by channel: How long does it take leads from each channel to move through the funnel?
• Content to conversion path: Which blog posts or content pieces are most frequently in the conversion path of closed-won deals?

The Insight Layer

• When you can join marketing data with sales data at the database level, you find patterns invisible in any single platform.
• Example: leads from organic search with a lead score above 70 who attend a webinar close at 3x the rate of any other segment.
• These insights inform budget allocation, content strategy, and sales prioritization.

---

9. Campaign Framework Document

Every campaign needs a standardized campaign framework document before it launches.

Template Structure

Campaign Name: [Standardized naming convention]
Campaign Owner: [Role, not individual name]
Launch Date: [Date]
End Date: [Date]
Objective: [One sentence. Be specific. "Generate 50 MQLs" not "drive awareness"]
Target Audience: [ICP segment, firmographics, personas]
Channels: [List all channels with budget allocation]
UTM Parameters: [Exact UTMs for every link]
Success Metrics: [Primary KPI, secondary KPIs, benchmarks]
Tracking Setup: [Confirm goals, pixels, UTMs are live before launch]
Reporting Cadence: [Weekly, bi-weekly, monthly]
Post-Campaign Review Date: [Date]

Why This Matters

• Forces alignment across marketing, sales, and leadership before money is spent.
• Creates accountability by defining success criteria upfront.
• Makes post-campaign analysis straightforward because expectations were documented.
• Builds an institutional library of campaign performance data over time.

---

10. User Journey Mapping with Referral URLs and Session IDs

Database Architecture

Create separate tables to track the full user journey:

Sessions Table

Column	Type	Description
session_id	UUID	Unique session identifier
user_id	UUID	Persistent user identifier (cookie or auth)
start_time	Timestamp	Session start
referral_url	String	Full referring URL
utm_source	String	UTM source parameter
utm_medium	String	UTM medium parameter
utm_campaign	String	UTM campaign parameter
landing_page	String	First page viewed
device_type	String	Desktop, mobile, tablet

Page Views Table

Column	Type	Description
pageview_id	UUID	Unique pageview identifier
session_id	UUID	Links to sessions table
page_url	String	Page viewed
timestamp	Timestamp	When viewed
time_on_page	Integer	Seconds on page

Conversions Table

Column	Type	Description
conversion_id	UUID	Unique conversion identifier
session_id	UUID	Links to sessions table
user_id	UUID	Links across sessions
conversion_type	String	Form submit, demo request, signup
timestamp	Timestamp	When converted

The Payoff

• True multi-session, multi-channel user journey mapping.
• Attribute conversions to the correct touchpoints across days or weeks.
• Identify the most common paths to conversion and optimize for those paths.
• Calculate time-to-conversion by channel and campaign.

---

11. Google Tag Manager as the Tracking Hub

GTM should be the single point of control for all tracking across your marketing stack.

What Lives in GTM

• Google Analytics 4 configuration and event tags
• Google Ads conversion tracking and remarketing tags
• LinkedIn Insight Tag
• Facebook/Meta Pixel
• Hotjar, Mixpanel, or other analytics tools
• Custom JavaScript for form tracking, scroll depth, and click tracking
• Server-side tagging configuration

GTM Best Practices

• Use a consistent naming convention for tags, triggers, and variables: [Platform] - [Action] - [Details] (e.g., "GA4 - Event - Form Submit - Contact Us").
• Version control: name every container version with a description of changes before publishing.
• Use GTM's built-in debugging tool (Preview mode) to verify every tag fires correctly before publishing.
• Set up a staging container for testing. Never test in production.
• Limit container access. Only trained team members should publish changes.
• Audit the container quarterly. Remove tags for tools you no longer use. Dead tags slow down page load.

Container Size and Performance

• Keep the container under 200KB. Large containers impact page load time.
• Use tag sequencing to control firing order for dependent tags.
• Implement consent mode for GDPR/CCPA compliance.

---

12. Multi-Touch Attribution Setup

Attribution Models

Model	How It Works	Best For
First Touch	100% credit to the first interaction	Understanding top-of-funnel effectiveness
Last Touch	100% credit to the last interaction before conversion	Understanding bottom-of-funnel effectiveness
Linear	Equal credit to every touchpoint	Balanced view of the full journey
Time Decay	More credit to recent touchpoints	Long sales cycles where recency matters
Position-Based (U-Shaped)	40% first, 40% last, 20% split among middle	Balanced but emphasizes introduction and close
Data-Driven	Algorithmic based on actual conversion patterns	Mature organizations with high conversion volume

Implementation Requirements

• Minimum 300-500 conversions per month for data-driven attribution to be reliable.
• All touchpoints must be tracked consistently (see UTM strategy and session tracking above).
• CRM must have both first-touch and multi-touch attribution fields.
• Build attribution reports that show pipeline and revenue by model, not just lead volume.

Practical Advice

• Run two models in parallel (first-touch and position-based) and compare. If they tell the same story, your data is consistent.
• If they tell very different stories, dig into the touchpoints that appear in one model but not the other.
• Attribution is a tool for directional guidance, not absolute truth. Use it to inform decisions, not to make them in isolation.

---

13. Automated Workflows Based on Lead Scoring

Lead Scoring Framework

Signal	Points	Rationale
Visited pricing page	+15	High intent signal
Downloaded whitepaper	+10	Content engagement
Attended webinar	+20	Active participation
Opened 3+ emails in a week	+5	Engaged but passive
Requested demo	+30	Highest intent
Job title matches ICP	+20	Firmographic fit
Company size matches ICP	+15	Firmographic fit
No activity in 30 days	-10	Decay signal
Unsubscribed from email	-20	Disengagement

Workflow Triggers

• Score crosses 50: Assign to SDR for outreach. Lead source and engagement history visible in CRM.
• Score crosses 80: Flag as hot lead. Alert sales team via Slack or email. Prioritize for same-day follow-up.
• Score drops below 30 after being above 50: Trigger re-engagement campaign. Different content, different channel.
• Score crosses 100: Auto-create opportunity in CRM. Route to account executive.

Revenue Impact

• Companies with properly configured lead scoring and automated workflows see 20-35% improvement in sales efficiency.
• Sales teams spend less time qualifying and more time closing.
• Marketing can prove that higher-scored leads convert at higher rates, validating the scoring model.

---

Summary: Implementation Order

1. Week 1-2: Set up GTM, GA4 goals, and UTM parameter strategy.
2. Week 3-4: Configure CRM data flow, lead source fields, and sync monitoring.
3. Week 5-6: Implement form tracking with hidden fields, first-party data capture.
4. Week 7-8: Build lead scoring model and automated workflows.
5. Month 3: Set up SQL database for cross-platform analysis.
6. Month 4: Implement multi-touch attribution.
7. Ongoing: Audit data quality monthly, normalize new data sources, optimize based on insights.

The companies that invest in data infrastructure now will outperform those that do not. It is not glamorous work, but it is the foundation everything else is built on.

---

14. Tag Management & Server-Side Tracking

Your tracking infrastructure is only as reliable as how you deploy it. Hardcoding tracking scripts into your site templates is a relic from a decade ago — it creates developer dependencies, makes auditing nearly impossible, and turns every new marketing tool into a deployment ticket.

Tag Manager as the Hub

Every tracking code — analytics, ad pixels, heatmaps, chat widgets, A/B testing scripts — should be deployed through a tag management system. No exceptions.

Why centralized tag management matters:

• Speed of deployment: Marketing can add, modify, or remove tracking without waiting for a developer to write code, create a pull request, pass code review, and deploy. What used to take a sprint cycle now takes 15 minutes.
• Auditing and transparency: Every tag, trigger, and variable lives in one place. You can see everything that fires on your site, when it fires, and what data it sends. Without this, tracking scripts accumulate like barnacles — nobody knows what half of them do or whether they still work.
• Conditional firing based on consent: Modern privacy regulations require that tracking only fires when the user has given explicit consent. Tag management systems integrate with consent management platforms so tags respect opt-in and opt-out preferences automatically.
• No developer dependency for marketing tags: The marketing team owns their own tracking destiny. Developers maintain the tag management container itself, but individual tag changes do not require engineering resources.

Server-Side Tagging Architecture

Client-side tracking — loading scripts in the visitor's browser — is increasingly broken. Ad blockers strip out tracking requests. Browsers impose strict cookie limits. JavaScript failures silently kill your data collection. Server-side tagging fixes all of this by moving the tracking execution from the visitor's browser to a server you control.

How it works: Instead of loading a tracking script in the browser that sends data directly to third-party servers (Google Analytics, ad platforms, etc.), the browser sends data to your own server endpoint. Your server then processes and forwards that data to each vendor. The visitor's browser never communicates directly with third-party tracking domains.

Why server-side tracking changes everything:

• First-party cookies that actually last: Browser-set cookies from third-party domains expire in 1-7 days (depending on the browser). Server-set cookies from your own domain can persist for 400+ days. This is critical for attribution — without persistent cookies, a user who visits your site on Monday and converts on Thursday looks like two separate people.
• Resistance to ad blockers: Ad blockers work by identifying and blocking requests to known tracking domains (google-analytics.com, facebook.com/tr, etc.). When tracking requests go to your own subdomain, blockers cannot distinguish them from legitimate first-party requests. You recover 30-40% of data that client-side tracking loses.
• Hidden tracking identifiers: With client-side tracking, anyone can view page source and see your analytics IDs, pixel IDs, and measurement codes. With server-side tracking, those identifiers live on your server and are never exposed to the browser. This prevents spam hits and unauthorized data manipulation.
• Dramatically faster page loads: Every client-side tracking script adds weight to your page. Removing 5-10 tracking scripts from the browser and running them server-side can reduce page load time significantly — directly improving Core Web Vitals and user experience.
• Full control over outbound data: Client-side scripts send whatever data the vendor decides to collect. Server-side tracking lets you inspect and modify every data payload before it leaves your infrastructure. You control exactly what each vendor receives — nothing more, nothing less.

Server-Side Impact on Paid Media

Moving to server-side tracking typically increases reported conversions by 30-50% for ad platforms like Google Ads, Meta, and LinkedIn. This is not phantom data — these are real conversions that client-side tracking was missing due to ad blockers, browser restrictions, cookie expiration, and JavaScript failures.

The downstream impact on campaign performance is substantial. Automated bidding algorithms (Target CPA, Target ROAS, Maximize Conversions) are only as good as the conversion data they receive. When 30-50% of conversions are invisible, the algorithm makes poor optimization decisions — it does not know which clicks actually converted. Feed it complete data, and the algorithm spends your budget more effectively because it can see the full picture of what works.

Custom Subdomain Setup

When implementing server-side tracking, deploy your tracking endpoint on a subdomain of your main domain — something like data.yourdomain.com or collect.yourdomain.com.

Why this matters:

• Cookies set by this subdomain are first-party cookies, not third-party. Browsers treat them with the same trust as your main domain's cookies.
• Ad blockers identify tracking requests by domain. A request to data.yourdomain.com looks like any other first-party request and passes through blockers undetected.
• DNS configuration is straightforward — create a CNAME record pointing your subdomain to your server-side container's host.

Consent Mode Integration

Server-side tracking does not mean ignoring privacy regulations. If anything, it gives you better tools for compliance because you have full control over when and how data flows.

Implementation approach:

• Deploy a consent management platform that captures user preferences before any tracking fires
• Configure your server-side container to check consent status before forwarding data to any vendor
• When a user opts out, the server suppresses all tracking requests for that session — no cookies set, no data forwarded, no vendor receives information
• This is more reliable than client-side consent banners, which can break due to JavaScript errors, load order issues, or browser extensions. Server-side consent enforcement is deterministic — if the consent flag is not present, data does not flow.

Single Collection, Multi-Destination

One of the most powerful architectural benefits of server-side tracking is the single-collection pattern. Instead of loading separate scripts for every vendor (one for analytics, one for Google Ads, one for Meta, one for LinkedIn, one for your CRM), you collect the event once on the server and forward it to multiple destinations.

Benefits:

• Fewer scripts in the browser means fewer conflicts, fewer race conditions, and fewer mysterious bugs
• One consistent data payload across all platforms — no more discrepancies between what Google Analytics reports and what your ad platform reports
• Adding a new vendor is a server-side configuration change, not a new script in the browser
• Removing a vendor is equally simple — stop forwarding data without touching the browser

Offline Conversion Tracking

Server-side infrastructure unlocks the ability to track conversions that never touch a browser — phone orders, in-store purchases, CRM-recorded sales, and chat-initiated deals.

How it works:

• When a visitor interacts with your site, your server-side container assigns and stores a persistent identifier
• When that visitor later converts offline (calls your sales team, walks into a store, signs a contract), you match the offline conversion back to the original web session using the stored identifier
• The conversion event is then forwarded to your analytics and ad platforms through the same server-side pipeline

Why this matters: For businesses where the final conversion happens offline, this is the difference between knowing which campaigns drive real revenue and guessing. Without offline conversion tracking, you are optimizing for proxy metrics (form fills, page views) rather than the outcomes that actually matter.

Tag Management Hygiene

A tag management container is like a codebase — without discipline, it accumulates technical debt that eventually causes problems.

Audit cadence: Review your entire container every 6-12 months. Remove tags for tools you stopped using, vendors whose contracts ended, or experiments that concluded months ago. Dead tags add page weight and increase the surface area for conflicts.

Naming conventions from day one: When you have 5 tags, you can find anything. When you have 50+ tags, a naming convention is the difference between manageable and chaotic. Use a consistent format: [Platform] - [Action] - [Details] (e.g., "GA4 - Event - Form Submit - Contact Page"). Establish this convention before your container grows.

Small, deliberate changes: Publish changes in small batches — one feature or one tag change per version. If something breaks after a publish that included 10 changes, you cannot isolate the cause. One change per version means instant root cause identification.

Container backups: Export your container as a JSON backup before major changes and on a regular schedule. If a publish goes wrong, you can restore to any previous version instantly.

Performance monitoring: After deploying any new tag, check your page speed metrics. A single poorly configured tag can add hundreds of milliseconds to page load. Monitor Core Web Vitals before and after every container change.

Common Tracking Mistakes to Avoid

Do not use click triggers for form tracking: A click on a submit button does not mean the form was successfully submitted. The form might have validation errors, the API call might fail, or the user might click submit on an empty form. Click triggers inflate your conversion count with failed submissions. Use form submission success events instead — track the thank-you page load or the successful API response.

Do not place data layer code below your tag manager snippet: The data layer must be initialized before your tag manager loads. If the data layer code appears below the tag manager snippet in your HTML, the tag manager fires before the data layer exists — and every tag that depends on data layer variables fails silently. Always place dataLayer initialization code above the tag manager script.

Do not publish all changes at once: If you have been accumulating changes for weeks, resist the temptation to publish everything in one batch. Publish incrementally. Test each change in preview mode. Verify in a staging environment. Then publish to production. This discipline saves you from the nightmare of a broken container with no clear cause.

Always test in preview and debug mode first: Every tag management system has a preview or debug mode that lets you verify which tags fire, which triggers activate, and what data is passed — without affecting live visitors. Use it for every single change, no matter how small. The cost of testing is minutes. The cost of a broken tracking setup is weeks of lost data.