What happens
after the hit.

1 · The processing pipeline

From the moment a hit lands on Adobe's edge to the moment it appears in Workspace, it passes through several transformation layers — each capable of changing variables, dropping the hit entirely, or splitting it across report suites.

Browser
  │  (HTTPS GET / POST)
  ▼
Adobe Edge / Data Collection
  │
  ▼
┌──────────────────────────────────────────┐
│  VISTA rules         (Adobe-managed)     │
│  Processing rules    (Admin Console)     │
│  Marketing channels  (Admin Console)     │
└──────────────────────────────────────────┘
  │
  ▼
Reporting database (with classifications applied at read time)
  │
  ▼
Workspace

Three of these — Processing Rules, Marketing Channels, and Classifications — are configured by you in the Admin Console. VISTA rules are configured by Adobe ClientCare on your behalf, usually for use cases that exceed Processing Rules' capabilities.

2 · Processing rules

Processing rules transform hits server-side, after collection, before storage. Configured in Admin Console → Report Suites → Processing Rules.

Why they exist: sometimes you cannot or should not change client code. Maybe the dev team's release cycle is six weeks and you need a fix today. Maybe the data layer is wrong and you don't control it. Maybe you want to normalise across many sites sending into one report suite.

Capabilities of a processing rule:

• Set, copy, or overwrite any eVar, prop, or event.
• Copy a value from one variable to another (e.g. "copy eVar15 to eVar22").
• Concatenate values.
• Apply conditional logic (if-this-then-that based on any other variable's value).
• Discard the entire hit if conditions match (a powerful, dangerous capability).

Limitations:

• You cannot read or write to the visitor profile — no access to history.
• No regex on values (only on URLs in the marketing-channel processor, which is separate).
• Rules execute in declaration order; later rules see the effect of earlier ones.
• No backfill — rules apply only to hits collected after the rule is enabled.

3 · Common processing-rule patterns

3.1 — Concatenation for hierarchy reports

The site sends section in eVar1 and sub-section in eVar2. Analyst wants a single eVar that shows "Shop > Telescopes" for drill-down.

Rule: Build sub-section path
  IF   eVar1 is set
  AND  eVar2 is set
  THEN Overwrite eVar30 with concatenation:
       eVar1 + " > " + eVar2

3.2 — Default value

The implementation sometimes forgets to set channel. You want every hit to have something useful:

Rule: Default channel to "Unknown"
  IF   channel is NOT set
  THEN Overwrite channel with: "Unknown"

3.3 — Per-domain report-suite split

You collect three brands into one global report suite, but each brand has its own report suite too. A copy-to-extra rule handles this — though in practice this is handled by Multi-Suite Tagging in Launch, not processing rules.

3.4 — Bot exclusion by IP

Not a processing rule but a related Admin-Console setting: IP Exclusion. List the office's public IPs to keep internal QA out of production data. Always exclude vendor monitoring services (Pingdom, StatusCake).

4 · VISTA rules

VISTA (Visitor Identification, Segmentation, and Transformation Architecture) is the older, more powerful server-side rules engine. Where processing rules are configured by customers, VISTA rules are configured by Adobe Engineering Services for paid engagements.

VISTA can do everything processing rules can, and also:

• Regex matching and substitution on any variable.
• Cross-variable transformations using sophisticated logic.
• Look up against external lookup tables.
• Split a single hit into multiple report suites with different transformations.

You don't write VISTA rules — Adobe does, against requirements you supply. They're useful for legacy implementations that can't be re-engineered, or for very high-volume regex transformations that would clutter processing rules.

The trade-off: VISTA rules are billed work, documented only in your contract, and invisible in the Admin Console. They are a black box for anyone who joins after they were configured. Strongly prefer processing rules where the capability exists.

5 · Classifications

Classifications are read-time transformations. Where processing and VISTA rules rewrite the value stored against a variable, classifications add alternate views of the same value — a lookup table mapping eVar values to additional attributes.

Concrete example. eVar15 stores campaign codes like "gpaid-summer25-1199". Without classifications, the eVar15 report is unreadable. With classifications, the same hit appears in reports as:

Each new column is a "classification" of eVar15. You configure them in Admin Console → Report Suites → Edit Settings → Conversion Classifications.

Why it matters: classifications are retroactive. Upload a new mapping today and every historical hit that carried that eVar value is reported with the new attribute, instantly, with no backfill required. This is exactly what processing rules cannot do.

5.1 — Where to use them

• Campaign codes → human-readable channel / source / campaign / asset
• Product SKUs → product name / category / brand (for the Products report)
• Author IDs → author name / department / region (for content reports)
• Search terms → category / language / intent (heavy lift; usually via SAINT importer)

6 · The classification importer

Two ways to upload classification data:

1. Manual upload — a tab-delimited file via Admin Console. Useful for one-off campaign lookups.
2. SAINT FTP / API — Adobe hosts an FTP endpoint per report suite. Drop a classification file and Adobe processes it nightly. Useful for ongoing campaign attribution where marketing teams add codes daily.

File format:

## SC SiteCatalyst SAINT Import File v:2.1                                  
## SC                                                                       
## SC Generated 2025-09-15  by AAAcademy                                    
## SC                                                                       
Key             | Channel       | Source     | Campaign Name      | Variant 
gpaid-summer25-1199 | Paid Search | Google     | Summer Sale 2025   | v1199  
fb-loyalty-440      | Paid Social | Facebook   | Loyalty FY25       | v440   

Columns are tab-delimited. The first column is the eVar / prop / event value being classified. Subsequent columns are the classification dimensions, defined in Admin Console.

6.1 — Rule-based classifications

Adobe added a UI to define classifications via regex against the variable value, no FTP file needed. For values that follow a predictable pattern (campaign code format always {channel}-{campaign}-{id}), this is faster than maintaining a file. Find it under Admin → Classification Rule Builder.

7 · Governance and risk

Server-side transformations are powerful exactly because they're invisible. A new analyst looks at a report, sees nothing in the network panel that explains a value, and is stuck. Document everything.

Minimum hygiene for any team running processing rules / VISTA / classifications:

• A wiki page per rule. What does it do, why does it exist, who requested it, what dates is it active.
• A naming convention for classifications. Don't have a column called "Campaign Name" in one suite and "Campaign" in another.
• A change log. Adobe doesn't keep one for processing rules. You must.
• A quarterly audit. List every rule, classification, VISTA. Mark any that are no longer used. Decommission them.

The same hygiene applies to marketing channels, which we haven't covered explicitly — it's a small DSL in Admin Console for parsing campaign / referrer / tracking-code into a channel attribution. It's a special case of processing rules with its own UI; the governance discipline is identical.

8 · Checkpoint

You should now be able to:

• Explain where in the pipeline a processing rule fires (server-side, after collection, before storage).
• Choose between a Launch fix and a processing-rule fix for a given bug.
• Set up a classification for campaign codes with three sub-dimensions.
• Recognise when retroactive correction is needed (classifications) versus going-forward correction (processing rules).