Because variables in Adobe Analytics tend to be scarce resources, Medallia represents a survey response in Analytics using a single conversion variable (i.e., eVar) and stores each related data as metadata (called Classifications), by default.

By default, the parent value (at the eVar value) and joining key should be the feedback UUID, but other IDs can be considered depending on use case (e.g., session ID). Records are then enriched on a daily basis using this value to populate the Classifications nested inside.

Below is the full list of options available to store data in Adobe Analytics. The perfect design depends on your exact needs. Medallia recommends keeping it as simple as possible .

• Medallia Survey (required) — Key is the UUID set by the on-site integration (regardless of the implementation method); the rest can be enriched later via backend integration.

  • Example of eVar value — 'cbde-3eb4-7be7-7ac2-a8a5-40c4-a2b2-bf33'

  • Pro — Most use cases do not require survey data to flow in real time in Analytics. Batching offers a more efficient solution. Set of data available is broader.

  • Con — Cannot be used to immediately detect an emerging issue; take action on site in real time.

• Tracked key metrics (optional) — Key and data concatenated and set by on-site integration. This relies on a parsing rule to populate classification.

  • Example of an eVar value with one key scale question answer for Overall Satisfaction (e.g., osat score of 9) — '|uuid:cbde-3eb4-7be7-7ac2-a8a5-40c4-a2b2-bf33|osat:9|'

  • Pro — This is the only way to help a Digital marketer to detect issues with the website swiftly by analyzing Adobe data. This is a use case that is best monitored within Experience Cloud.

  • Con — Dataset available on the site is limited. Because of limitations in how classifications can be set in Adobe Analytics, you will need to set up parsing rules, which creates extra complexity, client effort, and maintenance. Only use if critical and if the relevant person cannot access Experience Cloud.

• One conversion variable per key metric (not recommended)

  • Expensive design in terms of eVars used. This is not recommended except if true, in which case real-time is a must.

  • Example of eVar value — '9'