eVar, prop, event Strategy: Mapping to Business Outcomes

Why variable strategy matters

A good variable plan is not a list of fields—it’s an operating model for measurement. When eVars, props, and events are intentionally aligned to outcomes, teams can:

Prove impact with unambiguous attribution.
Scale across products, regions, and campaigns without rework.
Reduce QA noise, cardinality explosions, and reporting conflicts.

A 3-minute refresher

eVars: Persistent dimensions used to attribute success events across time (allocation and expiration control how persistence credits events). Ideal for marketing sources, product IDs, user/account traits, promotion codes, and “things that deserve credit.”
Props: Hit-scoped dimensions used for immediate context and pathing (entries, exits, next/previous). Ideal for page template, component names, click context, error codes, and internal search terms when pathing matters.
Events: Count, numeric, currency, or duration metrics that represent outcomes (lead submitted, quote generated, revenue, errors). Events are what eVars get credit for and what props describe on the hit.

Strategy anchor: start from outcomes, not fields

List the business outcomes that stakeholders pay for: leads, qualified demos, quotes, trials started, orders, revenue, churn saves, support deflections.
Model the outcome’s journey (preconditions, interactions, system confirmations).
Assign one or more events to the outcome (e.g., event “lead_submitted”; event “order_revenue” with currency).
Decide what deserves credit (channels, offers, audiences, content, products). Those become eVars.
Decide what needs pathing and UI context (component names, page types). Those become props.
Lock allocation and expiration for eVars so attribution mirrors your commercial reality.

Governance patterns that keep data trustworthy

One-page SDD per outcome: outcome definition, canonical event(s), success criteria, eVars that can claim credit, props for hit context, QA steps, and owner.
Naming convention: snake_case for data layer keys; short, human-readable labels for reported components (“Lead source (eVar12)”).
Allocation/expiration: document the “why” and align to buying cycle length; avoid defaults.
Change control: any change to allocation/expiration requires impact review and effective dates.
Cardinality guardrails: require enumerations or lookup tables for anything user-entered.

Allocation and expiration cookbook (with examples)

Marketing channel/source (eVar): Most recent (override), visit-level expiration. Why: last non-direct touch claims credit in the session.
Campaign ID (eVar): Most recent, visit-level or 7–30 days. Why: honor campaign windows.
Offer/promo code (eVar): Original (first) or most recent, visit or purchase-level. Why: choose policy—first-touch incentive vs. latest code used.
Product ID (merchandising eVar bound to products): Most recent, hit-level for cart actions or purchase-level for orders. Why: item-level attribution to the correct SKU.
Account ID / Industry (eVar): Original (first) or most recent, visitor-level expiration (90–365 days). Why: B2B stitching across sessions.
UI Component (prop): Hit-level only; pathing enabled. Why: entry/exit and flows across components.
Page Template (prop): Hit-level, pathing enabled. Why: identify high-exit templates, navigation friction.
Error Code (prop): Hit-level. Why: diagnose defects when error events fire.

Merchandising and product-level attribution done right

If revenue is a business outcome, bind product-context eVars to s.products on the same hit as cart and purchase events. Example bindings:

eVar for product_id (merchandising): credits all commerce events for that item.
eVar for product_category: analyze add-to-cart and revenue by taxonomy.
eVar for promo_applied: compare revenue lift when a promotion was present at item-level.

Pro tip: Avoid mixing PDP variant IDs with parent IDs—choose one scheme and carry variant in a separate eVar to prevent split attribution.

Prop and eVar together: when and why

Use both when a dimension needs attribution over time and pathing on the hit:

Internal search term: eVar for attribution to “lead_submitted” and “order” events; prop for pathing (search → PDP → checkout).
Site section or content group: eVar to credit conversions to the initial section; prop to identify entry/exit and navigational flows.
CTA label: eVar for cross-journey credit (if the CTA represents a campaign or offer), prop for click context and component pathing.

Event taxonomy: align to business and engineering

Group events by outcome families and keep counts clean:

Acquisition: lead_submitted, trial_started, signup_completed.
Revenue: order_revenue (currency), refund_amount (currency), subscription_started, subscription_renewed, subscription_canceled.
Product engagement: feature_used, video_complete, doc_downloaded.
Support/quality: error_raised, error_resolved, deflection_completed.
Lifecycle milestones (B2B): opportunity_created, opportunity_stage_changed, meeting_booked.

For currency events, enforce a single currency per report suite or carry currency code and convert downstream—be consistent.

Data layer contract that maps cleanly

Emit a normalized data layer for each event; Launch rules map keys to eVars/props/events:

event: “lead_submitted”, “order_completed”, etc.
ctx.*: page_name, page_template, component_name, language, region.
user.*: auth_state, account_id, industry, plan_tier.
marketing.*: channel, source, medium, campaign_id, creative_id, term.
commerce.*: transaction_id, value, tax, shipping, coupon, items[].
items[]: id, name, category, brand, variant, price, quantity.

This structure lets you bind persistent eVars (marketing, user) and hit props (page/component) reliably without DOM scraping.

Sample mappings you can lift into an SDD

eVar12 Campaign ID: most recent, 30-day expiration, participation model in Workspace for influence; credited to lead_submitted, trial_started, order_revenue.
eVar21 Account ID: original, visitor-level 180 days; credited to all B2B lifecycle events.
eVar31 Product Category: merchandising binding to products; credited to add_to_cart, purchase, refund.
prop5 Page Template: hit-level, pathing enabled; used in Fallout and Flow.
prop14 Component Name: hit-level, pathing; used for component engagement analysis.
event1 Lead Submitted: counter; fired on server-acknowledged lead creation.
event10 Order Revenue: currency; fired with s.products and tax/shipping parameters.
event32 Error Occurrence: counter; pairs with prop/error_code to triage.

Attribution choices that mirror reality

Use participation or linear for content assists over long cycles; use last touch (visit) for operational conversion reporting.
For promotions, first touch encourages original offer credit; most recent discourages code swapping. Document the rationale and stick to it.
When multiple sources claim credit (e.g., retargeting + brand search), decide if you’ll accept dual credit (participation) in analysis and single credit in finance. Communicate the difference.

Quality, cardinality, and privacy guardrails

Limit high-cardinality eVars: URLs, free-text, and user-entered strings can explode reports—classify them via lookups or map to controlled enums.
Enforce lowercase normalization and trimming in processing rules to reduce duplicates.
Never store PII in eVars/props; hash only when contractually allowed and never as a unique ID in reports.
Cap list sizes: if list props/eVars are enabled, implement sane separators and maximum lengths; validate on the client before sending.

B2B-specific extensions

Visitor/account stitching: Use account_id in a persistent eVar with a well-defined expiration; join CRM offline for pipeline and revenue.
Opportunity analytics: Model opportunity_id and stage in eVars; fire events on stage changes with numeric revenue (forecast vs. actual).
Content influence: Attribute pipeline to gated content by using a content_id eVar that persists through the visit and across visits where justified.

QA and rollout checklist

For every new outcome: test allocation/expiration with synthetic journeys (switch pages, convert later) and verify the eVar still claims credit.
Validate that props used for pathing are present on all relevant hits (no nulls that break flows).
Confirm that merchandising eVars resolve on s.products lines for all commerce events.
Compare Workspace results to a controlled dataset (server logs/warehouse) during a pilot window; document expected deltas (bot filtering, time zones, processing time).

Operating model to keep strategy alive

Monthly review: top 20 dimensions/metrics by usage and data quality; retire or repurpose unused variables.
Change board: review requests for new eVars/props/events; enforce naming, allocation/expiration, and cardinality policies.
Versioned SDD: every change has an effective date, owner, and migration guidance (e.g., “eVar18 industry replaced by eVar52 vertical; dual-report for 30 days”).
Training: publish Workspace templates (Acquisition, Product, Commerce, Support, B2B Pipeline) that encode your attribution choices.

Closing thought

The most successful Adobe Analytics programs don’t treat eVars, props, and events as “available slots.” They are contracts that encode how the business assigns credit and context to outcomes. Start from outcomes, choose eVars for what deserves credit, props for what needs pathing and hit context, and events for the moments that matter. Lock allocation and expiration to business reality, document relentlessly, and your analytics will stay resilient through redesigns, rebrands, and leadership changes.

👉 Want to set up a tailored variable strategy for your business outcomes? Contact us today.

References & Further Reading

Need help implementing GA4, GTM, or KPI restructuring?

Schedule free consultation