我很快就要开始一个横幅旋转脚本,但我对如何开发它感到有点困惑。假设客户要求

“在接下来的 10 天内获得 10,000 次展示,费用为 10,000 美元。”

另一位客户要求

“1000 次展示只需 100 美元。”

第三个要求

“1,000 次点击或 10,000 次展示,只需 5,000 美元。”

我到底如何确定根据页面请求显示哪个横幅?我如何权衡其中一个?显然,第一个请求相当重要,因为我希望在时间窗口内提供一定数量的展示次数。

第二个客户并不那么重要,因为他们不关心时间窗口,他们只想要一些面对面的时间。

最后一个客户想要对展示次数/点击次数进行 n 或 m 限制,这使得事情变得稍微困难​​一些。

我已经非常有信心,我需要从这些场景中提取一些权重来确定谁最受关注。我的问题是哪种类型的算法可以处理这个问题,其次我如何才能按重量提供横幅而不总是为每个请求提供最重要的横幅?

有帮助吗?

解决方案

在困难来自时间上的限制比什么都重要。我会分裂谁没有指定由365(一年)时间限制任何人的优先级,然后用时间作为权重因子的一部分。所以:

Client 1 priority: 10000/10 = 1000 
Client 2 priority: 1000/365 ~ 3 
Client 3 priority: 10000/365 ~30

这应该让你优先的一个相当不错的指标。现在,你不能混搭展示和点击次数可以吗?他们要么去的印象路线或点击路线。眼看你无法控制的点击,但你可以控制的展示(至少比moreso点击),我会根据印象称重。

其他提示

使用随机数生成器选择要显示的广告,并根据每个广告的优先级对其进行加权。对于想要更多展示次数或有截止日期的客户,将权重系数设置得更高。如果时间快到了,您可以增加权重因子。

一旦客户达到了他们所要求的展示次数,请将权重降至 0 以阻止其广告展示。

默认权重可以是 1 左右,允许客户支付额外费用以提高优先级(无需告诉他们机制 - 将其记为“高级”放置等)。


编辑:权重细节

您可以根据需要使其简单或复杂,但基本版本将包含以下术语:

  • 如果广告已达到购买的展示次数/点击次数,则权重为 0
  • 基本权重(可能为 1.0)
  • 将权重乘以impressions_remaining / 所有客户剩余的总印象数
  • 如果剩余展示次数/点击次数很少,则添加一个小常数 - 确保他们获得完成帐户所需的最后几个次数
  • 对于截止日期的客户:添加术语(剩余展示次数/已购买展示次数)/(剩余时间/总时间)

客户的截止日期应该限制在所有页面显示的 90% 之类的,以确保他们不会在竞争中胜过其他人。最后一项给出了截止日期客户的“紧迫性”——随着截止日期的临近,它会变得无穷大,因此您应该对剩余时间段设置一个条件,以防止出现问题。

Microsoft Commerce Server包含一个点头算法(请参阅 http://msdn.microsoft.com/en-us/library/ms960081%28v=cs.70%29.aspxhttp://msdn.microsoft.com/en-us/library/ee825423%28v=cs.10%29.aspx )

我在 3 个不同的广告服务器中使用了该公式的派生版本,结果证明它非常适合我的条件。

关于您的情况的基本公式使用一个名为 NOD 的变量,它是“交付需求”的缩写。在任何给定时间,横幅的“基本”NOD 公式是:

nod =(剩下的事件 /请求的总事件) *(总运行时 /剩余的运行时)

请注意,“事件”是一个通用术语,可能代表展示次数、点击次数、转化次数等。取决于您的系统。

该方程表明,所有横幅的生命值都以 1.0 开始,因为 (e / e) * (t / t) = 1.0

NOD 值高于 1 意味着您落后于计划,而 NOD 介于 0 和 1 之间通常意味着您显示横幅“太快”。0.9 到 1.2 之间的值通常在可接受的范围内(这不是技术范围,而是业务经验)。

只要服务比率与持续时间比率匹配,值就会保持在 1.0 左右。

对于特定广告位,算法会检查该广告位上可作为目标的所有可用横幅的 NOD。假设一个槽位上有 3 个可用横幅,NOD 值分别为 0.6、1.35 和 1.05,总计为 3.0。那么每个横幅显示的相对概率依次变为 20%、45% 和 35% [ 0.6 / (0.6 + 1.35 + 1.05)] = 20%

该算法采用加权概率分布,这意味着即使是NOD值最小的横幅也有机会被展示。虽然基本公式使用这种方法,但业务决策通常总是迫使我实施比原始公式更有利于紧急 NOD 值的算法。因此,我将基本 NOD 与它们自身相乘。在同一示例中,概率的顺序为11%,55.5%和33,5%。

根据您的情况,您可以考虑稍微改变配方以满足您的需求。首先,为了能够比较通过显示横幅获得的收入,您应该将所有显示类型(展示、点击、操作等)转换为通用的 eCPM 值。然后,您可以使用此有效每千次展示费用作为原始方程的乘数。

对于尚未发布的广告系列,计算 eCPM(有效 CPM)可能会很棘手,在这种情况下,您应该使用历史数据。

让我稍微解释一下这部分:当尝试比较通过“展示”单个横幅获得的可能收入时,您不需要比较基于展示次数的预算。对于基于点击的预算,您应该使用历史点击率值来猜测“我的系统需要提供多少展示次数才能获得 X 个点击”。更高级的算法可能会利用“我的系统需要提供多少展示次数才能在 y 库存中获得 X 类别的广告活动”。

那么你的最终方程就变成:

nod = ecpm *(剩余的事件 /请求的总事件) *(总运行时 /剩余的运行时)

您始终可以考虑使用 eCPM 的力量来比较结果。就像我改变原始公式以支持更紧急的活动一样,您可能会喜欢“支付更多”的活动。

我真的很喜欢 AlbertoPL 基于时间的方法,但他没有考虑点击次数。很容易演示与点击相关的病理情况:

  • 客户 A 为 1 次点击或 10,000 次展示提供 1000 美元
  • 客户 B 为 5000 次点击或 10,000 次展示提供 1000 美元。

任何有理智的人都会给予一键点击者更高的优先级。计算实际上非常简单:假设您的点击率为每次点击 100 次展示。

  • 客户 A 想要 10,000 次展示或 1 次点击,因此我们要求至少达到 100 次展示才能获得付款。每 100 次展示的费用为 1000 美元,您可以计算出您的客户愿意为每次展示支付 10 美元。

  • 客户 B 想要 10,000 次展示或 5000 次点击。5000 次点击需要 500,000 次展示,在此之前我们显然会达到 10,000 次展示大关,因此我们假设客户确实愿意为 10,000 次展示支付 1000 美元,或每次展示 0.10 美元。

我们通过最大化 $$$$$/印象来最大化收入,因此客户 A 优先。让我们使用OP中提供的数字:

客户1:

  • 未来 10 天内获得 10,000 次展示,费用为 10,000 美元
  • = 至少 10,000 次展示 * 1 美元/展示 / 10 天
  • = 1000 美元/天

客户2:

  • 1,000 次展示只需 100 美元
  • = 至少 1,000 次展示 * $.01/展示 / 365 天
  • = 0.27 美元/天。

客户端3:

  • 1,000 次点击或 10,000 次展示,只需 5000 美元
  • = 分钟(100,000 次展示,获得 1,000 次点击,10,000 次展示)= 10,000 次展示,费用为 5000 美元
  • = 至少 10,000 次展示 * 0.5 美元/展示 / 365
  • = 13.7 美元/天。

客户根据每天支付的金额优先。

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top