Originally published at Analyst Admin.

最初发布于Analyst Admin 。

In my experience working with Adobe Analytics, I’ve found that Processing Rules help in some cases, but oftentimes they create more work. I try to avoid using Processing Rules whenever possible. In this post, I will cover the main reasons why using Adobe Analytics Processing Rules is not worth it for me.

在使用Adobe Analytics的经验中，我发现处理规则在某些情况下会有所帮助，但通常它们会带来更多工作。 我尽量避免使用处理规则。 在这篇文章中，我将介绍为什么不适合使用Adobe Analytics Processing Rules的主要原因。

跟踪问题更加困难 (Tracing Issues Is More Difficult)

第1部分-附加故障点 (Part 1 — Additional Point of Failure)

Picture this — you see a strange value in your Custom Conversion report, so you begin to investigate. The page data layer looks fine. The data beacon looks fine. You can’t replicate the issue. Then you begin to wonder, maybe the issue is only on certain devices? Or only on certain browsers? You continue to spend time checking and rechecking your tracking. After a while, you remember the Processing Rule you created a year ago, and sure enough, you find that it was the culprit causing the issue.

想象一下-您在“自定义转化”报告中看到一个奇怪的值，因此开始调查。 页面数据层看起来不错。 数据信标看起来不错。 您无法复制该问题。 然后您开始怀疑，也许问题仅在某些设备上存在？ 还是仅在某些浏览器上？ 您继续花时间检查和重新检查您的跟踪。 过了一会儿，您还记得一年前创建的“处理规则”，果然，您发现这是导致此问题的罪魁祸首。

In a typical Adobe Analytics data pipeline, data gets collected at the browser, then goes to Adobe for processing. Any point where data is created, collected, or transformed can be a point of failure. For example:

在典型的Adobe Analytics数据管道中，数据在浏览器中收集，然后转到Adobe进行处理。 创建，收集或转换数据的任何点都可能是故障点。 例如：

1. The server can send faulty data
   服务器可能发送错误数据
2. The tag manager can be misconfigured
   标签管理器可能配置错误
3. Adobe Analytics could be filtering your data via Bot Rules or IP Filters
   Adobe Analytics可能通过Bot规则或IP过滤器过滤了您的数据
4. Adobe Marketing Channel Processing Rules could be miscategorizing your traffic sources
   Adobe Marketing渠道处理规则可能对流量来源进行了错误分类

If you add Processing Rules to the pipeline, you would add an additional transformation step. An increase in steps would inherently increase the complexity of the model and introduce an additional point of failure which makes tracing issues more difficult.

如果将“处理规则”添加到管道，则将添加其他转换步骤。 步骤的增加会固有地增加模型的复杂性并引入额外的故障点，这将使跟踪问题更加困难。

第2部分-处理规则具有级联作用 (Part 2 — Processing Rules Have a Cascading Effect)

That’s right — Processing Rules are daisy-chained. This means that variables are transformed and passed down to the next Processing Rule, which makes tracing issues difficult.

没错-处理规则是菊花链式的。 这意味着变量将被转换并向下传递到下一个处理规则，这使得跟踪问题变得困难。

Let’s say you have 50 rules, and you identify that rule #25 is transforming your variable. By the time beacon data gets to rule #25, your data could have been transformed 24 different ways. This means that if you see a data beacon with a value “abc”, by the time data gets to rule #25 it could say “xyz” instead. A somewhat useful but human-error-prone way to check what Processing Rules are doing is to take a sample value and manually go through each rule and keep track of the transformations on paper.

假设您有50条规则，并且您确定规则25正在转换变量。 当信标数据达到规则25时，您的数据可能已经以24种不同的方式进行了转换。 这意味着，如果您看到数据信标的值为“ abc”，那么当数据到达规则25时，它可能会改为“ xyz”。 检查处理规则正在执行的一种有用但容易人为错误的方法是获取一个样本值，然后手动检查每个规则，并在纸上跟踪转换。

Furthermore, you also need to worry about the rules that follow the rule that you are working with. Each rule has the same potential to modify your variable whether it’s before or after the rule that you edit.

此外，您还需要担心遵循所使用规则的规则。 无论是在编辑规则之前还是之后，每个规则都有修改变量的潜力。

Take this example:

举个例子：

• Rule #1: Set v3 on checkout page where campaign = social
  规则1：在结帐页面上设置v3，其中广告系列=社交
• Rule #2: Set c3 from v3
  规则2：从v3设置c3
• Rule #3: Set v5 into c5
  规则3：将v5设置为c5
• Rule #4: Patch for v3 missing on cart page
  规则4：购物车页面上缺少v3补丁
• Rule #5: Set v4 based on v3 equal to “us|shop”
  规则5：根据v3将v4设置为等于“ us | shop”
• Rule #6: Set v3 on homepage for mobile
  规则6：在首页上为手机设置v3
• Rule #7: Add v3 when v3 is not set
  规则7：未设置v3时添加v3

If you needed to update Rule #4, it would behoove you to also check the rules before and after #4 to make sure the final state of v3 is what you were expecting.

如果您需要更新规则＃4，那么您还应该检查＃4之前和之后的规则，以确保v3的最终状态符合您的期望。

Now picture 100+ rules, a laggy browser, 10 team members, and more not-so-great rule names — It’s a recipe for disaster.

现在可以查看100多个规则，一个浏览器缓慢，10个团队成员以及更多不太好的规则名称-这是灾难的秘诀。

处理规则界面笨拙 (The Processing Rules Interface Is Clunky)

When you first load the Processing Rules editor, all rules are collapsed — this makes it impossible to CMD+F (search) by rule definition. Expanding each rule can take a long time since the more rules that you have expanded the worse the whole page lags. I’ve had times where after expanding 100+ rules the page will crash and I need to restart at the top.

首次加载“处理规则”编辑器时，所有规则都将折叠起来-这使得无法通过规则定义进行CMD + F(搜索)。 扩展每个规则可能需要很长时间，因为扩展的规则越多，整个页面的滞后就越严重。 在扩展100多个规则之后，有时页面会崩溃，而我需要在顶部重新启动。

In my desperation, I tried every browser imaginable and found that Firefox is the fastest when dealing with 100+ processing rules.

无奈之下，我尝试了所有可以想象的浏览器，发现Firefox在处理100多个处理规则时是最快的。

Bonus: The interface is so clunky and slow that one time while waiting for a rule to expand I built an entire Processing Rules exporting tool that uses the 1.4 APi. Try it here.

奖励：界面是如此笨拙且缓慢，以至于在等待规则扩展时有一次，我构建了一个使用1.4 APi的完整处理规则导出工具。 在这里尝试 。

处理规则有限 (Processing Rules Are Limited)

Yes — 150 is the max…can we lower it to zero?

是的-最大值为150…我们可以将其降低为零吗？

Keep in mind that you will only see this message when you try to save. The page will allow you to add more than 150, but it won’t actually save.

请记住，您尝试保存时只会看到此消息。 该页面将允许您添加150多个，但实际上不会保存。

文档问题 (Documentation Is An Issue)

Keeping track of Adobe eVars, Props, Success Events, and their corresponding Processing Rules can only be done manually. There is no automated solution for extracting variable transformations from Processing Rules. This is part of the reason why tracing issues involving Processing Rules is more difficult.

跟踪Adobe eVar，道具，成功事件及其相应的处理规则只能手动完成。 没有从“处理规则”中提取变量转换的自动化解决方案。 这是跟踪涉及处理规则的问题更加困难的部分原因。

测试处理规则很慢 (Testing Processing Rules Is Slow)

Testing Processing Rules requires patience since there is no real-time Processing Rules testing feature. For example, if you created a new rule for an eVar and wanted to validate the rule by checking the data, you would have to wait up to 90 minutes for the eVar data to get processed and become available in Analysis Workspace or Reports and Analytics.

由于没有实时的处理规则测试功能，因此测试处理规则需要耐心。 例如，如果您为eVar创建了新规则，并想通过检查数据来验证规则，则您可能需要等待90分钟才能处理eVar数据并使其在Analysis Workspace或Reports and Analytics中可用。

As a workaround sometimes I will copy the data to a prop since props are available in real-time reporting, which I can validate immediately without waiting for the eVar.

作为一种解决方法，有时我会将数据复制到道具，因为道具可以在实时报告中使用，我可以立即进行验证，而无需等待eVar。

You might think “This guy really hates processing rules!”, and the truth is that I don’t hate them, I just find that using them is not worth the hassle. However, there are perfectly valid reasons to use them — for instance, if you have no choice (Adobe Heartbeat) or if you need to put in a quick patch.

您可能会认为“这个家伙真的很讨厌处理规则！”，事实是我不讨厌它们，我只是发现使用它们不值得麻烦。 但是，有完全正当的理由使用它们-例如，如果您别无选择(Adobe Heartbeat)或需要快速添加补丁。

Now let’s hear from you — what’s your experience using Adobe Analytics Processing Rules?

现在，让我们听听您的声音-使用Adobe Analytics处理规则有什么经验？

Originally published at https://blog.analystadmin.com

最初发布在 https://blog.analystadmin.com