加入新推出的
Discord 社区,展开实时讨论,获得同行支持,并直接与 Meridian 团队互动!
评估基准
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
基准是指在所有处理变量均设置为基准值的反事实情景下的预期结果。对于付费媒体和自然媒体,基准值为零。对于非媒体处理变量,基准值可设置为观测到的变量最小值(默认)、最大值或用户提供的浮点值。估计基准值有助于了解如果不参与付费媒体、自然媒体或其他非媒体处理,会出现什么结果。这对于处理的因果推理是必要的,因此评估基准非常重要。
评估基准是否为负值
结果(收入或 KPI,详见术语库)不能为负。因此,基准为负表示处理效应的因果推理存在统计误差。与所有统计模型一样,Meridian 中可能也会出现一些统计误差。不过,如果基准是极低的负值,则表明存在严重误差。
如果模型结果出现极低的负基准值,则表明模型需要调整。这就给出了一个明确的信号,即模型设置、用于拟合模型的数据或先验需要进行调整(详见减少出现基准为负或偏低的情况)。这就要求在模型开发过程中进行更彻底的迭代,最终得到一个更准确、更可靠且更有洞察力的模型。
Meridian 是一种统计和概率模型。我们建议利用这一特性,从概率上评估基准为负值的可能性。具体而言,应考虑在整个时间窗口内汇总的基准为负的后验概率。如果这个概率过高,则模型结果可能会存在较大的统计误差。您可以用下面的方法计算此概率:
from meridian.analysis import analyzer
from meridian.model import model
import numpy as np
mmm = model.Meridian(...)
mmm.sample_posterior(...)
a = analyzer.Analyzer(mmm)
posterior_baseline_draws = a._calculate_baseline_expected_outcome()
posterior_negative_baseline_prob = np.mean(posterior_baseline_draws < 0)
或者,您也可以检查在整个时间窗口内汇总的基准的点估计值,如渠道贡献图中所示。不过,请注意,Meridian 是一种统计和概率模型,点估计值可能具有很大的不确定性。负基准点估计值不一定表示模型存在偏差,但一定表示存在误差,而误差可能源自偏差或方差(详见均方误差的偏差-方差分解)。当数据包含的信息有限时,这种情况尤其明显(详见所需数据量)。
我们建议不要过度强调基准时间序列,例如模型拟合图中偶尔会降至负值的时间序列。偶尔出现的(尤其是小幅)下降表示存在微小误差,任何统计模型都难免会出现这种误差。
负基准与贡献率百分比
“总贡献率超过观测结果的 100%”(如果增量结果超过观测结果,就会出现这种情况)与“负基准”(如果增量结果超过预期结果,就会出现这种情况)之间存在细微差别。总预期结果的后验分布通常会紧密围绕总观测结果分布,但预期结果的先验分布往往具有较大方差且不以观测结果为中心。因此,评估负基准的先验概率意义不大,这就是为什么我们建议改为评估贡献率超过观测结果 100% 的概率。
另请注意,如果您的模型使用具有高方差的 revenue_per_kpi
值,则总预期结果可能与总观测结果不同。通常情况下,总预期 KPI 与总观测 KPI 高度接近,但 revenue_per_kpi
的高方差可能会导致总预期结果与总观测结果之间存在差异。
减少出现基准为负或偏低的情况
第一步,计算总处理贡献率超过总观测结果 100% 的先验概率:
from meridian.model import model
from meridian.analyzer import analyzer
import numpy as np
mmm = model.Meridian(...)
mmm.sample_prior(1000)
a = analyzer.Analyzer(mmm)
outcome = mmm.kpi
if mmm.revenue_per_kpi is not None:
outcome *= mmm.revenue_per_kpi
total_outcome = np.sum(outcome)
prior_contribution = a.incremental_outcome(use_posterior=False) / total_outcome
total_prior_contribution = np.sum(prior_contribution, -1)
np.mean(total_prior_contribution > 1, (0, 1))
接下来,计算每个单独处理的贡献率超过 100% 的先验概率:
np.mean(prior_contribution > 1, (0, 1))
如果这些先验概率过高,尤其是当数据包含的信息有限时(详见后验与先验相同时),可能会出现负基准问题。可以考虑对先验进行以下调整,然后使用前面所述的检查方法重新评估自定义先验:
- 负基准相当于处理效应获得过多功劳。若要缓解这种情况,可为处理效应设置自定义先验(请参阅如何选择处理变量的先验类型),以降低总处理贡献率超过总观测结果 100% 的先验概率。具体而言,自定义
contribution
先验类型可能比较合适。
- 如果渠道的支出和投资回报率 (ROI) 都很高,则可能表示该渠道带来了超过 100% 的结果,从而导致基准为负。例如,如果您的结果是收入,而某个渠道的支出占总收入的 20%,那么 ROI 为 5.0 表示该渠道带来了 100% 的收入,即该渠道的贡献率为 100%。实际 ROI 可能远低于 5.0,而设置先验 ROI 来反映这一点有助于防止基准为负的情况。根据经验,渠道的第 90 个百分位 ROI 先验不应暗示该渠道的贡献率超过 100%。
- 如果付费媒体获得过多的功劳,可以考虑根据媒体总贡献率来设置 ROI 先验,这样媒体总贡献率大于 100% 的先验概率就会较低。如需了解详情,请参阅设置媒体总贡献率先验。
除了调整先验之外,还有一些其他可能的原因需要调查:
- 模型没有足够的优质控制变量,即对媒体投放和响应都有影响的控制变量。可以考虑添加更多有意义的控制变量,或在合理的情况下添加按人口比例缩放的控制变量,如搜索查询量。默认情况下,Meridian 不会按人口比例缩放控制变量。如需按人口比例缩放控制变量,请在
ModelSpec
中使用 control_population_scaling_id
。
- 模型无法充分解释时间效应。可以考虑增加
knots
,或选择更合适的结位置。
评估基准的趋势和季节性变化
评估基准时间序列(例如模型拟合图中的时间序列)是否与基本需求的预期趋势和季节性变化相符。如果基准未在预期时间段内捕捉到趋势或季节性变化,可考虑在这些时间段周围选择更多的结。为此,您可以将 knots
设置为一个列表,用于指定结的位置。此外,还要考虑可以解释基本需求趋势或季节性变化的控制变量。详见控制变量。
如未另行说明,那么本页面中的内容已根据知识共享署名 4.0 许可获得了许可,并且代码示例已根据 Apache 2.0 许可获得了许可。有关详情,请参阅 Google 开发者网站政策。Java 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-08-16。
[null,null,["最后更新时间 (UTC):2025-08-16。"],[],["The baseline, representing the expected outcome without treatments, should not be negative, as negativity indicates statistical error. An extremely negative baseline signals the need to adjust model settings, data, or priors. Evaluate the probability of a negative baseline probabilistically, and check the prior probability of negative baselines and treatments exceeding 100% contribution. Mitigation strategies involve adjusting treatment effect priors, setting realistic ROI priors, adding controls, and refining time effect modeling via knots. Additionally it is important to check the baseline for appropriate trends and seasonality.\n"],null,["# Assess the baseline\n\nThe baseline is the expected outcome in the counterfactual scenario where all\ntreatment variables are set to their baseline values. For paid and organic\nmedia, the baseline values are zero. For non-media treatment variables, the\nbaseline value can be set to the observed minimum value of the variable\n(default), the maximum, or a user-provided float. Estimating the baseline allows\none to understand what would have happened if they did not engage in paid media,\norganic media, or other non-media treatments. It is necessary for the causal\ninference of the treatments, and thus, it is important to assess the baseline.\n\nAssess the baseline for negativity\n----------------------------------\n\nThe outcome (either revenue or the KPI, see\n[Glossary](/meridian/docs/basics/glossary)) cannot be negative. Therefore, a\nnegative baseline indicates statistical error in the causal inference of the\ntreatment effects. Like all statistical models, we expect some statistical error\nin Meridian. However, an extremely negative baseline indicates extreme\nerror.\n\nA model result with an extremely negative baseline reveals that the model needs\nadjustment. This provides a clear signal that model settings, data used to fit\nthe model, or priors ought to be adjusted (see\n[Mitigate negative or low baseline](/meridian/docs/advanced-modeling/baseline#mitigate-negative-baseline)).\nThis compels a more thorough and iterative model development process, ultimately\nleading to a more accurate, reliable, and insightful model.\n\nMeridian is a statistical and probabilistic model. We recommend taking\nadvantage of this by assessing the negativity of the baseline probabilistically.\nSpecifically, consider the posterior probability that the baseline aggregated\nover the entire time window is negative. If this probability is too high, then\nthe model result may have large statistical error. You can calculate\nthis probability with the following: \n\n from meridian.analysis import analyzer\n from meridian.model import model\n import numpy as np\n\n mmm = model.Meridian(...)\n mmm.sample_posterior(...)\n a = analyzer.Analyzer(mmm)\n posterior_baseline_draws = a._calculate_baseline_expected_outcome()\n posterior_negative_baseline_prob = np.mean(posterior_baseline_draws \u003c 0)\n\nAlternatively, one could examine the point estimate of the baseline aggregated\nover the entire time window, as in [Channel contribution charts](/meridian/docs/advanced-modeling/interpret-visualizations#channel_contribution_charts).\nHowever, remember that Meridian is a statistical and probabilistic\nmodel, and a point estimate can have significant uncertainty. A negative\nbaseline point estimate does not necessarily indicate model bias. It indicates\nerror, which can stem from either bias or variance (see [Bias--variance\ndecomposition of mean squared error](https://en.wikipedia.org/wiki/Bias%E2%80%93variance_tradeoff#Bias%E2%80%93variance_decomposition_of_mean_squared_error)).\nThis is especially true when the data contains limited information (see\n[Amount of data needed](/meridian/docs/advanced-modeling/amount-data-needed)).\n\nWe advise against overemphasizing a baseline time series, such as the one in\n[Model fit charts](/meridian/docs/advanced-modeling/interpret-visualizations#model_fit_charts),\nthat occasionally dips into negative values. An occasional, especially small,\ndip indicates minor error, which is inherent in any statistical model.\n\nNegative baseline versus contribution percentage\n------------------------------------------------\n\nThere is a subtle difference between \"total contribution exceeding\n100% of observed outcome\" (which occurs if incremental outcome exceeds\n**observed** outcome) and \"negative baseline\" (which occurs if incremental\noutcome exceeds **expected** outcome). The posterior distribution of total\nexpected outcome is usually very closely distributed around the total observed\noutcome, but the prior distribution of expected outcome typically has large\nvariance and is not centered around the observed outcome. Consequently, it does\nnot make much sense to evaluate the prior probability of negative baseline,\nwhich is why we advise evaluating the probability that contribution exceeds 100%\nof observed outcome instead.\n\nAlso note that the total expected outcome may differ from the total observed\noutcome if your model uses `revenue_per_kpi` values with high variance.\nTypically the total expected KPI will be very close to the total observed KPI,\nbut high variance in `revenue_per_kpi` can create a discrepancy between total\nexpected outcome and total observed outcome.\n\nMitigate negative or low baseline\n---------------------------------\n\nAs a first step, calculate the prior probability that the total treatment\ncontribution exceeds 100% of total observed outcome: \n\n from meridian.model import model\n from meridian.analyzer import analyzer\n import numpy as np\n\n mmm = model.Meridian(...)\n mmm.sample_prior(1000)\n a = analyzer.Analyzer(mmm)\n outcome = mmm.kpi\n if mmm.revenue_per_kpi is not None:\n outcome *= mmm.revenue_per_kpi\n total_outcome = np.sum(outcome)\n prior_contribution = a.incremental_outcome(use_posterior=False) / total_outcome\n total_prior_contribution = np.sum(prior_contribution, -1)\n np.mean(total_prior_contribution \u003e 1, (0, 1))\n\nAs a next step, calculate the prior probability that each individual treatment's\ncontribution exceeds 100%: \n\n np.mean(prior_contribution \u003e 1, (0, 1))\n\nIf these prior probabilities are too high, particularly when the data contains\nlimited information (see [When the posterior is the same as the prior](/meridian/docs/advanced-modeling/model-debugging#posterior-same-as-prior)),\na negative baseline problem may arise. Consider these adjustments to the prior\nand then reevaluate the custom priors using the checks described earlier:\n\n- Negative baseline is equivalent to the treatment effects getting too much credit. To mitigate this, set custom priors for the treatment effects (see [How to choose treatment prior types](/meridian/docs/advanced-modeling/how-to-choose-treatment-prior-types)) that reduce the prior probability that the total treatment contribution exceeds 100% of total observed outcome. In particular, a custom `contribution` prior type may be appropriate.\n- A channel with both high spend and high ROI might suggest that the channel drives more than 100% of the outcome, resulting in a negative baseline. For example, if your outcome is revenue and a channel's spend is 20% of total revenue, an ROI of 5.0 would indicate that the channel drives 100% of revenue (i.e., the channel's contribution is 100%). The actual ROI is likely much lower than 5.0, and setting a prior ROI to reflect this can help prevent a negative baseline. As a rule of thumb, the 90th percentile ROI prior for a channel shouldn't imply that the channel's contribution is over 100%.\n- If paid media is getting too much credit, consider setting the ROI prior in terms of total media contribution, so that the total media contribution has low prior probability of being larger than 100%. For more information, see [Set the total media contribution prior](/meridian/docs/advanced-modeling/unknown-revenue-kpi-custom#set-total-paid-media-contribution-prior).\n\nIn addition to adjusting the prior, there are a few other possible causes to\ninvestigate:\n\n- The model doesn't have enough high-quality controls, meaning controls that have an affect on both media execution and the response. Consider adding more meaningful controls or population scaling controls where it makes sense to do, such as query volume. Meridian does not population scale control variables by default. To population scale control variables, use `control_population_scaling_id` in `ModelSpec`.\n- The model is not sufficiently explaining time effects. Consider increasing `knots` or selecting more appropriate knot locations.\n\nAssess the baseline for trend and seasonality\n---------------------------------------------\n\nAssess whether the baseline time series, such as the one in\n[Model fit charts](/meridian/docs/advanced-modeling/interpret-visualizations#model_fit_charts),\nmatches the expected trend and seasonality of base demand. If the baseline fails\nto capture trend or seasonality during expected time periods, consider selecting\nmore knots around those periods. This can be achieved by setting `knots` to a\nlist, which specifies knot locations. Additionally, consider control variables\nthat could explain the trend or seasonality in the base demand (see\n[Control variables](/meridian/docs/advanced-modeling/control-variables))."]]