Home AppMeasurement Web SDK · Migration Guide Created by Amit G Dusane

MigrationKnowledge Base › The Full Extension

Decisions

The Full Extension

If the schema is the blueprint, field groups are the pre-drawn room templates you drop into it. For an Analytics migration, one template does almost all the work.

The Adobe Analytics ExperienceEvent Full Extension adds the entire _experience.analytics structure, every eVar, prop, event, hierarchy, and list[3][4], and the Edge already knows how to translate those fields straight into your Analytics variables. No processing rules required.

Anything you put outside this structure (a custom field group of your own) does not auto-map: it arrives in Analytics as a context-data variable prefixed a.x., and you map it with a processing rule. That's occasionally what you want, but for standard eVars/props/events it's needless labour.

For your migration: adding this one field group is the difference between drag-and-drop mapping and hand-wiring two hundred variables through processing rules. It's the highest-leverage click in the whole build.

⚑ Architect's Decision

Always add the Adobe Analytics ExperienceEvent Full Extension. Hand-mapping variables through processing rules is a last resort, never the default.

Full detail, the complete reference

What it contributes

The Adobe Analytics ExperienceEvent Full Extension adds the complete _experience.analytics object: eVars (customDimensions.eVars.eVar1..250), props and list props (customDimensions.props / .listProps), events (event1to100, event101to200, …), plus hierarchies and lists. In one move your schema gains a named home for every Analytics variable you have.

The auto-mapping, why it's the highest-leverage click

The reason this field group matters isn't the fields, it's that the Edge already understands them. Populate _experience.analytics.customDimensions.eVars.eVar12 and it lands in eVar12, no processing rule[3][4], no configuration. Compare that to the alternative: a value modelled outside this structure arrives as a.x. context data and needs a processing rule to reach a variable. Across a 200-variable implementation, that's the difference between an afternoon and a month.

Events and serialization

Events carry a value and, when you need de-duplication, an id, the XDM equivalent of the old event7:dedupeID syntax.

counter / numeric : _experience.analytics.event1to100.event7.value = 1 serialized : ...event7.value = 1 + ...event7.id = "ORD-55012"
Also add

For commerce, include the Commerce / productListItems field group too. And remember: adding the field group is necessary but not sufficient; you still leave the schema's Profile toggle off until validated.