The Orchestration Gap

Phase 1: The Unified Data Layer — semantics, not tools #

The most common wrong turn in enablement setups is the wrong segmentation. Teams think in tools ("HubSpot list", "Salesforce campaign", "GA4 audience") — and replicate the silos they were meant to dissolve.

The right layer of thinking is the lifecycle stage, not the tool. Every contact in your system has a current stage in their lifecycle, and this stage is defined across tools.

Canonical lifecycle model

• Anonymous — first-party signal without identity (session, page view, cookie)
• Subscriber — consent given but no buying-intent signal (newsletter opt-in, content download)
• Lead — specific buying-intent signal (demo request, pricing-page visit, contact form)
• MQL (Marketing Qualified) — marketing has qualified the lead against the score threshold
• SQL (Sales Accepted) — sales has accepted the lead, ownership transferred
• Opportunity — open deal stage, forecast-relevant
• Customer — deal closed, active relationship

Each of these stages has a single definition, documented in a stages.yaml (or a Notion page, whatever — the point is: one source). And every tool in the stack respects that definition:

• GA4 custom dimension lifecycle_stage
• HubSpot/Marketo property lifecycle_stage
• Salesforce contact field Lifecycle_Stage__c

SOURCE attribution on every contact

Alongside the lifecycle stage, every contact carries a source string that identifies the original conversion CTA (campaign_q3_webinar_series, whitepaper_analytics_maturity, linkedin_ads_cxo_retargeting). This string survives tool boundaries.

# Example: create a contact in the ESP layer with full context
curl -sS -X POST \
  -H "api-key: $ESP_API_KEY" \
  -H "content-type: application/json" \
  -d '{
    "email": "j.mueller@example.com",
    "attributes": {
      "SOURCE": "campaign_q3_webinar_series",
      "CAMPAIGN_ID": "camp_20260615_webinar_analytics",
      "LIFECYCLE_STAGE": "Subscriber",
      "FIRST_TOUCH_UTM_SOURCE": "linkedin",
      "FIRST_TOUCH_UTM_MEDIUM": "paid_social"
    },
    "listIds": [12],
    "updateEnabled": true
  }' \
  https://api.esp-vendor.com/v3/contacts

Two attribute fields — SOURCE and CAMPAIGN_ID — that must resurface in every downstream system. When a Salesforce AE opens a deal, these fields are visible on the contact/lead. When marketing builds retargeting audiences, they filter by CAMPAIGN_ID.

Phase 2: The Universal Ingest pipeline #

The second core building block: one technical endpoint for every lead-capture event across every domain, landing page and channel. No form posts directly to HubSpot or the ESP — everyone posts to a Universal Ingest that routes centrally.

Reference implementation (Vercel/Node.js Serverless, also deployable as AWS Lambda or Cloudflare Worker):

// api/ingest.js — universal lead capture endpoint
const FORM_TO_ROUTING = {
  webinar_registration:  { list_id: 12, lifecycle: 'Subscriber' },
  content_download:      { list_id: 15, lifecycle: 'Subscriber' },
  demo_request:          { list_id: 22, lifecycle: 'Lead' },
  pricing_inquiry:       { list_id: 25, lifecycle: 'Lead' },
  enterprise_contact:    { list_id: 28, lifecycle: 'MQL' },  // pre-qualified
};

export default async function handler(req, res) {
  // ... auth, CORS, validation ...

  const {
    email, form, campaign_id, source,
    utm_source, utm_medium, utm_campaign,
    first_name, last_name, company_domain, honeypot,
  } = req.body;

  if (honeypot) return res.status(200).json({ ok: true });

  const routing = FORM_TO_ROUTING[form];
  if (!routing) return res.status(400).json({ ok: false, error: 'invalid_form' });

  // 1. Write to ESP with full attribution context
  await fetch('https://api.esp-vendor.com/v3/contacts', {
    method: 'POST',
    headers: { 'api-key': process.env.ESP_API_KEY, 'content-type': 'application/json' },
    body: JSON.stringify({
      email: email.trim().toLowerCase(),
      attributes: {
        SOURCE: source,
        CAMPAIGN_ID: campaign_id,
        LIFECYCLE_STAGE: routing.lifecycle,
        FIRST_TOUCH_UTM_SOURCE: utm_source,
        FIRST_TOUCH_UTM_MEDIUM: utm_medium,
        FIRST_TOUCH_UTM_CAMPAIGN: utm_campaign,
        COMPANY_DOMAIN: company_domain,
      },
      listIds: [routing.list_id],
      updateEnabled: true,
    }),
  });

  // 2. Fire GA4 conversion event (server-side, survives ad blockers)
  await fetch(`https://www.google-analytics.com/mp/collect?measurement_id=${GA_ID}&api_secret=${GA_SECRET}`, {
    method: 'POST',
    body: JSON.stringify({
      client_id: req.body.client_id,
      events: [{ name: routing.lifecycle === 'Lead' ? 'lead_generated' : 'signup', params: {
        source, campaign_id, lifecycle_stage: routing.lifecycle,
      }}],
    }),
  });

  // 3. Push to CRM if pre-qualified
  if (routing.lifecycle === 'MQL') {
    await createSalesforceLead({ email, first_name, last_name, company_domain, source, campaign_id });
  }

  return res.status(200).json({ ok: true });
}

Three parallel signal streams from one endpoint: ESP for nurturing, GA4 for analytics attribution, CRM for sales handoff. All consistent, all carrying the same SOURCE + CAMPAIGN_ID.

That's the most important move: one endpoint, three layer sinks, consistent semantics.

Phase 3: Analytics-as-Code #

In enterprise setups, GA4 typically gets configured through the UI: an analytics engineer clicks custom dimensions, key events and data streams together. Result: no versioning, no reproducibility across regions/brands, and property migrations lose the config state.

The enterprise move: GA4 configuration via the Admin API, in version control, as part of the deployment process. New regional property? One script run, not a 3-day UI setup.

# ga4-config-apply.sh — reproducible property configuration
TOKEN=$(python3 ga_token.py)
PROP=$1  # numeric property ID

# 1. Data retention → 14 months (default is 2)
curl -sS -X PATCH \
  -H "Authorization: Bearer $TOKEN" \
  -H "content-type: application/json" \
  -d '{"eventDataRetention":"FOURTEEN_MONTHS","resetUserDataOnNewActivity":true}' \
  "https://analyticsadmin.googleapis.com/v1beta/properties/$PROP/dataRetentionSettings?updateMask=eventDataRetention,resetUserDataOnNewActivity"

# 2. Custom dimensions — the enablement taxonomy
for DIM in source campaign_id lifecycle_stage first_touch_utm_source first_touch_utm_medium first_touch_utm_campaign company_domain; do
  curl -sS -X POST \
    -H "Authorization: Bearer $TOKEN" \
    -H "content-type: application/json" \
    -d "{\"parameterName\":\"$DIM\",\"displayName\":\"$DIM\",\"scope\":\"EVENT\"}" \
    "https://analyticsadmin.googleapis.com/v1beta/properties/$PROP/customDimensions"
done

# 3. Key events — the enablement conversion set
for EV in signup lead_generated demo_requested mql_qualified sql_accepted opportunity_created deal_won; do
  curl -sS -X POST \
    -H "Authorization: Bearer $TOKEN" \
    -H "content-type: application/json" \
    -d "{\"eventName\":\"$EV\",\"countingMethod\":\"ONCE_PER_EVENT\"}" \
    "https://analyticsadmin.googleapis.com/v1beta/properties/$PROP/keyEvents"
done

Note: the key events cover the whole lifecycle, not only marketing conversions. sql_accepted, opportunity_created, deal_won get fired back into GA4 from the sales system (via Measurement Protocol), so marketing attribution stays visible in GA4 all the way to the closed deal.

This is the real enablement move: GA4 stops being just a marketing tool and starts being a cross-layer attribution backbone. Sales events flow back, attribution closes.

Phase 4: The Cross-Team Attribution layer #

After Phase 3 you have the technical data layer. Phase 4 is the process work — and it's often the hardest part.

The MQL → SQL handoff contract. Sales and marketing must agree on:

• Definition of an MQL (score threshold, ICP fit, behaviour signal). Documented, versioned, quarterly reviewed.
• SLA for the sales action (max. 24h between MQL trigger and sales outreach).
• Rejection process (sales rejects an MQL → back to marketing with a reason: wrong_persona, no_budget_signal, outside_icp). The reason is a structured field, not a free-text note.

Technically: a Salesforce trigger on lead status change fires an event back to the Command Center backend:

// Salesforce Apex trigger (simplified)
trigger LeadHandoffTrigger on Lead (after update) {
  for (Lead l : Trigger.new) {
    Lead old = Trigger.oldMap.get(l.Id);
    if (l.Status != old.Status) {
      HttpRequest req = new HttpRequest();
      req.setEndpoint('https://command-center.company.com/api/salesforce-webhook');
      req.setMethod('POST');
      req.setBody(JSON.serialize(new Map<String, Object>{
        'lead_id' => l.Id,
        'email' => l.Email,
        'status_old' => old.Status,
        'status_new' => l.Status,
        'rejection_reason' => l.Rejection_Reason__c,
        'campaign_id' => l.Original_Campaign_ID__c,
        'source' => l.SOURCE__c
      }));
      Http h = new Http(); h.send(req);
    }
  }
}

These webhook events get aggregated in the Command Center backend and mixed into the marketing views.

Phase 5: The Orchestration backend #

The backend is the core of the Command Center. A serverless function (or a container deployment, depending on enterprise standard) that reads in parallel from all three layers, aggregates, and returns a canonical JSON response.

Core tasks:

1. GA4 Data API (analytics layer) — sessions, events, attribution paths
2. ESP / marketing automation API (campaign layer) — contacts, list membership, campaign performance
3. CRM API (sales layer) — deals, stages, pipeline value, deal-to-lead mapping
4. Cross-system attribution join — match contacts across the three systems (email as primary key, company domain as backup)

Example response structure — the canonical data layer shared across all three persona views:

{
  "as_of": "2026-07-06T09:00:00Z",
  "kpis": {
    "leads_28d": 340,
    "mqls_28d": 127,
    "sqls_28d": 82,
    "opportunities_open": 23,
    "pipeline_value_open_eur": 4820000,
    "won_deals_qtd": 12,
    "won_value_qtd_eur": 2140000,
    "blended_cac_eur": 12300,
    "roas_qtd": 4.6
  },
  "attribution": {
    "won_deals_by_source": [
      { "source": "campaign_q3_webinar_series",    "deals": 4, "value_eur": 890000 },
      { "source": "linkedin_ads_cxo_retargeting",  "deals": 3, "value_eur": 620000 },
      { "source": "content_analytics_maturity",    "deals": 2, "value_eur": 340000 }
    ]
  },
  "handoff_health": {
    "mql_to_sql_conversion_rate": 0.645,
    "mql_avg_time_to_sales_action_hours": 8.3,
    "sql_rejection_reasons": {
      "wrong_persona": 12,
      "no_budget_signal": 8,
      "outside_icp": 5
    }
  }
}

Sales, marketing and finance render different widgets over the same response — but they see the same numbers.

Phase 6: Multi-Persona Dashboards #

The last layer is the front-end orchestration. Three views, one backend.

Sales view (for AEs and SDR managers):

• Pipeline overview with campaign context per deal
• MQL feed with SOURCE + first-touch context
• Deal attribution: "which campaign triggered which open deal"
• Personal pipeline panel for the individual AE

Marketing view (for demand-gen and campaign owners):

• Campaign performance with deal feedback (MQL→SQL conversion per campaign, not just MQL count)
• Top sources ranked by deal value, not by lead volume
• Rejection reasons as a structured feedback loop
• ROAS per campaign with sales attribution

Exec view (for CFO, CRO, VP Enablement):

• Blended CAC, LTV per cohort, payback period
• Pipeline coverage ratio (pipeline / quota target)
• Marketing-sourced revenue share
• Trend deltas vs. previous quarter

Technically trivial if the backend is built right: same JSON, three HTML layouts, three URL routes (/sales, /marketing, /exec). Auth via SSO against the corporate IdP. Auto-refresh every 60s.

The value isn't in fancier charts — it's in the consistency of the numbers across the three roles. When marketing says "we had 340 MQLs" and sales says "I see 340 MQLs in the Command Center", an attribution argument is over before it starts.

Where internal teams usually fail #

Why don't most enterprises build this themselves? Three recurring patterns from our discovery calls:

Next steps #

If you recognise sales-marketing alignment as a structural problem in your organisation — not a reporting detail — these are the three ways forward:

1. Discovery workshop (2 hours, free). We walk through your current stack, identify the three biggest attribution gaps and quantify the blind spot in your marketing return. Not a sales pitch, concrete analysis. Request a slot →

2. Reference architecture. The full technical blueprint (Universal Ingest, Analytics-as-Code, attribution layer, multi-persona front-end) with Terraform/CDK modules, GA4 config scripts and Salesforce trigger reference. Delivered to your inbox after this signup.

3. Embedded engagement. 4–6 weeks of embedded team. Fixed price, defined scope, transparent weekly deliverables. Request scope →

If you're not sure which route is right: start with the discovery workshop. We'll tell you honestly whether your problem is big enough to justify a 6-week investment — or whether a smaller intervention will do.