The Processing Rule That Overwrote the Campaign
A media company uses eVar1 for internal campaign codes. A processing rule copies prop4 into eVar1 whenever prop4 is not empty. Prop4 is set on every article page to the section name, such as Politics or Sports. The campaign plug-in sets eVar1 on landing pages from a query string. Since the rule was deployed, 22% of campaign entries are missing and eVar1 reports show section names instead of campaign codes. The team also uses list1 for article tags. Tag values sometimes contain commas, and list1 is configured with a comma delimiter. A merchandising eVar for promotion is set directly in the products string.
1. Explain why the processing rule overwrites campaigns and how to fix it without losing section reporting.
Read the worked answer
Processing rules run on the hit after it is received and before VISTA and marketing channel processing. When the condition matches, the assignment is effectively unconditional. Prop4 is populated on every article page, so the rule fires on campaign landing pages and overwrites the campaign value the plug-in wrote into eVar1. The 22% is the share of campaign landings that occur on article pages with prop4 present.
Fix options, in order of preference:
- Do not use a processing rule for a variable that another collection path owns. Set eVar1 from the plug-in and leave it alone. Put section reporting in prop4 or a separate eVar.
- If a rule is still needed, make the condition exclusive: copy only when eVar1 is empty and the hit is not a campaign landing, for example when no campaign query parameter exists. This is fragile and should be documented.
- Use a classification on prop4 for section, and keep eVar1 campaign-only.
Section reporting is preserved because prop4 remains the section dimension; campaign reporting is preserved because eVar1 is no longer overwritten.
2. What is wrong with list1, and what can be corrected for future data?
Read the worked answer
List variables split on a delimiter configured in the report suite. If a tag value contains the delimiter, one tag becomes several values. A tag such as election, recount becomes two list items and inflates the list report.
Choose a delimiter that cannot occur in tag values, such as a pipe or a non-printing character, set it in the report suite, and send the new format from a cutover date. Existing data cannot be re-split correctly without a data-repair or re-processing request, so decide whether the old values are materially wrong. If they are, allocate a new list variable and start clean. Validate with hit-level data rather than the list report alone, because the report aggregates away the splitting error.
3. How should the merchandising eVar be set and tested?
Read the worked answer
A merchandising eVar must be included in the products string with the product it applies to, for example s.products = 'Apparel;Jacket;1;120.00;event1=1;eVar7=SPRING'. The eVar must be configured for product merchandising and bound to the purchase event.
If the eVar is set outside the products string, it does not bind to the product, and promotion-level revenue will be wrong even though the eVar report looks populated. Test with a purchase hit and check the product-level Merchandising eVar report, not only the raw eVar report. Also confirm that the promotion value is present on the product line and that the binding event is the same event used for the purchase. Clear the eVar after the products string so later hits do not inherit the promotion.