How I led a cross-functional data and analytics program spanning 460K+ partner-marketing touches, three enterprise systems, seven currencies, and three global regions — turning fragmented marketing data into a decision platform partner leadership could actually trust. I owned the program end to end: framing the problem, decomposing it into workstreams, aligning technical and business stakeholders, driving the hard technical decisions, and turning a one-off analysis into a repeatable operating capability.
Program at a glance
| My role | Technical Program & Delivery Lead — owned the program from problem framing to operating model |
| Program objective | Give partner leadership one trusted view of what every Market Development Fund (MDF) dollar actually sources |
| Business problem | Partner-marketing investment, CRM pipeline, account identity, geography, currency, and campaign taxonomy were fragmented — so MDF ROI didn’t exist as a number anyone could trust |
| Scale & complexity | 460K+ partner-marketing touches · 3 enterprise systems · 7 currencies → USD · North America / EMEA / Asia Pacific |
| Core technologies | BigQuery · Python (identity resolution) · Salesforce · SAP · Tableau · SQL |
| Primary stakeholders | Partner global / executive leadership · regional geo leaders · regional partner operations · source-system owners |
| Operating cadence | Monthly refresh, match-quality validation, spend & pipeline reconciliation, and publication |
| Automated resolution | ~82–85% of touches resolved automatically; borderline records reviewed by a person, low-confidence records held as an explicit unattributed line |
| Primary outcome | From no trustworthy MDF attribution to a single monthly decision view leadership used to judge partner and regional performance and steer where MDF gets invested |
The business problem
Every cycle, the business funded partner-led demand generation worldwide — events, webinars, telemarketing, campaigns — through a global network of resellers and distributors. Leadership’s question was simple: what does that spend actually return, and where should the next dollar go? The data needed to answer it lived in disconnected pieces.
MDF funding claims lived in the partner-marketing system; the pipeline they were meant to drive lived in the CRM — with no reliable way to connect one to the other.
Customer and partner names in the claims were hand-typed free text — abbreviations, legal suffixes, typos, multiple languages — with no shared key to the CRM’s account master.
Spend spanned seven currencies and three regions, with years of inconsistent free-text taxonomy for activities, objectives, products, and solutions — none of it comparable as-is.
Until the pieces were connected, none of these had a defensible answer. The program existed to make them answerable.
The distinction that framed everything
This was never “we need a dashboard.” The technical solution existed to enable those decisions — and every design choice was judged by whether leadership could trust the answer enough to move money on it.
My role & program mandate
My mandate was to turn an ambiguous business need into an executable, cross-functional technical program — and to keep it trustworthy enough that leadership would act on it. I led the program; I also went hands-on in the technical core where that’s where the program decisions were won.
I used technical depth directly — not to be the engineer of record on everything, but to make better program decisions:
I went deep enough to validate assumptions, understand engineering trade-offs, investigate quality issues, and improve decisions — then led the program around them.
The message in one line
I was technically hands-on where it improved program decisions — but my primary responsibility was leading the program: framing the problem, decomposing the work, aligning the people, driving the technical decisions, and making the whole thing repeatable. I understand the technology deeply enough to challenge assumptions, evaluate trade-offs, and identify risk — not just track engineering work.
Program strategy
“We need to understand MDF ROI” is a sentence, not a plan. I decomposed it into a chain of technical capabilities — each one answering part of the business question and feeding the next. The visual below is deliberately a program decomposition, not just a data flow: every stage is a workstream with its own problem, deliverable, dependency, and exit condition.
Each arrow is also a dependency: get standardization wrong and identity resolution degrades; get identity wrong and attribution can’t be trusted; if attribution can’t be trusted, leadership won’t move money — and the program hasn’t delivered its value. The chain is the reason this was run as a program, not a script.
Stakeholder alignment
This was as much an alignment problem as a technical one. The same numbers meant different things to different groups — and each would only trust the platform if it answered their question. Part of my job was making one model serve all of them without bending the data to any of them.
| Stakeholder | What they cared about | Information they needed | Decision it enabled |
|---|---|---|---|
| Global / executive leadership | Trusted ROI and how regions compare | MDF ROI, partner performance, regional trends | Where to invest MDF next, globally |
| Regional / geo leaders | Their own partners and activities | Regional pipeline, partner performance, exceptions | Local investment and partner management |
| Source / technical owners | Stable definitions and reproducibility | Source mappings, identity logic, quality thresholds, traceability | A reliable, repeatable data foundation |
| Regional partner operations | Defensible attribution behind payouts | The exception queue and match-confidence scores | Verify borderline matches before they count |
The principle that earned trust
Partner leaders had been burned by numbers that didn’t reconcile before. So trust was not created by pretending the data was perfect. It was created by making uncertainty visible and manageable — surfacing match confidence, showing the unattributed slice honestly, and making the same number mean the same thing in every region’s view.
Workstream decomposition
Each workstream solved a distinct problem, produced a specific deliverable, carried a dependency I had to manage, forced a decision, and had an exit condition before the next could safely start. Together they laddered up to the business capability leadership actually wanted.
The story was split across the partner-marketing system, Salesforce, and SAP — each with its own account identifiers.
One place (BigQuery) holding the three sources with their raw fields retained.
Source-owner access. Decided: land raw first, transform downstream — so source data is replayable when logic changes.
All three sources loading reliably → a single foundation to build on.
Free-text geography, seven currencies, and years of inconsistent activity/product taxonomy made nothing comparable.
A clean geo → country → area hierarchy, currency normalized to USD, and a stable taxonomy for activities, objectives, and solutions.
Agreed definitions with source owners. Decided: spend follows claim lifecycle — in-flight claims use the requested amount, closed claims use the paid amount.
Every record comparable like-for-like → global numbers that add up.
Hand-typed, multilingual company names had no key to the CRM. An exact-string join would match almost nothing.
A Python entity-resolution pipeline resolving each touch to exactly one canonical account, with a confidence score.
Depends on clean harmonized input. Decided: country blocking before fuzzy comparison, and confidence thresholds instead of forcing every match.
~82–85% auto-resolved, the rest routed or held → touches tied to real accounts, defensibly.
Even with matches, leadership needed a credit rule they could defend in a review — not a black box.
A rules-based, account-based attribution model: touch → account → that account’s sourced and influenced pipeline.
Depends on trusted matches. Decided: explainable rules over a statistical (Markov / Shapley) model, because every credited dollar has to trace to a specific touch and account.
Every credited dollar traceable → MDF ROI and cost-per-opportunity leaders can stand behind.
A correct model is useless if leaders can’t read the answer to their own question.
A Tableau suite: MDF ROI, sourced pipeline, cost-per-opportunity, by partner, geo, activity, and solution — with match confidence surfaced.
Depends on the attribution model. Decided: tailor the read per audience — global heads see ROI and reallocation; geo leads see their own partners.
Each stakeholder answered in their own view → decisions leadership could actually make.
A number that’s true once and stale next month rebuilds no trust. It had to land reliably every cycle.
A repeatable monthly refresh with match-quality validation, spend and pipeline reconciliation, exception review, and publication.
Depends on all of the above holding. Decided: run it as a standing operating cycle with an enhancement backlog, not a one-off.
Same trusted number, every month → a durable decision capability, not a project artifact.
Technical architecture
The architecture came after the problem, mandate, and workstreams — it exists to serve them. It’s deliberately layered: unify and harmonize the raw data, resolve every touch to a real account, then attribute and report. Here it is source to dashboard — and why it’s shaped this way.
The unglamorous layer — parsing a delimited partner string into a clean geo hierarchy, writing spend logic tied to each claim’s lifecycle, collapsing years of free-text into a stable taxonomy — is what every downstream number depends on. The full mechanics are in the technical deep dive.
Decisions that shaped the program
These are the calls that decided whether leadership would trust the platform. Each was a technical decision with a business consequence — and the point of showing them is not sophistication for its own sake, but that I understood the choices deeply enough to make them defensible on accuracy, cost, explainability, risk, and stakeholder trust.
Leadership had to defend credited ROI in partner reviews. The attribution model had to be trusted and explained.
An explainable rules-based, account-based model — vs. a more “sophisticated” statistical model (Markov / Shapley).
Rules-based, explainable. Every credited dollar traces to a specific touch and account. A black box would have looked smarter and been indefensible in a QBR.
Trades statistical nuance for adoption. The right trade: an attribution number leaders won’t stand behind is worthless, however elegant.
Partner payouts and investment decisions ride on these matches. A wrong match is more damaging than a missing one.
Force every touch to a best-guess account — vs. confidence thresholds with human review and an unresolved bucket.
Thresholds + human-in-the-loop. High confidence auto-resolves; borderline goes to regional partner ops; low confidence is held. A person decides the ambiguous cases, not an algorithm guessing.
Accepts a review workload and a visible unattributed slice — in exchange for a number leadership can trust with money on it.
Comparing every touch against every account is accurate in theory and prohibitively expensive at 460K+ records — and generates cross-country false matches.
Compare every possible pair — vs. country/geographic blocking before fuzzy comparison.
Block by country first. Only compare candidates within the same country. Cuts the comparison space by orders of magnitude — better accuracy and lower compute cost.
Assumes country is reliable enough to block on — handled in harmonization, so the assumption is controlled rather than blind.
Non-Latin-script markets (Japan, Korea, Taiwan, Israel) need translation to compare — but translation is the most expensive step in the pipeline.
Translate/transliterate everything — vs. targeted handling only for the records that actually need it.
Targeted path. Isolate and translate only the small share of non-Latin records, on a separate path — keeping the monthly refresh fast and cheap without losing coverage.
Adds a branch to maintain — worth it: it kept a recurring cost-and-time driver small at scale.
Fuzzy matching on multilingual free text never reaches 100%. A tidy dashboard could hide that; a trustworthy one can’t.
Force 100% attribution for a clean-looking result — vs. an explicit “Unattributed Partner Spend” line.
Keep an honest unattributed bucket. Leaders see the true size of what we couldn’t attribute, so they trust everything above it. An honest gap protects the credibility of the whole platform.
A less “perfect” headline — deliberately. Credibility mattered more than a falsely clean 100%.
Dependency management
This program was a chain, and the chain was only as strong as its weakest link. Managing those interdependencies — in business language, not just technical — was the core of the delivery job.
The chain in business language
If harmonization is wrong, matching quality falls. If account matching is wrong, attribution becomes unreliable. If attribution is unreliable, the analytics can’t be trusted. And if leadership doesn’t trust the analytics, the technical program hasn’t delivered its intended business value — no matter how well the pipeline runs.
| Dependency | Why it matters | Downstream impact if it fails | Program risk | Control |
|---|---|---|---|---|
| Source availability | No data, no program | Nothing refreshes | Cycle slips | Monthly intake check before the run |
| Harmonization | Everything compares on it | Silent match & comparison errors | Invisible degradation | Taxonomy & currency validation |
| Identity resolution | The make-or-break join | Attribution unreliable | False positives | Confidence thresholds + human review |
| CRM / pipeline connection | Turns matches into value | No pipeline to credit | Stale account links | Reconciliation against CRM each cycle |
| Reconciliation | Proves the numbers | Distrusted output | Unexplained variance | Spend & pipeline reconciled before publish |
Risk, quality & program controls
The central risk here wasn’t a failed pipeline run — it was a confident wrong answer. Leadership was moving investment on this output, so I treated identity resolution as program risk, not just an engineering task.
The principle that set the quality bar
A false positive was more dangerous than an unresolved record — because a wrong match quietly credits the wrong partner and skews an investment decision, while an unresolved record is at least visibly unknown. So the whole control model was built to avoid confident wrong answers, not just to maximize match rate.
High confidence
Automatic resolution. Clear, high-scoring matches resolve without a human — roughly 82–85% of records.
Medium confidence
Human-in-the-loop review. Records scoring ~0.60–0.79 route to regional partner operations to verify — a person, not a guess.
Low confidence
Held as unattributed. Below ~0.60, tagged “Unattributed Partner Spend” rather than force-matched — visible, not hidden.
| Risk | Business impact | Preventive control | Detection | Exception / fallback |
|---|---|---|---|---|
| False-positive match | Wrong partner credited; skewed investment | Confidence thresholds; harmonic-mean scoring | Match-confidence score in the output | Human review below threshold |
| Missing identifiers | Records can’t resolve | Multiple signals (name, domain, tax/VAT ID) | Unresolved-rate tracking | Held as unattributed |
| Multilingual records | APAC touches under-attributed | Targeted translation path | Per-region resolution rates | Review queue for the residue |
| Taxonomy / currency drift | Regions stop being comparable | Stable taxonomy; currency → USD | Cross-region reconciliation | Correct & re-publish |
| Silent quality degradation | Distrust builds unnoticed | Monthly QA & reconciliation gates | Variance vs. prior cycle | Investigate before publish |
| Stakeholder distrust | Platform ignored | Surface confidence & the unattributed line | Stakeholder feedback | Make the seams visible, not hidden |
The ~82–85% figure is an automated resolution rate — the share of records that matched confidently without human review — not a validated “model accuracy.” The long tail wasn’t hidden; it was routed to review or shown as an explicit unattributed line.
From project to operating model
A senior program isn’t “get it working once.” It’s a mechanism that lands reliably every cycle and keeps earning trust. I converted the technical solution into a standing monthly operating model with validation gates and a managed backlog.
| Dimension | How I ran it |
|---|---|
| Cadence | A monthly refresh + QA cycle — re-run the pipeline, validate match quality, reconcile spend and pipeline, publish the updated Tableau suite. |
| Validation gates | Match-quality validation and spend/pipeline reconciliation had to pass before anything was published — no unreconciled number reached leadership. |
| Exception handling | Borderline matches worked through the review queue; unresolved records carried forward as the explicit unattributed line. |
| Backlog & roadmap | Ran the roadmap, refresh schedule, and enhancement backlog in Asana, and mapped it into the wider program plan in Microsoft Project so it stayed visible alongside the broader partner-marketing calendar. |
| Stakeholder comms | Tailored the read per audience and surfaced match confidence in the dashboard — credibility comes from showing the seams, not hiding them. |
The takeaway
I converted a technical solution into a repeatable operating capability — the same trusted number, every month, with the gates and backlog that keep it trustworthy as the data and the questions evolve.
Outcomes
I separate what was delivered from what the business could decide — and I’m deliberate about not inflating either.
One unified model
Three enterprise systems — partner marketing, Salesforce, SAP — joined into a single MDF attribution model.
460K+ touches resolved
Free-text, multilingual partner-marketing touches resolved to canonical CRM accounts, with confidence and an honest unattributed line.
A standing capability
A monthly-refresh Tableau suite with reconciliation gates, an exception process, and a managed enhancement backlog.
Comparable, global data
Seven currencies to USD and years of free-text collapsed into a stable taxonomy — regions finally comparable like-for-like.
Defensible attribution
~82–85% of touches auto-resolved, on an explainable rules-based model where every credited dollar traces to a touch and account.
Visible uncertainty
Match confidence and an explicit unattributed slice built into the output — trust through transparency, not false precision.
MDF ROI, finally
Spend tied to sourced and influenced pipeline — by partner, geo, activity, and solution — instead of disconnected spreadsheets.
Efficiency, not just totals
Cost-per-opportunity and cost-per-won-opportunity showed which partners and activities returned most per MDF dollar.
Promise vs. reality
A “solutions promoted vs. products actually purchased” view exposed where funded campaigns and real buying diverged.
Repeatable, not heroic
A monthly operating cycle anyone could rely on — not a number that was true once and stale after.
Trust that compounded
The same number meant the same thing in every region’s view, cycle after cycle — which is how distrust turned into reliance.
A managed backlog
Enhancements prioritized and delivered over time, so the capability improved instead of decaying.
The shape of the monthly MDF-ROI view partner leaders used to decide where the next dollar went — MDF invested against sourced pipeline, opportunities, and cost-per-opportunity, by partner. The numbers below are illustrative sample values to show the layout, not validated enterprise results.
The honest version of the impact
I won’t attach an inflated ROI multiple to this. What’s true and defensible: partner leadership went from no trustworthy MDF attribution to a single monthly view — 460K+ touches resolved, three systems and seven currencies reconciled — that they used to judge partner and regional performance and steer where MDF gets invested. The sample dashboard figures above illustrate the layout, not a validated business result.
What this program taught me
Here: partner leaders had been burned by numbers that didn’t reconcile, so a “correct” model wasn’t enough — I had to make confidence and uncertainty visible to earn adoption. At larger scale: I’d treat trust as a first-class deliverable of any data-platform program — with reconciliation, transparency, and stakeholder validation planned in, not bolted on.
Here: an explicit “unattributed” line protected the credibility of everything above it — a falsely clean 100% would have quietly destroyed trust. At larger scale: I’d bake confidence scoring and honest gaps into platform outputs by design, so consumers always know how much to rely on a number.
Here: “understand MDF ROI” became six workstreams with their own problems, dependencies, decisions, and exit conditions. At larger scale: that decomposition discipline is exactly how I’d take a multi-team platform program from a vague mandate to an executable plan with clear ownership and sequencing.
Here: I chose explainable rules over a fancier statistical model because leaders had to defend the number — the “less sophisticated” choice was the right one. At larger scale: I’d keep anchoring architecture and tooling decisions to the business decision they enable, resisting complexity that doesn’t earn its keep.
Here: the value came from a repeatable monthly cycle with gates and a backlog, not a one-time analysis. At larger scale: I’d plan the transition to a standing operating model — cadence, quality gates, ownership, and enhancement backlog — as part of the program, not an afterthought.
Technical deep dive · under the hood
The program story stands on its own above. This section is for a technical reviewer who wants to confirm the depth is real. Expand what you want to inspect.
| Step | What it does | Why |
|---|---|---|
| Cleanse | Strip legal suffixes and punctuation; remove any word appearing in >0.5% of names. | Removes noise (“Inc”, “GmbH”, “Technologies”) that would inflate false matches. |
| Standardize | Convert every country to a clean ISO-2 code; translate non-Latin names to Latin script. | Lets an APAC touch and a US account name be compared on the same footing. |
| Block | Only compare candidates within the same country (sorted-neighbourhood indexing). | Cuts the comparison space by orders of magnitude — accuracy and compute cost. |
| Score | Six similarity metrics — Jaro-Winkler, Damerau-Levenshtein, token-set and partial ratios over two cleansing passes — combined by harmonic mean. | Harmonic mean punishes any single weak signal, so one flattering metric can’t carry a bad match. |
| Resolve | Add a composite city/country tie-break, rank, and keep the single best account per touch. | One touch resolves to exactly one account — no double-counting downstream. |
Before anything could be matched, the raw claim data had to be made trustworthy. In BigQuery I parsed a delimited partner-level string into a clean geo → country → area hierarchy across the three theaters; wrote MDF-spend logic tied to each claim’s lifecycle status (in-flight claims use the requested amount, closed claims use the paid amount); and collapsed years of inconsistent free-text — activity types, business objectives, product and solution names — into a stable taxonomy. Unglamorous, but every downstream number depends on it.
The unit: one MDF-funded partner-marketing touch (event, webinar, telemarketing push, or campaign), carrying its funding claim and spend. The join: each touch is resolved to a canonical CRM account, then joined to that account’s pipeline and opportunities. The credit rule: a touch that reached an account is credited with the pipeline that account generated — sourced or influenced — in the window; because one touch resolves to exactly one account, nothing is double-counted. The efficiency lens: MDF investment ÷ opportunities from touched accounts gives cost-per-opportunity and cost-per-won-opportunity — the numbers leaders use to compare partners and activities. It’s deliberately a rules-based, account-based model, not a statistical one, so every credited dollar is explainable.
| Automated match rate | Roughly 82–85% resolved confidently through automated fuzzy matching and domain pairing on clean or semi-structured fields — using tokenization, edit-distance scoring, and normalization for legal suffixes, tax/VAT identifiers, and email domains. |
| Long tail (15–18%) | Multi-byte characters in APAC claims, non-standard abbreviations, and records missing a domain or tax ID couldn’t resolve safely without risking false positives. |
| Human-in-the-loop | Records scoring 0.60–0.79 routed to an exception queue for regional partner operations to verify manually — borderline cases went to a person, not an algorithm guessing. |
| Below 0.60 | Tagged “Unattributed Partner Spend” rather than force-matched — shown as its own line so leadership sees the true size of what couldn’t be attributed. |
Non-Latin-script markets (Japan, Korea, Taiwan, Israel) were pulled and translated on a separate path rather than translating everything — translation is the most expensive step, so isolating the small share of records that actually need it kept the monthly refresh fast and cheap without losing coverage. Blocking by country before fuzzy comparison then cut the candidate space dramatically, which improved both accuracy (no cross-country false matches) and compute cost.