Variables, Processing Rules, and Data Mapping
Shape the hit before it is processed
Processing rules translate incoming context data into report suite variables without a code release. They run on every hit, top to bottom; each condition is evaluated against that hit and actions can set, copy, or delete values. They execute before VISTA rules, marketing channel processing, and classification lookups, which explains why a rule can repair a badly named eVar but cannot rescue a hit that was never sent. Rules are configured per report suite and only reshape existing data; they never generate new traffic.
Also master merchandising eVars, the products string, and marketing channels. The products string uses semicolons between fields (category, product, quantity, price, events) and commas between products, so a stray separator breaks an entire order. Merchandising eVars can be set in product syntax or conversion syntax and behave differently for allocation. Marketing channel processing rules are ordered and first match wins, so a broad paid search rule placed above an organic rule swallows all natural traffic.
Traps: expecting processing rules to retroactively fix processed data; setting an eVar with an expiration that does not match the business question; using a hit-expiring eVar at purchase time and then wondering why campaign revenue is zero; delimiter collisions inside list vars; and classification imports that overwrite values when you expected an append.
Rule of thumb: capture the truth in the data layer, then shape it in processing rules or datastream mapping. Never let a business rule live only inside the tag manager.
Worked example: a retail page pushes context data product equal to a four-field string and a campaign code. The rule copies the product string into the products variable, copies the campaign code into eVar1 (original allocation, 30-day expiration), and maps a numeric event for units. Test with a single order containing two distinct products, because that is where separator mistakes surface.