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