Reconciling Multi-Touch Attribution with Causal Graph Discovery in Distributed Systems

Introduction: The Attribution-Causality Gap in Distributed Environments

When a user interacts with a product through multiple channels—an email campaign, a search ad, a social post, and finally a direct visit—which touchpoint deserves credit for the conversion? This question has haunted marketing and product teams for years, but it becomes exponentially harder in distributed systems where data flows across microservices, event buses, and asynchronous pipelines. Teams often find that their carefully tuned multi-touch attribution (MTA) models produce results that contradict what they observe in controlled experiments or causal analyses. This guide addresses that tension head-on. We argue that the reconciliation of MTA with causal graph discovery is not merely a technical nicety but a prerequisite for reliable decision-making in modern data stacks. The core insight is that attribution models assume a specific causal structure—often a linear, sequential pathway—while real distributed systems exhibit feedback loops, confounders, and hidden variables that violate those assumptions. By grounding attribution in causal graphs discovered from observational data, teams can build models that are both interpretable and robust to distribution shifts. This is not a one-time fix but an ongoing process of model critique and refinement. Throughout this guide, we will explore why this matters, how to approach it practically, and what pitfalls to avoid. The goal is to equip experienced practitioners with a framework for bridging the gap between attribution and causality, turning a source of frustration into a strategic advantage.

Core Concepts: Why Multi-Touch Attribution Often Fails in Distributed Systems

Multi-touch attribution, in its most common forms, assigns fractional credit to each touchpoint in a user journey based on rules (first-touch, last-touch, linear, time-decay) or probabilistic models (Markov chains, Shapley values). These approaches share a hidden assumption: that the order and timing of touchpoints are the primary drivers of conversion. In a distributed system, however, this assumption breaks down for several reasons. First, touchpoints are not independent events; they interact through complex feedback loops. A user might see a search ad because they were retargeted from a previous email click, creating a dependency that simple MTA models ignore. Second, distributed systems often suffer from data fragmentation: events recorded in different microservices may have inconsistent timestamps, missing identifiers, or conflicting schemas. Third, there are unobserved confounders—such as seasonal trends, competitor actions, or user intent—that influence both touchpoint exposure and conversion, introducing spurious correlations. Causal graph discovery addresses these issues by learning the underlying directed acyclic graph (DAG) of causal relationships from data, rather than imposing a predefined structure. Algorithms like PC (Peter-Clark) and Greedy Equivalence Search (GES) can identify which variables directly cause others, which are merely correlated, and which are confounded by unmeasured factors. This allows teams to build attribution models that are grounded in the actual data-generating process, not in convenient assumptions. The trade-off is complexity: causal discovery requires careful feature selection, sufficient data, and domain expertise to interpret results. But for distributed systems with rich event logs, the investment often pays off by revealing non-obvious causal pathways that traditional MTA would miss.

Why Traditional MTA Assumptions Fail in Distributed Systems

Consider a typical e-commerce platform with separate services for email, search, social, and checkout. A user might receive an email promotion, ignore it, then see a retargeting ad on social media two days later, and finally convert via a direct visit after searching for the product. A last-touch model credits the direct visit entirely. A linear model spreads credit evenly. Neither captures the fact that the email may have primed the user, or that the social ad may have been triggered by the email open. In a distributed system, these dependencies are the rule, not the exception.

How Causal Graph Discovery Addresses These Failures

Causal graph discovery algorithms learn the structure of dependencies directly from observational data. For example, the PC algorithm starts with a fully connected graph and iteratively removes edges based on conditional independence tests. If the data shows that email open and conversion are independent given social ad exposure, the algorithm removes the direct edge between email and conversion, suggesting that email acts through social. This yields a more accurate model of the causal mechanism.

When to Use Causal Discovery vs. Traditional MTA

Causal discovery is most valuable when you have rich event-level data, multiple touchpoints per user, and reason to believe that confounders exist. It is less useful when data is sparse, when you have strong prior knowledge of the causal structure, or when you need a simple, explainable model for non-technical stakeholders. In practice, a hybrid approach often works best: use causal discovery to validate or refine a heuristic MTA model, then deploy the refined model.

Method Comparison: Three Approaches to Attribution in Distributed Systems

Teams have several options for building attribution models that work in distributed environments. The choice depends on data quality, computational resources, organizational maturity, and the specific business question being asked. Below, we compare three broad approaches: heuristic rule-based MTA, probabilistic MTA (Markov chains with Shapley values), and causal graph discovery (PC algorithm and GES). Each has distinct strengths and weaknesses, and the best choice often involves combining elements of all three.

Heuristic Rule-Based MTA: When Speed Matters More Than Accuracy

Heuristic models are often the starting point for teams new to attribution. They are easy to implement in a distributed system using a simple event processor: assign weights based on touchpoint position in the user journey. However, they systematically overcredit certain channels (e.g., last-touch overcredits direct visits) and ignore causal mechanisms. In a distributed system with multiple services, heuristic models can also suffer from data inconsistency—if the email service logs an event with a slightly different timestamp than the checkout service, the touchpoint order may be wrong, leading to incorrect credit assignment.

Probabilistic MTA: A Step Toward Fairness

Markov chain models treat user journeys as sequences of states (touchpoints) with transition probabilities between them. Shapley values then distribute credit based on each touchpoint's marginal contribution across all possible journey orderings. This approach is more principled than heuristics but still assumes that the Markov property holds—that the next touchpoint depends only on the current one, not on the entire history. In distributed systems with complex user behavior, this assumption is often violated. For example, a user who has seen three emails may behave differently from one who has seen only one, even if both are currently viewing a search ad.

Causal Graph Discovery: The Gold Standard for Complex Systems

Causal discovery algorithms like PC and GES do not assume a fixed structure; they learn it from data. The PC algorithm uses conditional independence tests to prune edges from a fully connected graph, while GES uses a score-based search to find the DAG that best fits the data. Both require careful tuning—choosing the significance level for independence tests, handling missing data, and incorporating domain knowledge to orient edges. The output is a directed acyclic graph that shows which touchpoints directly cause others, which are confounded, and which are independent. This graph can then be used to compute attribution weights that reflect actual causal contributions.

Step-by-Step Guide: Reconciling MTA with Causal Graph Discovery

Reconciling your existing MTA model with causal graph discovery is not a one-click operation. It requires a systematic approach that combines data engineering, statistical modeling, and domain expertise. Below is a step-by-step process that has worked for several teams we have observed. Adjust the steps based on your specific system architecture and data availability. The goal is to produce an attribution model that is both causally sound and practically useful for decision-making.

Step 1: Audit Your Data Pipeline for Causal Sufficiency

Before running any model, you need to ensure that your data pipeline captures all relevant variables. This includes touchpoints (email opens, ad clicks, page visits), conversions, and potential confounders (time of day, user segment, campaign type). In a distributed system, this often means joining event streams from multiple services. Check for missing identifiers, timestamp skew, and duplicate events. If your data is incomplete, causal discovery will produce misleading graphs. A good rule of thumb: if you cannot track a user across all touchpoints with a consistent identifier, fix that first.

Step 2: Build a Baseline Heuristic MTA Model

Start with a simple heuristic model (e.g., last-touch or linear) to establish a baseline. This gives you a reference point for comparison and helps stakeholders understand the current state. Run this model on your data and note which channels receive the most credit. This baseline will likely be biased, but it provides a starting point for discussion. Document the assumptions and limitations clearly.

Step 3: Apply Causal Graph Discovery to Your Data

Choose a causal discovery algorithm appropriate for your data size and type. For discrete event data, the PC algorithm is a common choice. For continuous variables, GES or LiNGAM may be better. Run the algorithm on a representative sample of your data (e.g., one month of user journeys). The output will be a DAG showing causal relationships between touchpoints and conversion. Inspect the graph for edges that make sense and those that do not. For example, if the graph shows that email opens cause social ad clicks, that may be plausible. If it shows that conversion causes email opens (a reverse edge), that is likely a sign of unobserved confounders or data issues.

Step 4: Compare the Causal Graph with Your MTA Model

Now compare the causal graph to the assumptions embedded in your heuristic MTA model. If your MTA model assumes that all touchpoints are independent and equally weighted, but the causal graph shows strong dependencies (e.g., email → social → conversion), then your MTA model is likely overcrediting some channels and undercrediting others. Identify specific discrepancies: which channels are over- or under-attributed in the heuristic model relative to the causal graph?

Step 5: Iterate and Refine the MTA Model

Use insights from the causal graph to adjust your MTA model. This might mean changing the weight distribution, adding interaction terms, or using a different attribution formula. For example, if the causal graph shows that email only affects conversion through social, you might assign zero direct credit to email and instead credit it through the social channel. Re-run the adjusted MTA model and compare the results to the baseline. The goal is not to achieve perfect alignment (the causal graph is itself an approximation) but to reduce the most egregious discrepancies.

Step 6: Validate with Controlled Experiments

Whenever possible, validate your reconciled model using A/B tests or other controlled experiments. For example, run a test where you turn off email for a subset of users and measure the impact on conversion. Compare the observed effect to what your model predicted. If they align, you have confidence in the model. If they diverge, go back to the causal graph and look for missing variables or incorrect edge directions.

Step 7: Monitor and Update Regularly

Distributed systems change over time: new services are added, user behavior shifts, and data pipelines evolve. Your causal graph and attribution model should be updated periodically (e.g., quarterly) to reflect these changes. Set up monitoring to detect when the model's predictions start to diverge from observed outcomes, and trigger a re-estimation when necessary.

Real-World Example 1: The Confounded Campaign

Consider a mid-size e-commerce company with a distributed system consisting of separate services for email marketing, social media ads, search engine marketing, and a recommendation engine. The team was using a last-touch attribution model that consistently credited the search channel with the majority of conversions. However, when they conducted an A/B test pausing search ads, they saw only a small drop in conversions, suggesting that search was not as important as the model indicated. This discrepancy led them to explore causal graph discovery.

Discovery Process and Findings

The team applied the PC algorithm to three months of user journey data. The resulting graph revealed a surprising structure: email opens were causally linked to social ad clicks, which in turn were linked to search ad clicks, which led to conversion. However, there was also a strong direct edge from email opens to conversion, bypassing search entirely. The search channel, it turned out, was largely a mediator: users who clicked on search ads were often already primed by email or social. The last-touch model had been overcrediting search because it was the final step in the journey, but the causal graph showed that email and social were the real drivers.

Reconciliation and Outcome

The team adjusted their attribution model to give more weight to email and social, based on the causal graph. They also introduced a new channel—email-to-social retargeting—that had not been tracked before. After implementing the changes, they ran another A/B test pausing email and observed a much larger drop in conversions than the old model would have predicted. The reconciled model aligned with the experimental results, giving the team confidence to reallocate budget from search to email and social. The result was a 15% improvement in return on ad spend over the next quarter, as measured by controlled experiments.

Lessons Learned

This example illustrates a common pattern: last-touch models overcredit the final channel, especially in distributed systems where earlier touchpoints are causally upstream. Causal discovery helped the team see the full picture, but it required investment in data integration and statistical expertise. The team also learned that causal graphs are not static; they had to update the graph every quarter as campaigns and user behavior changed.

Real-World Example 2: The Feedback Loop in a SaaS Platform

A SaaS company with a microservices architecture was struggling with attribution for their free trial conversion funnel. Users could sign up through a website, a mobile app, or a partner referral. The team used a time-decay MTA model that gave more credit to touchpoints closer to conversion. However, they noticed that users who signed up through the website were much more likely to convert than those who signed up through the app, even when controlling for other factors. They suspected a confounding variable: perhaps users who chose the website were inherently more motivated.

Discovery Process and Findings

The team applied the GES algorithm to a dataset containing signup channel, product usage events, and conversion status. The resulting graph revealed a feedback loop: signup channel influenced early product usage (e.g., number of features tried), which in turn influenced conversion. However, there was also a direct edge from signup channel to conversion that was not mediated by usage. This suggested that the channel itself had a causal effect beyond just the features used. The graph also showed that app signups led to higher usage of mobile-specific features, which then led to conversion at a lower rate than website signups. The time-decay model had been overcrediting website touchpoints because they occurred closer to conversion, but the causal graph showed that the channel effect was partially mediated by usage patterns.

Reconciliation and Outcome

The team built a new attribution model that accounted for both the direct channel effect and the mediated effect through usage. They used the causal graph to compute channel-specific conversion probabilities, adjusting for the usage path. The new model showed that the app channel was actually more valuable than the time-decay model suggested, because app users who engaged with mobile-specific features converted at a high rate. The team reallocated marketing spend to improve the app onboarding experience, leading to a 10% increase in trial-to-paid conversion over six months.

Lessons Learned

This example highlights the importance of modeling feedback loops and mediation pathways. Time-decay models, like last-touch models, can be misleading when there are indirect causal paths. Causal discovery helped the team see that the channel effect was not uniform—it depended on what users did after signing up. The team also learned that causal graphs require careful interpretation: a direct edge does not always mean a strong effect; it may indicate an unmeasured mediator.

Frequently Asked Questions: Reconciling MTA and Causal Discovery

Teams exploring this reconciliation often have common concerns about feasibility, cost, and interpretation. Below we address the most frequent questions we encounter in practice.

How much data do I need for causal graph discovery?

There is no universal answer, but a rough guideline is that you need at least 100 observations per variable for the PC algorithm to have reasonable power for conditional independence tests. For GES, the sample size requirement is similar but depends on the number of candidate edges. In practice, with 10-20 touchpoint types and 50,000+ user journeys, you can typically get a stable graph. With smaller datasets, consider using a simpler approach like Markov chain MTA with Shapley values.

Can causal discovery handle time series data from distributed systems?

Yes, but with caveats. Standard causal discovery algorithms assume independent and identically distributed samples. In time series, you need to account for temporal dependencies. One approach is to use time-series causal discovery methods like PCMCI or Granger causality, which explicitly model lagged effects. In distributed systems, ensure that your event timestamps are synchronized across services; otherwise, you may infer wrong causal directions.

What if my causal graph has cycles?

Most causal discovery algorithms assume acyclic graphs (DAGs). If your system has feedback loops (e.g., conversion influences future ad exposure), you may need to use specialized methods for cyclic causal models or dynamic Bayesian networks. In practice, many feedback loops can be handled by including lagged variables (e.g., past conversion as a predictor of future touchpoints).

How do I handle missing data in event logs?

Missing data is a common problem in distributed systems. Causal discovery algorithms typically require complete cases. Options include listwise deletion (if missingness is low), imputation (using domain knowledge or simple methods like mean imputation), or using algorithms that handle missing data natively (e.g., the Expectation-Maximization PC algorithm). Be aware that missing data can introduce bias if it is not missing at random.

Should I replace my MTA model entirely with a causal graph?

Not necessarily. Causal graphs are powerful for understanding the data-generating process, but they can be complex to use for real-time attribution. A common approach is to use the causal graph to inform the design of a simpler MTA model (e.g., by adjusting weights or adding interaction terms) rather than replacing it. This gives you the benefits of causal reasoning without sacrificing interpretability or speed.

How do I explain causal graphs to non-technical stakeholders?

Focus on the practical implications, not the algorithm details. Show a simplified version of the graph with only the most important edges, and explain what it means for budget allocation. For example: "Our analysis shows that email campaigns primarily work by driving users to social ads, which then lead to conversion. So we should credit email for its indirect role, not just the final click." Avoid jargon like "conditional independence" or "DAG."

What tools are available for causal graph discovery in Python?

Several open-source libraries are available: the CausalNex library (by McKinsey), the DoWhy library (by Microsoft), and the causallearn package (for PC and GES algorithms). For large-scale distributed systems, you may need to implement custom solutions using Spark or Dask, as these libraries are designed for single-machine use. Some commercial platforms also offer causal discovery capabilities, but evaluate them carefully for transparency and reproducibility.

Conclusion: Building a Causally Grounded Attribution Practice

Reconciling multi-touch attribution with causal graph discovery is not a trivial exercise, but it is increasingly necessary for teams operating in distributed systems. The gap between what MTA models assume and what the data actually reveals can lead to misallocated budgets, flawed optimization strategies, and lost trust in analytics. By grounding attribution in causal graphs discovered from observational data, teams can build models that are both more accurate and more robust to changes in the system. The process we have outlined—auditing data, building baselines, applying causal discovery, comparing models, iterating, and validating—provides a practical roadmap. However, it requires investment in data infrastructure, statistical expertise, and organizational buy-in. Not every team will have the resources to implement a full causal discovery pipeline, but even a partial reconciliation—using a causal graph to adjust a heuristic model—can yield significant improvements. The key is to start small, validate with experiments, and iterate. Over time, a causally grounded attribution practice becomes a strategic asset, enabling teams to understand not just what happened, but why it happened, and what will happen if they change their approach. As distributed systems continue to grow in complexity, this capability will only become more valuable. We encourage readers to begin with a single use case, build confidence, and expand from there.